Skip to main content
SnapCenter Software 4.6
本製品の最新リリースがご利用いただけます。
日本語は機械翻訳による参考訳です。内容に矛盾や不一致があった場合には、英語の内容が優先されます。

Oracle データベースのバックアップ戦略を定義する

共同作成者

バックアップジョブを作成する前にバックアップ戦略を定義しておくと、データベースの正常なリストアやクローニングに必要なバックアップを確実に作成できます。バックアップ戦略の大部分は、サービスレベルアグリーメント( SLA )、目標復旧時間( RTO )、および目標復旧時点( RPO )によって決まります。

SLA では、サービスの可用性やパフォーマンスなど、サービス関連の多くの問題に対処するために必要なサービスレベルを定義します。RTO は、サービスの停止からビジネスプロセスの復旧までに必要となる時間です。RPO は、障害発生後に通常処理を再開するためにバックアップストレージからリカバリする必要があるファイルの経過時間に関する戦略を定義したものです。SLA 、 RTO 、および RPO は、データ保護戦略に関与します。

バックアップ対象としてサポートされる Oracle データベース構成

SnapCenter では、各種の Oracle データベース構成のバックアップがサポートされます。

  • Oracle スタンドアロン構成

  • Oracle Real Application Clusters ( RAC )

  • Oracle スタンドアロンレガシーです

  • Oracle スタンドアロンコンテナデータベース( CDB )

  • Oracle Data Guard スタンバイ

    Data Guard スタンバイデータベースのオフラインマウントバックアップだけを作成できます。オフラインシャットダウンバックアップ、アーカイブログのみのバックアップ、およびフルバックアップはサポートされていません。

  • Oracle Active Data Guard スタンバイ

    Active Data Guard スタンバイデータベースのオンラインバックアップだけを作成できます。アーカイブログのみのバックアップとフルバックアップはサポートされていません。

    メモ Data Guard スタンバイデータベースまたは Active Data Guard スタンバイデータベースのバックアップを作成する前に、管理されたリカバリプロセス( MRP )が停止し、バックアップが作成されたあとに MRP が開始されます。
  • Automatic Storage Management ( ASM ;自動ストレージ管理)

    • 仮想マシンディスク( VMDK )上の ASM スタンドアロンおよび ASM RAC

      メモ Oracle データベースでサポートされるどのリストア方式でも、 VMDK 上で実行できるのは ASM RAC データベースの Connect and Copy リストアだけです。
    • raw デバイスマッピング( RDM )上の ASM スタンドアロンおよび ASM RAC では、 ASM 上の Oracle データベースに対して、 ASMLib の有無に関係なく、バックアップ、リストア、クローニングの各処理を実行できます。

    • Oracle ASM フィルタドライバ (ASMFD)

      メモ PDB 移行処理と PDB クローニング処理はサポートされていません。
    • Oracle Flex ASM

サポートされている Oracle のバージョンの最新情報については、を参照してください "NetApp Interoperability Matrix Tool で確認できます"

Oracle データベースでサポートされるバックアップのタイプ

バックアップタイプでは、作成するバックアップのタイプを指定します。SnapCenter では、 Oracle データベースに対してオンラインバックアップタイプとオフラインバックアップタイプがサポートされます。

オンラインバックアップ

データベースがオンライン状態のときに作成されるバックアップを、オンラインバックアップと呼びます。ホットバックアップとも呼ばれるオンラインバックアップでは、データベースをシャットダウンすることなくバックアップを作成できます。

オンラインバックアップでは、次のファイルのバックアップを作成できます。

  • データファイルと制御ファイルのみ

  • アーカイブログファイルのみ(この場合はデータベースがバックアップモードになりません)

  • データファイル、制御ファイル、アーカイブログファイルを含むフルデータベース

オフラインバックアップ

