【翻译自mos文章】怎么有效的drop 或者truncate 有大量extents的table?

怎么有效的drop 或者truncate 有大量extents的table?

来源于:

How To Efficiently Drop (or Truncate) A Table With Many Extents (文档 ID 68836.1)

目的:

本文描述了为什么一个用户进程在drop 了一个含有大量extents的table之后消耗大量的cpu资源。并给出一个潜在的workaround以阻止该问题的发生。本质来说,CPU被用于对extents的管理(manipulate),比如moving used extents(uet$)到 free extents(fet$).在某种情况中,it may be possible to regulate this CPU activity.

适用范围:

本文协助DBA处理 drop 掉很多extents的表。

相关的文章:

Note:61997.1 SMON - Temporary Segment Cleanup and Free Space Coalescing

永久对象的清理

如果一个永久对象(table)是由 很多extents组成的,并且该object被drop,drop 该object的用户进程将会消耗很多的CPU资源,

这是不可避免的事实(an inescapable fact)。但是,基于一些远见卓识(with some forethought),

可以减轻(mitigate)CPU的使用(and hence the knock-on effect on other users of system resources)

1. Identify, but do NOT drop the table

2.使用 REUSE STORAGE子句来truncate 该表。这样会很快,因为相关的extents不会被释放。高水位线(highwater mark)被简单的调整到segment header block

3. 使用KEEP子句来释放该table中未使用的extents。这是本步骤的关键所在--通过指定table中有多少extent不会被释放,你可以控制有多少extents被释放

举例:

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)

在上面的例子中,table可以分为几个阶段在几个晚上被drop

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:

注意:If the table only needed truncating, no drop statement is needed here.

 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;

相同的方法也适用于LOB segments和index segment

        SQL> ALTER TABLE  MODIFY LOB ()
             DEALLOCATE UNUSED KEEP M;

        SQL> ALTER INDEX  DEALLOCATE UNUSED KEEP M;

警告(caveats):

o.如果你无意之间使用了drop 命令,本方法就不适用了。这是因为,drop table 会首先convert segment到一个临时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 (fixed in 10g and higher)

时间: 2024-11-06 11:26:36

【翻译自mos文章】怎么有效的drop 或者truncate 有大量extents的table?的相关文章

【翻译自mos文章】在alter/drop表空间时遇到错误ORA-38301,ORA-00604,purge dba_recyclebin 也不行

在alter/drop表空间时遇到错误ORA-38301,ORA-00604,purge dba_recyclebin 也不行 适用于: Oracle Database - Enterprise Edition - Version 10.2.0.1 and later Information in this document applies to any platform. 症状: 当你试图drop一个empty的tablespace时,遇到与recyclebin相关的错误 SQL> drop

【翻译自mos文章】asm 归档路径满了

asm 归档路径满了 参考原文: ASM Archive destination is full. (Doc ID 351547.1) 适用于: Oracle Server - Enterprise Edition - Version: 10.1.0.2 to 11.1.0.7 This problem can occur on any platform. 症状: 1)归档路径满了 2)归档文件被存储于asm中. 原因: asm 磁盘组消耗完了空间. 解决方法: 1)在数据库实例中,编辑好如下脚

【翻译自mos文章】运行utlpwdmg.sql之后报ORA-28003, ORA-20001, ORA-20002, ORA-20003, ORA-20004 错误

运行utlpwdmg.sql之后报ORA-28003, ORA-20001, ORA-20002, ORA-20003, ORA-20004 错误. 适用于: Oracle Server - Enterprise Edition - Version 8.1.7.0 and later Information in this document applies to any platform. Checked for relevance on 15-Sep-2012 原因: 运行 utlpwdmg.

【翻译自mos文章】11gR2中的asm后台进程

11gR2中的asm后台进程 参考原文: ASM Background Processes in 11.2 (Doc ID 1641678.1) 适用于: Oracle Database - Enterprise Edition - Version 11.2.0.2 to 11.2.0.4 [Release 11.2] Information in this document applies to any platform. 1 ASMB - ASM Background Process 与as

【翻译自mos文章】 11gR1版本 asmcmd的新命令--cp、md_backup、md_restore

11gR1版本 asmcmd的新命令--cp.md_backup.md_restore 参考原文: ASMCMD - New commands in 11gR1 (Doc ID 451900.1) 适用于: Oracle Database - Enterprise Edition - Version 11.1.0.6 to 11.1.0.7 [Release 11.1] Information in this document applies to any platform. ***Checke

【翻译自mos文章】找到'cursor: pin S wait on X' 等待事件的阻塞者session(即:持有者session)

找到'cursor: pin S wait on X' 等待事件的阻塞者session(即:持有者session) 来源于: How to Determine the Blocking Session for Event: 'cursor: pin S wait on X' (Doc ID 786507.1) 适用于: Oracle Database - Enterprise Edition - Version 10.2.0.1 to 11.2.0.3 [Release 10.2 to 11.2

【翻译自mos文章】SGA_TARGET与SHMMAX的关系

SGA_TARGET与SHMMAX的关系 参考原文: Relationship Between SGA_TARGET and SHMMAX (文档 ID 1527109.1) 适用于: Oracle Database - Enterprise Edition - Version 10.1.0.2 to 11.2.0.3 [Release 10.1 to 11.2] Information in this document applies to any platform. 目的: 解释了参数文件中

【翻译自mos文章】在11gR2 rac环境中,文件系统使用率紧张,并且lsof显示有很多oraagent_oracle.l10 (deleted)

在11gR2 rac环境中,文件系统使用率紧张,并且lsof显示有很多oraagent_oracle.l10 (deleted) 参考原文: High Space Usage and "lsof" Output Shows Many 'oraagent_oracle.l10 (deleted)' in GI environment (Doc ID 1598252.1) 适用于: Oracle Database - Enterprise Edition - Version 11.2.0.

【翻译自mos文章】使用Windows操作系统的Dell Pcserver,Oracle db报错:ORA-8103

翻译自mos文章:使用Windows操作系统的Dell Pcserver,Oracle db报错:ORA-8103 ORA-8103 using Windows platform and DELL servers (Doc ID 1921533.1) Applies to: Oracle Database - Personal Edition - Version 11.1.0.6 to 12.1.0.2 [Release 11.1 to 12.1] Oracle Database - Stand