problem with drop/truncate big tables... [message #60025] |
Sat, 10 January 2004 22:35 |
Julia
Messages: 30 Registered: December 1999
|
Member |
|
|
I'm running 8.1.6.0.0 on Saloris.
Once a while I need to drop/truncate tables (all regular tables) with around 50 mil rows. It always takes a couple of hours to several hours to have those table dropped/truncated. Somatimes the truncate even failed with ora-600. Further more, even the table(s) got dropped successfully, smon can't digest the big 'drop', ie can't release the space (usually around 10~15GB) and hangs...so I have to restore the database with cold backup and allocated more space/storge to the database. My questions are:
1) is it normal that dorpping a table this size takes a few hrs?
2) is there any better way to get ride of big tables and release the unused space?
3) I sort of heard that it's a known bug that smon hangs when a big table dropped. is there any patch can solve this problem.
It's kind of urgent. any thought will be greatly appeciated.
thx. julia
|
|
|
Re: problem with drop/truncate big tables... [message #60027 is a reply to message #60025] |
Sun, 11 January 2004 03:29 |
Thiru
Messages: 1089 Registered: May 2002
|
Senior Member |
|
|
Hi,
if you are using dictionary managed tablespaces and the table contains thousands of extents,then it could take a while to drop the segments as the data dictionary(sys.UET$ and sys.FET$ tables) need to be updated(hence update rollback segments) via recursive sql.
Did you say truncate also hangs for hours ? theoreticall y it should be faster than a drop becos ,it just needs to adjust the Highwater mark of the table back to 1st extent. Truncate followed by Drop is what is recommended for dropping big tables with tons of extents. You could check v$session_event and v$session_wait for that session, to find out whats its waiting for. Its likely that SMON is holding the ST(space transaction) lock on the uet$ and fet$ tables.
The permanent remedy is to move to locally managed tablespaces where the recursive sql to lookup datadictionary is skipped.
-Thiru
|
|
|
Re: problem with drop/truncate big tables... [message #60050 is a reply to message #60027] |
Mon, 12 January 2004 08:19 |
Julia
Messages: 30 Registered: December 1999
|
Member |
|
|
Thanks for your professional expertise. It's exactly as you point out. The tablesapce is dictionary managed. And Yes, it took a few hrs for truncate as well (actually the truncate even failed with ORA-600 and something else). And also I think the slow of truncate is also because the lock on uet$/fet$ as well, but why is that? shall I give the truncate a try again in hopes that SMON won't holding the lock this time? or seems like the only way left for me is reorg the database complietely by wipe it out and import eveything since this database indeed need something like this anyway for instance I have 5+GB free space shows in dba_free_space for one of my data tablespace but the biggest chunk is only 7m.
Thanks again,
Julia
|
|
|
Re: problem with drop/truncate big tables... [message #60051 is a reply to message #60050] |
Mon, 12 January 2004 09:48 |
Thiru
Messages: 1089 Registered: May 2002
|
Senior Member |
|
|
If you ask me,go for the reorg,if you can afford the downtime or Create new Locally Managed tablespaces and move the objects from the dictionary managed tablespace,if you have space. You could then drop the old DMTs.
You'll have to migrate to LMTs anyway sooner or later,is'nt it ?
You could try TRUNCATE REUSE STORAGE , to speedup the truncate meanwhile as it avoids deallocating extents. ST enqueue is serialised and when there are tons of extents,each update to uet$ & fet$ cluster has to wait causing a huge delay. Also make sure you dont have any locks on this table when attempting the truncate.
Ora-600 during truncate could be due to Oracle bugs.
HTH
Thiru
|
|
|
|
Re: problem with drop/truncate big tables... [message #60078 is a reply to message #60051] |
Tue, 13 January 2004 22:49 |
Julia
Messages: 30 Registered: December 1999
|
Member |
|
|
I'm having a new problem when I'm simulating the complete reorg on a dev server. The problem is I created local managed data/index tablespaces from scratch. But weird problem happened when I import the dmp from the production: about 20GB tablespace was ate up immediately with few small tables. I guess this is because the tables/indexes from my production have initial/next/min/max extents definition in the storage clause and those screwed the the storage management of the LM tablespaces. If there any work-around or if something i'm missing here? I know I don;t have problem of create LM tablespace since we have multiple 9i instances are using LM tablespace. this is 8.1.6 though.
Any help will be greatly appreciated.
Julia
|
|
|
Re: problem with drop/truncate big tables... [message #60086 is a reply to message #60078] |
Thu, 15 January 2004 03:19 |
Thiru
Messages: 1089 Registered: May 2002
|
Senior Member |
|
|
Julia,
was wondering if you exported the tables with COMPRESS=Y.Did those tables have minextents set ? If yes,the size of the INITIAL_EXTENT of those segments in the Locally Managed tablespace will be the sum of those minimum number of extents. Also what type of Locally Managed tablespaces(SYSTEM or UNIFORM allocation) did you create ?
In case of System managed LMT,the system calculates the size of the NEXT_EXTENT based on size of the table, whereas in case of UNIFORM allocation,the size of the extents do not get affected(although the INITIAL_EXTENT shows as the sum of the minimum extents of the table created).
For eg)
-- Lets consider this Locally Managed tablespace with UNIFORM extent sizes(INITIAL=NEXT=64k)
thiru@9.2.0:SQL>select * from dba_Tablespaces where tablespace_name='LOCAL_UNIFORM';
TABLESPACE_NAME BLOCK_SIZE INITIAL_EXTENT NEXT_EXTENT MIN_EXTENTS MAX_EXTENTS PCT_INCREASE MIN_EXTLEN S
-------------------- ---------- -------------- ----------- ----------- ----------- ------------ ---------- -
LOGGING FOR EXTENT_MAN ALLOCATIO PLU SEGMEN
--------- --- ---------- --------- --- ------
LOCAL_UNIFORM 4096 65536 65536 1 2147483645 0 65536 O
LOGGING NO LOCAL UNIFORM NO MANUAL
thiru@9.2.0:SQL>drop table t2;
Table dropped.
thiru@9.2.0:SQL>create table t2 (x int) storage(initial 1m next 1m minextents 5) tablespace local_uniform;
create table t2 (x int) storage(initial 1m next 1m minextents 5) tablespace local_uniform
*
ERROR at line 1:
ORA-01542: tablespace 'LOCAL_UNIFORM' is offline, cannot allocate space in it
thiru@9.2.0:SQL>alter tablespace local_uniform online;
Tablespace altered.
-- Lets create a table specifying (similar to the import) the initial,next,minextents in this tablespace
thiru@9.2.0:SQL>create table t2 (x int) storage(initial 1m next 1m minextents 5) tablespace local_uniform;
Table created.
thiru@9.2.0:SQL>select * from user_Segments where segment_name='T2';
SEGMENT_NAME PARTITION_NAME SEGMENT_TYPE TABLESPACE_NAME B
------------------------------ ------------------------------ ------------------ -------------------- ------
EXTENTS INITIAL_EXTENT NEXT_EXTENT MIN_EXTENTS MAX_EXTENTS PCT_INCREASE FREELISTS FREELIST_GROUPS BUFFER
---------- -------------- ----------- ----------- ----------- ------------ ---------- --------------- ------
T2 TABLE LOCAL_UNIFORM 524
80 5242880 65536 1 2147483645 0 1 1 DEFAUL
-- As seen above,the size of the INITIAL_EXTENT is shown as the sum of the minextents(5*1M) of the table created. The NEXT_EXTENT is 64k however.
-- But look at the number of extents. It is 80 , not 5,which tells us that we have 80 * 64k extents allocated and not 5*1m extents ( ie as per the tablespace definition and not per the table specification).
thiru@9.2.0:SQL>select 65536*80 from dual;
65536*80
----------
5242880
-- and this (ie 5M) is the size of the table.
thiru@9.2.0:SQL>analyze table t2 compute statistics;
Table analyzed.
thiru@9.2.0:SQL>select initial_Extent,next_Extent,blocks from user_Tables where table_name='T2';
INITIAL_EXTENT NEXT_EXTENT BLOCKS
-------------- ----------- ----------
5242880 65536 0
thiru@9.2.0:SQL>
So when you know the size of the tables upfront,its always better to create UNIFORM sized extents ,rather than SYSTEM managed.
You could also try moving the tables using
alter table T move tablespace LOCAL_UNIFORM;
and rebuild the indexes, instead of exp/imp.
-Thiru
|
|
|
|