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

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

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

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

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

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

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

カタログ化するためには、データベースの状態が少なくともマウント済み状態であることが必要です。カタログ化を実行できるのは、データバックアップ、アーカイブログバックアップ、およびフルバックアップです。複数のデータベースを含むリソースグループのバックアップに対してカタログ化を有効にすると、データベースごとにカタログ化が実行されます。Oracle 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 で使用される形式と同じです。

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

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

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

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

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 ライセンスが必要です。