Re: SAP Reorgs

From: Mogens Nørgaard <mln_at_miracleas.dk>
Date: Mon, 14 Jun 2004 22:34:35 +0200
Message-ID: <40CE0BDB.6040700@miracleas.dk>

Hmm. Allow me to say two things:

0. As a director (and shareholder to a large degree) of a database consulting, education and support outfit, I would like to encourage everybody to reorg as often as physically possible. Only extreme situations such as database down or production schedules that can't be ignored any longer should prevent this life-saving activity. With the ability to reorg online both indexes and tables, it can easily, without much ado, become the primary function of the database (and associated disk system, preferably a RAID-5 one). If - and only if - you should experience any inconvenience due to this highly recommended, on-going activity, please call me on my mobile at any time for a reasonable quote on our services.

On a slightly more serious note, the proof that a reorg paid off is that the number of LIO's went down for specific operations like index lookups (that takes a lot of dis-org'ing activity) or table scans. And even that is not good enough: It doesn't matter how many LIO's took place, it's the time they took. Reorg'ing could potentially (I think?) change the LIO's from one kind to another, thereby changing the time they take (Anjo - help me out here if you can, or tell me I'm wrong).
Could some of the reorg benefits seen (if, indeed, they can be measured) by some of the nasty ERP/CRM gorillas be because of the wonderfully long rows in some of the tables combined with block sizes that could be bigger?

Mogens

Please see the official ORACLE-L FAQ: http://www.orafaq.com

To unsubscribe send email to: oracle-l-request_at_freelists.org put 'unsubscribe' in the subject line.
--

Archives are at http://www.freelists.org/archives/oracle-l/ FAQ is at http://www.freelists.org/help/fom-serve/cache/1.html

Received on Mon Jun 14 2004 - 15:37:02 CDT