Skip to main content
Enterprise applications
日本語は機械翻訳による参考訳です。内容に矛盾や不一致があった場合には、英語の内容が優先されます。

バックアップモードなしのOracle自動リカバリ

PDF

Oracle 12c がリリースされたとき、データベースをホット バックアップモードに切り替える必要がなくなったため、スナップショットベースのバックアップとリカバリがさらに簡単になりました。その結果、スナップショットベースのバックアップをストレージシステム上で直接スケジュール設定することが可能になりました。

データベース管理者にとってはホットバックアップリカバリの手順の方がなじみがありますが、データベースがホットバックアップモードのときに作成されなかったSnapshotを使用することは以前から可能でした。Oracle 10gおよび11gでは、データベースの整合性を維持するために、リカバリ時に手動で追加の手順を実行する必要がありました。Oracle 12cでは、 sqlplus および rman ホットバックアップモードではないデータファイルバックアップでアーカイブログを再生するための追加ロジックが含まれています。

前述したように、スナップショットベースのホットバックアップをリカバリするには、次の2セットのデータが必要です。

  • バックアップモードで作成されたデータファイルのSnapshot

  • データファイルがホットバックアップモードのときに生成されたアーカイブログ

リカバリ中、データベースはデータファイルからメタデータを読み取り、リカバリに必要なアーカイブログを選択します。

バックアップモードを使用しない自動復旧では、同じ結果を得るために若干異なるデータセットが必要になります：

  • データファイルのスナップショット。

  • 同期されたアーカイブログ、制御ファイル、およびリドゥログのセット。アーカイブログには、データファイルのスナップショットが作成された時点からのすべてのレコードを含める必要があるため、積極的なログの削除には注意してください。

復旧処理中、データベースはデータファイルからメタデータを読み取り、必要なログレコードを特定し、記録されたすべてのトランザクションを再生します。

注：

このアプローチはポイントインタイムリカバリに近似できますが、詳細度は限られています。例えば、バックアップモードのデータファイルから開始した場合、データベースを任意のトランザクションまでロールフォワードすることができます。

バックアップモードを使用せずに自動復旧方式を使用する場合は、データベースをログスナップショットの時点まで復旧する必要があります。通常の状況では、元のアーカイブログ、リドゥログ、および制御ファイルはアクティブなファイルシステムに残っているため、RPO は依然としてゼロになります。アクティブなファイルシステム内のすべてのデータが失われ、スナップショットからのみ復旧を行う必要がある場合、RPO は 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 基本的な手順は次のとおりです：

  1. データベースをシャットダウンします。

  2. データファイルボリューム、LUN、またはネームスペースを、目的の復元ポイントの直前のSnapshotに復元します。

  3. 実行 alter database automatic;

この手順では、目的のアーカイブログがアクティブファイルシステムにまだ存在していることを前提としています。サポートされていない場合は、アーカイブログをリストアする必要があります。または、 rman または sqlplus のデータに転送できます。 .snapshot ディレクトリ。

また、小規模なデータベースの場合は、エンドユーザがデータファイルを .snapshot SnapRestoreコマンドを実行するための自動化ツールやストレージ管理者の支援がないディレクトリ。

== ローカル復旧手順 - SAN 基本的な手順は次のとおりです：

  1. データベースをシャットダウンします。

  2. データファイルをホストしているディスクグループを休止します。手順は、選択した論理ボリュームマネージャによって異なります。ASMでは、このプロセスでディスクグループをディスマウントする必要があります。Linuxでは、ファイルシステムをディスマウントし、論理ボリュームとボリュームグループを非アクティブ化する必要があります。目的は、リストア対象のターゲットボリュームグループに対するすべての更新を停止することです。

  3. 目的のリストアポイントの直前に、データファイルディスクグループをSnapshotにリストアします。

  4. 新しくリストアしたディスクグループを再アクティブ化します。

  5. 実行 alter database automatic;

この手順は、目的のアーカイブ ログがまだアクティブ ファイル システムに存在することを前提としています。そうでない場合は、アーカイブログ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>