データベースがマウント済み状態またはシャットダウン状態のときに作成されるバックアップを、オフラインバックアップと呼びます。オフラインバックアップはコールドバックアップとも呼ばれます。オフラインバックアップにはデータファイルと制御ファイルのみを含めることができます。オフラインマウントバックアップまたはオフラインシャットダウンバックアップのいずれかを作成できます。

  • オフラインマウントバックアップを作成する場合は、データベースがマウント済み状態であることを確認する必要があります。

    データベースがそれ以外の状態の場合は、バックアップ処理が失敗します。

  • オフラインシャットダウンバックアップを作成する場合、データベースはどの状態でもかまいません。

    データベースは、バックアップを作成するために必要な状態に変更されます。バックアップが作成されると、データベースは元の状態に戻ります。

SnapCenter による Oracle データベースの検出方法

「リソース」とは、 SnapCenter で管理されているホスト上の Oracle データベースのことです。使用可能なデータベースを検出したあとに、それらのデータベースをリソースグループに追加してデータ保護処理を実行できます。SnapCenter がさまざまなタイプやバージョンの Oracle データベースを検出するプロセスについて理解しておく必要があります。

Oracle バージョン 11___ ~ 12_c_R1 Oracle バージョン 12_c_R2 から 18_c_c__

*RAC データベース *: RAC データベースは /etc/oratab エントリに基づいてのみ検出されます。

/etc/oratab ファイル内にデータベース・エントリが必要です。

*RAC データベース *: srvctl config コマンドを使用して RAC データベースが検出されます。

  • スタンドアロン * :スタンドアロン・データベースは、 /etc/oratab エントリに基づいてのみ検出されます。

/etc/oratab ファイル内にデータベース・エントリが必要です。

  • Standalone * : /etc/oratab ファイル内のエントリおよび srvctl config コマンドの出力に基づいて、スタンドアロンデータベースが検出されます。

ASM: ASM インスタンス・エントリは、 /etc/oratab ファイル内に存在する必要があります。

ASM: ASM インスタンス・エントリは、 /etc/oratab ファイル内に存在する必要はありません。

  • RAC One Node * : RAC One Node データベースは、 /etc/oratab エントリに基づいてのみ検出されます。

データベースは、 nomountmount、 または _open_state のいずれかである必要があります。/etc/oratab ファイル内にデータベース・エントリが必要です。

データベースがすでに検出され、バックアップが関連付けられている場合、 RAC One Node データベースのステータスは「 Renamed 」または「 deleted 」とマークされます。

データベースを再配置する場合は、次の手順を実行する必要があります。

  1. フェイルオーバーが発生した RAC ノードの /etc/oratab ファイルに、再配置されたデータベース・エントリを手動で追加します。

  2. リソースを手動で更新する。

  3. リソースページから RAC One Node データベースを選択し、 * Database Settings * (データベース設定)をクリックします。

  4. データベースを設定して、データベースを現在ホストしている RAC ノードに優先クラスタノードを設定します。

  5. SnapCenter 処理を実行します。

メモ あるノードから別のノードにデータベースを再配置した場合、および以前のノード内の oratab エントリが削除されていない場合は、同じデータベースが 2 回表示されないように、 oratab エントリを手動で削除する必要があります。
  • RAC One Node * : srvctl config コマンドのみを使用して、 RAC One Node データベースを検出します。

データベースは、 nomountmount、 または _open_state のいずれかである必要があります。データベースがすでに検出され、バックアップが関連付けられている場合、 RAC One Node データベースのステータスは「 Renamed 」または「 deleted 」とマークされます。

データベースを再配置する場合は、次の手順を実行する必要があります。

  1. リソースを手動で更新する。

  2. リソースページから RAC One Node データベースを選択し、 Database Settings をクリックします。

  3. データベースを設定して、データベースを現在ホストしている RAC ノードに優先クラスタノードを設定します。

  4. SnapCenter 処理を実行します。

メモ /etc/oratab ファイル内に Oracle 12_c__R2 および 18_c_database のエントリがあり、同じデータベースが srvctl config コマンドで登録されている場合、 SnapCenter は重複するデータベースエントリを削除します。古いデータベースエントリがある場合は、データベースは検出されますが、データベースにアクセスできず、ステータスはオフラインになります。

RAC セットアップで優先ノードを指定します

