ヘッダーをスキップ
Oracle® Fusion Middleware Oracle SOA SuiteおよびOracle Business Process Management Suite管理者ガイド
11g リリース1 (11.1.1.5.0)
B55916-05
  ドキュメント・ライブラリへ移動
ライブラリ
製品リストへ移動
製品
目次へ移動
目次
索引へ移動
索引

前
 
次
 

9 データベース増分の管理

この章では、SOAコンポジット・アプリケーション・インスタンスのパージ・スクリプトおよびコンポーネント・データベース表のパーティション化の両方を使用して、データベース内のデータの増加を管理する方法について説明します。

この章の内容は、次のとおりです。


注意:

表のパーティション化は高度なデータベース・タスクであるため、熟練したデータベース管理者(DBA)のみが実行する必要があります。

9.1 データベース増分の管理の概要

Oracle SOA Suiteデータベースのデータ量が増加して非常に大きくなると、データベースのメンテナンスが困難になる場合があります。この課題に対処するために、データベース増分を管理する次の2通りの方法があります。

9.1.1 パージ・スクリプトを使用した大量のインスタンスの削除

Oracle Enterprise Manager Fusion Middleware Controlで数千のインスタンスを削除すると時間がかかるため、トランザクション・タイムアウトが発生することがあります。かわりに、インスタンスおよび拒否メッセージの削除にパージ・スクリプトを使用できます。パージ・スクリプトはRCU_HOME/rcu/integration/soainfra/sql/soa_purgeにあります。

データベースのパーティション化は熟練したDBAに適したタスクであるため、ほとんどのOracle SOA Suiteのインストール環境では、パージ・スクリプトが適切です。スキーマが大きく増加し、パージ・スクリプトではパフォーマンス・ニーズを満たすことができなくなった場合に、表のパーティション化の使用を検討してください。

パージ・スクリプトの詳細は、第9.3項「パージ・スクリプトを使用した大量のインスタンスの削除」を参照してください。

9.1.2 コンポーネント・データベース表のパーティション化

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

注意:

  • DBAは、特に、ラージ・オブジェクト(LOB)セグメントがある表について、ハッシュ・サブパーティションの適用を検討することがあります。これは最高水位(HW)エンキューの競合への対応に役立つ場合があります。

  • 単調に増加する主キー(CIKEYなど)に対してグローバル・ハッシュ索引を使用すると、ブロックの競合が緩和されることがあります。


9.1.2.1 参照整合性および同一レベル・パーティション化

パフォーマンス上の理由から、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はマスター表と詳細表が同じ間隔でレンジ・パーティション化されていることを確認する必要があります。この章の後の各項で、いくつかの例を示します。


注意:

実際のサイトでは、古いパーティションについては参照整合性を考慮する必要がないと判断することがあります。例として、サイトに十分なディスク領域があるために、古いデータを格納することが許容されている場合や、参照されないデータを依存表に保管しておいても、特に悪影響がない場合をあげることができます。

9.1.2.2 パーティション・キーの選択の概要

スキーマのパーティション・キーを選択する場合は、次の要素を考慮します。

  • 参照整合性の状態(完了など)を伝達するか、または暗黙的に示すこと

  • メンテナンス操作のための、時間間隔でのレンジ・パーティション化が可能であること

  • 参照されないデータが生じる可能性がある行の移動を回避するために静的であること

  • 表のメンテナンス操作を実行する場合に行が移動されないように、静的であること

  • パーティション・プルーニングによってコンソール問合せに対するパフォーマンス上の利点がもたらされること

9.2 パージおよびパーティション化の方法の開発

この項では、デハイドレーション・ストアのパージまたはパーティション化(あるいはその両方)を行う場合に実行できる、アクション・プランの主なポイントを要約します。パージおよびパーティション化はオプションです。Oracle SOA Suiteではこのことは必須ではなく、データによって消費される領域が多すぎる場合、または、別の理由でデータを除去する場合にのみ必要となります。

スキーマのサイズを削減するには、主に、次の3通りの方法があります。

最初の2つの場合では、同じパージ・スクリプトが使用されます。パーティション化する場合でも、パーティション化された表をコメント・アウトするためにパージ・スクリプトを編集する必要があります。

