データ・リフレッシュ・パフォーマンスについて
Oracle Fusion Data Intelligenceでのデータ・リフレッシュは、複雑なプロセスです。リフレッシュ期間の日々の変動が予想されます。
一般的なデータ・リフレッシュには、次のプロセスが含まれます。
- Oracle Fusion Cloud Applicationsまたは他のサード・パーティ・ソースからデータを抽出します。
- 分析可能な事前構築済みスキーマにデータを変換します。
- Oracle Autonomous AI Lakehouseへのデータのロード。
- データ共有機能を使用した外部ターゲットとのデータの共有。
データ・リフレッシュのパフォーマンスに影響する要因
データのリフレッシュに必要な時間、および結果として得られるすべての主要メトリックとダッシュボードは、いくつかの要因に依存します。
これらには次のものがあります。
- ソース・システムの可用性 – ソース・システムが使用できない場合、リフレッシュは一時停止して待機します。通知が送信されます。アクセスの問題が無効な資格証明によって発生したことがシステムで判断できる場合、「リクエスト履歴」および「ウェアハウス・リフレッシュ統計」には、ソース可用性のためにリフレッシュがキューに入れられたかどうかが表示されます。
- ソース・システムでのリソースの可用性 – ソース・システム・リソースがOracle Fusion Data Intelligence抽出プロセス以外のプロセスによって消費されると、Oracle Fusion Data Intelligenceのデータ・リフレッシュで遅延が発生します。これは、Oracle Fusion Cloud Applicationsに特に当てはまります。
- ソース・データのサイズと複雑さ – 一般に、リフレッシュ中に処理されるデータの量は、リフレッシュにかかる時間を示すよい指標ですが、必ずしもそうではありません。ウェアハウス・リフレッシュ統計には、ボリューム全体を示すことができる公開済レコードの数が含まれます。ウェアハウス・リフレッシュ統計の表示を参照してください。
- アクティブ化された機能領域 – 一般に、機能領域が多くなるほど、処理するデータが多くなり、リフレッシュが長くなります。
- カスタムSQLクエリ – Oracle Autonomous AI Lakehouseでカスタムクエリを実行している場合、パイプラインに必要なリソースを消費できるため、全体的なリフレッシュパフォーマンスに影響する可能性があります。
- カスタム・ダウンストリーム処理による表のロック- ダウンストリーム・プロセスがOracle Fusion Data Intelligence表に対するロックを取得し、保持する時間が長すぎる場合、Oracle Fusion Data Intelligenceによって実行されるデータ・リフレッシュの遅延が発生する可能性があります。
- ソース・システム・オブジェクトに対して行われたカスタマイズ – カスタマイズでそれらのオブジェクトのフル・ロードが必要な場合、リフレッシュに時間がかかります。
- ソースおよびターゲットのシステム・メンテナンス – パッチ適用などのシステム・メンテナンス・アクティビティは、パイプライン・プロセスを一時停止または遅延させることができ、全体的なリフレッシュ時間が長くなる可能性があります。
- カスタム・データ・パイプライン – カスタム・データ・パイプラインのデータ拡張スクリプトで複雑な変換ロジックが使用されている場合、全体的なリフレッシュ時間に影響する可能性があります。
データ・リフレッシュのパフォーマンスに関する考慮事項
データ・リフレッシュに影響する様々な要因を考慮すると、完了時間は日ごとに異なります。
データ・リフレッシュのパフォーマンスに影響するファクタを参照してください。
パイプライン・パフォーマンスは共有責任であるため、Oracleはスケーラブルなプラットフォーム、構成制御および使用ガイダンスを提供し、データ量、ソース・システムの準備状況、変換設計(カスタム・データ・パイプラインが使用されている場合)、スケジューリングおよび環境固有の構成を管理します。最適な結果を得るには、構成への継続的なユーザーの関与、データ・リフレッシュに影響する様々な要因の予防的な監視、およびOracle推奨のプラクティスとツールの遵守が必要です。
リフレッシュ・パフォーマンスを最適に保つために、次のアクションを検討してください。
- アクティブ化された機能領域 - 分析ビジネス・ニーズに必要な機能領域のみをアクティブ化します。必要なものから始め、すべてを事前に有効にするのではなく、新しい要件が発生したときにさらに追加します。機能領域のデータ・パイプラインのアクティブ化を参照してください。分析に重要ではない機能領域をすべて削除します。機能領域のデータ・パイプラインを非アクティブ化するを参照してください。
- 頻繁なデータ・リフレッシュにおけるモジュールおよびデータ表– 頻繁なデータ・リフレッシュ機能を使用して、日中業務分析のビジネス・ニーズに必要なモジュールのみを追加します。分析に重要でないモジュールをすべて削除します。「頻繁なデータ・リフレッシュV2の構成(プレビュー)」および「頻繁なデータ・リフレッシュのパフォーマンスに関する考慮事項」を参照してください。
- 初期抽出日– この設定は、ウェアハウスに抽出、変換および格納されるデータを制御します。実際のビジネス要件に基づいて慎重に構成します。絶対初期抽出日ではなく、相対初期抽出日の使用を検討してください。「パイプライン・パラメータについて」を参照してください。これは、構成可能な勘定科目分析機能を使用している場合に特に有効です。構成可能な勘定科目分析を参照してください。
- カスタム抽出– カスタム・データ抽出がソース・システムで実行されている場合、リソースについて競合し、データ・リフレッシュを遅延できます。たとえば、Oracle Fusion Data Intelligence抽出プロセスと並行して実行されるカスタムBusiness Intelligence Cloud Connector (BICC)抽出によって、Oracle Fusion Data Intelligenceのリフレッシュが遅くなる場合があります。遅延を回避するには、Oracle Fusion Data Intelligenceデータ・リフレッシュ・ウィンドウ中に他のカスタム・リフレッシュ・ジョブが実行されていないことを確認します。特定のリフレッシュに予想より時間がかかる場合は、「ウェアハウス・リフレッシュ」統計を使用して、データ・リフレッシュ時にカスタム抽出による遅延があるかどうかを判断します。ウェアハウス・リフレッシュ統計の表示を参照してください。
- Oracle Autonomous AI Lakehouseの高サービス・セッション – データ・リフレッシュ・プロセスは、使用可能なウェアハウス・リソースによって異なります。Highサービス・セッションが実行されている場合、容量を消費し、ウェアハウスへのデータの公開を遅らせることができます。「Oracle Fusion Data Intelligenceに関連付けられたAutonomous AI Lakehouseの使用ガイドライン」を参照してください。特定のリフレッシュに予想より時間がかかった場合は、「ウェアハウス・リフレッシュ」統計を使用して、データ・リフレッシュ中に高セッションがあったかどうかを判断します。ウェアハウス・リフレッシュ統計の表示を参照してください。
- ダウンストリーム・カスタムETLプロセス– データ・リフレッシュ・プロセスには、データ・ウェアハウス内の表への中断のないアクセスが必要です。これらの表にアクセスし、ロングヘルド・ロックを取得するカスタムETLプロセスは、Oracle Fusion Data Intelligenceリフレッシュ・ウィンドウの外部でスケジュールする必要があります。
- 優先リフレッシュ– 増分リフレッシュ内でも、特定のデータを最初にリフレッシュする場合は、優先リフレッシュ用にウェアハウス表を選択できます。ただし、これは、ほかのデータセットよりも前にリフレッシュすることが本当に重要である限定されたテーブルのセットに対してのみ使用します。増分リフレッシュのデータセットの優先順位付け(プレビュー)を参照してください。
- 機能領域スケジュールの上書き– アクティブにした機能領域を確認し、ビジネス・ニーズに基づいて更新時間をずらすことを検討します。これにより、日次増分パイプライン・リフレッシュによる処理負荷が軽減されます。機能領域のデータ・パイプライン・スケジュールの上書き(プレビュー)を参照してください。
- Fusion拡張ソース– データ拡張が主にダウンストリーム統合に使用される場合は、データセットにFusion拡張ソースを使用することを検討してください。このオプションを使用すると、拡張リフレッシュを、Oracle Fusion Cloud Applicationsの機能領域の日次増分リフレッシュと並行して実行できます。これにより、Oracle Fusion Cloud Applicationsソースの増分リフレッシュ・パフォーマンスが向上します。また、Fusion Augmentationsソースを使用したデータ拡張に対して異なるリフレッシュ頻度を有効にすることもできます。Oracle Fusion Cloud Applicationsでのリソースの競合を回避するために、Oracle Fusion Cloud ApplicationsソースおよびFusion Augmentationsソースに基づくリフレッシュを段階的にスケジュールします。Fusion Augmentations Sourceを使用したデータ拡張の実行を参照してください。
- リクエスト時にステージ優先度変更のリフレッシュ– スケジュール済増分リフレッシュの場合、サービス・リクエストを申請して、特定のモジュールをプライマリ・ステージからセカンダリ・ステージに移動できます。「増分データ・リフレッシュのスケジュール」を参照してください。これにより、より重要なビジネス・ニーズをより早く実現できます。