| Oracle® Fusion Middleware Oracle SOA SuiteおよびOracle Business Process Management Suite管理者ガイド 11gリリース1 (11.1.1.7) B55916-10 |
|
 前 |
 次 |
| Oracle® Fusion Middleware Oracle SOA SuiteおよびOracle Business Process Management Suite管理者ガイド 11gリリース1 (11.1.1.7) B55916-10 |
|
前 |
次 |
この章では、大量のインスタンスを削除するパージ・スクリプトによるデータベースの増大化の管理方法、時間間隔によるレンジ・パーティション化が有効化されるスキーマを使用する表のパーティション化、表を削除することなく実行時の表のすべてのレコードを削除する切捨てスクリプト、およびオープン・コンポジット・インスタンスで表を再作成し、データベース領域を再使用する表作成スクリプト(TRSスクリプト)について説明します。
|
注意: 表のパーティション化は高度なデータベース・タスクであるため、熟練したデータベース管理者(DBA)のみが実行する必要があります。 |
データベース増大問題に関する詳細は、第B.2項「パラレル・パージと表のパーティション化の問題」、第B.7.4項「表領域の拡張による実行時の問題の回避」および第B.7.5項「大量のトランザクションによるデータベース増大の問題の解決」を参照してください。
データベース増分管理戦略の詳細は、第9章「データベース増分管理戦略の策定」を参照してください。
Oracle SOA Suiteデータベースのデータ量が増加して非常に大きくなると、データベースのメンテナンスが困難になる場合があります。この課題に対処するため、データベースの増分管理には表10-1に示されるようにいくつかの方法が用意されています。
表10-1 データベース増分の戦略
| 環境 | 使用方法 | 関連項目 |
|---|---|---|
|
データベース内の行が100,000未満の小規模な開発インストール |
Oracle Enterprise Manager Fusion Middleware Controlの「オプションを指定して削除」ボタン |
第8.2項「アプリケーションのホーム・ページからの、SOAコンポジット・アプリケーション・インスタンスの監視と削除」および第8.3項「SOAインフラストラクチャ・レベルでの、SOAコンポジット・アプリケーション・インスタンスの監視と削除」 |
|
データベース内の行が100,000を超える小規模な開発インストール |
ループしたパージ・スクリプト |
第10.3項「パージ・スクリプトを使用した大量のインスタンスの削除」 |
|
1日当たり10GBのデータを生成し、かつ500GB未満のデータを保存する中規模のインストール |
スケジュールされ、最適なスレッド数によるパラレル・パージ |
第10.3項「パージ・スクリプトを使用した大量のインスタンスの削除」 |
|
1日に10GBを超えるデータを生成する、または500GBを超えるデータを保存する大規模なインストール |
|
第10.3項「パージ・スクリプトを使用した大量のインスタンスの削除」 第10.4.1項「コンポーネント・データベース表のパーティション化」 |
|
切捨てスクリプト |
|
|
インストールをより効率的なデータベース増分管理戦略に移行するための修正処理が必要で、重大なメンテナンス停止時間がある小規模なインストール |
TRSスクリプト |
第10.6項「オープン・コンポジット・インスタンスでの表の再作成およびデータベース領域の再利用」 |
|
Microsoft SQL Serverデータベース |
ループしたパージ・スクリプト |
第10.7項「Microsoft SQL Serverでのインスタンスのパージ」 |
この項では、デハイドレーション・ストアのパージおよびパーティション化を行う場合に実行できる、アクション・プランの主なポイントを要約します。パージはあらゆるプランの根幹であり、データによって消費される領域が多すぎる場合、または別の理由でデータを削除する場合に実行します。
スキーマのサイズを削減するには、主に、次の3通りの戦略があります。
パージ・スクリプト
パージ・スクリプトおよびパーティション化(つまり、表パーティションの削除)
すべての表のパーティション化
最初の2つの場合では、同じパージ・スクリプトが使用されます。パーティション化する場合でも、パーティション化された表をコメント・アウトするためにパージ・スクリプトを編集する必要があります。
パージ・スクリプトでは、BPEL表から行を削除するために標準のSQL DELETE文を使用します。ほとんどのサイトではこれで十分です。ただし、サイトによっては蓄積されたデータが多すぎて、パージ・スクリプトの実行時間が非常に長くなることがあります。このような場合は、パーティション化の方がより適切な解決策となります。ただし、パーティション化によって非常に多くのデータベース・メンテナンス作業が発生することがトレードオフとなります。また、パーティション化は高度な技術であり、知識のあるDBAが必要となります。一方、パージ・スクリプトは簡単に実行でき、かつ、DBAの専門的な知識を必要としません。
入力メッセージ、データベース増分率およびパージ・プロセスでパージされるデータ量の概要を確認します。入力レートとパージ・レートが同じである場合は、通常のパージで十分です。これ以外の場合、パーティション化を検討します。
パーティション化を使用する場合、ディスク領域を追加し、最終的にパーティションを削除することをお薦めします。ただし、このことによってディスク容量の管理や適切なパーティション・サイズの決定などの追加要件が発生します。パーティション化を使用し、かつ、ディスク領域を解放するためにパージ・スクリプトに依存することは避けてください。
Oracle Enterprise Manager Fusion Middleware Controlで、SOAコンポジット・アプリケーションの「インスタンス」ページにある「オプションを指定して削除」ボタンを使用して数千のインスタンスを削除すると、時間がかかり、トランザクション・タイムアウトが発生する場合があります。かわりに、インスタンスを削除するためのパージ・スクリプトを使用します。パージ・スクリプトに関する次の詳細情報に注意してください。
パージ・スクリプトは、完了したインスタンスまたはエラー状態の(失敗した)インスタンスを削除します。詳細は、第10.3.3項「パージの状態」を参照してください。
|
注意: Oracle Mediatorのリシーケンサ表では、失敗したメッセージはパージされません。詳細は、第10.3.4項「Oracle Mediatorのリシーケンスされたメッセージのパージの状態」を参照してください。 |
パージ・スクリプトは、Oracle B2Bを除きすべてのOracle SOA Suite関連の表を削除します。Oracle SOA SuiteおよびOracle B2Bが同一インストールに配置されている場合、Oracle B2Bのパージ・スクリプトも必ず呼び出してください。Oracle SOA SuiteおよびOracle B2Bが別個のインストールに配置されている場合、それぞれの製品スキーマで適切なパージ・スクリプトのみを実行する必要があります。Oracle B2Bのパージの詳細は、『Oracle Fusion Middleware Oracle B2Bユーザーズ・ガイド』の「データのパージ」および「B2Bコマンドライン・ツール」を参照してください。
次の各項では、スクリプトを使用する方法の例を示します。
|
注意:
|
マスター・パージ・スクリプトには、バッチによるパージを実行できるループ構文が含まれています。また、このスクリプトにはmax_runtimeパラメータを指定して、このパラメータの値を超過するとループが停止されるようにすることもできます。
マスター・スクリプトはSOAデータベース表のパージを実行します。delete_instancesプロシージャを使用してSOAデータベース表をパージできます。
|
注意: パージするインスタンスが多い場合は、 |
インスタンスを削除するにはdelete_instancesプロシージャを使用します。例10-1に構文を示します。
例10-1 delete_instancesプロシージャの構文
procedure delete_instances (
min_creation_date in timestamp,
max_creation_date in timestamp,
batch_size in integer,
max_runtime in integer,
retention_period in timestamp,
purge_partitioned_component in boolean
ignore_state in boolean
composite_name in varchar2
composite_revision in varchar2
soa_partition_name in varchar2
);
表10-2で、スクリプトのパラメータについて説明します。
表10-2 delete_instancesプロシージャのパラメータの説明
| パラメータ | 説明 |
|---|---|
|
|
コンポジット・インスタンスの開始作成日。 |
|
|
コンポジット・インスタンスの終了作成日。 |
|
|
パージのループに使用されるバッチ・サイズ。デフォルト値は |
|
|
パージ・スクリプトがループを終了する有効期限。デフォルト値は |
|
|
保存期間はBPELプロセス・サービス・エンジンによってのみ使用されます(作成時間パラメータの使用に追加して)。この機能は他のコンポーネントに拡張されません。 このパラメータは、 BPELインスタンス( この例では、BPELインスタンス表の
min_creation_date = 1st June 2011
max_creation_date = 30 June 2011
retention_period = 1st July 2011
これにより、コンポジットの |
|
|
同じパージを起動して、パーティション化されたデータを削除できます。デフォルト値は |
|
|
注意: オープン・インスタンスのパージは、システムを不整合状態にする可能性があるため、このパラメータは慎重に使用してください。 |
|
|
SOAコンポジット・アプリケーションの名前。このパラメータを |
|
|
SOAコンポジット・アプリケーションのリビジョン番号。 |
|
|
SOAコンポジット・アプリケーションが格納されているパーティション。 |
|
注意:
|
このスクリプトは、第10.3.1項「ループしたパージ・スクリプト」で説明したループしたパージ・スクリプトと機能的には同じです。ただし、このスクリプトはdbms_schedulerパッケージを使用して、それぞれがサブセット・データに作用する複数のパージ・ジョブを作成します。
SOAデータベース表をパージするには、次の手順を使用します。
インスタンスを削除するにはdelete_instancesプロシージャをパラレルで使用します。例10-2に構文を示します。
例10-2 パラレル構文でのdelete_instancesプロシージャ
PROCEDURE delete_instances_in_parallel (
min_creation_date in timestamp,
max_creation_date in timestamp,
batch_size in integer,
max_runtime in integer,
retention_period in integer,
DOP in integer
max_count integer,
purge_partitioned_component in boolean)
composite_name in varchar2
composite_revision in varchar2
soa_partition_name in varchar2
表10-3で、スクリプトのパラメータについて説明します。
表10-3 パラレルでのdelete_instancesプロシージャのパラメータの説明
| パラメータ | 説明 |
|---|---|
|
|
コンポジット・インスタンスの開始作成日。 |
|
|
コンポジット・インスタンスの終了作成日。 |
|
|
パージのループに使用されるバッチ・サイズ。デフォルト値は |
|
|
パージ・スクリプトがループを終了する有効期限。デフォルト値は |
|
|
保存期間はBPELプロセス・サービス・エンジンによってのみ使用されます(作成時間パラメータの使用に追加して)。デフォルト値は |
|
|
スケジュールするパラレル・ジョブの数を定義します。デフォルト値は |
|
|
処理される行数を定義します(削除される行数ではありません)。大規模な |
|
|
同じパージを起動して、パーティション化されたデータを削除できます。デフォルト値は |
|
|
SOAコンポジット・アプリケーションの名前。このパラメータを |
|
|
SOAコンポジット・アプリケーションのリビジョン番号。 |
|
|
SOAコンポジット・アプリケーションが格納されているパーティション。 |
パラレル・スクリプトでループしたパージを実行した後にいずれかのスレッドのスレッド・ログでデッドロック検出される場合があります。例10-3に詳細を示します。
例10-3 スレッド・ログのデッドロック・エラー
SOA_PURGE_LOG_THREAD1 (total of 4 threads) 17-JUL-2012 03:03:48 : Purge AUDIT_DETAILS. Error Code = -60, Error Message = ORA-00060: deadlock detected while waiting for resource 17-JUL-2012 03:03:48 : ERROR(delete_inst_in_parallel_job. Error Code = -60, Error Message = ORA-00060: deadlock detected while waiting for resource
デッドロック問題を解決するには、AUDIT_DETAILS表を再構築して、次のいずれかの値を大きくします。
PCTFREEを大きくします(関連トランザクション・リスト(ITL)の割当てを拡大できるようにするため)。
INITRANS (初期ITL)を大きくします。このオプションは、以下で説明します。
AUDIT_DETAILS表を拡大し、INITRANS値を増やす手順は次のとおりです。
一時表を作成し、INITRANSの値を増やします(この例では名前AUDIT_DETAILS_TMPの表が作成されます)。
SQL> CREATE TABLE "PS6_SOAINFRA"."AUDIT_DETAILS_TMP"
( "CIKEY" NUMBER(*,0),
"DETAIL_ID" NUMBER(*,0),
"BIN_CSIZE" NUMBER(*,0),
"BIN_USIZE" NUMBER(*,0),
"DOC_REF" VARCHAR2(300),
"BIN" BLOB,
"CI_PARTITION_DATE" TIMESTAMP (6)
) SEGMENT CREATION IMMEDIATE
PCTFREE 0 PCTUSED 1 INITRANS 4 MAXTRANS 255 NOCOMPRESS LOGGING
STORAGE(INITIAL 331350016 NEXT 1048576 MINEXTENTS 1 MAXEXTENTS 2147483645
PCTINCREASE 0 FREELISTS 6 FREELIST GROUPS 1 BUFFER_POOL DEFAULT FLASH_CACHE
DEFAULT CELL_FLASH_CACHE DEFAULT)
TABLESPACE "PS6_SOAINFRA"
LOB ("BIN") STORE AS BASICFILE (
TABLESPACE "PS6_SOAINFRA" ENABLE STORAGE IN ROW CHUNK 8192 PCTVERSION 0
CACHE
STORAGE(INITIAL 16384 NEXT 8192 MINEXTENTS 1 MAXEXTENTS 2147483645
PCTINCREASE 0 FREELISTS 1 FREELIST GROUPS 1 BUFFER_POOL DEFAULT FLASH_CACHE
DEFAULT CELL_FLASH_CACHE DEFAULT)) ;
SQL> INSERT /*+ APPEND */ into audit_details_TMP select * from audit_details;
SQL> COMMIT;
AUDIT_DETAILS表を削除します。
SQL> DROP TABLE PS6_SOAINFRA.AUDIT_DETAILS CASCADE CONSTRAINTS;
AUDIT_DETAILS_TMP一時表の名前をAUDIT_DETAILSに変更します。
SQL> ALTER TABLE PS6_SOAINFRA.AUDIT_DETAILS_TMP RENAME TO AUDIT_DETAILS;
AUDIT_DETAILSで一意索引を作成します。
SQL> CREATE UNIQUE INDEX "PS6_SOAINFRA"."AD_PK" ON "PS6_SOAINFRA"."AUDIT_ DETAILS" ("CIKEY", "DETAIL_ID");
制約と主キーをAUDIT_DETAILSに追加します。
SQL> ALTER TABLE "PS6_SOAINFRA"."AUDIT_DETAILS" ADD CONSTRAINT "AD_PK" PRIMARY
KEY ("CIKEY", "DETAIL_ID") ENABLE;
次の状態のインスタンスは、パージ・スクリプトでパージされます。
正常に完了しました
フォルト
ユーザーによって終了されました
失効
不明(インスタンス・トラッキングが無効)
次のインスタンス状態のパージはサポートされていません。
BPELプロセス・サービス・エンジン・レベルまたはSOAコンポジット・アプリケーション・レベルでのリカバリを保留中のインスタンス
実行中のインスタンス
このようなインスタンスをパージするには、まずパージ・スクリプトによってサポートされるインスタンス状態のいずれかに移行する必要があります。
パージ・スクリプトには、Oracle Mediatorのリシーケンサ表(mediator_group_statusおよびmediator_resequencer_message)内の情報をパージするパージ・コマンドが含まれています。パージ・スクリプトを実行すると、次の情報がリシーケンサ表からパージされます。
すべてのリシーケンサ・タイプの完了したメッセージと中断されたメッセージ
標準リシーケンサのタイムアウトしたメッセージ
ベスト・エフォート・リシーケンサとFIFO(先入れ先出し)リシーケンサの準備完了状態のグループ(パージ可能な唯一のグループ)
フォルト・リカバリおよびメッセージ処理を完了できるようにするため、パージ・スクリプトは、リシーケンスされたすべてのメッセージ情報をパージするわけではありません。標準リシーケンサ・グループには、パージせずに残す必要がある情報も格納されます。パージ・スクリプトを実行しても、次の情報はパージされません。
すべてのリシーケンサ・タイプの失敗したメッセージ
すべてのリシーケンサ・タイプの実行中のメッセージ
標準リシーケンサのグループ情報
ベスト・エフォート・リシーケンサとFIFOリシーケンサの準備完了以外の状態のグループ
|
注意: Oracle Mediatorリシーケンサのパージ・スクリプトは、最初にメッセージをパージし、次にグループに移動します。 |
前述の説明は、インスタンスのトラッキングが有効か無効かに関係なく、パージ・スクリプトのループ処理とパラレル処理の両方について記載しています。シーケンス・グループをパージする前に、グループに関連付けられているすべてのメッセージが処理されることを確認するチェックが実行されます。
次に、リシーケンサ表で使用されるグループ状態コードのリストを示します。
0: 準備完了
1: ロック
2: エラー
4: タイムアウト
6: グループ・エラー
次に、リシーケンサ表で使用されるメッセージ状態コードのリストを示します。
0: 準備完了
1: ロック
2: 完了
3: エラー
4: タイムアウト(無視されます)
5: 中断
特定のSOAコンポジット・アプリケーションのインスタンスをパージし、その他のコンポジットのインスタンスはパージせずに残すことができます。このアクションを使用して、大量または保存期間が長い特性のために、特定のフローを他のフローより頻繁にパージできます。
パージ・スクリプトには、COMPOSITE_DNに基づいてパージするためのオプションが含まれています。COMPOSITE_DNをベースとするパージでは、composite_nameおよびcomposite_revisionパラメータとの併用がサポートされます。
このパージ・ロジックは、COMPOSITE_IDではなく、フロー(実行コンテキストID (ECID)) に基づいています。したがって、目的のCOMPOSITE_DN以外に、同じECIDを共有している他のコンポジットが削除されます。次に示すシナリオが発生する場合があります。
コンポジット・インスタンスはクローズされますが、フローはオープンしたままになります。
コンポジットAがコンポジットBをコールするシナリオでは、パージにより、コンポジットAのインスタンスが削除の対象となります。ただし、コンポジットAのインスタンスがクローズされ、対応するコンポジットBのインスタンスがオープンしたままの場合があります。したがって、全体的なフローがオープン状態にあり、コンポジットAのインスタンスは(クローズしたとしても)パージされません。
コンポジット・インスタンスがクローズされ、フローもクローズされます。
コンポジットAがコンポジットBを再度コールします。パージにより、コンポジットAのインスタンスが削除の対象となります。したがって、コンポジットAがクローズされ、コンポジットBもクローズされている場合は、フロー全体がクローズされているため、コンポジットAおよびBの両方のインスタンスがパージされます。
これらのシナリオにより、フローの一貫性が維持されます。
composite_nameおよびcomposite_revisionパラメータの詳細は、第10.3.1項「ループしたパージ・スクリプト」および第10.3.2項「dbms_schedulerを使用したパラレル・スクリプトでのループしたパージ」を参照してください。
この項では、パージ・スクリプトを実行する方法について説明します。
パージ・スクリプトを実行するには、次の手順を実行します。
SQL*Plusで、データベースAS SYSDBAに接続します。
CONNECT SYS AS SYSDBA
次のSQLコマンドを実行します。
GRANT EXECUTE ON DBMS_LOCK TO USER; GRANT CREATE ANY JOB TO USER;
ここで、USERはスクリプトを実行するためのsoainfraアカウントです。これらの特権は、スクリプトを実行するために必要です。
MW_HOME/SOA_ORACLE_HOME/rcu/integration/soainfra/sql/soa_purgeディレクトリにあるメイン・パージ・スクリプトを実行することで、パージ・スクリプトをロードします。
パラレル・パージの場合、パラレル・パージによって生成されたジョブからのデバッグ・ログは、SOA_PURGE_DIRという名前のディレクトリに作成されるファイルに記録されます。このディレクトリはOracleデータベースからアクセスできる必要があります。
SOA_PURGE_DIRを作成し、soainfraユーザーに書込み権限を付与します。
mkdir -p /tmp/purgelog
CREATE OR REPLACE DIRECTORY SOA_PURGE_DIR AS 'SERVER_DIRECTORY'
ここで、SERVER_DIRECTORYは作成するディレクトリ('/tmp/purgelog/'など)です。ディレクトリ・パスを囲む一重引用符は必須です。
スクリプトをデバッグ・モードで実行する場合、common/debug_on.sqlを実行し、SQL*Plusでserveroutをonに設定します。このステップはオプションです。
SET SERVEROUTPUT ON
生成されたジョブからのログは、ステップ4で作成されたディレクトリに記録されます(ジョブごとに別のファイル)。残りのログはstdout(または構成された場合はスプール・ファイル)に表示されます。
パージには次の2つのオプションがあります。
ループしたパージ
パラレル・パージ
次に示すようにパージ・スクリプトを実行します。両方のオプションに対して例を示します。
ループしたパージの場合
DECLARE
MAX_CREATION_DATE timestamp;
MIN_CREATION_DATE timestamp;
batch_size integer;
max_runtime integer;
retention_period timestamp;
BEGIN
MIN_CREATION_DATE := to_timestamp('2010-01-01','YYYY-MM-DD');
MAX_CREATION_DATE := to_timestamp('2010-01-31','YYYY-MM-DD');
max_runtime := 60;
retention_period := to_timestamp('2010-01-31','YYYY-MM-DD');
batch_size := 10000;
soa.delete_instances(
min_creation_date => MIN_CREATION_DATE,
max_creation_date => MAX_CREATION_DATE,
batch_size => batch_size,
max_runtime => max_runtime,
retention_period => retention_period,
purge_partitioned_component => false);
END;
/
パラレル・パージの場合
DECLARE
max_creation_date timestamp;
min_creation_date timestamp;
retention_period timestamp;
BEGIN
min_creation_date := to_timestamp('2010-01-01','YYYY-MM-DD');
max_creation_date := to_timestamp('2010-01-31','YYYY-MM-DD');
retention_period := to_timestamp('2010-01-31','YYYY-MM-DD');
soa.delete_instances_in_parallel(
min_creation_date => min_creation_date,
max_creation_date => max_creation_date,
batch_size => 10000,
max_runtime => 60,
retention_period => retention_period,
DOP => 3,
max_count => 1000000,
purge_partitioned_component => false);
END;
次のコンポーネントのランタイムおよびスキーマ・コードは、フロー作成日付列をトランザクション表に格納するように変更されました。
Oracle BPEL Process Manager
Oracle Mediator
ヒューマン・ワークフロー
Oracle B2B
SOAインフラストラクチャ(コンポーネント・インスタンスを含む)
Oracle BPM Suite
CPST_CREATED_DATE列には、インスタンス・トラッキング・コードによって移入されたフロー作成日時が含まれています。これは、正規化されたメッセージ・プロパティoracle.integration.platform.instance.CommonConstants.COMPOSITE_INSTANCE_CREATED_TIMEとして使用できます。
すべてのSOAコンポーネントは同じパーティション・キーでパーティション化されます。これらのパーティション化されたコンポーネントでは同じ時間範囲とパーティションIDが使用されます。
Oracle SOA Suiteには、DBAがOracle RDBMSのパーティション化機能を活用できるように、パーティション・キーが備えられています。このアクションにより、スキーマ表を時間間隔に基づいてレンジ・パーティション化できます。これは、大規模な表のデータベース・メンテナンス・ウィンドウを短縮する必要がある場合に役立ちます。(この章では説明していませんが、これにより、パーティション化されたデータをアーカイブすることもできるようになります。)
Oracle SOA Suiteの表をパーティション化するタスクは、熟練したDBAが実行する必要があります。表のパーティション化はDBAのコア・スキルであるため、この章では表をパーティション化する方法について、手順を追った詳細な説明は行いません。ここでは、Oracle SOA Suiteのスキーマおよび関連するスクリプトに関する、DBA向けの知識と説明を提供します。DBAは、この知識を活用して、各自の環境での任意のパーティション化戦略をカスタマイズし、データベースのパフォーマンスに応じたチューニング・パラメータを組み込むことができます。チューニングは状況に応じて実施する必要があり、また、構成に1回変更を加えるのみでは完了しません。これは監視とチューニングの反復プロセスです。
この章で説明するパーティション・スキームは、Oracle SOA Suite 11gリリース1 (11.1.1.4以降)でのみ使用できます。
次のコンポーネントは、コンポーネント独自のデータベース・スキーマに関連付けられています。
Oracle BPEL Process Manager
Oracle Mediator
ヒューマン・ワークフロー
Oracle B2B
SOAインフラストラクチャ
Oracle BPM Suite
表のパーティション化の詳細は、次のURLにあるOracleデータベース管理ドキュメント・ライブラリを参照してください。
http://www.oracle.com/technetwork/indexes/documentation/index.html
|
注意:
|
パフォーマンス上の理由から、Oracle BPEL Process Manager、Oracle Mediator、ヒューマン・ワークフロー、Oracle B2B、SOAインフラストラクチャおよびOracle BPM Suiteスキーマでは、整合性を強制するための外部キー制約がありません。このことには、参照パーティション化と呼ばれる11gのRDBMS機能を使用することが考慮されています。この機能は、外部キー制約を横断して、マスター表と詳細表の同一レベル・パーティション化を行うことによって、大きな利点をもたらします。同一レベル・パーティション化とは、関連する依存表の行が、マスター表の行と同じパーティション・キー間隔を持つ、1つのデータベース・パーティションに存在することを意味します。
この機能には、同一レベル・パーティション内の各詳細行の状態(完了、フォルトなど)について、その行に関連するマスター表の行から推測できるという利点があります。
11g RDBMSの参照パーティション化機能は使用できませんが、類似した動作を模倣して、いくつかの同じ利点を得ることができます。Oracle BPEL Process Manager、Oracle Mediator、ヒューマン・ワークフロー、Oracle B2B、SOAインフラストラクチャおよびOracle BPM Suiteのコンポーネントでは、詳細表の各行のパーティション・キーが、マスター表の行のパーティション・キーと同じであることが保証されます(つまり、詳細表でも日付(タイムスタンプ)がパーティション・キーとなります)。この場合、設定を完了するために、DBAはマスター表と詳細表が同じ間隔でレンジ・パーティション化されていることを確認する必要があります。この章の後の各項で、いくつかの例を示します。
|
注意: 実際のサイトでは、古いパーティションについては参照整合性を考慮する必要がないと判断することがあります。例として、サイトに十分なディスク領域があるために、古いデータを格納することが許容されている場合や、参照されないデータを依存表に保管しておいても、特に悪影響がない場合をあげることができます。 |
パーティション化は、デフォルトでは構成されていません。手動で実行する必要があるインストール後ステップです。データベースのパーティション化を実装することにした場合は、いくつかの初期構成タスクを1回のみ実行する必要があります。
この章の情報に従がって、パーティション化するグループを決定します。
それらのグループごとに、パーティション化する必要がある各グループに一部の必須表があることを念頭に、パーティション化する表を決定します。
グループごとに、パーティション間隔を決定します。
Oracle SOA Suiteスキーマをパーティション化するパーティション・スクリプトを作成します。スクリプトは提供されないため、各DBAに、各自の環境に適したパーティション・スクリプトを作成する責任があります。
パージ・スクリプトを編集し、パーティション化した表への参照を削除します。
パーティションおよび同一レベル・パーティション化された依存表を削除するタイミングを識別するために、DBAには検証スクリプトが提供されています。この検証スクリプトでは、長時間実行されているアクティブなインスタンスの存在も識別されます。その後、これらのインスタンスを別のパーティションに移動し、元のパーティションを削除できます。
|
注意: 検証スクリプトではパーティションが削除できることを確認するのみであり、パーティションを削除しません。 |
この項では、パーティション化の制約について説明し、コンポーネント表、コンポーネント表が属するグループおよびそのパーティション・キーのリストを示します。
次に示す表のパーティション化の制約に注意してください。
パーティション化のアプローチには、次の選択肢があります。
部分的なパーティション化: パーティション化を増加率が高い特定の表に制限します。表10-4に、パーティション化可能なマスター表および依存表を示します。
表10-4 部分的なパーティション化
| マスター表 | マスター表の依存表 |
|---|---|
|
|
|
|
|
|
|
|
なし |
|
|
|
|
|
なし |
表10-4のいずれの表も、次の制限に従ってパーティション化できます。
依存表をパーティション化する場合は、そのマスター表もパーティション化する必要があります。
すべての表は、同じ日付範囲と同じ名前に従って同一レベル・パーティション化される必要があります。
COMPOSITE_INSTANCE表は、常にパーティション化します。いずれかのコンポジットの「監査レベル」プロパティが「開発」または「本番」に設定されている場合、この制約は必須です。検証スクリプトは、そのパーティション内のアクティブなコンポジット・インスタンスに基づいて、アクティブなフローをチェックします。したがって、COMPOSITE_INSTANCE表がパーティション化されていない場合、すべての表の同一レベル・パーティション化に基づく全体検証スクリプト・ロジックは機能しません。
グループやコンポーネントに関係なく、パーティション化されたすべての表では、同じ時間範囲およびパーティションIDが使用されます。
表10-5から表10-10までは、3つのグループに分けられます。
グループ1: コンポジットのエンドツーエンド・フロー・トレースに直接関係する表が含まれます。表の大多数がこのグループに該当します。
グループ1A: フロー・トレースに直接関係しない表の小規模なセットが含まれます(REJECTED_MESSAGEなど)。
グループ2: グループ1とグループ1Aの表の複数の表に依存する表の小規模なセットが含まれます。グループ2の検証スクリプトを実行する前に、まず、グループ1の検証スクリプトを実行して、グループ1のパーティションを削除する必要があります。
|
注意: グループ1と1Aは、検証スクリプト内で結合されています。検証スクリプトを実行する際に、この分類に関する知識は必要ありません。 |
表10-5 コンポーネント: SOAインフラストラクチャ
| 表 | レンジ・パーティション・キー | グループ |
|---|---|---|
|
|
|
1 |
|
|
|
1 |
|
|
|
1 |
|
|
|
1 |
|
|
|
1 |
|
|
|
1A |
|
|
|
1A |
|
|
|
2 |
|
|
|
2 |
表10-6 コンポーネント: Oracle BPEL Process Manager
| 表 | レンジ・パーティション・キー | グループ |
|---|---|---|
|
|
|
1 |
|
|
|
1 |
|
|
|
1 |
|
|
|
1 |
|
|
|
1 |
|
|
|
1 |
|
|
|
1 |
|
|
|
1 |
|
|
|
1 |
|
|
|
1 |
|
|
|
1A |
|
|
|
1A |
|
|
|
1A |
|
|
|
2 |
表10-7 コンポーネント: Oracle Mediator
| 表名 | レンジ・パーティション・キー | グループ |
|---|---|---|
|
|
|
1 |
|
|
|
1 |
|
|
|
1 |
|
|
|
1 |
|
|
|
1A |
|
|
|
2 |
表10-8 コンポーネント: ヒューマン・ワークフロー
| 表 | レンジ・パーティション・キー | グループ |
|---|---|---|
|
|
|
1 |
|
|
|
1 |
|
|
|
1 |
|
|
|
1 |
|
|
|
1 |
|
|
|
1 |
|
|
|
1 |
|
|
|
1 |
|
|
|
1 |
|
|
|
1 |
|
|
|
1 |
|
|
|
1 |
|
|
|
1 |
|
|
|
1 |
|
|
|
1 |
|
|
|
1 |
|
|
|
1 |
|
|
|
1 |
表10-9 コンポーネント: Oracle B2B
| 表 | レンジ・パーティション・キー | グループ |
|---|---|---|
|
|
|
1 |
|
|
|
1 |
|
|
|
1 |
|
|
|
1 |
|
|
|
1 |
表10-10 コンポーネント: Oracle BPM Suite
| 表 | レンジ・パーティション・キー | グループ |
|---|---|---|
|
|
|
1 |
|
|
|
1 |
|
|
|
1 |
|
|
|
1 |
|
|
|
1 |
|
|
|
1 |
DBAがパーティションおよび同一レベル・パーティション化された依存表を削除するタイミングを識別するための検証スクリプトが提供されています。検証スクリプトは、MW_HOME/SOA_ORACLE_HOME/rcu/integration/soainfra/sql/verifyにあります。
検証スクリプトを実行する手順は次のとおりです。
SQLコマンドPART_DIRでディレクトリを作成します。例:
CREATE DIRECTORY PART_DIR AS '/tmp/verify'
soainfraユーザーにこのディレクトリの書込み権限を付与します。ログおよびSQLファイルはこのディレクトリに生成されます。
次のストアド・プロシージャをコールして、一時表を削除します。これは、アクティブなインスタンスが行移動スクリプトによって処理される一時表のセットで取得されるためです。
グループ1の場合:
DECLARE BEGIN verify_soa.trunc_verify1_temp_tables; END;
グループ2の場合:
DECLARE BEGIN verify_soa.trunc_verify2_temp_tables; END;
ストアド・プロシージャの実行には、クライアント・スクリプトsoa_exec_verify.sqlを使用できます。soa_exec_verify.sqlを編集し、検証が必要なパーティション名を配列mySoa_drv_listに入力します。
関数verify_soa.verify_1を実行するには、パラメータとして1を渡します。
関数verify_soa.verify_2を実行するには、パラメータとして2を渡します。
PART_DIRディレクトリに生成されるログおよびSQLファイルを確認します。
パーティションを検証して削除するには、次の手順を実行します。
関数verify_soa.verify_1を実行します。
PART_DIRフォルダのSOA_PARTITION_NAME_LOG_1という名前のログ・ファイルにエラーがないかチェックします。長時間実行されているアクティブなインスタンスがある場合は、第10.4.7項「別のパーティションへの長時間実行されているアクティブなインスタンスの移動」を参照してください。
PART_DIRフォルダに生成されたSOA_PARTITION_NAME_RESULT_1.sqlという名前のスクリプトを使用して、削除可能なパーティションを削除します。
verify_soa.verify_2を実行します。
PART_DIRフォルダのSOA_PARTITION_NAME_LOG_2という名前のログ・ファイルにエラーがあるかどうかをチェックします。
PART_DIRフォルダに生成されたSOA_PARTITION_NAME_RESULT_2.sqlという名前のスクリプトを使用して、削除可能なパーティションを削除します。
この検証スクリプトでは、パーティション内にアクティブなインスタンスが存在するかどうかが確認されます。アクティブなインスタンスがない場合は、パーティションを削除できます。しかし、パーティションには長時間実行されているアクティブなインスタンスが存在することがあります。これらのアクティブなインスタンスがあると、パーティションは削除されません。この問題を回避するために、長時間実行されているインスタンスを別のパーティションに移動できます。
Oracleデータベースには、パーティション間での行の移動を有効または無効にするためのオプションが用意されています。パーティション表を作成または変更する際は、行移動句(ENABLE ROW MOVEMENTまたはDISABLE ROW MOVEMENTのいずれか)を指定できます。この句は、キーが更新された場合の新しいパーティションへの行の移動を有効または無効にします。このオプションによって、パーティションの削除を阻止する長時間実行されているプロセスを処理できます。
検証スクリプトでは、合計インスタンス数、オープン・インスタンス数およびパーティション内のオープン・インスタンスの割合が提供されます。この情報に基づいて、行移動プロシージャの実行が選択可能になります。これによりターゲット表のパーティション・キーが更新され、これらのインスタンスの別のパーティションへの行移動が順に開始されます。パーティション化されたすべての表からアクティブなインスタンスすべてが別のパーティションに移動した後は、ターゲット・パーティションを削除できます。
|
注意:
|
長時間実行されているインスタンスを別のパーティションに移動する手順は、次のとおりです。
グループ1の検証スクリプトを実行します。このスクリプトの説明は、第10.4.5項「検証スクリプトの実行」を参照してください。
ログ・スクリプトをチェックして、パーティションの削除を阻止するアクティブなインスタンスがあるかどうかを確認します。
行移動プロシージャを実行します。ステップ2のログに基づいて、オープン・インスタンス数をチェックします。この件数に基づいて、行移動スクリプトを実行するか、パーティションの削除を延期するかを判断します。
SQL*PlusにSOAINFRAユーザーとしてログインします。
CONNECT SOAINFRA/password
次のPL/SQLプロシージャを実行して、グループ1の表の行を移動します。
SQL> PROCEDURE exec_row_movement_1( partition_name in varchar2, new_partition_date in timestamp );
説明:
partition_nameは、行移動を実行するパーティションの名前です。
new_partition_dateは、パーティション・キー列を更新する新しい日付です。
第10.3.6項「パージ・スクリプトの実行」の説明に従って、パージ・スクリプトを実行してパーティション化されていない表を削除します。パージ・プロシージャのpurge_partitioned_componentパラメータは、falseに設定する必要があります。
グループ1のパーティションを(ステップ3に基づいて)削除します。
グループ2の検証スクリプトを実行します。
パーティションの削除を妨げるアクティブなインスタンスがあるかどうかを確認します。
行移動プロシージャを実行します。ステップ7のログに基づいて、オープン・インスタンス数をチェックします。この件数に基づいて、行移動スクリプトを実行するか、パーティションの削除を延期するかを判断します。
SQL*PlusにSOAINFRAユーザーとして復帰します。
CONNECT SOAINFRA/password
次のPL/SQLプロシージャを実行して、グループ2の表の行を移動します。
SQL> PROCEDURE exec_row_movement_2( partition_name in varchar2, new_partition_date in timestamp );
説明:
partition_nameは、行移動を実行するパーティションの名前です。
new_partition_dateは、パーティション・キー列を更新する新しい日付です。
グループ2のパーティションを(ステップ8に基づいて)削除します。
一部のコンポーネントがパーティション化され、他のコンポーネントがパーティション化されていない環境の場合、パーティション化されていないデータ・セットは、第10.3項「パージ・スクリプトを使用した大量のインスタンスの削除」で説明したパージ・スクリプトを使用してパージする必要があります。
たとえば、ヒューマン・ワークフローがパーティション化されておらず、他のコンポーネントがパーティション化されているとします。検証スクリプトでは、すべてのSOAパーティションがパーティションの削除コマンドを使用して削除可能とレポートされます。ただし、ヒューマン・ワークフローの各表は、ループ/パラレル・パージ・スクリプトを使用してデータがパージされるまで、引続きワークフロー・データを保持します。
切捨てスクリプトを使用すると、表を削除することなくすべてのOracle SOA Suite実行時表からすべてのレコードを削除できます。切捨てスクリプトでは、データベース領域の再利用はできません。
切捨てスクリプトは、次のシナリオで役立ちます。
本番のカスタマイズおよび新規ジョブ定義を保管できるように本番環境のスキーマを保持する一方で、SOAインフラストラクチャ内(つまりクローン・データベース内)のすべてのインスタンス・データを状態にかかわりなく切り捨てる必要がある状況で、本番環境またはテスト環境クローンを作成する場合。
テスト・シナリオの再作成および再実行を必要とするテストでの使用。
切捨てスクリプトは、次のコンポーネントのすべての実行時表を対象とする切捨て文を含めることによって、このオプションを提供します。
Oracle BPEL Process Manager
Oracle Mediator
ビジネス・ルール
Oracle B2B
SOAインフラストラクチャ
Oracle BPM Suite
表を削除することなく実行時表からレコードを削除する手順は次のとおりです。
SQL*Plusを起動します。
sqlplus
SQL*Plusで、SOAINFRAユーザーとしてデータベースに接続します。
CONNECT SYS AS SOAINFRA
MW_HOME/SOA_ORACLE_HOME/rcu/integration/soainfra/sql/truncateディレクトリにある切捨てスクリプトを実行します。
SQL> @truncate_soa_oracle.sql
一部のOracle SOA Suite環境では、パージ・スクリプトでデータベース領域の再利用できるだけの十分な数のコンポジット・インスタンスを削除できない場合があります。これによりパフォーマンスの問題が発生する可能性があります。次のタスクを実行するために、表の再作成スクリプト(TRSスクリプト)が用意されています。
指定した保存ポリシーを考慮して、クローズしたすべてのコンポジット・インスタンスを削除します。
オープン・コンポジット・インスタンスのみを保持して、Oracle SOA Suiteの表を再作成します。
データベース・セグメント(表および索引)を縮小または再構築することなく、過剰に増大したデータベース表にただちに領域を再利用します。
クローズしたすべてのコンポジット・インスタンスの削除および領域の再編成と再利用が単一の手順で実行されます。
TRSスクリプトを使用すると、データベース増分戦略を適切な状態に戻すことができます。TRSスクリプトは、Oracle SOA Suiteスキーマ表で、ループまたはパラレル・スクリプトによってパージが行われていないことなどが原因で過剰な増大が発生した場合に、インストールでの領域の再利用を可能にするために提供されています。領域の再利用にTRSスクリプトが使用された場合は、適切なパージおよびパーティション化戦略を実装してデータベースの増大を管理する必要があります。TRSスクリプトは修正処理を目的として提供されるもので、パージ・スクリプトに置き換わるものではありません。
TRSスクリプトは、オープン・コンポジットおよびサービス・コンポーネントのデータを保持し、指定された保存ポリシーを優先します。また、TRSはオンサイトのOracle SOA Suiteスキーマから表を再作成するDDLスクリプトを生成するため、オンサイトのカスタマイズは保持されます。(オンサイトのデータベース管理者と協力してDDLの解析およびテストを実行することは不可欠です。)
TRSは次の2つのフェーズで実行されます。
フェーズ1: 表の再構築時に無視(削除)するクローズしたコンポジットおよびサービス・コンポーネントのIDが格納される一時表のセットへの移入を行います。このフェーズでは、表を再構築するためのDDLスクリプトも生成されます。
フェーズ2: 生成されたDDLスクリプトを実行して、指定されたOracle SOA Suiteの表を再作成します。このスクリプトは、実行前に解析およびテストを行う必要があり、カスタマイズが可能です。フェーズ2の前後には、データベースのバックアップが必要です。
次の要件を確認して、対象のOracle SOA Suite環境にTRSスクリプトが適合するかどうかを判定します。
|
注意: TRSスクリプトを使用する前に、まず第10.3項「パージ・スクリプトを使用した大量のインスタンスの削除」で説明されているOracle SOA Suiteのパージ・スクリプトを調整および使用する必要があります。 |
TRSスクリプトは修正処理の実行を目的として提供されるもので、パージ・スクリプトに置き換わるものではありません。修正処理とは、ご使用のインストールをより効率的なデータベース増分管理戦略に移行するための処理です。これには、レンジ・パーティション化表、パージ戦略がないことが原因で過剰に増大した各表のサイズの縮小が含まれます。TRSスクリプトは、ご使用のOracle SOA Suite環境を適切な状態に戻すためにのみ使用してください。パージ・スクリプトでの処理が最適になるように増分管理戦略を策定する必要があります。調整後は、インスタンスの削除の第1の方法としてパージ・スクリプトの使用に戻してください。
TRSスクリプトは、直接パス挿入、パラレル問合せスレーブ、およびロギングなしの実装を行いますが、パージ・スクリプトより時間がかかると予測されます。パージ・スクリプトは、クローズしたコンポジットのサブセットのみを削除しますが、TRSはクローズしたコンポジットのすべてを削除します。TRSスクリプトは、パージ・スクリプトの場合と同様にコンポジットの解析を行う必要がありますが、これはすべてのコンポジットに対して実行されます(保存期間は考慮されます)。
TRSスクリプトは、表の再作成(削除/作成/挿入)が必要であるため、Oracle SOA Suiteのダウンタイムが必要になります。これが、TRSスクリプトがパージ・スクリプトの代替にはならない理由です。インストールの多くは、24時間-7日間で、短時間のメンテナンス・ウィンドウで稼働し、Oracle SOA Suiteデータベースの増大の完全メンテナンスを行うこれらのスクリプトの使用は想定されません。
領域の再利用が緊急でなく、SOA表のレンジ・パーティション化や構造の変更が必要な場合は、TRSオプションが最適なオプションではない可能性があります。特定の表内のすべて(クローズおよびオープン)コンポジットをコピーするプレーンCTAS (CREATE TABLE AS SELECT)、またはITAS (INSERT TABLE AS SELECT)コマンドを使用して表を再構築する方法が適している場合もあります。データベース管理者はカスタム・スクリプトを作成でき、クローズするコンポジットを判定するための解析が不要になるため、このスクリプトのほうがTRSより高速になる場合も多くあります。
さらに、不確定な参照を回避するため、一部の表(COMPOSITE_INSTANCEなどのマスター表、詳細は後述)でも、依存表の再構築が必要になる可能性があります。カスタムCTASスクリプトまたはITASスクリプトは、特定のマスター表内のすべての行を保持するため、依存表の再構築が回避されます。したがって、領域の再利用が必要ない場合は、TRSが最適なオプションではない可能性があります。
フェーズ2でTRS DDL生成スクリプトを実行する前と後にOracle SOA Suiteデータベースをバックアップする必要があります。これは、第10.6.4項「フェーズ1-TRSスクリプトの作成」のtrs_instances PL/SQLプロシージャでredo_flagパラメータをfalseに設定して、ロギングなしを指定した場合に特に重要です。
動的に作成されたDDLスクリプトは、本番環境での実行前に、データベース管理者が品質保証(QA)環境で綿密な確認およびテストを行う必要があります。
TRSスクリプトは、Oracle SOA SuiteスキーマのOracle B2Bの表を除くすべての実行時表を再構築できます。
Oracle SOA Suite 11gパージ・スクリプトで言及されていないOracle SOA Suiteの表は削除できません。
TRSスクリプトは非常に大きな表を再構築でき、次の機能が設計されています。
パフォーマンス機能
パラレル問合せスレーブが大型の表を管理および走査します。
データ操作言語(DML)スクリプトが生成されます。
最小のRedo/Undoロギングにより、生成されるRedoログの数が減少します。
直接パス入力/出力(I/O)によって、生成されるRedoおよびUndoログの数が減少します。直接I/Oは、データベース・バッファ・キャッシュのバイパスもします。TRSスクリプトは、副問合せによる直接パス挿入を使用して、再作成された表への移入を行います。副問合せは、ソース表からオープン・コンポジット・フローのみを選択し、クローズした(削除された)コンポジットを無視します。表の再作成の副次的効果として、ディスク領域も再利用および再編成されます。
オンサイトの表と索引定義(データ定義言語(DDL))は、基本表と索引の定義に加えたカスタマイズにかかわりなく保持されます。
TRSスクリプトは実行前にカスタマイズできるため、表のパーティション化が促進されます。オンサイト・データベース管理者は、生成されたDDLスクリプトを変更する必要があります。
ファイングレイン表によってターゲットの大きな表が再構築されます。これは、TRSスクリプトの主目的です。これは、パージ戦略が実装されていない場合に発生する重大なエスカレーションの回避に役立ちます。
drop_flagパラメータによって、ソース(元)表が削除可能であるかどうかが判定されます。これは、領域の推定および検証に役立ちます。
TRSスクリプトは、表10-11に示されるように2フェーズで実行されます。
表10-11 2フェーズ実行のTRSスクリプト
| フェーズ1のタスク | フェーズ2のタスク |
|---|---|
|
PL/SQLプロシージャは、次のタスクを実行します。
注意: フェーズ1が失敗した場合、DDLスクリプトが生成されない、または一部のみ生成される結果になります。 |
QA環境で綿密なテストを行った後に、Oracle SOA Suiteインストールの停止時間にDDLスクリプトを実行します。 DDLスクリプトは実行前にカスタマイズできます。このスクリプトは、次のタスクを実行します。
|
第10.6.4項「フェーズ1-TRSスクリプトの作成」で、オープン・コンポジット・インスタンスを使用して表を再作成することを指定しています。XML_DOCUMENTは、指定可能な表に含まれている表です。XML_DOCUMENT表は、SOAインフラストラクチャ内のコンポーネント間で、次の表に表示されるドキュメントIDによって共有されます。
INSTANCE_PAYLOAD
DOCUMENT_DLV_MSG_REF
DOCUMENT_CI_REF
MEDIATOR_AUDIT_DOCUMENT (開発モードのみで使用)
B2B_DATA_STORAGE
XML_DOCUMENT表はそれ自体がマスター表です。他の表の再構築に使用される論理とは異なり、この表は前述の表にも表示されるドキュメントIDで再構築されます。したがって、XML_DOCUMENT表の再構築の前に前述の表のパージ、またはTRSスクリプトによる再作成が必要になります。
これにはTRSスクリプトの複数回の実行が必要な場合があります(前述の表でパージ・スクリプトが使用されない場合)。最初のタスクで、前述の表からクローズしたすべてのドキュメントIDを削除し、第2のタスクではこれらの表内に残っている内容に基づいてXML_DOCUMENT表のサイズを縮小します。
XML_DOCUMENT表は、B2B_DATA_STORAGE表との外部キー関連があるため、クローズ済のコンポジットおよびサービス・コンポーネントIDに基づいて再構築されるわけではありません。TRSスクリプトおよびこれによるこの表の再構築の必要性は、残っている内容に従うものであるため、Oracle B2BでクローズされているドキュメントIDは削除できません。
XML_DOCUMENT再構築の前に、次のいずれかを実行します。
パージ・スクリプトを実行して、INSTANCE_PAYLOAD、DOCUMENT_DLV_MSG_REF、DOCUMENT_CI_REF、およびMEDIATOR_AUDIT_DOCUMENTの各表から行を削除します。
または(あるいは両方)
TRSスクリプトを実行して、INSTANCE_PAYLOAD、DOCUMENT_DLV_MSG_REF、およびDOCUMENT_CI_REFの各表から行を削除します。
Oracle B2Bパージ・スクリプトを実行して、B2B_DATA_STORAGEから行を削除します。
|
注意:
|
trs_instances PL/SQLプロシージャを使用して、TRS DDLスクリプトを作成します。このスクリプトは、入力パラメータを受け取り、データベース表を読み取って再作成する表を決定します。例10-4に構文を示します。
例10-4 trs_instancesプロシージャ
PROCEDURE trs_instances (i_older in TIMESTAMP default null,
drop_flag in boolean default false,
redo_flag in boolean default false,
DOP in number default 0,
sql_trace in boolean default false);
表10-12は、TRSスクリプトのパラメータについて説明しています。
表10-12 パラメータの説明
| パラメータ | 説明 |
|---|---|
|
|
保存ポリシーを実装する日付を指定します。つまり、作成日付がこの日付より古いコンポジット・インスタンスは、クローズしていると削除の候補になります。 作成日付がこの日付より前のコンポジットは、オープンとクローズのいずれでも保存されます。これは必須パラメータです。デフォルト値はありません。 |
|
|
TRSスクリプトの一環として、元(ソース)表が削除されるかどうかを指定します。このフラグを使用して、トライアルを実行し、TRS操作の実行に十分なデータベース領域が存在することを確認します。TRS走査には、元の表と同じサイズの追加表を収容できるだけの十分な領域が必要です。
|
|
|
選択した表の再作成時にデータベースのRedoロギングが実行されるかどうかを指定します。Redoロギングの生成を回避すると、TRSスクリプトのパフォーマンスを大幅に向上できますが、データベースのバックアップとリカバリが必要なことになります。このパラメータの設定にかかわりなく、TRSスクリプトの実行前と後にバックアップを実行することをお薦めします。
|
|
|
TRSスクリプト操作のパラレル問合せスレーブの数の設定で使用されるパラレルの程度を指定します。パラレル問合せスレーブは、マルチCPUハードウェア上のTRSパフォーマンスを支援します。 |
|
|
SQL> SHOW PARAMETER DUMP SQLトレースによってSQL実行に重大なオーバーヘッドが生じます。デフォルト値は |
RCUが最初にTRSスクリプトをインストールします。TRSスクリプトのインストールを完了するには、次の手順を実行する必要があります。
TRSスクリプトのインストールを完了する手順は次のとおりです。
DDLスクリプトおよびログ・ファイルを取得するディレクトリを作成します。
mkdir -p /…/trs_output
SQL*Plusで、データベースAS SYSDBAに接続します。
SQL> CONNECT SYS AS SYSDBA
trs_dirデータベース・ディレクトリを作成します。
SQL> CREATE OR REPLACE DIRECTORY trs_dir AS '/.../trs_output';
Oracle SOA Suiteスキーマ所有者に権限を付与します。
SQL> GRANT READ, WRITE ON DIRECTORY trs_dir TO soa_owner;
SQLトレースでは、Oracle SOA Suiteスキーマ所有者にALTER SESSION権限が要求される場合があります。
SQL > GRANT ALTER SESSION TO soa_owner;
TRS_PARAMETER表内で再作成されるOracle SOA Suiteの表の表名を挿入します。
表にはTABLE_NAMEと呼ばれる列が1つあり、パージ・スクリプトで言及されたすべてのOracle SOA Suite表の名前を受け入れます。TRS_PARAMETER表には1つ以上の表を挿入できますが、Oracle SOA Suiteスキーマ内のマスター表とみなされる一部の表は、不確定な参照を回避するために追加の表の再構築が要求される場合があります。(TRSでは表の依存性が自動的に判定されます。)
SQL> CREATE TABLE TRS_PARAMETER (TABLE_NAME VARCHAR2(200));
SQL> INSERT INTO TABLE TRS_PARAMETER VALUES('COMPOSITE_INSTANCE');
SQL> COMMIT;
COMPOSITE_INSTANCE表がTRS_PARAMETER表に挿入される場合は、すべてのコンポーネントの実行時表を再構築する必要があります。これはCOMPOSITE_INSTANCE表にすべてのコンポジット・フローの状態(オープンまたはクローズ)が格納されるためです。不確定な参照を回避するために、Oracle BPEL Process Manager、Oracle Mediator、ヒューマン・ワークフロー、およびデシジョン・サービス(ビジネス・ルール)のサービス・コンポーネント表が再構築されます。これは、DDLの生成時にTRSスクリプトによって自動的に処理されます。
また、TRS_PARAMETER表にOracle BPEL Process Managerのマスター表CUBE_INSTANCEのみを挿入する場合は、Oracle BPEL Process Manager実行時表のみが再構築されます。したがって、SOAインフラストラクチャ、Oracle Mediator、ヒューマン・ワークフロー、およびデシジョン・サービス(ビジネス・ルール)の実行時表はそのままで保持され、クローズ済のコンポジットはSOAインフラストラクチャの表(COMPOSITE_INSTANCE)を介して引続きOracle Enterprise Manager Fusion Middleware Controlに表示できます。クローズ済のSOAコンポジット・アプリケーションを削除するには、第10.3項「パージ・スクリプトを使用した大量のインスタンスの削除」で説明されているパージ・スクリプトを実行する必要があります。(前述のように、TRSはパージおよびパーティション化の実装を可能にする修正処理を目的としています。)
|
注意: パージ・スクリプト内の個別のOracle SOA Suite表はすべて再作成が可能ですが、Oracle SOA Suiteスキーマ内の表にはマスター表とみなされる表も、依存性が存在する表もあります。不確定の参照を回避するため、TRSスクリプトは依存表を自動的に組み込みます。 |
表10-13 マスター・コンポーネント表とTRS_PARAMETER表
| マスター・コンポーネント表名 | 自動的に組み込まれる表 |
|---|---|
|
|
SOAインフラストラクチャ、Oracle BPEL Process Manager、Oracle Mediator、ヒューマン・ワークフロー、およびビジネス・ルール(デシジョン・サービス)コンポーネントのすべての実行時表を再作成します。 |
|
|
Oracle BPEL Process Manager実行時表(Oracle BPM Suiteの実行時表を含む)のすべてを再作成します。 |
|
|
Oracle Mediator実行時表のすべてを再作成します。 |
|
|
ヒューマン・ワークフロー実行時表のすべてを再作成します。 |
|
|
ビジネス・ルール(デシジョン・サービス)の実行時表のすべてを再作成します。 |
|
|
|
脚注 1 一般にこの表はサイズが増大します。XML_DOCUMENT表の再作成前は、実行が必要な固有の前提条件が存在します。詳細は、第10.6.3項「XML_DOCUMENT表再構築の前提条件」を参照してください。
表10-14 個別の表とTRS_PARAMETER表
| 表名 | 自動的に組み込まれる表 |
|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
脚注 1 一般にこの表はサイズが増大します。
データベース・ディレクトリtrs_dirにログ・ファイルを生成します。
SQL> @debug_on
ログ・ファイル内のすべてのAPI文の失敗を取得します。
SQL> SET SERVEROUTPUT ON
|
注意:
|
終了して、最終バッファをログおよびSQLスクリプト・ファイルにフラッシュします。
SQL> EXIT
データベース・ディレクトリtrs_dirにある生成されたDDLスクリプトを実行します。このスクリプトには、第10.6.4項「フェーズ1-TRSスクリプトの作成」で生成され、Oracle SOA Suiteの表を再作成するための文が含まれています。
SQL*Plusで、データベースAS SYSDBAに接続します。
SQL> CONNECT SYS AS SYSDBA
trs_dirディレクトリで、生成されたDDLスクリプトを実行します。
SQL> @SOA_TRS_20120711091958.sql
これで、SOA_TRS_20120711091958.logという名前のスプール・ファイルが作成されます。
現在のプロシージャ、および実行されるSQL文の監査証跡を記録できます。監査証跡は、trs_dirディレクトリのsoa_trs_DATE.logという名前のログ・ファイルに書き込まれます。
ロギングとデバッグを有効にする手順は次のとおりです。
次の場所にディレクトリを変更します。
$ cd …./trs_common
デバッグをオンにします。
SQL> @debug_on.sql;
DDLスクリプトの実行が完了したら、デバッグをオフにします。
SQL> @debug_off.sql;
DDLスクリプトの作成および実行時に発生したエラーを追跡できます。sql_traceフラグに関する次の詳細に注意してください。
SQLトレースは、trs_instancesプロシージャ内の文に対して設定されます(イベント10046)。
SQLトレース・ファイルは、データベース・ユーザーのダンプ出力先にあります。
SQL文をDEBUGログ設定と関連付けると、プロシージャを判定できます。
SQLトレースは、TRSスクリプトの最上部で設定されます(イベント10046)。
Microsoft SQL Serverのデータベース・インスタンスをパージするには、第10.3.1項「ループしたパージ・スクリプト」で説明されているループ (シングル・スレッド)のパージ・スクリプトを実行します。
ループしたパージ・スクリプトを実行する前に、次の詳細に注意します。
Microsoft SQL Server上でのパラレル・パージ・スクリプトの実行、およびパーティション化はサポートされていません。
次のMicrosoft SQL Serverバージョンがサポートされています。
2005 (すべてのサービス・パック・レベルが含まれます)
2008 (すべてのサービス・パック・レベルが含まれます)
2008 R2 (すべてのサービス・パック・レベルが含まれます)
Oracle PL/SQLパージ・スクリプトは、Microsoft SQL Server Transact-SQL (T-SQL)に変換されます。
T-SQLとは相違点があるため、スクリプトの実行はOracleデータベースの場合とは少し異なります。これらの相違点については、以降の項で説明します。
ここでは、いくつかの基本的なMicrosoft SQL Serverの機能について説明します。より具体的な詳細は、Microsoft SQL Serverのドキュメントを参照してください。
Microsoft SQL Serverは、ディスク・ファイルを共有しない独立したデータベースです。これは、1つのデータベース・インスタンスで多数のユーザーとスキーマを保持でき、ユーザーが表領域を共有できるOracleデータベースとは異なります。
Microsoft SQL Serverは、ログインを使用して、インスタンスへのアクセスを提供します。表、ビューなどへの個別アクセスを取得するためにログインにマップされるユーザーが、データベースのそれぞれに存在します。
ユーザーのそれぞれにデフォルト・スキーマがあり、他のスキーマへのアクセスを取得できます。
sysadminロールを使用したログインには、データベース所有者(dbo)に割り当てられるデフォルト・スキーマがあります。
T-SQLは、Oracle PL/SQLと同等です。
ログインのそれぞれには複数のデータベースおよびデータベース内のスキーマに対するアクセスがあります。どのオブジェクトについても、アクセスには完全修飾名を使用する必要があります。
[DATEBASE_NAME].[SCHEMA_NAME].[TABLE_NAME]
データベース・オブジェクトにアクセスする前に、データベース名をデフォルトにできます。
[DATEBASE_NAME]コマンドを使用します。
スキーマ・オブジェクトには、[SCHEMA_NAME].[TABLE_NAME]としてアクセスします。
オブジェクトがユーザーに指定されたデフォルト・スキーマに存在する場合は、スキーマ名を修飾することなく、直接アクセスできます。
ここでは、Microsoft SQL Server上でパージ・スクリプトを使用する際に相違のある状況について説明します。
Microsoft SQL Serverではパッケージがサポートされませんが、パージ・スクリプトはコンポーネントごとに別個のパッケージに依存します。Microsoft SQL Serverのスキーマは、この機能の実現のために使用されます。
T-SQLは、ロギング(dbms_putlineおよびutl_file.put_line)を直接的にはサポートしていません。xp_cmdshellによってパージの詳細がファイルのログ記録されます。この機能には、第10.7.3項「Microsoft SQL Server上でのパージ・スクリプトの実行」で説明される構成の追加変更が必要です。
T-SQLでは、Oracleデータベースのデバッグのオンとオフの切替えに使用されるコンパイラ・フラグがサポートされません。追加の表でデバッグの設定が管理されます。
Microsoft SQL Serverから表にアクセスするには、表がスキーマ名で修飾されている必要があります。メイン・スクリプトでスキーマ名の接頭辞を回避するためのシノニムの作成および削除のため、Microsoft SQL Serverには追加のプロシージャが用意されています。
xp_cmdshellは、Windowsコマンド・シェルを作成し、実行用の文字列を渡します。この文の実行には、sysadminロールが必要です。
SQLCMDユーティリティを使用してパージ・スクリプトを実行します。このユーティリティを使用すると、次の場所のコマンド・プロンプトでT-SQL文、システム・プロシージャおよびスクリプト・ファイルを入力できます。
SQLCMDモードの問合せエディタ
Windowsのスクリプト・ファイル
SQL Serverエージェント・ジョブのオペレーティング・システム(cmd.exe)ジョブ・ステップ
パージ・スクリプトは別のディレクトリにある別のSQLファイルでパッケージ化され、その相対パスを介してアクセスするため、このロードにはSQLCMDユーティリティの使用が最適な方法です。
パージ・スクリプトは、MW_HOME/SOA_ORACLE_HOME/rcu/integration/soainfra/mssql/soa_purgeディレクトリにあります。
sysadmin権限のあるユーザーとして、SQLCMDユーティリティを使用してMicrosoft SQL Serverに接続します。例:
sqlcmd -S myhost.us.example.com\Instance_Name -D database_name - U user_name -P password
DATEFORMATコマンドを設定して、パージ・スクリプトを英語で実行します。
|
注意: Microsoft SQL Serverでは、パージ・スクリプトを実行する際にサポートされる言語は英語のみです。 |
'set DATEFORMAT mdy'
例:
'set DATEFORMAT 08122013'
パージ・スクリプトをロードします。
:r soa_purge_scripts.sql <1 rows affected>
xp_cmdshellをサポートするように、構成を変更します。
sp_configure 'xp_cmdshell', 1; GO RECONFIGURE; GO
必要に応じてデバッグを有効化します。
:r common\debug_on.sql
特定のスキーマ上のパージをターゲットにするシノニムを作成します。
exec soa.create_synonyms
@schema_name = 'SS1_SOAINFRA'
GO
パージ・スクリプトを実行します。
Exec soa.delete_instances @min_creation_date ='01 Jan 2012', @max_creation_date ='30 Jan 2012', @batch_size = 50 , @max_runtime = 15 , @retention_period = '31 Dec 2012', @write_file = 'C:\temp\out1.txt' GO
指定するパラメータは、purge_partitioned_componentパラメータがサポートされないことを除き、表10-1に示されたOracleデータベース上でのループしたパージ・スクリプトの実行のパラメータと同じです。
|
注意:
|
