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 wi
4000
th 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:
Hang (Process Hang) Waits for "enq: TT - contention"	BIGFILE Tablespaces

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，成功。

激动之情，日月可鉴。