説明が必要: 伝票引き出し者とレビュー担当者のロジックは、サブモジュールのエラスティック フィールドを介して伝票のフレックスフィールドに送信されず、取得するにはサブモジュールに侵入する必要があり、各サブモジュールの抽出ロジックはそのままです。現状では伝票明細や補助元帳の規模が数千万件となっている 複数テーブルの結合クエリはSQL書き換えコストが高すぎるため効率がやや低い ビジネスロジックを変更しない前提コードを可能な限りコード化し、コード構造を変換し、最適化のためのパラメータ設定を行います。
試した方法：以下の方法を連続して試した
SQLチューニング
Oracle の組み込み SQL 実行プランを使用して書き換えると、書き換えられた実行プランではあまり良い結果が得られませんでした。
SQLの書き換え
SQL の書き換え: 複数の SQL を一時テーブルに部分的に抽出するのではなく、サブカテゴリからの複数の SQL を大きなビューにマージします。結果は元の SQL よりも遅くなり、現実的ではありません。
Dbms_Parallel_Execute
Dbms_Parallel_Execute では、この並列処理は主にエンティティ テーブルに使用されます。これは、セッション ベースの一時テーブルに基づいてタスクを分解するときにデータが見つからず、これは現実的ではないためです。
パイプライン関数
パイプライン関数は通常、ストリーミング メディア テクノロジと同様に、クエリの結果グループを具体化する必要はありません。従来の結合クエリは結果セットを具体化してから結果を出力しますが、パイプライン関数はすぐに結果を返すことができます。それは実行され、並行して開くことができます。
パイプライン関数技術を使用すると、1.のビューに対応する OBJECT と TYPE が確立されますが、結果は最適化前ほど理想的ではありません。
キャッシュ機能
同じ入力パラメータの場合、キャッシュ関数は結果を取得するために SQL を実行する必要がなく、戻り値を直接キャッシュします。
作成者の取得と本人確認のロジックをキャッシュ関数にカプセル化しますが、クレデンシャルje_header_id + クレデンシャル行je_line_numの入力パラメータは再利用率が高くないため、即効性が分かりません。
マテリアライズドビュー
マテリアライズド ビューはエンティティ テーブルと同等であり、主に DB_LINK インタラクションの共同クエリに使用され、ネットワーク待機による時間の浪費を回避し、時間のためのスペースを使用します。
CREATE MATERIALIZED VIEW xxxx_MV
REFRESH FORCE ON DEMAND
START WITH TO_DATE('23-06-2021 11:04:22', 'DD-MM-YYYY HH24:MI:SS') NEXT SYSDATE+5/(24*60) --每五分钟刷新一次
AS
--select 逻辑
マテリアライズド ビューを使用する場合は、2 つのリフレッシュ方法に注意する必要があります。1 つはマテリアライズド ビューのログ テーブルに依存しないフル リフレッシュで、もう 1 つはエンティティごとにログ テーブルを作成する必要がある増分リフレッシュです。マテリアライズド ビュー用に設計されたテーブル。これらの方法はどちらもデータベースのパフォーマンスに影響を与えます。これには一定の効果がありますが、リアルタイム データは遅延し、遅延時間はマテリアライズド ビューのリフレッシュ時間に依存します。
最終用途
マテリアライズド・ビュー + 関数キャッシュ + SQL リライト + (マージ比較)
サブ分類されたアカウントのすべてのクエリ ロジックをマテリアライズド ビューにカプセル化し、ジョブのタイミングによってマテリアライズド ビューを完全にリフレッシュします。
リフレッシュ間隔中に生成されたデータについては、マージ比較方式を使用して新しいデータが補完されます。
これら 2 つの方法を使用した結果、時間が大幅に改善され、当初 1 時間以上かかっていたリクエストが 10 分程度に短縮されました。DBMS_HPROF によるコードの階層分析により、標準関数が機能することがわかりました (DBMS_HPROF 経由)。 SELECTで呼び出されるCCID)を取得する COAの部分に中国語で記載されている関数は手間がかかるので、この部分をカスタマイズした関数を作りました、本質的にはキャッシュ機能を持つシェルであり、同じCCIDに対して、 SQLクエリを実行する必要がなく、キャッシュから直接データを返すため、データを返す時間を大幅に節約できます 12分かかっていたSQLをキャッシュ機能付きのシェル関数に変更したところ、2分以内に改善できました分、10 分の時間を節約できます。
包括的な変換後、以前は 1 時間以上かかっていた SQL が 2 分で実行され、結果が得られるようになりました。
要約する
ETL データ開発の候補者と面接する前に、最適化方法を尋ねることがありましたが、ほとんどの候補者は 2 つの答えを持っていました: SQL 実行計画とインデックス変換を検討することです。
SQLのパフォーマンス最適化は一回限りのプロセスではなく、SQLを書き換えられるか、現在のハードウェア性能でどの程度の並列処理をサポートできるか、空間を時間に交換できるかなど、ビジネス変革と総合的に組み合わせる必要があります。