|
|
このセクションでは、一般にチューニングによってパフォーマンスが向上する可能性のある WLI スキーマ内の部分について、重点的に説明します (ただし、その効果は対象となる WLI アプリケーションのアーキテクチャによって異なります)。このセクションに記載されているチューニング テクニックを使用すると、データベース システムのリソースの消費が増加します。これらのチューニング テクニックによって得られるメリットは、リソースの消費の増加による影響を上回る場合が大半ですが、このようなテクニックを使用するのは、具体的なパフォーマンスに関する問題が特定されてからにしてください。WLI アプリケーションでよく発生する特定可能なデータベースのパフォーマンスに関する問題のリストについては、「Oracle Statspack」を参照してください。
WLI では、ビジネス プロセスのロジックは、Java Process Definition (JPD) を使用して実装されます。JPD 情報は、WLI スキーマの JPD_PROCESS テーブルに保存されます。このテーブルは、いくつかのデータベース チューニング テクニックを使用することで、より高レベルな同時実行性とスループットに対応できるようチューニングできます。
JPD_PROCESS テーブルでパフォーマンスを大幅に向上させることができる主な方法の 1 つに、BLOB データ列である CG_DATA の格納特性を変更する方法があります。この列には、JPD インスタンスを表すシリアル化されたバイト配列が含まれています。
Oracle の LOB では、JPD テーブルでの BLOB の格納方法に関し、主に 2 つの問題が発生します。1 つは、BLOB データがキャッシュされないこと、もう 1 つは、BLOB データがテーブル データと共に保存されることです。これらのボトルネックを解消するには、JPD テーブルの BLOB 列をキャッシュし、別のテーブルスペースに格納する必要があります。
JPD テーブルがボトルネックになっていると判明した場合は、WLI データベースで JPD の BLOB のキャッシュを有効にする必要があります。BLOB データは、Oracle の DEFAULT プール、KEEP プール、RECYCLE プール、または別のブロック サイズのキャッシュにキャッシュできます。ただし、LOB データを DEFAULT プールにキャッシュすると、パフォーマンスが低下する可能性があります。これは、データベースで最も頻繁にキャッシュされるデータと、領域を競合することになるからです。このため、LOB データは、代替のバッファ プールのうちの 1 つにキャッシュする必要があります。
JPD の BLOB をキャッシュするには、キャッシュ先のバッファ プールを特定または作成し、JPD テーブルを作成するか、キャッシュを使用するよう JPD テーブルを変更する必要があります。
次のサンプル コードは、RECYCLE プールを作成し、jpd_process_table を変更する方法、および同テーブルを作成する方法を示しています。
-- RECYCLE プールを作成
ALTER SYSTEM
SET db_recycle_cache_size = 64M
SCOPE = BOTH
/
-- RECYCLE プールを使用するように既存の JPD テーブルを変更
ALTER TABLE jpd_processes_table
MODIFY LOB (cg_data)
(
CACHE
STORAGE
(
BUFFER_POOL RECYCLE
)
)
/
-- 新しい JPD テーブルを作成し、RECYCLE プールを使用するように構成
CREATE TABLE jpd_processes_table
(
cg_id VARCHAR2(768 byte) NOT NULL,
last_access_time NUMBER(19),
cg_data BLOB,
CONSTRAINT jpd_proceses_table_pk
PRIMARY KEY(cg_id)
USING INDEX TABLESPACE wli_index
)
TABLESPACE wli_data
LOB(cg_data) STORE AS
(
CACHE
STORAGE
(
BUFFER_POOL RECYCLE
)
)
/
LOB のキャッシュの詳細については、「データベースのチューニング」の「LOB のチューニング」を参照してください。
WLI の LOB データ専用のテーブルスペースを作成する必要があります。このテーブルスペースは、デフォルトのデータベース ブロック サイズで作成することも、より大きなブロック サイズで作成することもできます。ブロック サイズを大きくすると、LOB データにアクセスするときのパフォーマンスが向上する場合があります。
次のサンプル コードは、デフォルトのブロック サイズと、別のブロック サイズでテーブルスペースを作成する方法を示しています。
-- デフォルトのブロック サイズのテーブルスペースを作成
CREATE TABLESPACE wli_lob_data
DATAFILE '/u03/app/oracle/oradata/wlidb1/wli_lob_data01.dbf' SIZE 1000M
EXTENT MANAGEMENT LOCAL
UNIFORM SIZE 50M
SEGMENT SPACE MANAGEMENT AUTO
/
-- 別のブロック サイズのテーブルスペースを作成
CREATE TABLESPACE wli_lob_data
DATAFILE '/u03/app/oracle/oradata/wlidb1/wli_lob_data01.dbf' SIZE 1000M
BLOCKSIZE 16K
EXTENT MANAGEMENT LOCAL
UNIFORM SIZE 50M
SEGMENT SPACE MANAGEMENT AUTO
/
BLOB データを JPD テーブルから別のテーブルスペースに格納するには、JPD テーブルの TABLESPACE 格納パラメータを代替のテーブルスペースに設定して、同テーブルを作成または移動する必要があります。
次のサンプル コードは、JPD テーブルを作成する方法、および既存のテーブルを変更する方法を示しています。
-- 新しい JPD テーブルを作成
CREATE TABLE jpd_processes_table
(
cg_id VARCHAR2(768 byte) NOT NULL,
last_access_time NUMBER(19),
cg_data BLOB,
CONSTRAINT jpd_proceses_table_pk
PRIMARY KEY(cg_id)
USING INDEX TABLESPACE wli_index
)
TABLESPACE wli_data
LOB(cg_data) STORE AS
(
TABLESPACE wli_lob_data
DISABLE STORAGE IN ROW
CACHE
)
/
-- 既存の JPD テーブルを変更
ALTER TABLE jpd_processes_table
MOVE
LOB(cg_data)
STORE AS
(
DISABLE STORAGE IN ROW
TABLESPACE wli_lob_data
CACHE
)
/
複数のブロック サイズのテーブルスペースの詳細については、「データベースのチューニング」の「複数のブロック サイズのテーブルスペース」を参照してください。
WLI_PROCESS_INSTANCE_INFO テーブルは、JPD に永続的な変更を加えるたびに更新されます。WLI を使用して作成された一部のアプリケーションでは、同時に多数の挿入が実行された場合に、このテーブルがパフォーマンスのボトルネックになる場合があります。これまでに、このテーブルのパフォーマンス向上につながったチューニング テクニックは、逆キー インデックスの追加、およびハッシュ関数によるテーブルのパーティション化の 2 つです。
WLI_PROCESS_INSTANCE_INFO テーブルの主キー インデックスでは、データが順序どおりに並べられています。このようにデータが順序どおりに並べられていると、主キーのインデックスが膨大になり、同時に多数のロードが実行されると、パフォーマンスが低下します。主キーのインデックスを逆に並べ替えることで、インデックスで発生する直列化を解消できるため、この問題を軽減できます。
WLI_PROCESS_INSTANCE_INFO テーブルの主キー インデックスを逆にするには、インデックスを変更するか、テーブルを再度作成する必要があります。
次のサンプル コードは、インデックスを逆にする方法を示しています。
-- インデックスを逆に並べ替え
ALTER INDEX pk_wli_process_instance_info
REBUILD
REVERSE
COMPUTE STATISTICS
/
逆キー インデックスの使用方法の詳細については、「データベースのチューニング」の「逆キー インデックス」を参照してください。
ボリュームの大きい WLI アプリケーションで、テーブルへのアクセス要求が同時に多数発生すると、ブロック レベルでの競合が発生し始める可能性があります。テーブルをパーティション化すると、テーブルのデータを多数の物理パーティションに分散できるため、このような競合を削減できます。その結果、同時に実行されているトランザクションが、同じ物理ブロックにアクセスしようとする可能性も減少します。
WLI_PROCESS_INSTANCE_INFO テーブルをパーティション化するには、テーブルを再度作成する必要があります。パーティションの値は、2 の累乗に設定する必要があります。パーティションの値を 32 または 64 に設定すると、パフォーマンスが向上するようです。
次のサンプル コードでは、WLI_PROCESS_INSTANCE_INFO テーブルをパーティション化する方法を示しています。
-- パーティション化された WLI_PROCESS_INSTANCE_INFO テーブルを作成
CREATE TABLE WLI_PROCESS_INSTANCE_INFO
(
PROCESS_INSTANCE VARCHAR(768) NOT NULL,
PROCESS_TYPE VARCHAR(200) NOT NULL,
PROCESS_LABEL VARCHAR(1000),
PROCESS_STATUS SMALLINT NOT NULL,
PROCESS_START_TIME NUMBER NOT NULL,
PROCESS_END_TIME NUMBER,
SLA_EXCEED_TIME NUMBER,
SEQUENCE_ID INTEGER NOT NULL,
CONSTRAINT PK_WLI_PROCESS_INSTANCE_INFO
PRIMARY KEY(PROCESS_INSTANCE)
USING INDEX TABLESPACE wli_index
)
PARTITION BY HASH (PROCESS_INSTANCE) PARTITIONS 64
TABLESPACE wli_data
/
テーブルをパーティション化する方法の詳細については、「データベースのチューニング」の「パーティション化」を参照してください。
WLI_PROCESS_EVENT テーブルには、JPD 内で発生したイベントに関する詳細な追跡情報が含まれています。JPD トランザクションの終了時に、トランザクションの途中で生成されたすべてのイベントが JMS キューに送られ、WLI_PROCESS_EVENT テーブルに書き込まれます。実際に生成されるイベントの数は、JPD の複雑さと、OA&M コンソールで設定された TrackingLevel によって異なります。TrackingLevel が最も詳細なレベルに設定されていると、このテーブルへのアクセスで競合が発生し、システムのパフォーマンスが低下する可能性があります。このようなパフォーマンスの低下は、WLI_PROCESS_EVENT テーブルをパーティション化することで軽減できます。
追跡対象のイベントの数が増加すると、WLI_PROCESS_EVENT テーブルへのブロック レベルでのアクセスで発生する競合も増加します。テーブルをパーティション化すると、テーブルのデータを多数の物理パーティションに分散できるため、このような競合を削減できます。その結果、同時に実行されているトランザクションが、同じ物理ブロックにアクセスしようとする可能性も減少します。
WLI_PROCESS_EVENT テーブルをパーティション化するには、テーブルを再度作成する必要があります。パーティションの値は、2 の累乗に設定する必要があります。パーティションの値を 32 または 64 に設定すると、パフォーマンスが向上するようです。
次のサンプル コードは、WLI_PROCESS_EVENT テーブルをパーティション化する方法を示しています。
-- パーティション化された WLI_PROCESS_EVENT テーブルを作成
CREATE TABLE wli_process_event
(
process_type VARCHAR(200) NOT NULL,
process_event_id VARCHAR(60) NOT NULL,
process_instance VARCHAR(768) NOT NULL,
deployment_id INTEGER NOT NULL,
event_time INTEGER NOT NULL,
activity_id SMALLINT NOT NULL,
event_type SMALLINT NOT NULL,
event_data BLOB,
process_label VARCHAR(1000),
is_rolled_back SMALLINT NOT NULL,
event_elapsed_time NUMBER,
start_event_id VARCHAR(60),
event_count INT,
CONSTRAINT pk_wli_process_event
PRIMARY KEY (process_instance, process_event_id)
USING INDEX TABLESPACE wli_index
)
PARTITION BY HASH (process_instance, process_event_id) PARTITIONS 64
TABLESPACE wli_data
/
|
