drop 一張3.7T的含lob的分區表
今天drop 了一張3.7T的表,這張表爲分區本身的數據只有23G,兩個lob字段和lob index加起來佔到3.7T,下面處理過程:
1.因爲表特別大,開始嘗試用以下方式來做:
drop index ...;
truncate table ... reuse storage;
alter table ... deallocate unused keep 2000000m;
alter table ... deallocate unused keep 1500000m;
alter table ... deallocate unused keep 1000000m;
alter table ... deallocate unused keep 500000m;
alter table ... deallocate unused keep 0;
drop table ...;
結果做完truncate table ... reuse storage;之後做alter table ... deallocate unused keep 2000000m;時一直報
alter table EAI_CT_BUILD.EA_CROSS_SYS_DATA_TBL_BAK deallocate unused keep 10000M
*
ERROR at line 1:
ORA-03230: segment only contains 77 blocks of unused space above high water
mark
問了一下oracle,推薦我用下以下方法來做:
1.先truncate所有的subpartition:
truncate table EAI_CT_BUILD.EA_CROSS_SYS_DATA_TBL_BAK subpartition **;......
2.truncate所有的partition
truncate table EAI_CT_BUILD.EA_CROSS_SYS_DATA_TBL_BAK partition **;......
3.drop table EAI_CT_BUILD.EA_CROSS_SYS_DATA_TBL_BAK ;
大概在truncate subpartition時花了25分鐘,之後的就快了,drop table時只發了1分29秒.
附:
How To Efficiently Drop A Table With Many Extents | ||||
Doc ID: | Note:68836.1 | Type: | BULLETIN | |
Last Revision Date: | 12-JUN-2008 | Status: | PUBLISHED |
How to efficiently drop a table with many extents PURPOSE ~~~~~~~ This note describes why a user process can consume large amounts of CPU after dropping a table consisting of many extents, and a potential workaround to stop the problem occurring. Essentially the CPU is being used to manipulate the extents i.e. moving used extents (uet$) to free extents (fet$). In certain circumstances it may be possible to regulate this CPU activity. SCOPE & APPLICATION ~~~~~~~~~~~~~~~~~~~ This article is intended to assist DBAs who may need to drop a table consisting of many extents. RELATED DOCUMENTS ~~~~~~~~~~~~~~~~~Note 61997.1SMON - Temporary Segment Cleanup and Free Space Coalescing Permanent object cleanup ~~~~~~~~~~~~~~~~~~~~~~~~ If a permanent object (table) is made up of many extents, and the object is to be dropped, the user process dropping the object will consume large amounts of CPU - this is an inescapable fact. However, with some forethought it is possible to mitigate the effects of CPU usage (and hence the knock-on effect on other users of system resources) thus: 1. Identify, but do NOT drop the table 2. Truncate the table, specifying the REUSE STORAGE clause. This will be quick as extents are not deallocated; the highwater mark is simply adjusted to the segment header block. 3. Deallocate unused extents from the table, SPECIFYING THE KEEP CLAUSE. This is the crux - you can control how many extents are to be deallocated by specifying how much (in terms of Kb or Mb) of the table is NOT to be deallocated. Example: o. Table BIGTAB is 2Gb in size and consists of 262144 8Kb extents o. There is little CPU power available, and (from past experience) it is known that dropping an object of this number of extents can take days o. The system is quiet at night times (no other users or batch jobs) In the above example the table could be dropped in 'phases' over the period of a few nights as follows: 1. Truncate the table, specifying the REUSE STORAGE clause: SQL> TRUNCATE TABLE BIGTAB REUSE STORAGE; 2. If it takes 3 days (72 hours) to drop the table, spread this out over 6 nights i.e. drop 1/3 Gb per night. This can be achieved in 6 (nightly) steps as follows: Night 1: SQL> ALTER TABLE BIGTAB DEALLOCATE UNUSED KEEP 1707M; (2Gb*5/6) Night 2: SQL> ALTER TABLE BIGTAB DEALLOCATE UNUSED KEEP 1365M; (2Gb*4/6) Night 3: SQL> ALTER TABLE BIGTAB DEALLOCATE UNUSED KEEP 1024M; (2Gb*3/6) Night 4: SQL> ALTER TABLE BIGTAB DEALLOCATE UNUSED KEEP 683M; (2Gb*2/6) Night 5: SQL> ALTER TABLE BIGTAB DEALLOCATE UNUSED KEEP 341M; (2Gb*1/6) Night 6: SQL> DROP TABLE BIGTAB; The same method can be applied if LOB segments or indexes are involved. SQL> ALTER TABLE <table_name> MODIFY LOB (<lob_column>) DEALLOCATE UNUSED KEEP <value>M; SQL> ALTER INDEX <index_name> DEALLOCATE UNUSED KEEP <value>M; Caveats ~~~~~~~ o. If you have inadvertently tried to drop the table, this method will not work. This is because the drop will first convert the segment to a temporary segment, and only then start cleaning up the now temporary segment's extents. Thus, if the drop is interrupted, the temporary segment will now be cleaned up by SMON. o. This method will only work for table, lob and index segment types. o. This method will not work for segments bigger than 4gb in size due to unpublished bug: 1190939 <ORA-3277 WHEN ISSUING AN ALTER TABLE DEALLOCATE UNUSED > 4G ------------------------------------------------------------------------------- Oracle Support Services