oracle 12.1.0.2 对 bigfile进行resize 遇到enq:TT-contention

来源:互联网 发布:红叶知弦动漫奴役 编辑:程序博客网 时间:2024/05/18 03:14

上周五快下班了,开发那边找到我,说一个resize操作做了40分钟还没执行完,让我看看。

因为该开发所属的系统在exadata上,12c的库,我下意识的觉得,又来bug了。

登上数据库查看,该操作是将一个500g的bigfile文件resize为700g,该会话的等待事件是:enq:TT-contention

该等待事件在以前的版本是跟temporary table有关,在8i版本以后,更多的参与表空间事务管理。

以下是对enq:TT-contention等待事件的详细说明:

该enqueue TT队列锁用以在各种类型的表空间操作执行过程中避免出现死锁dead lock。
该enqueue lock的 ID2表明正在执行的操作种类,ID1表明该操作对应的表空间号V$Tablespace.TS#。
ID1/ ID2的含义
id1是tablespace number V$Tablespace.TS#,ID2表明执行中的操作类型。以下是操作类型对应代码;
0- 用以避免在drop tablespace和创建rollback segment之间发生死锁
1- 用以串行化在给定表空间上创建数据文件
2- 用以避免在TSPITR tablespace point in time recovery期间发生其他类型操作
4- 用以在创建tablespace时锁住该tablespace id
8- 用以避免在ALTER TABLESPACE期间发生死锁
16- 即16进制的0×10,用以同步 分配和回收盘区,allocation and deallocation of extents.
32+ 用在增加数据文件add datafile和创建表空间时,其中ID2为 32(十进制的)+相对文件号relative file number
最常见的TT enqueue争用是 TT-00000x-0000010 即allocation and deallocation of extents.
如果10g以后遇到类似问题 , 建议先了解一下extent management、segment management(ASSM、MSSM?)管理方式等,
是否打开了回收站recyclebin功能,以及该表空间上回收站对象的extent数量。
--------------------------------------------------------------------
在metalink看到了这样一篇文档:
Bug 14055559 - System hang due to TT enqueue contention with BIGFILE tablespace resize (Doc ID 14055559.8)

Affects:

Product (Component)Oracle Server (Rdbms)Range of versions believed to be affected(Not specified)Versions confirmed as being affected
  • 11.2.0.3
  • 11.1.0.7
Platforms affectedGeneric (all / most platforms affected)

Fixed:

The fix for 14055559 is first included in
  • 12.1.0.1 (Base Release)
  • 11.2.0.4 (Server Patch Set)

Interim patches may be available for earlier versions - click here to check.

Symptoms:

Related To:

  • Hang (Process Hang)
  • Waits for "enq: TT - contention"
  • BIGFILE Tablespaces

Description

A system hang can occur due to TT-enqueue contention if a session performsa BIGFILE tablespace resize concurrent with space allocation occuring. Rediscovery Notes User might hit this bug if system hangs due to TT-enqueue contention  and there is concurrent bigfile tablespace resize (shrink) and space allocation. Workaround None 
----------------------------------------------------------------------------------------------
我当前数据库版本是12.1.0.2,版本太相近了,所以我不得不怀疑该bug依然在12.1.0.2上存在。
给出的workaround竟然是none,也是醉了,只好拼人品了,试了几次,resize都卡住了,后来将退出操作系统,重新连接后,再次resize,成功。
激动之情,日月可鉴。




0 0
原创粉丝点击