パージ・スクリプトでは、BPEL表から行を削除するために標準のSQL DELETE文を使用します。ほとんどのサイトではこれで十分です。ただし、サイトによっては蓄積されたデータが多すぎて、パージ・スクリプトの実行時間が非常に長くなることがあります。このような場合は、パーティション化の方がより適切な解決策となります。ただし、パーティション化によって非常に多くのデータベース・メンテナンス作業が発生することがトレードオフとなります。また、パーティション化は高度な技術であり、知識のあるDBAが必要となります。一方、パージ・スクリプトは簡単に実行でき、かつ、DBAの専門的な知識を必要としません。

入力メッセージ、データベース増分率およびパージ・プロセスでパージされるデータ量の概要を確認します。入力レートとパージ・レートが同じである場合は、通常のパージで十分です。これ以外の場合、パーティション化を検討します。

パーティション化を使用する場合、ディスク領域を追加し、最終的にパーティションを削除することをお薦めします。ただし、このことによってディスク容量の管理や適切なパーティション・サイズの決定などの追加要件が発生します。パーティション化を使用し、かつ、ディスク領域を解放するためにパージ・スクリプトに依存することは避けてください。


注意:

環境でパージ・スクリプトのみを使用する場合は、この項の残りの説明をスキップできます。パーティション化を使用することを計画する場合にのみ、この項を読み進めてください。

9.3 パージ・スクリプトを使用した大量のインスタンスの削除

Oracle Enterprise Manager Fusion Middleware Controlで、SOAコンポジット・アプリケーションの「インスタンス」ページの「オプションを指定して削除」ボタンを使用して数千のインスタンスを削除すると、時間がかかり、トランザクション・タイムアウトが発生する場合があります。かわりに、インスタンスを削除するためのパージ・スクリプトを使用します。パージ・スクリプトに関する次の詳細情報に注意してください。

次の各項では、スクリプトを使用する方法の例を示します。


注意:

  • 11g リリース1 (11.1.1.4)よりも前のリリースで提供されているpurge_soainfra_oracle.sql PL/SQLスクリプトを使用する場合、Oracleデータベースでのみこのスクリプトがサポートされていることに注意してください。Microsoft SQL ServerまたはIBM DB2データベースでは、purge_soainfra_oracle.sqlパージ・スクリプトまたはリリース11g リリース1 (11.1.1.4以上)で提供される新しいパージ・スクリプトによるパージ・スクリプトのサポートがありません。Oracleデータベースのみがサポートされます。

  • 11.1.1.4よりも前のリリースで提供されたpurge_soainfra_oracle.sql PL/SQLパージ・スクリプトは推奨されなくなりました。このスクリプトの既存ユーザーである場合、11g リリース1 (11.1.1.4以上)のデータベースに対して使用を継続できます。ただし、11g リリース1 (11.1.1.4)から、このスクリプトは同梱されていません。11g リリース1 (11.1.1.4以上)に付属するパージ・スクリプトを使用することをお薦めします。

  • 11g リリース1 (11.1.1.3)から11g リリース1 (11.1.1.4)または11g リリース1 (11.1.1.5)にアップグレードする場合、パージ設定スクリプトは、必ず11.1.1.4 RCUまたは11.1.1.5 RCUロケーション(最新のパージ詳細が格納されている)からそれぞれ実行します。アップグレードの詳細は、『Oracle Fusion Middleware Oracle SOA Suite、WebCenterおよびADFアップグレード・ガイド』を参照してください。


9.3.1 ループしたパージ・スクリプト

マスター・パージ・スクリプトには、バッチによるパージを実行できるループ構文が含まれています。また、このスクリプトにはmax_runtimeパラメータを指定して、このパラメータの値を超過するとループが停止されるようにすることもできます。

マスター・スクリプトはSOAデータベース表のパージを実行します。delete_instancesプロシージャを使用してSOAデータベース表をパージできます。


注意:

パージするインスタンスが多い場合は、max_runtimeを高い値に設定します。この場合、スクリプトが終了するまでの待機時間が長くなることが予想されます。より短い時間でパージ・スクリプトを終了させるには、小さいバッチ・サイズを使用します。

9.3.1.1 delete_instancesプロシージャ

インスタンスを削除するには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
                   );

表9-1で、スクリプトのパラメータについて説明します。

表9-1 delete_instancesプロシージャのパラメータの説明

パラメータ 説明

min_creation_date

コンポジット・インスタンスの開始作成日。

max_creation_date

コンポジット・インスタンスの終了作成日。

batch_size

パージのループに使用されるバッチ・サイズ。デフォルト値は20000です。

max_runtime

パージ・スクリプトがループを終了する有効期限。デフォルト値は60です。この値は分で指定します。

