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

サポートされているOracleバージョンの最新情報については、 "NetApp Interoperability Matrix Tool" 。

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

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

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

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

例: RAC データベース cdbrac には、ノード 1 の cdbrac1、ノード 2 の cdbrac2、ノード 3 の cdbrac3 という 3 つのインスタンスがあります。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コマンドを実行して、カタログ化されたバックアップの情報（カタログ化されたデータファイルのタグ、制御ファイルのカタログ パス、カタログ化されたアーカイブ ログの場所など）を取得できます。

SnapCenter 3.0では、ASMディスク グループ名が16文字以上である場合に、バックアップに対してSC_HASHCODEofDISKGROUP_DBSID_BACKUPIDという命名形式が使用されます。一方、ディスク グループ名が16文字未満である場合は、バックアップに対してDISKGROUPNAME_DBSID_BACKUPIDという命名形式が使用されます。これはSnapCenter 2.0で使用される形式と同じです。

バックアップに関する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を実行して確認できます。あるいは、 "SnapCenterソフトウェア コマンド リファレンス ガイド" 。

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

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

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

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

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

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

resourcegroupname_hostname_timestamp

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

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

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

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

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

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

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

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

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

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