Home » RDBMS Server » Server Administration » problem with drop/truncate big tables...
problem with drop/truncate big tables... [message #60025] Sat, 10 January 2004 22:35 Go to next message
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 Go to previous messageGo to next message
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 Go to previous messageGo to next message
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 Go to previous messageGo to next message
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 #60074 is a reply to message #60051] Tue, 13 January 2004 09:06 Go to previous messageGo to next message
Julia
Messages: 30
Registered: December 1999
Member
Thanks for your replys. They help me a big time.

rgds - julia
Re: problem with drop/truncate big tables... [message #60078 is a reply to message #60051] Tue, 13 January 2004 22:49 Go to previous messageGo to next message
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 Go to previous messageGo to next message
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
Re: problem with drop/truncate big tables... [message #60097 is a reply to message #60086] Thu, 15 January 2004 09:27 Go to previous message
Julia
Messages: 30
Registered: December 1999
Member
Thiru, Thanks you very much for your help.

Regards,
Julia
Previous Topic: Patchset information
Next Topic: Lob Storage Allocation
Goto Forum:
  


Current Time: Fri Sep 20 10:37:35 CDT 2024