| Oracle® Exadata Storage Server Softwareユーザーズ・ガイド 12cリリース2 (12.2) E84909-03 |
|
 前 |
 次 |
この章のトピックは、次のとおりです:
従来は、本番システムのデータベースをクローニングするには、Exadata以外のシステムにテスト・マスターとスナップショット・データベースを作成しました(図10-1)。場合によっては、これらのデータベースはソースのフル・コピーで、ソースと同じ容量のストレージが消費されます(図10-2)。
クローンが本番データベースのフル・コピーである場合、消費されるストレージ容量およびクローンの作成にかかる時間に関してコストが高くなります。数TBのデータベースのクローンを10個作成するケースを想像してみると、このアプローチが発展しない理由をすぐに理解できます。
このアプローチのもう1つのデメリットは、Exadata以外のシステムでOracle Exadata Storage Server Softwareの機能(スマート・スキャン、スマート・ロギング、スマート・フラッシュなど)が使用できないことです。
このような問題を解決するために、Exadataスナップショットを使用できます。Exadataスナップショットは、Oracleデータベースに対してスペース効率に優れた読取り専用クローンまたは読取り/書込みクローンを作成する理想的な方法です。このようなクローンは、開発やテストまたはその他の本番以外の目的で使用できます。また、複数のクローンが必要な場合にディスク領域や時間を節約することができます。次の図は、Exadataスナップショットで必要な領域を示します。
注意:
Exadataスナップショットは、開発およびテスト用にのみ使用してください。本番環境ではそれらを使用しないようにしてください。
Exadataスナップショットは、ソース・データベースのフル・クローンであるテスト・マスターに基づいています。テスト・マスターはソース・データベースをフル・コピーしたものです。1つのテスト・マスターから複数のExadataスナップショットを作成することができ、追加ストレージと作業は最小限に抑えられます。各Exadataスナップショットで使用されるのはテスト・マスター用に必要な小容量のディスク領域のみで、スナップショットの作成も削除も数秒で行うことができます。各Exadataスナップショットはテスト・マスターの論理コピーです。
テスト・マスターからExadataスナップショットを作成する前に、必要であればテスト・マスターのデータを変更できます。たとえば、テスト・マスターの機密データを削除またはマスクしてから、権限を持たないユーザーがテスト・マスターを使用できるようにします。
テスト・マスターからのExadataスナップショットの作成は、子ファイルのヘッダーに親ファイル名を記録することにより行えます。この操作は数秒で完了し、必要なディスク領域も最小限です。追加のディスク領域が消費されるのは、スナップショットのユーザーがデータの変更を開始したときのみです。新しいデータのみがデータ・ブロックに書き込まれますが、そのデータ・ブロックは書込み時にスナップショットに割り当てられるものです。変更されていないデータに対するリクエストはすべて、テスト・マスターのデータ・ブロックによって処理されます。
複数のユーザーが、同じテスト・マスターから別々のスナップショットを作成することもできます。これにより、複数の開発環境およびテスト環境が、各ユーザー用のデータベースを別々に維持しつつ、領域を共有することができます。次の図は、同じテスト・マスターを使用する3つのExadataスナップショットがあるExadata環境です。
階層型スナップショットおよび読取り-書込みスナップショット
Oracle Exadataリリース12.2.1.1.0では、階層型スナップショットおよび読取り-書込みスナップショットが導入されました。階層型スナップショットを使用すると、スナップショットからスナップショットを作成できます。スナップショットで作業しているときに、コピーを保存してから追加変更を加えたい場合に、これを行うことがあります。階層型スナップショットでは、テスト・マスターから枝分かれしたどのレベルでもスナップショットを作成できます。スナップショットは書込み可能です。スナップショットは、データの親のブロックを指します。スナップショットを編集すると、スナップショットは新しいデータを指すようになります。データが変更されていない場合は、親のブロックを指します。
スナップショットからスナップショットを取得して、親スナップショットを編集する場合は、そのスナップショットに依存するすべてのスナップショットを削除する必要があります。
領域と時間の節約に加えて、Exadataスナップショットによって、Exadataでコスト効果の高い開発環境や品質が保証されたテスト環境が実現します。Exadataスナップショットは、完全に稼働するExadata環境(たとえば、Exadataスマート・フラッシュ、スマート・スキャン、ハイブリッド列圧縮など)において、機能の検証や保守および運用手順の実行を行う必要がある開発者およびテスト担当者が使用できます。
テスト環境と開発環境は、本番データベースをホストするExadataラックとは別の物理Exadataラックでホストすることをお薦めします(図10-5および図10-6を参照)。開発とテスト専用のExadataシステムが理想です。テスト・マスターとそれに対応するExadataスナップショットをこのシステムでホストします。あるいは、容量が許す場合は、高可用性、障害時リカバリなどのためのData Guardスタンバイ・データベースをホストするExadataシステムを使用することもできます。テスト・マスターとそれに対応するスナップショットは、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スナップショットは、同じASMクラスタ環境に存在する必要があります。
次の図に、3つのPDBを含む本番CDBを示します。PDBのうち2つ(PDB1とPDB2)はクローニングされて、テスト・マスターPDBが作成されています。これらは、アンプラグされてからテストExadataシステムの別のCDBにプラグされました。この図では、6個のExadataスナップショットPDBがテスト・マスターPDBから作成されています。
1つのコンテナ・データベース(CDB)があり、すべてのPDBからテスト・マスターを作成します。または、コンテナではない単純なデータベースがあり、そのデータベースからテスト・マスターを作成します。
Exadataスナップショット・データベースは、非コンテナ・データベース(非CDB)またはコンテナ・データベース(CDB)のどちらにもすることができます。CDBのExadataスナップショット・データベースを作成すると、そのコンテナ内のすべてのプラガブル・データベースにアクセスできます。
次の図は、本番データベースのフル・クローンです。クローン(つまりテスト・マスター・データベース)は、別のテスト/開発環境でホストされ、6個のExadataスナップショットが関連付けられています。
テスト・マスター・データベースは、Data Guardスタンバイ・データベース(テスト・マスターを定期的にリフレッシュする場合に推奨)またはRMANを使用して作成されます。
テスト・マスター・データベースと対応するExadataスナップショットは、同じASMクラスタ環境に存在する必要があります。
Oracle Exadataリリース12.2.1.1.0では、階層型スナップショットが導入されました。階層型スナップショットを使用すると、他のスナップショット・データベースからスナップショット・データベースを作成できます。スナップショット・データベースで作業しているときに、コピーを保存してから追加変更を加える場合に、これを行うことがあります。スナップショット・データベースのレベルは希望する数だけ作成できますが、パフォーマンス上の理由により10レベルに制限することがあります。
スナップショット・データベースは、データのその親のブロックを指します。スナップショット・データベースに変更を加えると、スナップショット・データベースは変更されたデータに新しいブロックを割り当てます。データが変更されていない場合は、親のブロックを指します。元のテスト・マスターから枝分かれした複数のレベルのスナップショットは、作成元のスナップショット・データベースを起点としたツリーを上に移動して、そのデータを取得します。
別のスナップショット・データベースからスナップショット・データベースを取得して、親スナップショット・データベースに変更を加える場合は、そのスナップショット・データベースに依存するすべてのスナップショット・データベースを削除する必要があります。子スナップショットが親スナップショットから作成されると、親スナップショットは読取り専用になります。親スナップショットに再度書き込む場合は、すべての子スナップショットを削除する必要があります。
階層型スナップショットの導入に伴い、スパース・テスト・マスターを作成できるようになりました。
階層型スナップショット・データベースでは、スパース・テスト・マスターを作成できます。スパース・テスト・マスターは、データをフル・コピーしたものであり、複数のレベルのスナップショットに親ファイル・データを提供します。スナップショットを作成する準備ができたら、スパース・ファイルの追加セットを作成し、Data Guardなどのレプリケーション技術を使用して本番データベースから更新を受信します。現在のデータの新しいテスト・マスターを作成する必要がある場合は、その新しい時点で再度完全な本番データベースをクローニングするのではなく、以前の追加のスパース・ファイルを読取り専用とマークしてスパース・テスト・マスターを作成し、最新の状態の新しいスパース・ファイルのセットを作成します。このスパース・テスト・マスターに追加のスナップショットを作成して、アプリケーション開発者がテスト用に使用できるようにすることができます。 本番データベースの1つのフル・コピーで複数の時点のスナップショットをサポートできるように、このプロセスを合計9回まで繰り返すことができます。 新しいスパース・テスト・マスターは短時間(5分以内)で作成できるため、本番にあわせて簡単に最新に保つことができます。
スパース・テスト・マスター・データベースは、CDBと非CDBの両方に適用されます。
Exadataスナップショット・データベースを作成する前に、ご使用の環境が次の要件を満たしていることを確認します。
ストレージ・サーバーはExadata X3以降である必要があります
Exadata Storage Server Software 12.1.2.1.0以上(Exadataストレージ・サーバーおよびデータベース・サーバー用)
セルにスパース・グリッド・ディスクがある状態では以前のバージョンにダウングレードできません。
Oracle Grid Infrastructure 12.1.0.2.0 BP5以上
スパースASMグリッド・ディスクを含むASMディスク・グループでは、COMPATIBLE.RDBMSとCOMPATIBLE.ASMの両方を12.1.0.2以上に設定する必要があります。
親ディスク・グループは11.2と互換性を持つことができます。
Oracle Databaseバージョン12.1.0.2.0 BP5以上
親データベースおよびスナップショット・データベースは12.1.0.2との互換性が必要です。
スナップショット・データベースと親データベースのデータ・ファイルは、同一のASMクラスタに存在する必要があります。
db_block_sizeは、4K以上で、4Kの倍数として指定する必要があります。
階層型スナップショット・データベース、スパース・テスト・マスター・データベース、ASM cpコマンドの新しい--sparseオプションまたは新しいsetsparseparent ASMコマンドを使用している場合は、Oracle DatabaseおよびOracle Grid Infrastructure 12.2.0.1.0、およびOracle Exadata 12.2.1.1.0以降が必要です。
この項では、Exadataスナップショットを作成して使用するために必要なオブジェクトについて説明します。内容は次のとおりです。
データベースは次のファイルで構成されます。
制御ファイル
オンラインREDOログ
一時ファイル
データ・ファイル
Exadataスナップショットのようなスパース・データベースでは、データ・ファイルはスパース・ファイルです。図10-3に示すように、スパース・ファイルは、親ファイルのブロックに対する変更のみを含み(親ファイルは変更されません)、未変更データにアクセスするために親ファイルへのポインタを保持します。
Exadataスナップショットは、他のデータベース・ファイル(制御ファイル、オンラインREDOログおよび一時ファイル)のコピーを含みます。このような他のデータベース・ファイルはスパース・ファイルではありません。
スパースASMディスク・グループはスパース・グリッド・ディスクで構成されます。スパース・グリッド・ディスクには仮想サイズ属性と物理サイズ属性があります。
単一のセル・ディスクからスパース・グリッド・ディスクに割り当てることのできる最大物理サイズは4TBです。最大仮想サイズは100TBです。
スパース・グリッド・ディスクを作成してからスパースASMディスク・グループを作成します。新しいシステムをデプロイしている場合、または既存のシステムを再デプロイしている場合は、他のディスク・グループのケースと同様に、各セル・ディスクの領域の一部をディスク・グループ用に確保します。
再イメージ化せずに既存のシステムを使用する場合は、既存のグリッド・ディスクのサイズ変更の方法について、My Oracle Supportノート1467056.1を参照してください。
Exadataスナップショットは、Oracle ASMスパース・ディスク・グループを利用します。つまり、スパース・データ・ファイルはOracle ASMスパース・ディスク・グループにしか作成できません。次の図に、3つのExadataスナップショットを含むスパース・ディスク・グループを示します。
スパースASMディスク・グループは、スパース・ファイルと非スパース・ファイルを格納できます。スパースASMディスク・グループにすべてのデータベース・オブジェクトを作成できます。たとえば、Exadataスナップショットを含むスパースASMディスク・グループにテスト・マスター・データベースを作成できます。テスト・マスターはソース・データベースのフル・コピーであるため、領域は節約されないことに注意してください。
スパース・ディスク・グループには次の属性があります。
compatible.asmは12.1.0.2以上に設定する必要があります。
compatible.rdbmsは12.1.0.2以上に設定する必要があります。
cell.sparse_dgはallsparseに設定する必要があります。これは、ディスク・グループがスパース・グリッド・ディスクで構成されていることを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スナップショットを作成するには、スパース・グリッド・ディスクをそれらのディスクに基づいて作成されたASMディスク・グループで作成する必要があります。既存のディスク・グループを直接変更してスパース・ディスク・グループに変換することはできません。スパース属性で新規のグリッド・ディスクを作成する必要があります。既存のディスク・グループを使用する場合、ディスク・グループおよび関連付けられているグリッド・ディスクを削除して再作成する必要があります。
新しいスパース・ディスク・グループを作成する際、すべての領域が現在既存のディスク・グループに割り当てられている場合、1つ以上の既存のディスク・グループをサイズ変更して領域を空ける必要があります。このプロセスを実行するには、次の手順を実行します。
リフレッシュ・サイクルが、Exadataスナップショットの使用および作成方法に影響することがあります。テスト・マスターは、READONLY状態(オープンしている場合)か、スナップショットが関連付けられているときはクローズ状態になっている必要があります。テスト・マスターをリフレッシュする必要がある場合は、そのテスト・マスターに依存するすべてのスナップショットを削除して再作成する必要があります。
様々なグループのスナップショット・ユーザーのリフレッシュ・サイクル要件が異なる場合、複数のテスト・マスターを維持する必要が生じます。次の図に、それぞれに独自のリフレッシュ・スケジュールがある3つのテスト・マスターを示します。
テスト・マスターが非コンテナ・データベースか、定期的にリフレッシュが必要なフルCDBである場合(つまり、テスト・マスターがPDBでない場合)、テスト・マスター・データベースを、その目的専用のData Guard物理スタンバイとして作成することをお薦めします。
この方法を使用すると次に示す複数のメリットが得られます。
容易なリフレッシュ
Oracle Data Guardは、本番データベースの複数の物理レプリカ(障害時リカバリ、本番の読取り専用オフロード、バックアップ・オフロードおよびテストに使用される)を同期するソリューションとして実績があります。これと同じ機能を使用すると、本番データベースのコピーをテスト・マスター・データベース専用として維持でき、定期的なリフレッシュも容易に行うことができます。Data Guard物理スタンバイを使用するメリットは、テスト・マスター・データベースのサイズやリフレッシュが必要な回数に応じて増大します。Data Guardレプリカの作成は、RMANバックアップからデータベースを単純にクローニングすることに比べて細々とした手順が必要になりますが、利点の方が大きく上回ります。
プライマリへの最小の影響
Data Guardレプリカがテスト・マスター・データベースとして使用されている間、Data Guard REDOのトランスポートおよび適用は無効になります。本番データベースの影響はまったくありません。リフレッシュする際には、Data Guardレプリカがテスト・マスター・データベースに変換されて以降に生成されたデルタのみが本番データベースから取得され、テスト・マスター・データベースの再同期に使用されます。
注意: このData Guardレプリカがテスト・マスターとして作動している間、トランスポートと適用は停止されるため、障害時リカバリなどテスト・マスター以外の目的には使用しないでください。すでに高可用性または障害保護の目的でData Guardを使用している場合は、Exadataスナップショット・データベース用のテスト・マスター・データベースとして使用するためにData Guardレプリカを作成することをお薦めします。
スナップショット・クローン作成前の容易な修正
Data Guardでは、Exadataスナップショットの作成に使用する前に、テスト・マスター・データベースを簡単に変更できます。たとえば、Data Guardレプリカを読取り/書込みとして開き、マスクまたは修正してからExadataスナップショットを作成できます。その後、テストが完了したら、テスト・マスター・データベースをData Guardレプリカに再変換することができます。このときに、元のコピーに加えらえた変更が破棄され、本番データベースのデルタのみを使用してリフレッシュされます。Data Guardレプリカのリフレッシュ後は、テスト・マスターとして再使用する前に、データベースを再修正する必要があることに注意してください。
RMANバックアップ・データベースを使用しているときに、データをマスクまたは修正した場合は、テスト・マスターをリフレッシュする必要があるときに、別のバックアップをテスト・マスターとして作成し、それを再修正して最新状態にする必要があります。
Exadataスナップショットを作成および管理するには、次の手順を実行する必要があります。
スパース・グリッド・ディスクを作成するときは、物理サイズと仮想サイズを指定する必要があります。
次の式を使用して、スパース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%の領域クッションを追加する必要があります。
次の式を使用して、スパース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境界に合うように調整します。
複数のプロジェクトや複数の反復で使用するために余分な領域を確保しておく必要があることに注意してください。
スパース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は、グリッド・ディスクの仮想サイズです。
スパース・グリッド・ディスクを作成した後で、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に設定する必要があります。
次のいずれかの方法を使用してテスト・マスターを作成できます。
次に、「テスト・マスター・データ・ファイルの所有権の設定」で説明されているタスクを実行します。
データベースのフル・クローンを作成するには、RMANバックアップ/リストアやデータ・ポンプなど、データベースのフル・クローンの作成に一般的に使用される方法を使用します。
フル・クローンを作成したら、すべてのデータ・ファイルの書込み権限を削除して、誤って上書きされることを防ぎます。
ファイル権限を読取り専用に設定できるのはASMインスタンスでのSQLコマンドのみです。SQLでは書込み権限を削除できません。
SQL> ALTER DISKGROUP DATA set permission owner=read ONLY, group=read ONLY, other=none for file 'FILENAME';
すでに存在しているフル・クローンまたはスタンバイ・データベースをテスト・マスターとして利用したい場合は、そのデータベースをテスト・マスターに変換できます。
関連項目
データベースをクローニングしてテスト・マスター・データベースを作成したら、オペレーティング・システム・ユーザーをディスク・グループの所有者として設定し、そのオペレーティング・システム・ユーザーをテスト・マスター・データ・ファイルの所有者にします。
これには、SQLコマンドをSQL*Plusで手動で実行するか、スクリプトを実行します。
プラガブル・データベース(PDB)またはフル・データベースのExadataスナップショット・データベースを作成できます。テスト・マスター・データベースからスナップショット・データベースを作成する場合、テスト・マスター・データベースは読取り専用になります。
前者はExadataスナップショットPDB、後者はスナップショット・データベース(非CDBまたはCDB)です。
プラガブル・データベース(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を作成します。
フル・データベースのExadataスナップショットを作成するのは、テスト・マスター・データベースが非CDBの場合、またはCDBであるが実質すべてのPDBがテストで使用される場合です。
テスト・マスター・データベースは、高可用性または障害時リカバリを提供するフェイルオーバー・ターゲットとして使用できないことに注意してください(Data Guard構成は、別の目的に使用される複数のレプリカを含むことができます)。テスト・マスターPDBと似ていますが、テスト・マスター・データベースは、対応するExadataスナップショットが存在している場合は変更できません。
テスト・マスター・データベースとして、リカバリ・モードの読取り専用スタンバイ・データベース(たとえばリアル・タイム適用のActive Data Guard)を使用することはできません。
テスト・マスター・データベースと対応するExadataスナップショットは、同じOracle ASMクラスタ環境に存在する必要があります。
次の図は、Exadataテスト・マスター・データベースおよびスナップショット・データベースのライフサイクルを示しています。
図10-13 テスト・マスター・データベースおよびスナップショット・データベースのライフサイクル
テスト・マスター・データベース(読取り専用)をリフレッシュするための主な手順は次のとおりです。
リフレッシュするテスト・マスター・データベースの子であるExadataスナップショット・データベースを削除します。
RMANを使用して削除できます。たとえば、ExadataスナップショットをターゲットとしたRMANを使用して、各Exadataスナップショット・データベースに接続し、次のコマンドを実行します。
RMAN> startup mount force; RMAN> delete database;
注意: Exadataスナップショット・データベースの削除に失敗しても、テスト・マスター・データベースの状態には影響しません。ただし、テスト・マスター・データベースが削除またはリフレッシュされると、Exadataスナップショットで予期しない動作が発生することがあります。
最初にData Guardスナップショット・スタンバイを使用してテスト・マスター・データベースを用意していた場合は、Data Guard変換コマンドを使用して元の状態のData Guardレプリカに再変換します。これにより、レプリカをテスト・マスターとして準備するために加えられた変更は破棄されます。また、現在のバックアップを完全にリストアするかわりに、ソース・データベースの増分変更のみを使用してテスト・マスターをリフレッシュできるようになります。
テスト・マスター・データベースのリフレッシュには2つのオプションがあります。
Data Guardによりテスト・マスター・データベースをリフレッシュ
Data Guardレプリカがテスト・マスター・データベースとして使用されたのがごく短期間で、ソース・データベースでこの期間に生成されたすべてのREDOがディスク上のアーカイブ・ログにある場合、REDOの移動を有効にしてREDO適用を開始できます。テスト・マスター・データベースは標準のData Guardプロトコルを使用して、アーカイブ・ログを取得し、ログを適用して、プライマリ・データベースの状態に追い付きます。Data Guardレプリカが必要な状態までリフレッシュされたら、REDOの移動を無効化してREDOの適用を停止し、前に説明したテスト・マスター/スナップショットの作成サイクルを繰り返します。
このオプションのメリットは、テスト・マスター・データベースを最新状態にする前の段階でREDO適用を停止できることです。
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を使用してテスト・マスター・データベースをロール・フォワード
Data Guardレプリカがテスト・マスター・データベースとして長期にわたって使用されている場合、またはData Guardによってテスト・マスター・データベースを自動的にリフレッシュするためのREDOがディスク上にない場合は、RMANを使用してネットワークを介したライブ増分適用を実行します。
この方法を使用する主なメリットは、追加のディスク領域が必要ないことです。RMANが、プライマリの変更済ブロックをネットワークを介してスタンバイに移し、直接適用します。また、RMANは、テスト・マスターのデータファイルのSCNに基づいて取得すべきブロックを判別することでプロセスを大幅に単純化します。この方法では中間の時点にリカバリすることはできません。リフレッシュによってテスト・マスター・データベースがプライマリと同じ状態になります。この方法の詳細は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』のRMANリカバリの実行の拡張シナリオに関する項を参照してください。
RMANネットワーク増分を使用してテスト・マスター・データベースをリフレッシュするには、次の手順を実行します。
RMANに接続するためにSQL*Netを準備します。このプロセスでこれらの手順を実行する必要があるのは初回のみです。
テスト・マスター・データベース(Data Guardレプリカ)のlistener.oraエントリを作成して、RMANがSIDに接続できるようにします。データベースがNOMOUNTモードでオープンしている場合、このサービスは起動されないためです。次に、このエントリの例を示します。
SID_LIST_LISTENER =
(SID_LIST =
(SID_DESC =
(SID_NAME = TESTMASTER1)
(ORACLE_HOME = /u01/app/oracle/product/12.1.0.2/dbhome_1)
)
)
listener.oraに対する変更を反映するためにリスナーをリロードします。
$ lsnrctl reload listener
ローカル・テスト・マスター・インスタンスのSIDを指すTNSエントリをテスト・マスター環境に作成します。このエントリでは、接続リクエストが正しいホストに送られるように、SCAN名ではなくローカル・ホスト名を使用する必要があります。
TESTMASTER1 =
(DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP)(HOST = standbydb01.us.oracle.com)(PORT = 1521))
(CONNECT_DATA =
(SERVER = DEDICATED)
(SID = TESTMASTER1)
(UR=A)
)
)
RMAN経由でテスト・マスター・データベースに接続し、CURRENT_SCNを後で使用するために保存します。これを使用して、直前のリフレッシュ以降に新たに作成されたファイルをソース・データベースからリストアする必要があるかどうかを判別します。
RMAN> select current_scn from v$database;
CURRENT_SCN#
------------------
17081990
Data GuardレプリカのオンラインREDOログ・ファイル名およびスタンバイREDOログ・ファイル名をメモします。後の手順でこれらの名前が必要になる場合があります。
次のコマンドでは、REDOログ・ファイル名およびグループ識別子が表示されます。
RMAN> SELECT type, group#, member FROM v$logfile;
ソース・データベースに基づいてData Guardレプリカのスタンバイ制御ファイルをリフレッシュして、制御ファイルを最新状態にします。
RMANターゲットとしてData Guardレプリカに再接続します。
これをNOMOUNTモードで再起動します。
RMAN> startup nomount force;
ソース・データベース上の制御ファイルを使用して、スタンバイ制御ファイルをリストアします。
次のコマンド例では、SOURCEMASTER (ソース・データベース)のデータベース制御ファイルを使用して、Data Guardレプリカ上の制御ファイルがリストアされます。
RMAN> RESTORE STANDBY CONTROLFILE FROM SERVICE SOURCEMASTER;
次のコマンドを使用してData Guardレプリカをマウントします。
RMAN> ALTER DATABASE MOUNT;
RMANカタログを使用していない場合、スタンバイ制御ファイル内のファイルの名前は、ソース・データベースで使用されていた名前になります。スタンバイ制御ファイル内のデータファイル名および一時ファイル名を更新する必要があります。
CATALOGコマンドおよびSWITCHコマンドを使用してすべてのデータ・ファイルの名前を更新します。SWITCHコマンドは、ソース・データベースの新たに作成されたファイルを手順7でリストアした後で使用されます。
RMAN> CATALOG START WITH '+DATA/TESTMASTER/DATAFILE/';
この例で、+DATA/TESTMASTER/DATAFILE/はData Guardレプリカのデータ・ファイルの場所です。すべてのデータファイルを、この場所に格納する必要があります。
手順2のCURRENT_SCNを使用して、ソース・データベースからリストアする必要がある新しいファイルが追加されたかどうかを判別します。
RMAN> select file# from v$datafile where creation_change# >= 17081990;
FILE#
----------
9
10
前の問合せでファイルが返された場合は、それらのデータファイルをソース・データベースからリストアします。前の手順で返されたFILE#のリストを使用して、次のようなRMAN RUNブロックを実行します。FILE#が返されなかった場合はこの手順をスキップします。
RMAN> run{
2> set newname for database to '+DATA';
3> restore datafile 9,10 from service SOURCEMASTER;
4> }
RMANカタログを使用しない場合は、手順5でカタログ化されたコピーに切り替えて、スタンバイ制御ファイルのデータファイル名を変更します。
RMAN> SWITCH DATABASE TO COPY;
次の方法で、スタンバイ制御ファイル内のオンラインREDOログとスタンバイREDOログの名前を更新します。
ALTER DATABASE CLEARコマンドを使用して、Data GuardレプリカのすべてのREDOログ・グループのログ・ファイルを消去します。RMANで、すべてのスタンバイREDOログおよびオンラインREDOログ・ファイルを再作成します。
注意: Data Guardレプリカに、ソース・データベースのオンラインREDOログ・ファイルおよびスタンバイREDOログ・ファイルへのアクセス権がない場合のみ、ログ・ファイルを消去することをお薦めします。Data Guardレプリカに、ソース・データベースのREDOログ・ファイルへのアクセス権があり、ソース・データベースのREDOログ・ファイル名がOMF名である場合は、ALTER DATABASEコマンドでソース・データベース上のログ・ファイルを削除します。また、ログ・ファイルの消去により新しいログ・ファイルが作成されます。既存のファイルは使用されません。制御ファイルはそのような既存のファイルを認識しません。領域を節約するため、ALTER DATABASE CLEARコマンドを実行する前に既存のログ・ファイルをASMから削除します。
手順5で問い合せたV$LOGFILEビューのGROUP#列に、消去する必要があるログ・グループのREDOログ・グループ識別子が示されます。個別にALTER DATABASE CLEARコマンドを使用して、各REDOログ・グループを消去します。
次のコマンドで、識別子2を持つREDOログ・グループを消去します。
SQL> ALTER DATABASE CLEAR LOGFILE GROUP 2;
ALTER DATABASE RENAME FILEコマンドを使用して、REDOログ・ファイルの名前を変更します。個別のコマンドを使用して、手順5で示された各ログ・ファイルの名前を変更します。
ログ・ファイルの名前を変更するには、STANDBY_FILE_MANAGEMENT初期化パラメータをMANUALに設定する必要があります。ソース・データベースとData Guardレプリカで、オンラインREDOログ・ファイルとスタンバイREDOログ・ファイルの数が同じ場合、ログ・ファイルの名前を変更することをお薦めします。
RMAN RECOVER...FROM SERVICEを使用して、データ・ファイルを最新状態にロール・フォワードします。この操作には追加の領域は必要ありません。このプロセスではファイルは最新状態にしかリフレッシュできません。それよりも前の時点にファイルをリフレッシュすることはできません。手順3で作成したTNSエントリを使用して、RMAN経由でターゲットとしてData Guardレプリカに接続し、次のコマンドを発行します。指定されるサービスはプライマリを指す必要があります。
RMAN> recover database noredo from service SOURCEMASTER;
Data GuardレプリカへのREDOの移動を有効にし、REDOの適用を開始します。これは、手順10の中で適用したブロックで制御ファイルを更新するために必要です。
DGMGRL> edit database TESTMASTER set property logshipping=ON; Property "logshipping" updated DGMGRL> edit database TESTMASTER set state=apply-on; Succeeded.
REDOが適用されたら、Data Guardレプリカをテスト・マスター・データベースに変換するために使用したプロセスを繰り返して、Exadataデータベース・スナップショットを作成します。忘れずにスタンバイでログの移動とREDOの適用を再び無効にしてください。
次に、「テスト・マスター・データ・ファイルの所有権の設定」.で説明されているタスクのいずれかを完了します。
「テスト・マスター・データベース(読取り専用)からのスナップショット・データベースの作成」で説明されているフル・データベースまたはプラガブル・データベース(PDB)のExadataスナップショット・データベースを作成できます。
スナップショットからスナップショットを作成するには、次の手順を実行します。
第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;
関連項目
フル・データベースの1つのコピーから複数のスパース・テスト・マスターを作成できます。テスト・マスターのソースは、Data Guardのフィジカル・スタンバイ・データベースのフル・コピーです。このスタンバイ・データベースは、スイッチオーバーまたはフェイルオーバーのターゲットとして使用しないでください。これは、このプロセスで定義されたテスト・マスターのソースとしてのみ使用するようにしてください。
このプロセスでは、階層型スナップショット機能を利用してREDOを送信および適用できるようにし、スタンバイ・データベースを本番にあわせて最新に保ちます。また、Exadata Storageスナップショットで使用されるテスト・マスターのソースとして使用されるファイルを提供します。フィジカル・スタンバイ・データベースは、プライマリ・データベースのフル・コピーとして開始されます。ストレージ・スナップショットを作成する準備ができたら、フル・データベース・ファイルを指すスパース・データ・ファイルを作成し、プライマリから送信されたREDOを適用します。次に、これらのスパース・ファイルをスタンバイ・データベース・インスタンスで使用して、REDOを適用します。また、スパース・データ・ファイルをActive Data Guardモードで開いて、現在のデータの読取り専用アクセスを指定することもできます。
様々な時点で追加のスナップショットが必要な場合は、以前作成したスパース・ファイルの上に新しいスパース・ファイルを作成してREDOを適用し、データを最新に保つプロセスを繰り返します。これにより、データ・ファイルの1つのフル・コピーを使用して、様々な時点の複数のテスト・マスターとして使用できます。また、既存のスナップショットを削除する必要がないため、新しいテスト・マスターを短時間で作成することもできます。
制限事項
このプロセスは、非コンテナ・データベースでもコンテナ・データベースでも使用できますが、Oracle Data Guardで使用している場合は、プラガブル・データベース(PDB)に対する制限があります。
プライマリ・データベースのシードから新しいPDBを作成すると、スタンバイ・データベースでのActive Data Guard操作に関係なく、CREATE PLUGGABLE DATABASE文のREDOが適用されたときに、自動的にスタンバイ・データベースにロールされます。
ソースPDBがプライマリ・データベースに存在するプライマリ・データベースで実行されるクローンの場合は、スタンバイ・データベースでクローンPDBを自動的に開始するためにActive Data Guardモードにする必要があります。
ソースPDBが別のデータベースに存在するプライマリ・データベースで実行されるクローンの場合は、PDBの作成でメソッドを使用して、このスタンバイ・データベースでのリカバリを遅延する必要があります。これらのクローンPDBは、スタンバイが完全にリフレッシュされるまで、スタンバイに含まれません。
プライマリ・データベースにプラグインされたPDBの場合は、ファイルをスタンバイ・データベースに事前にコピーするか、PDBのプラグインでメソッドを使用して、このスタンバイ・データベースでのリカバリを遅延する必要があります。
PDBの移行操作が原因でスタンバイでのREDO適用が失敗した場合、またはPDBのリカバリを有効にする必要がある場合は、プライマリからフル・スタンバイ・データベースをリフレッシュする必要があります。
次のタスクは、フィジカル・スタンバイ・データベースがすでに作成されていて、テスト・マスターのソースとして使用することを前提としています。
関連項目:
『Oracle Data Guard概要および管理』のプライマリ・データベースでのPDBの作成に関する項スタンバイ・データベースの既存のファイルは、スナップショットのサポートに使用されます。スタンバイの既存のファイルを指す一連のスパース・ファイルを作成します。プライマリ・データベースから受信したREDOが、これらのファイルに適用されます。これらのスパース・ファイルにより、スタンバイ・データベースをスパース・テスト・マスターとして使用できるようになり、また、プライマリ・データベースを最新に保つことができます。
このタスクでは、スタンバイをテスト・マスターに変換し、スパース・ファイルを作成して、プライマリ・データベースからREDOを受信して適用します。
注意:
このプロセスでは、フル・スナップショット・データベースを作成せず、既存のスタンバイ・データベースの一部を使用して、スタンバイにスパース・データ・ファイルを追加します。スタンバイ・データベースの制御ファイルは、追加されるスパース・ファイルを使用するために変更されます。今後は、同じスタンバイ・インスタンスが使用されますが、REDO適用ではスパース・ファイルを使用して変更を格納し、スナップショットのスパース・テスト・マスター・ファイルとして機能する元のスタンバイ・データ・ファイルはそのままにします。既存のデータ・ファイルを使用して、プロセスが実行された時点のデータでフル・データベース・スナップショットをサポートします。
新しいスパース・テスト・マスターを使用して、フル・スナップショットを作成します。
「タスク1: スタンバイ・データベースをスパース・テスト・マスターとして使用するための準備」の手順2で作成したバックアップ制御ファイルを使用して、CREATE CONTROLFILE文を作成する必要があります。このファイルを使用するには、一時データベース・インスタンスを作成して制御ファイルをマウントし、バックアップ制御ファイルを実行してコマンドをトレースします。
新しいテスト・マスターおよび新しいREDO適用ファイルを提供するために新しいスナップショットのセットを作成します。
テスト・マスターの完全なコピーを作成することなく、定期的にスタンバイ・データベースを使用して追加のスナップショットを作成できます。階層型スナップショット機能を利用して、前の3つのタスクで実行したプロセスを繰り返すことにより、これを行うことができます。新しいテスト・マスターは、REDOを適用している既存の最新のスナップショットの上に作成されます。このスナップショットは読取り専用となり、新しいスナップショットは、REDO適用処理を続行するように作成されます。
次を実行して、新しいテスト・マスター・タイムラインのスタンバイを構成します。
このプロセスは9回まで繰り返すことができ、10レベルの環境が作成されます(元のスタンバイ・データ・ファイルおよび9の階層型スナップショット)。 9回目のプロセスを繰り返すときは、新しいスナップショットを作成して、プライマリ・データベースからREDOを受信しないようにしてください。
最大の10レベルに到達したら、次の複数のオプションから選択します。
スタンバイ・データベースおよびスナップショットの複数のコピーを管理するための十分な領域がある場合は、スタンバイ・データベースをリフレッシュして、新しい階層型スナップショットのツリーを作成します。 元の完全なファイルおよびスナップショットは、必要であれば残すことができます。
スタンバイ・データベースおよびスナップショットの複数のコピーを管理するための十分な領域がない場合は、すべてのデータ・ファイルおよびスナップショットを削除し、スタンバイをリフレッシュして、新しい階層型スナップショットのツリーを作成します。
別の環境に新しいスタンバイ・データベースを作成し、新しい階層型スナップショットのツリーを作成します。
この手順では、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;
PRODPDB1 PDBで行われた変更がTMPDB1 PDBに抽出、レプリケートおよび適用されるよう、Oracle GoldenGateを構成します。ExtractおよびReplicatを構成し、抽出プロセスを開始した後、PRODPDB1 PDBを読取り/書込みモードで開きます。
注意:
Oracle GoldenGateが構成され、抽出プロセスが開始されるまで、PRODPDB1 PDBを変更用に開くことはできません。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を指す新しいスパースTMPDB1 PDBを作成します。また、新しいTMPDB1 PDBは、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を削除して再度作成し、新しい階層型スナップショット・ツリーを構築する必要があります。
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/
スパース・グリッド・ディスクのサイズ変更、再作成または活動の監視を行うことができます。
V$ASM_DISKGROUP.FREE_MBまたはV$ASM_DISK.FREE_MBの値が低い場合、仮想アドレス領域を増やす必要があります。
関連項目
グリッド・ディスクが物理領域外で動作している場合は、グリッド・ディスクの物理サイズを増やす必要があります。
V$ASM_DISK_SPARSEのTOTAL_MAT_MBおよびALLOCATED_MAT_MB列の値を比較して、残りの物理領域の容量を確認できます。これら2つの列の値が近い場合は、グリッド・ディスクの物理サイズを増やす必要があります。
関連項目
V$ASM_DISKビューおよびV$ASM_DISKGROUPビューには、仮想サイズとスパースASMディスク・グループの使用率に関する情報が含まれます。新しいビューV$ASM_DISK_SPARSEおよびV$ASM_DISKGROUP_SPARSEには、スパースASMディスク・グループの実際のサイズと使用率に関する情報が含まれます。V$ASM_DISK_SPARSEにもパフォーマンスと使用率のメトリックが含まれます。
次の表に、V$ASM_DISK_SPARSEの各列についての説明を示します。
表10-1 V$ASM_DISK_SPARSE
| 列 | 説明 |
|---|---|
|
ディスクを含むディスク・グループの番号 |
|
このディスク・グループ内のディスクに割り当てられた番号 |
|
ディスクのインカネーション番号 |
|
このディスクの合計使用済物理容量 |
|
このディスクの合計物理容量 |
|
このディスクのスパース・リージョンの読取りリクエスト数 |
|
このディスクのスパース・リージョンの読取りバイト数 |
|
スパース読取りI/Oにかかった時間 |
次の表に、V$ASM_DISKGROUP_SPARSEの各列についての説明を示します。
表10-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