retention_period

保存期間はBPELプロセス・サービス・エンジンによってのみ使用されます(作成時間パラメータの使用に追加して)。この機能は他のコンポーネントに拡張されません。

このパラメータは、cube_instance表のレコードをチェックして削除します。このパラメータの値はmax_creation_date以上である必要があります。デフォルト値はnullです。

BPELインスタンス(cube_instance)のmodify_dateに基づいてコンポジット・インスタンスを保存する場合は、保存期間を指定します。

この例では、BPELインスタンス表のmodify_date (コンポジットのcreated_dateとは異なる場合がある)は、フィルタ処理の第2レベルとして使用されています。

min_creation_date = 1st June 2011 
      max_creation_date = 30  June 2011
      retention_period = 1st July 2011 

これにより、コンポジットのcreation_time2011年6月1日から2011年6月30日の範囲にあり、cube_instancemodify_date2011年7月1日より前であるすべてのコンポジット・インスタンスが削除されます。

purge_partitioned_component

ユーザーはパーティション化されたデータを削除するために同じパージを起動できます。デフォルト値はfalseです。



注意:

retention_periodに値を指定しない場合、このプロパティの値はmax_creation_dateの値にデフォルトで設定されます(つまり、retention_periodnullに等しい場合、retention_period = max_creation_date)。この結果は、第9.3.2項「dbms_schedulerを使用したパラレル・スクリプトでのループしたパージ」で説明されているスクリプト・パラメータにも適用されます。

9.3.2 dbms_schedulerを使用したパラレル・スクリプトでのループしたパージ

このスクリプトは、第9.3.1項「ループしたパージ・スクリプト」で説明されているループしたパージ・スクリプトと機能的に同じです。ただし、このスクリプトでは、各ジョブがサブセット・データを処理する複数のパージ・ジョブを生成するためのdbms_schedulerパッケージを使用します。

SOAデータベース表をパージするには、次の手順を使用します。


注意:

複数のCPUを持つホストがある場合、パラレル・スクリプトを使用することが役立ちます。ただし、パラレル・スクリプトはオフピーク時にのみ有効化することをお薦めします。さらに、オフピーク時にデータをパージするとき、大量のデータをパージする前に索引を削除し、後で索引を追加して戻すことをお薦めします。これにより、パージ処理が高速化され、索引のバランスを維持できます。

9.3.2.1 パラレルでのdelete_instancesプロシージャ

インスタンスを削除するには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)

表9-2で、スクリプトのパラメータについて説明します。

表9-2 パラレルでのdelete_instancesプロシージャのパラメータの説明

パラメータ 説明

min_creation_date

コンポジット・インスタンスの開始作成日。

max_creation_date

コンポジット・インスタンスの終了作成日。

batch_size

パージのループに使用されるバッチ・サイズ。デフォルト値は20000です。

max_runtime

パージ・スクリプトがループを終了する有効期限。デフォルト値は60です。この値は分で指定します。

retention_period

保存期間はBPELプロセス・サービス・エンジンによってのみ使用されます(作成時間パラメータの使用に追加して)。デフォルト値はnullです。このパラメータの詳細は、表9-1を参照してください。

DOP

スケジュールするパラレル・ジョブの数を定義します。デフォルト値は4です。

max_count

処理される行数を定義します(削除される行数ではありません)。大規模なtemp表が作成され、データに基づいてパージするジョブがスケジュールされます。これはパージする行数の最大値であり、デフォルトで100万に設定されます。デフォルト値は1000000です。

purge_partitioned_component

ユーザーはパーティション化されたデータを削除するために同じパージを起動できます。デフォルト値はfalseです。


9.3.3 パージの状態

次の状態のインスタンスは、パージ・スクリプトでパージされます。

  • 正常に完了しました

  • フォルト

  • ユーザーによって終了されました

  • 失効

  • 不明(インスタンス・トラッキングが無効)

次のインスタンス状態のパージはサポートされていません。

  • BPELプロセス・サービス・エンジン・レベルまたはSOAコンポジット・アプリケーション・レベルでのリカバリを保留中のインスタンス

  • 実行中のインスタンス

このようなインスタンスをパージするには、まずパージ・スクリプトによってサポートされるインスタンス状態のいずれかに移行する必要があります。

9.3.4 パージ・スクリプトの実行

この項では、パージ・スクリプトを実行する方法について説明します。

