1. 高可用性概要およびベスト・プラクティス
  2. 『Oracle Database高可用性ベスト・プラクティス』
  3. Oracle Database構成のベスト・プラクティス

9 Oracle Database構成のベスト・プラクティス

すべてのOracle単一インスタンス・データベースを構成する場合にOracle MAAベスト・プラクティスを採用すると、停止が削減または回避され、破損のリスクが軽減され、リカバリ・パフォーマンスが向上します。

Oracle MAA Bronzeリファレンス・アーキテクチャは次のOracle Databaseのベスト・プラクティスを使用して構成し、これらはSilver (Oracle RAC)、Gold (Oracle Data Guard)およびPlatinum (Oracle GoldenGate)という他のMAAリファレンス・アーキテクチャの基本データベースの基本プラクティスでもあります。

サーバー・パラメータ・ファイル(SPFILE)の使用

サーバー・パラメータ・ファイル(SPFILE)は、データベースのすべてのインスタンスに関連付けられたすべてのデータベース初期化パラメータを保持する単一の集中管理パラメータ・ファイルです。このファイルにより、データベース・パラメータを管理するための簡単で確実な永続的環境が提供されます。SPFILEは、DATA ASMディスク・グループに配置することをお薦めします。

アーカイブ・ログ・モードと強制ロギングの有効化

データベースのARCHIVELOGモードでの実行とデータベースのFORCE LOGGINGモードの使用は、データベースのリカバリ操作のための前提条件です。

ARCHIVELOGモードでは、オンラインでのデータベース・バックアップが可能です。リストアされている時点より後の時点にデータベースをリカバリするには、このモードで運用する必要があります。Oracle Data Guardやフラッシュバック・データベースなどの機能を使用する場合、本番データベースはARCHIVELOGモードで実行する必要があります。

特定の表領域内でリカバリの必要がないデータを分離できる場合は、データベースのFORCE LOGGINGモードのかわりに、表領域レベルのFORCE LOGGING属性を使用できます。

代替ローカル・アーカイブ先の構成

ローカル・アーカイブ先(通常はLOG_ARCHIVE_DEST_1)では、代替ローカル宛先が別のASMディスク・グループに必要になります。この構成により、DB_RECOVERY_FILE_DESTがいっぱいになった場合や、なんらかの理由で使用できなくなった場合に、アーカイブ・ログ領域が不足してデータベースがハングすることを回避できます。

表9-1 代替ローカル・アーカイブ構成パラメータ

データベース・パラメータ ローカル・アーカイブ先のLOG_ARCHIVE_DEST_nパラメータ設定
LOG_ARCHIVE_DEST_n LOCATION=USE_DB_FILE_RECOVERY_DEST

VALID_FOR=(ALL_LOGFILES,ALL_ROLES)

MAX_FAILURE=1

REOPEN=5

データベースのDB_UNIQUE_NAME=db_unique_name

ALTERNATE=ログ・アーカイブの他の宛先。log_archive_dest_[1-10]である必要があります

LOG_ARCHIVE_DEST_y LOCATION=DB_RECOVERY_FILE_DESTに使用されるディスク・グループ以外のディスク・グループ。通常はDATAディスク・グループです。

VALID_FOR=(ALL_LOGFILES,ALL_ROLES)

MAX_FAILURE=1

REOPEN=5

ALTERNATE=プライマリ・ローカル・アーカイブ・ログの宛先: 通常はLOG_ARCHIVE_DEST_1です
DB_RECOVERY_FILE_DEST アーカイブ先(RECOディスク・グループなど)
LOG_ARCHIVE_DEST_STATE_n ENABLE
LOG_ARCHIVE_DEST_STATE_y ALTERNATE

サンプル・パラメータ設定:

  • LOG_ARCHIVE_DEST_1='LOCATION=USE_DB_FILE_RECOVERY_DEST VALID_FOR=(ALL_LOGFILES,ALL_ROLES) MAX_FAILURE=1 REOPEN=5 DB_UNIQUE_NAME=db_unique_name of the database ALTERNATE=LOG_ARCHIVE_DEST_10'
  • LOG_ARCHIVE_DEST_10='LOCATION=+DATA VALID_FOR=(ALL_LOGFILES,ALL_ROLES) MAX_FAILURE=1 REOPEN=5 DB_UNIQUE_NAME=db_unique_name of the database ALTERNATE=LOG_ARCHIVE_DEST_1'
  • LOG_ARCHIVE_DEST_STATE_1 =enable
  • LOG_ARCHIVE_DEST_STATE_10=alternate
  • DB_RECOVERY_FILE_DEST=typically the RECO disk group

