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

この章では、Oracle Enterprise Manager Fusion Middleware ControllまたはSQL*Plusでパージ・スクリプトを使用してデータベース内の大量のフロー・インスタンス、アダプタ・レポートおよびフォルト・アラートの増大化を管理する方法、スキーマ表を時間間隔に基づいてレンジ・パーティション化できるようにする表のパーティション化および表を削除することなく実行時の表のすべてのレコードを削除する切捨てスクリプトについて説明します。

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

ノート:

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

データベース増大問題のトラブルシューティングに関する詳細は、「パラレル・パージと表のパーティション化の問題」「表領域の拡張による実行時の問題の回避」および「大量のトランザクションによるデータベース増大の問題の解決」を参照してください。

データベース増分管理戦略の詳細は、「データベース増分管理戦略の策定」を参照してください。

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

Oracle SOA Suiteデータベースのデータ量が増加して非常に大きくなると、データベースのメンテナンスが困難になる場合があります。この課題に対処するため、データベースの増分管理には表15-1に示すようにいくつかの方法が用意されています。

表15-1 データベース増分の戦略

環境 使用 参照先

データベース内の行が100,000を超える小規模な開発インストール

Oracle Enterprise Manager Fusion Middleware Controlの「自動パージ」ページまたはループされるパージ・スクリプト

Oracle Enterprise Manager Fusion Middleware Controlによる大量のインスタンスの削除

または

「SQL*Plusを使用した大量のインスタンスの削除」

1日当たり10GBのデータを生成し、かつ500GB未満のデータを保存する中規模のインストール

Oracle Enterprise Manager Fusion Middleware Controlの「自動パージ」ページまたは最適なスレッド数でスケジュールされたパラレル・パージ

Oracle Enterprise Manager Fusion Middleware Controlによる大量のインスタンスの削除

または

「SQL*Plusを使用した大量のインスタンスの削除」

1日に10GBを超えるデータを生成する、または500GBを超えるデータを保存する大規模なインストール

  • パーティション化(頻度が低く長時間実行されるプロセス)。

  • パラレル・パージとパーティション化の組合せ(数か月に広がる長期間実行プロセス)。たとえば、日次パージと月次のパーティション削除を実行します。

  • Oracle Enterprise Manager Fusion Middleware Controlの「自動パージ」ページ

大量のフロー・インスタンス、アダプタ・レポートおよびフォルト・アラートの削除

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

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

  • テスト・シナリオの再作成および再実行の場合

  • 本番のカスタマイズおよび新規ジョブ定義を保管できるように本番環境からのスキーマを保持する一方で、すべてのインスタンス・データを状態にかかわりなく切り捨てるようにするための、本番環境またはテスト環境クローンの作成

切捨てスクリプト

表削除なしでの実行時表からのレコードの削除

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

この項では、デハイドレーション・ストアのパージおよびパーティション化を行う場合に実行できる、アクション・プランの主なポイントを要約します。パージはあらゆるプランの根幹であり、データによって消費される領域が多すぎる場合、または別の理由でデータを削除する場合に実行します。

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

  • パージ・スクリプト(次のいずれかの方法で実行できます)

    • Oracle Enterprise Manager Fusion Middleware Controlの「自動パージ」ページから自動実行

    • SQL*Plusで手動実行

  • パージ・スクリプトおよびパーティション化(つまり、表パーティションの削除)

  • すべての表のパーティション化

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

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

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

ノート:

パーティション化機能を使用できるのは、Oracle DatabaseでOracle Partitioningオプションを購入した場合のみです。

大量のフロー・インスタンス、アダプタ・レポートおよびフォルト・アラートの削除

フロー・インスタンス、アダプタ・レポートおよびフォルト・アラートは、(Oracle Enterprise Manager Fusion Middleware Controlの「自動パージ」ページから自動で呼び出されるか、SQL*Plusで手動で呼び出す)パージ・スクリプトを使用して削除できます。

次の詳細に注意してください。

  • パージ・スクリプトは、完了したインスタンスまたはエラー状態の(失敗した)インスタンスを削除します。詳細は、「パージの状態」を参照してください。

  • パージ・スクリプトは、処理中のインスタンスまたはリカバリ可能な(リカバリが必要な状態の)インスタンスを削除しません。

  • パージ・スクリプトは、Oracle B2Bを除きすべてのOracle SOA Suite関連の表を削除します。Oracle SOA SuiteおよびOracle B2Bが同一インストールに配置されている場合、Oracle B2Bのパージ・スクリプトも必ず呼び出してください。Oracle SOA SuiteおよびOracle B2Bが別個のインストールに配置されている場合、それぞれの製品スキーマで適切なパージ・スクリプトのみを実行する必要があります。Oracle B2Bのパージの詳細は、『Oracle B2Bの使用』データのパージに関する項およびB2Bコマンドライン・ツールに関する項を参照してください。

  • 12c (12.1.3)以降、Oracle Enterprise Manager Fusion Middleware Controlおよびパージ・スクリプトではMEDIATOR_RESEQUENCER_MESSAGE表およびMEDIATOR_GROUP_STATUS表を削除します。

  • インストーラでデータベース・スケジューラのタイムゾーンを適切に構成する必要があります。そうしないと、パージ・ジョブが予期しない時間に実行される可能性があります。

  • SQL*PlusからまたはOracle Enterprise Manager Fusion Middleware Controlの「自動パージ」ページからパージ・スクリプトを実行して、次の表を削除できます。

    • MEDIATOR_GROUP_STATUS

    • EIS_CONNECTION_DOWN_TIMEおよびMESSAGE_STATISTICS (JCAアダプタ・レポート)。

    • FAULT_ALERT

  • リシーケンス・グループのグループ情報は削除されません。グループには、そのグループの次のシーケンスIDに関する必須情報が含まれています。この情報をパージすると、最初のシーケンスIDからグループを始めることと同じになり、意図に反することになる可能性があります。

次の各項では、Oracle Enterprise Manager Fusion Middleware Controlの「自動パージ」ページまたはSQL*Plusからパージ・スクリプトを呼び出して、フロー・インスタンス、アダプタ・レポートおよびフォルト・アラートを削除する方法について説明します。

ノート:

IBM DB2データベースでは、パージ・スクリプトはサポートされません。

パージの状態

次の状態のインスタンスは、Oracle Enterprise Manager Fusion Middleware Controlまたはパージ・スクリプトを使用してパージします。

  • 正常終了

  • フォルト

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

  • 中断

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

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

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

  • 実行中のインスタンス

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

Oracle Enterprise Manager Fusion Middleware Controlによる大量のインスタンスの削除

Oracle Enterprise Manager Fusion Middleware Controlの「自動パージ」ページを使用して、より古いフロー・インスタンス、アダプタ・レポートおよびフォルト・アラートを自動的にデータベースから削除するジョブをスケジュールおよび実行します。