パージ・スクリプトを実行するには、次の手順を実行します。

  1. SQL*Plusで、データベースAS SYSDBAに接続します。

    CONNECT SYS AS SYSDBA
    
  2. 次のSQLコマンドを実行します。

    GRANT EXECUTE ON DBMS_LOCK to USER;
    GRANT CREATE ANY JOB TO USER;
    

    ここで、USERはスクリプトを実行するためのsoainfraアカウントです。これらの特権は、スクリプトを実行するために必要です。

  3. RCU_HOME/rcu/integration/soainfra/sql/soa_purgeでメイン・パージ・スクリプトを実行してパージ・スクリプトをロードします。

    パラレル・パージの場合、パラレル・パージによって生成されたジョブからのデバッグ・ログは、SOA_PURGE_DIRという名前のディレクトリに作成されるファイルに記録されます。このディレクトリはOracleデータベースからアクセスできる必要があります。

  4. SOA_PURGE_DIRを作成し、soainfraユーザーに書込み権限を付与します。

    mkdir -p /tmp/purgelog
    CREATE OR REPLACE DIRECTORY SOA_PURGE_DIR AS 'SERVER_DIRECTORY'
    

    ここで、SERVER_DIRECTORYは作成するディレクトリ('/tmp/purgelog/'など)です。ディレクトリ・パスを囲む一重引用符は必須です。

  5. スクリプトをデバッグ・モードで実行する場合、common/debug_on.sqlを実行し、SQL*Plusでserveroutonに設定します。このステップはオプションです。

    SET SERVEROUTPUT ON
    

    生成されたジョブからのログは、ステップ4で作成されたディレクトリに記録されます(ジョブごとに別のファイル)。残りのログはstdout(または構成された場合はスプール・ファイル)に表示されます。

    パージには次の2つのオプションがあります。

    • ループしたパージ

    • パラレル・パージ

  6. 次に示すようにパージ・スクリプトを実行します。両方のオプションに対して例を示します。

    1. ループしたパージの場合

      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;
        /
      
    2. パラレル・パージの場合

      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;
      

9.4 コンポーネント表のパーティション化

次のコンポーネントのランタイムおよびスキーマ・コードは、フロー作成日付列をトランザクション表に格納するように変更されました。

CPST_CREATED_DATE列には、インスタンス・トラッキング・コードによって移入されたフロー作成日時が含まれています。これは、正規化されたメッセージ・プロパティoracle.integration.platform.instance.CommonConstants.COMPOSITE_INSTANCE_CREATED_TIMEとして使用できます。

すべてのSOAコンポーネントは同じパーティション・キーでパーティション化されます。これらのパーティション化されたコンポーネントでは同じ時間範囲とパーティションIDが使用されます。

9.4.1 パーティションの構成

パーティション化は、デフォルトでは構成されていません。手動で実行する必要があるインストール後ステップです。データベースのパーティション化を実装することにした場合は、いくつかの初期構成タスクを1回のみ実行する必要があります。

  • この章の情報に従がって、パーティション化するグループを決定します。

  • それらのグループごとに、パーティション化する必要がある各グループに一部の必須表があることを念頭に、パーティション化する表を決定します。

  • グループごとに、パーティション間隔を決定します。

  • Oracle SOA Suiteスキーマをパーティション化するパーティション・スクリプトを作成します。スクリプトは提供されないため、各DBAに、各自の環境に適したパーティション・スクリプトを作成する責任があります。

  • パージ・スクリプトを編集し、パーティション化した表への参照を削除します。

9.4.2 検証スクリプトの概要

DBAがパーティションおよび同一レベル・パーティション化された依存表を削除するタイミングを決定するために、検証スクリプトが提供されています。


注意:

検証スクリプトではパーティションが削除できることを確認するのみであり、パーティションを削除しません。

9.4.3 コンポーネント表

この項では、コンポーネント表、コンポーネント表が属するグループおよびコンポーネント表のパーティション・キーを示します。

次に示す表のパーティション化の制約に注意してください。

  • パーティション化するかどうかは、コンポーネントの粒度でのみ選択できます。コンポーネントごとに、すべての表をパーティション化するか、または表を一切パーティション化しないようにする必要があります。たとえば、Oracle BPEL Process Managerの表をパーティション化し、他のコンポーネントはパーティション化しないままにできます。ただし、この場合は、BPELコンポーネントに関連するすべての表をパーティション化する必要があります。

  • グループやコンポーネントに関係なく、パーティション化されたすべての表では、同じ時間範囲およびパーティションIDが使用されます。