高速リカバリ領域の使用

高速リカバリ領域は、Oracle管理のディスク領域として、バックアップ・ファイルおよびリカバリ・ファイル用の集中管理されたディスクの場所を提供します。

高速リカバリ領域は、次のデータベース初期化パラメータを設定することで定義します。

  • DB_RECOVERY_FILE_DESTには、高速リカバリ領域のデフォルトの位置を指定します。このパラメータをRECOディスク・グループに設定します。

  • DB_RECOVERY_FILE_DEST_SIZE リカバリ領域の場所に作成されるデータベースのリカバリ・ファイルで使用される合計領域に対する厳密な制限(バイト)を指定します。

    このパラメータには、アーカイブ・ログ、フラッシュバック・ログおよびローカル・データベース・バックアップ・ファイルをローカルに格納するのに十分な大きさの値を設定します。ファイルをローカルに保持すると、バックアップのリストア後のリカバリ時間を短縮できます。RMANは、RMANバックアップおよびデータ保持のポリシーに従って、これらのファイルを自動的に管理します。通常、顧客は24時間分のデータを宛先に格納します

    同じDB_RECOVERY_FILE_DEST_SIZEを共有する多数のデータベースをホストする場合には、領域全体を管理および監視する必要があります。たとえば、RECOディスク・グループの使用率が90%になったときに警告することをお薦めします。

フラッシュバック・データベースの有効化

フラッシュバック・データベースは、意図と異なるデータベースの変更を元に戻すための、ポイント・イン・タイム・リカバリに代わる方法です。

フラッシュバック・データベースを使用すると、データベース全体を復元して、一定期間内のデータベースの変更の影響を元に戻すことができます。その効果は、データベースのポイント・イン・タイム・リカバリを使用した場合と同様です。複雑な手順を使用することなく、単一のRMANコマンドまたはSQL*Plus文を実行してデータベースをフラッシュバックできます。

フラッシュバック・データベースを有効にするには、次に示すベスト・プラクティスを使用して、高速リカバリ領域を構成し、フラッシュバック保存目標を設定します。この保存目標では、フラッシュバック・データベースを使用してデータベースをどの程度巻き戻すかを指定します。

  • フラッシュバック・データベースを有効化する前に、使用するアプリケーションのパフォーマンス・ベースラインを認識しておくと、オーバーヘッドの判断と、フラッシュバック・データベースの有効化におけるアプリケーション・ワークロードの影響の評価に役立ちます。

  • フラッシュバック・データベースのフラッシュバック・ログを保持するために、高速リカバリ領域が十分あることを確認します。一般的な経験則では、フラッシュバック・ログ生成のサイズは、REDOログ生成のサイズと同程度になります。たとえば、DB_FLASHBACK_RETENTION_TARGETを24時間に設定し、1日に20GBのREDOがデータベースで生成される場合は、20から30GBのディスク領域をフラッシュバック・ログに使用できるようにします。

    • 高速リカバリ領域のサイズ指定を判断するもう1つの方法は、フラッシュバック・データベースを有効化して、データベースを短時間(2、3時間)稼働させることです。V$FLASHBACK_DATABASE_STAT.ESTIMATED_FLASHBACK_SIZEを問い合せて、高速リカバリ領域に必要な見積もり領域サイズを取得します。

    • DB_FLASHBACK_RETENTION_TARGETは目標であり、データベースを同じくらいフラッシュバックできるという保証はありませんので注意してください。フラッシュバック・ログが保存されている高速リカバリ領域で領域圧迫があるような場合は、最も古いフラッシュバック・ログが削除される可能性があります。フラッシュバックのポイント・イン・タイムを保証するには、保証付きリストア・ポイントを使用する必要があります。

  • 高速リカバリ領域に十分なI/O帯域幅があることを確認します。FLASHBACK BUF FREE BY RVWR待機イベントが頻繁に発生すると、一般的には、フラッシュバック・データベースにおけるI/O帯域幅が不十分です。

  • フラッシュバック・データベース操作の進捗状況は、V$SESSION_LONGOPSビューを問い合せることによって監視できます。進捗状況を監視するための問合せの例は次のとおりです 

    SELECT sofar, totalwork, units FROM v$session_longops WHERE opname = 'Flashback Database';

  • 同じポイントにフラッシュバックすることが必要な繰返しのテストについては、フラッシュバック・データベースを有効化するかわりにフラッシュバック・データベースの保証付きリストア・ポイントを使用します。これにより、領域の使用が最小限に抑えられます。

  • フラッシュバックPDBは、CDB内の他のPDBに影響を与えずにプラガブル・データベースを巻き戻しできます。PDBリストア・ポイントを作成することもできます。

