oracle 12.1.0.2 bigfileに対するresize遭遇enq:TT-contention
3103 ワード
先週の金曜日はもうすぐ退勤します.開発側は私を見つけて、resize操作が40分も行われていないと言って、私に見せてください.
この開発が属するシステムがexadataにあるので、12 cのライブラリは、私は無意識に、またバグが来たような気がします.
データベースにログインして、500 gのbigfileファイルresizeを700 gにします.このセッションの待機イベントはenq:TT-contentionです.
この待機イベントは、以前のバージョンではtemporary tableに関連しており、8 iバージョン以降は表領域トランザクション管理に参加することが多い.
enq:TT-contention待機イベントの詳細は、次のとおりです.
このenqueue TTキューロックは、様々なタイプの表領域操作の実行中にデッドロックdead lockが発生しないようにするために使用される.
このenqueue lockのID 2は実行中の操作の種類を示し、ID 1はその操作に対応する表空間番号V$Tablespaceを示す.TS#.
ID 1/ID 2の意味
id 1はtablespace number V$Tablespaceである.TS#,ID 2は、実行中の操作タイプを示します.以下は操作タイプ対応コードです.
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を追加し、表領域を作成するときに使用します.ID 2は32(10進数)+相対ファイル番号relative file numberです.
最も一般的なTT enqueue競合はTT-00000 x-000010すなわちallocation and deallocation of extentsである.
10 g以降に類似の問題が発生した場合は、まず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)
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)
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.
Hang (Process Hang) Waits for "enq: TT - contention" BIGFILE Tablespaces
----------------------------------------------------------------------------------------------
私の現在のデータベースバージョンは12.1.0.2で、バージョンが近すぎるので、このバグが12.1.0.2に存在するのではないかと疑わざるを得ません.
与えられたworkaroundはnoneで、酔っ払っていたので、人柄をつづるしかなかった.何度もやってみたが、resizeは引っかかっていた.その後、オペレーティングシステムを脱退し、再接続した後、再びresizeし、成功した.
興奮の情は,日月が鑑みることができる.
この開発が属するシステムがexadataにあるので、12 cのライブラリは、私は無意識に、またバグが来たような気がします.
データベースにログインして、500 gのbigfileファイルresizeを700 gにします.このセッションの待機イベントはenq:TT-contentionです.
この待機イベントは、以前のバージョンではtemporary tableに関連しており、8 iバージョン以降は表領域トランザクション管理に参加することが多い.
enq:TT-contention待機イベントの詳細は、次のとおりです.
このenqueue TTキューロックは、様々なタイプの表領域操作の実行中にデッドロックdead lockが発生しないようにするために使用される.
このenqueue lockのID 2は実行中の操作の種類を示し、ID 1はその操作に対応する表空間番号V$Tablespaceを示す.TS#.
ID 1/ID 2の意味
id 1はtablespace number V$Tablespaceである.TS#,ID 2は、実行中の操作タイプを示します.以下は操作タイプ対応コードです.
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を追加し、表領域を作成するときに使用します.ID 2は32(10進数)+相対ファイル番号relative file numberです.
最も一般的なTT enqueue競合はTT-00000 x-000010すなわちallocation and deallocation of extentsである.
10 g以降に類似の問題が発生した場合は、まず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
Platforms affected
Generic (all/most platforms affected)
Fixed:
The fix for 14055559 is first included in
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で、バージョンが近すぎるので、このバグが12.1.0.2に存在するのではないかと疑わざるを得ません.
与えられたworkaroundはnoneで、酔っ払っていたので、人柄をつづるしかなかった.何度もやってみたが、resizeは引っかかっていた.その後、オペレーティングシステムを脱退し、再接続した後、再びresizeし、成功した.
興奮の情は,日月が鑑みることができる.