表9-3から表9-8までは、3つのグループに分けられます。

  • グループ1: コンポジットのエンドツーエンド・フロー・トレースに直接関係する表が含まれます。表の大多数がこのグループに該当します。

  • グループ1A: フロー・トレースに直接関係しない表の小規模なセットが含まれます(REJECTED_MESSAGEなど)。

  • グループ2: グループ1とグループ1Aの表の複数の表に依存する表の小規模なセットが含まれます。グループ2の検証スクリプトを実行する前に、最初にグループ1の検証スクリプトを実行してグループ1のパーティションを削除する必要があります。


    注意:

    グループ1と1Aは、検証スクリプト内では結合されています。検証スクリプトを実行する場合に、この分類に関する知識は必要ありません。

表9-3 コンポーネント: SOAインフラストラクチャ

レンジ・パーティション・キー グループ

COMPOSITE_INSTANCE

PARTITION_DATE

1

REFERENCE_INSTANCE

CPST_PARTITION_DATE

1

COMPOSITE_INSTANCE_FAULT

CPST_PARTITION_DATE

1

COMPOSITE_SENSOR_VALUE

CPST_PARTITION_DATE

1

COMPONENT_INSTANCE

CPST_PARTITION_DATE

1

REJECTED_MESSAGE

CREATED_TIME

1A

REJECTED_MSG_NATIVE_PAYLOAD

RM_PARTITION_DATE

1A

INSTANCE_PAYLOAD

CREATED_TIME

2

COMPOSITE_INSTANCE_ASSOC

CREATED_TIME

2


表9-4 コンポーネント: Oracle BPEL Process Manager

レンジ・パーティション・キー グループ

CUBE_INSTANCE

CPST_INST_CREATED_TIME

1

CI_INDEXES

CI_PARTITION_DATE

1

CUBE_SCOPE

CI_PARTITION_DATE

1

DOCUMENT_CI_REF

CI_PARTITION_DATE

1

AUDIT_TRAIL

CI_PARTITION_DATE

1

AUDIT_DETAILS

CI_PARTITION_DATE

1

DLV_SUBSCRIPTION

CI_PARTITION_DATE

1

WORK_ITEM

CI_PARTITION_DATE

1

AUDIT_COUNTER

CI_PARTITION_DATE

1

WI_FAULT

CI_PARTITION_DATE

1

DLV_MESSAGE

RECEIVE_DATE

1A

HEADERS_PROPERTIES

DLV_PARTITION_DATE

1A

DOCUMENT_DLV_MSG_REF

DLV_PARTITION_DATE

1A

XML_DOCUMENT

DOC_PARTITION_DATE

2


表9-5 コンポーネント: Oracle Mediator

表名 レンジ・パーティション・キー グループ

MEDIATOR_INSTANCE

COMPOSITE_CREATION_DATE

1

MEDIATOR_CASE_INSTANCE

MI_PARTITION_DATE

1

MEDIATOR_CASE_DETAIL

MI_PARTITION_DATE

1

MEDIATOR_AUDIT_DOCUMENT

MI_PARTITION_DATE

1

MEDIATOR_DEFERRED_MESSAGE

CREATION_TIME

1A

MEDIATOR_PAYLOAD

CREATION_TIME

2


表9-6 コンポーネント: ヒューマン・ワークフロー

レンジ・パーティション・キー グループ

WFTASK

COMPOSITECREATEDTIME

1

WFTask_TL

COMPOSITECREATEDTIME

1

WFTaskHistory

COMPOSITECREATEDTIME

1

WFTaskHistory_TL

COMPOSITECREATEDTIME

1

WFComments

COMPOSITECREATEDTIME

1

WFMessageAttribute

COMPOSITECREATEDTIME

1

WFAttachment

COMPOSITECREATEDTIME

1

WFAssignee

COMPOSITECREATEDTIME

1

WFReviewer

COMPOSITECREATEDTIME

1

WFCollectionTarget

COMPOSITECREATEDTIME

1

WFRoutingSlip

COMPOSITECREATEDTIME

1

WFNotification

COMPOSITECREATEDTIME

1

WFTaskTimer

COMPOSITECREATEDTIME

1

WFTaskError

COMPOSITECREATEDTIME

1

WFHeaderProps

COMPOSITECREATEDTIME

1

WFEvidence

COMPOSITECREATEDTIME

1

WFTaskAssignmentStatistic

COMPOSITECREATEDTIME

1

WFTaskAggregation

COMPOSITECREATEDTIME

