On Jun 25, 6:46*am, Ian <ianb...@mobileaudio.comwrote:
Okonita via DBMonster.com wrote:
Hi all,
I am very surprised to see that after doing a Reorgchk followed by reorg of
selected tables and concluding with a runstats of the reorged tables, all of
the tables continue to be identified and selected as reorg candidates in
subsequent/followup reorgchk.
Has anyone had this experience? Can you share with me what you may havefound
out to the the reason and if possible what are the possible solutions to
correct the situation?
This is very important to us to get this tables to their optimal state and
I'll greatly appreciate a
solution to this issue.
As I suggested before, please post the output from reorgchk -- before
reorg, then after reorg/runstats.
As I explained before, this is very common with indexes. *You may also
see it for tables depending on your physical table design / page size
etc. *But without more information we can't help you.
I have seen this and it is a problem with the way metrics are used
generically without consideration of some aspects of a table. From
memory the the cluster ratio metric doesn't determine if it is a
clustering index. The other good one is using on-line reorg. It
cannot reduce the table to one page so if the table has a few rows it
always appears as a re-org required regardless of how many times you
do an online reorg. On this if the table is less than a few pages you
are better off performing a offline reorg. Then it goes down to one
page. I gave up using the utility and generated my own SQL statement
to determine the re-org list. It can be used as a base but you have
to mask out certain options.
By the way, it doesn't pick up certain situation. It cannot pick up
defragmentation within the tablespace where you have multiple
objects. We discovered a major performance issue in this area (raised
a PMR on version 9) My suggestion is to use the clause to determine
priority items to re-org and then re-org every table/index that
sustains updates regardless.