oracle 12.1.0.2 对 bigfile进行resize 遇到enq:TT-contention
上周五快下班了，开发那边找到我，说一个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 affected Generic (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: |
|
|
Description
----------------------------------------------------------------------------------------------A system hang can occur due to TT-enqueue contention if a session performs a 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，成功。
激动之情，日月可鉴。