| Oracle® Exadata Storage Server Softwareユーザーズ・ガイド 12c リリース1 (12.1) E52920-09 |
|
 前 |
 次 |
この章の内容は次のとおりです。
従来は、本番システムのデータベースをクローニングするには、Exadata以外のシステムにテスト・マスターとスナップショット・データベースを作成しました(図12-1)。場合によっては、これらのデータベースはソースのフル・コピーで、ソースと同じ容量のストレージが消費されます(図12-2)。
クローンが本番データベースのフル・コピーである場合、消費されるストレージ容量およびクローンの作成にかかる時間に関してコストが高くなります。数TBのデータベースのクローンを10個作成するケースを想像してみると、このアプローチが発展しない理由をすぐに理解できます。
このアプローチのもう1つのデメリットは、Exadata以外のシステムでOracle Exadata Storage Server Softwareの機能(スマート・スキャン、スマート・ロギング、スマート・フラッシュなど)が使用できないことです。
このような問題を解決するために、Exadataスナップショットを使用できます。Exadataスナップショットは、Oracleデータベースに対してスペース効率に優れた読取り専用クローンまたは読取り/書込みクローンを作成する理想的な方法です。このようなクローンは、開発やテストまたはその他の本番以外の目的で使用できます。また、複数のクローンが必要な場合にディスク領域や時間を節約することができます。図12-3は、Exadataスナップショットで必要な領域を示します。
Exadataスナップショットは、ソース・データベースのフル・クローンであるテスト・マスターに基づいています。テスト・マスターはソース・データベースをフル・コピーしたものです。1つのテスト・マスターから複数のExadataスナップショットを作成することができ、追加ストレージと作業は最小限に抑えられます。各Exadataスナップショットで使用されるのはテスト・マスター用に必要な小容量のディスク領域のみで、スナップショットの作成も削除も数秒で行うことができます。各Exadataスナップショットはテスト・マスターの論理コピーです。
テスト・マスターからExadataスナップショットを作成する前に、必要であればテスト・マスターのデータを変更できます。たとえば、テスト・マスターの機密データを削除またはマスクしてから、権限を持たないユーザーがテスト・マスターを使用できるようにします。
テスト・マスターからのExadataスナップショットの作成は、子ファイルのヘッダーに親ファイル名を記録することにより行えます。この操作は数秒で完了し、必要なディスク領域も最小限です。追加のディスク領域が消費されるのは、スナップショットのユーザーがデータの変更を開始したときのみです。新しいデータのみがデータ・ブロックに書き込まれますが、そのデータ・ブロックは書込み時にスナップショットに割り当てられるものです。変更されていないデータに対するリクエストはすべて、テスト・マスターのデータ・ブロックによって処理されます。
複数のユーザーが、同じテスト・マスターから別々のスナップショットを作成することもできます。これにより、複数の開発環境およびテスト環境が、各ユーザー用のデータベースを別々に維持しつつ、領域を共有することができます。図12-4は、同じテスト・マスターを使用する3つのExadataスナップショットがあるExadata環境です。現在、既存のExadataスナップショットに基づいて第2レベルのスナップショットを作成することはできません。
図12-4 同じテスト・マスターの3つのExadataスナップショットがあるExadata環境
領域と時間の節約に加えて、Exadataスナップショットによって、Exadataでコスト効果の高い開発環境や品質が保証されたテスト環境が実現します。Exadataスナップショットは、完全に稼働するExadata環境(たとえば、Exadataスマート・フラッシュ、スマート・スキャン、ハイブリッド列圧縮など)において、機能の検証や保守および運用手順の実行を行う必要がある開発者およびテスト担当者が使用できます。
テスト環境と開発環境は、本番データベースをホストするExadataラックとは別の物理Exadataラックでホストすることをお薦めします(図12-5および図12-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クラスタ環境に存在する必要があります。
図12-5に、3つのPDBを含む本番CDBを示します。PDBのうち2つ(PDB1とPDB2)はクローニングされて、テスト・マスターPDBが作成されています。これらは、アンプラグされてからテストExadataシステムの別のCDBにプラグされました。この図では、6個のExadataスナップショットPDBがテスト・マスターPDBから作成されています。
1つのコンテナ・データベース(CDB)があり、すべてのPDBからテスト・マスターを作成します。または、コンテナではない単純なデータベースがあり、そのデータベースからテスト・マスターを作成します。
Exadataスナップショット・データベースは、非コンテナ・データベース(非CDB)またはコンテナ・データベース(CDB)のどちらにもすることができます。CDBのExadataスナップショット・データベースを作成すると、そのコンテナ内のすべてのプラガブル・データベースにアクセスできます。
図12-6は本番データベースのフル・クローンです。クローン(つまりテスト・マスター・データベース)は、別のテスト/開発環境でホストされ、6個のExadataスナップショットが関連付けられています。
テスト・マスター・データベースは、Data Guardスタンバイ・データベース(テスト・マスターを定期的にリフレッシュする場合に推奨)またはRMANを使用して作成されます。
テスト・マスター・データベースと対応するExadataスナップショットは、同じASMクラスタ環境に存在する必要があります。
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の倍数として指定する必要があります。
この項では、Exadataスナップショットを作成して使用するために必要なオブジェクトについて説明します。内容は次のとおりです。
データベースは次のファイルで構成されます。
制御ファイル
オンラインREDOログ
一時ファイル
データ・ファイル
Exadataスナップショットのようなスパース・データベースでは、データ・ファイルはスパース・ファイルです。スパース・ファイルは、親ファイルのブロックに対する変更のみを含み(親ファイルは変更されません)、未変更データにアクセスするために親ファイルへのポインタを保持します。図12-3を参照してください。
Exadataスナップショットは、他のデータベース・ファイル(制御ファイル、オンラインREDOログおよび一時ファイル)のコピーを含みます。このような他のデータベース・ファイルはスパース・ファイルではありません。
スパースASMディスク・グループはスパース・グリッド・ディスクで構成されます。スパース・グリッド・ディスクには仮想サイズ属性と物理サイズ属性があります。
単一のセル・ディスクからスパース・グリッド・ディスクに割り当てることのできる最大物理サイズは4TBです。
最大仮想サイズは100TBです。
スパース・グリッド・ディスクを作成してからスパースASMディスク・グループを作成します。新しいシステムをデプロイしている場合、または既存のシステムを再デプロイしている場合は、他のディスク・グループのケースと同様に、各セル・ディスクの領域の一部をディスク・グループ用に確保します。
再イメージ化せずに既存のシステムを使用する場合は、既存のグリッド・ディスクのサイズ変更の方法について、My Oracle Supportノート1467056.1「Exadataでのグリッド・ディスクのサイズ変更: 例」を参照してください。
詳細は、「スパース・グリッド・ディスクの作成」を参照してください。
Exadataスナップショットは、Oracle ASMスパース・ディスク・グループを利用します。つまり、スパース・データ・ファイルはOracle ASMスパース・ディスク・グループにしか作成できません。図12-7に、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つ以上の既存のディスク・グループをサイズ変更して領域を空ける必要があります。このプロセスを実行するには、次の手順を実行します。
サイズ変更を行う場合、非スパース・データベースをスパース・ディスク・グループに入れることもできます。非スパース・データベースおよびファイルは、全部の物理領域を使い切ります。
単一のセル・ディスクからスパース・グリッド・ディスクに割り当てることのできる最大物理サイズは4TBです。
スパース・グリッド・ディスクごとに割り当てることのできる最大仮想サイズは100TBです。しかし、さらなるパフォーマンスへの影響を回避するために、本当に必要な場合を除き、大きな仮想サイズを作成することは推奨されません。
スナップショットの物理領域の容量を決定します。「グリッド・ディスクの物理サイズの計算」にある式を使用します。
スパース・グリッド・ディスクへの物理領域割当ての最大開始点として、合計領域の15%が適しています。これは将来の利用パターンおよびニーズに基づき、必要に応じて増減できます。
スナップショットに必要な仮想領域の容量を決定します。「グリッド・ディスクの仮想サイズの計算」にある式を使用します。
基となるグリッド・ディスクには変更を加えずに、ASMディスク・グループを変更するだけで、仮想サイズをオンラインで変更できます。
一度に持つスナップショット数および行う予定の変更数を使用し、My Oracle Supportノート1464809.1のスクリプトを使用して、スパース・ディスク・グループに領域を空けるために縮小する既存のディスク・グループを決定します。このスクリプトの結果に基づき、複数のディスク・グループを縮小して、スパース・ディスク・グループに必要な領域を得ることができます。元のディスク・グループに最低15%の空き領域を残して、サイズ変更操作中にリバランスできるようにします。
現在のディスク・グループに、スパース・ディスク・グループに必要な領域を提供する十分な空き領域がない場合:
この環境でのスパースの使用方法を再考し、それに応じて縮小します
この環境から空き領域のある別の環境に、オブジェクトとデータベースを再配置します
記憶域を追加します
サイズ変更するディスク・グループを決定したら、My Oracle Supportノート1465230.1の手順に従ってディスクをサイズ変更します。このプロセスでは、ローリング方式でサイズ変更を行うことができます。サイズ変更するディスク・グループに、1つのセルをグループ外にリバランスするのに十分な空き領域があることが、主要な前提条件になります。
「スパース・グリッド・ディスクの作成」に概説されているコマンドを使用して、解放したばかりの領域からスパース・グリッド・ディスクを作成します。
「スパース・グリッド・ディスク用のASMディスク・グループの作成」に概説されているコマンドを使用して、スパースASMディスク・グループを作成します。
スパース・グリッド・ディスクのアクティビティを監視するには、「スパース・ディスク・グループ・アクティビティの監視」を参照してください。
スパース・グリッド・ディスクをサイズ変更する必要がある場合:
より多くの物理領域が必要な場合は、この項の手順1から4に従って領域を解放した後、「グリッド・ディスクのサイズ変更」の手順に従います。単一のセル・ディスクからスパース・グリッド・ディスクに割り当てることのできる最大物理サイズは4TBです。
より多くの仮想領域が必要な場合は、「仮想領域のサイズ変更」の手順に従います。単一のセル・ディスクからスパース・グリッド・ディスクに割り当てることのできる最大仮想サイズは100TBです。
リフレッシュ・サイクルが、Exadataスナップショットの使用および作成方法に影響することがあります。テスト・マスターは、READONLY状態(オープンしている場合)か、スナップショットが関連付けられているときはクローズ状態になっている必要があります。テスト・マスターをリフレッシュする必要がある場合は、そのテスト・マスターに依存するすべてのスナップショットを削除して再作成する必要があります。
様々なグループのスナップショット・ユーザーのリフレッシュ・サイクル要件が異なる場合、複数のテスト・マスターを維持する必要が生じます。図12-8に、それぞれに独自のリフレッシュ・スケジュールがある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レプリカに再変換することができます。このときに、元のコピーに加えらえた変更が破棄され、本番データベースのデルタのみを使用してリフレッシュされます。
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境界に合うように調整します。
複数のプロジェクトや複数の反復で使用するために余分な領域を確保しておく必要があることに注意してください。
次の式を使用して、スパース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';
すでに存在しているフル・クローンまたはスタンバイ・データベースをテスト・マスターとして利用したい場合は、次の手順を実行します。
スタンバイ・データベースは、テスト・マスターとして作動している間、REDO適用を実行できないことに注意してください。
スタンバイ・データベースを使用する場合:
Data Guardレプリカを初めて作成する場合は、My Oracle Supportノート1617946.1「RMAN複製を使用したスタンバイの作成(RACまたはRAC以外)」の手順を使用します。
Data Guardコピーを、READONLY状態で開くためには十分なREDOが適用されている必要があります。
|
注意: Data Guardスナップショット・スタンバイはExadataスナップショットとは異なります。Data Guardスナップショット・スタンバイは、読取り/書込みで開いているソース・データベースの完全なコピーです。Data Guardスナップショット・スタンバイへの変換は1つのコマンドを使用する単純な操作です。Data Guardスナップショット・スタンバイでは、後の手順でのテストに備えて、テスト・マスターへの変更やリフレッシュを容易に行うことができます。Data Guardスナップショット・スタンバイ・データベースの詳細は、『Oracle Data Guard概要および管理』のスナップショット・スタンバイ・データベースの管理に関する項を参照してください。 |
スタンバイ・データベースが一貫性のある状態で、READONLYで開くことができる場合は、ログのトランスポートを停止してスタンバイでのREDOの適用を無効にする必要があります。
DGMGRL> edit database TESTMASTER set property logshipping=OFF; Property "logshipping" updated DGMGRL> edit database TESTMASTER set state=APPLY-OFF; Succeeded
テスト・マスターに変更を行います。たとえば、必要な場合に機密データを削除します。
compatible.ASMとcompatible.RDBMSの両方が11.2.0.0以上であることを確認します。
テスト・マスターのデータ・ファイルが格納されるディスク・グループ上のアクセス・コントロールを有効にします。ディスク・グループはExadata上にあることが必要です。
SQL> ALTER DISKGROUP DATA SET ATTRIBUTE 'ACCESS_CONTROL.ENABLED' = 'TRUE';
すべてのデータ・ファイルに所有権を付与します。詳細は、「テスト・マスター・データ・ファイルの所有権の設定」を参照してください。
すべてのデータ・ファイルの書込み権限を削除して、誤って上書きされることを防ぎます。
ファイル権限を読取り専用に設定できるのはASMインスタンスでのSQLコマンドのみです。SQLでは書込み権限を削除できません。
SQL> ALTER DISKGROUP DATA set permission owner=read ONLY, group=read ONLY, other=none for file 'FILENAME';
これにより、スナップショットが作成され、ベース・ファイル所有者以外のユーザーによって所有されます。
データベースをクローニングしてテスト・マスター・データベースを作成したら、オペレーティング・システム・ユーザーをディスク・グループの所有者として設定し、そのオペレーティング・システム・ユーザーをテスト・マスター・データ・ファイルの所有者にします。
これには、SQLコマンドをSQL*Plusで手動で実行するか、スクリプトを実行します。
次のコマンドをSQL*Plusで実行します。
ディスク・グループの所有者としてオペレーティング・システム・ユーザーを指定します。
SQL> ALTER DISKGROUP DATA ADD USER 'scott';
このオペレーティング・システム・ユーザーをテスト・マスターのデータ・ファイルの所有者にします。
SQL> ALTER DISKGROUP DATA SET OWNERSHIP OWNER='scott' FOR FILE '+DATA/TESTMASTER/DATAFILE/system.257.865863315'; SQL> ALTER DISKGROUP DATA SET OWNERSHIP OWNER='scott' FOR FILE '+DATA/TESTMASTER/DATAFILE/sysaux.258.865863317'; SQL> ALTER DISKGROUP DATA SET OWNERSHIP OWNER='scott' FOR FILE '+DATA/TESTMASTER/DATAFILE/sysext.259.865863317'; SQL> ALTER DISKGROUP DATA SET OWNERSHIP OWNER='scott' FOR FILE '+DATA/TESTMASTER/DATAFILE/tbs_1.256.865863315';
次の手順は、前のコマンドと同じ結果になりますが、ファイル名をv$datafileに問い合せる点が異なります。
ディスク・グループの所有者としてオペレーティング・システム・ユーザーを追加します。
SQL> ALTER DISKGROUP DATA ADD USER 'scott';
set_owner.sqlという名前のスクリプトを生成して、テスト・マスター・データ・ファイルの所有者を設定します。
テスト・マスターがフル・データベースの場合は、テスト・マスター・データベースで次のコマンドを実行します。
set newpage 0 set linesize 999 set pagesize 0 set feedback off set heading off set echo off set space 0 set tab off set trimspool on spool set_owner.sql select 'ALTER DISKGROUP DATA set ownership owner='||''''||'scott'||''''||' for file '||''''||name||''''||';' from v$datafile; exit
テスト・マスターがPDBの場合は、テスト・マスターPDBのCDB$ROOTで次のコマンドを実行します。
次のselect文では、この例のテスト・マスターPDBのcon_idは10と想定しています。
set newpage 0 set linesize 999 set pagesize 0 set feedback off set heading off set echo off set space 0 set tab off set trimspool on spool set_owner.sql select 'ALTER DISKGROUP DATA set ownership owner='||''''||'scott'||''''||' for file '||''''||name||''''||';' from v$datafile where con_id=10; exit
set_owner.sqlの余分な行を削除します。
sed -i '/SQL/d' set_owner.sql
このスクリプトをASMインスタンスで実行します。
SQL> @set_owner
プラガブル・データベース(PDB)またはフル・データベースのExadataスナップショット・データベースを作成できます。
前者はExadataスナップショットPDB、後者はスナップショット・データベース(非CDBまたはCDB)です。
プラガブル・データベース(PDB)のExadataスナップショットの作成は、手動の手順を加える必要がないため、スナップショットの作成の中で最も単純です。CREATE PLUGGABLE DATABASE文に、PDBをExadataスナップショットとして指定する2つの句が新たに追加されました。スナップショット作成プロセスにより、テスト・マスターPDBのファイルが修正されないように、ファイルに対する権限がREADONLYに変更されます。
個々のExadataスナップショットPDBの作成は、指定のCDB内のPDB数が少ない場合にスナップショットを作成するときに最適です。図12-9に、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を作成します。
SQL*Plusでcdb$rootに接続します。
すべてのインスタンスでテスト・マスターPDBをクローズします。
SQL> alter pluggable database PDB1TM1 close instances=all;
ローカル・インスタンスでテスト・マスターPDBを読取り専用モードでオープンします。
SQL> alter pluggable database PDB1TM1 open read only;
このテスト・マスターのExadataスナップショットPDBを作成します。
SQL> create pluggable database PDB1S1 from PDB1TM1 tempfile reuse create_file_dest='+SPARSE' snapshot copy;
create_file_destには、スパース・ディスク・グループの名前を指定する必要があります。こうすることで、Exadataスナップショットのファイルが正しいディスク・グループに作成されます。snapshot copy句によって、フルPDBクローンではなくスナップショットとしてPDBが作成されます。
注意: ExadataスナップショットPDBが作成されるとき、コマンドによって、テスト・マスターPDBに対するファイル権限が変更され、ファイルがASMでREADONLYとしてマークされます。
フル・データベースのExadataスナップショットを作成するのは、テスト・マスター・データベースが非CDBの場合、またはCDBであるが実質すべてのPDBがテストで使用される場合です。
テスト・マスター・データベースは、高可用性または障害時リカバリを提供するフェイルオーバー・ターゲットとして使用できないことに注意してください(Data Guard構成は、別の目的に使用される複数のレプリカを含むことができます)。テスト・マスターPDBと似ていますが、テスト・マスター・データベースは、対応するExadataスナップショットが存在している場合は変更できません。
テスト・マスター・データベースとして、リカバリ・モードの読取り専用スタンバイ・データベース(たとえばリアル・タイム適用のActive Data Guard)を使用することはできません。
テスト・マスター・データベースと対応するExadataスナップショットは、同じASMクラスタ環境に存在する必要があります。
図12-10に、Exadataテスト・マスター・データベースとスナップショット・データベースのライフサイクルを示します。
図12-10 テスト・マスター・データベースおよびスナップショット・データベースのライフサイクル
Exadataスナップショット・データベースを作成および管理するには、次の手順を実行します。
テスト・マスター・データベースで、トレースする既存の制御ファイルをバックアップすることにより、Exadataスナップショット・データベース用のサンプル制御ファイル・スクリプトを作成します。
sysdbaとしてSQL*Plusからテスト・マスター・データベースに接続し、次のコマンドを実行します。
セッションで生成されるすべてのトレース・ファイルの名前と場所を判別します。
SQL> select value from v$diag_info where name = 'Default Trace File'; VALUE -------------------------------------------------------------------------- /u01/app/oracle/diag/rdbms/TESTMASTER/TESTMASTER1/trace/TESTMASTER1_ora_26756.trc
バックアップ制御ファイルを実行してコマンドをトレースし、create controlfileコマンドをトレース・ファイルに含めます。
SQL> alter database backup controlfile to trace;
デフォルト・トレース・ファイルとして示されるファイルを取得します。
テスト・マスター・データベースで、名前を変更する手順(手順9)のために既存のファイル名を判別します。sysdbaとしてSQL*Plusにログインし、次のコマンドを実行します。
set newpage 0
set linesize 999
set pagesize 0
set feedback off
set heading off
set echo off
set space 0
set tab off
set trimspool on
spool rename_files.sql
select 'EXECUTE dbms_dnfs.clonedb_renamefile
('||''''||name||''''||','||''''||replace(replace(replace(name,'.','_'),'TESTMASTER','JOHNTEST'),'DATA','SPARSE')||''''||');' from v$datafile;
exit
前述の問合せにより、次のような、各データ・ファイル用の文を含むrename_files.sqlというファイルが作成されます。
EXECUTE dbms_dnfs.clonedb_renamefile ( '+DATA/TESTMASTER/DATAFILE/system.257.865863315', '+SPARSE/JOHNTEST/DATAFILE/system_257_865863315');
REPLACEは、問合せ内で次にように働きます。
オリジナルのファイル名に含まれるピリオドをアンダースコアに置換
オリジナルのデータベース名のTESTMASTERをJOHNTESTに置換
オリジナルのディスク・グループ名のDATAをSPARSEに置換
テスト・マスターを停止します。
SQL> shutdown;
Exadataスナップショット・データベースのinit.oraファイルを作成します。テスト・マスターのinit.oraファイルをテンプレートとして使用できます。その場合は、db_nameと制御ファイルのエントリを必ず変更してください。この手順では、Exadataスナップショット・データベースのinit.oraファイルは、コマンドおよび例でsnap_init.oraとして参照されます。
$ cp init_TestMaster.ora snap_init.ora
たとえば、snap_init.oraを次のように新しいデータベース名と新しい制御ファイルで変更します。
db_name = JohnTest control_files = '+DATA/JOHNTEST/control1.f'
手順1で生成されたトレース・ファイルを編集して、Exadataスナップショット・データベースの制御ファイルを作成し、後から手順8で実行するcrt_ctlfile.sqlという名前の.sqlファイルを作成します。制御ファイルは、Exadataスナップショット・データベース名、新しいログ・ファイル名、およびテスト・マスターのデータ・ファイル名を使用して作成してください。
この後の例は、制御ファイル作成スクリプトです。JohnTestはExadataスナップショット・データベースです。LOGFILE行は新しいログ・ファイルの場所を指定し、DATAFILE行はテスト・マスター・データベースのデータ・ファイルの場所を指定します。新しいログ・ファイルは、十分な領域がある任意のディスク・グループに格納できますが、スパースASMディスク・グループ内に作成することはできません。
SQL> CREATE CONTROLFILE REUSE SET DATABASE JohnTest RESETLOGS
MAXLOGFILES 32
MAXLOGMEMBERS 2
MAXINSTANCES 1
MAXLOGHISTORY 908
LOGFILE
GROUP 1 '+DATA/JOHNTEST/t_log1.f' SIZE 100M BLOCKSIZE 512,
GROUP 2 '+DATA/JOHNTEST/t_log2.f' SIZE 100M BLOCKSIZE 512
DATAFILE
'+DATA/TESTMASTER/DATAFILE/system.257.865863315',
'+DATA/TESTMASTER/DATAFILE/sysaux.258.865863317',
'+DATA/TESTMASTER/DATAFILE/sysext.259.865863317',
'+DATA/TESTMASTER/DATAFILE/tbs_1.256.865863315'
CHARACTER SET WE8DEC;
audit_file_destディレクトリを作成します。
$ mkdir /u01/app/oracle/admin/johntest
次のコマンドを使用し、Exadataスナップショット・データベースのinit.oraファイルを指定してデータベース・インスタンスを起動します。
SQL> sqlplus / as sysdba SQL> startup nomount pfile=snap_init.ora
手順5で作成されたスクリプトを使用してExadataスナップショット制御ファイルを作成します。次の例ではスクリプトの名前はcrt_ctlfile.sqlです。
SQL> @crt_ctlfile
手順2で変更したスクリプトを実行します。Exadataスナップショット・データベースを開く前に、すべてのファイルの名前を変更する必要があります。SQL*Plusを使用してsysdbaとしてExadataスナップショット・データベースに接続して次のように実行します。
SQL> @rename_files
このスクリプトは、ASMでテスト・マスター・データベース・ファイルの権限を変更し、READONLYとしてマークします。
dbms_dnfs.clonedb_renamefileプロシージャ(rename_files.sqlによって呼び出される)は、テスト・マスター・データベースとスナップショット・データベースの間の親子関係を設定し、スナップショット・データベースの制御ファイル内のファイル名を変更します。
RESETLOGSオプションを指定してExadataスナップショット・データベースを開きます。
SQL> ALTER DATABASE OPEN RESETLOGS;
Exadataスナップショット・ファイルがテスト・マスター・データベースの子ファイルであることを確認します。SQL*Plusを使用してsysasmとしてExadataスナップショットに接続し、次のコマンドを実行します。
SQL> a.select filenumber num, CLONEFILENAME child, SNAPSHOTFILENAME parent from x$ksfdsscloneinfo;
問い合わせの出力例を、次に示します。
NUM CHILD PARENT ------------------------------------------------------------------ 1 +SPARSE/JOHNTEST/DATAFILE/system_257_865863315 +DATA/TESTMASTER/DATAFILE/system.257.865863315 2 +SPARSE/JOHNTEST/DATAFILE/sysaux_258_865863317 +DATA/TESTMASTER/DATAFILE/sysaux.258.865863317 3 +SPARSE/JOHNTEST/DATAFILE/sysext_259_865863317 +DATA/TESTMASTER/DATAFILE/sysext.259.865863317 4 +SPARSE/JOHNTEST/DATAFILE/tbs_1_256_865863315 +DATA/TESTMASTER/DATAFILE/tbs_1.256.865863315
SQL*Plusを使用してExadataスナップショット・データベースにログインし、TEMP表領域に一時ファイルを追加します。これは、スパースではなく、フル・サイズの一時ファイルになります。
SQL> alter tablespace TEMP add tempfile '+DATA' size 10g;
テスト・マスター・データベースをリフレッシュするための主な手順は次のとおりです。
リフレッシュするテスト・マスター・データベースの子であるExadataスナップショット・データベースを削除します。
RMANを使用して削除できます。たとえば、ExadataスナップショットをターゲットとしたRMANを使用して、各Exadataスナップショット・データベースに接続し、次のコマンドを実行します。
RMAN> startup mount force; RMAN> delete database;
注意: Exadataスナップショット・データベースの削除に失敗しても、テスト・マスター・データベースの状態には影響しません。ただし、テスト・マスター・データベースが削除またはリフレッシュされると、Exadataスナップショットで予期しない動作が発生することがあります。
すべてのExadataスナップショット・データベースが削除されたら、テスト・マスター・データベースをマウント・モードで起動します。
テスト・マスターにSQL*Plusを使用して接続し、次のスクリプトを実行して、テスト・マスター・データベースに属するデータ・ファイルの権限をリセットするコマンドを含む新しいSQLスクリプトを作成します。
set newpage 0 set linesize 999 set pagesize 0 set feedback off set heading off set echo off set space 0 set tab off set trimspool on spool change_perm.sql select 'ALTER DISKGROUP DATA set permission owner=read write, group=read write, other=none for file '||''''||name||''''||';' from v$datafile; exit
次のsedコマンドを実行し、前の手順で作成されたchange_perm.sqlスクリプトから余分な行を削除します。change_perm.sqlスクリプトを含むディレクトリで、このコマンドをシェルから実行します。
$ sed -i '/SQL/d' change_perm.sql
SQL*PlusからASMインスタンスにsysasmとして接続し、change_perm.sqlスクリプトを実行します。このスクリプトは、テスト・マスターのデータ・ファイルを書込み可能にするために権限を変更します。
SQL> @change_perm
最初に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の適用を再び無効にしてください。
「テスト・マスター・データベースの設定」の項を参照してください。
「スナップショット・データベースの作成」の項を参照してください。
仮想領域または物理領域(あるいは両方)を必要に応じて増減することができます。物理領域と仮想領域のサイズ変更は同時に行うことができます。
V$ASM_DISKGROUP.FREE_MBまたはV$ASM_DISK.FREE_MBの値が低い場合、仮想アドレス領域を増やす必要があります。
セルで次のコマンドを実行します。
CellCLI> alter griddisk prefix=SPARSE, virtualSize=newSize
例:
CellCLI> alter griddisk prefix=SPARSE, virtualSize=12000G
ASMインスタンスで、ディスク・グループをこの新しいサイズに変更します。
SQL> alter diskgroup SPARSE resize disks in failgroup cel1 size newSize
例:
SQL> alter diskgroup SPARSE resize disks in failgroup cel1 size 12000G
詳細は、http://docs.oracle.com/cd/B28359_01/server.111/b31107/asmdiskgrps.htm#CHDFIHHCを参照してください。
仮想アドレス領域を減らす場合も同じ手順を実行できます。
グリッド・ディスクで物理領域が不足しているとき、つまりV$ASM_DISK_SPARSEのTOTAL_MAT_MB列とALLOCATED_MAT_MB列の値が近いときは、グリッド・ディスクの物理サイズを増やす必要があります。
セルで次のコマンドを実行します。
CellCLI> alter griddisk prefix=SPARSE, size=newPhysicalSize
例:
CellCLI> alter griddisk prefix=SPARSE, size=4000G
ASMインスタンスでは何もする必要はありません。
物理サイズを減らす場合も同じ手順を実行できます。
V$ASM_DISKビューおよびV$ASM_DISKGROUPビューには、仮想サイズとスパースASMディスク・グループの使用率に関する情報が含まれます。新しいビューV$ASM_DISK_SPARSEおよびV$ASM_DISKGROUP_SPARSEには、スパースASMディスク・グループの実際のサイズと使用率に関する情報が含まれます。V$ASM_DISK_SPARSEにもパフォーマンスと使用率のメトリックが含まれます。
表12-1に、V$ASM_DISK_SPARSEの列を示します。
表12-1 V$ASM_DISK_SPARSE
| 列 | 説明 |
|---|---|
|
|
ディスクを含むディスク・グループの番号 |
|
|
このディスク・グループ内のディスクに割り当てられた番号 |
|
|
ディスクのインカネーション番号 |
|
|
このディスクの合計使用済物理容量 |
|
|
このディスクの合計物理容量 |
|
|
このディスクのスパース・リージョンの読取りリクエスト数 |
|
|
このディスクのスパース・リージョンの読取りバイト数 |
|
|
スパース読取りI/Oにかかった時間 |
表12-2にV$ASM_DISKGROUP_SPARSEの列を示します。
表12-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