FAST_START_MTTR_TARGET初期化パラメータの設定

ファスト・スタート・フォルト・リカバリでは、初期化パラメータFAST_START_MTTR_TARGETによって、インスタンス障害またはシステム障害からのリカバリ時間を簡単に構成できます。

FAST_START_MTTR_TARGETパラメータは、リカバリ時間目標(RTO)の目標値、つまりインスタンスを起動してキャッシュ・リカバリの実行にかかる時間(秒単位)の目標値を指定します。このパラメータを設定すると、データベースはその目標を達成するために増分チェックポイントの書込みを管理します。このパラメータに現実的な値を選択した場合、選択したおおよその平均秒数内でデータベースがリカバリされます。

最初に、FAST_START_MTTR_TARGET初期化パラメータを300 (秒)またはリカバリ時間目標(RTO)の目標値に必要な値に設定します。この値を設定するか、さらに小さい値にすると、データベース・ライター(DBWR)がリカバリ目標を満たすようにアクティブになります。

さらに高い負荷でも処理できるように十分なIO帯域幅があることを確認します。FAST_START_MTTR_TARGETの監視およびチューニングの詳細は、『データベース・パフォーマンス・チューニング・ガイド』を参照してください。

ピーク負荷時のノードやインスタンスの障害などの場合の停止テストをお薦めします。

データ破損の防止

Oracle Databaseの破損の防止、検出および修復の機能は、保護対象のデータおよびトランザクションの内部知識と、包括的な高可用性ソリューションのインテリジェント統合を基に構築されています。

データ・ブロックは、認識されているOracleデータベース形式ではないか、または内容に内部的な一貫性がないと破損します。データ・ブロック破損は、内部のOracle制御情報やアプリケーションおよびユーザー・データにダメージを与えて、これがクリティカル・データおよびサービスの重大な損失につながる場合があります。

Oracle Databaseは、破損を検出すると、データをリカバリするためのブロック・メディア・リカバリおよびデータ・ファイル・メディア・リカバリを提供します。Oracle Flashbackテクノロジを使用すると、人的エラーまたはアプリケーション・エラーによって発生したデータベース全体の論理破損を元に戻すことができます。ツールは論理データ構造の予防的検証にも使用できます。たとえば、SQL*Plus ANALYZE TABLE文はブロック間の破損を検出します。

次に、データベースを破損から保護するためのベスト・プラクティスを示します。

  • ディスク障害からの保護にディスクのミラー化を提供する場合は、Oracle Automatic Storage Management (Oracle ASM)を使用します。

  • HIGH冗長性ディスク・タイプを使用して、Oracle ASMで破損を最適に修復します。

    ディスク・グループでOracle ASM冗長性を使用すると、I/Oエラーまたは破損の発生時にミラー・エクステントをデータベースで使用できます。継続的な保護を目的として、Oracle ASMの冗長性により、I/Oエラーの発生時にエクステントをディスク上の別の領域に移動できます。Oracle ASMによる冗長性メカニズムは、メディア・エラーを戻す不良セクターがある場合に役立ちます。

  • (ほとんどの場合、人的エラーによって引き起こされた)論理破損からの高速ポイント・イン・タイム・リカバリと、フェイルオーバー後のプライマリ・データベースの高速復元には、Flashbackテクノロジを有効化します。

  • Recovery Manager (RMAN)によるバックアップおよびリカバリ計画を実装し、RMANのBACKUP VALIDATE CHECK LOGICALスキャンを定期的に使用して破損を検出します。

    バックアップおよびリストア操作中の追加的なブロック・チェックにはRMANおよびOracle Secure Backupを使用します。破損のチェックと修復、中央バックアップ検証、本番データベースへの影響の縮小、Enterprise Cloudバックアップおよびリカバリ・ソリューションを含め、バックアップおよびリカバリの検証にはZero Data Loss Recovery Applianceを使用します。

  • データベース初期化パラメータDB_BLOCK_CHECKSUM=MEDIUMまたはFULLを設定します。
  • DB_BLOCK_CHECKING=MEDIUMまたはFULLの設定値を評価しますが、これはアプリケーションでパフォーマンスを完全に評価した後にのみ行います。

