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

プライマリストレージでのバックアップのリストア

共同作成者

プライマリストレージにデータベースバックアップをリストアするには、 backup restore コマンドを使用します。

SnapManager でバックアップの全体をリストアするか一部をリストアするかを指定するには、 backup restore コマンドのオプションを使用します。SnapManager では、 1 度のユーザ処理で、データ・ファイルまたは表領域のいずれかと制御ファイルをバックアップからリストアすることもできます。controlfiles と -complete の両方を指定すると、表領域およびデータ・ファイルと同時に制御ファイルをリストアできます。

次のいずれかのオプションを選択して、バックアップをリストアします。

リストアの対象 使用

すべての表領域およびデータ・ファイルを含むバックアップ全体

  • 完了しました

特定の表領域のリスト

  • 表領域

特定のデータ・ファイル

ファイル

制御ファイルのみ

controlfiles

表領域、データ・ファイル、および制御ファイル

-complete-controlfiles 」と入力します

また、 -restorespec を指定して、代替保存場所からバックアップをリストアすることもできます。

-recover を含めると ' データベースを次のようにリカバリできます

  • データベースで実行された最後のトランザクション(すべてのログ)

  • 特定の日時

  • 特定の Oracle System Change Number ( SCN )

  • バックアップした時点(ログを使用しない)

  • リストアのみ

メモ 日時および SCN によるリカバリは、 point-in-time リカバリです。

SnapManager ( 3.2 以降)では、アーカイブ・ログ・ファイルを使用して、リストアされたデータベース・バックアップを自動的にリカバリできます。アーカイブログファイルが外部の場所にある場合でも、 -recover-to-location オプションを指定すると、 SnapManager は外部の場所からアーカイブログファイルを使用して、リストアされたデータベースバックアップをリカバリします。

リストアするバックアップのリカバリに外部アーカイブログの場所を指定する場合は、外部の場所の名前を大文字で指定する必要があります。ファイルシステムでは、すべてのフォルダとサブフォルダ名は大文字である必要があります。これは、 Oracle がデスティネーションパスを大文字に変換し、外部のデスティネーションパス、フォルダ名、サブフォルダ名が大文字であることを前提としているためです。外部アーカイブログのデスティネーションパスを小文字で指定すると、 Oracle は指定されたパスを特定できず、データベースのリストアに失敗することがあります。

SnapManager は、 Oracle の外部の場所を提供します。ただし、 Oracle は外部の保存先からファイルを識別しません。この動作は、フラッシュリカバリ領域のデスティネーションで検出されます。これらは Oracle の問題であり、回避策では、このようなデータベースレイアウトでアーカイブログファイルのバックアップを常に保持しています。

整合性のない SCN または日付を指定した場合、「 Recovery succeeded 」というエラーメッセージが表示され、整合性のある最後の時点でリカバリが停止しますが、不十分です。整合性のある状態へのリカバリは、手動で実行する必要があります。

リカバリでログが適用されない場合、 SnapManager は、バックアップ中に作成された最後のアーカイブログファイルの最後の SCN までリカバリします。この SCN までデータベースに整合性がある場合、データベースは正常にオープンされます。この時点でデータベースに整合性がない場合、 SnapManager はデータベースのオープンを試行します。データベースに整合性がある場合は、このデータベースが正常にオープンされます。

メモ SnapManager では、アーカイブログのみのバックアップのリカバリはサポートされていません。

アーカイブログデスティネーションが Snapshot に対応していない場合、 SnapManager を使用すると、プロファイルを使用して、リストアしたデータベースバックアップをリカバリできます。非 Snapshot 対応ストレージで SnapManager 処理を実行する前に、 smo .config に archivedLogs.exclude のデスティネーションを追加する必要があります。

プロファイルを作成する前に、除外パラメータを設定する必要があります。SnapManager 構成ファイルで除外パラメータを設定した場合にのみ、プロファイルの作成が成功します。

バックアップがすでにマウントされている場合、 SnapManager はバックアップを再マウントせず、すでにマウントされているバックアップを使用します。バックアップが別のユーザによってマウントされている場合、現在のユーザが以前にマウントされたバックアップにアクセスできないときは、他のユーザがその権限を提供する必要があります。すべてのアーカイブログファイルには、グループ所有者に対する読み取り権限が設定されています。バックアップが別のユーザグループでマウントされている場合、現在のユーザには権限が付与されないことがあります。ユーザは、マウントされたアーカイブログファイルに対する権限を手動で付与して、リストアまたはリカバリを再試行できます。

