Yeah, that's what I do too. I just wish it wouldn't clobber the stats on
the indices after I've so carefully gathered them. We have the 6.2 sapdba,
so I don't think it's using dbastatc as much to control when and how it does
the stats.
Russ
-----Original Message-----
Sent: Wednesday, August 21, 2002 1:59 PM
To: Multiple recipients of list ORACLE-L
Ironically, analyzing tables is one of the jobs I leave up to SAPDBA.
There are a number of tables that shouldn't be analyzed, ( ~150
on my system ) and the system knows which ones they are.
Just schedule the job through transaction DB13 and forget about it.
Jared
paquette stephane <stephane_paquette_at_YAHOO.COM>
Sent by: root_at_fatcity.com
08/20/2002 09:48 PM
Please respond to ORACLE-L
To: Multiple recipients of list ORACLE-L <ORACLE-L_at_fatcity.com>
cc:
Subject: Re:drop tablespace including contents
At one client, one team was using SAP without a DBA,
only the SAP administrator using SAPDBA. They were
having poor performance.
After 2-3 days they came to see me, after 5 minutes I
told them that 4000 tables out of 16 000 were having
no statistics at all. They analyzed during the weekend
and performance was pretty good ....
- Jared.Still_at_radisys.com a écrit : > Dick,
>
> There is absolutely *nothing* that SAPDBA does that
> a reasonably
> knowledgeable DBA can't do from his of her favorite
> toolset.
> ( vi, Perl and sqlplus for me :)
>
> SAP types have it drummed into their heads that the
> only proper
> way to do anything DBA work is via SAPDBA.
>
> I refuse to use it, and it just drives the SAP
> consultants crazy.
>
> There are many cases where a good DBA can do a much
> better
> job than SAPDBA. The tablespace reorganization is a
> good
> example. Trying to 'drop tablespace including
> contents' with
> 3500 tables is not a terribly bright way of going
> about it.
>
>
> Jared
>
>
>
>
>
>
>
> dgoulet_at_vicr.com
> Sent by: root_at_fatcity.com
> 08/20/2002 02:43 PM
> Please respond to ORACLE-L
>
>
> To: Multiple recipients of list ORACLE-L
> <ORACLE-L_at_fatcity.com>
> cc:
> Subject: Re:drop tablespace including
> contents
>
>
> Russ,
>
> Your high usage of RBS was due to the updates
> being done to the system
> data
> dictionary. Since you were dropping a tablespace
> and contents the DDL
> statements for the individual objects (tables and
> indexes) needs to be
> done
> first, but I've a funny idea from practice that
> Oracle does not do an
> implicit
> commit in this case but instead holds on till the
> end. This makes
> dropping a
> tablespace with the "including contents" caviot very
> nasty. Thank GOD we
> never
> implemented SAP over here. I've heard nothing but
> bad about SAP and
> sapdba.
>
> Dick Goulet
>
> ____________________Reply
> Separator____________________
> Author: "Brooks; Russ" <Russ.Brooks_at_dayzim.com>
> Date: 8/20/2002 11:13 AM
>
> Hi,
> This past weekend we experienced a problem on a
> production database, and I
> would
> like to try to determine what went wrong, how to
> avoid it in the future,
> and any
> better ways of dealing with it should it be
> encountered again.
> After moving some large objects out of tablespace to
> spread I/O, we wanted
> to
> reorganize the old tablespace to remove some
> fragmentation. The tool we
> were
> using, sapdba, does not readily permit you to drop
> the individual tables
> between
> the export and the drop tablespace including
> contents. Since the
> tablespace had
> over 3500 tables the drop tablespace was expected to
> take a long time. We
> also
> defined a large rollback segment for use this
> weekend, although with only
> maxextents of 100. When Oracle tried to allocate the
> 101 extent in the
> RBS,
> error messages were issued and things came to a
> grinding halt. sar
> indicated
> disk I/O to the new RBS, but not to any of the
> datafiles. We waited
> several
> hours, but the situation did not appear to change.
> Shutdown immediate did not work. We could alter the
> datafiles back online,
> but
> not the tablespace. Since it was production, the
> decision was made to
> restore to
> a recent backup.
> 1. Was the rollback activity due solely to storing
> and restoring DDL for
> the
> tables and indices?
> 2. Once the RBS was unable to extend, was the drop
> tablespace including
> contents
> dead? We tried to alter maxextents on the RBS, but
> did not get a response
> from
> the system. Was that the appropriate reaction to
> this problem.
> 3. A join of v$session and v$sql did not indicate
> any active SQL. How
> should we
> have monitored the progress of what we assume was
> rollback activity? Any
> way
> to estimate how much or how long the rollback would
> take?
> 4. If the database were shutdown during the rollback
> I assume the rollback
> would
> recommence when Oracle came back up. Would it start
> where it left off or
> start
> from scratch. It was my impression that it is
> marking the header blocks
> as it
> goes, but I would like to check.
>
> Thanks,
> Russ Brooks
>
> <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0
> Transitional//EN">
> <HTML><HEAD>
> <META HTTP-EQUIV="Content-Type" CONTENT="text/html;
> charset=iso-8859-1">
>
>
> <META content="MSHTML 5.50.4807.2300"
> name=GENERATOR></HEAD>
> <BODY>
> <DIV>Hi, <BR>This past weekend we experienced a
> problem on a production
> database, and I would like to try to determine what
> went wrong, how to
> avoid it
> in the future, and any better ways of dealing with
> it should it be
> encountered
> again. <BR>After moving some large objects out of
> tablespace to spread
> I/O, we
> wanted to reorganize the old tablespace to remove
> some fragmentation. The
> tool
> we were using, sapdba, does not readily permit you
> to drop the individual
> tables
>
> between the export and the drop tablespace including
> contents. Since the
> tablespace had over 3500 tables the drop tablespace
> was expected to take a
> long
> time. We also defined a large rollback segment for
> use this weekend,
> although
> with only maxextents of 100. When Oracle tried to
> allocate the 101 extent
> in the
>
> RBS, error messages were issued and things came to a
> grinding halt. sar
> indicated disk I/O to the new RBS, but not to any of
> the datafiles. We
> waited
> several hours, but the situation did not appear to
> change. <BR>Shutdown
> immediate did not work. We could alter the datafiles
> back
=== message truncated ===
Stéphane Paquette
DBA Oracle, consultant entrepôt de données
Oracle DBA, datawarehouse consultant
stephane_paquette_at_yahoo.com
Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français !
Yahoo! Mail :
http://fr.mail.yahoo.com
--
Please see the official ORACLE-L FAQ: http://www.orafaq.com
--
Author: =?iso-8859-1?q?paquette=20stephane?=
INET: stephane_paquette_at_yahoo.com
Fat City Network Services -- (858) 538-5051 FAX: (858) 538-5051
San Diego, California -- Public Internet access / Mailing Lists
--------------------------------------------------------------------
To REMOVE yourself from this mailing list, send an E-Mail message
to: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from). You may
also send the HELP command for other information (like subscribing).
--
Please see the official ORACLE-L FAQ: http://www.orafaq.com
--
Author:
INET: Jared.Still_at_radisys.com
Fat City Network Services -- (858) 538-5051 FAX: (858) 538-5051
San Diego, California -- Public Internet access / Mailing Lists
--------------------------------------------------------------------
To REMOVE yourself from this mailing list, send an E-Mail message
to: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from). You may
also send the HELP command for other information (like subscribing).
--
Please see the official ORACLE-L FAQ: http://www.orafaq.com
--
Author: Brooks, Russ
INET: Russ.Brooks_at_dayzim.com
Fat City Network Services -- (858) 538-5051 FAX: (858) 538-5051
San Diego, California -- Public Internet access / Mailing Lists
--------------------------------------------------------------------
To REMOVE yourself from this mailing list, send an E-Mail message
to: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from). You may
also send the HELP command for other information (like subscribing).
Received on Wed Aug 21 2002 - 14:48:47 CDT
