SnapCenter Software 4.8

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

サポートされているOracleバージョンに関する最新の情報については、富士通サポートにお問い合わせください。

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

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

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クラスタ ノードのロールに変更があった場合は、優先ノードが更新されるように手動で検出する必要があります。

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

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

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

デフォルトでは、ターゲット データベースの制御ファイルがカタログ化に使用されます。外部カタログ データベースを追加する場合は、SnapCenterグラフィカル ユーザー インターフェイス（GUI）から[Database Settings]ウィザードを使用して外部カタログのクレデンシャルとTransparent Network Substrate（TNS）名を指定することにより、そのデータベースを設定できます。外部カタログ データベースはCLIから設定することもできます。その場合は、Configure-SmOracleDatabaseコマンドを、-OracleRmanCatalogCredentialNameオプションおよび-OracleRmanCatalogTnsNameオプションとともに実行します。

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

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

sccli Set-SmConfigSettings-ConfigSettingsTypePlugin-PluginCodeSCO-ConfigSettings "KEY=ENABLE_CROSSCHECK, VALUE=TRUE"

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

処理時間が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つの要素があります。

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

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

resourcegroupname_hostname_timestamp

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

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

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

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

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

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

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

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

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

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