Oracle Real Application Clusters ( RAC )セットアップでは、バックアップ処理が実行される優先ノードを指定できます。優先ノードを指定しない場合は、 SnapCenter によって自動的に優先ノードが割り当てられ、そのノードにバックアップが作成されます。

優先ノードには、 RAC データベースインスタンスが存在するクラスタノードを 1 つまたはすべて指定できます。バックアップ処理は、これらの優先ノードで優先順位に従ってトリガされます。

例: RAC データベース cdbrac に 3 つのインスタンスがあります。 cdbrac1 on node1 、 cdbrac2 on node2 、および cdbrac3 on node3node1 インスタンスと node2 インスタンスが優先ノードとして設定され、 node2 に最初の優先順位、 node1 に 2 番目の優先順位が指定されます。バックアップ処理を実行すると、まず第 1 優先ノードである node2 で処理が試行されます。node2 がバックアップの状態になっていない場合は、プラグインエージェントがホストで実行されていないなどの複数の理由で、ホスト上のデータベースインスタンスが指定したバックアップタイプに必要な状態になっていない可能性があります。 または、 FlexASM 構成内の node2 上のデータベースインスタンスがローカル ASM インスタンスで提供されていない場合は、 node1 で処理が試行されます。node3 は、優先ノードのリストに含まれていないため、バックアップには使用されません。

Flex ASM 設定では、カード濃度が RAC クラスタ内のノード数より少ない場合、リーフノードは優先ノードとして表示されません。Flex ASM クラスタノードのロールに変更がある場合は、優先ノードが更新されるように、手動で検出する必要があります。

必要なデータベースの状態

バックアップを正常に完了するには、優先ノード上の RAC データベースインスタンスが必要な状態であることが必要です。

  • オンラインバックアップを作成する場合は、設定された優先ノードの RAC データベースインスタンスの 1 つがオープン状態であることが必要です。

  • オフラインマウントバックアップを作成する場合は、設定された優先ノードの RAC データベースインスタンスの 1 つがマウント状態であり、かつ他の優先ノードを含むその他すべてのインスタンスがマウント状態またはそれより低いレベルの状態であることが必要です。

  • オフラインシャットダウンバックアップを作成する場合は、 RAC データベースインスタンスはどの状態でもかまいませんが、優先ノードを指定する必要があります。

Oracle Recovery Manager を使用してバックアップをカタログ化する方法

Oracle Recovery Manager ( RMAN )で Oracle データベースのバックアップをカタログ化することにより、 Oracle RMAN リポジトリにバックアップ情報を保存できます。

カタログ化されたバックアップは、あとでブロックレベルのリストア処理や表領域のポイントインタイムリカバリ処理に使用できます。カタログ化されたバックアップが不要となった場合は、カタログ情報を削除できます。

カタログ化するためには、データベースの状態が少なくともマウント済み状態であることが必要です。カタログ化を実行できるのは、データバックアップ、アーカイブログバックアップ、およびフルバックアップです。複数のデータベースを含むリソースグループのバックアップに対してカタログ化を有効にすると、データベースごとにカタログ化が実行されます。Oracle RAC データベースの場合は、データベースが少なくともマウント済み状態にある優先ノードでカタログ化が実行されます。

メモ RAC データベースのバックアップをカタログ化する場合は、そのデータベースに対して他のジョブが実行されていないことを確認します。別のジョブが実行されている場合は、カタログ化処理がキューに登録されずに失敗します。

デフォルトでは、ターゲットデータベースの制御ファイルがカタログ化に使用されます。外部カタログデータベースを追加する場合は、 SnapCenter グラフィカルユーザーインタフェース( GUI )のデータベース設定ウィザードを使用して、外部カタログの資格情報と透過ネットワーク印刷材( TNS )名を指定して構成できます。CLI から外部カタログデータベースを設定するには、 Configure-SmOracleDatabase コマンドで -OracleRmanCatalogCredentialName オプションおよび -OracleRmanCatalogTnsName オプションを実行します。