ノート:

  • ランタイム環境のパフォーマンスを最適化するために、「自動パージ」ページで自動パージを有効にすることをお薦めします。自動パージの状態は、SOAインフラストラクチャおよび個々のパーティション・レベルの「ダッシュボード」ページの「キー構成」セクションに表示されます。自動パージは、12cの新規インストールで自動的に有効になりますが、アップグレードされた環境では有効になりません。

  • パージ構成を有効化または変更する前に、重要なデータをバックアップするようにしてください。

  • SOA開発者インストール・オプションに含まれるJavaデータベースを使用している場合、「自動パージ」ページは使用できません。truncate_soa_javadb.sqlスクリプトを使用してデータベースをパージします。

  1. 次のいずれかのオプションを使用して、このページにアクセスします。

    SOAインフラストラクチャのメニューから... ナビゲータのSOAフォルダから... 「ダッシュボード」ページの「キー構成」セクションから... 「ダッシュボード」ページの「キー構成」セクションから...
    1. 「SOA管理」「自動パージ」を選択します。

    1. 「soa-infra」を右クリックします。

    2. 「SOA管理」「自動パージ」を選択します。

    1. 「関連リンク」アイコンをクリックします。

    2. 「自動パージ」を選択します。

    1. 「自動パージ」「ステータス」の右側にあるアイコンをクリックします。

    2. 表示されたメッセージで、「自動パージの設定」をクリックします。

    自動パージ・ページが表示されます。

  2. 環境に適した値を選択し、「適用」をクリックします。

    フィールド 説明

    自動パージ・ジョブ

    実行する事前定義済のデータベース・パージ・ジョブを選択します:

    • SOAフロー・パージ・ジョブ1: 平日に適切なスケジュールで(月曜日から金曜日の午前0時に)パージします。このジョブは自動的に有効になります。

    • SOAフロー・パージ・ジョブ2: より積極的な週末のスケジュールで(土曜日と日曜日に)パージします。

    • SOAインメモリー・フロー・パージ・ジョブ: インメモリー・フロー関連レコードをパージします。これにより、データベースに永続化されているインメモリー・インスタンスのみがパージされます。このジョブは、Oracle Enterprise Manager Fusion Middleware ControlのSOA共通プロパティでinMemoryEnvironmenttrueに設定すると有効になります。

    • 統合ワークロード統計パージ・ジョブ: SOAデータベースから統合ワークロード統計(IWS)スナップショット・データをパージします。デフォルトでは、このジョブは毎日午前0時に実行されるようスケジュールされています。IWSレポートの詳細は、「IWSレポートを使用したSOA全体の問題の監視とトラブルシューティング」を参照してください。

    • ヘルス・チェック・パージ・ジョブ: SOAヘルス・チェック・レポートをパージします。SOAヘルス・チェックの詳細は、「SOAヘルス・チェックの使用」を参照してください。

    • SOAコンポーネント状態ベースのフロー・パージ・ジョブ: コンポーネントの状態に基づいて、フローおよび関連表をパージします(他のパージ・ジョブはフロー・インスタンスの状態に基づいて行われます)。これは、フロー・インスタンスの状態が同期されていない場合やオフになっている場合に対処するものです。このジョブは、Oracle Enterprise Manager Fusion Middleware ControlのSOA共通プロパティでCaptureFlowInstanceStatefalseに設定すると有効になります。

      ノート: この選択が12c (12.2.1.4)で使用可能になるのは、パッチ31572611以上をインストールした場合のみです。My Oracle Supportにサインインし、パッチ番号でパッチを検索してダウンロードします。

    ノート: パージ・ジョブは追加できません。

    警告: 自動パージ・ジョブを有効化または無効化する場合は、別のジョブを選択するか、このページから移動する前に、変更内容を保存するか元に戻す必要があります。そうしないと、現在選択しているジョブに対して行った未保存の変更は失われます。

    有効

    選択すると、「自動パージ・ジョブ」リストから選択されたデータベース・パージ・ジョブによる自動データベース・パージが有効になります。

    有効にした時点で、パージ期間が開始します。たとえば、データの保存フィールドに7日間と指定した場合、このチェック・ボックスを再び有効にした日からデータが保存されます。より新しいデータは作成後7日間保存されます。

    カレンダ式アイコン

    クリックすると、ジョブのスケジュール設定構文の例が表示されます。環境に合う構文をコピーして、「ジョブ・スケジュール」フィールドに貼り付け、必要に応じて変更します。「詳細情報」をクリックすると、repeat_interval属性を設定してジョブの頻度を構成する方法に関するドキュメントにアクセスします。

    ジョブ・スケジュール

    インスタンスをパージするジョブ実行スケジュールを指定します。デフォルトのスケジュールでは、毎日午前0時にパージを実行します。これは必須フィールドです。スケジュールを指定するには、有効なカレンダ式を使用します。一般的に使用される式の例を表示するには、「情報」アイコンまたはカレンダ式アイコンをクリックします。スケジュール構文では、大文字と小文字は区別されません。

    パージ・タイプ

    実行するパージ・スクリプトのタイプを選択します。これは必須フィールドです。

    • 単一: バッチによるパージを実行する、単一ループのパージ・スクリプト。

    • パラレル: 機能は、単一ループのパージ・スクリプトと同じです。ただし、このオプションでは、dbms_schedulerパッケージが複数のパージ・ジョブを生成でき、各ジョブがサブセット・データを処理します。

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

    単一(ループ)およびパージ・パラレル・スクリプトの詳細は、「ループされるパージ・スクリプト」および「dbms_schedulerを使用したパラレル・スクリプトでのループされるパージ」を参照してください。

    データの保持

    データを保持する期間(日数)を指定します。ジョブを実行しても、この期間内のデータはパージされません。デフォルト値は7日間です。たとえば、7日間のデータ保持間隔を指定する場合、データは作成されてから7日間、パージから保護されます。システム内にすでに存在する古いデータは、自動パージが有効化されてから7日間保持されます。このプロパティを-1に設定するとデータの保持フィルタを無視できます。

    パージする最大フロー

    1回のジョブ実行でパージするインスタンス・フローの最大数を選択します。

    バッチ・サイズ

    一度に削除するビジネス・フローの最大数を選択します。デフォルト値は20000です。

    このフィールドが表示されるのは、「パージ・タイプ」リストで「パラレル」が選択されている場合です。

    並列度

    パラレルで実行するジョブの数を選択します。デフォルト値は4です。

    このフィールドが表示されるのは、「パージ・タイプ」リストで「パラレル」が選択されている場合です。

  3. システムMBeanブラウザの詳細な構成プロパティを表示して構成するには、「詳細な自動パージ構成プロパティ」をクリックします。

  4. 「PurgeJobDetails」をクリックします。

  5. ジョブを展開して、単一パージおよびパラレル・パージのすべてのプロパティを表示します。単一パージとパラレル・パージのいずれかのパージ・タイプが実行されると、選択したタイプに適切なプロパティ値が実行されます。

    ノート:

    詳細パージ・プロパティを編集する必要がある場合は、最新の注意を払ってください。たとえば、ジョブ名を変更しないでください。

  6. 値を表示または変更して、「適用」をクリックします。

    フィールド 説明

    DOP

    パラレルで実行するジョブの数を定義します。デフォルト値は4です。

    PQS

    パラレル問合せスレーブの数を表示します。さらにスレーブを追加して負荷の高いSQLコマンドのパフォーマンスを向上できます。

    batchSize

    一度に削除できるビジネス・フローの最大数を表示します。デフォルト値は20000です。

    有効

    データベース・パージ・ジョブが有効になっているかどうかを示します。

    executionSchedule

    ジョブのスケジュール設定構文を表示します。

    ignoreState

    trueに設定すると、指定された日付範囲内でオープンおよびクローズされたすべてのインスタンスがパージされます。デフォルト値はfalseです。

    ノート: オープン・インスタンスのパージは、システムを不整合状態にする可能性があるため、このパラメータは慎重に使用してください。

    maxCount

    パージするフローの最大数を表示します。

    maxCreationPeriodDays

    最長の作成期間を日数で表示します。このプロパティは、特定の期間内に作成されたフローを選択するために、minCreationPeriodDaysとともに使用されます。

    maxRuntime

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

    minCreationPeriodDays

    最短の作成期間を日数で表示します。このプロパティは、特定の期間内に作成されたフローを選択するために、maxCreationPeriodDaysとともに使用されます。

    purgePartitionedComponent

    パーティション化された表をパージする必要があるかどうかを示します。trueに設定すると、同じパージ・ジョブが呼び出され、パーティション化されたデータが削除されます。デフォルト値はfalseです。

    ノート: 表は、パーティション化するとDROP文で維持されるため、パージする必要はありません。

    purgeType

    単一またはパラレルのいずれかを表示します。

    retentionPeriodDays

    データを保持する期間(日数)を指定します。パージ・ジョブを実行しても、この期間内のデータはパージされません。

    sqlTrace

    trueに設定すると、SQLトレースが設定されていることを示します。

    SQLトレースの詳細は、『Oracle Database SQLチューニング・ガイド』を参照してください。

    ノート:

    保存期間は時間の粒度では動作しません。そのため、保存期間が1日に設定されている場合、ジョブは完了後24時間以内にパージされないということです。次のパージまで最長48時間かかる可能性があります(つまり、1日の保存期間では、フローが20日の午前12:01に完了した場合、22日の午前12:00までパージされません)。

SQL*Plusを使用した大量のインスタンスの削除

