Chinaunix首页 | 论坛 | 博客
  • 博客访问: 1169206
  • 博文数量: 178
  • 博客积分: 2776
  • 博客等级: 少校
  • 技术积分: 2809
  • 用 户 组: 普通用户
  • 注册时间: 2012-03-22 15:36
文章分类

全部博文(178)

文章存档

2014年(3)

2013年(66)

2012年(109)

分类: Oracle

2012-11-26 09:31:48

  对于永久表空间上的temporary segment,SMON会三分钟清理一次(前提是接到post),如果SMON过于繁忙那么可能temporary segment长期不被清理。temporary segment长期不被清理可能造成一个典型的问题是:在rebuild index online失败后,后续执行的rebuild index命令要求之前产生的temporary segment已被cleanup,如果cleanup没有完成那么就需要一直等下去。在10gR2中我们可以使用dbms_repair.online_index_clean来手动清理online index rebuild的遗留问题:
  The dbms_repair.online_index_clean function has been created to cleanup online index rebuilds.
  Use the dbms_repair.online_index_clean function to resolve the issue.
  Please note if you are unable to run the dbms_repair.online_index_clean function it is due to the fact
  that you have not installed the patch for Bug 3805539 or are not running on a release that includes this fix.
  The fix for this bug is a new function in the dbms_repair package called dbms_repair.online_index_clean,
  which has been created to cleanup online index [[sub]partition] [re]builds.
  
  New functionality is not allowed in patchsets;
  therefore, this is not available in a patchset but is available in 10gR2.
  
  Check your patch list to verify the database is patched for Bug 3805539
  using the following command and patch for the bug if it is not listed:
  
  opatch lsinventory -detail
  
  Cleanup after a failed online index [re]build can be slow to occurpreventing subsequent such operations
  until the cleanup has occured.
  
  接着我们通过实践来看一下smon是如何清理永久表空间上的temporary segment的:
  设置10500事件以跟踪smon进程,这个诊断事件后面会介绍
  
  SQL> alter system set events '10500 trace name context forever,level 10';
  System altered.
  
  在第一个会话中执行create table命令,这将产生一定量的Temorary Extents
  
  SQL> create table smon as select * from ymon;
  
  在另一个会话中执行对DBA_EXTENTS视图的查询,可以发现产生了多少临时区间
  
  SQL> SELECT COUNT(*) FROM DBA_EXTENTS WHERE SEGMENT_TYPE='TEMPORARY';
  
  COUNT(*)
  ----------
  117
  
  终止以上create table的session,等待一段时间后观察smon后台进程的trc可以发现以下信息:
  
  *** 2011-06-07 21:18:39.817
  SMON: system monitor process posted msgflag:0x0200 (-/-/-/-/TMPSDROP/-/-)
  
  *** 2011-06-07 21:18:39.818
  SMON: Posted, but not for trans recovery, so skip it.
  
  *** 2011-06-07 21:18:39.818
  SMON: clean up temp segments in slave
  
  SQL> SELECT COUNT(*) FROM DBA_EXTENTS WHERE SEGMENT_TYPE='TEMPORARY';
  
  COUNT(*)
  ----------
  0
  
  可以看到smon通过slave进程完成了对temporary segment的清理
  
  与永久表空间上的临时段不同,出于性能的考虑临时表空间上的Extents并不在操作(operations)完成后立即被释放和归还。相反,这些Temporary Extents会被标记为可用,以便用于下一次的排序操作。SMON仍会清理这些Temporary segments,但这种清理仅发生在实例启动时(instance startup):
  For performance issues, extents in TEMPORARY tablespaces are not released ordeallocated
  once the operation is complete.Instead, the extent is simply marked as available for the next sort operation.
  SMON cleans up the segments at startup.
  
  A sort segment is created by the first statement that used a TEMPORARY tablespacefor sorting, after startup.
  A sort segment created in a TEMPOARY tablespace is only released at shutdown.
  The large number of EXTENTS is caused when the STORAGE clause has been incorrectly calculated.ocm培训http://www.cuug.com/
阅读(1882) | 评论(0) | 转发(0) |
给主人留下些什么吧!~~