SnapCenter Software 4.8
HTML版のドキュメントが最新版です。 to English version
Oracleデータベースのバックアップ戦略の定義
バックアップ ジョブを作成する前にバックアップ戦略を定義しておくと、データベースの正常なリストアやクローニングに必要なバックアップを確実に作成できます。バックアップ戦略の大部分は、サービス レベル アグリーメント(SLA)、目標復旧時間(RTO)、および目標復旧時点(RPO)によって決まります。
SLAとは、求められるサービス レベル、およびサービスに関連する多くの問題(サービスの可用性やパフォーマンスなど)への対応を定義したものです。RTOは、サービスの停止からビジネス プロセスの復旧までに必要となる時間です。RPOは、障害発生後に通常処理を再開するためにバックアップ ストレージからリカバリーする必要があるファイルの経過時間に関する戦略を定義したものです。SLA、RTO、およびRPOは、データ保護戦略に関与します。
バックアップ対象としてサポートされるOracleデータベース構成
SnapCenterでは、各種のOracleデータベース構成のバックアップがサポートされます。
-
Oracle Standalone
-
Oracle Real Application Clusters(RAC)
-
Oracle Standalone Legacy
-
Oracle Standalone Container Database(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バージョンに関する最新の情報については、富士通サポートにお問い合わせください。
Oracleデータベースでサポートされるバックアップ タイプ
バックアップ タイプでは、作成するバックアップのタイプを指定します。SnapCenterでは、Oracleデータベースに対してオンライン バックアップ タイプとオフライン バックアップ タイプがサポートされます。
オンライン バックアップ
データベースがオンライン状態のときに作成されるバックアップを、オンライン バックアップと呼びます。ホット バックアップとも呼ばれるオンライン バックアップでは、データベースをシャットダウンすることなくバックアップを作成できます。
オンライン バックアップでは、次のファイルのバックアップを作成できます。
-
データファイルと制御ファイルのみ
-
アーカイブ ログ ファイルのみ(この場合はデータベースがバックアップ モードになりません)
-
データベース全体(データファイル、制御ファイル、およびアーカイブ ログ ファイル)
オフライン バックアップ
データベースがマウント済み状態またはシャットダウン状態のときに作成されるバックアップを、オフライン バックアップと呼びます。オフライン バックアップはコールド バックアップとも呼ばれます。オフライン バックアップにはデータファイルと制御ファイルのみを含めることができます。オフライン マウント バックアップまたはオフライン シャットダウン バックアップのいずれかを作成できます。
-
オフライン マウント バックアップを作成する場合は、データベースがマウント済み状態であることを確認する必要があります。
データベースがそれ以外の状態であると、バックアップ処理は失敗します。
-
オフライン シャットダウン バックアップを作成する場合は、データベースはどの状態でもかまいません。
データベースは、バックアップを作成するために必要な状態に変更されます。バックアップが作成されると、データベースは元の状態に戻ります。
SnapCenterのOracleデータベース検出方法
「リソース」となるのは、ホスト上でSnapCenterによって管理されているOracleデータベースです。使用できるデータベースを検出したあとに、それらのデータベースをリソース グループに追加してデータ保護処理を実行できます。さまざまなタイプとバージョンのOracleデータベースを検出するためにSnapCenterが実行するプロセスを理解しておく必要があります。
Oracleバージョン11g~12cR1の場合 | Oracleバージョン12cR2~18cの場合 | ||
---|---|---|---|
RACデータベース:RACデータベースは、/etc/oratabエントリに基づいてのみ検出されます。 /etc/oratabファイルにデータベース エントリが含まれている必要があります。 |
RACデータベース:RACデータベースはsrvctl configコマンドを使用して検出されます。 |
||
スタンドアロン:スタンドアロン データベースは、/etc/oratabエントリに基づいてのみ検出されます。 /etc/oratabファイルにデータベース エントリが含まれている必要があります。 |
スタンドアロン:スタンドアロン データベースは、/etc/oratabファイルのエントリとsrvctl configコマンドの出力に基づいて検出されます。 |
||
ASM:ASMインスタンス エントリが/etc/oratabファイルに含まれている必要があります。 |
ASM:ASMインスタンス エントリが/etc/oratabファイルに含まれている必要はありません。 |
||
RAC One Node:RAC One Nodeデータベースは、/etc/oratabエントリに基づいてのみ検出されます。 データベースがnomount、mount、openのいずれかの状態である必要があります。/etc/oratabファイルにデータベース エントリが含まれている必要があります。 データベースがすでに検出され、バックアップがデータベースに関連付けられている場合、RAC One Nodeデータベースのステータスは名前変更または削除とマークされます。 データベースを再配置した場合は、次の手順を実行する必要があります。
|
RAC One Node:RAC One Nodeデータベースは、srvctl configコマンドのみを使用して検出されます。 データベースがnomount、mount、openのいずれかの状態である必要があります。データベースがすでに検出され、バックアップがデータベースに関連付けられている場合、RAC One Nodeデータベースのステータスは名前変更または削除とマークされます。 データベースを再配置した場合は、次の手順を実行する必要があります。
|
/etc/oratabファイルにOracle 12cR2および18cデータベースのエントリがあり、同じデータベースをsrvctl configコマンドで登録する場合、SnapCenterにより重複するデータベース エントリが削除されます。 古いデータベース エントリがある場合、データベースは検出されますが、データベースは到達不能になり、ステータスはオフラインになります。 |
RACセットアップにおける優先ノード
Oracle Real Application Clusters(RAC)セットアップでは、バックアップ処理が実行される優先ノードを指定できます。優先ノードを指定しない場合は、SnapCenterによって自動的に優先ノードが割り当てられ、そのノードにバックアップが作成されます。
優先ノードには、RACデータベース インスタンスが存在するクラスタ ノードを1つまたは複数指定できます。バックアップ処理は、これらの優先ノードで優先順位に従ってトリガされます。
例:RACデータベースcdbracには、3つのインスタンス(node1上にcdbrac1、node2上にcdbrac2、node3上にcdbrac3)があります。node1とnode2のインスタンスが優先ノードとして設定され、node2に第1優先順位、node1に第2優先順位が指定されています。バックアップ処理を実行すると、まず第1優先ノードであるnode2で処理が試行されます。node2がバックアップできる状態にない場合(ホストでプラグイン エージェントが実行されていない、ホスト上のデータベース インスタンスが指定したタイプのバックアップを行うのに必要な状態にない、Flex ASM構成の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)から[Database Settings]ウィザードを使用して外部カタログのクレデンシャルとTransparent Network Substrate(TNS)名を指定することにより、そのデータベースを設定できます。外部カタログ データベースはCLIから設定することもできます。その場合は、Configure-SmOracleDatabaseコマンドを、-OracleRmanCatalogCredentialNameオプションおよび-OracleRmanCatalogTnsNameオプションとともに実行します。
SnapCenter GUIでOracleバックアップ ポリシーを作成する際にカタログ化オプションを有効にした場合は、バックアップ処理の一環としてOracle RMANを使用してバックアップがカタログ化されます。バックアップのカタログ化を遅らせて実行することもできます。その場合は、Catalog-SmBackupWithOracleRMANコマンドを実行します。バックアップをカタログ化したあとに、Get-SmBackupDetailsコマンドを実行して、カタログ化されたバックアップの情報(カタログ化されたデータファイルのタグ、制御ファイルのカタログ パス、カタログ化されたアーカイブ ログの場所など)を取得できます。
HASHCODEofDISKGROUPは自動生成される2~10桁の番号で、各ASMドライブ グループに固有です。 |
バックアップに関するRMANリポジトリ情報が古くなってバックアップのリポジトリ レコードがその物理ステータスと一致しなくなった場合は、クロスチェックを実行してリポジトリ情報を更新できます。たとえば、ユーザーがオペレーティング システム コマンドでディスクからアーカイブ ログを削除した場合、実際にはディスクにログがないにもかかわらず、制御ファイルにはディスクにログがあることが示されます。クロスチェック処理では、制御ファイルの情報を更新できます。クロスチェックを有効にするには、Set-SmConfigSettingsコマンドを実行し、ENABLE_CROSSCHECKパラメーターにTRUEを割り当てます。デフォルト値はFALSEです。
sccli Set-SmConfigSettings-ConfigSettingsTypePlugin-PluginCodeSCO-ConfigSettings "KEY=ENABLE_CROSSCHECK, VALUE=TRUE"
カタログ情報を削除するには、Uncatalog-SmBackupWithOracleRMANコマンドを実行します。SnapCenter GUIではカタログ情報を削除できません。ただし、バックアップを削除するとき、またはカタログ化されたバックアップに関連する保持設定とリソース グループを削除するときに、カタログ化されたバックアップの情報も削除されます。
SnapCenterホストを強制的に削除する場合は、そのホストに関連するカタログ化されたバックアップの情報が削除されません。ホストを強制的に削除する場合は、事前にそのホストに関連するすべてのカタログ化されたバックアップの情報を削除しておく必要があります。 |
処理時間がORACLE_PLUGIN_RMAN_CATALOG_TIMEOUTパラメーターに指定されたタイムアウト値を超えたためにカタログ化やカタログ化解除が失敗した場合は、次のコマンドを実行してパラメーターの値を変更する必要があります。
/opt/NetApp/snapcenter/spl/bin/sccli Set-SmConfigSettings-ConfigSettingsType Plugin -PluginCode SCO-ConfigSettings "KEY=ORACLE_PLUGIN_RMAN_CATALOG_TIMEOUT,VALUE=user_defined_value"
パラメーターの値を変更したら、次のコマンドを実行してSnapCenter Plug-in Loader(SPL)サービスを再起動します。
/opt/NetApp/snapcenter/spl/bin/spl restart
コマンドで使用できるパラメーターとその説明は、Get-Help command_nameを実行して確認できます。
バックアップ スケジュール
バックアップ頻度(スケジュール タイプ)はポリシーで指定され、バックアップ スケジュールはリソース グループの設定で指定されます。バックアップの頻度またはスケジュールを決定する場合に最も重要な要因となるのは、リソースの変更率とデータの重要性です。使用頻度の高いリソースは1時間ごとにバックアップする必要がありますが、ほとんど使用されないリソースは1日に1回バックアップすれば十分です。その他の要因としては、組織におけるリソースの重要性、サービス レベル アグリーメント(SLA)、目標復旧時点(RPO)などがあります。
SLAは、求められるサービス レベル、およびサービスに関連する多くの問題(サービスの可用性やパフォーマンスなど)への対応を定義したものです。RPOは、障害発生後に通常処理を再開するためにバックアップ ストレージからリカバリーする必要があるファイルの経過時間に関する戦略を定義したものです。SLAとRPOはデータ保護戦略に関わる要件です。
使用頻度の高いリソースであっても、フル バックアップは1日に1~2回で十分です。たとえば、定期的なトランザクション ログ バックアップを実行すれば、必要なバックアップが作成されます。データベースをバックアップする回数が多いほど、リストア時にSnapCenterが使用する必要のあるトランザクション ログの数が少なくなります。これにより、リストア処理の時間を短縮できます。
バックアップ スケジュールには、次の2つの要素があります。
-
バックアップ頻度
バックアップ頻度(バックアップを実行する間隔)は、ポリシー設定の一部であり、一部のプラグインではスケジュール タイプと呼ばれます。ポリシーでは、バックアップ頻度として、毎時、毎日、毎週、または毎月を選択できます。頻度を選択しなかった場合は、オンデマンドのみのポリシーが作成されます。ポリシーにアクセスするには、[設定] > [ポリシー]の順にクリックします。
-
バックアップ スケジュール
バックアップ スケジュール(バックアップが実行される日時)は、リソース グループ設定の一部です。たとえば、リソース グループのポリシーで週に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のライセンスが必要です。