1. 回復可能なデータ統合を作成するためのベスト・プラクティス
  2. レジリエンシのコード

レジリエンシのコード

回復可能なデータ統合を開発する際には、これらのベスト・プラクティスを使用します。

自動クリーンアップ手順の定義

自動クリーンアップ手順を定義すると、コードのリジリエンシに役立ちます。

コードを開発してテストを実行する際、不具合の修正、パフォーマンスの改善およびロード戦略の最適化を行う間、使用する環境を繰り返しリセットする必要があります。クリーン・アップ・プロシージャを早期に作成することにより、コードが進化するときに、必要な状態に環境をリセットできるだけの柔軟性を持たせる必要のある時点まで、これらの手順を改善できます。

  • すべてリセット(ターゲット・システムにデータなし)
  • 最後のロード前の状態(変数、ステータス、監査表などが含まれる)に環境をリセットします。
  • 特定のロード(または、batch_idまたはrun_id)のデータが他のデータに影響を与えずに環境全体でリセットされるように環境をリセットします

通常、クリーンアップ・プロセスを自動化すると、そのプロセスの実行速度が向上します(リセットする表のリストや実行するSQL問合せを検索する必要がありません)。自動化によって、環境の間違った部分をリセットする危険性も大幅に低下します。特にデバッグが不満を受け、ユーザーが操作を中断した場合です。

これらのクリーン・アップ・プロシージャはきめ細かくなったため、統合プロセスに含めることができます。次の2つの方法を利用できます。

  • 常にデータをロードする前に事前のクリーンアップを実行してください。(バッチIdまたは特定の日付で)簡単に識別できるデータをロードする場合は、同じデータ・セットの前回のロードを上書きして失敗する方法が簡単になります。
  • エラー発生時には、これらのクリーンアップ手順をワークフローで使用します。短時間、ソース環境またはターゲット環境への接続が失われてしまうため、ロード全体を中断しません。何百ものファイルをロードし、これらのファイルに対して複雑な変換を実行するとします。ファイルの1つのみにアクセスする際に問題が発生したことがあるか、すべてを完了するのではなく、そのファイルをできるかぎり早く再試行し、そのファイルを引き続きロードできない場合は、もっと逆に対処する必要があるため、すべてを中断しますか。実行している環境の安定性によっては、適切なユーザーにアラートを通知するまでに数回かかる場合があります。同様に、使用している環境で発生した停止の種類に基づいて、一時停止を強制的に行ってから再試行することもできます。

様々なタイプのリカバリ手順について検討してください。単純なタスクの場合、他のクリーンアップまたはリセットを行わずに失敗した操作を再試行するだけの十分な場合があります。しかし、コードが進化し、より複雑になった場合、発生するエラーのタイプも同様に展開されます。ロード・エラーを解決した後(ロード自体は機能しません)、ビジネス・エラーが発生します(データがロードされたが、誤ったデータをロードしているか、計算がエラーになっている)。このタイプの修正に対処する方法を慎重に調査する必要があります。初期ステージでは、ビジネス・エラーが発生したときに、すべてをリセットすることが有効である可能性があります。ただし、コードが拡大するにつれてきれいに拡大する必要があるため、修正作業の規模が大きくなる可能性があります。

ループをOracle Data Integratorで定義すると、クリーンアップ・プロシージャおよび試行回数を追跡する増分カウンタを含めることができます。停止の追跡性を向上させるため、ベスト・プラクティスには、発生したエラーの記録が含まれているため、エラーが頻繁に発生する場合に適切なアクションをとることができます。発生した問題の非表示になるコストに適応させないようにする場合です。「失敗したステップからのエラーの取得」で説明されている方法を使用できます。

プロセス内の1つの特定ステップでエラーが発生しやすいとわかっている場合(たとえば、停止の設定されたタイミングなしで定期的にオフラインになるリモート・システムなど)は、Oracle Data Integratorの組込み機能を使用してパッケージ内のステップを再試行できます。自動再試行では、ステップの自動再試行の設定方法について説明します。

この方法を使用する場合は、次の2点に注意する必要があります。

  • プロセスが再試行に設定されている場合、Oracle Data Integratorによりそのプロセスが失敗したことは通知されません。その後の試行の1つが成功した場合、ステップはOracle Data Integratorログに成功としてログに記録されます(ただし、この試行は独自の監査表で追跡できます)。
  • 再試行してこのステップの実行時間が長くなるまで待機します。統合プロセスのパフォーマンスをレビューするときは、注意してください。

パフォーマンス・ドリフトの識別

パフォーマンスは時間の経過とともに徐々に低下します。パフォーマンスを監視して、同じ量のデータが処理されることを確認することが重要であり、オリジナルのパフォーマンスを取得します。より多くのデータの処理に時間をかけることは意味があります。同じ量のデータを処理するほど時間がかかる場合、警告記号になることがあります。

遅延の場所と遅延の原因を把握することが望ましいでしょう。これは、使用可能な帯域幅を減らすネットワーク・アクティビティ、SQLコードの実行に悪影響を与えるデータベースの失効している統計、または選択した数だけに関心があるサーバー上の専門ファイルです。

Oracle Data Integratorでは、パフォーマンスを向上させるために、ログ(およびシナリオ・レポート)を可能なかぎりパージすることをお薦めします。ログをアーカイブしたり、パフォーマンス関連情報をコピーすることは非常に便利であるため、時間の経過とともにパフォーマンスをサーベイできます。

