9 Oracle Exadata Storageスナップショットの設定
- Exadataスナップショットを使用する
Exadataスナップショットを使用する前に、最適なユースケースを理解します。 - Exadataスナップショットの概要
- Exadataスナップショット・データベースの前提条件
Exadataスナップショット・データベースを作成する前に、環境がこれらの要件を満たしていることを確認します。 - スパース・ディスクのサイズ変更および割当てメソドロジ
Exadataスナップショットを作成するには、スパース・グリッド・ディスクをそれらのディスクに基づいて作成されたOracle ASMディスク・グループで作成する必要があります。 - リフレッシュの考慮事項(Exadataスナップショットのライフサイクル)
リフレッシュ・サイクルが、Exadataスナップショットの使用および作成方法に影響することがあります。 - テスト・マスターとしてのOracle Data Guardスタンバイ・データベースの使用
テスト・マスターが定期的なリフレッシュを必要とする完全なデータベースの場合、テスト・マスター・データベースは、この目的専用のOracle Data Guardフィジカル・スタンバイとして作成することをお薦めします。 - Exadataスナップショットの管理
Exadataスナップショットを作成および管理するには、次の手順を実行する必要があります。 - スパース・グリッド・ディスクの管理
スパース・グリッド・ディスクのサイズ変更、再作成または活動の監視を行うことができます。 - データベース統計および待機イベントを使用したExadataスナップショットの監視
9.1 Exadataスナップショットを使用する前に
Exadataスナップショットを使用する前に、最適なユースケースを理解します。
本番データベースのワークロードに加えて、多くの顧客は、アプリケーション開発、テスト、品質保証などの非本番ワークロードにOracle Exadataを使用します。
Exadataスナップショットは、Oracleデータベースに対してスペース効率に優れた読取り専用クローンまたは読取り/書込みクローンを作成する理想的な方法です。このようなクローンは、開発やテストまたはその他の本番以外の目的で使用できます。Exadataスナップショットは、Exadataのパフォーマンスおよび可用性の機能を利用する非本番データベースで特に役立ちます。たとえば、Exadataスマート・スキャン機能の使用を検証するアプリケーション機能テストなどです。
ただし、Exadataスナップショットを使用する前に、非本番データベースのニーズには代替テクノロジやアプローチを使用した方がよい場合があることに注意してください。ビジネス・ニーズとともに次の点を考慮してください。
-
エンドツーエンドの完全なパフォーマンスと高可用性(HA)テストが必要な場合、Oracleでは、本番環境をミラー化した対応するテスト環境をお薦めします。これは、ハードウェア、ソフトウェア、データベースまたはアプリケーションの変更に応じてパフォーマンスの向上または低下を完全に評価できる唯一のソリューションです。
-
要件において、Exadataスマート・ストレージ機能を必要としない動的スナップショット機能が重視されている場合は、ExadataでOracle Advanced Cluster File System (Oracle ACFS)スナップショットを使用することを検討してください。
Oracle ACFSスナップショットの詳細は、次の関連リンクを参照してください。
9.2 Exadataスナップショットの概要
従来は、本番システムのデータベースをクローニングするには、Exadata以外のシステムにテスト・マスターとスナップショット・データベースを作成しました(図9-1)。場合によっては、これらのデータベースはソースのフル・コピーで、ソースと同じ容量のストレージが消費されます(図9-2)。
クローンが本番データベースのフル・コピーである場合、消費されるストレージ容量およびクローンの作成にかかる時間に関してコストが高くなります。数TBのデータベースのクローンを10個作成するケースを想像してみると、このアプローチが発展しない理由をすぐに理解できます。
このアプローチのもう1つのデメリットは、Exadata以外のシステムでOracle Exadata System Softwareの機能(スマート・スキャン、スマート・ロギング、スマート・フラッシュなど)が使用できないことです。
このような問題を解決するために、Exadataスナップショットを使用できます。Exadataスナップショットは、Oracleデータベースに対してスペース効率に優れた読取り専用クローンまたは読取り/書込みクローンを作成する理想的な方法です。このようなクローンは、開発やテストまたはその他の本番以外の目的で使用できます。また、複数のクローンが必要な場合にディスク領域や時間を節約できます。次の図は、Exadataスナップショットで必要な領域を示します。
ノート:
Exadataスナップショットは、開発およびテスト用にのみ使用してください。本番環境ではそれらを使用しないようにしてください。
Exadataスナップショットは、ソース・データベースのフル・クローンであるテスト・マスターに基づいています。テスト・マスターはソース・データベースをフル・コピーしたものです。1つのテスト・マスターから複数のExadataスナップショットを作成でき、追加ストレージと作業は最小限に抑えられます。各Exadataスナップショットで使用されるのはテスト・マスター用に必要な小容量のディスク領域のみで、スナップショットの作成も削除も数秒で行うことができます。各Exadataスナップショットはテスト・マスターの論理コピーです。
テスト・マスターからExadataスナップショットを作成する前に、必要であればテスト・マスターのデータを変更できます。たとえば、テスト・マスターの機密データを削除またはマスクしてから、権限を持たないユーザーがテスト・マスターを使用できるようにします。
テスト・マスターからのExadataスナップショットの作成は、子ファイルのヘッダーに親ファイル名を記録することにより行えます。この操作は数秒で完了し、必要なディスク領域も最小限です。追加のディスク領域が消費されるのは、スナップショットのユーザーがデータの変更を開始したときのみです。新しいデータのみがデータ・ブロックに書き込まれますが、そのデータ・ブロックは書込み時にスナップショットに割り当てられるものです。変更されていないデータに対するリクエストはすべて、テスト・マスターのデータ・ブロックによって処理されます。
複数のユーザーが、同じテスト・マスターから別々のスナップショットを作成することもできます。これにより、複数の開発環境およびテスト環境が、各ユーザー用のデータベースを別々に維持しつつ、領域を共有することができます。次の図は、同じテスト・マスターを使用する3つのExadataスナップショットがあるExadata環境です。
階層型スナップショットおよび読取り-書込みスナップショット
Oracle Exadata System Softwareリリース12.2.1.1.0では、階層型スナップショットおよび読取り-書込みスナップショットが導入されました。階層型スナップショットを使用すると、スナップショットからスナップショットを作成できます。スナップショットで作業しているときに、コピーを保存してから追加変更を加えたい場合に、これを行うことがあります。階層型スナップショットでは、テスト・マスターから枝分かれしたどのレベルでもスナップショットを作成できます。Exadataスナップショットは書込み可能です。スナップショットは、データの親のブロックを指します。スナップショットを編集すると、スナップショットは新しいデータを指すようになります。データが変更されていない場合は、親のブロックを指します。
スナップショットからスナップショットを取得して、親スナップショットを編集する場合は、そのスナップショットに依存するすべてのスナップショットを削除する必要があります。
- Exadataスナップショットの概念
Exadataスナップショットを作成および使用する際に必要となる様々なオブジェクトがあります。 - Exadata機能のExadataスナップショットのサポート
領域と時間の節約に加えて、Exadataスナップショットによって、Oracle Exadataでコスト効果の高い開発環境や品質が保証されたテスト環境が実現します。 - テスト/開発環境と本番環境の分離
テスト環境と開発環境は、本番データベースをホストするExadataラックとは別の物理Oracle Exadataラックでホストすることをお薦めします。 - Exadataスナップショットのタイプ
ご使用の環境の現在の設定に応じて、2種類のExadataスナップショットを作成できます。 - 階層型スナップショット・データベース
階層型スナップショットを使用すると、他のスナップショット・データベースからスナップショット・データベースを作成できます。 - スパース・テスト・マスター
階層型スナップショットの導入により、スパース・テスト・マスターを作成できるようになりました。
9.2.1 Exadataスナップショットの概念
Exadataスナップショットを作成および使用する際に必要となる様々なオブジェクトがあります。
- スパース・グリッド・ディスク
スパース・グリッド・ディスクには仮想サイズ属性と物理サイズ属性があります。 - スパース・ディスク・グループ
Exadataスナップショットでは、Oracle ASMスパース・ディスク・グループが使用されます。 - スパース・データベースおよびスパース・ファイル
Exadataスナップショット・データベースのようなスパース・データベースでは、データ・ファイルはスパース・ファイルです。
親トピック: Exadataスナップショットの概要
9.2.1.1 スパース・グリッド・ディスク
スパース・グリッド・ディスクには仮想サイズ属性と物理サイズ属性があります。
スパースOracle ASMディスク・グループはスパース・グリッド・ディスクで構成されます。
単一のセル・ディスクからスパース・グリッド・ディスクに割り当てることのできる最大物理サイズは4TBです。最大仮想サイズは100TBです。
スパース・グリッド・ディスクを作成してからスパースOracle ASMディスク・グループを作成します。新しいシステムをデプロイしている場合、または既存のシステムを再デプロイしている場合は、他のディスク・グループのケースと同様に、各セル・ディスクの領域の一部をディスク・グループ用に確保します。
再イメージ化せずに既存のシステムを使用する場合は、既存のグリッド・ディスクのサイズ変更の方法について、My Oracle Supportノート1467056.1を参照してください。
9.2.1.2 スパース・ディスク・グループ
Exadataスナップショットでは、Oracle ASMスパース・ディスク・グループが使用されます。
スパース・データ・ファイルは、Oracle Automatic Storage Management (Oracle ASM)のスパース・ディスク・グループにのみ作成できます。次の図に、3つのExadataスナップショットを含むスパース・ディスク・グループを示します。
スパース・ディスク・グループには次の属性があります。
compatible.asmは12.1.0.2以上に設定する必要があります。compatible.rdbmsは12.1.0.2以上に設定する必要があります。cell.smart_scan_capableをtrueに設定する必要があります。cell.sparse_dgはallsparseに設定する必要があります。これは、ディスク・グループがスパース・グリッド・ディスクで構成されていることをOracle ASMに示します。- Exadata上のすべてのOracle ASMディスク・グループの場合と同様に、推奨される割当て単位(AU)サイズは
4Mです。
たとえば、次のSQLコマンドによってスパース・ディスク・グループが作成されます。
SQL> CREATE DISKGROUP SPARSE
NORMAL REDUNDANCY
DISK 'o/*/SPARSE_*'
ATTRIBUTE
'compatible.asm' = '12.1.0.2',
'compatible.rdbms' = '12.1.0.2',
'cell.smart_scan_capable' = 'true',
'cell.sparse_dg' = 'allsparse',
'au_size' = '4M';
スパースOracle ASMディスク・グループは、スパース・ファイルと非スパース・ファイルを格納できるため、テスト・マスター・データベースとExadataスナップショットを同じディスク・グループに格納できます。ただし、スパース・グリッド・ディスクのサイズは制限されており(セル・ディスクで最大4 TB)、非スパース・ファイルをスパース・ディスク・グループに配置してもメリットがないため、Exadataスナップショットに関連付けられているスパース・ファイル用にスパース・ディスク・グループの領域を確保し、テスト・マスター・データベースを通常の(非スパース)ディスク・グループに配置する必要があります。
親トピック: Exadataスナップショットの概念
9.2.1.3 スパース・データベースおよびスパース・ファイル
Exadataスナップショット・データベースのようなスパース・データベースでは、データ・ファイルはスパース・ファイルです。
データベースは次のファイルで構成されます。
- 制御ファイル
- オンラインREDOログ
- 一時ファイル
- データ・ファイル
スパース・ファイルは、親ファイルのブロックに対する変更のみを含み(親ファイルは変更されません)、未変更データにアクセスするために親ファイルへのポインタを保持します。
Exadataスナップショットは、他のデータベース・ファイル(制御ファイル、オンラインREDOログおよび一時ファイル)のコピーを含みます。このような他のデータベース・ファイルはスパース・ファイルではありません。
関連項目
親トピック: Exadataスナップショットの概念
9.2.2 Exadata機能のExadataスナップショットサポート
領域と時間の節約に加えて、Exadataスナップショットによって、Oracle Exadataでコスト効果の高い開発環境や品質が保証されたテスト環境が実現します。
Exadataスナップショットは、機能の検証を必要とする開発者およびテスト担当者が使用できます。Exadataスナップショットを使用して、完全に機能するExadata環境(Exadataスマート・フラッシュ・キャッシュ、Exadataスマート・スキャンのオフロードおよびExadataハイブリッド列圧縮など)で保守および運用ステップを実行することもできます。
親トピック: Exadataスナップショットの概要
9.2.3 テスト/開発環境と本番環境の分離
テスト環境と開発環境は、本番データベースをホストするExadataラックとは別の物理Oracle Exadataラックでホストすることをお薦めします。
開発とテスト専用のOracle Exadataシステムが理想です。テスト・マスターとそれに対応するExadataスナップショットをこのシステムでホストします。あるいは、容量が許す場合は、高可用性、障害時リカバリなどのためのOracle Data Guardスタンバイ・データベースをホストするOracle Exadataシステムを使用することもできます。テスト・マスターとそれに対応するスナップショットは、Oracle Exadataシステム上の物理マシンまたは仮想マシンに配置できます。
関連項目
親トピック: Exadataスナップショットの概要
9.2.4 Exadataスナップショットのタイプ
ご使用の環境の現在の設定に応じて、2種類のExadataスナップショットを作成できます。
-
プラガブル・データベース(PDB)からのテスト・マスターの使用。
コンテナ・データベース(CDB)内の個別のPDBからExadataスナップショットPDBを作成できます。個別のPDBをクローニングしてテスト・マスターPDBを作成し、そこからExadataスナップショットPDBを生成できます。
ExadataスナップショットPDBは、同一のExadataクラスタ内で別のCDBへ移動できます。また、2つのCDBが同じExadataクラスタにある場合、あるコンテナ内に存在するテスト・マスターPDBから別のコンテナ内にExadataスナップショットPDBを作成することもできます。
テスト・マスター・データベースと対応するExadataスナップショットは、同じOracle Automatic Storage Management (Oracle ASM)クラスタ環境に存在する必要があります。
次の図に、3つのPDBを含む本番CDBを示します。PDBのうちの2つ(PDB1とPDB2)は、テスト・マスターPDBを作成するためにクローニングされています。これらは、切断されてからテストOracle Exadataの別のCDBに接続されています。この図では、テスト・マスターPDBから6個のExadataスナップショットPDBが作成されています。
-
データベース全体(CDBまたは非CDB)からのテスト・マスターの使用
Exadataスナップショット・データベースは、完全なコンテナ・データベース(CDB)と非コンテナ・データベース(非CDB)のどちらでもかまいません。完全なCDBのスナップショットには、CDB内のすべてのPDBが含まれています。
ノート:
完全なCDBのスナップショットを作成するには、Exadataスナップショット・データベースをサポートするOracleホーム・ディレクトリに、パッチ32233739を適用する必要があります。
次の図は、本番データベースのフル・クローンです。クローン(つまりテスト・マスター・データベース)は、別のテスト/開発環境でホストされ、6個のExadataスナップショットが関連付けられています。テスト・マスター・データベースは、Oracle Data Guardスタンバイ・データベース(テスト・マスターを定期的にリフレッシュする場合に推奨)またはOracle Recovery Manager (RMAN)を使用して作成されます。
テスト・マスター・データベースと対応するExadataスナップショットは、同じOracle ASMクラスタ環境に存在する必要があります。
親トピック: Exadataスナップショットの概要
9.2.5 階層型スナップショット・データベース
階層型スナップショットを使用すると、他のスナップショット・データベースからスナップショット・データベースを作成できます。
Oracle Exadata System Softwareリリース12.2.1.1.0では、階層型スナップショットが導入されました。スナップショット・データベースで作業しているときに、追加変更を加える前にコピーを保存する場合は、階層型スナップショットの使用が必要になることがあります。
階層内で許可されるレベルの数に制限は設定されていませんが、パフォーマンスと管理にかかわる理由から、現実的には10レベルに制限することをお薦めします。
スナップショット・データベースは、データのその親のブロックを指します。スナップショット・データベースに変更を加えると、スナップショット・データベースは変更されたデータに新しいブロックを割り当てます。データが変更されていない場合、スナップショットは親のブロックを指します。元のテスト・マスターから枝分かれした複数のレベルのスナップショットは、作成元のスナップショット・データベースを起点としたツリーを上に移動して、そのデータを取得します。
別のスナップショット・データベースからスナップショット・データベースを取得して、親スナップショット・データベースに変更を加える場合は、そのスナップショット・データベースに依存するすべてのスナップショット・データベースを削除する必要があります。子スナップショットが親スナップショットから作成されると、親スナップショット・データベースは読取り専用になります。親スナップショットに再度書き込む場合は、すべての子スナップショットを削除する必要があります。
親トピック: Exadataスナップショットの概要
9.2.6 スパース・テスト・マスター
階層型スナップショットの導入により、スパース・テスト・マスターを作成できるようになりました。
階層型スナップショット・データベースでは、スパース・テスト・マスターを作成できます。スパース・テスト・マスターには、データのフル・コピーがあり、複数のレベルのスナップショットの親データを提供します。スナップショットを作成する準備ができたら、スパース・ファイルの追加セットを作成し、Oracle Data Guardなどのレプリケーション技術を使用して本番データベースから更新を受信します。
現在のデータの新しいテスト・マスターを作成する必要がある場合は、その新しい時点で再度完全な本番データベースをクローニングするのではなく、以前の追加のスパース・ファイルを読取り専用とマークしてスパース・テスト・マスターを作成し、最新の状態の新しいスパース・ファイルのセットを作成します。このスパース・テスト・マスターに追加のスナップショットを作成して、アプリケーション開発者がテスト用に使用できるようにすることができます。本番データベースの1つのフル・コピーで複数の時点のスナップショットをサポートできるように、このプロセスを合計9回まで繰り返すことができます。 新しいスパース・テスト・マスターは短時間(5分以内)で作成できるため、本番にあわせて簡単に最新に保つことができます。
スパース・テスト・マスター・データベースは、コンテナ・データベース(CDB)と非コンテナ・データベース(非CDB)のどちらでもかまいません。
9.3 Exadataスナップショット・データベースの前提条件
Exadataスナップショット・データベースを作成する前に、ご使用の環境がこれらの要件を満たしていることを確認します。
-
ストレージ・サーバーは、Oracle Exadata Database Machine X3-2以降である必要があります
-
Oracle Exadata Storage ServerおよびOracle Exadata Database Server用のOracle Exadata System Software 12.1.2.1.0以上
セルにスパース・グリッド・ディスクがある状態では以前のバージョンにダウングレードできません。
-
Oracle Grid Infrastructureソフトウェア・リリース12.1.0.2.0 BP5以上
スパースOracle ASMグリッド・ディスクを含むOracle ASMディスク・グループでは、
COMPATIBLE.RDBMSとCOMPATIBLE.ASMの両方を12.1.0.2以上に設定する必要があります。親ディスク・グループは11.2と互換性を持つことができます。
- テスト・マスター・ファイルをホストするディスク・グループの場合、
COMPATIBLE.RDBMSを11.2.0.0.0以降に設定する必要があります。 -
Oracle Databaseソフトウェア・リリース12.1.0.2.0 BP5以上
親データベースおよびスナップショット・データベースは12.1.0.2との互換性が必要です。
-
スナップショット・データベースと親データベースのデータ・ファイルは、同一のOracle ASMクラスタに存在する必要があります。
-
db_block_sizeデータベース初期化パラメータは4096以上で、4096の倍数である必要があります。 -
階層型スナップショット・データベース、スパース・テスト・マスター・データベース、Oracle ASMの
cpコマンドの新しい--sparseオプションまたはOracle ASMの新しいsetsparseparentコマンドを使用している場合は、Oracle DatabaseおよびOracle Grid Infrastructureソフトウェア・リリース12.2.0.1.0およびOracle Exadata System Software 12.2.1.1.0以降が必要です。 - Exadataスパース・グリッド・ディスクおよびOracle ASMスパース・ディスク・グループは、Exadata XTストレージ・サーバーに作成できません。
-
完全なコンテナ・データベース(CDB)のスナップショットを作成するには、Exadataスナップショット・データベースをサポートするOracleホーム・ディレクトリに、パッチ32233739を適用する必要があります。
関連項目
9.4 スパース・ディスクのサイズ変更および割当てメソドロジ
Exadataスナップショットを作成するには、スパース・グリッド・ディスクをそれらのディスクに基づいて作成されたOracle ASMディスク・グループで作成する必要があります。
既存のディスク・グループを直接変更してスパース・ディスク・グループに変換することはできません。スパース属性でグリッド・ディスクを作成する必要があります。既存のディスク・グループを使用する場合、ディスク・グループおよび関連付けられているグリッド・ディスクを削除して再作成する必要があります。
新しいスパース・ディスク・グループを作成する際、すべての領域が現在既存のディスク・グループに割り当てられている場合、1つ以上の既存のディスク・グループをサイズ変更して領域を空ける必要があります。このプロセスを実行するには、次のステップを実行します。
- 新しいスパース・ディスク・グループのサイズ設定ステップ
ここに示すステップでは、スパース・ディスク・グループに必要な領域の決定方法と、その領域の割当て方法について説明します。
9.4.1 新しいスパース・ディスク・グループのサイズ設定ステップ
ここに示すステップでは、スパース・ディスク・グループに必要な領域の決定方法と、その領域の割当て方法について説明します。
単一のセル・ディスクからスパース・グリッド・ディスクに割り当てることのできる最大物理サイズは4TBです。
スパース・グリッド・ディスクごとに割り当てることのできる最大仮想サイズは100TBです。しかし、さらなるパフォーマンスへの影響を回避するために、本当に必要な場合を除き、大きな仮想サイズを作成することは推奨されません。
スパース・ディスク・グループには、非スパース・データベースのファイルも格納できます。その場合、物理記憶域の使用量は仮想ファイルのサイズと一致します。
9.5 リフレッシュの考慮事項(Exadataスナップショットのライフサイクル)
リフレッシュ・サイクルが、Exadataスナップショットの使用および作成方法に影響することがあります。
テスト・マスターは、READONLY状態(オープンしている場合)か、Exadataスナップショットが関連付けられているときはクローズ状態になっている必要があります。テスト・マスターをリフレッシュする必要がある場合は、そのテスト・マスターに依存するすべてのExadataスナップショットを削除して再作成する必要があります。
様々なグループのExadataスナップショット・ユーザーのリフレッシュ・サイクル要件が異なる場合、複数のテスト・マスターを維持する必要が生じます。次の図に、それぞれに独自のリフレッシュ・スケジュールがある3つのテスト・マスターを示します。
9.6 テスト・マスターとしてのOracle Data Guardスタンバイ・データベースの使用
テスト・マスターが定期的なリフレッシュを必要とする完全なデータベースの場合、テスト・マスター・データベースは、この目的専用のOracle Data Guardフィジカル・スタンバイとして作成することをお薦めします。
この方法を使用すると次に示す複数のメリットが得られます。
-
容易なリフレッシュ
Oracle Data Guardは、本番データベースの複数の物理レプリカ(障害時リカバリ、本番の読取り専用オフロード、バックアップ・オフロードおよびテストに使用される)を同期するソリューションとして実績があります。これと同じ機能を使用すると、本番データベースのコピーをテスト・マスター・データベース専用として維持でき、定期的なリフレッシュも容易に行うことができます。Oracle Data Guard物理スタンバイを使用するメリットは、テスト・マスター・データベースのサイズやリフレッシュが必要な回数に応じて増大します。Oracle Data Guardレプリカの作成には、Oracle Recovery Manager (RMAN)のバックアップからデータベースを単純にクローニングすることに比べて細々とした手順が必要になりますが、利点の方が大きく上回ります。
-
プライマリへの最小の影響
Oracle Data Guardレプリカがテスト・マスター・データベースとして使用されている間、Oracle Data Guard REDOのトランスポートおよび適用は無効になります。本番データベースの影響はまったくありません。リフレッシュする際には、Oracle Data Guardレプリカがテスト・マスター・データベースに変換されて以降に生成されたデルタのみが本番データベースから取得され、テスト・マスター・データベースの再同期に使用されます。
ノート:
このOracle Data Guardレプリカがテスト・マスターとして作動している間、トランスポートと適用は停止されるため、障害時リカバリなどテスト・マスター以外の目的には使用しないでください。すでに高可用性または障害保護の目的でOracle Data Guardを使用している場合は、Exadataスナップショット・データベース用のテスト・マスター・データベースとして使用するためにOracle Data Guardレプリカを作成することをお薦めします。 -
スナップショット・クローン作成前の容易なスクラブ
Oracle Data Guardでは、Exadataスナップショットの作成に使用する前に、テスト・マスター・データベースを簡単に変更できます。たとえば、Oracle Data Guardレプリカを読取り/書込みとして開き、データをマスクまたはスクラブしてからExadataスナップショットを作成できます。その後、テストが完了したら、テスト・マスター・データベースをOracle Data Guardレプリカに再変換できます。このときに、元のコピーに加えらえた変更が破棄され、本番データベースのデルタのみを使用してリフレッシュされます。Oracle Data Guardレプリカのリフレッシュ後は、テスト・マスターとして再使用する前に、データベースを再スクラブする必要があることに注意してください。
RMANバックアップ・データベースを使用しているときに、データをマスクまたはスクラブした場合は、テスト・マスターをリフレッシュする必要があるときに、別のバックアップをテスト・マスターとして作成し、それを再スクラブして最新状態にする必要があります。
9.7 Exadataスナップショットの管理
Exadataスナップショットを作成および管理するには、次の手順を実行する必要があります。
- スパース・グリッド・ディスクの作成
- スパース・グリッド・ディスク用のASMディスク・グループの作成
- テスト・マスターの設定
次の2つの方法のいずれかを使用して、テスト・マスターを作成できます。 - スナップショットの作成
プラガブル・データベース(PDB)または完全なデータベースのExadataスナップショットを作成できます。 - テスト・マスター・データベース(読取り専用)のリフレッシュ
読取り専用テスト・マスター・データベースをリフレッシュするには、読取り専用テスト・マスターに一時的に変換する必要があります。 - 別のスナップショット・データベースからのスナップショット・データベースの作成
- フル・データベースの1つのコピーからのスパース・テスト・マスターの作成
フル・データベースの1つのコピーから複数のスパース・テスト・マスターを作成できます。 - PDB用のスパース・テスト・マスターの作成
この手順では、Oracle Multitenant Databaseのプラガブル・データベース(PDB)用に階層型スナップショット・ツリーまたはスパース・テスト・マスターを手動で作成します。 - テスト・マスターに関連付けられているすべてのスナップショットの特定
この問合せを使用して、テスト・マスターに関連付けられているすべての子を検出します。 - スパース・コピーの実行
9.7.1 スパース・グリッド・ディスクの作成
スパース・グリッド・ディスクを作成するときは、物理サイズと仮想サイズを指定する必要があります。
9.7.1.1 グリッド・ディスクの物理サイズの計算
次の式を使用して、スパースASMディスク・グループ用に確保する物理領域の合計を推計できます。
Total physical space = (SUM(size of all test masters in the sparse ASM disk group) + SUM(approximate size of all updates to the snapshot databases)) * ASM Redundancy
この式では、ASM冗長性はエクステントのASMミラー化を考慮に入れています。Exadataでは、ASM冗長性を標準冗長性(エクステントを二重にミラー化)または高冗長性(エクステントを三重にミラー化)に設定する必要があります。スパースASMディスク・グループが標準冗長性を使用する場合は、2倍の領域が使用されると考えます。高冗長性を使用する場合は、3倍の領域が使用されると考えます。
たとえば、スパースASMディスク・グループ内に2つのテスト・マスターが必要で、このディスク・グループを合計容量500GB (それぞれ250GB)の標準冗長性で作成するとします。さらに、各テスト・マスターに対して5個のExadataスナップショットが生成され、各スナップショットがブロックの20%を変更すると推定した場合、必要となる合計物理領域は次のように計算されます。
Space for 2 test masters: 2 * 250 GB = 500 GB Space for 5 snapshots per test master, for a total of 10 snapshots: 10 * 250 GB * 20% = 500 GB Subtotal 1000 GB Normal redundancy: 2 * 1000 GB = 2000 GB
この値をディスク数で割って、各ディスクのsizeパラメータを決定します。ASMグリッド・ディスクは、16MBごとの境界で割り当てる必要があります。各グリッド・ディスクのMBのsizeパラメータが16で均等に分割できない場合は、16MB境界に合うように調整します。
複数のプロジェクトや複数の反復で使用するために余分な領域を確保しておく必要があることに注意してください。
また、ディスクのリバランス操作に対応するには、スナップショットおよびテスト・マスターに使用される領域の上に15%の領域クッションを追加する必要があります。
親トピック: スパース・グリッド・ディスクの作成
9.7.1.2 グリッド・ディスクの仮想サイズの計算
次の式を使用して、スパースASMディスク・グループに割り当てる仮想サイズを推計できます。
Virtual size required for sparse disks = (SUM(full virtual size of all Exadata snapshots) + Physical space allocated) * ASM Redundancy
前の項の例を使用すると、10個のExadataスナップショットがあります。これらがテスト・マスターのフル・コピーである場合、それぞれ250GBになります。
次に、合計仮想領域の計算を示します。
Full size for 5 snapshots per test master, for a total of 10 snapshots: 10 * 250 GB = 2500 GB Size of the 2 test masters: 2 * 250 GB = 500 GB Subtotal 3000 GB Normal redundancy: 2 * 3000 GB = 6000 GB
この値をディスク数で割って、各ディスクのvirtualsizeパラメータを決定します。各グリッド・ディスクの仮想サイズは、16MBごとの境界で割り当てる必要があります。各グリッド・ディスクのMBのvirtualSizeパラメータが16で均等に分割できない場合は、16MB境界に合うように調整します。
複数のプロジェクトや複数の反復で使用するために余分な領域を確保しておく必要があることに注意してください。
親トピック: スパース・グリッド・ディスクの作成
9.7.1.3 スパース・グリッド・ディスクの作成
スパースASMグリッド・ディスクを作成するには、CellCLIで各セルにログインし(またはdcliを使用し)、次のようなコマンドを実行します。サイズの値は必要に応じて変更してください。
CellCLI> create griddisk all harddisk prefix=SPARSE, size=56G, virtualsize=560G
これによって、物理サイズが56GBのグリッド・ディスクが作成されますが、ASMに対しては560GBのグリッド・ディスクとして表されます。sizeパラメータは、ASMグリッド・ディスクの実際の物理サイズと一致する必要がありますが、virtualsizeパラメータはASMグリッド・ディスクの物理サイズ以上に設定してください。
ここで作成されらASMグリッド・ディスクの属性は、LIST GRIDDISK DETAILコマンドでは次のように表示されます。
CellCLI> LIST GRIDDISK DETAIL size: 56G sparse: TRUE virtualSize: 560G
sizeは、グリッド・ディスクの実際の物理サイズです。
sparseの値はTRUEです。
virtualSizeは、グリッド・ディスクの仮想サイズです。
親トピック: スパース・グリッド・ディスクの作成
9.7.2 スパース・グリッド・ディスク用のASMディスク・グループの作成
スパース・グリッド・ディスクを作成した後で、ASMディスク・グループを作成して、それらのディスクにクラスタ上のデータベースがアクセスできるようにします。ディスク・グループを作成するには、SQL*Plusをsysasmとして使用してASMインスタンスにログインし、次のようなコマンドを実行します。
SQL> create diskgroup SPARSE high redundancy disk 'o/*/SPARSE_*' attribute 'compatible.asm'='12.1.0.2', 'compatible.rdbms'='12.1.0.2', 'au_size'='4M', 'cell.smart_scan_capable'='true', 'cell.sparse_dg'='allsparse', 'appliance.mode' = 'TRUE';
compatible.asmは12.1.0.2以上に設定する必要があります。
compatible.rdbmsは12.1.0.2以上に設定する必要があります。
cell.sparse_dgはallsparseに設定する必要があります。これは、ディスク・グループがスパース・グリッド・ディスクで構成されていることをASMに示します。
appliance.modeはtrueに設定する必要があります。
親トピック: Exadataスナップショットの管理
9.7.3 テスト・マスターの設定
2つの方法のいずれかを使用してテスト・マスターを作成できます。
テスト・マスターを作成した後、「テスト・マスター・データ・ファイルの所有権の設定」で説明されているタスクを実行します。
- 新しいテスト・マスターの作成 - ASM ACLが有効化されたディスク・グループでのフル・クローン
- 既存のフル・クローンまたはスタンバイ・データベースのテスト・マスターへの変換
すでに存在しているフル・クローンまたはスタンバイ・データベースをテスト・マスターとして利用したい場合は、そのデータベースをテスト・マスターに変換できます。 - テスト・マスター・データ・ファイルの所有権の設定
テスト・マスター・データベースを作成するためにデータベースをクローニングした後、ディスク・グループおよびデータ・ファイルに対する権限を構成します。
親トピック: Exadataスナップショットの管理
9.7.3.1 新しいテスト・マスターの作成 - ASM ACLが有効化されたディスク・グループでのフル・クローン
データベースのフル・クローンを作成するには、RMANバックアップ/リストアやデータ・ポンプなど、データベースのフル・クローンの作成に一般的に使用される方法を使用します。
クローンは、通常(非スパース)のOracle ASMディスク・グループに配置する必要があります。
フル・クローンを作成した後は、誤って上書きしないようにデータ・ファイルを読取り専用にします。
たとえば:
SQL> ALTER DISKGROUP DATA SET PERMISSON OWNER=READ ONLY, GROUP=READ ONLY, OTHER=NONE FOR FILE 'FILENAME';
親トピック: テスト・マスターの設定
9.7.3.2 既存のフル・クローンまたはスタンバイ・データベースのテスト・マスターへの変換
すでに存在しているフル・クローンまたはスタンバイ・データベースをテスト・マスターとして利用したい場合は、そのデータベースをテスト・マスターに変換できます。
9.7.3.3 テスト・マスター・データ・ファイルの所有権の設定
テスト・マスター・データベースを作成するためにデータベースをクローニングした後、ディスク・グループおよびデータ・ファイルに対する権限を構成します。
オペレーティング・システム・ユーザーをディスク・グループの所有者に設定し、オペレーティング・システム・ユーザーをテスト・マスターのデータ・ファイルの所有者にします。
これには、SQLコマンドをSQL*Plusで手動で実行するか、スクリプトを実行します。
- コマンドの手動実行
テスト・マスター・データ・ファイルの所有権を設定するには、SQL*Plusを使用してコマンドを手動で実行します。 - スクリプトの実行
SQLスクリプトを使用してテスト・マスター・データ・ファイルの所有権を設定することもできます。
親トピック: テスト・マスターの設定
9.7.3.3.2 スクリプトの実行
SQLスクリプトを使用してテスト・マスター・データ・ファイルの所有権を設定することもできます。
次の手順は、前のトピックのコマンドと同じ結果になりますが、ファイル名をV$DATAFILEに問い合せる点が異なります。
親トピック: テスト・マスター・データ・ファイルの所有権の設定
9.7.4 スナップショットの作成
プラガブル・データベース(PDB)または完全なデータベースのExadataスナップショットを作成できます。
- プラガブル・データベースのスナップショットの作成
- フル・データベースのスナップショットの作成
フル・データベースのExadataスナップショットを作成します。
親トピック: Exadataスナップショットの管理
9.7.4.1 プラガブル・データベースのスナップショットの作成
プラガブル・データベース(PDB)のExadataスナップショットの作成は、手動のステップを加える必要がないため、スナップショットの作成の中で最も単純です。CREATE PLUGGABLE DATABASE文の2つの新しい句は、PDBをExadataスナップショットとして識別します。
個々のExadataスナップショットPDBの作成は、指定のCDB内のPDB数が少ない場合にスナップショットを作成するときに最適です。次の図に、2つのPDBスナップショットがあるPDBの典型的なライフサイクルの概要を例として示します。
OracleのマルチテナントとPDBのメリットの1つは、既存のPDBのクローンを容易にクローニングしてテスト・マスターを作成し、あるCDBから別のCDBに移動できることです。ソースPDBをクローニングしてテスト・マスターを作成し、必要なデータ・スクラブを実行できるテスト環境にテスト・マスターを移行することをお薦めします。これが完了すると、テスト・マスターPDBを使用して多数のExadataスナップショットPDBを作成できます。
ExadataスナップショットPDBは、CDB内のPDBとして作成されます。その他すべてのPDBと同様に、ExadataスナップショットPDBは、単一のCDB内のPDBの最大数に関する一般的な制限を受けます。Oracle Database 12cリリース1 (12.1)では、単一のCDB内のPDB数の制限は252個です。Oracle Database 12cリリース2 (12.2)以降では、単一のCDB内のPDB数の制限は4096個です。
ExadataスナップショットPDBの作成時に、このコマンドによってテスト・マスターPDBに対するファイル権限が変更され、Oracle ASMでファイルがREADONLYとしてマークされます。そのため、テスト・マスターPDBを削除する場合は、最初にスナップショット・コピーをすべて削除し、テスト・マスターPDBファイルの権限をREAD WRITEに戻す必要があります。
ノート:
ファイルの権限をREAD WRITEに変更する前にテスト・マスターPDBを削除した場合、コマンドはエラーなしで完了します。ただし、基礎になるデータベース・ファイルは残り、エントリがデータベース・アラート・ログ・ファイルに書き込まれます。この場合、Oracle ASM内のファイルを手動で削除して、ファイルが占有している領域を解放する必要があります。
テスト・マスターPDBを作成した後で、次のステップを実行してExadataスナップショットPDBを作成します。
親トピック: スナップショットの作成
9.7.4.2 フル・データベースのスナップショットの作成
フル・データベースのExadataスナップショットを作成します。
次の図は、Exadataテスト・マスター・データベースおよびスナップショット・データベースのライフサイクルを示しています。ここでは、テスト・マスターはOracle Data Guardレプリカに基づいています。
テスト・マスター・データベースは、高可用性または障害時リカバリを提供するフェイルオーバー・ターゲットとして使用できないことに注意してください(Data Guard構成は、別の目的に使用される複数のレプリカを含むことができます)。テスト・マスターPDBと似ていますが、テスト・マスター・データベースは、対応するExadataスナップショットが存在している場合は変更できません。
テスト・マスター・データベースとして、リカバリ・モードの読取り専用スタンバイ・データベース(たとえばリアル・タイム適用のActive Data Guard)を使用することはできません。
テスト・マスター・データベースと対応するExadataスナップショットは、同じOracle ASMクラスタ環境に存在する必要があります。
ノート:
テスト・マスターがOracle RACデータベースの場合は、次のいずれかを実行する必要があります。
- スパース・クローン用に
CREATE CONTROLFILE文ですべてのスレッドのREDOログを作成します。または - スパース・クローンのSPFILEにある
ONLINE_LOG_CREATE_DEST_1初期化パラメータを使用して、REDOログにOracle Managed Filesを指定して、REDOログが自動作成されるようにします。
親トピック: スナップショットの作成
9.7.5 テスト・マスター・データベース(読取り専用)のリフレッシュ
読取り専用テスト・マスター・データベースをリフレッシュするには、読取り専用テスト・マスターに一時的に変換する必要があります。
テスト・マスター・データベース(読取り専用)をリフレッシュするための主なステップは次のとおりです。
- スナップショット・データベースの削除
リフレッシュするテスト・マスター・データベースの子であるExadataスナップショット・データベースを削除します。 - テスト・マスターの権限の読取り/書込みへの変更
データ・ファイルを読取り専用から読取り/書込みに変更する際に、SQLを使用すると、SQLコマンドのスクリプトを生成できます。 - テスト・マスター・データベースのData Guardレプリカへの再変換
テスト・マスターのデータ・ファイルが書込み可能になったら、読取り専用テスト・マスター・データベースをOracle Data Guardレプリカに変換します。 - テスト・マスター・データベースの更新
- テスト・マスターのクローズとすべてのテスト・マスター・データ・ファイルの読取り専用設定
テスト・マスターが更新された後、読取り専用テスト・マスターに戻すことができます。 - すべてのスナップショットの再作成
テスト・マスターが更新され、再度読取り専用になった後、すべてのスナップショット・データベースを再作成して最新の更新を取得します。
親トピック: Exadataスナップショットの管理
9.7.5.1 スナップショット・データベースの削除
リフレッシュするテスト・マスター・データベースの子であるExadataスナップショット・データベースを削除します。
RMANを使用してスナップショット・データベースを削除できます。
9.7.5.2 テスト・マスターの権限の読取り/書込みへの変更
データ・ファイルを読取り専用から読取り/書込みに変更する際に、SQLを使用すると、SQLコマンドのスクリプトを生成できます。
9.7.5.3 テスト・マスター・データベースのData Guardレプリカへの再変換
テスト・マスターのデータ・ファイルが書込み可能になったら、読取り専用テスト・マスター・データベースをOracle Data Guardレプリカに変換します。
最初にOracle Data Guardスナップショット・スタンバイを使用してテスト・マスター・データベースを用意していた場合は、CONVERTコマンドを使用して元の状態のOracle Data Guardレプリカに再変換します。このコマンドにより、レプリカをテスト・マスターとして準備するために加えられた変更は破棄されます。また、現在のバックアップを完全にリストアするかわりに、ソース・データベースの増分変更のみを使用してテスト・マスターをリフレッシュできるようになります。
9.7.5.4 テスト・マスター・データベースの更新
テスト・マスター・データベースのリフレッシュには2つのオプションがあります。
-
Oracle Data Guardによりテスト・マスター・データベースをリフレッシュ
Oracle Data Guardレプリカがテスト・マスター・データベースとして使用されたのがごく短期間で、ソース・データベースでこの期間に生成されたすべてのREDOがディスク上のアーカイブ・ログにある場合、REDO送信を有効にしてREDO適用を開始できます。テスト・マスター・データベースは標準のOracle Data Guardプロトコルを使用して、アーカイブ・ログを取得し、ログを適用して、プライマリ・データベースの状態に追い付きます。Oracle Data Guardレプリカが必要な時点の状態になったら、REDO送信を無効にして、REDO適用を停止し、テスト・マスターとスナップショットの作成サイクルを繰り返します(「テスト・マスターの設定」および「スナップショットの作成」を参照)。
このオプションのメリットは、テスト・マスター・データベースを最新状態にする前の段階でREDO適用を停止できることです。
Oracle Data Guardによってスタンバイをリフレッシュさせるには、スタンバイへのログの送信とスタンバイでのREDOの適用を有効にします。
DGMGRL> edit database TESTMASTER set property logshipping=ON; Property "logshipping" updated DGMGRL> edit database TESTMASTER set state=apply-on; Succeeded -
RMAN
RECOVER...FROM SERVICEを使用してテスト・マスター・データベースをロール・フォワードOracle Data Guardレプリカがテスト・マスター・データベースとして長期にわたって使用されている場合、またはOracle Data Guardによってテスト・マスター・データベースを自動的にリフレッシュするためのREDOがディスク上にない場合は、RMANを使用してネットワークを介したライブ増分適用を実行します。
この方法を使用する主なメリットは、追加のディスク領域が必要ないことです。RMANが、プライマリの変更済ブロックをネットワークを介してスタンバイに移し、直接適用します。また、RMANは、テスト・マスターのデータ・ファイルのSCNに基づいて取得すべきブロックを判別することでプロセスを大幅に単純化します。この方法では中間の時点にリカバリすることはできません。リフレッシュによってテスト・マスター・データベースがプライマリと同じ状態になります。この方法の詳細は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』のRMANリカバリの実行: 拡張シナリオに関する項を参照してください。
RMANネットワーク増分を使用してテスト・マスター・データベースをリフレッシュするには:
9.7.5.5 テスト・マスターのクローズとすべてのテスト・マスター・データ・ファイルの読取り専用設定
テスト・マスターが更新された後、読取り専用テスト・マスターに戻すことができます。
次に、「テスト・マスター・データ・ファイルの所有権の設定」.で説明されているタスクのいずれかを完了します。
9.7.5.6 すべてのスナップショットの再作成
テスト・マスターが更新され、再度読取り専用になった後、すべてのスナップショット・データベースを再作成して最新の更新を取得します。
プラガブル・データベース(PDB)またはフル・データベースのExadataスナップショット・データベースを作成できます(「スナップショットの作成」を参照)。
9.7.6 別のスナップショット・データベースからのスナップショット・データベースの作成
スナップショットからスナップショットを作成するには:
-
第1レベルのスナップショットを作成します。次の例では、このスナップショットは、
PDB1S1と呼ばれています。create pluggable database PDB1S1 from PDB1TM1 create_file_dest='+SPARSE' snapshot copy;
-
次のステップで読取り専用として再度開くことができるように、PDBを開いて閉じます。
alter pluggable database PDB1S1 open; alter pluggable database PDB1S1 close;
-
テスト・マスターとして機能できるように、PDBを読取り専用モードで開きます。
alter pluggable database PDB1S1 open read only;
-
ステップ1で作成したスナップショットからスナップショットを作成します。次の例では、第2レベルのスナップショットは、
PDB1S1_Aと呼ばれています。create pluggable database PDB1S1_A from PDB1S1 create_file_dest='+SPARSE' snapshot copy; alter pluggable database PDB1S1_A open;
関連項目
親トピック: Exadataスナップショットの管理
9.7.7 フル・データベースの1つのコピーからのスパース・テスト・マスターの作成
フル・データベースの1つのコピーから複数のスパース・テスト・マスターを作成できます。
この手順では、テスト・マスターのソースは、Data Guardのフィジカル・スタンバイ・データベースのフル・コピーです。このスタンバイ・データベースは、スイッチオーバーまたはフェイルオーバーのターゲットとして使用しないでください。これは、このプロセスで定義されたテスト・マスターのソースとしてのみ使用するようにしてください。
このプロセスでは、階層型スナップショット機能を利用してREDOを送信および適用できるようにし、スタンバイ・データベースを本番にあわせて最新に保ちます。また、Exadata Storageスナップショットで使用されるテスト・マスターのソースとして使用されるファイルを提供します。フィジカル・スタンバイ・データベースは、プライマリ・データベースのフル・コピーとして開始されます。ストレージ・スナップショットを作成する準備ができたら、フル・データベース・ファイルを指すスパース・データ・ファイルを作成し、プライマリから送信されたREDOを適用します。次に、これらのスパース・ファイルをスタンバイ・データベース・インスタンスで使用して、REDOを適用します。また、スパース・データ・ファイルをActive Data Guardモードで開いて、現在のデータの読取り専用アクセスを指定することもできます。
様々な時点で追加のスナップショットが必要な場合は、以前作成したスパース・ファイルの上に新しいスパース・ファイルを作成してREDOを適用し、データを最新に保つプロセスを繰り返します。これにより、データ・ファイルの1つのフル・コピーを使用して、様々な時点の複数のテスト・マスターとして使用できます。また、既存のスナップショットを削除する必要がないため、新しいテスト・マスターを短時間で作成することもできます。
次のタスクは、フィジカル・スタンバイ・データベースがすでに作成されていて、テスト・マスターのソースとして使用することを前提としています。このデータベースは、コンテナ・データベース(CDB)と非コンテナ・データベース(非CDB)のどちらでもかまいません。
- タスク1: スタンバイ・データベースをスパース・テスト・マスターとして使用するための準備
- タスク2: スタンバイ・サイトでのスパース・テスト・マスターおよびスパース・ファイルの構成
このタスクでは、スタンバイをテスト・マスターに変換し、スパース・ファイルを作成して、プライマリ・データベースからREDOを受信して適用します。 - タスク3: 新しいスパース・テスト・マスターを使用したフル・データベース・スナップショットの作成
- タスク4: 以前に作成したスパース・テスト・マスターを使用した新しいスパース・テスト・マスターの作成
新しいスナップショットのセットを作成して、新しいテスト・マスターと、プライマリからの変更内容を含めるための新しいスパース・ファイルを用意します。
親トピック: Exadataスナップショットの管理
9.7.7.1 タスク1: スタンバイ・データベースをスパース・テスト・マスターとして使用するための準備
スタンバイ・データベースの既存のファイルは、スナップショットのサポートに使用されます。スタンバイの既存のファイルを指す一連のスパース・ファイルを作成します。プライマリ・データベースから受信したREDOが、これらのファイルに適用されます。これらのスパース・ファイルにより、スタンバイ・データベースをスパース・テスト・マスターとして使用できるようになり、また、プライマリ・データベースを最新に保つことができます。
9.7.7.2 タスク2: スタンバイ・サイトでのスパース・テスト・マスターおよびスパース・ファイルの構成
このタスクでは、スタンバイをテスト・マスターに変換し、スパース・ファイルを作成して、プライマリ・データベースからREDOを受信して適用します。
ノート:
このプロセスでは、フル・スナップショット・データベースを作成せず、既存のスタンバイ・データベースの一部を使用して、スタンバイにスパース・データ・ファイルを追加します。スタンバイ・データベースの制御ファイルは、追加されるスパース・ファイルを使用するために変更されます。今後は、同じスタンバイ・インスタンスが使用されますが、REDO適用ではスパース・ファイルを使用して変更を格納し、スナップショットのスパース・テスト・マスター・ファイルとして機能する元のスタンバイ・データ・ファイルはそのままにします。既存のデータ・ファイルを使用して、プロセスが実行された時点のデータでフル・データベース・スナップショットをサポートします。
9.7.7.3 タスク3: 新しいスパース・テスト・マスターを使用したフル・データベース・スナップショットの作成
タスク1: スタンバイ・データベースをスパース・テスト・マスターとして使用するための準備のステップ2で作成したバックアップ制御ファイルを使用して、CREATE CONTROLFILE文を作成する必要があります。このファイルを使用するには、一時データベース・インスタンスを作成して制御ファイルをマウントし、「backup controlfile to trace」コマンドを実行します。
9.7.7.4 タスク4: 以前に作成したスパース・テスト・マスターを使用した新しいスパース・テスト・マスターの作成
新しいスナップショットのセットを作成して、新しいテスト・マスターと、プライマリからの変更内容を含めるための新しいスパース・ファイルを用意します。
テスト・マスターの完全なコピーを作成することなく、定期的にスタンバイ・データベースを使用して追加のスナップショットを作成できます。階層型スナップショット機能を利用して、前の3つのタスクで実行したプロセスを繰り返すことにより、これを行うことができます。新しいテスト・マスターは、REDOを適用している既存の最新のスナップショットの上に作成されます。このスナップショットは読取り専用となり、新しいスナップショットは、REDO適用処理を続行するように作成されます。
次を実行して、新しいテスト・マスター・タイムラインのスタンバイを構成します。
新しいスパース・テスト・マスターを作成するプロセスは9回まで繰り返すことができ、10レベルの環境が作成されます(元のスタンバイ・データ・ファイルと9つの階層型スナップショット)。このプロセスを9回繰り返すときには、プライマリ・データベースからREDOを受信するための新しいスナップショットを作成しないでください。
最大の10レベルに到達したら、次の複数のオプションから選択します。
-
スタンバイ・データベースとスナップショットの複数のコピーを保持するための十分な領域がある場合は、別のスタンバイ・データベースに基づいた新しい階層型スナップショットのツリーを作成します。元のスタンバイ・データ・ファイルとスナップショットは、不要になるまで保持できます。
-
スタンバイ・データベースとスナップショットの複数のコピーを保持するための十分な領域がない場合は、次の操作を実行します。
-
スナップショットとそれに関連付けられたデータ・ファイル(テスト・マスターとして使用されているスナップショットを含む)を削除します。
-
スタンバイをリフレッシュします。
-
新しい階層型スナップショットのツリーを作成します。
-
-
別の環境に新しいスタンバイ・データベースを作成し、新しい階層型スナップショットのツリーを作成します。
9.7.8 PDB用のスパース・テスト・マスターの作成
この手順では、Oracle Multitenant Databaseのプラガブル・データベース(PDB)用に階層型スナップショット・ツリーまたはスパース・テスト・マスターを手動で作成します。
参照用のdailyスナップショットを作成する間、テスト・マスターは閉じられている必要があります。停止時間はごく短い(5分未満)です。Oracle GoldenGateなどのレプリケーション・メカニズムを使用して、本番PDBでスパース・テスト・マスターを最新の状態に維持できます。PDBを使用したOracle GoldenGateの構成の詳細は、『Oracle GoldenGate Oracleインストレーションおよびセットアップ・ガイド』のマルチテナント・コンテナ・データベースでのOracle GoldenGateの構成に関する項を参照してください。次の例では、Oracle GoldenGateを使用していると想定しています。
ステップ1: PROD PDBからの最初のテスト・マスターPDBの作成
これは、テスト・マスターPDBをインスタンス化する従来のPDBのクローニング操作です。クローニングが完了したら、Oracle GoldenGateを構成して、本番のPRODPDB1 PDBから変更を抽出し、これらの変更をテスト・マスターTMPDB1 PDBにレプリケートします。
-
PRODコンテナ・データベース(CDB)のルートで次のコマンドを実行します。PRODCDB> alter pluggable database prodpdb1 close; PRODCDB> alter pluggable database prodpdb1 open read only; -
テスト・マスターCDBのルートから次のコマンドを実行します。
TMCDB> create database link PROD_DBLINK connect to system identified by password using 'PROD_CDB'; TMCDB> create pluggable database TMPDB1 from PRODPDB1@PROD_DBLINK; TMCDB> alter pluggable database TMPDB1 open; -
PRODPDB1PDBで行われた変更がTMPDB1PDBに抽出、レプリケートおよび適用されるよう、Oracle GoldenGateを構成します。ExtractおよびReplicatを構成し、抽出プロセスを開始した後、PRODPDB1PDBを読取り/書込みモードで開きます。ノート:
Oracle GoldenGateが構成され、抽出プロセスが開始されるまで、PRODPDB1PDBを変更用に開くことはできません。PRODCDB> alter pluggable database PRODPDB1 close; PRODCDB> alter pluggable database PRODPDB1 open;
このとき、テスト・マスターにはPRODPDB1のフル・コピーがあり、TMPDB1はPRODPDB1で行われたデータの変更をすべて受け取ります。
ノート:
Oracle GoldenGateでは、CREATE TABLESPACEまたはADD DATAFILEのようなデータ・ディレクトリの変更をレプリケートしません。スキーマの変更のみ、PRODPDB1からTMPDB1にレプリケートされます。
TMPDB1は読取り/書込みモードで開くことができますが、Oracle GoldenGateを通じて受け取る必要がある変更はPRODPDB1のみのため、読取り専用のままにしてください。
TMPDB1からスナップショットを作成するには、テスト・マスターPDBを読取り専用モードで開く必要があります。スナップショットを作成するテスト・マスターPDB、およびソースにより最新の状態に維持されるテスト・マスターPDBを提供するには、2つのPDBが必要です。次のステップは、これを達成する方法を示します。
ステップ2: 読取り専用のdailyスナップショットの作成およびTMPDB1 PDBの新しいスパース・テスト・マスターPDBへの移動
このステップでは、テスト・マスターとして動作する読取り専用のスナップショットPDBを作成します。その後、この読取り専用のスナップショットPDBから毎日、読取り/書込み用のPDBを作成できます。主なステップは次のとおりです。
-
プライベートの読取り/書込みクライアントが使用可能な読取り専用の(daily)スナップショットPDBを作成します。
-
読取り専用のdailyスナップショットPDBを指す新しいスパース
TMPDB1PDBを作成します。また、新しいTMPDB1PDBは、PRODPDB1から変更を受け入れ、適用します。
TMPDB1 PDBに接続し、次のコマンドを実行します。
TMCDB> alter session set container = CDB$ROOT;
# Stop the Oracle GoldenGate replicat process at the Test Master database. This allows
# all changes made at PRODPDB1 to continue to be extracted and then applied to
# TMPDB1 when the replicat process is restarted.
# Close the test master PDB.
TMCDB> alter pluggable database TMPDB1 close;
# Write the test master PDB metadata to an XML file.
TMCDB> alter pluggable database TMPDB1 unplug into
'/home/oracle/snapshot/TMPDB1_monday.XML';
# Drop the test master PDB, but keep the data files.
TMCDB> drop pluggable database TMPDB1 keep datafiles;
# Create a TMPDB1_MONDAY PDB using the XML file you just created.
#Use the NOCOPY clause to reuse the original data files.
TMCDB> create pluggable database TMPDB1_MONDAY using
'/home/oracle/snapshot/TMPDB1_monday.XML' nocopy;
# Open the new TMPDB1_MONDAY PDB. The PDB must be opened
# once in read/write mode to complete the creation process.
TMCDB> alter pluggable database TMPDB1_MONDAY open;
TMCDB> alter pluggable database TMPDB1_MONDAY close;
TMCDB> alter pluggable database TMPDB1_MONDAY open read only;
# Create the new TMPDB1 PDB to receive changes from PRODPDB1. This PDB
# must have the same name as the original test master PDB to ensure no
# changes are required to the Oracle GoldenGate configuration.
TMCDB> create pluggable database TMPDB1 from TMPDB1_MONDAY
create_file_dest='+SPARSE'
snapshot copy;
# Open the new TMPDB1 PDB. The PDB must be opened once in read/write
# mode to complete the PDB creation process.
TMCDB> alter pluggable database TMPDB1 open;
TMCDB> alter pluggable database TMPDB1 close;
TMCDB> alter pluggable database TMPDB1 open read only;
# Restart the Oracle GoldenGate replicat process to the new TMPDB1
# PDB. The Oracle GoldenGate replicat process now applies changes from
# PRODPDB1 to the TMPDB1 snapshot and all changes are written to
# sparse files.
次の図は、TMPDB1_MONDAYから作成されるTMPDB1を示しています。オリジナルのTMPDB1は、前述のDROP PLUGGABLE DATABASE/CREATE PLUGGABLE DATABASEのステップでTMPDB1_Mondayという名前に変更されています。新しいTMPDB1は、TMPDB1に対して変更が行われるまで、TMPDB1_Mondayとまったく同じに見えるスパース・スナップショット・プラガブル・データベースです。Oracle GoldenGateは新しいTMPDB1スナップショットにREDOを適用します。Replicat構成への変更は必要ありません。
ステップ3:TMPDB1_MONDAYからの読取り/書込みスナップショットの作成
TMPDB1ではなく、TMPDB1_MONDAYからスナップショットを作成します。これにより、TMPDB1 PDBは、PRODPDB1から変更を受け取り、適用できます。
TMPDB1_MONDAY PDBに接続し、次のコマンドを実行します。
TMCDB> alter session set container = cdb$ROOT;
TMCDB> create pluggable database TEST_MONDAY_JIM from TMPDB1_MONDAY
create_file_dest='+SPARSE'
snapshot copy;
TMCDB> alter pluggable database TEST_MONDAY_JIM open;
次の図は、TMPDB1_MONDAYから作成されるTEST_MONDAY_JIMスナップショットPDBを示しています。TEST_MONDAY_JIMではTMPDB1_MONDAYが親として使用されるため、スナップショットPDBに変更が追加されるまで、TMPDB1_MONDAY_JIM内のすべてのデータはTMPDB1_MONDAYのデータと同じです。Oracle GoldenGateは引き続きREDOを受け取り、TMPDB1に適用します。
別のテスト・マスターおよびスナップショットを作成する必要がある場合は、ステップ2を繰り返す必要があります。たとえば、火曜日にテスト・マスターを作成するには、次を実行します。
TMPDB1 PDBのSQL*Plusセッションを開始します。
TMCDB> alter session set container = CDB$ROOT;
# Stop the Oracle GoldenGate replicat process from applying changes to
# TMPDB1
# Close the test master PDB
TMCDB> alter pluggable database TMPDB1 close;
# Write the test master PDB metadata to an XML file
TMCDB> alter pluggable database TMPDB1 unplug into
'/home/oracle/snapshots/TMPDB1_tuesday.XML';
# Drop the test master PDB, but keep the data files
TMCDB> drop pluggable database TMPDB1 keep datafiles;
# Create a TMPDB1_TUESDAY PDB from the XML file
TMCDB> create pluggable database TMPDB1_TUESDAY using
'/home/oracle/snapshot/TMPDB1_tuesday.XML' nocopy;
# Open the new TMPDB1_TUESDAY PDB
TMCDB> alter pluggable database TMPDB1_TUESDAY open;
TMCDB> alter pluggable database TMPDB1_TUESDAY close;
TMCDB> alter pluggable database TMPDB1_TUESDAY open read only;
# Create the new TMPDB1 PDB as a snapshot PDB
TMCDB> create pluggable database TMPDB1 from TMPDB1_TUESDAY
create_file_dest='+SPARSE'
snapshot copy;
# Open the TMPDB1 PDB
TMCDB> alter pluggable database TMPDB1 open;
TMCDB> alter pluggable database TMPDB1 close;
TMCDB> alter pluggable database TMPDB1 open read only;
# Restart the Oracle GoldenGate replicat process to apply changes to
# the new TMPDB1前述のステップ3と同様、TMPDB1_TUESDAYから読取り/書込みスナップショットPDBを作成できます。フル・データベースのスパース・テスト・マスターと同様、このプロセスを合計9回まで繰り返すことができます。その後は、新しいTMPDB1テスト・マスターを作成するか、オリジナルのTMPDB1を削除して再度作成し、新しい階層型スナップショット・ツリーを構築する必要があります。
親トピック: Exadataスナップショットの管理
9.7.9 テスト・マスターに関連付けられているすべてのスナップショットの特定
この問合せを使用して、テスト・マスターに関連付けられているすべての子を検出します。
複数の子があるテスト・マスターについて次の構成を考えます。
各データベースに関連するSYSTEMデータ・ファイルの問合せを使用して、同じツリー内のすべての子をリストできます。この問合せにより、各データベースまたはPDBのSYSTEMデータ・ファイルのみが選択されます。データ・ファイルは、すべてのクローンおよび親に存在する必要があり、それぞれに1つのデータ・ファイルのみが存在する必要があります。START WITH句は、元のテスト・マスターの親である、クローン・ファイルではないファイルの開始点になります。
Oracle ASMインスタンスに接続し、このコマンドをSYSASMユーザーとして実行します。
SELECT clonefilename "Child", snapshotfilename "Parent"
FROM v$clonedfile
WHERE LOWER(snapshotfilename) LIKE '%system.%'
START WITH snapshotfilename NOT IN (SELECT clonefilename FROM v$clonedfile)
CONNECT BY LOWER(clonefilename) = PRIOR (snapshotfilename);
データベース・ベースのスナップショットのこの問合せの結果は、次のようになります。
Child
Parent
-----------------------------------------------------------
-----------------------------------------------------------------
+SPARSE/SNAP001/DATAFILE/SYSTEM.256.1011532891
+DATA/TESTMASTER/DATAFILE/system.270.1011530981
+SPARSE/SNAP002/DATAFILE/SYSTEM.265.1011532969
+DATA/TESTMASTER/DATAFILE/system.270.1011530981
+SPARSE/SNAP1011/DATAFILE/SYSTEM.270.1011533005
+SPARSE/SNAP001/DATAFILE/system.256.1011532891
+SPARSE/SNAP1012/DATAFILE/SYSTEM.275.1011780925
+SPARSE/SNAP001/DATAFILE/system.256.1011532891
+SPARSE/SNAP2011/DATAFILE/SYSTEM.281.1011781103
+SPARSE/SNAP1011/DATAFILE/system.270.1011533005
前述の結果で示すように、データベース名を含むフォルダをOracle ASMで作成した場合、CLONEFILENAME文字列のデータベース名はスナップショットで、SNAPSHOTFILENAME文字列のデータベース名はそのスナップショットのマスターになります。
PDBベースのスナップショットのこの問合せの結果は、次のようになります。
CLONEFILENAME
SNAPSHOTFILENAME
---------------------------------------------------------------------------------
---------------------------------------------------------------------------------
+SPARSEC1/CDB001/8BDBC355D43721F5E053412E850AB5D1/DATAFILE/SYSTEM.256.1011532891
+DATAC1/CDB001/8BDBC355D42D21F5E053412E850AB5D1/DATAFILE/system.270.1011530981
+SPARSEC1/CDB001/8BDBC355D43E21F5E053412E850AB5D1/DATAFILE/SYSTEM.265.1011532969
+DATAC1/CDB001/8BDBC355D42D21F5E053412E850AB5D1/DATAFILE/system.270.1011530981
+SPARSEC1/CDB001/8BDBC355D44021F5E053412E850AB5D1/DATAFILE/SYSTEM.270.1011533005
+SPARSEC1/CDB001/8BDBC355D43721F5E053412E850AB5D1/DATAFILE/system.256.1011532891
+SPARSEC1/CDB001/8BDBC355D44821F5E053412E850AB5D1/DATAFILE/SYSTEM.275.1011780925
+SPARSEC1/CDB001/8BDBC355D43721F5E053412E850AB5D1/DATAFILE/system.256.1011532891
+SPARSEC1/CDB001/8BDBC355D44D21F5E053412E850AB5D1/DATAFILE/SYSTEM.281.1011781103
+SPARSEC1/CDB001/8BDBC355D44021F5E053412E850AB5D1/DATAFILE/system.270.1011533005
この場合、Oracle ASMでのフォルダ名は、PDBに関連付けられたGUIDです。教育スナップショットPDBおよびそのマスターの名前を特定するには、次のことを行う必要があります。
-
結果に表示されている名前(たとえば、
CDB001)が含まれているCDBにログインします。 -
次に示すように、
CDB_PDBSビューに対する問合せを実行して、GUIDをPDB名に変換します。SELECT pdb_name, guid FROM CDB_PDBS WHERE guid IN ('8BDBC355D42D21F5E053412E850AB5D1','8BDBC355D43721F5E053412E850AB5D1' '8BDBC355D44821F5E053412E850AB5D1','8BDBC355D43E21F5E053412E850AB5D1', '8BDBC355D44021F5E053412E850AB5D1','8BDBC355D44D21F5E053412E850AB5D1'); PDB_NAME GUID ----------------------- ----------------------------------- TESTMASTER 8BDBC355D42D21F5E053412E850AB5D1 SNAP001 8BDBC355D43721F5E053412E850AB5D1 SNAP1012 8BDBC355D44821F5E053412E850AB5D1 SNAP02 8BDBC355D43E21F5E053412E850AB5D1 SNAP1011 8BDBC355D44021F5E053412E850AB5D1 SNAP2011 8BDBC355D44D21F5E053412E850AB5D1
次に、この情報を使用して元の問合せ結果のPDB間の親/子関係を特定します。
親トピック: Exadataスナップショットの管理
9.7.10 スパース・コピーの実行
ASM cpコマンドは、スパース・ファイルを新しい宛先にコピーします。ただし、この操作では、すべてのブロックがインスタンス化されているスパース・ファイルが親からコピーされます。スパース・コピー機能を使用すると、ファイルのスパース・コピーを実行できます。
複数のASMインスタンスを同時に実行できます。操作に、操作が実行されている以外の別のASMインスタンスのソースまたは宛先が含まれる場合は、リモートASMインスタンスとして処理されます。スパース・コピーは、ローカルASMインスタンス上、またはローカルASMインスタンスとリモートASMインスタンス間で実行できます。ただし、スパース・コピーは、2つのリモートASMインスタンス間では機能しません。
スパース・コピーを実行するには、既存のASM cpコマンドで新しい--sparseオプションを使用します。構文は次のようになります。
ASMCMD> cp --sparse <src_sparse_file> <tgt_file>
setsparseparentという新しいASMコマンドを使用すると、スパース・ファイルの親を設定できます。ローカルASMインスタンス上のスパース宛先に対するファイルのスパース・コピーを実行すると、その親がスパース・コピー操作の一部として設定されます。ただし、この宛先がリモートASMインスタンスにある場合は、setsparseparentコマンドを使用してその親を明示的に設定する必要があります。
setsparseparentコマンドには、パラメータとしてスパース子ファイルと親ファイルが必要です。これにより、スパース子ファイルの親が新しい親ファイルに設定されます。構文は次のようになります。
ASMCMD> setsparseparent <sparse_file> <parent_file>
cp ASMコマンドは、スパース・コピー操作を実行する前に次の検証を実行します。この操作は、次の基準を満たす場合にのみ許可されます。
-
ソース・ファイルが存在し、これがスパース・ファイルである必要があります。
-
複数のソース・スパース・ファイルを指定する場合は、これらすべてが同じASMインスタンス上に存在する必要があります。
-
リモートASMインスタンス上の複数のスパース・ファイルをローカルASMインスタンス上の宛先にコピーする(その逆も同様)ことは、すべてのソース・ファイルが同じASMインスタンス上にある場合に許可されます。
-
宛先ファイルは、スパース・ディスク・グループでサポートされる必要があります。ただし、イベントKFTST_KFPKG_CP_SPARSEが設定されている場合は、非スパース・ファイルでも構いません。このイベントは、ファイルをスパース以外の宛先にマージしてコピーすることにより、スパース・コピー操作を検証する場合に必要です。
-
リモートASMインスタンスにソースと宛先の両方が存在することはできません。ただし、リモートASMインスタンスにソースまたは宛先のいずれかは存在できます。
-
この宛先がリモートASMインスタンスにある場合、そのファイル・タイプを検証できないため、スパース・ディスク・グループでサポートされていることを確認する必要があります。また、ASM
setsparseparentコマンドを使用して、親を明示的に設定する必要があります。 -
宛先が非スパース・ファイルの場合に、
setsparseparentコマンドを実行すると、子ファイルがスパースである必要があるため、このコマンドは失敗します。宛先が非スパース・ファイルの場合、これは第2レベルの検証です。
setsparseparent ASMコマンドは、親を設定する前に次の検証を実行します。この操作は、次の基準を満たす場合にのみ許可されます。
-
子ファイルが存在し、これがスパース・ファイルである必要があります。
-
親ファイルが存在している必要があります。これは、スパース・ファイルでも非スパース・ファイルでも構いません。
-
親ファイルおよび子ファイルが、同じASMインスタンス上に存在する必要があります。
ノート:
setsparseparent ASMコマンドで指定するファイルに有効な親子関係があることを確認する必要があります。このコマンドは、リモートASMインスタンス上のファイルに対してこのチェックを実行できません。ファイルに有効な親子関係がない場合は、データの整合性および破損の問題が発生する可能性があります。
例1: 次のASMコマンドは、スパース・ファイルTBS_1.264.908376549を宛先+SPARSEDG/child_1にコピーします。
ASMCMD> cp –-sparse +SPARSEDG/MERGE/DATAFILE/TBS_1.264.908376549 +SPARSEDG/child_1
例2: 次のASMコマンドは、スパース・ファイルremote_child_10に親tbs_1.269.908374993を設定します。
ASMCMD> setsparseparent +SPARSEDG/remote_child_10 +DATAFILE/DATAFILE/tbs_1.269.908374993
例3: 次のコマンドは、スパース子ファイルchild_1、child_2およびchild_3を宛先ディレクトリ+SPARSEDGにコピーします。
ASMCMD> cp –-sparse +SPARSEDG/DATAFILE/child_1 +SPARSEDG/DATAFILE/child_2 +SPARSEDG/DATAFILE/child_3 +SPARSEDG/
親トピック: Exadataスナップショットの管理
9.8 スパース・グリッド・ディスクの管理
スパース・グリッド・ディスクのサイズ変更、再作成または活動の監視を行うことができます。
- 仮想領域のサイズ変更
V$ASM_DISKGROUP.FREE_MBまたはV$ASM_DISK.FREE_MBの値が低い場合、仮想アドレス領域を増やす必要があります。 - 物理領域のサイズ変更
- スパース・ディスク・グループの使用率の監視
- スパース・グリッド・ディスクの再利用
スパース・グリッド・ディスクを通常のグリッド・ディスクに変更できます。
9.8.1 仮想領域のサイズ変更
V$ASM_DISKGROUP.FREE_MBまたはV$ASM_DISK.FREE_MBの値が低い場合、仮想アドレス領域を増やす必要があります。
- 仮想アドレス領域のサイズを増やすには:
- 仮想アドレス領域のサイズを減らすには:
9.8.2 物理領域のサイズ変更
Oracle Exadata System Software 22.1.0以降では、sizeAllocatedグリッド・ディスク属性を使用して、スパース・グリッド・ディスク内のデータによって使用されるマテリアライズド領域の合計サイズを決定できます。sizeAllocatedが物理グリッド・ディスク・サイズに近づいたら、さらなるデータの増加をサポートするために物理グリッド・ディスク・サイズを大きくする必要があります。
そうしない場合は、V$ASM_DISK_SPARSE内のTOTAL_MAT_MB列値とALLOCATED_MAT_MB列値の差異を調べることで、スパース・グリッド・ディスク内の使用可能な物理領域の容量を確認できます。
グリッド・ディスクの物理サイズを大きくするには:
-
それぞれのセル・ディスク上に使用可能な空き領域があることを確認します。
たとえば:
# dcli -g cell_group -l root "cellcli -e list celldisk attributes name,freespace" exa01celadm01: CD_00_exa01celadm01 0 exa01celadm01: CD_01_exa01celadm01 0 exa01celadm01: CD_02_exa01celadm01 0 exa01celadm01: CD_03_exa01celadm01 0 exa01celadm01: CD_04_exa01celadm01 0 exa01celadm01: CD_05_exa01celadm01 0 exa01celadm01: CD_06_exa01celadm01 0 exa01celadm01: CD_07_exa01celadm01 0 exa01celadm01: CD_08_exa01celadm01 0 exa01celadm01: CD_09_exa01celadm01 0 exa01celadm01: CD_10_exa01celadm01 0 exa01celadm01: CD_11_exa01celadm01 0 ...使用可能な空き領域がない場合は、他のグリッド・ディスクのサイズを小さくするか不要なグリッド・ディスクを削除することで、他のグリッド・ディスクによって使用されているディスク領域を解放する必要があります。
-
サイズを変更するグリッド・ディスク、および各グリッド・ディスクの新しい物理サイズを指定して、セルで
ALTER GRIDDISKコマンドを実行します。コマンドの構文は次のようになります。
CellCLI> alter griddisk gridDisk1,gridDisk2,...,gridDiskN size=newPhysicalSize各セルでこのコマンドを実行します。
たとえば、最初のセルでは、次のようにします。
CellCLI> alter griddisk data01_CD_00_exa01celadm01,data01_CD_01_exa01celadm01, data01_CD_02_exa01celadm01,data01_CD_03_exa01celadm01,data01_CD_04_exa01celadm01, data01_CD_05_exa01celadm01,data01_CD_06_exa01celadm01,data01_CD_07_exa01celadm01, data01_CD_08_exa01celadm01,data01_CD_09_exa01celadm01,data01_CD_10_exa01celadm01, data01_CD_11_exa01celadm01 size=12000Gその後、次のセルで実行します。
CellCLI> alter griddisk data01_CD_00_exa01celadm02,data01_CD_01_exa01celadm02, data01_CD_02_exa01celadm02,data01_CD_03_exa01celadm02,data01_CD_04_exa01celadm02, data01_CD_05_exa01celadm02,data01_CD_06_exa01celadm02,data01_CD_07_exa01celadm02, data01_CD_08_exa01celadm02,data01_CD_09_exa01celadm02,data01_CD_10_exa01celadm02, data01_CD_11_exa01celadm02 size=12000Gこのように続きます。
グリッド・ディスクの物理サイズを大きくした後は、スパース・ディスク・グループによって、必要に応じて自動的にさらに多くの領域が使用されます。
グリッド・ディスクの物理サイズを小さくするには:
-
スパース・グリッド・ディスク内のデータによって使用されているマテリアライズド領域の量を確認します。グリッド・ディスクのサイズを現在のマテリアライズド・データ量より小さくすることはできません。
Oracle Exadata System Software 22.1.0以降では、
sizeAllocatedグリッド・ディスク属性を確認します。たとえば:
# dcli -g cell_group -l root "cellcli -e list griddisk attributes name,sizeAllocated" exa01celadm01: data01_CD_00_exa01celadm01 1023.9375M exa01celadm01: data01_CD_01_exa01celadm01 1024.4375M exa01celadm01: data01_CD_02_exa01celadm01 1023.4375M exa01celadm01: data01_CD_03_exa01celadm01 1024.9375M exa01celadm01: data01_CD_04_exa01celadm01 1023.9375M exa01celadm01: data01_CD_05_exa01celadm01 1024.4375M exa01celadm01: data01_CD_06_exa01celadm01 1023.4375M exa01celadm01: data01_CD_07_exa01celadm01 1024.9375M exa01celadm01: data01_CD_08_exa01celadm01 1023.9375M exa01celadm01: data01_CD_09_exa01celadm01 1024.4375M exa01celadm01: data01_CD_10_exa01celadm01 1023.4375M exa01celadm01: data01_CD_11_exa01celadm01 1024.9375M ...それ以外の場合は、
V$ASM_DISK_SPARSE内のALLOCATED_MAT_MB列値を調べます。たとえば:SQL> SELECT allocated_mat_mb FROM v$asm_disk_sparse WHERE group_number = spare_disk_group_number;グリッド・ディスクを縮小して現在のマテリアライズド・データ量より小さくする必要がある場合は、スパース・ディスク・グループからオブジェクトを削除する必要があります。
-
縮小するグリッド・ディスク、および各グリッド・ディスクの新しい物理サイズを指定して、セルで
ALTER GRIDDISKコマンドを実行します。コマンド構文は、グリッド・ディスク・サイズを大きくする場合と同じです。
CellCLI> alter griddisk gridDisk1,gridDisk2,...,gridDiskN size=newPhysicalSize各セルでこのコマンドを実行します。
たとえば、最初のセルでは、次のようにします。
CellCLI> alter griddisk data01_CD_00_exa01celadm01,data01_CD_01_exa01celadm01, data01_CD_02_exa01celadm01,data01_CD_03_exa01celadm01,data01_CD_04_exa01celadm01, data01_CD_05_exa01celadm01,data01_CD_06_exa01celadm01,data01_CD_07_exa01celadm01, data01_CD_08_exa01celadm01,data01_CD_09_exa01celadm01,data01_CD_10_exa01celadm01, data01_CD_11_exa01celadm01 size=4000Gその後、次のセルで実行します。
CellCLI> alter griddisk data01_CD_00_exa01celadm02,data01_CD_01_exa01celadm02, data01_CD_02_exa01celadm02,data01_CD_03_exa01celadm02,data01_CD_04_exa01celadm02, data01_CD_05_exa01celadm02,data01_CD_06_exa01celadm02,data01_CD_07_exa01celadm02, data01_CD_08_exa01celadm02,data01_CD_09_exa01celadm02,data01_CD_10_exa01celadm02, data01_CD_11_exa01celadm02 size=4000Gこのように続きます。
関連項目
親トピック: スパース・グリッド・ディスクの管理
9.8.3 スパース・ディスク・グループの使用率の監視
V$ASM_DISKビューおよびV$ASM_DISKGROUPビューには、仮想サイズとスパースASMディスク・グループの使用率に関する情報が含まれます。新しいビューV$ASM_DISK_SPARSEおよびV$ASM_DISKGROUP_SPARSEには、スパースASMディスク・グループの実際のサイズと使用率に関する情報が含まれます。V$ASM_DISK_SPARSEにもパフォーマンスと使用率のメトリックが含まれます。
次の表に、V$ASM_DISK_SPARSEの各列についての説明を示します。
表9-1 V$ASM_DISK_SPARSEの列および説明
| 列 | 説明 |
|---|---|
|
|
ディスクを含むディスク・グループの番号。 |
|
|
このディスク・グループ内のディスクに割り当てられた番号。 |
|
|
ディスクのインカネーション番号。 |
|
|
ディスク上の使用済物理容量およびマテリアライズド容量の合計。 |
|
|
ディスク上の物理容量の合計。 |
|
|
ディスクの非マテリアライズド・リージョンのI/O読取りリクエストの合計。 |
|
|
ディスクの非マテリアライズド・リージョンから読み取ったバイト数の合計。 |
|
|
スパース読取りI/O操作にかかった時間。 |
次の表に、V$ASM_DISKGROUP_SPARSEの各列についての説明を示します。
表9-2 V$ASM_DISKGROUP_SPARSEの列および説明
| 列 | 説明 |
|---|---|
|
|
ディスク・グループに割り当てられたクラスタ全体の番号。 |
|
|
ディスク・グループの使用済物理容量およびマテリアライズド容量の合計。 |
|
|
ディスク・グループの物理容量の合計。 |
次の例は、特定のディスク・グループの使用済(割当て済)領域とディスクの合計領域を示しています。
SQL> select
DISK_NUMBER dsk_num,
ALLOCATED_MAT_MB alloc,
TOTAL_MAT_MB total
from V$ASM_DISK_SPARSE
where GROUP_NUMBER = 5;
DSK_NUM ALLOC TOTAL
---------- ---------- ----------
0 5536 57336
1 5424 57336
2 5532 57336
3 5424 57336
4 5424 57336
次の例のスパースASMグリッド・ディスクは、実際のサイズが56GB、仮想サイズが560GBで作成されています。V$ASM_DISKのOS_MB列とTOTAL_MB列を問い合せると、仮想サイズが573440MB (573440MB / 1024 = 560GB) と表示されます。
SQL> select os_mb, total_mb from v$asm_disk where group_number=4;
OS_MB TOTAL_MB
---------- ----------
573440 573440
573440 573440
573440 573440
V$ASM_DISK_SPARSEのTOTAL_MBを問い合せると、ASMグリッド・ディスクで使用可能な実際のサイズを確認できます。各ASMグリッド・ディスクには、スパースASMグリッド・ディスクに割り当てられている16GBごとに約2MBのメタデータ情報が格納されることに注意してください。この例ではグリッド・ディスク当たり56GBが割り当てられ、8MBの領域がスパース・ディスク・メタデータ用に確保されます(57336MB + 8MB = 57344MB / 1024 = 56GB)。
SQL> select total_mb from v$asm_disk_sparse where group_number=4; TOTAL_MB --------- 57336 57336 57336
親トピック: スパース・グリッド・ディスクの管理
9.8.4 スパース・グリッド・ディスクの再利用
スパース・グリッド・ディスクを通常のグリッド・ディスクに変更できます。
関連項目
親トピック: スパース・グリッド・ディスクの管理
9.9 データベース統計および待機イベントを使用したExadataスナップショットの監視
次の表では、Exadataスナップショットの監視に役立つデータベース固有の統計について説明します。これらの統計は、V$SYSSTATなどの様々な動的パフォーマンス・ビューで使用でき、AWRレポートのグローバル・アクティビティ統計セクションまたはインスタンス・アクティビティ統計セクションに表示されます。
| 統計 | 説明 |
|---|---|
physical read snap IO requests base |
親ファイルまたはベース・ファイルでの物理I/Oの数。 |
physical read snap IO requests copy |
スナップショット・ファイルでの物理I/Oの数。 |
physical read snap bytes base |
親ファイルまたはベース・ファイルから読み取られるバイト数 |
physical read snap bytes copy |
スナップショット・ファイルから読み取られるバイト数。 |
physical read snap IO requests new allocation |
スナップショット・ファイルでの新規割当ての数。 |
physical read snap IO requests no data |
子ファイル・レベルで物理I/Oが行われない物理読取りI/Oリクエストの数。 |
次の表では、Exadataスナップショットの監視に役立つ特定のデータベース待機イベントについて説明します。待機イベントは、V$SESSION、V$SYSTEM_EVENT、V$SESSION_EVENTなどの様々な動的パフォーマンス・ビューに表示され、AWRレポートの待機イベント・セクションに表示されることがあります。
| 待機イベント | 説明 |
|---|---|
cell physical read no I/O |
待機イベントは、スパース・ディスク・グループからの読取りが行われ、データが返されなかった場合に表示されます。 |
特定の統計または待機イベントの可用性は、使用しているOracle Databaseのバージョンによって決まります。