1


表9-7 コンポーネント: Oracle B2B

レンジ・パーティション・キー グループ

B2B_BUSINESS_MESSAGE

CPST_INST_CREATED_TIME

1

B2B_APP_MESSAGE

CPST_INST_CREATED_TIME

1

B2B_WIRE_MESSAGE

CPST_INST_CREATED_TIME

1

B2B_DATA_STORAGE

CPST_INST_CREATED_TIME

1

B2B_EXT_BUSINESS_MESSAGE

CPST_INST_CREATED_TIME

1


表9-8 コンポーネント: Oracle BPM Suite

レンジ・パーティション・キー グループ

BPM_AUDIT_QUERY

CI_PARTITION_DATE

1

BPM_MEASUREMENT_ACTIONS

CI_PARTITION_DATE

1

BPM_MEASUREMENT_ACTION_EXCEPS

CI_PARTITION_DATE

1

BPM_CUBE_AUDITINSTANCE

CI_PARTITION_DATE

1

BPM_CUBE_TASKPERFORMANCE

CI_PARTITION_DATE

1

BPM_CUBE_PROCESSPERFORMANCE

CI_PARTITION_DATE

1


9.4.4 検証スクリプトの実行

DBAがパーティションおよび同一レベル・パーティション化された依存表を削除するタイミングを判別するために、検証スクリプトが提供されています。検証スクリプトはRCU_HOME/rcu/integration/soainfra/sql/verifyにあります。

検証スクリプトを実行するには、次の手順を実行します。

  1. SQLコマンドPART_DIRでディレクトリを作成します。例:

    CREATE DIRECTORY PART_DIR AS '/tmp/verify'
    
  2. soainfraユーザーにこのディレクトリの書込み権限を付与します。ログおよびSQLファイルはこのディレクトリに生成されます。

  3. ストアド・プロシージャを実行するために、クライアント・スクリプトsoa_exec_verify.sqlを使用できます。soa_exec_verify.sqlを編集し、検証が必要なパーティション名を配列mySoa_drv_listに入力します。

    1. 関数verify_soa.verify_1を実行するには、パラメータとして1を渡します。

    2. 関数verify_soa.verify_2を実行するには、パラメータとして2を渡します。

  4. PART_DIRディレクトリに生成されるログおよびSQLファイルを確認します。


注意:

検証スクリプトはビジネス・ルール用に提供されていません。

9.4.5 パーティションの検証と削除

パーティションを検証して削除するには、次の手順を実行します。

  1. 関数verify_soa.verify_1を実行します。

  2. PART_DIRフォルダのSOA_PARTITION_NAME_LOG_1という名前のログ・ファイルにエラーがないかチェックします。

  3. PART_DIRフォルダに生成されたSOA_PARTITION_NAME_RESULT_1.sqlという名前のスクリプトを使用して、削除可能なパーティションを削除します。

  4. verify_soa.verify_2を実行します。

  5. PART_DIRフォルダのSOA_PARTITION_NAME_LOG_2という名前のログ・ファイルにエラーがあるかどうかをチェックします。

  6. PART_DIRフォルダに生成されたSOA_PARTITION_NAME_RESULT_2.sqlという名前のスクリプトを使用して、削除可能なパーティションを削除します。


注意:

Oracle B2B表に外部キー制約が存在することによって発生する問題があります。パーティションを削除する場合にB2Bパーティションのパージが起動されるとき、パーティションを削除する前に外部キー制約を無効化し、後で有効化する必要があります。このアクションを実行するには、前述の手順の適切なステップで、PL/SQLプロシージャb2b_disable_constraintsおよびb2b_enable_constraintsを実行する必要があります。これらのプロシージャでは外部キーが有効化および無効化されるため、稼働中のシステムでは実行しないことをお薦めします。

9.4.6 コンポーネントの部分的なパーティション化

一部のコンポーネントがパーティション化され、他のコンポーネントがパーティション化されていない環境の場合、パーティション化されていないデータ・セットは、第9.3項「パージ・スクリプトを使用した大量のインスタンスの削除」で説明したパージ・スクリプトを使用してパージする必要があります。

たとえば、ヒューマン・ワークフローがパーティション化されておらず、他のコンポーネントがパーティション化されているとします。検証スクリプトでは、すべてのSOAパーティションが削除可能とレポートされます。ただし、ヒューマン・ワークフローの各表は、パージ・スクリプトを使用してパージされるまで、ワークフロー・データを引き続き保持します。