Printable View
Hey Guys,
I created Script that will rebuild indexes per schema. I wanted to post for others to enjoy.
BEGIN
FOR INDEx_RECORD IN (select 'SCHEMA_NAME.'||object_name as obj
from dba_objects
where object_type = 'INDEX' and
owner ='SCHEMA_NAME'
) LOOP
execute immediate 'ALTER INDEX '||INDEx_RECORD.obj||' REBUILD';
END LOOP; -- implicit CLOSE occurs
END;
Thank you very much, I'm sure somebody will really enjoy it.
so...
... why are you rebuilding all indexes on the schema? any special reason?
... since you are not doing rebuild online you are going to certainly affect business.
... how about partitioned indexes?
... how about statistics?
... have a couple more but I'll wait until you get these solved ;)
what a dangerous script to post - i hope you feel ashamedQuote:
Originally Posted by hozay
I have an application that likes to delete 36 million rows out of the database per week. It's not a well written app. I really did not want to resort to rebuilding indexes but i seem to have no choice. We are not up 24 x 7. This is done with no users on. So yes please be careful. If you have any better ideas I'm certainly open to hear them.
Thanks
Hoz
36 million rows deleted a week doesn't sound like whole bunch of them, either you are talking about a very small database or you are just panicking.Quote:
Originally Posted by hozay
So... why are you doing it?Quote:
Originally Posted by hozay
Do not give the same medicine -specially when you are using a dangerous one- to all your patients; give it only to the ones that need it.Quote:
Originally Posted by hozay
looks like you (Hoz) got into wrong site? lemme make a guess, this basic knowledge of rebuild indexes coming from Don B?
I keep on thinking, what a hot topic this is... rebuild index?.. or it looks like so.. lol
btw, i love to see one liners of davey.. wow..
There are many queries that go from running in 15mins to 6 hours after about 10 days. The queries are all based on joining of many views. Each of those views many up of many extremely wide tables.
I took a close look at one particular query. First, I tried to make sure I had updated statistics. No affect. Next, I rebuilt the indexes for that query. It returned to a 15min query.
I rebuilt indexes once a week for 3 weeks. The query ran consistently in 15 min. Then I rebuilt indexes for the entire schema. All queries run consistently in 15min.
There is nothing I can do about the SQL. I've been told it cannot be changed.
Database is size 150gb.
Hoz
Do you still have the trace? Could you please post Wait Events section of it?Quote:
Originally Posted by hozay
Are you partitioning your tables? If you are deleting by date partitioning by date would make it easier to drop a partition rather than delete. even though you are being told that the sql can not change, if you can show a bad query, and how to fix the query so that it runs consistently fast without rebuilding the indexes, then you might convince the right people to allow the change.
I don't have a trace file I can post. The wait event was a db sequential read.
Quote:
Originally Posted by gandolf989
This is a purchased application that does not support table partitioning.
If you paid for this then you should have support. And the vendor should spend some time on performance.Quote:
Originally Posted by hozay
For tables that get a lot of inserts and deletes you might consider not generating stats on those tables, and not rebuilding any indexes. No stats are usually better than bad stats.
Great suggestion! Did not even think of that. I will give that a try.
i still wonder how the heck can rebuild help in query completing faster than without?.. Ofcourse stats after rebuild of index is favoring some path (which looks to be better plan).. and then after some time if you collect stats, its not getting you that plan and instead a worse plan, if thats the case then you should start thinking, are you collecting stats properly?
Specially true when your data follows normal distribution which is what Oracle assumes when no stats are available.Quote:
Originally Posted by gandolf989
Here is a scenario, assume that...Quote:
Originally Posted by abhaysk
a) You have a large table where heavy random delete happens.
b) You have a composite index where a sequence or a date is the first column of the index.
c) Your queries have faulty predicates where WHERE clause is using an incomplete set of the columns of your composite index.
As a result of this scenario, over time you are going to find that...
1) Because of items (A) and (B) your index is getting less and less dense e.g. less and less active keys per block as time goes on.
2) Because of item (C) your queries are forced to do range scan on the index e.g. scanning more and more blocks as time goes on.
In this scenario your queries are going to slow down performance over time, just a bit worst every single day.
When you rebuild your offending index guess what? index gets more dense e.g. more active keys per block then... index range scans are shorther and voila!... queries run faster.
PS: Please don't come back with the leaf-blocks are always in balance theory; because of (B) followed by (A) this is not true for this specific index.
I always use exception of sequence/date + heavy random deletes (leading to suboptimal usage of blocks), but somehow missed to highlight that exception in the message..
I would rather use coalesce only on such indexes (sequence or date columns being first key)
One more thing @PAVB, if orignal poster's appl deletes 36 million records per week (though not practical) then i would guess/expect it would leave many free blocks for re-use. I suspect if oracle is using blocks efficiently in his case, either due to wrong settings in his environment or oracle is genuinely failing to re-use blocks or he is using IOT. IMHO IOT not re-using index blocks though we do delete range of sequence numbers (first key of IOT) which are older than some date.
This whole thing was discussed a couple of days ago... please research.
Index blocks are re-used ONLY in they get empty, if you have a single active key sitting in the middle of the block and you are inserting keys that do not belong to the block, block is not reused.
I know that.. PAVB, i remember pando and myself making a point of block being re-used if all keys are deleted (wrt sequence/date).. unlike a set/range of blocks.. (i hope you remember).
so... if you know it, why you don't understand it? LMAO
when did i say that for a index with sequence/date as first key, if any block has even a single entry, then its candidate for re-use.. can you point where and when did i mention this?
If you want to pick up some argument unnessarily (or for the heck of it), then i dont have issues.. i will just ignore your message..