LOG_BUFFER初期化パラメータを128 MB以上に設定

フラッシュバックが有効なデータベースでは、LOG_BUFFER初期化パラメータを128 MB以上に設定します。

Set USE_LARGE_PAGES=ONLY

Linuxでは、データベースのSGAは、一貫したパフォーマンスと安定性を実現するために大きなページを利用する必要があります。

USE_LARGE_PAGESパラメータを使用して、これが行われるようにするには、次の2つの方法があります。

  • USE_LARGE_PAGES=ONLY - インスタンスの起動前にHugepagesを事前に割り当てる必要があります。
  • USE_LARGE_PAGES=AUTO_ONLY - Hugepagesはインスタンスの起動時に動的に取得されますが、メモリーが断片化されている場合、または別のインスタンスが同時にHugepagesを起動して動的に取得している場合は、この動的取得が失敗する可能性があります。

MAAのベスト・プラクティスはUSE_LARGE_PAGES=ONLYです。この推奨事項は、クラウド環境およびクラウド以外の環境に適用でき、すべてのクラウドおよびExadata自動化ツールでこの構成が適用されていることを確認します。

ノート:

ExadataのUSE_LARGE_PAGESのOracle RDBMS 19cのデフォルトはAUTO_ONLYですが、この値は今後非推奨になります。

ビッグファイル表領域の使用

データベースが大きくなるにつれて、スモールファイル表領域にデータ・ファイルが追加されます。この表領域には、追加の管理、監視およびメンテナンスが必要ですが、Oracle Data Guard環境ではデータベースのオープン時間およびロール・トランジション時間に悪影響を及ぼします。

ビッグファイル表領域では、表領域ごとに1つの大きなデータ・ファイル(8Kブロック・サイズに最大32TB、32Kブロック・サイズに128TB)が可能です。1つのデータ・ファイルによってデータベース内のファイルの数が削減されるため、データベース・チェックポイント、データベース・オープンおよびロール・トランジション時間が改善し、管理コストも改善します。

推奨事項は次のとおりです:

  • 新しいデータベースの設計およびデプロイメントでは、ビッグファイル表領域およびパーティション化を使用して、データ・ファイルの数を最小限に抑えます。大規模な表のパーティション化により、大きなビッグファイルが回避されます。妥当なビッグファイルは16TB以下です。

    • 保持ポリシーが異なる、またはアクセス要件が異なる大規模な表の場合、データベースおよびオブジェクト設計の一部としてOracleパーティション化を使用します。Oracleパーティション化は、潜在的なビッグファイル・サイズ制限に対処することもできます。

    • 非常に大きい表領域の場合は、多数のスモールファイル・データ・ファイルのかわりにビッグファイル表領域を使用します。ビッグファイル表領域は、自動セグメント領域管理を備えたローカル管理表領域でのみサポートされます。

    • ビッグファイル表領域の使用には、DB_BLOCK_SIZEの最大制限を理解すること以外に、負のトレードオフはありません。データベースのバックアップおよびリストア・パフォーマンスを向上させるには、ビッグファイル表領域がある場合は、RMAN SECTION SIZEパラメータを使用してバックアップおよびリストア操作をパラレル化する必要もあります。

  • 多くのデータ・ファイルを含む既存のデータベースの場合は、データ・ファイルが最も多い表領域に焦点を当て、ALTER TABLE MOVEまたはオンライン再定義を使用して表またはパーティションをビッグファイル表領域に移行できるかどうかを評価します。

次の表に、データベース内のデータ・ファイルの数を9000データ・ファイルから最大100データ・ファイルまで減らし、フェイルオーバー時間を10倍に、スイッチオーバー時間を4回短縮したことを示す最新のData Guardパフォーマンス・テストを示します。

