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

オンラインハツクアツフ

共同作成者 jfsinmsp
PDF

バックアップモードでOracleデータベースを保護およびリカバリするには、2セットのデータが必要です。これはOracleの唯一のバックアップ・オプションではなく'最も一般的なバックアップ・オプションであることに注意してください

  • バックアップモードでのデータファイルのSnapshot

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

コミットされたすべてのトランザクションを含む完全なリカバリが必要な場合は、3つ目の項目が必要です。

  • 最新のREDOログのセット

オンラインバックアップのリカバリを促進する方法はいくつかあります。多くのお客様は、ONTAP CLIを使用してSnapshotをリストアし、次にOracle RMANまたはsqlplusを使用してリカバリを完了します。これは、データベースをリストアする可能性と頻度が非常に低く、すべてのリストア手順が熟練したデータベース管理者によって処理される大規模な本番環境では特に顕著です。完全な自動化を実現するために、NetApp SnapCenterなどのソリューションには、コマンドラインインターフェイスとグラフィカルインターフェイスの両方を備えたOracleプラグインが含まれています。

一部の大規模なお客様では、スケジュールされたSnapshotに備えて特定の時間にデータベースをバックアップモードにするように、ホストで基本的なスクリプトを設定することで、よりシンプルなアプローチを採用しています。たとえば、次のコマンドをスケジュールします。 alter database begin backup 23時58分、 alter database end backup 00:02に実行し、午前0時にストレージシステム上でSnapshotの直接スケジュールを設定します。その結果、外部のソフトウェアやライセンスを必要としない、シンプルで拡張性に優れたバックアップ戦略が実現します。

データレイアウト

最もシンプルなレイアウトは、データファイルを1つまたは複数の専用ボリューム、LUN、またはNVMeネームスペースに分離することです。ストレージ リソースは、他のファイル タイプによって汚染されていないものでなければなりません。これは、SnapRestore処理によって重要なREDOログ、制御ファイル、またはアーカイブ ログを破壊することなく、データファイルを迅速にリストアできるようにするためです。

SANにおいても、専用リソース内でのデータファイル分離に関して同様の要件が存在する。AFFストレージを使用するMicrosoft Windowsなどのオペレーティング システムの場合、1つのボリュームに複数のデータファイルLUNが含まれる可能性があり、それぞれがNTFSファイル システムを持つ。他のオペレーティング システムでは、一般的に論理ボリューム マネージャが存在する。例えば、Oracle ASMの場合、最も簡単なオプションは、ASMディスク グループのLUNを単一のボリュームに制限し、それを単位としてバックアップおよびリストアできるようにすることである。パフォーマンスや容量管理の理由で追加のボリュームが必要な場合は、新しいボリュームに追加のディスク グループを作成することで、管理がより簡素化される。

ASAには、AFFシステムで複数のLUNをホストできるボリュームレベルの抽象化がありません。その代わり、ASAは整合性グループを使用します。多くの場合、単一のLUNまたはNVMeネームスペースで、データベースの管理およびパフォーマンス要件を満たすことができます。複数のLUNまたはネームスペースが必要な場合は、追加のリソースを追加して整合性グループとして結合し、それをデータファイル コンテナにすることができます。

これらのガイドラインに従えば、Snapshotをストレージ システム上で直接スケジュール設定できます。

注意： ASMが spfile および passwd データファイルをホストしているディスクグループにファイルがありません。これにより、データファイルのみを選択してリストアすることができなくなります。

ローカルリカバリ手順—NFS

この手順は、手動で実行することも、SnapCenterなどのアプリケーションを使用して実行することもできます。基本的な手順は次のとおりです。

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

  2. データファイルNFSボリュームを、目的のリストア ポイントの直前のSnapshotにリカバリします。

  3. アーカイブログを目的のポイントまで再生します。

  4. 完全なリカバリが必要な場合は、現在のREDOログを再生します。

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

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

ローカルリカバリ手順—SAN

この手順は、手動で実行することも、SnapCenterなどのアプリケーションを使用して実行することもできます。基本的な手順は次のとおりです。

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

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

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

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

  5. アーカイブログを目的のポイントまで再生します。

  6. 完全なリカバリが必要な場合は、すべてのREDOログを再生します。

この手順は、目的のアーカイブ ログがまだアクティブ ファイル システムに存在することを前提としています。そうでない場合は、アーカイブ ログ LUN/名前空間を完全にオフラインにしてリストアを実行するか、以前のスナップショットのクローンを作成することによってアーカイブ ログを復元する必要があります（ただし、同じホスト上に重複する UUID または LVM 名が作成されるため、クローン作成は困難な場合があります）。これは、アーカイブ ログを専用のストレージ リソースに分離することが有効であることを示す一例でもあります。アーカイブ ログがリドゥ ログと同じボリューム グループに属している場合、LUN 全体の復元を行う前に、リドゥ ログを別の場所にコピーする必要があります。この手順により、最終的に記録されたトランザクションの損失を防ぐことができます。