9 Oracle Exadata Storageスナップショットの設定
Exadataスナップショットは、Oracleデータベースに対してスペース効率に優れた読取り専用クローンまたは読取り/書込みクローンを作成する理想的な方法です。このようなクローンは、開発やテストまたはその他の本番以外の目的で使用できます。
- Exadataスナップショットの概要
- Exadataスナップショット・データベースの前提条件
Exadataスナップショット・データベースを作成する前に、環境がこれらの要件を満たしていることを確認します。 - Exadataスナップショットの概念
Exadataスナップショットを作成および使用する際に必要となる様々なオブジェクトがあります。 - スパース・ディスクのサイズ変更および割当てメソドロジ
Exadataスナップショットを作成するには、スパース・グリッド・ディスクをそれらのディスクに基づいて作成されたOracle ASMディスク・グループで作成する必要があります。 - リフレッシュの考慮事項(Exadataスナップショットのライフサイクル)
リフレッシュ・サイクルが、Exadataスナップショットの使用および作成方法に影響することがあります。 - テスト・マスターとしてのOracle Data Guardスタンバイ・データベースの使用
テスト・マスターが非コンテナ・データベースか、定期的にリフレッシュが必要なフルCDBである場合(つまり、テスト・マスターがPDBでない場合)、テスト・マスター・データベースを、その目的専用のOracle Data Guard物理スタンバイとして作成することをお薦めします。 - Exadataスナップショットの管理
Exadataスナップショットを作成および管理するには、次の手順を実行する必要があります。 - スパース・グリッド・ディスクの管理
スパース・グリッド・ディスクのサイズ変更、再作成または活動の監視を行うことができます。
9.1 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スナップショットによって、Oracle Exadata Database Machineでコスト効果の高い開発環境や品質が保証されたテスト環境が実現します。 - テスト/開発環境と本番環境の分離
テスト環境と開発環境は、本番データベースをホストするExadataラックとは別の物理Oracle Exadataラックでホストすることをお薦めします。 - Exadataスナップショットのタイプ
ご使用の環境の現在の設定に応じて、2種類のExadataスナップショットを作成できます。 - 階層型スナップショット・データベース
階層型スナップショットを使用すると、他のスナップショット・データベースからスナップショット・データベースを作成できます。 - スパース・テスト・マスター
階層型スナップショットの導入に伴い、スパース・テスト・マスターを作成できるようになりました。
9.1.1 Exadata機能のExadataスナップショットサポート
領域と時間の節約に加えて、Exadataスナップショットによって、Oracle Exadata Database Machineでコスト効果の高い開発環境や品質が保証されたテスト環境が実現します。
Exadataスナップショットは、機能の検証を必要とする開発者およびテスト担当者が使用できます。Exadataスナップショットを使用して、完全に機能するExadata環境(Exadataスマート・フラッシュ・キャッシュ、Exadataスマート・スキャンのオフロードおよびExadataハイブリッド列圧縮など)で保守および運用ステップを実行することもできます。
親トピック: Exadataスナップショットの概要
9.1.2 テスト/開発環境と本番環境の分離
テスト環境と開発環境は、本番データベースをホストするExadataラックとは別の物理Oracle Exadataラックでホストすることをお薦めします。
開発とテスト専用のOracle Exadata Database Machineシステムが理想です。テスト・マスターとそれに対応するExadataスナップショットをこのシステムでホストします。あるいは、容量が許す場合は、高可用性、障害時リカバリなどのためのOracle Data Guardスタンバイ・データベースをホストするOracle Exadata Database Machineシステムを使用することもできます。テスト・マスターとそれに対応するスナップショットは、Oracle Exadata Database Machineシステム上の物理マシンまたは仮想マシンに配置できます。
関連項目
親トピック: Exadataスナップショットの概要
9.1.3 Exadataスナップショットのタイプ
ご使用の環境の現在の設定に応じて、2種類のExadataスナップショットを作成できます。
-
プラガブル・データベース(PDB)からのテスト・マスター。
コンテナ・データベース(CDB)内の個々のPDBからExadataスナップショットPDBを作成できます。個々のPDBをクローニングしてテスト・マスターPDBを作成し、そこからExadataスナップショットPDBを生成できます。
同一のExadataクラスタ内で、あるCDBから別のCDBへExadataスナップショットPDBを移動できます。また、2つのCDBが同じExadataクラスタにある場合、1つのコンテナに存在するテスト・マスターPDBから、もう1つのコンテナにExadataスナップショットPDBを作成することもできます。
テスト・マスター・データベースと対応するExadataスナップショットは、同じOracle Automatic Storage Management (Oracle ASM)クラスタ環境に存在する必要があります。
次の図に、3つのPDBを含む本番CDBを示します。PDBのうち2つ(PDB1とPDB2)はクローニングされて、テスト・マスターPDBが作成されています。これらは、アンプラグされてからテストOracle Exadata Database Machineの別のCDBにプラグされました。この図では、6個のExadataスナップショットPDBがテスト・マスターPDBから作成されています。
-
コンテナ・データベース以外からのテスト・マスター
Exadataスナップショット・データベースは、非コンテナ・データベース(非CDB)にすることができます。
次の図は、本番データベースのフル・クローンです。クローン(つまりテスト・マスター・データベース)は、別のテスト/開発環境でホストされ、6個のExadataスナップショットが関連付けられています。テスト・マスター・データベースは、Oracle Data Guardスタンバイ・データベース(テスト・マスターを定期的にリフレッシュする場合に推奨)またはOracle Recovery Manager (RMAN)を使用して作成されます。
テスト・マスター・データベースと対応するExadataスナップショットは、同じOracle ASMクラスタ環境に存在する必要があります。
親トピック: Exadataスナップショットの概要
9.1.4 階層型スナップショット・データベース
階層型スナップショットを使用すると、他のスナップショット・データベースからスナップショット・データベースを作成できます。
Oracle Exadata System Softwareリリース12.2.1.1.0では、階層型スナップショットが導入されました。スナップショット・データベースで作業しているときに、コピーを保存してから追加変更を加える場合に、階層型スナップショットを使用することがあります。スナップショット・データベースのレベルは希望する数だけ作成できますが、パフォーマンス上の理由により10レベルに制限することがあります。
スナップショット・データベースは、データのその親のブロックを指します。スナップショット・データベースに変更を加えると、スナップショット・データベースは変更されたデータに新しいブロックを割り当てます。データが変更されていない場合、スナップショットは親のブロックを指します。元のテスト・マスターから枝分かれした複数のレベルのスナップショットは、作成元のスナップショット・データベースを起点としたツリーを上に移動して、そのデータを取得します。
別のスナップショット・データベースからスナップショット・データベースを取得して、親スナップショット・データベースに変更を加える場合は、そのスナップショット・データベースに依存するすべてのスナップショット・データベースを削除する必要があります。子スナップショットが親スナップショットから作成されると、親スナップショット・データベースは読取り専用になります。親スナップショットに再度書き込む場合は、すべての子スナップショットを削除する必要があります。
親トピック: Exadataスナップショットの概要
9.1.5 スパース・テスト・マスター
階層型スナップショットの導入に伴い、スパース・テスト・マスターを作成できるようになりました。
階層型スナップショット・データベースでは、スパース・テスト・マスターを作成できます。スパース・テスト・マスターは、データをフル・コピーしたものであり、複数のレベルのスナップショットに親ファイル・データを提供します。スナップショットを作成する準備ができたら、スパース・ファイルの追加セットを作成し、Oracle Data Guardなどのレプリケーション技術を使用して本番データベースから更新を受信します。現在のデータの新しいテスト・マスターを作成する必要がある場合は、その新しい時点で再度完全な本番データベースをクローニングするのではなく、以前の追加のスパース・ファイルを読取り専用とマークしてスパース・テスト・マスターを作成し、最新の状態の新しいスパース・ファイルのセットを作成します。このスパース・テスト・マスターに追加のスナップショットを作成して、アプリケーション開発者がテスト用に使用できるようにすることができます。本番データベースの1つのフル・コピーで複数の時点のスナップショットをサポートできるように、このプロセスを合計9回まで繰り返すことができます。 新しいスパース・テスト・マスターは短時間(5分以内)で作成できるため、本番にあわせて簡単に最新に保つことができます。
スパース・テスト・マスター・データベースTMは、コンテナ・データベース(CDB)以外のデータベースに適用されます。
9.2 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以降が必要です。
関連項目
9.3 Exadataスナップショットの概念
Exadataスナップショットを作成および使用する際に必要となる様々なオブジェクトがあります。
- スパース・データベースおよびスパース・ファイル
Exadataスナップショット・データベースのようなスパース・データベースでは、データ・ファイルはスパース・ファイルです。 - スパース・グリッド・ディスク
スパース・グリッド・ディスクには仮想サイズ属性と物理サイズ属性があります。 - スパース・ディスク・グループ
Exadataスナップショットでは、Oracle ASMスパース・ディスク・グループが使用されます。
9.3.1 スパース・データベースおよびスパース・ファイル
Exadataスナップショット・データベースのようなスパース・データベースでは、データ・ファイルはスパース・ファイルです。
データベースは次のファイルで構成されます。
- 制御ファイル
- オンラインREDOログ
- 一時ファイル
- データ・ファイル
スパース・ファイルは、親ファイルのブロックに対する変更のみを含み(親ファイルは変更されません)、未変更データにアクセスするために親ファイルへのポインタを保持します。
Exadataスナップショットは、他のデータベース・ファイル(制御ファイル、オンラインREDOログおよび一時ファイル)のコピーを含みます。このような他のデータベース・ファイルはスパース・ファイルではありません。
関連項目
親トピック: Exadataスナップショットの概念
9.3.2 スパース・グリッド・ディスク
スパース・グリッド・ディスクには仮想サイズ属性と物理サイズ属性があります。
スパースOracle ASMディスク・グループはスパース・グリッド・ディスクで構成されます。
単一のセル・ディスクからスパース・グリッド・ディスクに割り当てることのできる最大物理サイズは4TBです。最大仮想サイズは100TBです。
スパース・グリッド・ディスクを作成してからスパースOracle ASMディスク・グループを作成します。新しいシステムをデプロイしている場合、または既存のシステムを再デプロイしている場合は、他のディスク・グループのケースと同様に、各セル・ディスクの領域の一部をディスク・グループ用に確保します。
再イメージ化せずに既存のシステムを使用する場合は、既存のグリッド・ディスクのサイズ変更の方法について、My Oracle Supportノート1467056.1を参照してください。
9.3.3 スパース・ディスク・グループ
Exadataスナップショットでは、Oracle ASMスパース・ディスク・グループが使用されます。
スパース・データ・ファイルは、Oracle Automatic Storage Management (Oracle ASM)のスパース・ディスク・グループにのみ作成できます。次の図に、3つのExadataスナップショットを含むスパース・ディスク・グループを示します。
スパースOracle ASMディスク・グループは、スパース・ファイルと非スパース・ファイルを格納できます。スパースOracle ASMディスク・グループにすべてのデータベース・オブジェクトを作成できます。たとえば、Exadataスナップショットを含むスパースOracle ASMディスク・グループにテスト・マスター・データベースを作成できます。テスト・マスターはソース・データベースのフル・コピーであるため、領域は節約されないことに注意してください。
スパース・ディスク・グループには次の属性があります。
compatible.asmは12.1.0.2以上に設定する必要があります。compatible.rdbmsは12.1.0.2以上に設定する必要があります。cell.sparse_dgはallsparseに設定する必要があります。これは、ディスク・グループがスパース・グリッド・ディスクで構成されていることをOracle ASMに示します。appliance.modeはtrueに設定する必要があります。- スパース・ディスク・グループは、エクステントの16倍のサイズを使用します。4Mの割当て単位(AU)では、各エクステントは64Mになります。
- スパース・ディスク・グループは仮想割当てメタデータを使用します。
たとえば、次の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';
親トピック: Exadataスナップショットの概念
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スタンバイ・データベースの使用
テスト・マスターが非コンテナ・データベースか、定期的にリフレッシュが必要なフルCDBである場合(つまり、テスト・マスターがPDBでない場合)、テスト・マスター・データベースを、その目的専用の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バックアップ/リストアやデータ・ポンプなど、データベースのフル・クローンの作成に一般的に使用される方法を使用します。
フル・クローンを作成したら、すべてのデータ・ファイルの書込み権限を削除して、誤って上書きされることを防ぎます。
ファイル権限を読取り専用に設定できるのはASMインスタンスでのSQLコマンドのみです。SQLでは書込み権限を削除できません。
SQL> ALTER DISKGROUP DATA set permission 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スナップショットPDB、後者はスナップショット・データベース(非CDBのみ)です。
- プラガブル・データベースのスナップショットの作成
- フル・データベースのスナップショットの作成
テスト・マスター・データベースが非CDBの場合は、フル・データベースのExadataスナップショットを作成します。
親トピック: Exadataスナップショットの管理
9.7.4.1 プラガブル・データベースのスナップショットの作成
プラガブル・データベース(PDB)のExadataスナップショットの作成は、手動のステップを加える必要がないため、スナップショットの作成の中で最も単純です。CREATE PLUGGABLE DATABASE文に、PDBをExadataスナップショットとして指定する2つの句が新たに追加されました。スナップショット作成プロセスにより、テスト・マスターPDBのファイルが修正されないように、ファイルに対する権限がREADONLYに変更されます。
個々のExadataスナップショットPDBの作成は、指定のCDB内のPDB数が少ない場合にスナップショットを作成するときに最適です。次の図に、2つのPDBスナップショットがあるPDBの典型的なライフサイクルの概要を例として示します。
OracleのマルチテナントとPDBのメリットの1つは、既存のPDBのクローンを容易にクローニングしてテスト・マスターを作成し、あるCDBから別のCDBに移動できることです。ソースPDBをクローニングしてテスト・マスターを作成し、必要なデータ修正を実行できるテスト環境にテスト・マスターを移行することをお薦めします。これが完了したら、テスト・マスターPDBを使用してExadataスナップショットPDBをいくつでも作成できます。
注意: ExadataスナップショットPDBはCDB内のPDBとして作成されます。1つのCDB内のPDBの合計数は252に制限されます。CDB内のPDBはすべて(テスト・マスター、スナップショット、またはスナップショットに使用されていないPDBのいずれでも)、この制限に含まれます。1つのCDBの制限を超えてPDBを作成する必要がある場合は、同じクラスタ上の別のCDBにExadataスナップショットPDBを作成できます。
テスト・マスターPDBを作成した後で、次のステップを実行してExadataスナップショットPDBを作成します。
9.7.4.2 フル・データベースのスナップショットの作成
テスト・マスター・データベースが非CDBの場合は、フル・データベースのExadataスナップショットを作成します。
次の図は、Exadataテスト・マスター・データベースおよびスナップショット・データベースのライフサイクルを示しています。
テスト・マスター・データベースは、高可用性または障害時リカバリを提供するフェイルオーバー・ターゲットとして使用できないことに注意してください(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つのフル・コピーを使用して、様々な時点の複数のテスト・マスターとして使用できます。また、既存のスナップショットを削除する必要がないため、新しいテスト・マスターを短時間で作成することもできます。
制限事項
このプロセスは、非コンテナ・データベースでのみ使用できます。
次のタスクは、フィジカル・スタンバイ・データベースがすでに作成されていて、テスト・マスターのソースとして使用することを前提としています。
- タスク1: スタンバイ・データベースをスパース・テスト・マスターとして使用するための準備
- タスク2: スタンバイ・サイトでのスパース・テスト・マスターおよびスパース・ファイルの構成
このタスクでは、スタンバイをテスト・マスターに変換し、スパース・ファイルを作成して、プライマリ・データベースからREDOを受信して適用します。 - タスク3: 新しいスパース・テスト・マスターを使用したフル・データベース・スナップショットの作成
新しいスパース・テスト・マスターを使用してフル・スナップショットを作成します。 - タスク4:以前に作成したスパース・テスト・マスターを使用した新しいスパース・テスト・マスターの作成
新しいテスト・マスターおよび新しいREDO適用ファイルを提供するために新しいスナップショットのセットを作成します。
親トピック: Exadataスナップショットの管理
9.7.7.1 タスク1: スタンバイ・データベースをスパース・テスト・マスターとして使用するための準備
スタンバイ・データベースの既存のファイルは、スナップショットのサポートに使用されます。スタンバイの既存のファイルを指す一連のスパース・ファイルを作成します。プライマリ・データベースから受信したREDOが、これらのファイルに適用されます。これらのスパース・ファイルにより、スタンバイ・データベースをスパース・テスト・マスターとして使用できるようになり、また、プライマリ・データベースを最新に保つことができます。
9.7.7.2 タスク2: スタンバイ・サイトでのスパース・テスト・マスターおよびスパース・ファイルの構成
このタスクでは、スタンバイをテスト・マスターに変換し、スパース・ファイルを作成して、プライマリ・データベースからREDOを受信して適用します。
注意:
このプロセスでは、フル・スナップショット・データベースを作成せず、既存のスタンバイ・データベースの一部を使用して、スタンバイにスパース・データ・ファイルを追加します。スタンバイ・データベースの制御ファイルは、追加されるスパース・ファイルを使用するために変更されます。今後は、同じスタンバイ・インスタンスが使用されますが、REDO適用ではスパース・ファイルを使用して変更を格納し、スナップショットのスパース・テスト・マスター・ファイルとして機能する元のスタンバイ・データ・ファイルはそのままにします。既存のデータ・ファイルを使用して、プロセスが実行された時点のデータでフル・データベース・スナップショットをサポートします。
9.7.7.3 タスク3: 新しいスパース・テスト・マスターを使用したフル・データベース・スナップショットの作成
新しいスパース・テスト・マスターを使用して、フル・スナップショットを作成します。
タスク1: スタンバイ・データベースをスパース・テスト・マスターとして使用するための準備のステップ2で作成したバックアップ制御ファイルを使用して、CREATE CONTROLFILE文を作成する必要があります。このファイルを使用するには、一時データベース・インスタンスを作成して制御ファイルをマウントし、バックアップ制御ファイルを実行してコマンドをトレースします。
9.7.7.4 タスク4: 以前に作成したスパース・テスト・マスターを使用した新しいスパース・テスト・マスターの作成
新しいテスト・マスターおよび新しいREDO適用ファイルを提供するために新しいスナップショットのセットを作成します。
テスト・マスターの完全なコピーを作成することなく、定期的にスタンバイ・データベースを使用して追加のスナップショットを作成できます。階層型スナップショット機能を利用して、前の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が親として使用されています。よって、Jimが自分のスナップショット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 スパース・コピーの実行
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 物理領域のサイズ変更
グリッド・ディスクが物理領域外で動作している場合は、グリッド・ディスクの物理サイズを増やす必要があります。
V$ASM_DISK_SPARSEのTOTAL_MAT_MBおよびALLOCATED_MAT_MB列の値を比較して、残りの物理領域の容量を確認できます。これら2つの列の値が近い場合は、グリッド・ディスクの物理サイズを増やす必要があります。
- ディスクの物理領域のサイズを増やす手順:
- ディスクの物理領域のサイズを減らす手順:
関連項目
親トピック: スパース・グリッド・ディスクの管理
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にかかった時間 |
次の表に、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 スパース・グリッド・ディスクの再利用
スパース・グリッド・ディスクを通常のグリッド・ディスクに変更できます。
関連項目
親トピック: スパース・グリッド・ディスクの管理