パフォーマンス低下を調べるには、Oracle Data Integratorの個々のステップを調べ(パフォーマンス全体を停止しないでください)、遅延の発生箇所を把握する最適な方法です。また、Oracle Data Integratorログをパージするプロセスが自動化されていることも確認してください。シナリオ・レポートなど、これらのパージを実行するOracle Data Integratorジョブを実際に作成できます。詳細は、「OdiPurgeLogによるログのパージ」を参照してください。

Oracle Data Integratorでは、オペレータに存在するセッションにリンクされたシナリオ・レポートのパージのみが提供されているため、セッションをパージした後でシナリオ・レポートをパージするには、Oracle Supportからの支援が必要になります。セッションを消去する前にシナリオ・レポートを消去しなかった場合は、Oracleサポートに連絡してください。Oracleでは、適切な手順を実行できます。

長時間実行する場合は、パフォーマンスを継続的に監視することが重要です。パフォーマンスの低下は、多くの場合、環境の低下を警告する記号です。特に、Oracleでは、SQL Plan Management (SPM)を使用して実行計画を制御することをお薦めします。本番での実行計画の変更によって障害が発生し、表ロードが原因で実行計画の変更リスクが発生する可能性があります。

OdiPurgeLogを使用したログのパージ

Oracle Data Integratorパッケージの「ユーティリティ」ドロワーを参照すると、OdiPurgeLogというツールが表示されます。これは、Oracle Data Integratorログのパージのために設計されたシナリオで使用でき、このシナリオは定期的に実行するようにスケジュールして、可能なかぎりログを少なくしておくことができます。

ベスト・プラクティスは次のとおりです。

  • レポートも必ずパージする必要があります。これらのログをパージしている間、自分自身のログを削除するのは困難です。
  • パージには待機時間のレベルを設定できます。たとえば、変数を使用して、すべてをパージする前の日時または前の日付を格納できます(End Dateパラメータでこれを使用します)。
  • シナリオ・ログ(およびレポート)のみをパージするか、シナリオとロード計画ログの両方をパージするかを選択できます。

失敗したステップからのエラーの取得

通常、getPrevStepLog () APIはOracle Data Integratorプロシージャで使用されます。ステップが失敗した場合に、修正処理を試みる前にそのステップで報告されたエラーを取得すると、非常に便利です。

このAPIは、適切な情報を返すプロパティ名を使用して起動されます。たとえば、セッションの名前、失敗したステップの名前、および関連するエラー・メッセージを表示する場合は、次のコードを使用してプロシージャのエラーを取得できます。

Session:
        <%=odiRef.getInfo("SESS_NAME")%> encountered the following
        error at step: <%=odiRef.getPrevStepLog("STEP_NAME")%>Error Message:
        <%odiRef.getPrevStepLog("MESSAGE")%>

このスニペットは、情報をどこかに格納する追加のコードでラップするか、適切に処理するためにその情報を送信します。

自動再試行を使用

自動再試行では、完全なプロセスに完了する場合と、簡潔または一時的な不一致により取消を行う場合があるため、時間を節約できます。

パッケージで、再試行を許可するステップを選択します。プロパティ・ボックスで、「拡張」タブをクリックします。「失敗後の処理」領域で、次の操作を実行します。

  • ステップの再試行回数を定義
  • 各再試行の間に待機する期間を定義します

シナリオ・セッションに一意の名前または動的名を使用

異なるデータのセットをロードするために同じシナリオが複数回実行される場合、Oracle Data Integrator演算子ビューは、同じシナリオの多数のインスタンスのリストが表示されていることが原因でエラーが発生する場合があります。

シナリオを起動する際のこの要素の1つは、セッション名(SESS_NAME)パラメータを利用することです。同じシナリオが何回も実行されている場合は、このシナリオに対して、処理する必要のあるデータ(特定のデータ・スライス、load_id、日付など)を示すパラメータがすでに存在している可能性があります。この変数を使用して、シナリオの実行ごとに一意の名前を作成できます。シナリオのコールでセッション名を設定すると、パッケージの追加セッションがOracle Data Integrator演算子でより読みやすくなります。これにより、1つの障害が発生したときに問題のあるデータ・セットを理解しやすくなります。

イベント・ドリブン・ツールの使用

Oracle Data Integratorでは、新しいデータが利用できるようになるまでパッケージで使用できる多数のツールが提供されています。

次のツールを使用すると、ポーリング・レートおよびタイムアウト期間を設定できます。

  • OdiFileWaitは、ディレクトリでファイルが利用できる状態になるまで待機します(Oracle Data Integratorエージェントがそのディレクトリを参照する必要があることに注意してください)。
  • OdiWaitForDataは、指定した問合せに基づいて、新しいデータが表内で使用可能になるまで待機します。
  • OdiWaitForTableは、データベース内に表が作成されるのを待ちます。

エージェント・ブループリントのキャッシュ・タイムアウトの構成

Oracle Data Integrator 12 cでは、実行されるシナリオの定義をキャッシュしてエージェントの効率が向上しました。シナリオのキャッシュ期間をOracle Data Integratorのトポロジの物理エージェントの定義で制御できます。

エージェントでシナリオをキャッシュすると、リアルタイムのジョブで便利なため、エージェントは実行のたびにリポジトリで情報を取得する必要がありません。デメリットは、新しいバージョンのシナリオのデプロイメントが即時に取得されないことです。キャッシュされたシナリオの新しいバージョンが選択されるまで、デフォルトのタイムアウトは600秒(10分)で、100個のエントリがデフォルトでキャッシュされます。

これらの値は管理できます。「エージェント」定義の「定義」タブで、「セッション・ブループリント・キャッシュ管理」セクションを使用して、最大キャッシュ・エントリおよび未使用ブループリント・ライフタイム(秒)を設定します。