| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
 |
 | |||
| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
|
| |||
Home -> Community -> Mailing Lists -> Oracle-L -> Re: SAP Reorgs
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
"E").
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 ...
Cheers
Richard
Dan:
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.
-- 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 - 03:40:27 CDT
 |
 |