計画外停止/DR (フェイルオーバー) 初期構成 チューニングされたMAA構成
クローズしてマウント(C2M) 21秒 1秒
ターミナル・リカバリ(TR) 154秒 2秒
プライマリに変換(C2P) 114秒 5秒
新規プライマリのオープン(OnP) 98秒 28秒
PDBのオープンおよびサービスの開始(OPDB) 146秒 16秒
合計アプリケーション停止時間 533秒(8分53秒) 52秒(90%低下)
計画DRスイッチ(スイッチオーバー) 初期構成 チューニングされたMAA構成
プライマリをスタンバイに変換 26秒 21秒
スタンバイをプライマリに変換(C2P) 47秒 7秒
新規プライマリのオープン(OnP) 152秒 14秒
PDBのオープンおよびサービスの開始(OPDB) 130秒 39秒
合計アプリケーション停止時間 355秒(5分55秒) 81秒(78%低下)

多数のデータ・ファイルを含む既存のデータベースの場合、次の表では、表またはパーティションをビッグファイル表領域に移行するためのALTER TABLE MOVEまたはDBMS_REDEFINITIONの使用を比較します。

関連性またはユースケース DBMS_REDEFINITION ALTER TABLE MOVE ONLINE
アプリケーションへの影響
  • 移動中にDDLの変更は許可されません
  • アクティブ化中のアプリケーションのブラックアウト(秒)
  • 移動中にDDLの変更は許可されません
  • 最終スイッチ中のアプリケーションのブラックアウトが不明です
アプリケーション機能がサポートされています
  • DMLがサポートされています
  • PDMLがサポートされています
  • 移動中にDDLの変更は許可されません
  • DMLがサポートされています
  • PDMLはサポートされていません
  • 移動中にDDLの変更は許可されません
索引の影響
  • 移動中に使用可能です
  • 索引は維持されます
  • 移動中に使用可能です
  • 移動後に索引は維持されます(UPDATE INDEXES句を使用)
  • 索引は個別に移動されます(REBUILD ONLINE)
領域要件 ダブル・スペースが必要です(表+索引) ダブル・スペースが必要です(表+索引)
表パーティションの機能 1回の実行でパーティション表全体を移動します すべての索引を維持するためにパーティションを1つずつ移動します
統計管理 アクティブ化の前に新しい統計を作成できます アクティブ化後に新しい統計が作成されます
進捗状況の監視, V$ONLINE_REDEFビューを問い合せて、表のオンライン再定義操作の進行状況を監視できます。 V$SESSION_LONGOPS?を問い合せます
失敗時の再開 再起動可能 不明
ロールバック あり N/A
制限

  • 複数のLONG列を保持している表は、オンラインで再定義できますが、これらの列は、CLOBに変換する必要があります。また、LONG RAW列は、BLOBに変換する必要があります。LOB列を持つ表は、オンライン再定義可能です。

  • 索引構成表を移動できます

  • ドメイン索引を移動できます

  • パラレルDMLおよびダイレクト・パスINSERT操作は可能です

DBMS_REDEFINITIONで多数のレア・ケースの制限があります。『Oracle Database管理者ガイド』の表のオンライン再定義の制限事項を参照してください

  • LONGまたはRAW列を含む表は移動できません

  • パーティション化された索引構成表は移動できません。

  • 空間、XML、テキスト索引などの表でドメイン索引が定義されている場合、移動できません。

  • 表の移動中は、パラレルDMLおよびダイレクト・パスINSERT操作は実行できません。

  • LOB、VARRAY、Oracleが提供する型またはユーザー定義オブジェクト型の列を含む索引構成表は移動できません。

ドキュメントとリファレンス

『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』のDBMS_REDEFINITIONを参照してください

『Oracle Database SQL言語リファレンス』のALTER TABLEを参照してください

自動共有メモリー管理の使用およびメモリー・ページングの回避

SGA_TARGETパラメータを設定して自動共有メモリー管理を有効にし、USE_LARGE_PAGESデータベース初期化パラメータをAUTO_ONLYまたはONLYに設定し、USE_LARGE_PAGES ASM初期化パラメータをTRUEに設定します。

