| Oracle® Databaseパフォーマンス・チューニング・ガイド 11gリリース2 (11.2) B56312-06 |
|
 前 |
 次 |
この章では、パフォーマンスを考慮してデータベースを構成するための、オラクル社の方法論の概要を説明しています。パフォーマンスの修正はOracle Databaseに対して継続的に実行できますが、データベースの初期構成を適切に行うことにより、多大な利益を得ることができます。
この章には次の項があります。
この項では、パフォーマンスに重要な影響を与えるデータベース・インスタンスの初期構成オプションについて説明します。
Database Configuration Assistant(DBCA)を使用してデータベースを作成する場合、提供されるシード・データベースには必要な基本的初期化パラメータが組み込まれており、この章で説明するパフォーマンス推奨事項を満たしています。
|
関連項目:
|
実行中のOracleデータベース・インスタンスは、初期化パラメータ・ファイルで設定される初期化パラメータを使用して構成されます。これらのパラメータは、パフォーマンスへの影響を含め、実行中のインスタンスの動作に影響を与えます。一般的に、関連する設定がほとんどない非常に単純な初期化ファイルでは、ほとんどの状況に対応できます。表4-2に示す少数のパラメータを除き、初期化ファイルはパフォーマンス・チューニングを行う最初の場所ではありません。
表4-1に、最小初期化ファイルで必要なパラメータを示します。これらのパラメータは必須ですが、パフォーマンスに影響を与えません。
表4-1 パフォーマンスに影響を与えない必要な初期化パラメータ
| パラメータ | 説明 |
|---|---|
|
データベースの名前。これは、環境変数 |
|
|
インターネット・ドット表記法による、データベースの場所。 |
|
|
1セッション当たりのカーソル(アクティブなSQL文)の最大数に対する制限。設定はアプリケーションにより異なり、推奨値は500です。 |
|
|
異なるディスク・ドライブ上に少なくとも2つのファイルを含めるように設定して、制御ファイルの消失による障害を防ぎます。 |
|
|
|
データベースに割り当てることのできるファイルの最大数に設定します。 |
|
関連項目: これらの初期化パラメータの詳細は、『Oracle Database管理者ガイド』を参照してください。 |
表4-2に、パフォーマンスの考慮事項として設定する、最も重要なパラメータを示します。
表4-2 パフォーマンスに影響を与える重要な初期化パラメータ
| パラメータ | 説明 |
|---|---|
|
互換性を維持しておくOracleデータベースのリリースを指定します。このパラメータを使用すると、新しい機能を自分の環境でテストせずに、ただちに本番システムで新しいリリースで改善された機能を利用できるようになります。アプリケーションがOracle Databaseの特定のリリース用に設計されていて、実際にはそれより後のリリースをインストールする場合は、このパラメータをアプリケーション設計時のリリースに設定してください。 |
|
|
データベース・ファイルに格納され、SGAにキャッシュされるOracleデータベース・ブロックのサイズを設定します。値の範囲はオペレーティング・システムにより異なりますが、一般的にトランザクション処理システムの場合は8192で、データベース・ウェアハウス・システムの場合はさらに大きい値となります。 |
|
|
すべてのSGAコンポーネントのサイズ合計を指定します。 |
|
|
インスタンスに添付されたすべてのサーバー・プロセスに利用できるターゲット集計PGAメモリーを指定します。「PGAメモリー管理」を参照してください。 |
|
|
そのインスタンスで起動できるプロセスの最大数を設定します。このパラメータは、他のパラメータ値の多くがこのパラメータから導出されるため、設定する最も重要なプライマリ・パラメータとなります。 |
|
|
これは、デフォルトでPROCESSESの値から設定されます。ただし、共有サーバーを使用する場合は、導出された値では不十分である可能性があります。 |
|
|
データベースで使用するUNDO領域管理モードを指定します。デフォルトは |
|
|
インスタンス起動時に使用されるUNDO表領域を指定します。 |
データベースは、読取り一貫性、リカバリおよびロールバック文で使用するデータを格納するために、UNDO領域を使用します。このデータは1つ以上のUNDO表領域に格納されます。Database Configuration Assistant(DBCA)を使用してデータベースを作成すると、UNDO表領域が自動的に作成されます。UNDO表領域を手動で作成するには、CREATE DATABASE文にUNDO TABLESPACE句を追加します。
UNDOデータを自動的に管理するため、Oracle Databaseでは、UNDOセグメントを透過的に作成および管理する自動UNDO管理を使用します。自動UNDO管理を有効にするには、UNDO_MANAGEMENT初期化パラメータをAUTO(デフォルト設定)に設定します。指定しない場合、UNDO_MANAGEMENT初期化パラメータでは、AUTO設定が使用されます。自動UNDO管理の使用をお薦めするのは、データベース管理が大幅に簡素化され、UNDO(ロールバック)セグメントを手動でチューニングする必要がないためです。ロールバック・セグメントを使用する手動UNDO管理は、下位互換性のためにサポートされています。
V$UNDOSTATビューには、UNDO領域を監視およびチューニングするための統計が含まれています。このビューを使用して、現行のワークロードに必要なUNDO領域の大きさをより的確に見積ることができます。この情報を使用して、UNDO使用量を簡単にチューニングすることもできます。V$ROLLSTATビューには、UNDO表領域内のUNDOセグメントの動作に関する情報が含まれています。
|
関連項目:
|
REDOログ・ファイルのサイズはパフォーマンスに影響を与えます。これは、データベースのライター・プロセスおよびアーカイバ・プロセスの動作がREDOログのサイズによって変わるためです。一般に、REDOログ・ファイルが大きければ、パフォーマンスは向上します。ログ・ファイルのサイズが小さいと、チェックポイント・アクティビティが増加し、パフォーマンスが低下します。
REDOログ・ファイルのサイズはLGWRのパフォーマンスに影響を与えませんが、DBWRおよびチェックポイントの動作に影響を与える可能性があります。チェックポイントの頻度には、ログ・ファイルのサイズやFAST_START_MTTR_TARGET初期化パラメータの設定など、複数の要因が影響します。インスタンスのリカバリ時間を制限するためにFAST_START_MTTR_TARGETパラメータが設定されている場合、Oracle Databaseは自動的にチェックポイントを必要に応じて頻繁に試みます。この場合は、ログ・ファイルが小さすぎることによるチェックポイントの追加発生を防ぐために、ログ・ファイルを十分なサイズに設定する必要があります。最適なサイズは、V$INSTANCE_RECOVERYビューからOPTIMAL_LOGFILE_SIZE列を問い合せることで取得できます。また、Oracle Enterprise Managerの「REDOログ・グループ」ページからも、サイズ設定のアドバイスを取得できます。
REDOログ・ファイルに特定のサイズを推奨できない場合もありますが、100MBから数GBの範囲内にあるREDOログ・ファイルが妥当であると考えられます。システムが生成するREDOの量に従って、オンラインREDOログ・ファイルをサイズ設定します。およその目安として、多くても20分ごとに1回ログ・ファイルを切り替えます。
|
関連項目: REDOログの管理の詳細は、『Oracle Database管理者ガイド』を参照してください。 |
Database Configuration Assistant(DBCA)を使用してデータベースを作成する場合、シード・データベースには必要な表領域すべてが自動的に組み込まれます。DBCAを使用しないように選択した場合は、データベースの作成後に追加表領域を作成する必要があります。
すべてのデータベースには、SYSTEMおよびSYSAUX表領域に加えて複数の表領域が必要です。これらの追加表領域は次のとおりです。
読取り一貫性、リカバリおよびUNDO文に関する情報を格納するためのUNDO表領域
アプリケーションで使用する少なくとも1つの表領域(ほとんどの場合、アプリケーションには複数の表領域が必要です)
多数のデータファイルを含む非常に大きな表領域では、複数のALTER TABLESPACE . . .ADD DATAFILE文をパラレルで実行できます。表領域の作成時、表領域を構成するデータファイルは特殊な空のブロック・イメージで初期化されます。一時ファイルは初期化されません。
Oracle Databaseでは、この初期化により、すべてのデータファイル全体に書込みが行えるようになりますが、この処理をシリアルに実行すると時間がかかります。したがって、複数のCREATE TABLESPACE文を同時に実行して、表領域の作成を高速化します。永続的な表の場合、表領域作成時にローカルまたはグローバルのいずれかのエクステント管理を選択するかで、パフォーマンスに大きな影響を与える可能性があります。読取り操作と比べて、普通または大規模な、挿入、変更または削除操作を行う永続的な表領域の場合は、ローカル・エクステント管理を選択します。
永続的な表領域では、自動セグメント領域管理を使用することをお薦めします。これらの表領域(ビットマップ表領域と呼ばれる)は、ビットマップ・セグメント領域管理が行われるローカル管理表領域です。
|
関連項目:
|
一時表領域を正しく構成すると、ディスク・ソートのパフォーマンスの最適化に役立ちます。一時表領域はディクショナリ管理を行うこともローカル管理を行うこともできます。UNIFORMエクステント・サイズが1MBの、ローカル管理の一時表領域を使用することをお薦めします。
一時表領域アクティビティを監視して、一時セグメントに割り当てるエクステントの数をチェックする必要があります。たとえば、多数のユーザーが一時表を同時に使用しているような状況で、アプリケーションで一時表が頻繁に使用される場合は、1回の使用につき1つ以上のエクステントが必要になるため、エクステント・サイズを256KBなどの小さい値に設定できます。一時表領域はすべて均一サイズのローカル管理エクステントで作成されるため、EXTENT MANAGEMENT LOCAL句は一時表領域ではオプションです。SIZEのデフォルトは1MBです。
|
関連項目:
|
アプリケーションをインストールする際、最初のステップで、必要なすべての表および索引を作成します。表のようなセグメントを作成すると、データ用の領域がデータベースで割り当てられます。後続のデータベース操作によってデータ容量が増大し、割り当てられた領域を上回るようになると、Oracle Databaseはそのセグメントを拡張します。
表および索引を作成する際には、次の点に注意してください。
表領域の自動セグメント領域管理の指定
この方法では、最高のパフォーマンスが得られるよう、Oracle Databaseで自動的にセグメント領域が管理されます。
アプリケーションでは、表または索引の用途によって記憶領域オプションを慎重に設定する必要があります。この設定には、PCTFREEの値の設定が含まれます。自動セグメント領域管理を使用すると、PCTUSEDを指定する必要がありません。
|
注意: 空きリストの使用はお薦めしません。自動セグメント領域管理を使用するには、ローカル管理表領域を作成し、セグメント領域管理の句をAUTOに設定します。 |
ヒープ構成表は、どのような種類のアプリケーションにも透過的な圧縮形式で格納できます。データベース・ブロック内の圧縮データは自己完結型です。つまり、ブロック内の未圧縮データの再作成に必要なすべての情報がそのブロック内にあります。バッファ・キャッシュでも、ブロックは圧縮されています。表圧縮により、ディスク記憶域のみでなく、メモリー使用量、特にバッファ・キャッシュ要件も削減されます。表へのアクセスに必要なI/O操作の量が削減され、バッファ・キャッシュ・ヒットの確率が高まることで、パフォーマンスの向上が実現します。
Oracle Databaseの拡張圧縮オプションを使用すると、データ・ウェアハウスおよびOLTPアプリケーションを含め、どのタイプのアプリケーションもワークロードのパフォーマンスが向上し、データベースに必要なディスク領域を削減します。拡張圧縮機能は、構造化データ、非構造化データ、バックアップ・データおよびネットワーク・データを含め、すべてのタイプのデータに使用できます。
表圧縮は、個々のブロック内の列値の繰返しを解消することによって機能します。ブロック内のすべての行と列の重複値は、ブロックの先頭にある、そのブロックのシンボル表と呼ばれるものに一度格納されます。こうした値の出現箇所はすべて、シンボル表への簡単な参照で置き換えられます。繰返しの値が多いブロックほど圧縮率が高くなります。
大規模な表を圧縮する前に、予測される圧縮係数を見積る必要があります。圧縮係数は、圧縮されていない形式で情報を格納するために必要なブロック数を、圧縮記憶域に必要なブロック数で除算した値として定義されます。圧縮される表を代表する少数のデータ・ブロックをサンプリングし、圧縮されていない場合と圧縮された場合の各ブロックの平均レコード数を比較することで、圧縮係数を見積ることができます。これまでの経験では、およそ1000のデータ・ブロックを使用することで、きわめて正確な圧縮係数の見積りが可能であることがわかっています。サンプリングのブロック数が多いほど、見積り結果が正確になる点に注意してください。
Oracle Databaseでは、多くの場合、特別なチューニングなしで、優れた圧縮係数を達成しています。DBAまたはアプリケーション開発者は、圧縮が行われる際にレコードを再構成することによって、圧縮係数のチューニングを試行できます。チューニングを行うと、圧縮係数が若干改善されるケースもあれば大きく改善されるケースもあります。
圧縮係数を高めるには、データ・ブロック内の値の繰返しの可能性を高くする必要があります。達成できる圧縮係数は、特定の列または列のペアのカーディナリティ(列値の繰返しの可能性を表す)およびこれらの列の行の平均長さによって異なります。表圧縮では、単一列の重複値が圧縮されるだけでなく、可能な場合は、複数列値のペアの使用が試行されます。データ配分について熟知していない場合、最適な順序の予測は非常に困難です。
|
関連項目: 表圧縮およびパーティションの詳細は、『Oracle Databaseデータ・ウェアハウス・ガイド』を参照してください。 |
一般に、時間経過とともにセグメント領域が断片化されたり、更新および削除操作の結果としてセグメントに多数の空き領域が生じます。このようにして粗密に移入されたオブジェクトは、問合せおよびDML操作中にパフォーマンスを低下させる可能性があります。
Oracle Databaseにはセグメント・アドバイザが用意されており、オブジェクト内の領域の断片化レベルに基づいて、オブジェクトに解放可能な領域があるかどうかのアドバイスを提供します。
|
関連項目: セグメント・アドバイザの詳細は、『Oracle Database管理者ガイド』および『Oracle Database 2日でデータベース管理者』を参照してください。 |
オブジェクトに解放可能な領域がある場合は、セグメントを圧縮して縮小するか、またはセグメントの終わりにある未使用領域を割当て解除できます。
|
関連項目:
|
最も効率的に索引を作成するタイミングは、データのロード後です。この方法では、領域管理が簡単になり、行が挿入されるたびに索引がメンテナンスされることもありません。この技術は、SQL*Loaderにより自動的に使用されますが、他の方法で初期データをロードする場合は、手動で索引を作成する必要があります。また、CREATE INDEX文のPARALLEL句を使用して、索引作成をパラレルで実行することもできます。ただし、SQL*Loaderでは索引作成をパラレル化できないため、データのロード後に索引を手動でパラレルに作成する必要があります。
|
関連項目: SQL*Loaderの詳細は、『Oracle Databaseユーティリティ』を参照してください。 |
データを含む表での索引の作成中に、データをソートする必要があります。このソートは、すべての使用可能なメモリーをソートに使用する場合に最も高速に行われます。PGA_AGGREGATE_TARGET初期化パラメータを設定して、SQL作業領域の自動サイズ指定を使用可能にすることをお薦めします。
|
関連項目:
|
共有サーバーを使用すると、プロセス数と、データベース・ホストでのメモリー使用量が削減されます。共有サーバーは、多数のOLTPユーザーが断続的なトランザクションを実行するデータベースに有効です。
また、データベースへの単位時間当たりの接続数が高いシステムでは、一般的に専用サーバーよりも共有サーバーを使用する方が適しています。共有サーバーでは、接続リクエストを受信する際に、ディスパッチャを使用して同時接続リクエストを処理できます。しかし、専用サーバーの場合は、接続固有の専用サーバーが、接続リクエストごとに順次初期化されます。
共有サーバー・アーキテクチャを使用すると、特定のデータベース機能のパフォーマンスが向上しますが、パフォーマンスがいくらか低下する機能もあります。たとえば、パラレル実行がアクティブな場合、セッションが別の共有サーバーに移行できないことがあります。
クライアントからのリクエストが処理された後でもセッションを移行できない場合があります。これは、すべてのユーザー情報がUGAに格納されているとは限らないためです。サーバーがクライアントからのリクエストを処理するとしても、UGAに格納されていなかったユーザー状態にはアクセスできません。この状況を回避するために、個々の共有サーバーは、しばしばユーザー・セッションにバインドされた状態のままである必要があります。
|
関連項目:
|
ある種の機能を使用する場合、あるサーバーがセッションに長期間バインドされる可能性があるため、追加の共有サーバーを構成する必要が生じる場合があります。
この項では、Oracle Databaseのアーキテクチャで使用するプロセスの競合を低減する方法について説明します。
次のビューによってディスパッチャのパフォーマンス統計が提供されます。
V$DISPATCHER: ディスパッチャ・プロセスの一般的な情報
V$DISPATCHER_RATE: ディスパッチャ・プロセスの統計情報
V$DISPATCHER_RATEビューには、いくつかのカテゴリについてディスパッチャ統計の現在、平均および最大の値が含まれています。接頭辞CUR_が付いている統計は、現在のサンプルの統計です。接頭辞AVG_が付いている統計は、収集期間の開始後の統計の平均値です。接頭辞MAX_が付いている統計は、統計収集の開始後のこれらのカテゴリでの最大値です。
ディスパッチャのパフォーマンスを調べるには、V$DISPATCHER_RATEビューを問い合せて、最大値と現在の値を比較します。現在のシステム・スループットが適切なレスポンス時間を提供し、このビューの現在の値が平均値に近くかつ最大値を下回る場合、共有サーバー環境は最適にチューニングされていると考えられます。
現在の値と平均値が最大値を大きく下回る場合は、ディスパッチャ数の削減を検討してください。反対に、現在の値と平均値が最大値に近い場合は、ディスパッチャを追加する場合があります。システム使用率が低い期間と高い期間の両方でV$DISPATCHER_RATE統計を調べてみることを一般規則としてお薦めします。共有サーバーの負荷パターンを識別した後で、それに従ってパラメータを調整します。
必要に応じて、システムのストレス・テストを実行し、定期的にV$DISPATCHER_RATE統計をポーリングすることによってワークロードをシミュレートすることもできます。これらの統計の正しい解釈方法は、プラットフォームごとに異なります。アプリケーションの種類が変わると、V$DISPATCHER_RATEに記録される統計値も大幅に異なる可能性があります。
|
関連項目:
|
ディスパッチャ・プロセスの追加
ディスパッチャ・プロセスの総数は、MAX_DISPATCHERS初期化パラメータの値で制限されます。ディスパッチャ・プロセスを追加する前に、この値を増やす必要がある場合があります。
接続プーリングの使用可能化
システム負荷が増加し、ディスパッチャ・スループットが最大限になった場合は、すぐにディスパッチャを追加することが必ずしも適切とはかぎりません。そのかわりに、接続プーリングによってより多くのユーザーをサポートできるようにディスパッチャを構成することを検討してください。
セッション多重化の有効化
多重化は、Connection Managerプロセスで、複数ユーザーから個別のディスパッチャへのネットワーク・セッションを確立およびメンテナンスする場合に使用されます。たとえば、いくつかのユーザー・プロセスがConnection Managerプロセスからの1つの接続を経由して1つのディスパッチャに接続できます。ディスパッチャ・プロセスが最大限に使用されるため、セッションの多重化は有効です。多重化は、ディスパッチャ間のデータベース・リンク・セッションを多重化する場合にも役立ちます。
|
関連項目:
|
リクエスト・キューにおいて待機時間が一貫して増加する場合、それは共有サーバーの競合を示します。待機時間のデータを調べるには、動的パフォーマンス・ビューV$QUEUEを使用します。このビューには、共有サーバーのリクエスト・キューのアクティビティを示す統計が含まれます。デフォルトでは、SYSユーザーと、SELECT ANY TABLEシステム権限を持っている他のユーザー(SYSTEMなど)のみがこのビューを使用できます。表4-3は、リクエストの待機時間とキュー内のリクエスト数を示す列のリストです。
表4-3 V$QUEUE内の待機時間およびリクエストの列
| 列 | 説明 |
|---|---|
|
|
キューに存在していた全リクエストについての待機時間の合計(100分の1秒単位) |
|
|
キューに存在していたリクエストの総数 |
アプリケーションの実行時に次のSQL文を発行して、この統計を数回監視してください。
SELECT DECODE(TOTALQ, 0, 'No Requests', WAIT/TOTALQ || ' HUNDREDTHS OF SECONDS') "AVERAGE WAIT TIME PER REQUESTS" FROM V$QUEUE WHERE TYPE = 'COMMON';
この問合せは、次のような計算結果を戻します。
AVERAGE WAIT TIME PER REQUEST ----------------------------- .090909 HUNDREDTHS OF SECONDS
この結果から、リクエストは処理される前にキューにおいて平均0.09待機したことがわかります(単位は100分の1秒)。
また、次の問合せを発行することによって、現在実行中の共有サーバーの数が判断できます。
SELECT COUNT(*) "Shared Server Processes" FROM V$SHARED_SERVER WHERE STATUS != 'QUIT';
この問合せの結果を次に示します。
Shared Server Processes ----------------------- 10
共有サーバーでのリソース競合を検出した場合は、まず、共有プールとラージ・プールを調査し、これがメモリー競合でないことを確認します。パフォーマンスが改善されない場合は、共有サーバー・プロセス競合を低減するためにさらにリソースを作成してください。その場合は、オプションのサーバー・プロセス初期化パラメータを変更します。
MAX_DISPATCHERS
MAX_SHARED_SERVERS
DISPATCHERS
SHARED_SERVERS
|
関連項目: 共有サーバー・プロセスの初期化パラメータの設定の詳細は、『Oracle Database管理者ガイド』を参照してください。 |
