Jared, I recently started a job that uses SAP on Oracle 8.1.7 and the only word that describes my day is "frustration". Are there any SAP do's and don'ts you can recommend? >From my brief experience, I should use SAPDBA to add tablespaces or check stats. Other than that I use sqlplus/scripts for everything else. When the system does have performance problems, it's really tough to isolate the problem because there's 400 users sharing 100+ connections and they're all SAPR3. the other irritating problem is on the BW system, tables get dropped and recreated in the wrong tablespace. I know there has to be screen (or table) that maps objects to tablespaces, but haven't found it. Any tips you have would be appreciated.
Thanks, Steve ----- Original Message ----- To: "Multiple recipients of list ORACLE-L" <[EMAIL PROTECTED]> Sent: Tuesday, September 10, 2002 3:28 PM > <RANT> > > I've just spent 30 minutes with our SAP administrator trying to > convince her that we really don't need to reorganize the tables > in our production SAP database. > > Due to some misinformation in an Oracle Press book, 'Oracle Unleashed' > I think, she is equating number of extents with fragmentation. > > The text she referred me to is in fact discussing 'migrated rows' though > that term is never used. She has become convinced that if the > extents allocated for tables are not all in contigous space, some > very nasty fragmentation will occur. > > I tried taking it down to disk and explaining that an OLTP system with > hundreds of users won't really see much benefit from this, but she > wasn't really ready for that. :) > > Her concern is that there are 29000 extents in an index tablespace. > This might have something to do with there being 3400 indexes in > said tablespace. > > Total 'wasted' ( honeycomb ) space in this 250 gig DB is < 20 meg. Not > much to gain there. > > The text of the book states that you should expect a '10 to 20 percent > performance increase' by reorganizing the tables/indexes. No data to > back it up of course. > > This is on a database that performs very well most of the time, outside > of a couple of custom reports that run too long. No complaints from > users about slowness. > > Arrghhh! > > I just had to vent to the list, cuz there's no one here that understands. > > <\RANT> > > Jared > > -- > Please see the official ORACLE-L FAQ: http://www.orafaq.com > -- > Author: > 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). -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: Steve Perry 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).
