|
|
Oracle データベースの初期化パラメータは、以下の目的で使用されます。
これらのパラメータの中には、WLI アプリケーションのパフォーマンスに大きな影響を与えるものがあります。この節では、重要なパラメータのいくつかをチューニングして、WLI のパフォーマンスを向上させる方法について説明します。
compatible 初期化パラメータは、以前のリリースの Oracle インスタンスの互換性を設定するために使用します。このチューニング ガイドでは、互換性を 9.2.0 に設定することを推奨しています。
このパラメータでは、複数のブロック サイズのテーブルスペースに格納されるデータのキャッシュ サイズを設定します。複数のブロック サイズのテーブルスペースを使用すると、インデックス セグメントや LOB (Large Object) などの大きなデータ オブジェクトの I/O を減らすことができます。nK の n の値は 4、8、16、または 32 であり、DB_BLOCK_SIZE で設定されるデフォルトのブロック サイズの倍数でなければなりません。このパラメータは、複数のブロック サイズのテーブルスペースを使用する場合のみ設定してください。このパラメータの設定方法の詳細については、「複数のブロック サイズのバッファ キャッシュ」または「WLI スキーマのチューニング」にある「JPD の BLOB データのキャッシュ」を参照してください。
このパラメータは非推奨です。代わりに、DB_BLOCK_SIZE パラメータを使用してください。このパラメータを使用すると、複数のブロック サイズのテーブルスペースの使用が無効になります。
このパラメータでは、データベースのデフォルトのブロック サイズを設定します。Oracle データベースの作成時にのみ設定できます。WLI データベースの場合、このパラメータの設定値は、WLI を使用して作成したアプリケーションの特性に基づいて決めてください。
| 注意 : | デフォルトの小さなブロック サイズでは、大きなキー長のインデックスの場合に ORA-01450 エラーが発生することがあります。大きなキー長のインデックスを使用する他のアプリケーションとの間でデータベースを共有している場合、その大きなキー長に対応できる大きさのブロック サイズを持つ、複数のブロック サイズのテーブルスペースにインデックスを移動する必要があります。 |
このパラメータでは、Oracle データベースのデフォルトのバッファ プールのサイズを設定します。デフォルトのバッファ プールは、使用率の高いデータをメモリにキャッシュして、すばやくアクセスできるようにするために使用されます。この領域は、データベースのからの情報の取得要求全体の約 90% を収容できるように設定します。この数字は、Statspack のバッファ ヒット率の割合で測定されます。Statspack の使用方法の詳細については、「Oracle Statspack」を参照してください。
このパラメータでは、テーブル全体のスキャンなどの順次読み込みで I/O サブシステムから Oracle によって要求されるブロック数を設定します。WLI. で使用する場合、この値は 16 に設定します。16 より大きい値を設定すると、Oracle オプティマイザによって、インデックス ルックアップの代わりに完全スキャンが選択される可能性が高くなります。
このパラメータでは、KEEP バッファ プールのサイズを設定します。KEEP バッファ プールは、デフォルトのブロック サイズのデータ オブジェクトで使用される代替バッファ プールです。このバッファ プールは、より動的なデータによってデフォルトのバッファ プールから排除される可能性のあるルックアップ テーブルなどのキャッシュされたデータ オブジェクトを、デフォルトのバッファ プールから分離するために使用します。このパラメータは、KEEP プールを使用する場合のみ設定します。WLI での代替バッファ ブールの使用方法の詳細については、「WLI スキーマのチューニング」の「JPD の BLOB データのキャッシュ」を参照してください。
このパラメータでは、RECYCLE バッファ プールのサイズを設定します。RECYCLE バッファ プールは、デフォルトのブロック サイズのデータ オブジェクトで使用される代替バッファ プールです。このバッファ プールは、デフォルトのバッファ プールでは古くなる可能性のある高度に動的なデータなどのキャッシュされたデータ オブジェクトを、デフォルトのバッファ プールから分離するために使用します。このパラメータは、RECYCLE プールを使用する場合のみ設定します。WLI でのこのバッファ プールの使用方法については、「WLI スキーマのチューニング」の「JPD の BLOB データのキャッシュ」を参照してください。
このパラメータでは、データベースのすべての同時トランザクションで発生する同時 DML 処理の最大数を設定します。WLI のように高容量のトランザクション データベース システムでは、デフォルト値 (トランザクション数の 4 倍) では十分でない可能性があります。より大きな固定値に設定できます。値 0 に設定すると、この制限を解除できますが、その場合、DROP TABLE ステートメント、CREATE INDEX ステートメント、および明示的な LOCK ステートメントは使用できなくなります。
ほとんどの WLI 実装では、このパラメータのデフォルト値が適しています。エンキュー待機が多数発生するシステムでは、エンキュー待機をチューニングするための各種手段を実施しても状況が改善されなかった場合、この値を変更してください。デフォルト値を変更する前に、DBA に相談してください。
このパラメータは Oracle9i では非推奨です。使用しないでください。このパラメータを設定すると、Oracle9i でインスタンス回復時間を制限する方法として Oracle で推奨されている FAST_START_MTTR_TARGET の使用がオーバーライドされます。
このパラメータでは、データベース インスタンスがクラッシュした場合の平均回復時間 (MTTR) の上限を設定します。この機能は有効そうに見えますが、これを使用すると、使用済みバッファが絶え間なくディスクにフラッシュされ、I/O の競合が増加するため、一部のシステムではパフォーマンスが悪化します。I/O が原因でパフォーマンス上の問題がある一部の WLI データベースでは、FAST_START_MTTR_TARGET の値を小さくすることで、パフォーマンスが大幅に向上する場合があります。
ハッシュ結合を無効にすると、WLI のパフォーマンスが多少改善されます。同じデータベース インスタンスを実行している他のアプリケーションで必要とされない場合、このパラメータは FALSE に設定してください。
このパラメータでは、オンライン REDO ログにエントリをバッファリングするために Oracle で使用するメモリの量を設定します。トランザクション数の多い WLI アプリケーションでは、このパラメータの値をデフォルト値の 512 KB より大きくしてください。高容量の WLI アプリケーションでは、値を 1 ～ 2 MB に設定すると、良好なパフォーマンスが得られます。
このパラメータを設定すると、FAST_START_MTTR_TARGET (インスタンス回復時間の上限を設定するための Oracle 推奨の方法) の正常な処理が干渉されます。このパラメータを 0 (ゼロ) に設定して、チェックポイント間隔が FAST_START_MTTR_TARGET によって制御されるようにしてください。
このパラメータを設定すると、FAST_START_MTTR_TARGET (インスタンス回復時間の上限を設定するための Oracle 推奨の方法) の正常な処理が干渉されます。このパラメータを 0 (ゼロ) に設定して、チェックポイント間隔が FAST_START_MTTR_TARGET によって制御されるようにしてください。
Oracle オプティマイザによって、データへの最も効率的なアクセス パスが生成されます。オプティマイザの動作モードは、CHOOSE、RULE、FIRST_ROWS、および ALL_ROWS があります。オプティマイザが CHOOSE モードで実行され、すべてのデータベース オブジェクトでデータベースの統計が収集されていると、WLI のパフォーマンスが大幅に改善されます。データベースの統計の収集方法については、「データベースの統計」を参照してください。
このパラメータでは、Oracle のプログラム グローバル領域 (PGA) のターゲット メモリ サイズを設定します。WORK_AREA_SIZE_POLICY を AUTO に設定してこのパラメータと共に使用すると、メモリを大量に消費する SQL 操作 (sort、group by など) のパフォーマンスが大幅に改善されます。
このメモリ領域を Oracle で自動的に管理するようにするには、BITMAP_MERGE_AREA_SIZE、CREATE_BITMAP_AREA_SIZE、HASH_AREA_SIZE、および SORT_AREA_SIZE の各パラメータの設定を解除します。
WLI では、このパラメータの一般的な値は 32 MB と 64 MB です。このパラメータの値は、Oracle Statspack レポートの「PGA Memory Advisory」セクションを確認することにより、微調整できます。Oracle Statspack の実行方法と使用方法については、「Oracle Statspack」を参照してください。
このパラメータでは、Oracle でのオペレーティング システム ユーザ プロセスの最大数を設定します。WLI データベース アプリケーションの場合、最小値の 600 に設定してください。
このパラメータでは、Oracle で共有カーソル、ストアド プロシージャ、および制御構造のキャッシング専用に使用されるメモリの量を設定します。WLI では、このパラメータの一般的な設定値は 32 MB です。このパラメータをチューニングしてパフォーマンスを最適化するには、Oracle Statspack レポートの「Shared Pool Advisory」セクションを参照してください。Oracle Statspack の詳細については、「Oracle Statspack」を参照してください。
このパラメータでは、UNDO 情報を UNDO テーブルスペースに保持する時間を秒単位で設定します。負荷の高い WLI データベースに多数の UNDO 情報を保持すると、I/O サブシステムに余分な負荷がかかる可能性があります。WLI では、UNDO の保持は使用されません。この機能を使用している他のアプリケーションとデータベースを共有している場合を除き、このパラメータは無効にしてください (0 に設定)。
このパラメータのデフォルトの設定は AUTO です。Oracle では、このパラメータをデフォルトのままにして、SQL 作業領域のメモリ管理を自動的に行うことを推奨しています。
Oracle データベースでは、オプティマイザを使用して、データを取り出すための最も効率的なアクセス計画を作成します。オプティマイザが最適な計画を選択するうえで、基になるデータについて Oracle が所有している情報 (統計) の量と、データにアクセスするシステムのパフォーマンスが影響します。オプティマイザが効率的なデータ アクセス計画を作成できるように、データベース、スキーマ、システムの各レベルで統計を収集する必要があります。
この節では、データベースに関して収集されるさまざまな統計について説明します。
データベース レベルで収集される統計では、データベース全体 (SYSTEM スキーマおよび SYS スキーマを含む) のデータ構造とデータについての情報が取り込まれます。データベース レベルの統計の収集は、データベースの作成後と、データベースの有効期間全体にわたって定期的に行います。
SYSDBA システム特権を持つユーザは、次のスクリプトを使用して、データベース レベルの統計を収集できます。
-- データベース レベルの統計を収集
begin
dbms_stats.gather_database_stats
(
estimate_percent => dbms_stats.auto_sample_size,
block_sample => FALSE,
method_opt => 'FOR ALL INDEXED COLUMNS SIZE AUTO',
degree => NULL,
granularity => 'ALL',
cascade => TRUE,
stattab => NULL,
statid => NULL,
options => 'GATHER',
statown => NULL,
gather_sys => TRUE,
no_invalidate => FALSE,
gather_temp => FALSE
);
end;
/
スキーマ レベルで収集される統計では、ターゲット スキーマ内のオブジェクトに関する統計のみが収集されます。WLI スキーマの統計は、頻繁に収集してください。低容量システムの場合は少なくとも週 1 回、高容量システムの場合は少なくとも 1 日 1 回収集することをお勧めします。WLI スキーマの収集を頻繁に行う必要があるのは、一部の WLI データ構造の性質が極めて動的であるためです。
WLI スキーマ オーナ、またはこの特権を持つユーザは、次のスクリプトを使用して、スキーマ レベルの統計を収集できます。
-- スキーマ レベルの統計を収集
begin
dbms_stats.gather_schema_stats
(
ownname => 'WLI_SCHEMA',
estimate_percent => dbms_stats.auto_sample_size,
block_sample => FALSE,
method_opt => 'FOR ALL INDEXED COLUMNS SIZE AUTO',
degree => NULL,
granularity => 'ALL',
cascade => TRUE,
stattab => NULL,
statid => NULL,
options => 'GATHER',
statown => NULL,
no_invalidate => FALSE,
gather_temp => FALSE
);
end;
/
システム レベルで収集される統計では、データベースのホスト OS およびそのサブシステムのパフォーマンス特性に関する情報が収集されます。具体的には、I/O パフォーマンス、CPU パフォーマンス、およびシステム使用率に関する統計が収集されます。これらの統計は、WLI の使用時、データベースに標準的な負荷がかかっているときに収集します。
SYSDBA システム特権を持つユーザは、次のスクリプトを使用して、システム レベルの統計を収集できます。
begin
dbms_stats.gather_system_stats
(
gathering_mode => 'INTERVAL',
interval => 60, -- 分単位の時間
stattab => NULL,
statid => NULL,
statown => NULL
);
end;
/
一般に、Oracle データベースのアクセスが最も遅くなるのは、永続データにアクセスするとき (つまりディスク I/O) です。ディスク I/O のパフォーマンスと同時実行性を向上させるために、Oracle では、アクセス特性の異なる I/O を別々のディスクに分離するか、高帯域幅の I/O を持つ高パフォーマンス ストレージ サブシステムを使用することを推奨しています。この節では、これらの推奨事項を取り上げます。
Oracle では、I/O をデータの種類に応じて次の 7 種類の I/O チャネルに分離することを推奨しています。
この推奨事項に従うには、Oracle を実行するために少なくとも 7 台のディスクが必要になります。冗長性を追加する場合は、この倍の数のディスクが必要になります。この推奨事項は、必ずしも実用的ではありません。小規模なデータベース システムの場合、ディスクの数は一般的には 4 台未満です。多くのデータベース システムでは、このように 7 つの個別の I/O チャネルを必要とすることはありません。
データベース システムで実行しているアプリケーションに特有のアクセス パターンを特定することにより、より効果的に I/O を分離することができます。WLI アプリケーションのアクセス パターンはオンライン トランザクション処理 (OLTP) システムと似ており、大部分のデータ要求はサイズが小さく、メモリ内データ バッファによって応答されます。これらのデータ バッファは、最初の要求時にメモリにロードされ、より使用頻度の高い他のデータによって書き換えられるまでメモリ内に保持されます。この動作では、アプリケーション データまたはアプリケーション インデックスの読み取り I/O の負荷が低くなります。
ただし、WLI では、データ書き込みの回数と種類が多いという点で I/O サブシステムに負荷がかかります。この場合、REDO ログ (アーカイブ ログ モードで実行している場合はアーカイブ ログ)、LOB データ、UNDO データ、アプリケーション データ、およびアプリケーション インデックスのための書き込みが行われます。
WLI の場合、次の種類のデータは、可能であれば、物理的に分離されたディスクまたは論理装置 (LUN) に格納することをお勧めします。以下では、分離の重要性が高い順に示しています。ディスク数の少ないシステムでは、リストで先に出現する種類のデータを先に分離してください。
Oracle データベースのパフォーマンスを向上できる各種の高パフォーマンス ストレージ システムがあります。このようなシステムでは、大規模なストライピング アレイ (RAID 0)、冗長性のあるアレイ (RAID 1)、ファイバ チャネル、およびストレージ システム内の拡張ロード バランシング アルゴリズムを利用して、高帯域幅の I/O を実現します。このマニュアルでは、これらのストレージ サブシステムの推奨事項については説明しません。ただし、高パフォーマンス ストレージ サブシステムと共に Oracle データベースを使用した場合、WLI アプリケーションでパフォーマンスが向上することが観測されています。I/O パフォーマンスは、Oracle Statspack レポートの「File I/O Stats」セクションで評価できます。Oracle Statspack の使用方法の詳細については、「Oracle Statspack」を参照してください。
多くのデータベース テーブルには、シーケンスに基づく主キーまたはユニーク キーがあります。これらのキーでは、インデックス付き値を順番に格納するという性質を持つ B-Tree インデックスを使用してインデックスが作成されます。このような順次ストレージの動作から、この種のインデックスは、「単調」または「適正成長」インデックスと呼ばれています。この種のインデックスは、インデックスのリーフ ブロックに値を挿入する際にシリアライゼーションが行われるため、高容量のトランザクション システムでは、パフォーマンス上のボトルネックになることがあります。
このシリアライゼーションを回避するために、逆キー インデックスを使用できます。逆キー インデックスでは、インデックス付き値が逆ビット順で格納されます。このため、標準の B ツリー インデックスでは値 (234、235、236) が順番に連続して格納されるのに対し、逆キー インデックスでは順番が入れ替わった、隣接しない値 (236、234、235) が格納されます (表 2-3 を参照)。より大きな値セットでは、この反転によってインデックスのリーフ ノード ブロック全体にわたってインデックス付き値が分散されるため、順次挿入時のシリアライゼーションが不要になります。
| 注意 : | 逆キー インデックスを使用する場合は、注意が必要です。REVERSE を指定してインデックスが構築されると、そのインデックスはインデックス範囲スキャンには使用できなくなります。つまり、Oracle では、次の SQL ステートメントのように、テーブル スキャンを使用して値範囲を定義する述部に応える必要があります。 |
| 注意 : | WHERE salary > 100,000 |
| 注意 : | AND salary < 200,000 |
| 注意 : | / |
| 注意 : | 逆キー インデックスを作成するには、インデックスを作成または再構築する際に REVERSE キーワードを使用する必要があります。 |
| 注意 : | 次のコード サンプルでは、インデックスの作成方法と再構築方法を示しています。 |
| 注意 : | -- インデックスを作成 |
| 注意 : | CREATE UNIQUE INDEX table_pk |
| 注意 : | ON table (column) |
| 注意 : | REVERSE |
| 注意 : | COMPUTE STATISTICS |
| 注意 : | / |
| 注意 : | -- インデックスを再構築 |
| 注意 : | ALTER INDEX table_pk |
| 注意 : | REBUILD |
| 注意 : | REVERSE |
| 注意 : | COMPUTE STATISTICS |
| 注意 : | WLI で逆キー インデックスを使用する方法の詳細については、「WLI スキーマのチューニング」の「WLI_PROCESS_INSTANCE_INFO テーブル」を参照してください。 |
Oracle9i では、データベースの 1 つのインスタンスで複数のブロック サイズを持つデータ構造を使用できる新機能が導入されています。この機能は、トランザクション処理アプリケーション (OLTP) では小さなブロック サイズを使用し、バッチ処理アプリケーション、意思決定支援システム (DSS) またはデータ ウェアハウジングをサポートするためには大きなブロック サイズを使用するという柔軟性を必要とするデータベースに向いています。この機能は、LOB のようにサイズの大きなデータ型へのアクセスを効率化するためにも使用できます。
複数のブロック サイズのテーブルスペースを作成するには、次のコード サンプルに示すように、テーブルスペースの作成時にキーワード BLOCKSIZE を使用します。
-- wli_lob_data テーブルスペースを作成
CREATE TABLESPACE wli_lob_data
LOGGING
DATAFILE '/oracle/oradata/perfdb01/wli_lob_data_01.dbf'
SIZE 1000M REUSE
BLOCKSIZE 16K
EXTENT MANAGEMENT LOCAL
UNIFORM SIZE 50M
SEGMENT SPACE MANAGEMENT AUTO
/
WLI で複数のブロック サイズのテーブルスペースを使用する方法の詳細については、「WLI スキーマのチューニング」の「JPD テーブル」を参照してください。
| 注意 : | 複数のブロック サイズのテーブルスペースを作成するには、複数のブロック サイズのバッファ キャッシュを先に作成する必要があります。複数のブロック サイズのバッファ キャッシュの詳細については、「複数のブロック サイズのバッファ キャッシュ」を参照してください。 |
複数のブロック サイズのデータをキャッシュするために、Oracle9i には複数のブロック サイズのバッファ キャッシュがあります。これらのキャッシュは、複数のデータ ブロックのテーブルスペースに格納されたデータの読み込みをバッファに入れるために使用します。
複数のブロック サイズのキャッシュを作成するには、次のコード サンプルに示すように、特権を持つユーザが以下のステートメントを実行します。
-- 16K のブロック サイズのキャッシュを作成
ALTER SYSTEM
SET db_16k_cache_size = 64M
SCOPE = BOTH
/
WLI で複数のブロック サイズのテーブルスペースを使用する方法の詳細については、「WLI スキーマのチューニング」の「JPD テーブル」を参照してください。
LOB のチューニングでは、キャッシングのチューニングと、適切な物理ストレージ パラメータの設定を行います。
デフォルトでは、Oracle では LOB データはキャッシュされません。LOB データをキャッシュすると、LOB へのアクセスのパフォーマンスが大幅に向上します。ただし、DEFAULT プールの LOB データをキャッシュすると、他のアプリケーション データが古くなって書き換えられるのが早まります。LOB データは、RECYCLE プールや KEEP プールなどの代替プール、または (複数のブロック サイズのテーブルスペースを使用している場合は) 複数のブロック サイズのキャッシュに入れることをお勧めします。
LOB キャッシングを有効にするには、次のコード サンプルに示すように、LOB キャッシングを使用するよう指定してテーブルを作成または変更します。
-- LOB キャッシングを指定してテーブル foo を作成
CREATE TABLE foo
(
bar NUMBER(16),
baz BLOB
)
TABLESPACE wli_data
LOB (baz)
STORE AS
(
CACHE
)
/
-- LOB キャッシングを使用するようにテーブル foo を変更
ALTER TABLE foo
MODIFY LOB (baz) (CACHE)
/
CHUNK パラメータを設定し、STORAGE IN ROW を無効にすると、データベースのパフォーマンスが向上します。
CHUNK パラメータでは、LOB の場合に一度に操作されるデータの量 (バイト単位) を設定します。この値は、LOB のブロック サイズの倍数に設定する必要があります。格納される LOB の平均データ サイズによっては、この値をできるだけ大きくするか、LOB カラムに格納されるデータの平均サイズよりも大きな値に設定します。
テーブルの平均 LOB 長を確認するには、次の SQL ステートメントを使用します。
-- テーブル foo の bas LOB カラムの平均長を取得
SELECT AVG(DBMS_LOB.GETLENGTH(baz)) avg_lob_len
FROM foo
/
AVG_LOB_LEN
-----------
13171.712
前述の例では、テーブル foo の平均 LOB 長は 13171.712 バイト、つまり 13K 未満です。CHUNK サイズを 16K に設定すると、foo への LOB データの要求 1 件当たりの平均 I/O 回数は 1 未満になります。
LOB データは、インラインでテーブルの行 (同一セグメント) に格納することも、独自のセグメントに格納することもできます。LOB データを独自のセグメントに格納すると、データ アクセスの効率とパフォーマンスが向上します (特に、大きなブロック サイズのテーブルスペースに LOB データを格納する場合)。
WLI で LOB のチューニングを使用する方法の詳細については、「WLI スキーマのチューニング」の「JPD テーブル」を参照してください。
Oracle9i データベースには、管理しやすい小さな単位にテーブルをパーティション化する機能があります。分割された各単位は、個別の物理データ セグメントに格納されます。パーティション化はアプリケーションに対して透過的であり、パーティション化されたテーブルは、パーティション化されていないテーブルと同じように扱われます。基本的に、テーブルをパーティション化するための方法としては、レンジ パーティション化、ハッシュ パーティション化、およびリスト パーティション化の 3 種類があります。このドキュメントでは、ハッシュ パーティション化についてのみ説明します。
ハッシュ パーティション化では、テーブルで見つかったキー値のハッシュで、テーブルを指定した数のパーティションに分割します。適切な値のハッシュを選択した場合、このパーティション化によって、テーブルのすべてのパーティションにデータが均等に分散されます。リソース競合の問題 (行ロック待機や、バッファ ビジー待機の頻度が高い) のあるビジーなテーブルでは、この種類のチューニングを行うと、パフォーマンスにプラスの効果があります。
既存のテーブルをパーティション化するには、以下のコード サンプルに示すように、パーティション化されたテーブルを新たに作成し、古いテーブルのデータを新しいテーブルにコピーします。
-- パーティション化されていないテーブルを作成
CREATE TABLE foo
(
bar NUMBER(16),
baz BLOB,
CONSTRAINT foo_pk
PRIMARY KEY (bar)
)
TABLESPACE users
/
-- foo のデータが格納された、パーティション化されたバージョンの foo を新たに作成
CREATE TABLE new_foo
(
bar,
baz,
CONSTRAINT new_foo_pk
PRIMARY KEY (bar)
)
TABLESPACE users
PARTITION BY HASH (bar)
PARTITIONS 32
AS SELECT * FROM foo
/
-- 元のテーブル foo を削除
DROP TABLE foo
/
-- テーブル new_foo の名前を foo に変更
RENAME new_foo TO foo
/
WLI でパーティション化を使用する方法の詳細については、「WLI スキーマのチューニング」の「WLI_PROCESS_INSTANCE_INFO テーブル」を参照してください。
|
