17 リカバリ・アプライアンスに関するベスト・プラクティス

この章では、リカバリ・アプライアンスの最適な構成に役立ついくつかの操作について説明します。

Oracle Zero Data Loss Recovery Applianceを使用するときは、次の運用のベスト・プラクティスに従うことをお薦めします。これは、パフォーマンス、可用性またはセキュリティに影響する可能性のある問題の防止に役立つことがあるためです。

• リカバリ・アプライアンス構成の変更は制限されています。特定の制限および許可される構成例外の詳細は、MOSノート2172842.1を参照してください。

• データベース保護のベスト・プラクティスは、REDOがアーカイブ・ログ・バックアップに自動的に変換されるリカバリ・アプライアンスへのリアルタイムREDOを有効にすることです。

  かわりにRMANアーカイブ・ログ・バックアップを使用する場合は、圧縮時間と領域節約の最適なバランスをとるために、LOW圧縮アルゴリズムをお薦めします。

• 安定して動作保証されたソフトウェア環境となるようにするには、公開されているMy Oracle Support (MoS)ノート1927416.1、2410137.1に概説されている推奨のリカバリ・アプライアンス(RA)ソフトウェア構成に従います。

  パッチを適用する前に、「Zero Data Loss Recovery Applianceでサポートされているバージョン」のドキュメント(Doc ID 1927416.1)を参照して、既知の重要な問題を回避し、互換性のあるソフトウェア・スタックの組合せを確認します。

• リカバリ・アプライアンスからデータベースを削除する場合は、最小のデータベース・バックアップから始めてより大きいデータベース・バックアップへと一度に1つずつ削除します。複数の削除リクエストを同時に送信しないでください。

• リカバリ・アプライアンスは、レベル0の初期バックアップとそれ以降のレベル1の増分バックアップで動作します。サポートの指示がないかぎり、複数のL0バックアップは実行しないでください。
• Data Guardアーキテクチャでは、プライマリ・データベースをあるリカバリ・アプライアンスにバックアップし、スタンバイ・データベースを別のリカバリ・アプライアンスにバックアップします。Data Guardのプライマリとスタンバイを同じリカバリ・アプライアンスにバックアップしないでください。

• Data Guardアーキテクチャでは、プライマリのバックアップとスタンバイのREDOログ、またはスタンバイのバックアップとプライマリのREDOログを同じリカバリ・アプライアンスに送信しないでください。

• デュアル・バックアップ戦略は、長期使用のために維持すると複雑になる可能性があるので、可能な場合は避けてください。デュアル・バックアップ戦略は、リカバリ・アプライアンス以外のソリューションからOracle Zero Data Loss Recovery Applianceソリューションへの移行用に設計されています。

• 複数セクション・バックアップの使用: 8Kブロック・サイズのbigfile表領域のリカバリ・アプライアンス・バックアップの場合は、64GBのSECTION SIZEを使用します。これは、リカバリ・アプライアンスのフラッシュ・キャッシュで効率的に処理できるためです。

  8kブロック・サイズのbigfile表領域(> 16TB)の場合は、128GBのSECTION SIZEを使用します。

  非常に大きなデータファイル(16TBより大きい)がある場合は、SRを開いて助言を受けてください。

• システム・アクティビティ・レポート(SAR)をできれば1日の同じ時間に毎日実行します。

• リカバリ・アプライアンスによって生成されたエラーまたは警告についてのEnterprise Manager (EM)通知を定期的に監視および確認して、潜在的な問題がクリティカルになる前に事前に特定および対処し、最適なシステム・パフォーマンスと信頼性になるようにします。

  Oracle Enterprise Managerが環境にデプロイされていない場合は、リカバリ・アプライアンス・システム・アクティビティ・レポート(SAR)を利用します。

• Exachkヘルス・チェックを毎月実行し、結果を十分に確認し、必要に応じて修正処置を実行します。

  パッチ適用の前後にExachkを実行し、スムーズで正常なアップグレード・プロセスとなるようにします。時間の経過に伴う変更を追跡するには、diffコマンドを使用して月次Exachkレポートを比較し、システムの構成における新しい問題や変更を簡単に識別できるようにします。

• 新しくインストールされたOracle Zero Data Loss Recovery Applianceとデータベースを統合する場合、システムへの負荷を回避するために、レベル0の初期バックアップをずらして実行します。

• リカバリ・アプライアンスを操作する場合、次の変更がベスト・プラクティスとみなされます

  • CONFIGURE BACKUP OPTIMIZATION ON;

  • CONFIGURE CONTROLFILE AUTOBACKUP ON;

  • CONFIGURE DEFAULT DEVICE TYPE TO ‘SBT_TAPE’;

  • ブロック・チェンジ・トラッキング・ファイル機能を有効にします。

  • フェイルオーバー後のスタンバイ・データベースの再作成を回避するために、フラッシュバック・データベース機能を最低60分保持を指定して有効にします。

• Data Guard Brokerを利用して、Data Guard環境でリアルタイムREDOを構成し、既存のブローカ構成および設定と一貫した管理となるようにします。

• 領域効率の高い暗号化バックアップを有効にすることで、ストレージ効率を最大化し、バックアップとリストアのパフォーマンスを向上させます。

  RMANチャネルの指定でRA_FORMAT=trueを設定すると、永久増分戦略でバックアップが圧縮および暗号化され、ネットワークを介したデータ・ボリュームのバックアップおよびリストアが削減されます。

  データベースの圧縮データは、バックアップではそれ以上圧縮されません。

• ワークロードが変動するデータベースの場合、または新しいデータベースをOracle Zero Data Loss Recovery Applianceにオンボードする場合は、autotune_reserved_spaceパラメータを設定して、システムが取込みワークロードに基づいて最適な予約領域値を動的に調整および決定できるようにし、領域管理アクティビティでリソース割当てが効率的になるようにします。