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" <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> > Sent by: [EMAIL PROTECTED] > 08/20/2002 09:48 PM > Please respond to ORACLE-L > > > To: Multiple recipients of list ORACLE-L > <[EMAIL PROTECTED]> > 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 .... > > > > --- [EMAIL PROTECTED] 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 > > > > > > > > > > > > > > > > [EMAIL PROTECTED] > > Sent by: [EMAIL PROTECTED] > > 08/20/2002 02:43 PM > > Please respond to ORACLE-L > > > > > > To: Multiple recipients of list > ORACLE-L > > <[EMAIL PROTECTED]> > > 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" <[EMAIL PROTECTED]> > > 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 [EMAIL PROTECTED] ___________________________________________________________ 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: [EMAIL PROTECTED] 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: [EMAIL PROTECTED] (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).