ノート:

Oracle SOA Suiteリリース11gを12cにアップグレードする際、パージ・スクリプトの実行中にアップグレード・アシスタントを起動しないでください。パージが完了するまで待ってから、アップグレード・プロセスを開始してください。アップグレード・アシスタントを使用してスキーマをアップグレードしようとしたときにパージ・スクリプトが実行中であると、アップグレードは失敗します。アップグレードの詳細は、Oracle SOA SuiteおよびOracle Business Process Managementのアップグレードを参照してください。

SQL*Plusでパージ・スクリプトを実行して、より古いフロー・インスタンス、アダプタ・レポートおよびフォルト・アラート・データをデータベースから削除します。パージ・スクリプトには次の2つのタイプがあります。

  • ループされるパージ・スクリプト

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

ループされるパージ・スクリプト

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

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

ノート:

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

delete_instancesプロシージャ

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

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

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

パラメータ 説明

min_creation_date

ビジネス・フロー・インスタンスの最短の作成期間(日数)。

max_creation_date

ビジネス・フロー・インスタンスの最長の作成期間(日数)。

batch_size

削除対象に選択され、単一のループ・パージの1回の実行でコミットされるフローの最大数。デフォルト値は20000です。

max_runtime

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

retention_period

データを保持する期間(日数)を指定します。ジョブを実行しても、この期間内のデータはパージされません。デフォルト値は7日間です。保存期間はフロー全体に基づきます。期間はSCA_FLOW_INSTANCE.UPDATED_TIMEに対して比較されます。

このパラメータは、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

パーティション化された表をパージする必要があるかどうかを示します。trueに設定すると、同じパージ・ジョブが呼び出され、パーティション化されたデータが削除されます。デフォルト値はfalseです。

ノート: 表は、パーティション化するとDROP文で維持されるため、パージする必要はありません。

ignore_state

trueに設定すると、指定された日付範囲内でオープンおよびクローズされたすべてのインスタンスがパージされます。デフォルト値はfalseです。

ノート: オープン・インスタンスのパージは、システムを不整合状態にする可能性があるため、このパラメータは慎重に使用してください。

composite_name

SOAコンポジット・アプリケーションの名前。このパラメータをcomposite_revisionパラメータおよびsoa_partition_nameパラメータとともに使用すると、特定のSOAコンポジット・アプリケーションのインスタンスをパージできます。詳細は、「特定のSOAコンポジット・アプリケーションのインスタンスのパージ」を参照してください。

composite_revision

SOAコンポジット・アプリケーションのリビジョン番号。

soa_partition_name

SOAコンポジット・アプリケーションが格納されているパーティション。

sql_trace

trueに設定すると、このパラメータによって、USER_DUMP_DEST初期化パラメータで指定された宛先にトレース・ファイルを生成するSQLトレースが構成されます。SOA_INFRAユーザーは、ALTER SESSION権限が付与されている必要があります。この権限は、トレースの詳細が収集された後にデータベース管理者が取り消すことができます。

GRANT ALTER SESSION TO SOA_INFRA

ノート: パフォーマンスに影響するため、このパラメータはデバッグのみに使用してください。

PQS

パラレル問合せスレーブの数を表示します。さらにスレーブを追加して負荷の高いSQLコマンドのパフォーマンスを向上できます。

ノート:

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

  • リリース11gから12cにアップグレードしているのではない場合、max_creation_dateおよびmin_creation_dateパラメータはオプションです。パージは、同様にオプションであるretention_periodによって完全に実行できます。

  • パージ・スクリプトのパージは、データベースと表内の既存行のみに制限されます。パージ・スクリプトでランタイム実行を調べる方法はありません。このため、パージ・スクリプトでアクティブな行が削除された直後に、(ignore_stateパラメータをtrueに設定して)自動リカバリを試行することが想定されます。このため、パージの実行後に行が作成されます。SCA_FLOW_INSTANCE表の行はすでに削除されているため、この行は不確定のままになります。

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

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

ノート:

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

delete_instances_in_parallelプロシージャ

インスタンスを削除するには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,
                   ignore_state in boolean,
                   composite_name in varchar2,
                   composite_revision in varchar2,
                   soa_partition_name in varchar2,
                   sql_trace in boolean
                   );

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

表15-3 delete_instances_in_parallelプロシージャのパラメータの説明

パラメータ 説明

min_creation_date

ビジネス・フロー・インスタンスの最短の作成期間(日数)。

max_creation_date

ビジネス・フロー・インスタンスの最長の作成期間(日数)。

batch_size

削除対象に選択されたフローの最大数。デフォルト値は20000です。

max_runtime

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

retention_period

データを保持する期間(日数)を指定します。ジョブを実行しても、この期間内のデータはパージされません。デフォルト値は7日間です。保存期間はフロー全体に基づきます。期間はSCA_FLOW_INSTANCE.UPDATED_TIMEに対して比較されます。デフォルト値はnullです。このパラメータの詳細は、表15-2を参照してください。

DOP

パラレルで実行するジョブの数を定義します。デフォルト値は4です。

max_count

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

purge_partitioned_component

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

ノート: 表は、パーティション化するとDROP文で維持されるため、パージする必要はありません。

ignore_state

trueに設定すると、指定された日付範囲内でオープンおよびクローズされたすべてのインスタンスがパージされます。デフォルト値はfalseです。

ノート: オープン・インスタンスのパージは、システムを不整合状態にする可能性があるため、このパラメータは慎重に使用してください。

composite_name

SOAコンポジット・アプリケーションの名前。このパラメータをcomposite_revisionパラメータおよびsoa_partition_nameパラメータとともに使用すると、特定のSOAコンポジット・アプリケーションのインスタンスをパージできます。詳細は、「特定のSOAコンポジット・アプリケーションのインスタンスのパージ」を参照してください。

composite_revision

SOAコンポジット・アプリケーションのリビジョン番号。

soa_partition_name

SOAコンポジット・アプリケーションが格納されているパーティション。

sql_trace

trueに設定すると、このパラメータによって、USER_DUMP_DEST初期化パラメータで指定された宛先にトレース・ファイルを生成するSQLトレースが構成されます。SOA_INFRAユーザーは、ALTER SESSION権限が付与されている必要があります。この権限は、トレースの詳細が収集された後にデータベース管理者が取り消すことができます。

GRANT ALTER SESSION TO SOA_INFRA

ノート: パフォーマンスに影響するため、このパラメータはデバッグのみに使用してください。

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

ここでのステップのかわりに「Oracle Enterprise Manager Fusion Middleware Controlによる大量のインスタンスの削除」のステップに従って、これらのスクリプトを実行することもできます。

パージ・スクリプトを実行するには:

  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. パージ・スクリプトをロードするには、メイン・パージ・スクリプトをMW_HOME/soa/common/sql/soainfra/sql/oracle/122140/soa_purge12/soa_purge_scripts.sqlで実行します。

    パラレル・パージの場合、パラレル・パージによって生成されたジョブからのデバッグ・ログは、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 SERVEROUT ON
    

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

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

    • ループされるパージ

    • パラレル・パージ

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

    1. ループされるパージの場合:

      DECLARE
      
         MAX_CREATION_DATE timestamp;
         MIN_CREATION_DATE timestamp;
         batch_size integer;
         max_runtime integer;
         retention_period timestamp;
         composite_name varchar2(500);
         composite_revision varchar2(50);
         soa_partition_name varchar2(200);
         PQS integer;
         ignore_state boolean; 
      
        BEGIN
      
         MIN_CREATION_DATE := to_timestamp('2019-10-01','YYYY-MM-DD');
         MAX_CREATION_DATE := to_timestamp('2019-10-31','YYYY-MM-DD');
          max_runtime := 60;
          retention_period := to_timestamp('2019-10-31','YYYY-MM-DD');
          batch_size := 10000;
          composite_name := 'example_composite';
          composite_revision := '1.0';
          soa_partition_name := 'default';
          ignore_state := false;
          PQS := 5; 
           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,
           ignore_state => ignore_state,
           sql_trace => true); 
        END;
    2. パラレル・パージの場合:

      DECLARE
      
         max_creation_date timestamp;
         min_creation_date timestamp;
         batch_size integer;
         max_runtime integer; 
         retention_period timestamp;
         composite_name varchar2(500);
         composite_revision varchar2(50);
         soa_partition_name varchar2(200);
         PQS integer;
         DOP integer;
         max_count integer;
         ignore_state boolean; 
      
        BEGIN
      
         min_creation_date := to_timestamp('2019-10-01','YYYY-MM-DD');
         max_creation_date := to_timestamp('2019-10-31','YYYY-MM-DD');
         batch_size integer;
         max_runtime integer; 
         retention_period := to_timestamp('2019-10-31','YYYY-MM-DD');
         composite_name := 'michael_composite';
         composite_revision := '1.0';
         soa_partition_name := 'default';
         ignore_state := true;
         PQS := 5;
         DOP := 2;
         max_count := 100000; 
          soa.delete_instances_in_parallel(
           min_creation_date => min_creation_date,
           max_creation_date => max_creation_date,
           batch_size => batch_size, 
           max_runtime => max_runtime, 
           retention_period => retention_period,
           DOP => DOP,
           max_count => max_count,
           purge_partitioned_component => false,
           ignore_state => ignore_state,
           sql_trace => true);
         END;