SnapCenter GUI から Oracle バックアップポリシーを作成する際にカタログ化オプションを有効にした場合は、バックアップ処理の一環として Oracle RMAN を使用してバックアップがカタログ化されます。バックアップのカタログ化は、 Catalog-SmBackupWithOracleRMAN コマンドを実行して遅延させることもできます。バックアップをカタログ化したら、 Get-SmBackupDetails コマンドを実行して、カタログ化されたデータファイルのタグ、制御ファイルカタログのパス、カタログ化されたアーカイブログの場所などのカタログ化されたバックアップ情報を取得できます。

SnapCenter 3.0 では、 ASM ディスクグループ名が 16 文字以上である場合、バックアップに使用される命名形式は SC_HASHCODEofDISKGROUP_DBSID_backupid です。ただし、ディスク・グループ名が 16 文字未満の場合、バックアップに使用される命名形式は DISKGROUPNAME_DBSID_backupid です。これは、 SnapCenter 2.0 で使用される形式と同じです。

メモ HASHCODEofDISKGROUP は、各 ASM ディスクグループに固有の自動生成番号( 2 ~ 10 桁)です。

バックアップに関する RMAN リポジトリ情報が古くなってバックアップのリポジトリレコードがその物理ステータスと一致しなくなった場合は、クロスチェックを実行してリポジトリ情報を更新できます。たとえば、ユーザがオペレーティングシステムコマンドでディスクからアーカイブログを削除した場合、実際にはディスクにログがないにもかかわらず、制御ファイルにはディスクにログがあることが示されます。クロスチェック処理では、制御ファイルを情報で更新できます。クロスチェックをイネーブルにするには、 Set-SmConfigSettings コマンドを実行して、 enable_croscHCK パラメータに値 true を割り当てます。デフォルト値は FALSE です。

'scli Set-SmConfigSettings - ConfigSettingsTypePlugin - PluginCodeSCO-ConfigSettings" key=enable_CROSCHECK 、 value=true"

カタログ情報を削除するには、 Uncatalog-SmBackupWithOracleRMAN コマンドを実行します。SnapCenter GUI ではカタログ情報を削除できません。ただし、バックアップを削除するとき、またはカタログ化されたバックアップに関連する保持設定とリソースグループを削除するときに、カタログ化されたバックアップの情報も削除されます。

メモ SnapCenter ホストを強制的に削除する場合は、そのホストに関連するカタログ化されたバックアップの情報が削除されません。ホストを強制的に削除する場合は、事前にそのホストに関連するすべてのカタログ化されたバックアップの情報を削除しておく必要があります。

ORACLE_PLUGIN_RMAN_CATALE_TIMEOUT パラメータに指定されたタイムアウト値を超えたためにカタログ化とカタログ化解除が失敗した場合は、次のコマンドを実行して、パラメータの値を変更する必要があります。

