この章では、パフォーマンスを考慮してデータベースを構成するための、オラクル社の方法論の概要を説明しています。パフォーマンスの修正は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の特定のリリース用に設計されていて、実際にはそれ以降のリリースのOracleをインストールする場合は、このパラメータをアプリケーション設計時のリリースに設定してください。 |
|
データベース・ファイルに格納され、SGAにキャッシュされるOracleデータベース・ブロックのサイズを設定します。値の範囲はオペレーティング・システムにより異なりますが、一般的にトランザクション処理システムの場合は8192で、データベース・ウェアハウス・システムの場合はさらに大きい値となります。 |
|
すべてのSGAコンポーネントのサイズ合計を指定します。 |
|
インスタンスに添付されたすべてのサーバー・プロセスに利用できるターゲット集計PGAメモリーを指定します。PGAメモリー管理の詳細は、「PGAメモリー管理」を参照してください。 |
|
そのインスタンスで起動できるプロセスの最大数を設定します。このパラメータは、他のパラメータ値の多くがこのパラメータから導出されるため、設定する最も重要なプライマリ・パラメータとなります。 |
|
これは、デフォルトでPROCESSESの値から設定されます。ただし、共有サーバーを使用する場合は、導出された値では不十分である可能性があります。 |
|
Oracle Databaseで使用するUNDO領域管理モードを指定します。デフォルト値は |
|
インスタンス起動時に使用されるUNDO表領域を指定します。 |
Oracle Databaseでは、読取り一貫性、リカバリおよび実際のロールバック文で使用するデータを格納するために、UNDO領域を使用します。このデータは1つ以上のUNDO表領域に保存されます。Database Configuration Assistant(DBCA)を使用してデータベースを作成すると、UNDO表領域が自動的に作成されます。UNDO表領域を手動で作成するには、データベースの作成時にCREATE DATABASE
文にUNDO TABLESPACE
句を追加します。
UNDOデータを自動的に管理するため、Oracle Databaseでは、UNDOセグメントを透過的に作成および管理する自動UNDO管理機能を使用します。自動UNDO管理は、UNDO_MANAGEMENT
初期化パラメータで制御します。自動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は自動的に必要に応じてチェックポイントを頻繁に試行しようとします。この場合は、ログ・ファイルが小さすぎることによるチェックポイントの追加発生を防ぐために、ログ・ファイルを十分なサイズに設定する必要があります。最適なサイズは、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表領域に加えて複数の表領域が必要です。これらの追加表領域は次のとおりです。
ほとんどの場合、アプリケーションにはいくつかの表領域が必要です。多数のデータファイルを持つ非常に大きな表領域の場合は、複数のALTER
TABLESPACE
x
ADD
DATAFILE
Y
文をパラレルに実行することもできます。
表領域の作成時、表領域を構成するデータファイルは特殊な空のブロック・イメージで初期化されます。一時ファイルは初期化されません。
この初期化は、すべてのデータファイルが、その全体に書込みを行えるようにするためですが、シリアルに行うと、長い処理になる可能性があります。したがって、複数のCREATE TABLESPACE
文を同時に実行して、表領域の作成処理を高速化します。永続的な表の場合、表領域作成時にローカルまたはグローバルのいずれかのエクステント管理を選択するかで、パフォーマンスに大きな影響を与える可能性があります。読取り操作と比べて、普通または大規模な、挿入、変更または削除操作を行う永続的な表領域の場合は、ローカル・エクステント管理を選択する必要があります。
永続的な表領域では、自動セグメント領域管理を使用することをお薦めします。これらの表領域(ビットマップ表領域と呼ばれる)は、ビットマップ・セグメント領域管理が行われるローカル管理表領域です。
関連項目:
|
一時表領域を正しく構成すると、ディスク・ソートのパフォーマンスの最適化に役立ちます。一時表領域はディクショナリ管理を行うこともローカル管理を行うこともできます。UNIFORM
エクステント・サイズが1MB
の、ローカル管理の一時表領域を使用することをお薦めします。
一時表領域アクティビティを監視して、一時セグメントに割り当てられているエクステントの数をチェックする必要があります。1つのアプリケーションで一時表が広範囲に使用されている場合は、多くのユーザーが一時表を同時に使用している場合と同様に、エクステント・サイズを256KBなどの小さい値に設定できます。これは、使用のたびに少なくとも1つのエクステントが必要になるためです。一時表領域はすべてサイズが均一のローカル管理エクステントで作成されるため、EXTENT MANAGEMENT LOCAL
句は一時表領域ではオプションです。SIZE
のデフォルトは1MB
です。
関連項目:
|
アプリケーションをインストールする際、最初のステップで、必要なすべての表および索引を作成します。表のようなセグメントを作成すると、データのために領域がデータベース内に割り当てられます。後続のデータベース操作によってデータ容量が増大し、割り当てられた領域を上回るようになると、Oracleはそのセグメントを拡張します。
表および索引を作成する際には、次の点に注意してください。
表領域の自動セグメント領域管理の指定
最高のパフォーマンスが得られるよう、Oracleによって自動的にセグメント領域が管理されます。
アプリケーションでは、表または索引の用途によって記憶領域オプションを慎重に設定する必要があります。この設定には、PCTFREE
の値の設定が含まれます。自動セグメント領域管理を使用すると、PCTUSED
を指定する必要がありません。
注意: 空きリストの使用はお薦めしません。自動セグメント領域管理を使用するには、ローカル管理表領域を作成し、セグメント領域管理の句をAUTO に設定します。 |
ヒープ構成表は、どのような種類のアプリケーションにも透過的な圧縮形式で格納できます。表圧縮は、主に読取り専用の環境向けに設計されたものであり、DML操作では処理のオーバーヘッドの原因となる可能性もあります。ただし、多くの読取り操作で、特にシステムがI/Oバウンドである場合は、パフォーマンスが向上します。
データベース・ブロック内の圧縮データは自己完結型です。これは、ブロック内の圧縮されていないデータの再現に必要な情報がすべてそのブロック内にあることを意味します。ブロックは、バッファ・キャッシュ内でも圧縮された状態で保持されます。表圧縮により、ディスク記憶域のみでなく、メモリー使用量、特にバッファ・キャッシュ要件も削減されます。表へのアクセスに必要なI/O操作の量が削減され、バッファ・キャッシュ・ヒットの確立が高まることで、パフォーマンスの向上が実現します。
表圧縮は、個々のブロック内の列値の繰返しを解消することによって機能します。ブロック内のすべての行と列の重複値は、ブロックの先頭にある、そのブロックのシンボル表と呼ばれるものに一度格納されます。こうした値の出現箇所はすべて、シンボル表への簡単な参照で置き換えられます。繰返しの値が多いブロックほど圧縮率が高くなります。
大規模な表を圧縮する前に、予測される圧縮係数を見積る必要があります。圧縮係数は、圧縮されていない形式で情報を格納するために必要なブロック数を、圧縮記憶域に必要なブロック数で除算した値として定義されます。圧縮される表を代表する少数のデータ・ブロックをサンプリングし、圧縮されていない場合と圧縮された場合の各ブロックの平均レコード数を比較することで、圧縮係数を見積ることができます。これまでの経験では、およそ1000のデータ・ブロックを使用することで、きわめて正確な圧縮係数の見積りが可能であることがわかっています。サンプリングのブロック数が多いほど、見積り結果が正確になる点に注意してください。
Oracleでは、多くの場合、特別なチューニングなしで、優れた圧縮係数を達成しています。データベース管理者またはアプリケーション開発者は、実際に圧縮が行われる際にレコードを再構成することによって、圧縮係数のチューニングを試行できます。チューニングを行うと、圧縮係数が若干改善されるケースもあれば大きく改善されるケースもあります。
圧縮係数を高めるには、データベース・ブロック内の値の繰返しの可能性を高くする必要があります。達成できる圧縮係数は、特定の列または列のペアのカーディナリティ(列値の繰返しの可能性を表す)およびこれらの列の行の平均長さによって異なります。Oracleの表圧縮では、単一列の重複値が圧縮されるだけでなく、可能な場合は、複数列値のペアの使用が試行されます。データ配分について熟知していない場合、最適な順序の予測は非常に困難です。
関連項目: 表圧縮およびパーティションの詳細は、『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のアーキテクチャで使用するプロセスの競合を低減する方法について説明します。
次のビューによってディスパッチャのパフォーマンス統計が提供されます。
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管理者ガイド』を参照してください。 |