ストレージSnapshotで最適化されたバックアップ
変更を提案
PDF
Oracle 12cがリリースされた時点では、データベースをホットバックアップモードにする必要がないため、Snapshotベースのバックアップとリカバリはさらにシンプルになりました。そのため、Snapshotベースのバックアップをストレージシステム上で直接スケジュール設定しても、完全なリカバリやポイントインタイムリカバリを引き続き実行できます。
データベース管理者にとってはホットバックアップリカバリの手順の方がなじみがありますが、データベースがホットバックアップモードのときに作成されなかったSnapshotを使用することは以前から可能でした。Oracle 10gおよび11gでは、データベースの整合性を維持するために、リカバリ時に手動で追加の手順を実行する必要がありました。Oracle 12cでは、 sqlplus および rman ホットバックアップモードではないデータファイルバックアップでアーカイブログを再生するための追加ロジックが含まれています。
前述したように、スナップショットベースのホットバックアップをリカバリするには、次の2セットのデータが必要です。
-
バックアップモードで作成されたデータファイルのSnapshot
-
データファイルがホットバックアップモードのときに生成されたアーカイブログ
リカバリ中、データベースはデータファイルからメタデータを読み取り、リカバリに必要なアーカイブログを選択します。
ストレージSnapshotを最適化したリカバリでは、同じ結果を達成するために必要なデータセットがわずかに異なります。
-
データファイルのSnapshot、およびSnapshotが作成された時刻を識別する方法
-
最新のデータファイルチェックポイントの時刻からSnapshotの正確な時刻までのログをアーカイブします。
リカバリ中、データベースはデータファイルからメタデータを読み取り、必要な最も古いアーカイブログを特定します。フルリカバリまたはポイントインタイムリカバリを実行できます。ポイントインタイムリカバリを実行する場合は、データファイルのSnapshotの時刻を把握することが重要です。指定したリカバリポイントは、Snapshotの作成時刻以降である必要があります。NetAppでは、クロックの変動を考慮して、スナップショット時間に少なくとも数分を追加することを推奨しています。
詳細については、Oracle 12cの各種ドキュメントで「Recovery Using Storage Snapshot Optimization」のトピックを参照してください。また、Oracleサードパーティ製スナップショットのサポートについては、OracleのドキュメントID Doc ID 604683.1を参照してください。
データレイアウト
最もシンプルなレイアウトは、データファイルを専用のボリューム、LUN、またはNVMeネームスペースに分離することです。ストレージ リソースは、他のファイル タイプによって汚染されていない状態である必要があります。これは、重要なREDOログ、コントロール ファイル、またはアーカイブ ログを破壊することなく、SnapRestore処理によってデータファイルを迅速にリストアできるようにするためです。
SANにおいても、専用リソース内でのデータファイル分離に関して同様の要件が存在する。AFFストレージを使用するMicrosoft Windowsなどのオペレーティング システムの場合、1つのボリュームに複数のデータファイルLUNが含まれる可能性があり、それぞれがNTFSファイル システムを持つ。他のオペレーティング システムでは、一般的に論理ボリューム マネージャが存在する。例えば、Oracle ASMの場合、最も簡単なオプションは、ASMディスク グループのLUNを単一のボリュームに制限し、それを単位としてバックアップおよびリストアできるようにすることである。パフォーマンスや容量管理の理由で追加のボリュームが必要な場合は、新しいボリュームに追加のディスク グループを作成することで、管理がより簡素化される。
ASAにはボリュームレベルの抽象化は備えていません。代わりに、整合性グループを使用します。多くの場合、単一のLUNまたはNVMeネームスペースで、データベースの管理およびパフォーマンス要件を満たすことができます。複数のLUNまたはネームスペースが必要な場合は、追加のリソースを追加して整合性グループとして結合し、それをデータファイルコンテナにすることができます。
これらのガイドラインに従えば、Snapshotをストレージ システム上で直接スケジュール設定できます。
注意： ASMが spfile および passwd データファイルをホストしているディスクグループにファイルがありません。これにより、データファイルのみを選択してリストアすることができなくなります。
ローカルリカバリ手順—NFS
この手順は、手動で実行することも、SnapCenterなどのアプリケーションを使用して実行することもできます。基本的な手順は次のとおりです。
-
データベースをシャットダウンします。
-
データファイルボリューム、LUN、またはネームスペースを、目的の復元ポイントの直前のSnapshotに復元します。
-
アーカイブログを目的のポイントまで再生します。
この手順では、目的のアーカイブログがアクティブファイルシステムにまだ存在していることを前提としています。サポートされていない場合は、アーカイブログをリストアする必要があります。または、 rman または sqlplus のデータに転送できます。 .snapshot ディレクトリ。
また、小規模なデータベースの場合は、エンドユーザがデータファイルを .snapshot SnapRestoreコマンドを実行するための自動化ツールやストレージ管理者の支援がないディレクトリ。
ローカルリカバリ手順—SAN
この手順は、手動で実行することも、SnapCenterなどのアプリケーションを使用して実行することもできます。基本的な手順は次のとおりです。
-
データベースをシャットダウンします。
-
データファイルをホストしているディスクグループを休止します。手順は、選択した論理ボリュームマネージャによって異なります。ASMでは、このプロセスでディスクグループをディスマウントする必要があります。Linuxでは、ファイルシステムをディスマウントし、論理ボリュームとボリュームグループを非アクティブ化する必要があります。目的は、リストア対象のターゲットボリュームグループに対するすべての更新を停止することです。
-
目的のリストアポイントの直前に、データファイルディスクグループをSnapshotにリストアします。
-
新しくリストアしたディスクグループを再アクティブ化します。
-
アーカイブログを目的のポイントまで再生します。
この手順は、目的のアーカイブ ログがまだアクティブ ファイル システムに存在することを前提としています。そうでない場合は、アーカイブログLUNをオフラインにしてリストアを実行することで、アーカイブログを復元する必要があります。これは、アーカイブログを専用のボリューム、LUN、または名前空間に分割することが有効な例の一つです。アーカイブログがリドゥログと同じボリュームグループを共有している場合、最終的に記録されたトランザクションが失われるのを避けるため、LUN全体の復元を行う前にリドゥログを別の場所にコピーする必要があります。
フルリカバリの例
データファイルが破損または破壊されており、完全なリカバリが必要であると仮定します。そのための手順は次のとおりです。
[oracle@host1 ~]$ sqlplus / as sysdba Connected to an idle instance. SQL> startup mount; ORACLE instance started. Total System Global Area 1610612736 bytes Fixed Size 2924928 bytes Variable Size 1040191104 bytes Database Buffers 553648128 bytes Redo Buffers 13848576 bytes Database mounted. SQL> recover automatic; Media recovery complete. SQL> alter database open; Database altered. SQL>
ポイントインタイムリカバリの例
リカバリ手順全体は1つのコマンドで実行できます。 recover automatic。
ポイントインタイムリカバリが必要な場合は、Snapshotのタイムスタンプがわかっている必要があり、次のように特定できます。
Cluster01::> snapshot show -vserver vserver1 -volume NTAP_oradata -fields create-time vserver volume snapshot create-time -------- ------------ --------- ------------------------ vserver1 NTAP_oradata my-backup Thu Mar 09 10:10:06 2017
Snapshotの作成時間は3月9日と10：10：06と表示されます。安全のために、Snapshotの時刻に1分が追加されます。
[oracle@host1 ~]$ sqlplus / as sysdba Connected to an idle instance. SQL> startup mount; ORACLE instance started. Total System Global Area 1610612736 bytes Fixed Size 2924928 bytes Variable Size 1040191104 bytes Database Buffers 553648128 bytes Redo Buffers 13848576 bytes Database mounted. SQL> recover database until time '09-MAR-2017 10:44:15' snapshot time '09-MAR-2017 10:11:00';
リカバリが開始されました。スナップショット時間は記録された時間の1分後の10：11：00、目標復旧時間は10：44と指定されています。次に、sqlplusは目的のリカバリ時間（10：44）に到達するために必要なアーカイブログを要求します。
ORA-00279: change 551760 generated at 03/09/2017 05:06:07 needed for thread 1
ORA-00289: suggestion : /oralogs_nfs/arch/1_31_930813377.dbf
ORA-00280: change 551760 for thread 1 is in sequence #31
Specify log: {<RET>=suggested | filename | AUTO | CANCEL}
ORA-00279: change 552566 generated at 03/09/2017 05:08:09 needed for thread 1
ORA-00289: suggestion : /oralogs_nfs/arch/1_32_930813377.dbf
ORA-00280: change 552566 for thread 1 is in sequence #32
Specify log: {<RET>=suggested | filename | AUTO | CANCEL}
ORA-00279: change 553045 generated at 03/09/2017 05:10:12 needed for thread 1
ORA-00289: suggestion : /oralogs_nfs/arch/1_33_930813377.dbf
ORA-00280: change 553045 for thread 1 is in sequence #33
Specify log: {<RET>=suggested | filename | AUTO | CANCEL}
ORA-00279: change 753229 generated at 03/09/2017 05:15:58 needed for thread 1
ORA-00289: suggestion : /oralogs_nfs/arch/1_34_930813377.dbf
ORA-00280: change 753229 for thread 1 is in sequence #34
Specify log: {<RET>=suggested | filename | AUTO | CANCEL}
Log applied.
Media recovery complete.
SQL> alter database open resetlogs;
Database altered.
SQL>
|
Snapshotを使用してデータベースを完全にリカバリするには、 recover automatic コマンドには特定のライセンスは不要ですが、を使用してポイントインタイムリカバリを実行できます。 snapshot time Oracle Advanced Compressionのライセンスが必要です。
|