| Oracle® Fusion Middleware Oracle SOA SuiteおよびOracle Business Process Management Suite管理者ガイド 11g リリース1 (11.1.1.6.0) B55916-06 |
|
 前 |
 次 |
| Oracle® Fusion Middleware Oracle SOA SuiteおよびOracle Business Process Management Suite管理者ガイド 11g リリース1 (11.1.1.6.0) B55916-06 |
|
前 |
次 |
この章では、SOAコンポジット・アプリケーションの大量のインスタンスを削除するためのパージ・スクリプト、およびスキーマ表を時間間隔に基づいてレンジ・パーティション化できるようにするデータベース表のパーティション化の両方を使用して、データベース内のデータの増加を管理する方法について説明します。
|
注意: 表のパーティション化は高度なデータベース・タスクであるため、熟練したデータベース管理者(DBA)のみが実行する必要があります。 |
Oracle SOA Suiteデータベースのデータ量が増加して非常に大きくなると、データベースのメンテナンスが困難になる場合があります。この課題に対処するために、データベース増分を管理する次の2通りの方法があります。
パージ・スクリプトを使用した大量のインスタンスの削除
コンポーネント・データベース表のパーティション化
インスタンスおよび拒否メッセージの削除にパージ・スクリプトを使用できます。パージ・スクリプトはMW_HOME/SOA_ORACLE_HOME/rcu/integration/soainfra/sql/soa_purgeディレクトリにあります。
ほとんどのOracle SOA Suiteのインストール環境では、パージ・スクリプトが適切です。スキーマが大きく増加し、パージ・スクリプトではパフォーマンス・ニーズを満たすことができなくなった場合に、表のパーティション化の使用を検討してください。
パージ・スクリプトの詳細は、第9.3項「パージ・スクリプトを使用した大量のインスタンスの削除」を参照してください。
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はマスター表と詳細表が同じ間隔でレンジ・パーティション化されていることを確認する必要があります。この章の後の各項で、いくつかの例を示します。
|
注意: 実際のサイトでは、古いパーティションについては参照整合性を考慮する必要がないと判断することがあります。例として、サイトに十分なディスク領域があるために、古いデータを格納することが許容されている場合や、参照されないデータを依存表に保管しておいても、特に悪影響がない場合をあげることができます。 |
スキーマのパーティション・キーを選択する場合は、次の要素を考慮します。
参照整合性の状態(完了など)を伝達するか、または暗黙的に示すこと
メンテナンス操作のための、時間間隔でのレンジ・パーティション化が可能であること
参照されないデータが生じる可能性がある行の移動を回避するために静的であること
表のメンテナンス操作を実行する場合に行が移動されないように、静的であること
パーティション・プルーニングによってコンソール問合せに対するパフォーマンス上の利点がもたらされること
この項では、デハイドレーション・ストアのパージおよびパーティション化を行う場合に実行できる、アクション・プランの主なポイントを要約します。パージはあらゆるプランの根幹であり、データによって消費される領域が多すぎる場合、または別の理由でデータを削除する場合に実行します。
スキーマのサイズを削減するには、主に、次の3通りの方法があります。
パージ・スクリプト
パージ・スクリプトおよびパーティション化(つまり、表パーティションの削除)
すべての表のパーティション化
最初の2つの場合では、同じパージ・スクリプトが使用されます。パーティション化する場合でも、パーティション化された表をコメント・アウトするためにパージ・スクリプトを編集する必要があります。
パージ・スクリプトでは、BPEL表から行を削除するために標準のSQL DELETE文を使用します。ほとんどのサイトではこれで十分です。ただし、サイトによっては蓄積されたデータが多すぎて、パージ・スクリプトの実行時間が非常に長くなることがあります。このような場合は、パーティション化の方がより適切な解決策となります。ただし、パーティション化によって非常に多くのデータベース・メンテナンス作業が発生することがトレードオフとなります。また、パーティション化は高度な技術であり、知識のあるDBAが必要となります。一方、パージ・スクリプトは簡単に実行でき、かつ、DBAの専門的な知識を必要としません。
入力メッセージ、データベース増分率およびパージ・プロセスでパージされるデータ量の概要を確認します。入力レートとパージ・レートが同じである場合は、通常のパージで十分です。これ以外の場合、パーティション化を検討します。
パーティション化を使用する場合、ディスク領域を追加し、最終的にパーティションを削除することをお薦めします。ただし、このことによってディスク容量の管理や適切なパーティション・サイズの決定などの追加要件が発生します。パーティション化を使用し、かつ、ディスク領域を解放するためにパージ・スクリプトに依存することは避けてください。
Oracle Enterprise Manager Fusion Middleware Controlで、SOAコンポジット・アプリケーションの「インスタンス」ページの「オプションを指定して削除」ボタンを使用して数千のインスタンスを削除すると、時間がかかり、トランザクション・タイムアウトが発生する場合があります。かわりに、インスタンスを削除するためのパージ・スクリプトを使用します。パージ・スクリプトに関する次の詳細情報に注意してください。
パージ・スクリプトは、完了したインスタンスまたはエラー状態の(失敗した)インスタンスを削除します。詳細は、第9.3.3項「パージの状態」を参照してください。
|
注意: Oracle Mediatorのリシーケンサ表では、失敗したメッセージはパージされません。詳細は、第9.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データベース表をパージできます。
|
注意: パージするインスタンスが多い場合は、max_runtimeを高い値に設定します。この場合、スクリプトが終了するまでの待機時間が長くなることが予想されます。より短い時間でパージ・スクリプトを終了させるには、小さいバッチ・サイズを使用します。 |
インスタンスを削除するにはdelete_instancesプロシージャを使用します。例9-1に構文を示します。
例9-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
composite_name in varchar2
composite_revision in varchar2
soa_partition_name in varchar2
);
表9-1で、スクリプトのパラメータについて説明します。
表9-1 delete_instancesプロシージャのパラメータの説明
| パラメータ | 説明 |
|---|---|
|
|
コンポジット・インスタンスの開始作成日。 |
|
|
コンポジット・インスタンスの終了作成日。 |
|
|
パージのループに使用されるバッチ・サイズ。デフォルト値は |
|
|
パージ・スクリプトがループを終了する有効期限。デフォルト値は |
|
|
保存期間はBPELプロセス・サービス・エンジンによってのみ使用されます(作成時間パラメータの使用に追加して)。この機能は他のコンポーネントに拡張されません。 このパラメータは、 BPELインスタンス( この例では、BPELインスタンス表の
min_creation_date = 1st June 2011
max_creation_date = 30 June 2011
retention_period = 1st July 2011
これにより、コンポジットの |
|
|
ユーザーはパーティション化されたデータを削除するために同じパージを起動できます。デフォルト値は |
|
|
SOAコンポジット・アプリケーションの名前。このパラメータをcomposite_revisionパラメータおよびsoa_partition_nameパラメータと併用すると、特定のSOAコンポジット・アプリケーションのインスタンスをパージできます。詳細は、第9.3.5項「特定のSOAコンポジット・アプリケーションのインスタンスのパージ」を参照してください。 |
|
|
SOAコンポジット・アプリケーションのリビジョン番号。 |
|
|
SOAコンポジット・アプリケーションが格納されているパーティション。 |
|
注意: retention_periodに値を指定しない場合、このプロパティの値はmax_creation_dateの値にデフォルトで設定されます(つまり、retention_periodがnullに等しい場合、retention_period = max_creation_date)。この結果は、第9.3.2項「dbms_schedulerを使用したパラレル・スクリプトでのループしたパージ」で説明されているスクリプト・パラメータにも適用されます。 |
このスクリプトは、第9.3.1項「ループしたパージ・スクリプト」で説明されているループしたパージ・スクリプトと機能的に同じです。ただし、このスクリプトでは、各ジョブがサブセット・データを処理する複数のパージ・ジョブを生成するためのdbms_schedulerパッケージを使用します。
SOAデータベース表をパージするには、次の手順を使用します。
|
注意: 複数のCPUを持つホストがある場合、パラレル・スクリプトを使用することが役立ちます。ただし、パラレル・スクリプトはオフピーク時にのみ有効化することをお薦めします。さらに、オフピーク時にデータをパージするとき、大量のデータをパージする前に索引を削除し、後で索引を追加して戻すことをお薦めします。これにより、パージ処理が高速化され、索引のバランスを維持できます。 |
インスタンスを削除するにはdelete_instancesプロシージャをパラレルで使用します。例9-2に構文を示します。
例9-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
表9-2で、スクリプトのパラメータについて説明します。
表9-2 パラレルでのdelete_instancesプロシージャのパラメータの説明
| パラメータ | 説明 |
|---|---|
|
|
コンポジット・インスタンスの開始作成日。 |
|
|
コンポジット・インスタンスの終了作成日。 |
|
|
パージのループに使用されるバッチ・サイズ。デフォルト値は |
|
|
パージ・スクリプトがループを終了する有効期限。デフォルト値は |
|
|
保存期間はBPELプロセス・サービス・エンジンによってのみ使用されます(作成時間パラメータの使用に追加して)。デフォルト値は |
|
|
スケジュールするパラレル・ジョブの数を定義します。デフォルト値は |
|
|
処理される行数を定義します(削除される行数ではありません)。大規模な |
|
|
ユーザーはパーティション化されたデータを削除するために同じパージを起動できます。デフォルト値は |
|
|
SOAコンポジット・アプリケーションの名前。このパラメータをcomposite_revisionパラメータおよびsoa_partition_nameパラメータと併用すると、特定のSOAコンポジット・アプリケーションのインスタンスをパージできます。詳細は、第9.3.5項「特定のSOAコンポジット・アプリケーションのインスタンスのパージ」を参照してください。 |
|
|
SOAコンポジット・アプリケーションのリビジョン番号。 |
|
|
SOAコンポジット・アプリケーションが格納されているパーティション。 |
次の状態のインスタンスは、パージ・スクリプトでパージされます。
正常に完了しました
フォルト
ユーザーによって終了されました
失効
不明(インスタンス・トラッキングが無効)
次のインスタンス状態のパージはサポートされていません。
BPELプロセス・サービス・エンジン・レベルまたはSOAコンポジット・アプリケーション・レベルでのリカバリを保留中のインスタンス
実行中のインスタンス
このようなインスタンスをパージするには、まずパージ・スクリプトによってサポートされるインスタンス状態のいずれかに移行する必要があります。
パージ・スクリプトには、Oracle Mediatorのリシーケンサ表(mediator_group_statusおよびmediator_resequencer_message)内の情報をパージするパージ・コマンドが含まれています。パージ・スクリプトを実行すると、次の情報がリシーケンサ表からパージされます。
すべてのリシーケンサ・タイプの完了したメッセージと中断されたメッセージ
標準リシーケンサのタイムアウトしたメッセージ
ベスト・エフォート・リシーケンサとFIFO(先入れ先出し)リシーケンサの準備完了状態のグループ(パージ可能な唯一のグループ)
フォルト・リカバリおよびメッセージ処理を完了できるようにするため、パージ・スクリプトでは、リシーケンスされたすべてのメッセージ情報がパージされるわけではありません。標準リシーケンサ・グループには、パージせずに残す必要がある情報も格納されます。パージ・スクリプトを実行しても、次の情報はパージされません。
すべてのリシーケンサ・タイプの失敗したメッセージ
すべてのリシーケンサ・タイプの実行中のメッセージ
標準リシーケンサのグループ情報
ベスト・エフォート・リシーケンサとFIFOリシーケンサの準備完了以外の状態のグループ
|
注意: Oracle Mediatorリシーケンサのパージ・スクリプトは、最初にメッセージをパージし、次にグループに移動します。mediator_resequencer_message表にグループのメッセージがある場合は、グループを削除できません。 |
前述の説明は、インスタンスのトラッキングが有効か無効かに関係なく、パージ・スクリプトのループ処理とパラレル処理の両方について記載しています。シーケンス・グループをパージする前に、グループに関連付けられているすべてのメッセージが処理されることを確認するチェックが実行されます。
次に、リシーケンサ表で使用されるグループ状態コードのリストを示します。
0: 準備完了
1: ロック
2: エラー
4: タイムアウト
6: グループ・エラー
次に、リシーケンサ表で使用されるメッセージ状態コードのリストを示します。
0: 準備完了
1: ロック
2: 完了
3: エラー
4: タイムアウト(無視されます)
5: 中断
特定のSOAコンポジット・アプリケーションのインスタンスをパージし、その他のコンポジットのインスタンスはパージせずに残すことができます。このアクションを使用して、大量または保存期間が長い特性のために、特定のフローを他のフローより頻繁にパージできます。
パージ・スクリプトには、COMPOSITE_DNに基づいてパージするためのオプションが含まれています。COMPOSITE_DNに基づくパージは、COMPOSITE_NAMEおよびCOMPOSITE_REVISIONパラメータとの併用がサポートされています。
パージ・ロジックは、COMPOSITE_IDではなくフロー(ECID)に基づいています。したがって、目的のCOMPOSITE_DN以外に、同じECIDを共有している他のコンポジットが削除されます。次に示すシナリオが発生する場合があります。
コンポジット・インスタンスはクローズされますが、フローはオープンしたままになります。
コンポジットAがコンポジットBをコールするシナリオでは、パージにより、コンポジットAのインスタンスが削除の対象となります。ただし、コンポジットAのインスタンスがクローズされ、対応するコンポジットBのインスタンスがオープンしたままの場合があります。したがって、全体的なフローがオープン状態にあり、コンポジットAのインスタンスは(クローズしたとしても)パージされません。
コンポジット・インスタンスがクローズされ、フローもクローズされます。
コンポジットAがコンポジットBを再度コールします。パージにより、コンポジットAのインスタンスが削除の対象となります。したがって、コンポジットAがクローズされ、コンポジットBもクローズされている場合は、フロー全体がクローズされているため、コンポジットAおよびBの両方のインスタンスがパージされます。
これらのシナリオにより、フローの一貫性が維持されます。
COMPOSITE_NAMEおよびCOMPOSITE_REVISIONパラメータの詳細は、第9.3.1項「ループしたパージ・スクリプト」および第9.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が使用されます。
|
注意: 完全または部分的なパーティション化を実行する前に、パージ・スクリプトを実行してください。 |
パーティション化は、デフォルトでは構成されていません。手動で実行する必要があるインストール後ステップです。データベースのパーティション化を実装することにした場合は、いくつかの初期構成タスクを1回のみ実行する必要があります。
この章の情報に従がって、パーティション化するグループを決定します。
それらのグループごとに、パーティション化する必要がある各グループに一部の必須表があることを念頭に、パーティション化する表を決定します。
グループごとに、パーティション間隔を決定します。
Oracle SOA Suiteスキーマをパーティション化するパーティション・スクリプトを作成します。スクリプトは提供されないため、各DBAに、各自の環境に適したパーティション・スクリプトを作成する責任があります。
パージ・スクリプトを編集し、パーティション化した表への参照を削除します。
DBAがパーティションおよび同一レベル・パーティション化された依存表を削除するタイミングを決定するために、検証スクリプトが提供されています。検証スクリプトでは、長時間実行されているアクティブなインスタンスの存在も識別されます。その後、これらのインスタンスを別のパーティションに移動し、元のパーティションを削除できます。
|
注意: 検証スクリプトではパーティションが削除できることを確認するのみであり、パーティションを削除しません。 |
この項では、パーティション化の制約について説明し、コンポーネント表、コンポーネント表が属するグループおよびそのパーティション・キーのリストを示します。
次に示す表のパーティション化の制約に注意してください。
パーティション化のアプローチには、次の選択肢があります。
部分的なパーティション化: パーティション化を増加率が高い特定の表に制限します。表9-3に、パーティション化可能なマスター表および依存表を示します。
表9-3 部分的なパーティション化
| マスター表 | マスター表の依存表 |
|---|---|
|
|
|
|
|
|
|
|
なし |
|
|
|
|
|
なし |
表9-3のいずれの表も、次の制限に従ってパーティション化できます。
依存表をパーティション化する場合は、そのマスター表もパーティション化する必要があります。
すべての表は、同じ日付範囲と同じ名前に従って同一レベル・パーティション化される必要があります。
COMPOSITE_INSTANCE表は、常にパーティション化します。いずれかのコンポジットの「監査レベル」プロパティが「開発」または「本番」に設定されている場合、この制約は必須です。検証スクリプトは、そのパーティション内でアクティブなコンポジット・インスタンスに基づいて、アクティブなフローをチェックします。したがって、COMPOSITE_INSTANCE表がパーティション化されていない場合、すべての表の同一レベル・パーティション化に基づく完全な検証スクリプト・ロジックは機能しません。
グループやコンポーネントに関係なく、パーティション化されたすべての表では、同じ時間範囲およびパーティションIDが使用されます。
グループ1: コンポジットのエンドツーエンド・フロー・トレースに直接関係する表が含まれます。表の大多数がこのグループに該当します。
グループ1A: フロー・トレースに直接関係しない表の小規模なセットが含まれます(REJECTED_MESSAGEなど)。
グループ2: グループ1とグループ1Aの表の複数の表に依存する表の小規模なセットが含まれます。グループ2の検証スクリプトを実行する前に、最初にグループ1の検証スクリプトを実行してグループ1のパーティションを削除する必要があります。
|
注意: グループ1と1Aは、検証スクリプト内では結合されています。検証スクリプトを実行する場合に、この分類に関する知識は必要ありません。 |
表9-4 コンポーネント: SOAインフラストラクチャ
| 表 | レンジ・パーティション・キー | グループ |
|---|---|---|
|
|
|
1 |
|
|
|
1 |
|
|
|
1 |
|
|
|
1 |
|
|
|
1 |
|
|
|
1A |
|
|
|
1A |
|
|
|
2 |
|
|
|
2 |
表9-5 コンポーネント: Oracle BPEL Process Manager
| 表 | レンジ・パーティション・キー | グループ |
|---|---|---|
|
|
|
1 |
|
|
|
1 |
|
|
|
1 |
|
|
|
1 |
|
|
|
1 |
|
|
|
1 |
|
|
|
1 |
|
|
|
1 |
|
|
|
1 |
|
|
|
1 |
|
|
|
1A |
|
|
|
1A |
|
|
|
1A |
|
|
|
2 |
表9-6 コンポーネント: Oracle Mediator
| 表名 | レンジ・パーティション・キー | グループ |
|---|---|---|
|
|
|
1 |
|
|
|
1 |
|
|
|
1 |
|
|
|
1 |
|
|
|
1A |
|
|
|
2 |
表9-7 コンポーネント: ヒューマン・ワークフロー
| 表 | レンジ・パーティション・キー | グループ |
|---|---|---|
|
|
|
1 |
|
|
|
1 |
|
|
|
1 |
|
|
|
1 |
|
|
|
1 |
|
|
|
1 |
|
|
|
1 |
|
|
|
1 |
|
|
|
1 |
|
|
|
1 |
|
|
|
1 |
|
|
|
1 |
|
|
|
1 |
|
|
|
1 |
|
|
|
1 |
|
|
|
1 |
|
|
|
1 |
|
|
|
1 |
表9-8 コンポーネント: Oracle B2B
| 表 | レンジ・パーティション・キー | グループ |
|---|---|---|
|
|
|
1 |
|
|
|
1 |
|
|
|
1 |
|
|
|
1 |
|
|
|
1 |
表9-9 コンポーネント: 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ファイルはこのディレクトリに生成されます。
ストアド・プロシージャを実行するために、クライアント・スクリプト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という名前のログ・ファイルにエラーがないかチェックします。長時間実行されているアクティブなインスタンスがある場合は、第9.4.6項「別のパーティションへの長時間実行されているアクティブなインスタンスの移動」を参照してください。
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 B2B表に外部キー制約が存在することによって発生する問題があります。パーティションを削除する場合にB2Bパーティションのパージが起動されるとき、パーティションを削除する前に外部キー制約を無効化し、後で有効化する必要があります。このアクションを実行するには、前述の手順の適切なステップで、PL/SQLプロシージャb2b_disable_constraintsおよびb2b_enable_constraintsを実行する必要があります。これらのプロシージャでは外部キーが有効化および無効化されるため、稼働中のシステムでは実行しないことをお薦めします。 |
検証スクリプトは、パーティションにアクティブなインスタンスがあるかどうかをチェックします。アクティブなインスタンスがない場合は、パーティションを削除できます。しかし、パーティションには長時間実行されているアクティブなインスタンスが存在することがあります。これらのアクティブなインスタンスがあると、パーティションは削除されません。この問題を回避するために、長時間実行されているインスタンスを別のパーティションに移動できます。
Oracleデータベースには、パーティション間での行の移動を有効または無効にするためのオプションが用意されています。パーティション表を作成または変更する際は、行移動句(ENABLE ROW MOVEMENTまたはDISABLE ROW MOVEMENTのいずれか)を指定できます。この句は、キーが更新された場合の新しいパーティションへの行の移動を有効または無効にします。このオプションによって、パーティションの削除を阻止する長時間実行されているプロセスを処理できます。
検証スクリプトでは、合計インスタンス数、オープン・インスタンス数およびパーティション内のオープン・インスタンスの割合が提供されます。この情報に基づいて、行移動プロシージャの実行が選択可能になります。これによりターゲット表のパーティション・キーが更新され、これらのインスタンスの別のパーティションへの行移動が順に開始されます。パーティション化されたすべての表からアクティブなインスタンスすべてが別のパーティションに移動した後は、ターゲット・パーティションを削除できます。
|
注意:
|
長時間実行されているインスタンスを別のパーティションに移動する手順は、次のとおりです。
グループ1の検証スクリプトを実行します。このスクリプトの説明は、第9.4.4項「検証スクリプトの実行」を参照してください。
ログ・スクリプトをチェックして、パーティションの削除を阻止するアクティブなインスタンスがあるかどうかを確認します。
行移動プロシージャを実行します。ステップ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は、パーティション・キー列を更新する新しい日付です。
第9.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に基づいて)削除します。
一部のコンポーネントがパーティション化され、他のコンポーネントがパーティション化されていない環境の場合、パーティション化されていないデータ・セットは、第9.3項「パージ・スクリプトを使用した大量のインスタンスの削除」で説明したパージ・スクリプトを使用してパージする必要があります。
たとえば、ヒューマン・ワークフローがパーティション化されておらず、他のコンポーネントがパーティション化されているとします。検証スクリプトでは、すべてのSOAパーティションがパーティションの削除コマンドを使用して削除可能とレポートされます。ただし、ヒューマン・ワークフローの各表は、ループ/パラレル・パージ・スクリプトを使用してパージされるまで、ワークフロー・データを引き続き保持します。
