I had one experience with an ERP, since then I'm
avoiding those contract.
Developping a system is so much more interesting in my
point of view.
Unfortunately there is more and more ERP sold :-(
- "Brooks, Russ" <Russ.Brooks_at_dayzim.com> a écrit :
> 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
>
=== 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).
Received on Wed Aug 21 2002 - 21:38:24 CDT