A reader, May 30, 2002 - 4:37 pm UTC
I have some indexes that have very high initial extents and little data. Is it possible at all to shrink them (I want to give a smaller initial extent size) online/offline? Or the only way is to drop and recreate? I tried the "alter index deallocate unused" without success. Thanks.
May 30, 2002 - 8:20 pm UTC
look up the alter index rebuild ONLINE command (with whatever new storage parameters you want to use)
john, June 28, 2002 - 12:46 pm UTC
tom,
i have job that runs for every 10 minutes that does:
delete from t;
insert into t from select * from t@remotedb;
i think it will be a problem with the high water mark.
there are other reports accessing this table parelly, so i can't issue truncate the table before inserting.
how can i handle this?
June 28, 2002 - 2:01 pm UTC
Do you full scan the table or index read it? Index read it, who cares about a HWM. Full scan it -- then we need to know -- How big is the table?
What is high water mark?
Reddy, June 28, 2002 - 2:18 pm UTC
Dear Tom
So many time i heard about high water mark. But I saw some documenation. But no clear. Actually what is that hiwater mark, why it is calling like that, and how to find it, with this any performace issuses will arise.
Thanks
Reddy
June 28, 2002 - 5:04 pm UTC
You have my book ( you should, you've asked lots of questions ;)
I describe it in there, with pictures and all. Chapter on Tables. Page 199.
Search this site for HWM and you'll find quite a few articles on it as well.
Reducing HWM
B, August 07, 2003 - 3:43 pm UTC
Hi Tom,
In your reply above you have said there are three ways to reduce HWM. Any other additions to the list in 9i.
Regards,
B
August 10, 2003 - 10:55 am UTC
nope not in 9i
A reader, August 13, 2009 - 8:15 am UTC
declare
i number;
begin
i:=0;
loop
insert into t1(name) values('xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx');
commit;
delete from t1;
commit;
i:=i+1;
exit when i=9999999999;
end loop;
commit;
end;
/
Is there any probability that above procedure increase the HWM for t1 beyond control.
August 13, 2009 - 12:32 pm UTC
beyond control - never, nope.
But I only say that because I have no idea what you mean by "beyond control", it (the HWM) will always be under our control and we'll advance it as we see fit.
It is not likely that the resulting space allocated would be very large (assuming it starts empty and assuming that name is a normal column, nothing special, assuming not triggers, assuming lots of things)
updates for 10g/11g
A reader, August 13, 2009 - 8:19 pm UTC
In your reply above you have said there are three ways to reduce HWM. Any other additions to the list in 10g or 11g?
Thanks!
August 24, 2009 - 7:20 am UTC
alter table t shrink space (new in 10g) can do this as well now.
A reader, August 14, 2009 - 1:36 am UTC
Thanks Tom,
What I want to say here is that
If we continuously insert records by using a procedure P1 and another procedure P2 simultaneously process and deletes same records from same table T1.
Both procedure runs for long time say 1 month or 1 year. And during this period maximum records in table(T1) stays always less than 200 (For example suppose
200 was the maximum records in table T1 during this period)
So according to theory of HWM what I read and understand; HWM should be set according to 200 records and not more than that am I right ?
Or it can go higher than that ?
One more thing
When I execute following mentioned PL/SQL procedure It took whole 1 day to finish.
declare
i number;
begin
i:=0;
loop
insert into T1(Name) values('xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx'||i);
commit;
delete from T1;
commit;
i:=i+1;
exit when i=9999999999;
end loop;
commit;
end;
/
Every time it inserts a different value in T1 and also the 'NAME' column of table T1 was primary key (So using Unique Index)
For first couple of hours after analyzing the table DB shows Total 3 BLOCKS uses by the table T1.
But After 8-9 hours analyzing the table it starts showing 13 BLOCK is being used by the table T1.
What can be the reason ?
Is insert statement not re-using the Blocks freed by delete statement and causing HWM to go up ?
August 24, 2009 - 7:27 am UTC
13 blocks - I am hardly even curious about that. 13 blocks is *nothing*
but basically all that means is at some point one session got ahead of the other by a TINY, a teeny tiny bit. The thing doing the delete didn't keep up.
but 13 blocks - that just sort of proves the point here - that space is and will be reused very efficiently over time.