パラレル・スクリプトでのループされるパージの実行後のデッドロックの解決

パラレル・スクリプトでループされるパージを実行した後にいずれかのスレッドのスレッド・ログでデッドロック検出される場合があります。次の例は、スレッド・ログで見つかったエラーを示します。

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値を増やすには:

  1. 一時表を作成し、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;
    
  2. AUDIT_DETAILS表を削除します。
    SQL> DROP TABLE PS6_SOAINFRA.AUDIT_DETAILS CASCADE CONSTRAINTS;
    
  3. AUDIT_DETAILS_TMP一時表の名前をAUDIT_DETAILSに変更します。
    SQL> ALTER TABLE PS6_SOAINFRA.AUDIT_DETAILS_TMP RENAME TO AUDIT_DETAILS;
    
  4. AUDIT_DETAILSで一意索引を作成します。
    SQL> CREATE UNIQUE INDEX "PS6_SOAINFRA"."AD_PK" ON "PS6_SOAINFRA"."AUDIT_ DETAILS" ("CIKEY", "DETAIL_ID");
    
  5. 制約と主キーをAUDIT_DETAILSに追加します。
    SQL> ALTER TABLE "PS6_SOAINFRA"."AUDIT_DETAILS" ADD CONSTRAINT "AD_PK" PRIMARY
     KEY ("CIKEY", "DETAIL_ID") ENABLE;
特定のSOAコンポジット・アプリケーションのインスタンスのパージ

特定のSOAコンポジット・アプリケーションのインスタンスをパージし、その他のコンポジットのインスタンスはパージせずに残すことができます。このアクションを使用して、大量または保存期間が長い特性のために、特定のフローを他のフローより頻繁にパージできます。

パージ・スクリプトには、COMPOSITE_DNに基づいてパージするためのオプションが含まれています。COMPOSITE_DNをベースとするパージでは、composite_nameおよびcomposite_revisionパラメータとの併用がサポートされます。

パージ・ロジックは、COMPOSITE_IDではなくフローIDに基づいています。したがって、目的のCOMPOSITE_DN以外に、同じフローIDを共有している他のコンポジットが削除されます。次に示すシナリオが発生する場合があります。

  • ビジネス・フロー・インスタンスはクローズされますが、フローはオープンしたままになります。

    コンポジットAがコンポジットBをコールするシナリオでは、パージにより、コンポジットAのインスタンスが削除の対象となります。ただし、コンポジットAのインスタンスがクローズされ、対応するコンポジットBのインスタンスがオープンしたままの場合があります。したがって、全体的なフローがオープン状態にあり、コンポジットAのインスタンスは(クローズしたとしても)パージされません。

  • ビジネス・フロー・インスタンスはクローズされ、フローもクローズされます。

    コンポジットAがコンポジットBを再度コールします。パージにより、コンポジットAのインスタンスが削除の対象となります。したがって、コンポジットAがクローズされ、コンポジットBもクローズされている場合は、フロー全体がクローズされているため、ビジネス・フロー・インスタンスAおよびBの両方がパージされます。

これらのシナリオにより、フローの一貫性が維持されます。

composite_nameおよびcomposite_revisionパラメータの詳細は、「ループされるパージ・スクリプト」および「dbms_schedulerを使用したパラレル・スクリプトでのループされるパージ」を参照してください。

Oracle Mediatorのリシーケンスされたメッセージのパージの状態

パージ・スクリプトには、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: 中断

パージのステータスの監視

Oracle Enterprise Manager Fusion Middleware Controlから実行されたパージ・ジョブは、表15-4に示されているSQLコマンドを使用して監視できます。

表15-4 パージのステータスを監視するためのSQL*Plusコマンド

使用目的 実行するコマンド

ジョブ履歴およびステータスの表示

SQL> select log_date, status from user_scheduler_job_
log where job_name = 'DELETE_INSTANCES_AUTO_JOB1' order
by log_date;

DELETE_INSTANCES_AUTO_JOB1はデフォルトで有効です。DELETE_INSTANCES_AUTO_JOB2も有効にできます。

「自動パージ」ページでのジョブの選択の詳細は、Oracle Enterprise Manager Fusion Middleware Controlによる大量のインスタンスの削除を参照してください。

実行中のジョブの表示

SQL> select session_id, running_instance, elapsed_time, cpu_used
from user_scheduler_running_jobs
where job_name = 'DELETE_INSTANCES_AUTO_JOB1'; 

ジョブの詳細の表示

SQL> select log_date, status, req_start_date, actual_start_date, run_duration
from user_scheduler_job_run_details
where job_name = 'DELETE_INSTANCES_AUTO_JOB1'
order by log_date; 

ジョブ・スケジュールの検索

SQL> select SCHEDULE_TYPE,START_DATE,REPEAT_INTERVAL
from user_scheduler_schedules
where schedule_name = 'DELETE_INSTANCES_AUTO_SCH1'; 

DELETE_INSTANCES_AUTO_SCH1およびDELETE_INSTANCES_AUTO_SCH2は、選択されたジョブに基づいています。

デフォルトのジョブ・スケジュールの変更

BEGIN
   DBMS_SCHEDULER.set_attribute (
    name      => 'DELETE_INSTANCES_AUTO_SCH1',
    attribute => 'repeat_interval',
    value     => 'freq=daily; byhour=0; byminute=0; bysecond=0');
END; 

ジョブ・スケジュールの変更(この例では、毎時30分に変更)

BEGIN
   DBMS_SCHEDULER.set_attribute (
    name      => 'DELETE_INSTANCES_AUTO_SCH1',
    attribute => 'repeat_interval',
    value     => 'freq=hourly; byminute=30');
END; 

データベースSQLトレースの生成

パージ・スクリプトには、SQLトレースを生成するためのパラメータが含まれています。

  • パージ・スクリプトをSQL*Plusから直接実行する場合、パラメータはsql_traceパラメータと名付けられます。

  • パージ・スクリプトをOracle Enterprise Manager Fusion Middleware Controlの「自動パージ」ページから実行する場合、パラメータはsqlTraceと名付けられます(「詳細な自動パージ構成プロパティ」リンクの下にあります)。

このパラメータをtrueに設定すると、データベース・ユーザーのdumpディレクトリに配置されるデータベースSQLトレースが生成されます。パラレル・パージ・スクリプトの場合、従属する各パラレル・パージ・ジョブ(J000、J001など)にもSQLトレースが生成されます。

パージ・スクリプトでパラレル問合せスレーブが有効になっている場合は、トレース・ファイルが作成されます。トレース・ファイルは、sql_traceの設定時に生成されます。パラレル・パージ・スクリプトを使用すると、J*という名前で複数のトレース・ファイルが作成されます。

SQLトレースの詳細は、Oracle Database SQLチューニング・ガイドを参照してください。

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

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

  • Oracle BPEL Process Manager

  • Oracle Mediator

  • ヒューマン・ワークフロー

  • Oracle B2B

  • SOAインフラストラクチャ

  • Oracle BPM Suite

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

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