オプションのパラメータとして -dump オプションを指定すると、リストア処理の成功後または失敗後にダンプファイルを収集できます。

  1. 次のコマンドを入力します。 smo backup restore -profile profile_name -label label-complete-recover-alllogs [-recover-from-locationpath[、 path2]] -dump -verbose

    smo backup restore -profile targetdb1_prof1 -label full_bkup_sales_Nov_08 -complete-recover-alllogs -verbose

  2. さまざまなシナリオでデータをリストアするには、次のいずれかを実行します。

    リストアの対象 コマンド例
    • 制御ファイルを含まない完全なデータベース。特定の SCN 番号( 3794392 )にリカバリ。この場合、現在の制御ファイルは存在しますが、すべてのデータファイルが破損しているか失われています。既存のオンラインフルバックアップから、その SCN の直前の時点までデータベースをリストアおよびリカバリします。 *

    smo backup restore -profile targetdb1_prof1 -label full_bkup_sales_Nov_08 -complete-recover - until 3794392 -verbose

    • 制御ファイルなしでデータベースを完了し、日付と時刻までリカバリします。 *

    smo backup restore -profile targetdb1_prof1 -label full_bkup_sales_Nov_08 -complete-recover -until 2008-09-15 : 15 : 29 : 23 -verbose

    • 制御ファイルなしでデータベース全体を完了し、データと時間までリカバリできます。この場合、現在の制御ファイルは存在しますが、すべてのデータファイルが破損したり失われたり、特定の時間が経過した後に論理エラーが発生したりします。データベースをリストアし、障害発生時点の直前の日時に、既存のオンラインフルバックアップからリカバリします。 *

    smo backup restore -profile targetdb1_prof1 -label full_bkup_sales_Nov_08 -complete-recover until "2008-09-15 : 15 : 29 : 23" -verbose

    • 制御ファイルを含まない部分的なデータベース( 1 つ以上のデータ・ファイル)と、使用可能なすべてのログを使用してリカバリします。この場合、現在の制御ファイルは存在しますが、 1 つ以上のデータファイルが破損したり失われたりします。これらのデータ・ファイルをリストアし、使用可能なすべてのログを使用して、既存のフル・オンライン・バックアップからデータベースをリカバリします。 *

    smo backup restore -profile targetdb1_prof1 -label full_bkup_sales_Nov_08 -files E : \disks \S02.dbf E : \disks \sales03.dbf E : \disks \sales04.dbf -recovery-alllogs -verbose

    • 制御ファイルを含まない部分的なデータベース( 1 つまたは複数の表領域)と、使用可能なすべてのログを使用したリカバリ。この場合、現在の制御ファイルは存在しますが、 1 つ以上の表領域が削除されたか、表領域に属する 1 つ以上のデータ・ファイルが破損したり失われたりします。これらの表領域をリストアし、使用可能なすべてのログを使用して、既存のオンライン・フル・バックアップからデータベースをリカバリします。 *

    smo backup restore -profile targetdb1_prof1 -label full_bkup_sales_Nov_08 -tablespaces users -recover-alllogs -verbose

    • 制御ファイルのみを管理し、使用可能なすべてのログを使用してリカバリします。この場合、データファイルは存在しますが、制御ファイルはすべて破損しているか失われています。制御ファイルだけをリストアし、使用可能なすべてのログを使用して、既存のフルオンラインバックアップからデータベースをリカバリします。 *

    smo backup restore -profile targetdb1_prof1 -label full_bkup_sales_Nov_08 -controlfiles -recover-alllogs -verbose

    • 制御ファイルなしでデータベースを完全に作成し、バックアップ制御ファイルと使用可能なすべてのログを使用してリカバリします。この場合、すべてのデータファイルが破損しているか失われています。制御ファイルだけをリストアし、使用可能なすべてのログを使用して、既存のフルオンラインバックアップからデータベースをリカバリします。 *

    smo backup restore -profile targetdb1_prof1 -label full_bkup_sales_Nov_08 -complete-using-backup-controlfile -recover-alllogs -verbose

    • アーカイブ・ログ・ファイルを使用して ' リストアされたデータベースを外部アーカイブ・ログの場所からリカバリします *

    smo backup restore -profile targetdb1_prof1 -label full_bkup_sales_Nov_08 -complete-using-backup-controlfile -recover-alllogs -recoverfrom -location E : \archive -verbose

  3. -recover-to-location オプションを使用して、外部アーカイブログの場所を指定します。

    • 関連情報 *