Bad as your experience is, be grateful you weren't confronted with this beauty in the one-world of JD Edwards:
>> At XXXXXXXX they're having wonderful problems. But what >> really started this is a detail from their recommendations that you >> missed last year: in there they suggest that you count the number >> of disk drives in your system and multiply by the rpm count. The >> result should then be used to set "_spin_count". So if you have 5 >> disks and they do 10000 rpm (each :) ), then "_spin_count" should >> be set to 50000 The mind reels... ...after all, what else could a parameter named "_spin_count" possibly represent? :-) As for me, I'm seeking out JD Edwards databases to tune...(yee haw!)...there's gotta be gold in them thar hills! ----- Original Message ----- To: "Multiple recipients of list ORACLE-L" <[EMAIL PROTECTED]> Sent: Tuesday, September 10, 2002 2: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: Tim Gorman 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).