ノート:

完全または部分的なパーティション化を実行する前に、パージ・スクリプトを実行してください。

リポジトリ作成ユーティリティを使用したデータベースのパーティション化

リポジトリ作成ユーティリティの実行中に、データベース・プロファイルを選択できます。プロファイルにより、SOAデータベースのサイズが決定され、Oracle SOA Suite関連ストレージのためのOracleデータベースのパフォーマンス機能を使用できるようになります。

  • 大: 大規模なパーティション化されたスキーマを提供します。これは、200 GB以上のデータベースに対して選択します。

  • 小: パーティションのない小さなスキーマを提供します。

詳細は、『リポジトリ作成ユーティリティによるスキーマの作成』カスタム変数に関する項を参照してください。

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

Oracle SOA Suiteには、DBAがOracle RDBMSのパーティション化機能を活用できるように、パーティション・キーが備えられています。このアクションにより、スキーマ表を時間間隔に基づいてレンジ・パーティション化できます。これは、大規模な表のデータベース・メンテナンス・ウィンドウを短縮する必要がある場合に役立ちます。(この章では説明していませんが、これにより、パーティション化されたデータをアーカイブすることもできるようになります。)

Oracle SOA Suiteの表をパーティション化するタスクは、熟練したDBAが実行する必要があります。表のパーティション化はDBAのコア・スキルであるため、この章では表をパーティション化する方法について、ステップを追った詳細な説明は行いません。ここでは、Oracle SOA Suiteのスキーマおよび関連するスクリプトに関する、DBA向けの知識と説明を提供します。DBAは、この知識を活用して、各自の環境での任意のパーティション化戦略をカスタマイズし、データベースのパフォーマンスに応じたチューニング・パラメータを組み込むことができます。チューニングは状況に応じて実施する必要があり、また、構成に1回変更を加えるのみでは完了しません。これは監視とチューニングの反復プロセスです。

次のコンポーネントは、コンポーネント独自のデータベース・スキーマに関連付けられています。

  • 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など)に対してグローバル・ハッシュ索引を使用すると、ブロックの競合が緩和されることがあります。

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

パフォーマンス上の理由から、Oracle BPEL Process ManagerOracle Mediator、ヒューマン・ワークフロー、Oracle B2B、SOAインフラストラクチャおよびOracle BPM Suiteスキーマでは、整合性を強制するための外部キー制約がありません。このことには、参照パーティション化と呼ばれるRDBMS機能を使用することが考慮されています。この機能は、外部キー制約を横断して、マスター表と詳細表の同一レベル・パーティション化を行うことによって、大きな利点をもたらします。同一レベル・パーティション化とは、関連する依存表の行が、マスター表の行と同じパーティション・キー間隔を持つ、1つのデータベース・パーティションに存在することを意味します。

この機能には、同一レベル・パーティション内の各詳細行の状態(完了、フォルトなど)について、その行に関連するマスター表の行から推測できるという利点があります。

RDBMSの参照パーティション化機能は使用できませんが、類似した動作を模倣して、いくつかの同じ利点を得ることができます。Oracle BPEL Process ManagerOracle Mediator、ヒューマン・ワークフロー、Oracle B2B、SOAインフラストラクチャおよびOracle BPM Suiteのコンポーネントでは、詳細表の各行のパーティション・キーが、マスター表の行のパーティション・キーと同じであることが保証されます(つまり、詳細表でも日付(タイムスタンプ)がパーティション・キーとなります)。この場合、設定を完了するために、DBAはマスター表と詳細表が同じ間隔でレンジ・パーティション化されていることを確認する必要があります。この章の後の各項で、いくつかの例を示します。

ノート:

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

レンジ時間隔パーティション化

レンジ時間隔パーティション化は、リリース11gのレンジ・パーティション化機能の拡張で、リリース12cの機能です。レンジ・パーティション化では、各パーティションを手動で割り当てる必要がありました。レンジ時間隔パーティション化では、パーティションを手動で割り当てる必要はありません。指定された間隔のパーティションは、割り当てたパーティション・キーの間隔値が既存のすべてのレンジ・パーティションを超えると自動的に作成されます。検証スクリプトではレンジ時間隔パーティション化がサポートされています。

レンジ時間隔パーティション化の詳細は、『Oracle Database VLDBおよびパーティショニング・ガイド』を参照してください。

同一レベル・パーティション化およびレンジ時間隔パーティション化

同一レベル・パーティション化の目標は、すべての依存表パーティションに、マスター表パーティションに対応する関連付けられた行の完全なセットが含まれるようにすることです。これは次のようにして行います。

  • パーティション・キー値は、依存表のレンジが同じになるように、マスター・キーからすべての依存表に伝播されます。

  • マスター・キーには、各フローの状態(オープンまたはクローズ)が格納されます。マスターがチェックされ、すべてがクローズされていると、同じパーティション・レンジを持つ依存表の削除が可能になります。

レンジ時間隔パーティション化の検証スクリプトでは、依存表パーティションごとに、マスター・パーティションと比較して次の点をチェックします。

  • 同じ間隔定義(各表では、月次、週次、日数などについて同じ間隔定義が必要です)。

    • 上限値と下限値はデータベースによって自動的に維持されます。

  • 削除する必要のあるパーティションでは、上限値が同じであることが必要です。

レンジ時間隔パーティション化の例

次の例では、レンジ時間隔パーティション化の動作を示します。この例では、SCA_FLOW_INSTANCEマスター表が使用されます。

CREATE TABLE SCA_FLOW_INSTANCE
(FLOW_ID INTEGER NOT NULL;
. . .
. . .
CREATED_TIME TIMESTAMP NOT NULL)
PARTITION BY RANGE (CREATED_TIME)
INTERVAL(NUMTOYMINTERVAL(1, 'MONTH'))
PARTITION p0 VALUES LESS THAN (TO_DATE('1-2-2007', 'DD-MM-YYYY')));

表15-5に、前述の例で示されている構文を説明します。

表15-5 レンジ時間隔パーティション化の例

構文 説明
PARTITION BY RANGE (CREATED_TIME)

パーティション・キー(たとえば、2013年7月1日の日付は01-07-2013と指定)。

INTERVAL(NUMTOYMINTERVAL(1, 'MONTH'))

間隔(この例では、1か月を指定)。したがって、パーティション・キーが(01-07-2013のように)7月1日に指定されている場合は、7月に対してパーティションが作成されます。その後、パーティションは、8月1日、9月1日、10月1日など、月単位で自動的に割り当てられます。各パーティションを手動で割り当てる必要はありません。

ノート: 同一レベル・パーティション化に対して上限および下限が作成されるように、すべてのOracle SOA Suite表はこの同じ間隔値を使用して作成する必要があります。

PARTITION p0 VALUES LESS THAN (TO_DATE
('1-2-2007', 'DD-MM-YYYY')));

最初のパーティションはレンジ・パーティションである必要があります。これは遷移ポイントで、この後はすべてのパーティションが自動的に割り当てられます。最初のレンジ・パーティションには、使用されることのないDATE間隔(完了日1-2-2007など)を指定することをお薦めします。

このパーティションの日付によって、パーティションは仮想メタデータになります。この日付により、必要に応じて簡単にパーティションを削除できます。

次の例に示すSQLコマンドでは、作成された最初のレンジ・パーティションを識別します。最後の行の値Noは、これがレンジ・パーティションであって時間隔パーティションでないことを示します。

SQL> select partition position, partition name, high value, interval
      from user_tab_partitions
       where table_name = 'SCA_FLOW_INSTANCE';

--------------------------------------------------------------
1     P0        TIMESTAMP' 2007-02-01 00:00:00'    No

次の例に示すSQLコマンドでは、システム名、上限値、およびこれが時間隔パーティションであるかどうかを識別します。最後の行の値Yesは、これが時間隔パーティションであることを示します。出力の2行目は削除されます。最初の行は単なるメタデータであり、削除されません。パーティションは、日付を挿入すると自動的に割り当てられます。システム名は自動的に生成され、パーティションは日付に基づき必要に応じて割り当てられます。

SQL> INSERT INTO SCA_FLOW_INSTANCE VALUES(..TO_TIMESTAMP('1-5-2013', 'DD-MM-YYYY')...};
 