`/opt/NetApp/snapcenter /spl/bin/sccli Set-SmConfigSettings - 構成設定タイププラグイン - プラグインコード sc-ConfigSettings" key=oracle_plugin_rman_catala_catalog_timeout 、 value=user_defined_value"

パラメータの値を変更したら、次のコマンドを実行して SnapCenter Plug-in Loader ( SPL )サービスを再起動します。

'/opt/NetApp/SnapCenter /spl/bin/spl restart

コマンドで使用できるパラメータとその説明に関する情報は、 Get-Help コマンド _name を実行して取得できます。または、を参照することもできます "SnapCenter ソフトウェアコマンドリファレンスガイド"

バックアップスケジュール

バックアップ頻度(スケジュールタイプ)はポリシーで指定され、バックアップスケジュールはリソースグループの設定で指定されます。バックアップの頻度またはスケジュールを決定する場合に最も重要な要因となるのは、リソースの変更率とデータの重要性です。使用頻度の高いリソースは 1 時間ごとにバックアップする必要がありますが、ほとんど使用されないリソースは 1 日に 1 回バックアップすれば十分です。その他の要因としては、組織におけるリソースの重要性、サービスレベルアグリーメント( SLA )、目標復旧時点( RPO )などがあります。

SLA は、想定されるサービスのレベルを定義し、サービスの可用性やパフォーマンスなど、サービス関連の多くの問題に対処します。RPO は、障害発生後に通常処理を再開するためにバックアップストレージからリカバリする必要があるファイルの経過時間に関する戦略を定義したものです。SLA と RPO は、データ保護戦略に関与します。

使用頻度の高いリソースであっても、フルバックアップは 1 日に 1~2 回で十分です。たとえば、定期的なトランザクションログバックアップを実行すれば、必要なバックアップが作成されます。データベースをバックアップする回数が多いほど、リストア時に SnapCenter が使用する必要のあるトランザクションログの数が少なくなります。これにより、リストア処理の時間を短縮できます。

バックアップスケジュールには、次の 2 つの要素があります。

  • バックアップ頻度

    バックアップ頻度(バックアップを実行する間隔)は、ポリシー設定の一部であり、一部のプラグインでは _ schedule type__ と呼ばれます。ポリシーでは、バックアップ頻度として、毎時、毎日、毎週、または毎月を選択できます。頻度を選択しない場合は、オンデマンドのみのポリシーが作成されます。ポリシーにアクセスするには、 * Settings * > * Policies * をクリックします。

  • バックアップスケジュール

    バックアップスケジュール(バックアップが実行される日時)は、リソースグループの設定の一部です。たとえば、リソースグループのポリシーで週に 1 回のバックアップが設定されている場合は、毎週木曜日の午後 10 時にバックアップが実行されるようにスケジュールを設定できます。リソースグループのスケジュールにアクセスするには、 * リソース * > * リソースグループ * をクリックします。

バックアップの命名規則

Snapshot コピーのデフォルトの命名規則を使用するか、カスタマイズした命名規則を使用できます。デフォルトのバックアップ命名規則では Snapshot コピー名にタイムスタンプが追加されるため、コピーが作成されたタイミングを特定できます。

Snapshot コピーでは、次のデフォルトの命名規則が使用されます。

「 resourcegroupname_hostname_timestamp 」

バックアップリソースグループには、次の例のように論理的な名前を付ける必要があります。

dts1_mach1x88_03-12-2015_23.17.26

この例では、各構文要素に次の意味があります。

  • _dts1_は リソースグループ名です。

  • mach1x88 はホスト名です。

  • 03-12-2015_23.17.26 は日付とタイムスタンプです。

または、「 * Snapshot コピーにカスタム名形式を使用」を選択して、リソースまたはリソースグループを保護しながら Snapshot コピー名の形式を指定することもできます。たとえば、 customtext_resourcegroup_policy_hostname や resourcegroup_hostname などの形式です。デフォルトでは、 Snapshot コピー名にタイムスタンプのサフィックスが追加されます。

バックアップ保持オプション

バックアップコピーを保持する日数を選択するか、保持するバックアップコピーの数を指定できます。指定できる最大数は ONTAP で 255 個です。たとえば、組織の必要に応じて、 10 日分のバックアップコピーや 130 個のバックアップコピーを保持できます。

ポリシーを作成する際に、バックアップタイプおよびスケジュールタイプの保持オプションを指定できます。

SnapMirror レプリケーションを設定すると、デスティネーションボリュームに保持ポリシーがミラーリングされます。

SnapCenter は、保持されているバックアップの保持ラベルがスケジュールタイプと一致する場合には、バックアップを削除します。リソースまたはリソースグループに対してスケジュールタイプが変更された場合、古いスケジュールタイプラベルのバックアップがシステムに残ることがあります。

メモ バックアップコピーを長期にわたって保持する場合は、 SnapVault バックアップを使用する必要があります。

プライマリストレージボリュームまたはセカンダリストレージボリュームを使用してバックアップコピーを検証する

プライマリストレージボリュームまたは SnapMirror または SnapVault セカンダリストレージボリュームでバックアップコピーを検証することができます。セカンダリストレージボリュームを使用して検証を実行すると、プライマリストレージボリュームの負荷が軽減されます。

プライマリストレージボリュームまたはセカンダリストレージボリュームにあるバックアップを検証すると、すべてのプライマリ Snapshot コピーとセカンダリ Snapshot コピーが検証済みとマークされます。

SnapMirror および SnapVault セカンダリストレージボリューム上のバックアップコピーを検証するには、 SnapRestore ライセンスが必要です。