| Oracle® Database高可用性ベスト・プラクティス 12cリリース1 (12.1) E57730-02 |
|
 前 |
 次 |
この章では、単一インスタンス、Oracle RACデータベース、Oracle RAC One Nodeデータベース、Oracle Data Guard構成のプライマリ・データベースおよびスタンバイ・データベースなどの、すべてのOracleデータベースを構成するためのベスト・プラクティスを説明します(高可用性アーキテクチャの詳細は、『Oracle Database高可用性概要』を参照してください)。停止時間の削減または回避、破損リスクの低減、およびリカバリ・パフォーマンスの向上を図るには、これらのベスト・プラクティスを採用します。
この章には、次の項目が含まれます。
|
関連項目: 高可用性アーキテクチャの詳細は、『Oracle Database高可用性概要』を参照してください。 |
リカバリ時間を短縮し、データベースの可用性と冗長性を向上するには、次のことを行います。
データベースのARCHIVELOGモードでの実行とデータベースのFORCE LOGGINGモードの使用は、データベースのリカバリ操作のための前提条件です。ARCHIVELOGモードでは、オンラインでのデータベース・バックアップが可能です。リストアされている時点より後の時点にデータベースをリカバリするには、このモードで運用する必要があります。Oracle Data Guardやフラッシュバック・データベースなどの機能を使用する場合、本番データベースはARCHIVELOGモードで実行する必要があります。
特定の表領域内でリカバリの必要がないデータを分離できる場合は、データベースのFORCE LOGGINGモードのかわりに、表領域レベルのFORCE LOGGING属性を使用できます。
|
関連項目:
|
Oracleログの多重化を使用して、データ領域および高速リカバリ領域の各REDOグループに複数のREDOログ・メンバーを作成します(REDOログがOracle ASMの高冗長性ディスク・グループ内にない場合)。これにより、REDOログに関連する障害(いずれかのメンバーのディスク障害やI/O障害、またはオペレーティング・システム・コマンドにより間違ってメンバーを削除するといったユーザー・エラー)からデータを保護できます。少なくとも1つのREDOログ・メンバーが使用できれば、インスタンスは継続して動作できます。
REDOログのファイルおよびグループをサイズ指定するには、次のことを行います。
ログ・スイッチ後にグループが使用可能になるのをログ・ライター・プロセス(LGWR)が待機することのないように、少なくとも3つのREDOログ・グループを使用します。
すべてのオンラインREDOログとスタンバイREDOログは同じサイズです。
REDOログ・サイズ = (ピークREDO速度MB/sec) * (1200秒または20分)を使用します。
比較的大きいワークロードにはデフォルトのREDOサイズ4GBから、比較的小さいワークロードには100MBから始めます。
REDOログを高パフォーマンス・ディスク上に置きます。
ピーク時、15分ごとにログ・スイッチを実行します。
ログ・ファイルを高冗長性のディスク・グループに配置します。または、ASM冗長性を使用中の場合、複数のログ・ファイルを様々な標準冗長性のディスク・グループに配置します。
|
注意: スタンバイREDOログは多重化しないでください。 |
|
関連項目:
|
高速リカバリ領域は、Oracleが管理するディスク領域であり、バックアップ・ファイルとリカバリ・ファイルを集中管理するためのディスク上の場所です。
高速リカバリ領域は、次のデータベース初期化パラメータを設定することで定義します。
『Oracle Database 2日でデータベース管理者』で説明されている推奨バックアップ計画では、リカバリのための主要な場所として、高速リカバリ領域を使用することを推奨しています。高速リカバリ領域のサイズが適切であれば、修復に必要なファイルをすぐに使用できます。推奨される最低限のディスク制限値は、データベース、増分バックアップ、テープにコピーされていないすべてのアーカイブREDOログ、およびフラッシュバック・ログの合計サイズです。
|
関連項目:
|
フラッシュバック・データベースは、意図と異なるデータベースの変更を元に戻すための、ポイント・イン・タイム・リカバリに代わる方法です。フラッシュバック・データベースを使用すると、データベース全体を復元して、一定期間内のデータベースの変更の影響を元に戻すことができます。影響は、データベース・ポイント・イン・タイム・リカバリ(DBPITR)と類似しています。複雑な手順を使用することなく、単一のRMANコマンドまたはSQL*Plus文を発行してデータベースをフラッシュバックできます。
フラッシュバック・データベースを有効にするには、高速リカバリ領域を構成し、フラッシュバック保存目標を設定します。この保存目標によって、フラッシュバック・データベースを使用してデータベースを巻き戻す時点が指定されます。高速リカバリ領域の指定の詳細は、4.1.3項「高速リカバリ領域の使用」を参照してください。
フラッシュバック・データベースを構成して有効化する場合、次のことを確認してください。
フラッシュバックを有効化する前に、使用するアプリケーションのパフォーマンス・ベースラインを認識しておくと、オーバーヘッドの判断と、フラッシュバック・データベースでのチューニングにおけるアプリケーション・ワークロードの影響の評価に役立ちます。
フラッシュバック・データベースのフラッシュバック・ログを保持するために、高速リカバリ領域が十分あることを確認します。高速リカバリ領域のサイズ指定の詳細は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。一般的な経験則では、フラッシュバック・ログ生成のサイズは、REDOログ生成のサイズと同程度になります。たとえば、DB_FLASHBACK_RETENTION_TARGETを24時間に設定し、1日に20GBのREDOがデータベースで生成される場合は、目安として20から30GBのディスク領域をフラッシュバック・ログに使用できるようにします。同じルールが保証付きリストア・ポイントにも適用されます。たとえば、毎日20GBのREDOがデータベースで生成され、保証付きリストア・ポイントが1日保持される場合は、20GBから30GBのディスク領域を割り当てます。
高速リカバリ領域のサイズ指定を判断するもう1つの方法は、フラッシュバック・データベースを有効化して、データベースを短時間(2、3時間)、稼働させることです。高速リカバリ領域に必要な見積もり領域サイズは、V$FLASHBACK_DATABASE_STAT.ESTIMATED_FLASHBACK_SIZEの問合せによって取得できます。
DB_FLASHBACK_RETENTION_TARGETは目標であり、データベースを同じくらいフラッシュバックできるという保証はありませんので注意してください。フラッシュバック・ログが保存されている高速リカバリ領域で領域圧迫があるような場合は、一番過去のフラッシュバック・ログが削除される可能性があります。高速リカバリ領域の削除ルールの詳細は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。フラッシュバックのポイント・イン・タイムを保証するには、保証付きリストア・ポイントを使用する必要があります。
Oracle Enterprise Managerの監視メトリック、「リカバリ領域空き領域(%)」を、高速リカバリ領域における領域の問題の予防的アラートに設定します。
高速リカバリ領域に十分なI/O帯域幅があることを確認します。自動ワークロード・リポジトリ(AWR)レポートで"FLASHBACK BUF FREE BY RVWR"待機イベントが頻繁に発生すると、一般的には、フラッシュバック・データベースにおけるI/O帯域幅が不十分です。
フラッシュバック・データベースにメモリー内バッファ領域をさらに付与する場合は、LOG_BUFFER初期化パラメータを8MB以上に設定します。4GBを超えるSGAを備える大規模データベースの場合、LOG_BUFFERを32MBから64MBの範囲の値に設定することを想定します(LOG_BUFFERと、32ビットおよび64ビットのオペレーティング・システムでの有効値の詳細は、『Oracle Databaseリファレンス』を参照してください)。
Data Guardスタンバイ・データベースがある場合、DB_FLASHBACK_RETENTION_TARGETを常にスタンバイ・データベース上でプライマリと同じ値に設定します。DB_FLASHBACK_RETENTION_TARGET初期化パラメータを、次のいずれかの適用される条件で指定されている最大値に設定します。
Data Guardフェイルオーバー後にフラッシュバック・データベースを利用して障害が発生したプライマリ・データベースを復元するには、ほとんどの場合、DB_FLASHBACK_RETENTION_TARGETを60 (分)以上に設定して、障害が発生したプライマリの復元を有効化します。
複数の停止が発生したケースを想定してください。たとえば、最初にネットワークの停止、しばらく後にプライマリ・データベースの停止が発生すると、フェイルオーバー時にプライマリ・データベースとスタンバイ・データベース間にトランスポート・ラグが生じる場合があります。このような場合は、DB_FLASHBACK_RETENTION_TARGETを、対応可能な最大トランスポート・ラグを60 (分)にプラスした合計と等しい値に設定します。これによって、障害が発生したプライマリ・データベースを、スタンバイがプライマリになったとき(プライマリ復元の要件)のSCNよりも前のSCNに必ずフラッシュバックできます。
ユーザー・エラーまたは論理破損からの高速ポイント・イン・タイム・リカバリにフラッシュバック・データベースを使用中の場合、DB_FLASHBACK_RETENTION_TARGETを、データベースのリカバリを行う先の過去の最も遠い時間と等しい値に設定します。
高速リカバリ領域の構成の詳細は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。
フラッシュバック・データベース操作の進捗状況は、V$SESSION_LONGOPSビューを問い合せることによって監視できます。進捗状況を監視するための問合せの例は次のとおりです。
select sofar, totalwork, units FROM v$session_longops WHERE opname = 'Flashback Database';
同じポイントにフラッシュバックすることが必要な繰返しのテストについては、フラッシュバック・データベースを有効化するかわりにフラッシュバック・データベースの保証付きリストア・ポイント(GRP)を使用して、領域使用率を最小限に抑えます。
一般的に言って、フラッシュバック・データベースを有効化してもパフォーマンスにはほとんど影響がありません。Oracle Database 11gリリース2以降では、著しいパフォーマンスの機能拡張があり、フラッシュバック・データベースを最初に有効化する場合やバッチのダイレクト・ロード中のオーバーヘッドがほとんど削減されます。詳細は、次のWebサイトのMy Oracle Support Note 565535.1の『フラッシュバック・データベースのベスト・プラクティスおよびパフォーマンス』を参照してください。
https://support.oracle.com/CSP/main/article?cmd=show&type=NOT&id=565535.1
|
関連項目:
|
ファスト・スタート・リカバリ機能により、クラッシュからのリカバリに必要な時間が短縮されます。また、使用済バッファの数、および最新のREDOレコードと最後のチェックポイントとの間に生成されるREDOレコードの数を制限して、リカバリの制御および予測を行うことができます。
インスタンスのリカバリ時間を制御するには、FAST_START_MTTR_TARGET初期化パラメータを設定します。ファスト・スタート・リカバリ機能では、FAST_START_MTTR_TARGET初期化パラメータによって、インスタンス障害またはシステム障害からのリカバリ時間を簡単に構成できます。このパラメータは、リカバリ時間目標(RTO)の目標値、つまりインスタンスを起動してキャッシュ・リカバリの実行にかかる時間(秒単位)の目標値を指定します。このパラメータを設定すると、データベースはその目標を達成するために増分チェックポイントの書込みを管理します。このパラメータに現実的な値を選択した場合、選択したおおよその平均秒数内でデータベースがリカバリされます。
最初に、FAST_START_MTTR_TARGET初期化パラメータを300 (秒)、またはリカバリ時間目標(RTO)の目標値に必要な値に設定します。
ピーク負荷時のノードやインスタンスの障害などの場合の停止テストをお薦めします。
|
関連項目:
|
データ・ブロックは、認識されているOracleデータベース形式ではないか、または内容に内部的な一貫性がないと破損します。データ・ブロック破損は、内部のOracle制御情報やアプリケーションおよびユーザー・データにダメージを与えて、これがクリティカル・データおよびサービスの重大な損失につながる場合があります。Oracleデータベースの破損の防止、検出および修復機能は、保護対象のデータおよびトランザクションの内部知識と、包括的な高可用性ソリューションのインテリジェント統合を基に構築されています。データ破損からのリカバリの詳細は、12.2.7項「データ破損からのリカバリ」を参照してください。
破損が検出されると、OracleはData Guard、ブロック・メディア・リカバリおよびデータファイル・メディア・リカバリを提供してデータをリカバリします。人為的エラーまたはアプリケーション・エラーで引き起こされたデータベース全体の論理破損は、Oracle Flashbackテクノロジによって元に戻すことができます。ツールは論理データ構造の予防的検証にも使用できます。たとえば、SQL*Plus ANALYZE TABLE文はブロック間の破損を検出します。
|
関連項目:
|
最も包括的なデータ破損の防止および検出を実現するには、次のことを行います。
ブロック破損の拡大を防止するには、フィジカル・スタンバイ・データベースでOracle Data Guardを使用します。Oracle Data Guardは、データの損失および破損や、書込みの欠落からOracleデータを保護する場合に最適なソリューションです。詳細は、8.3項「Data Guardの一般構成ベスト・プラクティス」を参照してください。
Oracleデータベースのブロック破損初期化パラメータを、Data Guardのプライマリ・データベースおよびスタンバイ・データベースで設定します。
| プライマリ・データベース上の設定 | スタンバイ・データベース上の設定 |
|---|---|
DB_BLOCK_CHECKSUM=FULL DB_LOST_WRITE_PROTECT=TYPICAL DB_BLOCK_CHECKING=FULL |
DB_BLOCK_CHECKSUM=FULL DB_LOST_WRITE_PROTECT=TYPICAL DB_BLOCK_CHECKING=FULL |
パフォーマンス・オーバーヘッドはブロック変更ごとに発生するため、パフォーマンス・テストはDB_BLOCK_CHECKINGパラメータの設定時に特に重要です。プライマリ・データベースまたはスタンバイ・データベースのいずれかで、DB_BLOCK_CHECKING=MEDIUMを最小の設定(索引ブロックではなくデータ・ブロック上のブロック・チェック)にすることを強くお薦めします。DB_BLOCK_CHECKINGをMEDIUMまたはFULLにすることを有効化するパフォーマンス・オーバーヘッドがプライマリ・データベースで許容されない場合、スタンバイ・データベースでDB_BLOCK_CHECKINGをMEDIUMまたはFULLに設定します。
|
注意: これらの設定の変更時は、綿密なパフォーマンス評価が推奨されます。 |
|
関連項目:
|
ディスク障害からの保護にディスクのミラー化を提供する場合は、Oracle Automatic Storage Management (Oracle ASM)を使用します。詳細は、3.2項「自動ストレージ管理(Oracle ASM)を使用したデータベース・ファイルの管理」を参照してください。
最適な破損の修復にはOracle ASM HIGH REDUNDANCYを使用します。ディスク・グループでOracle ASM冗長性を使用すると、I/Oエラーまたは破損の発生時にミラー・エクステントをデータベースで使用できます。継続的な保護を目的として、Oracle ASMの冗長性により、I/Oエラーの発生時にエクステントをディスク上の別の領域に移動する機能が提供されます。Oracle ASMによる冗長性メカニズムは、メディア・エラーを戻す不良セクターがある場合に役立ちます。詳細は、3.3.2項「冗長性を使用したディスク障害からの保護」を参照してください。ASM外部冗長性を使用している場合、自動ASM破損修復が使用できないので注意してください。
自動ブロック修復にはOracle Active Data Guardオプションを使用します。Active Data Guardの詳細は、8.6項「Oracle Active Data Guardのベスト・プラクティスの使用」を参照してください。
データ・リカバリ・アドバイザを構成し、その構成を使用してデータ障害を自動的に診断します。詳細は、4.2.2項「データ・リカバリ・アドバイザを使用したデータ障害の検出、分析および修復」を参照してください。
(ほとんどの場合、人為的エラーによって引き起こされた)論理破損からの高速ポイント・イン・タイム・リカバリと、フェイルオーバー後のプライマリ・データベースの高速復元には、Oracle Flashbackテクノロジを有効化します。詳細は、4.1.4項「フラッシュバック・データベースの有効化」を参照してください。
Recovery Manager (RMAN)によるバックアップおよびリカバリ計画を実装し、RMANのBACKUP VALIDATE CHECK LOGICAL...スキャンを定期的に使用して破損を検出します。詳細は、第7章「バックアップとリカバリの構成」を参照してください。バックアップおよびリストア操作中の追加的なブロック・チェックにはRMANおよびOracle Secure Backupを使用します。破損のチェックと修復、中央バックアップ検証、本番データベースへの影響の縮小、Enterprise Cloudバックアップおよびリカバリ・ソリューションを含め、バックアップおよびリカバリの検証にはZero Data Loss Recovery Applianceを使用します。
Exadata Database MachineおよびSparc Superclusterには、包括的なOracle Hardware Assisted Resilient Data (HARD)仕様も実装されており、Oracleブロック・データ構造を独自レベルで検証できます。Oracle Exadata Storage Server Softwareは、データベースとストレージ間のI/Oパスに発生した破損を検出します。HARDチェックが失敗した場合、破損データがディスクに書き込まれないようにします。Exadata HARDチェックの例として、1) REDOおよびブロックのチェックサム、2) ログ順序の修正、3) ブロック・タイプ検証、4) ブロック番号検証、5) ブロック・マジック番号、ブロック・サイズ、順序番号、ブロック・ヘッダー/テール・データ構造などのOracleデータ構造があります。
Oracle Exadata Storage Server Softwareには、自動ハード・ディスク・スクラブおよび修復機能が用意されています。この機能は、ハード・ディスクがアイドル状態のときに定期的にハード・ディスクを自動で検査して修復します。ハード・ディスクで不良セクターが検出された場合、Oracle Exadata Storage Server Softwareは、別のミラー・コピーからデータを読み取ることによって不良セクターを修復するようOracle ASMに自動的にリクエストを送信します。デフォルトでは、ハード・ディスクの修正は2週間ごとに実行されます。非常に軽量で、アクセス頻度の低いデータ関連であっても物理ブロック破損を修正することで、大きな価値が付加されます。
Oracle Data Integrity eXtensions (DIX) + T10 Data Integrity Field (DIF): Oracle Linuxチームがハードウェア・ベンダーおよびOracleデータベース開発と協力して、Oracleデータ整合性拡張機能をOracleのオペレーティング・システム(Linux)から、様々なベンダーのホスト・アダプタからストレージ・デバイスに至るまでに拡張しました。このような拡張機能を使用して、DIXでは、チェックサム検証による読取りおよび書込みについてエンドツーエンドのデータ整合性が保証されます。前提条件として、動作保証されたストレージ、HBAおよびディスク・ファームウェアの利用があります。このパートナシップの例には、Oracle Linux、EmulexまたはQLogicホスト・バス・アダプタ、EMC VMAXなどのT10 DIF対応のストレージ・アレイとのDIX統合があります。
|
関連項目:
|
破損データがディスクに書き込まれた場合、または正常なデータの書込み後にコンポーネント障害によってそのデータが破損した場合は、破損したブロックをできるだけ早く検出することが重要です。
データベースのエラーおよびアラートを監視するには、次のことを行います。
Enterprise Managerを使用して、検出されたすべてのターゲットの可用性を監視し、エラーおよびアラートを検出します。HA Consoleから1つのビューですべてのターゲットを参照することもできます。
ブロック破損が検出または修復されると自動的に更新される、V$DATABASE_BLOCK_CORRUPTIONビューを問い合せます。
データ・リカバリ・アドバイザを構成すると、データ障害の自動診断、適切な修復オプションの判別と提供、およびユーザー・リクエストに応じた修復操作の実行が行われます。詳細は、4.2.2項「データ・リカバリ・アドバイザを使用したデータ障害の検出、分析および修復」を参照してください。
|
注意: データ・リカバリ・アドバイザはOracle Enterprise Manager Support Workbench (サポート・ワークベンチ)、 状態モニターおよびRMANと統合されています。 |
Data Guardを使用して、物理破損を検出し、書込みの欠落を検出します。
Data Guardは、REDOストリームで破損ブロックのために適用プロセスが停止した場合、または書込みの欠落を検出した場合に、物理破損を検出します。Data Guard構成の管理および監視にはEnterprise Managerを使用します。自動ブロック・メディア・リカバリを利用することで、プライマリ・データベースまたはフィジカル・スタンバイ・データベースのどちらかで検出された破損ブロックは、Active Data Guardオプションが使用されていると自動的に修正できます。自動ブロック・メディア・リカバリの詳細は、12.2.7.2項「Active Data Guardの使用」を参照してください。
SQL*Plusを使用して、データファイル破損およびブロック間破損を検出します。
ANALYZE TABLE tablename VALIDATE STRUCTURE CASCADE SQL*Plus文を発行します。破損の判別後は、表を再作成するか、他の操作を行うことができます。
Recovery Manager (RMAN)によるバックアップおよびリカバリ計画では、物理ブロック破損を検出できます。
RMAN BACKUP VALIDATE CHECK LOGICALを使用したさらに徹底的なRMANチェックでは、論理ブロック破損を検出できます。
|
関連項目:
|
ほとんどの環境で、Oracle Databaseは、非同期I/Oが使用可能で、特定のプラットフォームに対して適切であるかどうかを自動的に検出し、DISK_ASYNCH_IO初期化パラメータを通じて非同期I/Oを有効化します。ただし、パフォーマンスを最大限に向上させるには、非同期I/Oが実際に使用されていることを確認することが常にベスト・プラクティスです。V$IOSTAT_FILEビューを問い合せて、非同期I/Oが使用されているかどうか確認します。
SQL> select file_no,filetype_name,asynch_io from v$iostat_file;
非同期I/Oを明示的に有効化するには、次のようにDISK_ASYNCH_IO初期化パラメータをTRUEに設定します。
ALTER SYSTEM SET DISK_ASYNCH_IO=TRUE SCOPE=SPFILE SID='*';
Oracle ASMを使用している場合、デフォルトでI/Oが非同期に実行されていることに注意してください。
|
関連項目: DISK_ASYNCH_IO初期化パラメータの詳細は、『Oracle Databaseリファレンス』を参照してください。 |
LOG_BUFFER初期化パラメータを8MB以上に設定します。
フラッシュバックが有効で、4GB以上のSGAを持つデータベースでは、LOG_BUFFERを64MB以上に設定します。
Oracle Data Guardの非同期REDO転送で使用していて、REDO生成速度が高い場合は、LOG_BUFFERを256MB以上に設定します。そうすることで、非同期REDO転送では、ログ・バッファからREDOを読み取り、オンラインREDOログへのディスクI/Oを避けることができます。詳細は、第8章「Oracle Data Guardの構成」を参照してください。
|
関連項目:
|
4GB以上のメモリーを持つシステムの場合、MEMORY_TARGET=0を設定して自動メモリー管理を無効化し、SGA_TARGETを設定して自動共有メモリー管理を有効化します。
データベース・サーバー上のSGAとPGAのメモリー割当ての合計は、常に、システムの物理メモリーより少なくする必要があり、保守的に考えると合計システム・メモリーの75%より少なくする必要があります。ただし、PGA_AGGREGATE_TARGETは厳密な制限ではなく、一部のデータ・ウェアハウスやレポーティングのアプリケーションでは、PGAメモリーをPGA_AGGREGATE_TARGETの3倍まで拡大できます。
メモリーの使用率を正確に把握するために、Oracle Enterprise Managerを使用するか、v$pgastatおよびオペレーティング・システムの統計を問い合せて、PGAメモリーとホストベースのメモリーの使用率を監視します。
データベースおよびアプリケーションの数を調整するか、または割り当てられたメモリー設定を減らして、メモリー・ページングを回避します。PGA_AGGREGATE_LIMITを設定してPGAメモリーの使用量に対して厳密な制限を指定します。PGA_AGGREGATE_LIMITの値を超過している場合は、Oracle Databaseにより、最も調整が困難なPGAメモリーを消費しているセッションのコールが最初に中断されます。それでもPGAメモリーの使用量合計が上限を超えている場合は、次に、最も調整が困難なメモリーを使用しているセッションが終了します。
|
注意:
|
Linuxオペレーティング・システムでは、ASMおよびデータベース・インスタンスがSGA用にHugePagesを使用できるように、HugePagesを構成することをお薦めします。HugePagesは、リリース2.6からLinuxカーネルに統合された機能です。この機能は、より大きいページを指定する4KBのページ・サイズの代替方法となります。HugePagesを使用するメリットは、メモリーがディスクにページングされていないことを確認する際に、ページ表のオーバーヘッドを減らして、メモリー・リソースを節約することです。これは、メモリー全体のパフォーマンスの向上に役立ちます。この次に、ノード全体の安定性がHugePagesを使用するメリットを享受します。
init.oraパラメータuse_large_pages=onlyを設定して、データベース・インスタンスのSGA全体がHugePagesに格納されていることを確認できます。このパラメータを設定すると、HugePagesからSGAのメモリーのすべてを取得できる場合のみ、確実にインスタンスが起動します。このため、データベース・インスタンスにuse_large_pages=onlyを設定することをお薦めします。
ASMインスタンスの場合、use_large_pages=true (デフォルト値)のままにします。この設定によって、使用可能な場合に確実にHugePagesを使用しますが、さらに、HugePagesが構成されていない場合や構成が不十分な場合には、Grid Infrastructureの一部として確実にASMが起動します。
HugePagesは自動メモリー管理と互換性がないため、自動共有メモリー管理を使用します。
|
関連項目:
|
V$INSTANCE_RECOVERYビューのRECOVERY_ESTIMATED_IOSの値が小さい場合(5000未満など)、パラレル・リカバリのオーバーヘッドがそのメリットを上回っている可能性があります。この状況は、FAST_START_MTTR_TARGETの設定が極端な場合によく発生します。この場合、RECOVERY_PARALLELISMを1に設定してパラレル・リカバリを無効化してください。
Oracleデータベースの管理性を向上するには、次のことを行います。
Oracle ClusterwareをOracle Real Application Clusters (Oracle RAC)またはOracle Restartとともに構成すると、主要なアプリケーションと、Oracle ASMインスタンス、リスナー、アプリケーション・エージェントおよびプロセスなどのOracleサービスを自動的に再起動できます。
Oracle Restartは、単一インスタンスの(クラスタ化されていない) Oracleデータベースおよびそのコンポーネントの可用性を向上します。Oracle Restartは、単一インスタンス環境でのみ使用されます。Oracle Real Application Clusters(Oracle RAC)環境では、Oracle Clusterwareによってコンポーネントを自動再起動する機能が提供されます。
Oracle Restartを構成すると、ハードウェアまたはソフトウェア障害の後、あるいはデータベースのホスト・コンピュータが再起動するときは必ず、データベース、リスナー、およびその他のOracleコンポーネントは自動的に再起動します。また、Oracleコンポーネントが、コンポーネントの依存性に応じて、確実に正しい順序で再起動します。
Oracle Restartは、Oracle Databaseホームとは別にインストールするOracle Grid Infrastructureホームから実行されます。
|
関連項目:
|
データ・リカバリ・アドバイザを使用し、データ障害の迅速な診断、適切な修復オプションの判別と提供、およびユーザー・リクエスト時の修復を行います。ここでは、データ障害とは、ディスク上の永続的データの破損または損失を指します。自動データ修復を行う集中化されたツールを持つデータ・リカバリ・アドバイザを使用すると、Oracleデータベースの管理性と信頼性が向上し、平均リカバリ時間(MTTR)が減少します。データ・リカバリ・アドバイザは、次のような兆候に基づいて障害を診断します。
存在しない、適切なアクセス権限がない、オフラインに移行したなどの理由によりアクセスできないコンポーネント
ブロック・チェックサムの障害や無効なブロック・ヘッダー・フィールド値などの物理破損
ソフトウェアの不具合を原因とする論理破損
不適切なコンポーネント・バージョンを原因とする非互換性障害
オープン・ファイル数の制限の超過、チャネル・アクセス障害、ネットワークまたはI/OのエラーなどのI/O障害
データベースのオープンを妨げる不適切な初期化パラメータ値などの構成エラー
診断された障害は、自動診断リポジトリ(ADR)に記録されます。データ・リカバリ・アドバイザは、次の処理に基づいてリカバリ計画を自動的に決定します。
障害がデータベースにより検出されてADRに格納された後にのみ、修復アドバイスを生成して障害を修復します。
効率的なリカバリのために複数の障害を集約します。
実行可能なリカバリ・オプションのみを提供します。
オプションごとのデータ損失を示します。
通常、データ・リカバリ・アドバイザは、自動修復オプションと手動修復オプションの両方を提供します。適切であれば、データ・リカバリ・アドバイザに自動的に修復を実行させ、修復の成功を検証し、関連する修復済障害をクローズできます。
|
注意: 現在のリリースのデータ・リカバリ・アドバイザでは、単一インスタンス・データベースのみがサポートされています。Oracle RACデータベースはサポートされていません。データ・リカバリ・アドバイザでサポートされているデータベース構成の詳細は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。 |
|
関連項目:
|
パフォーマンス問題を特定および修正するためには、効果的なデータの収集と分析が不可欠です。Oracleは、データベース・パフォーマンスに関する情報を収集する複数のツールを用意しています。
Oracleデータベースの自動パフォーマンス・チューニング機能は、次のもので構成されます。
自動ワークロード・リポジトリ(AWR)を使用する際は、次のベスト・プラクティスを検討してください。
問題発生時に比較目的で使用するパフォーマンス・データのベースラインを作成します。このベースラインはシステムのピーク負荷の代表値となります。
ストレス・テスト中にパフォーマンスのピークを取得する場合や、パフォーマンス問題を診断する場合、AWR自動スナップショットの間隔を10から20分に設定します。
通常のワークロードの場合、60分間隔で十分です。
|
関連項目: 自動ワークロード・リポジトリの管理の詳細は、『Oracle Databaseパフォーマンス・チューニング・ガイド』を参照してください。 |
サーバー・パラメータ・ファイル(SPFILE)は、データベースのすべてのインスタンスに関連付けられたすべてのデータベース初期化パラメータを保持する単一の集中管理パラメータ・ファイルです。このファイルにより、データベース・パラメータを管理するための簡単で確実な永続的環境が提供されます。Oracle Data Guardブローカを使用する場合、SPFILEは必須です。
|
関連項目:
|
自動UNDO管理を使用すると、Oracleデータベース・サーバーで効果的かつ効率的にUNDO領域を管理できるため、管理作業の複雑さとコストが削減されます。Oracleデータベースで内部的にUNDOセグメントを管理する場合、現在のワークロード要件に合せてUNDOセグメントのサイズと数が自動的に調整されるため、UNDOブロックと読取り一貫性の競合は発生しません。
自動UNDO管理を使用するには、次の初期化パラメータを設定します。
このパラメータをAUTOに設定します。
UNDOデータを保存する希望時間を秒単位で指定します。このパラメータは、すべてのインスタンスで同じに設定する必要があります。
インスタンスごとに一意のUNDO表領域を指定します。
フラッシュバック問合せ、フラッシュバック・バージョン問合せ、フラッシュバック・トランザクション問合せ、フラッシュバック表などの高度なオブジェクト・リカバリ機能では、自動UNDO管理が必要です。それらが機能するかどうかは、1つ前の時点でのデータを参照するためにUNDO情報を利用できるかどうかによります。
Oracleデータベースのデフォルトでは、データベース使用統計の収集とUNDO容量要件の評価により、自動的にUNDO保存期間が調整されます。UNDO表領域で保存保証を有効化(CREATE DATABASEまたはCREATE UNDO TABLESPACE文でRETENTION GUARANTEE句を指定)していない場合、Oracle DatabaseではUNDO保存期間がUNDO_RETENTION値を下回ることがあります。
フラッシュバック・テクノロジ機能の使用が要件に組み込まれている場合、ベスト・プラクティス推奨事項は、UNDO表領域でRETENTION GUARANTEEを有効化し、次のガイドラインに基づいてUNDO_RETENTIONの値を設定することです。
間違ったトランザクションが実行された場合に、その検出にかかる時間を算出します。その値に2をかけます。
UNDOアドバイザを使用して、UNDO_RETENTIONをステップ1で推奨された値に設定した場合の、最小限のUNDO表領域サイズを計算します。
UNDO表領域でAUTOEXTENDオプションが無効にされている場合、ステップ2で算出した容量の領域を割り当てるか、UNDO_RETENTIONパラメータの値を減らします。
UNDO表領域でAUTOEXTENDオプションが有効にされている場合は、データファイルをステップ2で算出したサイズまで拡張するために利用できるディスク領域が十分にあることを確認します。指定した自動拡張MAXSIZE値が十分な大きさであることを確認します。
RETENTION GUARANTEEオプションを使用すると、表領域に構成されている領域がトランザクション・スループットの必要量より少ない場合、次の一連のイベントが発生します。
自動拡張可能なファイルがある場合、保存されたUNDOデータを格納できるようそのファイルが自動拡張されます。
ディスクが85%フルになったことが警告アラートにより報告されます。
ディスクが97%フルになったことがクリティカル・アラートにより報告されます。
トランザクションに領域不足エラーが戻されます。
|
関連項目:
|
ローカル管理表領域は、ディクショナリ管理表領域よりパフォーマンスに優れており、管理が容易で領域が断片化する心配もありません。ローカル管理表領域では、データファイルのヘッダーに格納されたビットマップを使用します。ディクショナリ管理表領域とは異なり、領域の割当てと割当て解除において集中管理されたリソースに対する競合は発生しません。
|
関連項目: ローカル管理表領域の詳細は、『Oracle Database管理者ガイド』を参照してください |
自動セグメント領域管理により、領域管理タスクを簡略化することで、人為的エラーの発生を抑制できます。別のメリットとして、領域管理関連のパフォーマンス・チューニングが不要になります。この機能により、表や索引などのオブジェクト内の空き領域の管理が容易になり、領域使用率が向上し、簡単な管理操作でパフォーマンスとスケーラビリティが大幅に改善します。自動セグメント領域管理機能は、デフォルトの属性を使用して作成されたすべての表領域でデフォルトで有効化されます。
|
関連項目: 自動セグメント領域管理の詳細は、『Oracle Database管理者ガイド』を参照してください。 |
一時表領域により、複数のソート操作の同時実行性の向上、ソート操作のオーバーヘッドの削減、およびデータ・ディクショナリによる領域管理操作の回避が可能になります。これは、システム・リソースの使用とデータベース・パフォーマンスの両方の観点からして、一時セグメントを処理するためのより効率的な方法です。
ベスト・プラクティスは、個々のユーザーに一時表領域が割り当てられているかどうかにかかわらず、最も効率的なソート操作で一時セグメントが確実に使用されるように、データベース全体のデフォルト一時表領域を指定することです。
| デフォルト一時表領域の指定時期 | その後の手順 |
|---|---|
| データベースの作成時 | CREATE DATABASE文のDEFAULT TEMPORARY TABLESPACE句を使用します。 |
| データベースの作成後 | ALTER DATABASE文を使用します。 |
デフォルト一時表領域を使用すると、すべてのディスク・ソート処理は一時表領域で発生し、他の表領域が誤ってソートに使用されることはなくなります。
|
関連項目: 表領域管理の詳細は、『Oracle Database管理者ガイド』を参照してください。 |
再開可能領域割当ては、領域割当て障害が発生した場合にデータベース操作を一時停止して後から再開する方法です。データベースはエラーを戻さず、関連する操作を一時停止します。プロセスを再起動する必要はありません。領域問題が解決すると、一時停止されていた操作は自動的に再開されます。
再開可能領域割当てを使用するには、RESUMABLE_TIMEOUT初期化パラメータを使用して、システム・レベルで指定するか、ALTER SESSION文の句(たとえばALTER SESSION ENABLE RESUMABLE文)を使用して、セッション・レベルで有効化します。新規セッションのデフォルトでは、RESUMABLE_TIMEOUT初期化パラメータをゼロでない値に明示的に設定した場合を除き、再開可能モードは無効です。
|
関連項目: 再開可能領域割当ての管理方法の詳細は、『Oracle Database管理者ガイド』を参照してください。 |
Oracle Database Resource Manager (リソース・マネージャ)を使用すると、データベース管理者は、リソース割当てがエンタープライズのビジネス目標に合うようにリソース管理の設定を詳細に制御できます。リソース・マネージャでは、Oracleデータベース・サーバー内の作業に優先順位を設定できます。データベースの可用性には、その機能性とパフォーマンスの両方が含まれます。データベースが使用可能であっても、ユーザーの必要とするパフォーマンス・レベルに到達しなければ、可用性とサービス・レベルの目標は満たされません。アプリケーション・パフォーマンスは、データベースにアクセスする各アプリケーションにリソースがどのように配置されるかによって大きく変化します。リソース・マネージャの主な目的は、Oracleデータベース・サーバーでリソース管理の設定をより詳細に制御して、オペレーティング・システムの不十分な管理やオペレーティング・システムのリソース・マネージャを原因として発生する問題を回避することです。
Enterprise Managerを使用して、リソース・プランを管理します。
リソース・マネージャでテストする際は、CPUリソースの不足を生じさせる十分な負荷がシステム上にあることを確認します。
|
関連項目:
|
この項で列挙する非コンテナ・データベース(非CDB)に対するベスト・プラクティスもすべて、Oracle Multitenantコンテナ・データベース(CDB)に適用されます。次のベスト・プラクティスも適用されます。
AL32UTF8キャラクタ・セットでCDBを作成します。これにより、どのプラガブル・データベース(PDB)もキャラクタ・セットに関係なくこのCDBにプラグインできます。
PDBアップグレードの宛先として使用されるようにCDBを作成している場合は、ソースCDBと宛先PDBの両方に対してCOMPATIBLEパラメータが必ず同じ値に設定されるようにします。これにより、前のリリースへのフォールバックを簡単にアンプラグ/プラグできます。宛先CDBのターゲットとされたPDBがすべてプラグインされ、十分にテストされている場合は、COMPATIBLEの設定を高くします。
Database Creation Assistant (DBCA)により、CDBの作成時にすべてのデータベース・オプションが強制的に有効になり、どのPDBもオプションの使用に関係なくこの新しいCDBにプラグインできるようになります。CDBのデータベース・オプションを無効にしないでください。
フラッシュバック・データベースの有効化をお薦めします。ただし、現時点では、コンテナ内のすべてのPDBが同一時点までフラッシュバックされるように、CDBレベルでフラッシュバックが実行されます。