--------------------------------------------------------------
1     P0        TIMESTAMP' 2007-02-01 00:00:00'    No
2     SYS_P532  TIMESTAMP' 2013-06-01 00:00:00'    Yes

次の例に示すSQLコマンドでは、2行目と3行目を、削除するパーティションとして識別します。これは前の月(2013年5月ではなく2013年3月)から実行されているため、別のパーティションが挿入されます。パーティションの位置は変更されます。

SQL> INSERT INTO SCA_FLOW_INSTANCE VALUES(..TO_TIMESTAMP('1-3-2013', 'DD-MM-YYYY')...};
 
--------------------------------------------------------------
1     P0        TIMESTAMP' 2007-02-01 00:00:00'    No
2     SYS_P578  TIMESTAMP' 2013-04-01 00:00:00'    Yes
3     SYS_P532  TIMESTAMP' 2013-06-01 00:00:00'    Yes

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

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

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

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

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

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

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

パーティションの構成

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

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

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

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

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

検証スクリプトの概要

パーティションおよび同一レベル・パーティション化された依存表を削除するタイミングを識別するために、DBAには検証スクリプトが提供されています。この検証スクリプトでは、長時間実行されているアクティブなインスタンスの存在も識別されます。その後、これらのインスタンスを別のパーティションに移動し、元のパーティションを削除できます。検証スクリプトではレンジ時間隔パーティション化がサポートされています。

ノート:

検証スクリプトではパーティションが削除できることを確認するのみであり、パーティションを削除しません。スクリプトで正確なデータを得るためには、すべての表に対してパーティション化を有効にすることが重要です。

コンポーネント表

この項では、パーティション化の制約について説明し、コンポーネント表、コンポーネント表が属するグループおよびそのパーティション・キーのリストを示します。

パーティション化の制約

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

  • パーティション化のアプローチには、次の選択肢があります。

    • 完全なパーティション化: サービス・コンポーネント/サービス・エンジンのすべての表をパーティション化します。

    • パーティション化なし: サービス・コンポーネント/サービス・エンジンの表をパーティション化しません。

    • 部分的なパーティション化: パーティション化を増加率が高い特定の表に制限します。

      いずれの表も、次の制限に従ってパーティション化できます。

      • 依存表をパーティション化する場合は、そのマスター表もパーティション化する必要があります。

      • すべての表は、同じ日付範囲と同じ名前に従って同一レベル・パーティション化される必要があります。

      • SCA_FLOW_INSTANCE表は、常にパーティション化します。いずれかのコンポジットの「監査レベル」プロパティが「開発」または「本番」に設定されている場合、この制約は必須です。検証スクリプトは、そのパーティション内のアクティブなビジネス・フロー・インスタンスに基づいて、アクティブなフローをチェックします。したがって、SCA_FLOW_INSTANCE表がパーティション化されていない場合、すべての表の同一レベル・パーティション化に基づく全体検証スクリプト・ロジックは機能しません。

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

コンポーネント表、レンジ・パーティション・キーおよびグループ

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

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

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

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

    ノート:

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

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

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

SCA_FLOW_INSTANCE

CREATED_TIME

1

SCA_FLOW_TO_CPST

PARTITION_DATE

1

SCA_COMMON_FAULT

PARTITION_DATE

1

SCA_FLOW_ASSOC

PARTITION_DATE

1

SCA_META_DATA

PARTITION_DATE

1

SCA_REJECTED_MESSAGE

PARTITION_DATE

1

SCA_ATTACHMENT_REF

PARTITION_DATE

1

SCA_SENSOR_VALUE

PARTITION_DATE

1

AUDIT_DETAILS

CI_PARTITION_DATE

1

AUDIT_TRAIL

CI_PARTITION_DATE

1

表15-7 コンポーネント: Oracle BPEL Process Manager

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

CUBE_INSTANCE

CPST_INST_CREATED_TIME

1

CI_INDEXES

CI_PARTITION_DATE

1

CUBE_SCOPE

CI_PARTITION_DATE

1

WI_FAULT

CI_PARTITION_DATE

1

WORK_ITEM

CI_PARTITION_DATE

1

DLV_SUBSCRIPTION

CI_PARTITION_DATE

1

DOCUMENT_CI_REF

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

表15-8 コンポーネント: Oracle Mediator

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

MEDIATOR_DEFERRED_MESSAGE

CREATION_DATE

1

MEDIATOR_PAYLOAD

CREATION_TIME

2

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

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

WFASSIGNEE

COMPOSITECREATEDTIME

1

WFATTACHMENT

COMPOSITECREATEDTIME

1

WFEVIDENCE

COMPOSITECREATEDTIME

1

WFHEADERPROPS

COMPOSITECREATEDTIME

1

WFMESSAGEATTRIBUTE

COMPOSITECREATEDTIME

1

WFNOTIFICATION

COMPOSITECREATEDTIME

1

WFREVIEWER

COMPOSITECREATEDTIME

1

WFROUTINGSLIP

COMPOSITECREATEDTIME

1

WFTASK

COMPOSITECREATEDTIME

1

WFTASK_TL

COMPOSITECREATEDTIME

1

WFTASKAGGREGATION

COMPOSITECREATEDTIME

1

WFTASKERROR

COMPOSITECREATEDTIME

1

WFTASKHISTORY

COMPOSITECREATEDTIME

1

WFTASKHISTORY_TL

COMPOSITECREATEDTIME

1

WFTASKTIMER

COMPOSITECREATEDTIME

1

表15-10 コンポーネント: 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

表15-11 コンポーネント: 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

同一レベル・パーティション化および時間隔パーティション化の検証スクリプト・チェック

検証スクリプトでは、チェックの実行時に次の2つの表を使用します。

  • USER_PART_TABLES

  • USER_TAB_PARTITIONS

表に対して定義した間隔の定義をチェックするには、次のようにします。

SQL> select INTERVAL from USER_PART_TABLES 
     where table_name = 'table_name';

パーティションの上限値をチェックするには:

SQL> select high_value from USER_TAB_PARTITIONS
     where table_name = 'table_name'
     and partition_name = 'partition_name';

検証スクリプトの実行

検証スクリプトは、MW_HOME/SOA_ORACLE_HOME/rcu/integration/soainfra/sql/verifyのディレクトリにあります。検証スクリプトには、スキーマが時間隔パーティションかレンジ・パーティションかによって2つのバージョンがあります。
  • soa_exec_interval_verify.sql

  • soa_exec_verify.sql

検証スクリプトは、パーティションが削除可能かどうかを判断するのに役に立ちます。検証スクリプトを実行すると、パーティションごとにログ・ファイルと結果ファイルが生成されます。ログ・ファイルを調べ、データベース管理者は、結果ファイルを実行してパーティションを削除できるかどうかを評価する必要があります。

ログ・ファイルを調べると、アクティブなインスタンスが多すぎることが判明し、データベース管理者がパーティションの延長を決定する場合があります。少数のインスタンス、たとえば5%のインスタンスしか開かれていないことがわかった場合、データベース管理者は行の移動を実行して、そのインスタンスを他のパーティションに移すことができます。パーティションの特定のインスタンスを他のパーティションに移すと、そのパーティションは削除できます。

