遅延カーソルインバリデーション

以前、トランケートについて知っておくべきことで述べたように、DDLは（data_object_idの変更とともに）関連するオブジェクトの共有カーソルを即時に無効化していた。しかし、実はOracle12cR2からは、可能なものは無効化を回避し、避けられないものはローリング無効化を行うことができるようになっている。このあたりの挙動は実は設計や運用上、きわめて影響の大きい内容の割には、あまり詳しく説明したドキュメントがパブリックになっていないような気がする。津島博士によるドキュメントは参考になるが、トランケートの際の挙動が記載されていない。そこで、実際に自分で確かめてみようと考えた。

トランケートの場合、以下のようにdeferred invalidationオプションをつけることにより、共有カーソルの無効化を（可能な限り）回避することができる。

例） alter table scott.sales truncate partition sales_q1_2006 update global indexes deferred invalidation;

実際に検証してみた結果、deferred invalidationオプションにより、以下のような効果があることがわかった。

・フルテーブルスキャン、またはローカルインデックスによるレンジスキャンではカーソルの無効化を回避できる
・グローバル索引によるレンジスキャンではカーソルは即時無効化される

※詳細なログは以下参照：
https://community.oracle.com/people/Kazuhiro/blog/2019/05/31/partition-truncate-with-deferred-invalidation?customTheme=mosc

パーティション表による過去パーティションメンテナンスによりトランケートやドロップ運用を行うことは多いと思うが、このオプションによりグローバル索引を使用していなければカーソルの無効化、ひいてはハードパースを避けられるということで、こんなすばらしい機能改善はないと思う。個人的には華々しく宣伝しているオプティマイザの適応なんとか最適化とかより、ずっと広く世の中のDBAの幸せに貢献する機能であるように思う。

なお、オプションをつけない場合の挙動はCURSOR_INVALIDATION初期化パラメータに依存するが、デフォルトは12.2も19cもIMMEDIATEである。これはDEFERREDになる日が来れば、このオプションをもはや気にする必要はないだろう。（参考：Oracle Database Reference Manual 19c, CURSOR_INVALIDATION)

ただ、実際に商用で使った経験がないため、副作用についての留意は必要だと思っている。以下でコミュニティに問い合わせをしてみてはいるので、そのうちワールドワイドでなんらかの知見が得られることを期待したい。

https://community.oracle.com/thread/4281580

以上