| Oracle Database高可用性ベスト・プラクティス 11gリリース1（11.1） B54839-01 |
|
 戻る |
 次へ |
この項に記載されているベスト・プラクティスは、『Oracle Database高可用性概要』で説明されている、次のOracle Databaseリリース11gアーキテクチャに適用されます。
Oracle Database
Oracleクラスタウェアを使用したOracle Database
Oracle Real Application Clusters（Oracle RAC）を使用したOracle Database
拡張クラスタ上のOracle RACを使用したOracle Database
Oracle Data Guardを使用したOracle Database
OracleクラスタウェアとData Guardを使用したOracle Database
Oracle RACとOracle Data Guardを使用したOracle Database
Oracle Streamsを使用したOracle Database
Oracle Data Guardの構成では、この項の推奨事項は、プライマリ・データベースとスタンバイ・データベースのどちらでも同じです。停止時間の削減または回避、破損リスクの低減、およびリカバリ・パフォーマンスの向上を図るには、これらのプラクティスを採用する必要があります。
この項には、データベースを構成するための一般的なベスト・プラクティスが含まれます。
リカバリ時間を短縮し、可用性と冗長性を向上するためには、次のベスト・プラクティスを使用します。
ARCHIVELOGモードでは、オンラインでのデータベース・バックアップが可能です。リストアされている時点より後の時点にデータベースをリカバリするには、このモードで運用する必要があります。Oracle Data Guardやフラッシュバック・データベースなどの機能を使用する場合、本番データベースはARCHIVELOGモードで実行する必要があります。
|
関連項目: 自動アーカイブの使用方法の詳細は、『Oracle Database管理者ガイド』を参照してください。 |
Oracleログの多重化を使用して、データ領域およびフラッシュ・リカバリ領域の各REDOグループに複数のREDOログ・メンバーを作成します。これにより、REDOログに関連する障害（いずれかのメンバーのディスク障害やI/O障害、またはオペレーティング・システム・コマンドにより間違ってメンバーを削除するといったユーザー・エラー）からデータを保護できます。少なくとも1つのREDOログ・メンバーが使用できれば、インスタンスは継続して動作できます。
|
注意: スタンバイREDOログは多重化しないでください。 |
すべてのオンラインREDOログ・ファイルは、同じサイズとし、通常のアクティビティでほぼ1時間に1回切り替わるように構成します。アクティビティのピーク時でも、20分に1回より高い頻度で切り替わらないようにします。
ログ・スイッチ後にグループが使用可能になるのをログ・ライター・プロセスが待機することのないように、少なくとも4つのオンライン・ログ・グループを用意する必要があります。グループが使用できなくなる可能性があるのは、チェックポイント処理が完了していない場合や、グループがアーカイブされていない場合です。
|
関連項目:
|
フラッシュ・リカバリ領域は、Oracleが管理するディスク領域であり、バックアップ・ファイルとリカバリ・ファイルを集中管理するためのディスク上の場所です。
フラッシュ・リカバリ領域は、次のデータベース初期化パラメータを設定することで定義します。
このパラメータでは、フラッシュ・リカバリ領域のデフォルトの場所を指定します。
このパラメータでは、リカバリ領域の場所に作成されるデータベースのリカバリ・ファイルで使用される合計領域について、強い制限の値をバイト単位で指定します。
Oracle Suggested Backup Strategy described in the 『Oracle Database 2日でデータベース管理者』で説明されている推奨バックアップ計画では、リカバリのための主要な場所として、フラッシュ・リカバリ領域を使用することを推奨しています。フラッシュ・リカバリ領域のサイズが適切であれば、修復に必要なファイルをすぐに使用できます。推奨される最低限のディスク制限値は、データベース、増分バックアップ、テープにコピーされていないすべてのアーカイブREDOログ、およびフラッシュバック・ログの合計サイズです。
|
注意: Oracle Streamsによる取得用のアーカイブREDOログ・ファイルを、フラッシュ・リカバリ領域に単独で存在するように構成しないでください。かわりに、データベースのOracle Streamsによる取得プロセス用としてフラッシュ・リカバリ領域とは別に個別のログ・アーカイブ保存先を構成します。この操作が必要となる理由は、フラッシュ・リカバリ領域のアーカイブREDOログ・ファイルは、ディスク領域の不足を原因として自動的に削除される可能性があるためと、バックアップ保存ポリシーを満たさなくなったログは、ログ・ファイルがOracle Streamsで必要とされていても、RMANによって削除される可能性があるためです。 |
|
関連項目: フラッシュ・リカバリ領域のサイズ指定と保存期間の設定の詳細は、『Oracle Databaseバックアップおよびリカバリ基礎』を参照してください。 |
フラッシュバック・データベースは、意図と異なるデータベースの変更を元に戻すための、ポイント・イン・タイム・リカバリに代わる方法です。フラッシュバック・データベースを使用すると、データベース全体を復元して、一定期間内のデータベースの変更の影響を元に戻すことができます。影響は、データベース・ポイント・イン・タイム・リカバリ（DBPITR）と類似しています。複雑な手順を使用することなく、単一のRMANコマンドまたはSQL*Plus文を発行してデータベースをフラッシュバックできます。
フラッシュバック・データベースを構成して有効化する場合、次のことを確認してください。
本番データベースがARCHIVELOGモードで実行されていることを確認してください。
フラッシュバックの書込みスループットを維持するため、十分なI/O帯域幅がフラッシュ・リカバリ領域で使用できることを確認してください。
フラッシュバック・データベースでは、通常の実行時アクティビティで、フラッシュバック・リカバリ領域に存在するフラッシュバック・ログにデータ・ブロックの変更前のイメージがバッファされて書き込まれます。フラッシュバックの書込みが遅い場合（flashback free buffer waits待機イベントで判別できます）、データベース・スループットが影響を受けます。フラッシュバック・データベースによるディスク書込みの容量は、ワークロードとアプリケーション・プロファイルに応じて異なります。十分なディスク・スピンドルおよびI/Oスループットとともにフラッシュバック・リカバリ領域を使用する一般的なOLTPワークロードの場合、フラッシュバック・データベースにより発生するオーバーヘッドは、2%未満です。
スタンバイ・データベースを使用する場合、プライマリ・データベースとスタンバイ・データベースの両方でDB_FLASHBACK_RETENTION_TARGET初期化パラメータに同じ値を設定します。
大規模な本番データベースでは、LOG_BUFFER初期化パラメータを8MB以上に設定すると、データベースでは、フラッシュバック・データベース・ログの書込み用に最大メモリー（通常は16MB）が確実に割り当てられます。
フラッシュバック・データベースでは、プライマリまたはスタンバイ・データベースをロール移行より前の時点まで戻すことができます。また、保証付きリストア・ポイントを使用して、RESETLOGS操作より前の時点にデータベースをフラッシュバックできるため、より柔軟に人為的エラーを検出および修正できます。
次の機能を使用する場合、フラッシュバック・データベースまたは保証付きリストア・ポイントが必要です。
ファスト・スタート・フェイルオーバー: 自動フェイルオーバー後にブローカでプライマリ・データベースを自動的に復元する場合、フラッシュバック・データベースが必要です。フェイルオーバー後に無効化された可能性があるバイスタンダ・スタンバイ・データベースは、フラッシュバック・データベースの有効化時にのみ復元できます。
スナップショット・スタンバイ・データベース: スナップショット・スタンバイ・データベースをフィジカル・スタンバイ・データベースに変換する場合、保証付きリストア・ポイントが必要です。
フラッシュバック・データベースはオプションですが、データベースのローリング・アップグレードを実行する場合には推奨事項です。アップグレードが失敗した場合に備えて、アップグレードをフォールバックする前に保証付きリストア・ポイントを作成することをお薦めします。アップグレード前の状態にデータベースをリストアするこの方法の方が、実質的にはダウングレード手順より時間がかかりません。ただし、アップグレード前の状態にデータベースをフラッシュバックする手順が有効なのは、アプリケーション・データが変更されていない場合のみであることに注意してください。
一般的に言って、フラッシュバック・データベースを有効化してもパフォーマンスにはほとんど影響がありません。ただし、一部のアプリケーション・プロファイルで、特別な調整やその他の考慮が必要になる場合があります。フラッシュバック・データベースに関する追加の考慮事項やアプリケーションごとのユースケースの詳細は、サポート・ノート565535.1を参照してください（http://metalink.oracle.com/）。
システムにおけるフラッシュバック・データベースのワークロードを監視する場合、自動ワークロード・リポジトリ（AWR）の使用や、V$FLASHBACK_DATABASE_STATまたはV$SYSSTATビューの問合せなど、いくつかのデータ分析方法があります。たとえば、AWRを使用して、フラッシュバック・データベースの有効化時点の前後に収集されたAWRスナップショットを比較できます。AWRスナップショットを確認して、フラッシュバック・ロギングを原因とするシステム使用率を特定することも可能です。監視およびチューニング方法の詳細は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』のフラッシュバック・データベースのパフォーマンスに対する影響の監視に関する項を参照してください。
|
関連項目:
|
ファスト・スタート・リカバリ機能では、クラッシュからのリカバリに必要な時間を短縮できます。また、使用済バッファの数と、最新のREDOレコードと最後のチェックポイントの間に生成されるREDOレコードの数を制限することで、リカバリに境界を設定して予測可能とします。
この機能では、FAST_START_MTTR_TARGET初期化パラメータにより、インスタンスまたはシステム障害からのリカバリ時間を簡単に構成できます。このパラメータでは、予定する目標リカバリ時間（RTO）の目標値を指定します。RTOは、インスタンスを起動してキャッシュ・リカバリを実行するための時間（秒単位）です。このパラメータを設定すると、データベースでは、目標値に適合するよう増分チェックポイントの書込みが管理されます。このパラメータに特定の値を選択した場合、現在のデータベースは、平均でほぼ選択した秒数以内にリカバリされると期待できます。
ピーク負荷時の停止テスト（ノード、インスタンスの障害など）をお薦めします。
|
関連項目:
|
Oracleのデフォルトでは、ディスクから読み取られたデータ・ブロックが常に検証されます。基礎となるディスク、ストレージ・システムまたはI/Oシステムで発生するデータ破損に対して追加の保護および検出を行うには、次の1つ以上の方法も検討する必要があります。
Data Guardの使用とDB_ULTRA_SAFE初期化パラメータの構成
データ破損に対して最も包括的な保護および検出を行うため、Data Guardを使用して、プライマリ・システムとスタンバイ・システムの両方でDB_ULTRA_SAFE初期化パラメータを構成します。
プライマリ・データベースでDB_ULTRA_SAFE=DATA_AND_INDEX初期化パラメータを設定し、適宜データ破損を防止および検出することにより、Oracleデータベースで重要なデータの保護と高可用性が実現します。
DB_ULTRA_SAFE初期化パラメータは、Oracleデータベース内の他のデータ保護動作（順次ミラー書込みの実行に必要なASMなど）も制御します。
表2-1に、DB_ULTRA_SAFEパラメータがDB_BLOCK_CHECKING、DB_BLOCK_CHECKSUMまたはDB_LOST_WRITE_PROTECTの各パラメータに自動的に割り当てる値を示します。
表2-1 DB_ULTRA_SAFE初期化パラメータにより設定されるパラメータ値
DB_ULTRA_SAFEの設定値 |
割り当てられる値 |
|---|---|
|
|
|
|
|
|
|
注意: DB_ULTRA_SAFEパラメータを設定すると、次の初期化パラメータの動作（表2-1参照）が自動的に統合および制御されます。
ただし、初期化パラメータ・ファイルで |
フィジカル・スタンバイ・データベースでは、DB_BLOCK_CHECKSUMパラメータとDB_LOST_WRITE_PROTECTパラメータを次のように指定します。
DB_BLOCK_CHECKSUM=FULL
DB_BLOCK_CHECKSUMがFULLに設定されている場合、ディスク破損とメモリー内破損の両方が検出され、ブロックはディスクに書き込まれません。これにより、フィジカル・スタンバイ・データベースの整合性が維持されます。このパラメータがREDO Applyのパフォーマンスに与える影響は、ごくわずかです。
書込み欠落の保護により、プライマリ上での書込みの逸脱または欠落を原因とする破損がスタンバイ・データベースに伝播および適用されることを防止できます。このパラメータを設定することによるスタンバイ・データベースへの影響は、無視できる程度です。また、HARDソリューションを採用するよりもDB_LOST_WRITE_PROTECT初期化パラメータを設定することをお薦めします。HARDでは、書込みの逸脱および欠落の完全な保護とREDO適用の検証が行われないためです。
スタンバイ・データベースは、プライマリ・データベースとは分離された、REDOデータがチェックおよび検証されるデータベースです。REDO ApplyおよびSQL Applyプロセスがスタンバイ・データベース上で実行する別のレイヤーの検証では、ハードウェア、ソフトウェアまたはネットワークの問題が原因で発生する書込みの逸脱または欠落や破損ブロックを検出できます。これらの問題のほとんどは、プライマリ・データベース上では検出できないか、長期間プライマリ上で気付かれないままとなる可能性があります。
DB_BLOCK_CHECKING初期化パラメータを有効化します。
DB_BLOCK_CHECKINGパラメータを設定するかどうかは、プライマリ・データベース上でのみ検討します。スタンバイ・データベース上でDB_BLOCK_CHECKINGを有効化すると、非常に大きなオーバーヘッドが発生し、REDO Applyのパフォーマンスが大幅に低下する可能性があります。使用環境での影響を測定するテストをお薦めします。
|
注意: DB_BLOCK_CHECKINGパラメータの設定は推奨ですが、それによりREDO Applyプロセスのスループットが大幅に（最大50%程度）低下する可能性があります。
MAAの内部テストでは、REDO ApplyのスループットはOracle Database 11gで2倍となり、バッチ・ワークロードで100MB/秒、OLTPワークロードで50MB/秒に到達しました。 |
データ・リカバリ・アドバイザの構成
データ・リカバリ・アドバイザを構成し、Oracle RAC以外のプライマリ・データベースのデータ障害を迅速に診断および修復します。データ・リカバリ・アドバイザは、定期的にデータ破損をスキャンします。「データ・リカバリ・アドバイザの使用」を参照してください。
Oracle Recovery Manager（RMAN）の構成
Oracle Recovery Manager（RMAN）を構成し、リカバリ関連ファイルのバックアップと管理の自動化、バックアップ時にすべてのバックアップ対象ブロックを確実に検証するためのチェックサムの計算、および物理破損と論理破損の検出を行います。破損を検出するには、RMAN BACKUP VALIDATE CHECK LOGICAL...スキャンを定期的に実行します。「バックアップとリカバリの構成」を参照してください。
Oracle Secure Backupの構成
Oracle Secure Backupを構成し、ローカルおよびリモートのデータ保護を実現するために現在の環境にテープ・バックアップおよび管理を統合します。「Oracle Secure Backupを使用した高速なテープ・バックアップの作成」を参照してください。
ASM冗長性の使用
ディスク・グループでASM冗長性を使用すると、I/Oエラーまたは破損の発生時にミラー・エクステントをデータベースで使用できます。障害に対する継続的な保護を目的として、ASMの冗長性により、I/Oエラーの発生時にエクステントをディスク上の別の領域に移動する機能を提供します。ASMによる冗長性メカニズムは、メディア検出エラーを戻す不良セクターがある場合に役立ちます。
Oracle RAC以外のプライマリ・データベースでデータ・リカバリ・アドバイザを使用し、データ障害の迅速な診断、適切な修復オプションの判別と提供、およびユーザー・リクエスト時の修復を行います。データ・リカバリ・アドバイザは、混乱状態を排除して検出と修復を自動化することで、停止時間を短縮します。このアドバイザは、次のような兆候に基づいて障害を診断します。
存在しない、適切なアクセス権限がない、オフラインに移行したなどの理由によりアクセスできないコンポーネント
ブロック・チェックサムの障害や無効なブロック・ヘッダー・フィールド値などの物理破損
ソフトウェアの不具合を原因とする論理破損
不適切なコンポーネント・バージョンを原因とする非互換性障害
オープン・ファイル数の制限の超過、チャネル・アクセス障害、ネットワークまたはI/OのエラーなどのI/O障害
データベースのオープンを妨げる不適切な初期化パラメータ値などの構成エラー
診断された障害は、自動診断リポジトリ（ADR）に記録されます。データ・リカバリ・アドバイザは、次の処理に基づいてリカバリ計画を自動的に決定します。
障害がデータベースにより検出されてADRに格納された後にのみ、修復アドバイスを生成して障害を修復します。
効率的なリカバリのために複数の障害を集約します。
実行可能なリカバリ・オプションのみを提供します。
オプションごとのデータ損失を示します。
通常、データ・リカバリ・アドバイザは、自動修復オプションと手動修復オプションの両方を提供します。適切であれば、データ・リカバリ・アドバイザに自動的に修復を実行させ、修復の成功を検証し、関連する修復済障害をクローズできます。
|
関連項目: 『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』のデータ・リカバリ・アドバイザによる障害の診断および修復に関する章 |
ほとんどの環境で、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='*';
ASMを使用している場合、デフォルトでI/Oが非同期に実行されていることに注意してください。
大規模な本番データベースでは、LOG_BUFFER初期化パラメータを8MB以上に設定します。この設定により、データベースでは、フラッシュバック・データベース・ログの書込み用に最大メモリーを割り当てることができます。REDOデータをスタンバイ・データベースに非同期的に転送するようデータベースを構成する場合、ネットワーク送信に関連するプロセスに対応するのに十分な大きさのLOG_BUFFERパラメータを設定する必要があります。
自動共有メモリー管理（ASMM）を使用するとメモリー管理効率が向上します。SGA_TARGETパラメータに0（ゼロ）以外の値を設定すると、共有プール、ラージ・プール、Javaプール、ストリーム・プールおよびバッファ・キャッシュのサイズが、必要に応じて自動的かつ動的に変更されます。詳細は、『Oracle Database管理者ガイド』を参照してください。
Oracleデータベースの管理性を向上するには、次のベスト・プラクティスを使用します。
データ・リカバリ・アドバイザを使用すると、データ障害の自動診断、適切な修復オプションの判別と提供、およびユーザー・リクエストに応じた修復の実行が行われます。ここでは、データ障害とは、ディスク上の永続的データの破損または損失を指します。自動データ修復を行う集中化されたツールを持つデータ・リカバリ・アドバイザを使用すると、Oracleデータベースの管理性と信頼性が向上し、MTTRが減少します。
|
注意: 現在のリリースのデータ・リカバリ・アドバイザでは、単一インスタンス・データベースのみがサポートされています。Oracle RACデータベースおよびOracle Data Guardデータベースはサポートされていません。 |
|
関連項目: 『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』のデータ・リカバリ・アドバイザによる障害の診断および修復に関する章 |
パフォーマンス問題を特定および修正するためには、効果的なデータの収集と分析が不可欠です。Oracleは、データベース・パフォーマンスに関する情報を収集する複数のツールを用意しています。
Oracleデータベースの自動パフォーマンス・チューニング機能は、次のもので構成されます。
AWRを使用する場合、次のベスト・プラクティスを検討してください。
ストレス・テスト中にパフォーマンスのピークを取得する場合や、パフォーマンス問題を診断する場合、AWR自動スナップショットの間隔を10〜20分に設定します。
通常のワークロードの場合、60分間隔で十分です。
サーバー・パラメータ・ファイル（SPFILE）は、データベースのすべてのインスタンスに関連付けられたすべてのデータベース初期化パラメータを保持する単一の集中管理パラメータ・ファイルです。このファイルにより、データベース・パラメータを管理するための簡単で確実な永続的環境が提供されます。ブローカを使用する場合、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値が十分な大きさであることを確認します。
|
関連項目: 『Oracle Database 2日でデータベース管理者』の、UNDOアドバイザを使用した、UNDO表領域の最小サイズの計算に関する項を参照してください。 |
RETENTION GUARANTEEオプションを使用すると、表領域に構成されている領域がトランザクション・スループットの必要量より少ない場合、次の一連のイベントが発生します。
自動拡張可能なファイルがある場合、保存されたUNDOデータを格納できるようそのファイルが自動拡張されます。
ディスクが85%フルになったことが警告アラートにより報告されます。
ディスクが97%フルになったことがクリティカル・アラートにより報告されます。
トランザクションに領域不足エラーが戻されます。
|
関連項目: UNDO_RETENTIONの設定とUNDO表領域のサイズの詳細は、『Oracle Database管理者ガイド』を参照してください。 |
ローカル管理表領域は、ディクショナリ管理表領域よりパフォーマンスに優れており、管理が容易で領域が断片化する心配もありません。ローカル管理表領域では、データファイルのヘッダーに格納されたビットマップを使用します。ディクショナリ管理表領域とは異なり、領域の割当てと割当て解除において集中管理されたリソースに対する競合は発生しません。
|
関連項目: ローカル管理表領域の詳細は、『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データベース・サーバー内の作業に優先順位を設定できます。データベースの可用性には、その機能性とパフォーマンスの両方が含まれます。データベースが使用可能であっても、ユーザーの必要とするパフォーマンス・レベルに到達しなければ、可用性とサービス・レベルの目標は満たされません。アプリケーション・パフォーマンスは、データベースにアクセスする各アプリケーションにリソースがどのように配置されるかによって大きく変化します。データベース・リソース・マネージャの主な目的は、Oracleデータベース・サーバーでリソース管理の設定をより詳細に制御して、オペレーティング・システムの不十分な管理やオペレーティング・システムのリソース・マネージャを原因として発生する問題を回避することです。
|
関連項目: データベース・リソース・マネージャの詳細は、『Oracle Database管理者ガイド』を参照してください。 |
