データ・リフレッシュのパフォーマンスに関する考慮事項
データ・リフレッシュに影響する様々な要因を考慮すると、完了時間は日ごとに異なります。
データ・リフレッシュのパフォーマンスに影響するファクタを参照してください。
パイプライン・パフォーマンスは共有責任であるため、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を使用したデータ拡張の実行(プレビュー)を参照してください。
- リクエスト時にステージ優先度変更のリフレッシュ– スケジュール済増分リフレッシュの場合、サービス・リクエストを申請して、特定のモジュールをプライマリ・ステージからセカンダリ・ステージに移動できます。「増分データ・リフレッシュのスケジュール」を参照してください。これにより、より重要なビジネス・ニーズをより早く実現できます。