[Database] Transportable Tablespaces and READ ONLY in Oracle Database 12c

原文はこちら。
https://blogs.oracle.com/UPGRADE/entry/transportable_tablespaces_and_read_only

---

先日、トランスポータブル表領域を使って、同じ表領域のデータファイルを2個のデータベースに同時に接続することができない（表領域をSQL*PlusでREAD ONLYにした後にもかかわらず、です）ことに気付いたお客様と一緒に作業しました。これは12cでの新しい挙動であり、多くのお客様がまだこの変更に気付いていないことでしょう。以下に変更点とその理由、そしてこの変更が貴社の環境に影響する場合の対処法について説明します。

What Changed?

12cR1から、トランスポータブル表領域の移行のインポートフェーズの間、data pumpは表領域をread writeに設定します。これはつまり、トランスポータブル表領域を使用して、表領域を2つの異なるデータベースに同時にフックすることはできない、ということです。

Why Was This Change Made?

以下のようないくつかの要因があって変更されました。

まず第一に、データベースが増加するにつれて、多くのパーティションやサブパーティションを含む表または索引のための多くのパーティションやサブパーティションを含む表領域を処理する場合にパフォーマンスが低下することがありました。この理由（あまりにひどい場合はお詫びします）は、表領域を移動しているけれども当該表領域内の全ての表が操作の対象ではない場合には、空き領域を再利用できるようにしているためです。たとえば、5個の表のパーティションを含む表領域データファイルを移動することはできますが、それらの表のうち2個しか関心がない場合があります。その場合、別の3個の表が使用するセグメントは再利用対象のデッドスペースになります。

12c以前は、エクスポート・フェーズで最初にエクスポート対象の全てのセグメントを記録し、インポート・フェーズで当該セグメントをインポートすることで、この領域を再利用していました。これにより、インポート対象外のセグメントのスペースをすべて解放することができました。これは確かにうまくいきましたが、bigfile表領域が数十テラバイトにまで達するにつれ、パフォーマンスの劣化が激しくなりました。文字通り数日かかることもありました。そのため、12cでは異なる方式を実装しました。もうエクスポート時にセグメントを記録せず（これは11gへのバックポートとしても利用できます）、インポート時に表領域のビットマップを再計算します。ビットマップの再計算にあたっては、DBMS_SPACE_ADMIN.TABLESPACE_REBUILD_BITMAPSを呼び出し、数時間を要する可能性があった以前の方法に比べてあっという間で終了します。
したがって、多数のデータセグメントを含む場合、トランスポータブル表領域のエクスポート、インポートの両方でこの変更により、非常にパフォーマンスが改善されます。

この変更を実施した2番目の理由は、トランスポータブル表領域を使って、Timezone（TSTZ）データを持つ異なるバージョンのTimestampを使うデータベースに対し、表領域のデータベースへのインポートを実現するためです。12cより前では、データベース間でTSTZデータを移動するにあたり多くの制限がありましたが、徐々にこれらの制限を緩和して制限を取り除くことができました。ここでDatabaseユーティリティガイド (11.2.0.4) から引用してみます。

Oracle® Database Utilities 11g Release 2 (11.2)
Considerations for Time Zone File Versions in Transportable Tablespace Mode
https://docs.oracle.com/cd/E11882_01/server.112/e22490/dp_import.htm#SUTIL3777

Oracle® Databaseユーティリティ 11gリリース2 (11.2)
トランスポータブル表領域モードでのタイムゾーン・ファイルのバージョンに関する考慮点
http://docs.oracle.com/cd/E16338_01/server.112/b56303/dp_import.htm#SUTIL3777

12cR1から、より高いtimezoneバージョンを持つデータベースに表領域を移動する際にもTSTZデータを取り扱うことができます。これは、表領域データファイルを開き、この目的のために12cで作成された機能を使ってTSTZデータを修正することによって実現しています。つまり、12cを使うとトランスポータブル表領域をより多くのシナリオで利用でき、さらにTimezoneデータを含むTimestampがある場合に、結果として得られるインポートがより完全になることを意味します。

まとめると、トランスポータブル表領域のインポート時にデータファイルをread writeで開くように変更した結果、処理はより高速になり、このテクニックがより幅広く適用できるようになった、ということです。

But Neither of those Benefits Affect Me, and I Like the Old Behavior!

当該目的のために明示的にパラメータを実装することで、旧バージョンの挙動を許可することが可能な場合がありますが、このパラメータを使用する場合、次のような欠点があります。我々が旧バージョンの挙動を許すことができる可能性があります。

1. 比較対照とすべきエクスポートされたセグメントのリストがないため、トランスポータブル表領域をimpdp操作中にインポートされたセグメントを構成することはできません。ユーザーが明示的にプロシージャDBMS_SPACE_ADMIN.TABLESPACE_REBUILD_BITMAPSを呼び出すまで、当該セグメントはデッドスペースになります。
2. インポート対象の任意の表領域にTSTZデータが含まれている場合、
   

• インポートするデータベースのtimezoneバージョンが正確にエクスポートされたデータベースのそれと一致する必要があります。
• 一致しない場合、インポートは失敗します。

しかしながら、旧バージョンの挙動を残すという目的を達成するために、新しいパラメータを必要としていません。
もしファイルをOSレベル（もしくはASM）でREAD ONLYに設定すると、その設定により、データベースレベルでread writeに設定することはできなくなります。これはつまり、未使用のセグメントを空き領域に再利用しないということを意味し、結果としてTSTZの修正は実行されません。この場合、移行先のデータベースのTimezoneバージョンがインポート対象のデータのそれと一致しなければ、TSTZデータを持つ任意の表はインポート時に削除されます。

データ・ポンプ開発チームはこの変更によって得られるメリットが、機能の損失よりもはるかに上回るものと見てしまいがちですが、たくさんのお客様がデータ・ポンプの様々なユースケースをもち、データ・ポンプに対する位置づけが千差万別であることを認識しています。そのため、前述のようにオプションの提供を希望される場合は、是非エンハンスメント・リクエストを検討くださると幸甚です。