Re: Misinformation Ranting

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" <ORACLE-L_at_fatcity.com> 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: 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: Tim Gorman
  INET: Tim_at_SageLogix.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).