Oracle FAQ Your Portal to the Oracle Knowledge Grid

Home -> Community -> Mailing Lists -> Oracle-L -> Re: SAP Reorgs

Re: SAP Reorgs

From: Richard Foote <>
Date: Mon, 14 Jun 2004 18:49:05 +1000
Message-ID: <02c601c451ec$7325b800$0100000a@FOOTE>

Hi Mike,

You say that you re-org regularly. My specific question to you is why ? What specific *performance* issue does a regular re-org specifically address (I accept the fact that you choose to archive data and save disk but what are your *performance* implications).

There has been much nonsense written regarding the requirement to regularly re-org an Oracle database and when one actually looks under the covers to determine the justification for such re-orgs, such justifications rarely stand up to scrutiny.

Rather than your generalist claim that you see a "palpable return", can you please provide a specific example of what your re-orgs achieve. For example, what is a performance issue that you are addressing (say performance issue
"A"). What is the current metric that is unacceptable (say response time
"B"). What's the reason for this performance issue (say root cause "C").
How/why does the re-org fix this specific root cause (say explanation for remedy "D"). What is the now acceptable metric (say improved response time

Like I said, how "specifically" does the re-org help a specific *performance* issue.

Without "A", "B", "C", "D", "E", I remain sceptical of any such claims ...




I am surprised at the responses you are receiving about doing Reorgs. Everyone seems to think it's dumb and unnecessary.

We use SAP here at Guidant. It's our 900-lb gorilla application. As goes SAP, so goes most if not all of the other systems and databases.

We reorg regularly. We see a palpable return on several levels from performing this activity. We archive data on a active schedule, and reorging the tables/tablespaces that have just been archived brings down the tablespace size, rebuilds the indexes for improved performance, and allows us better management of our disk space.

It is for performance and savings that we reorg. We do not need to buy as much disk every year, and the performance remains acceptable to the users. I know...everybody says disk is cheap; try telling my manglement when we submit a purchase req for more EMC disk. Cheap? Not from our budget!

With that off my chest, we use Quest Live Reorg to perform our reorgs. Basically, LR does a CTAS, and then mines the redo logs to keep the current table and the reorged table in sync until 'cutover', which is when the new table becomes the main table and the former main table becomes baggage. We cutover late on Saturday night, when we can safely take SAP down without impacting too many users - Quest claims to the contrary, SAP does notice (and complains bitterly) when the cutover happens if you try it with SAP up. But cutover only takes minutes, and we've not yet (hear the sound of me knocking on wood, crossing myself, and lighting a candle) had an issue with the cutover that was not recoverable.

Please see the official ORACLE-L FAQ:

To unsubscribe send email to: put 'unsubscribe' in the subject line.
Archives are at
FAQ is at
Received on Mon Jun 14 2004 - 03:40:27 CDT

Original text of this message