SGA_TARGETの設定に加えて、次のガイドラインを使用して、自動共有メモリー管理を有効にします。

  • データベース・サーバー上のSGAとPGAのメモリー割当ての合計は、常にシステムの物理メモリーよりも小さくする必要がありますが、それでも同じデータベース・サーバー上で実行されているプロセス、PGAおよび他のアプリケーションに必要なメモリーを確保する必要があります。

  • メモリー使用状況を正確に把握するには、V$PGASTATでオペレーティング・システム統計を問い合せて、PGAメモリーおよびホストベース・メモリーの使用状況を監視します。

  • データベースおよびアプリケーションの数を調整するか、または割り当てられたメモリー設定を減らして、メモリー・ページングを回避します。

    PGA_AGGREGATE_LIMITを設定して、PGAメモリーの使用量に対して厳密な制限を指定します。PGA_AGGREGATE_LIMITの値を超過している場合は、Oracle Databaseにより、最もチューニングが困難なPGAメモリーを消費しているセッション・コールが最初に終了します。それでもPGAメモリーの使用量合計が上限を超えている場合は、次に、最も調整が困難なメモリーを使用しているセッションが終了します。

データベース初期化パラメータUSE_LARGE_PAGES=AUTO_ONLYまたはONLYを設定し、ASM初期化パラメータUSE_LARGE_PAGES=TRUEを設定します。

  • init.oraパラメータUSE_LARGE_PAGES=ONLYを設定するか、ExadataシステムでAUTO_ONLYに設定して、データベース・インスタンスのSGA全体がHugePagesに格納されていることを確認します。

    データベース・インスタンスのUSE_LARGE_PAGES=ONLYを設定することをお薦めします。このパラメータを設定すると、SGAのすべてのメモリーをHugePagesから取得できる場合にのみ、インスタンスが起動するようになります。

  • ASMインスタンスの場合、パラメータUSE_LARGE_PAGES=ONLYを(デフォルト値)のままにします。この設定によって、使用可能な場合に確実にHugePagesが使用されますが、さらに、HugePagesが構成されていない場合や構成が不十分な場合には、Grid Infrastructureの一部として確実にASMが起動します。

  • HugePagesは、自動メモリー管理と互換性がないため、自動共有メモリー管理を使用します。

Oracle Clusterwareの使用

Oracle Clusterwareを使用すると、複数のサーバーが相互に通信することにより、1つの集合単位として機能するように見えます。Oracle Clusterwareには、単一インスタンスのOracleデータベースを含むすべてのOracleデータベース用に高可用性オプションがあります。Oracle Clusterwareは、アプリケーションの可用性を高くするための最小要件の1つです。

Oracle Clusterwareでは、Oracle Real Application Clusters (Oracle RAC)、Oracle RAC One NodeおよびOracle Restartの実行に必要なインフラストラクチャが提供されます。Oracle Grid Infrastructureは、エンタープライズ・グリッド・アーキテクチャ用のインフラストラクチャを提供するソフトウェアです。クラスタの場合、このソフトウェアにはOracle Clusterwareと Oracle ASMが含まれます。

スタンドアロン・サーバーの場合、Grid InfrastructureにはOracle RestartとOracle ASMが含まれます。Oracle Restartでは、単一インスタンスの(クラスタ化されていない) Oracleデータベース、Oracle ASMインスタンス、サービス、リスナーおよびサーバー上で実行されているその他のプロセスの起動および再起動が管理されます。ハードウェア障害またはソフトウェア障害後にサービスの割込みが発生すると、Oracle Restartは自動的にコンポーネントを再起動します。

Oracle Clusterwareは、リソースおよびリソース・グループを管理し、それらを構成する方法に基づいて可用性を高めます。リソースおよびリソース・グループは、Oracle Clusterwareで次の操作が実行されるように構成できます。

  • クラスタまたはサーバーの起動時のリソースおよびリソース・グループの起動

  • 障害が発生した場合のリソースおよびリソース・グループの再起動

  • 各サーバーへのリソースおよびリソース・グループの再配置(他のサーバーを使用できる場合)

詳細は、Oracle Clusterware管理およびデプロイメント・ガイドのトピック、Oracle Database高可用性オプションおよびOracle Clusterwareを使用したアプリケーションの可用性の向上を参照してください。