検証スクリプトを実行するには:

  1. 結果ファイルおよびログ・ファイル用のデータベース・ディレクトリを設定します。
    スクリプトを実行する前に、オペレーティング・システムのディレクトリ、たとえば /tmp/verifyが、適切なアクセス権で存在している必要があります。

    SOAINFRAユーザーとしてSQL*Plusにログインし、結果ファイルとログ・ファイルを格納するディレクトリをマップします。

    sqlplus soainfra
    Enter password:
    SQL> CREATE OR REPLACE DIRECTORY PART_DIR AS '/tmp/verify';
  2. グループ1とグループ2の一時表を切り捨てます。
    グループ1の表の場合:
    $ sqlplus soainfra
    SQL> BEGIN
    SQL> verify_soa.trunc_verify1_temp_tables;  
    SQL> END;
    SQL> /
    
    グループ2の表の場合:
    $ sqlplus soainfra
    SQL> BEGIN
    SQL> verify_soa.trunc_verify2_temp_tables;  
    SQL> END;
    SQL> /
    
  3. グループ1の検証スクリプトを編集します。
    RANGEまたはINTERVALスクリプトを、使用するパーティションのタイプに応じて編集します。

    ノート:

    他の表はすべてこのファブリック表で等しくパーティションされるので、検証スクリプトによって評価されるパーティションは、SCA_FLOW_INSTANCEファブリック表に属します。

    • RANGE検証スクリプトsoa_exec_verify.sqlの場合:

      スキーマから削除する候補であるSCA_FLOW_COMPOSITEパーティションでPL/SQL表を更新します。たとえば:

      mySoa_drv_list   := verify_soa.soa_drv_table();
      mySoa_drv_list.extend(1);    -- Ensure that you set this correctly
      mySoa_drv_list(1) := 'P01';  -- One entry per partition.
    • INTERVAL検証スクリプトsoa_exec_interval_verify.sqlの場合:

      SOA_MAX_TIMESTAMP変数を適切な日付に更新します。この日付より前で高い値を持つパーティションがあれば、スキーマから削除する候補になります。たとえば:

      soa_max_timestamp := to_timestamp('2013-08-15','YYYY-MM-DD');

  4. グループ1の検証スクリプトを実行します。
    検証スクリプトはパーティションを削除せず、PART_DIRデータベース・ディレクトリにログ・ファイルと結果ファイルを生成します。データベース管理者は、ログ・ファイルを調べ、結果ファイルを実行してパーティションを削除できるかどうか、あるいは行の移動が必要かどうかを判断する必要があります。

    時間隔のグループ1のパーティションは、必ずグループ2のパーティションより前に削除する必要があります。検証手順では、グループ1の表によってまだ参照されているかどうかに基づいて、グループ2の表パーティションが評価されます。したがって、グループ1の表パーティションを先に削除すると、グループ2の表パーティションを削除できる可能性が高くなります。

    • レンジ・パーティションの場合:

      sqlplus soainfra
      SQL> @soa_exec_verify.sql 1   -- 1 for Group1.
    • 時間隔パーティションの場合:

      sqlplus soainfra
      SQL> @soa_exec_interval_verify.sql 1   -- 1 for Group1.
  5. PART_DIRディレクトリにあるログおよび結果ファイルを確認します。
    時間隔ごとのログ・ファイルと結果ファイルには、SCA_FLOW_INSTANCEというパーティション名が含まれます。時間隔パーティション化の場合、このパーティション名はRDBMSシステムで生成される名前です。

    レンジ・パーティションのログ・ファイルおよび結果ファイルの例が、SOA_P01_LOG_1SOA_P01_RESULT_1.sqlです。時間隔パーティションのログ・ファイルおよび結果ファイルの例が、SOA_SYS_P579_LOG_1SOA_SYS_P579_RESULT_1.sql.です。

    パーティション間隔ごとに、データベース管理者はログ・ファイルを慎重に確認して、その時間隔のパーティションがすべてのテストに合格していることを確認する必要があります。オープン/アクティブなフローがレポートされた場合は、パーティションを作成する前に行の移動が必要です。

    「別のパーティションへの長時間実行されているアクティブなインスタンスの移動」では、パーティション間で行を移動するプロセスについて説明しています。

  6. 削除可能なグループ1のパーティションを削除します。
    生成される結果ファイルには、パーティションを削除するコマンドが含まれています。外部キーのある表パーティションを削除する前に、外部キーを無効にする必要があります。これはRDBMSの要件であり、SOAINFRAスキーマには現在、多くの外部キーが定義されています。外部キーをDISABLEにしてから、必要な検証結果スクリプトをすべて実行することをお薦めします。パーティションを削除したら、外部キーを再度有効化する必要があります。

    ノート:

    外部キーの無効化と有効化を実行するためのルーチンが用意されており、それを使用すると適切なコマンドを持つスクリプトが生成されます。スクリプトを生成する必要があるのは1回のみです。データベース管理者は、スクリプトをカスタマイズすることもできます。詳細は、外部キーの変更(verify_soa.alter_FK)を参照してください。

    時間隔のパーティションを削除するには、結果スクリプトを実行します。たとえば:
    sqlplus soainfra
    SQL> SOA_SYS_P579_RESULT_1.sql
  7. 行を移動した場合には、行のリストアを実行します。
    この手順が必要なのは、行の移動手順を使用してグループ1のオープン・インスタンスを移動した場合のみです。この手順では、移動したそのオープン・インスタンスのパーティション・キーが更新され、元のフロー作成日の値に戻されます。レンジ・パーティションと時間隔パーティションのメカニズムは、次のとおりです。
    • レンジ・パーティションの場合、行の移動手順によってオープン・フローが安全なパーティションに移され、古いパーティションを削除できるようになります。次に、行のリストア手順によってパーティション・キーが元の作成日に戻され、まだ使用できる適切なパーティションにフローが移動します。現在のパーティションが、まだ使用できる唯一の適切なパーティションである可能性があるため、通常これによって行の移動は発生しません。

    • 時間隔パーティションの場合、行の移動手順によってオープン・フローが安全なパーティションに移され、古いパーティションを削除できるようになります。次に、行のリストア手順によってパーティション・キーが元の作成日に戻され、オープン・フローを使用するために古いパーティションを再作成するようRDBMSがトリガーされます。再作成されたパーティションは小さくなり、時間隔検証スクリプトを次に実行したときに選択されます。時間隔検証スクリプトは、以前の日付値を使用してパーティション候補を選択します。

    行のリストアが必要なのはグループ1の表のみで、レンジ・パーティションでも時間隔パーティションでも手順は同じです。表の行の移動が有効なことを確認します。(詳細は、データベースで表の移動を有効にするステップを参照してください。)

    sqlplus soainfra
    SQL> verify_soa.exec_row_restore_1;
    SQL> END;

    行リストアのルーチンが正常に完了したら、行リストア切捨てを実行します。行リストアのルーチンは、成功するまで繰り返すことができます。行リストア切捨てルーチンを実行すると、行のリストアは繰り返せなくなります。

    sqlplus soainfra
    SQL> BEGIN
    SQL> verify_soa.trunc_verify1_rst_temp_tables;
    SQL> END;
  8. グループ2検証スクリプトを実行します
    グループ2の検証スクリプトは、同じ時間隔でグループ1のパーティションを削除した後でのみ実行してください。

    グループ2のパーティションを削除するステップは、グループ1の場合と同じで、前述のステップどおりです。

    1. グループ2の検証スクリプトを、グループ1の場合と同じように編集します(グループ1の詳細な手順を参照)。

    2. グループ2の検証スクリプトを実行します。

      • レンジ・パーティションの場合:

        sqlplus soainfra
        SQL> @soa_exec_verify.sql 2   -- 2 for Group1.
      • 時間隔パーティションの場合:

        sqlplus soainfra
        SQL> @soa_exec_interval_verify.sql 2   -- 2 for Group1.
    3. PART_DIRディレクトリにあるログおよび結果ファイルを確認します。(グループ1の詳細な手順を参照)。

      結果によっては、行の移動にグループ2の表が必要な場合があります。詳細は、グループ2の行の移動のトリガー を参照してください。

    4. グループ2のパーティションを削除します(グループ1の詳細な手順を参照)。

    グループ2の表の場合、行リストアのルーチンは必要ありません。

  9. 外部キーを再度有効にします。
    外部キーの有効化と無効化に役立つスクリプトの詳細は、外部キーの変更(verify_soa.alter_FK)を参照してください。

ノート:

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

別のパーティションへの長時間実行されているアクティブなインスタンスの移動

検証スクリプト・ログでは、合計インスタンス数、オープン・インスタンス数およびパーティション内のオープン・インスタンスの割合が提供されます。オープン・インスタンスがある場合は、データベース管理者が行移動プロシージャを実行して、これらの行を別のパーティションに移動することができます。行移動プロシージャによって、オープン・インスタンスのパーティション・キーが更新され、次にこれらのインスタンスの別のパーティションへの行移動が開始されます。

行移動プロシージャは、等しくパーティション化されたすべての表で行を移動する必要があるため、行の移動は負荷が高くなります。パーティショニング戦略を計画する際には、オープン・インスタンスの比率がパーティションの全行数の5%未満になるように、パーティションが十分に時間経過できることを確認します。

  1. 表の行の移動を有効にします
    行移動プロシージャは、表パーティション間で行を移動します。RDBMSでこのタスクを実行するには、行移動を実行するより前に、表での行移動を有効にする必要があります。ご使用の環境に対してSOA_ENABLE_MVT.SQLスクリプトをカスタマイズして実行します。
    sqlplus soainfra
    SQL> @SOA_ENABLE_MVT.SQL
  2. グループ1に対して行移動を実行している場合は、ステップ3に移動します。グループ1のパーティションをすでに削除しており、グループ2に対して行移動を実行している場合は、ステップ5に移動します。
  3. グループ1の行移動をトリガーします。
    次のプロシージャのうちひとつを実行し、スキーマが間隔でレンジ・パーティション化されているか、時間隔パーティション化されているかに従って、グループ1の表の行を移動します。
    • レンジ・パーティションの場合:

      sqlplus soainfra
      SQL> PROCEDURE exec_row_movement_1( partition_name in varchar2, 
      new_partition_date in timestamp );
    • 時間隔パーティションの場合:

      sqlplus soainfra
      SQL> PROCEDURE exec_row_movement_interval_1( partition_name in varchar2, 
      new_partition_date in timestamp );

    説明:

    partition_nameは、行移動を実行するパーティションの名前です。

    new_partition_dateは、パーティション・キー列を更新する新しい日付です。

    ノート:

    行の移動が完了したら、グループ1の一時表を切り捨てグループ1検証スクリプトを再実行したうえで、生成されたログ・ファイルをチェックして、オープン・インスタンスがこれ以上ないことを確認します。

  4. これで、グループ1のパーティションの削除に進むことができます。
  5. グループ2の行移動をトリガーします。
    次のプロシージャのうちひとつを実行し、スキーマが間隔でレンジ・パーティション化されているか、時間隔パーティション化されているかに従って、グループ2の表の行を移動します。
    • レンジ・パーティションの場合:

      sqlplus soainfra
      SQL> PROCEDURE exec_row_movement_2( partition_name in varchar2, 
      new_partition_date in timestamp );
    • 時間隔パーティションの場合:

      sqlplus soainfra
      SQL> PROCEDURE exec_row_movement_interval_2( partition_name in varchar2, 
      new_partition_date in timestamp );

    説明:

    partition_nameは、行移動を実行するパーティションの名前です。

    new_partition_dateは、パーティション・キー列を更新する新しい日付です。

    ノート:

    行の移動が完了したら、グループ2の一時表を切り捨てグループ2検証スクリプトを再実行したうえで、生成されたログ・ファイルをチェックして、オープン・インスタンスがこれ以上ないことを確認します。

  6. これで、グループ2のパーティションの削除に進むことができます。

パーティションのメンテナンスに役立つルーチン

Oracle SOA Suiteには、データベース側のパーティション・メンテナンスを支援するルーチンが複数あります。ルーチンには、外部キーを有効または無効にするスクリプト、時間隔パーティション表の間隔を変更するスクリプト、行の移動後に行をリストアするスクリプトがあります。

行の移動などパーティションのメンテナンス・ルーチンは、パッチ21181834を通じて12.1.3に追加されました。ルーチンは、パッチ21520523を通じて12.2.1に追加されています。次のルーチンについて説明します。

行のリストア(verify_soa.exec_row_restore_1)

このルーチンは、グループ1の表のパーティション・キーをリストアして元の値に戻す際に使用されます。フローが行移行され、適切なパーティションを削除すると、行リストアのルーチンを実行できます。ルーチンが正常に完了すると、行リストア切捨てのルーチンを実行できます。

次に、行リストアを実行する例を示します。
BEGIN
 verify_soa.exec_row_restore_1;
END;

行リストア切捨て(verify_soa.trunc_verify1_rst_temp_tables)

このルーチンは、表verify_r_group1を切り捨てます。これは、行リストアのルーチンが正常に実行されてから実行してください。行リストアのルーチンは、成功するまで繰り返してください。行リストア切捨てを実行すると、行リストアのルーチンは繰り返せなくなります。(ノート: 切捨ての前に表verify_r_group1のバックアップも検討してください)。

ノート:

切捨てルーチンを実行する前に、表verify_r_group1のバックアップを検討します。

次に、行リストア切捨てを実行する例を示します。
BEGIN
verify_soa.trunc_verify1_rst_temp_tables;
END;

時間隔の変更(verify_soa.alter_interval)

このルーチンを使用して、時間間パーティション表の時間間を変更します。このルーチンで、PART_DIRディレクトリにSQLスクリプトが生成されます。これで、SOAINFRAユーザーがSQLスクリプトを実行できるようになります。

次に、間隔の変更を実行する例を示します。

ステップ1: SQLスクリプトの生成

set echo on;
set serverout on;
/*
NUMTOYMINTERVAL(1, ''MONTH'')
NUMTODSINTERVAL(1, ''DAY'')
NUMTODSINTERVAL(7, ''DAY'')
*/
begin
 verify_soa.alter_interval('NUMTODSINTERVAL(1, ''DAY'')');
end;

ステップ2: 生成されたSQLスクリプトの実行

SQL> @SOA_ALTER_INTERVAL_GROUP1.SQL

外部キーの変更(verify_soa.alter_FK)

パーティションを削除する前に外部キーを無効化し、パーティション削除コマンドの後で外部キーを再度有効化する際に使用します。このルーチンで、PART_DIRディレクトリに2つのSQLスクリプトが生成されます。SQLスクリプトは、それぞれのパフォーマンス要件に応じてカスタマイズできます。SQLスクリプトは、SOAINFRAユーザーとして実行する必要があります。

次に、外部キーの変更を実行する例を示します。

ステップ1: SQLスクリプトの生成:

set echo on;
set serverout on;
begin
 verify_soa.alter_fk;
end;

ステップ2: 有効化および無効化コマンドを、必要に応じて実行します。

SQL> @SOA_DISABLE_FK.SQL
SQL> @SOA_ENABLE_FK.SQL

グローバル索引の更新

パーティション・メインテナンス・スクリプトは、update global index句を使用してdrop partition文を実行します。この句を使用すると索引の再構築は避けられますが、競合が発生します。競合を回避するには、オフピーク時に、またはメンテナンス・ウィンドウでパーティション・メンテナンスを実行してください。

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

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

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

表削除なしでの実行時表からのレコードの削除

切捨てスクリプト(truncate_soa_oracle.sql、およびOracle SOA Suiteクイック・スタート・インストールで提供されるJavaデータベースの場合はtruncate_soa_javadb.sql)により、表を削除することなくすべてのOracle SOA Suiteランタイム表からすべてのレコードを削除できます。切捨てスクリプトでは、データベース領域の再利用はできません。

切捨てスクリプトは、次のシナリオで役立ちます。

  • 本番のカスタマイズおよび新規ジョブ定義を保管できるように本番環境のスキーマを保持する一方で、SOAインフラストラクチャ内(つまりクローン・データベース内)のすべてのインスタンス・データを状態にかかわりなく切り捨てる必要がある状況で、本番環境またはテスト環境クローンを作成する場合。

  • テスト・シナリオの再作成および再実行を必要とするテストでの使用。

切捨てスクリプトは、次のコンポーネントのすべての実行時表を対象とする切捨て文を含めることによって、このオプションを提供します。

  • Oracle BPEL Process Manager

  • Oracle Mediator

  • ビジネス・ルール

  • Oracle B2B

  • SOAインフラストラクチャ

  • Oracle BPM Suite

表を削除することなく実行時表からレコードを削除するには:

  1. SQL*Plusを起動します。
    sqlplus
    
  2. SQL*Plusで、SOAINFRAユーザーとしてデータベースに接続します。
    CONNECT SYS AS SOAINFRA
    
  3. MW_HOME/SOA_ORACLE_HOME/rcu/integration/soainfra/sql/truncateディレクトリにある切捨てスクリプトを実行します。
    SQL> @truncate_soa_oracle.sql