私は例を見つけようとしましたが、それらはすべて単一のwhere句で単純です。これが状況です。別のデータベースから転送されたレガシーデータがたくさんあります。同じデータベースに「良い」テーブルもあります。レガシーテーブルからwテーブルにデータを転送（データ変換）する必要があります。これは別のテーブルセットであるため、データ変換では、古いデータを新しいテーブルに正しく配置するために複雑な結合が必要です。
したがって、古いテーブルは古いデータです。
新しいテーブルには古いデータが含まれている必要がありますが、その古いデータを新しいテーブルに正しく取り込むには、多くの結合が必要です。
このような結合が多いダイレクトパスを使用できますか？INSERT SELECT（多数の結合）ダイレクトパスは、同じデータベース上にすでに存在するテーブルに適用されますか（テーブル間で転送）？たとえばテキストファイルからテーブルをロードするためだけですか？
ありがとうございました。
いいえ、逆に、データベースをバックアップできないということではなく、NOLOGGINGのロード後にバックアップを実行する必要があることを意味します。
少し詳しく説明させてください。通常、OracleでDMLを実行すると、行っている変更の変更前のイメージがUNDOに記録され、すべての変更（UNDOの変更を含む）が最初にREDOに書き込まれます。これは、Oracleがトランザクション、インスタンスリカバリ、およびデータベースリカバリを管理する方法です。トランザクションが中止またはロールバックされた場合、OracleはUNDOの情報を使用して、トランザクションに加えられた変更を元に戻します。インスタンスがクラッシュした場合、インスタンスを再起動すると、OracleはREDOおよびUNDOの情報を使用して、最後にコミットされたトランザクションまでリカバリします。まず、OracleはREDOを読み取り、ロールフォワードします。次に、UNDOを使用して、クラッシュ時にコミットされなかったすべてのトランザクションをロールバックします。このようにして、Oracleは最後にコミットされたトランザクションまで回復できます。
これで、挿入ステートメントにAPPENDヒントを指定すると、Oracleは直接ロードでINSERTを実行します。これは、データが最高水準点より上から、これまで使用されたことのない新しいブロックにロードされることを意味します。ロードされるブロックは真新しいため、「ビフォア・イメージ」がないため、OracleはUNDOの記述を回避でき、パフォーマンスが向上します。データベースがNOARCHIVELOGモードの場合、OracleはREDOも書き込みません。ARCHIVELOGモードのデータベースでは、挿入/ *+追加*/を実行する前に、テーブルをNOLOGGINGに設定しない限り（つまり、テーブルtab_name nologging;を変更しない限り）、OracleはREDOを書き込みます。その場合、テーブルのREDOロギングは無効になります。ただし、これはバックアップ/リカバリの影響に遭遇する可能性がある場所です。NOLOGGINGの直接ロードを実行した後、メディア障害が発生した場合、nologging操作のあるセグメントを含むデータファイルは、nologgingロードの前に作成されたバックアップから復元されます。その場合、REDOログには、そのセグメントを回復するために必要な変更は含まれません。それで、何が起こりますか？NOLOGGINGロードを実行すると、Oracleは、実際の変更ではなく、エクステント無効化レコードをREDOログに書き込みます。次に、そのREDOをリカバリで使用すると、それらのデータブロックは論理的に破損しているとマークされます。そのセグメントに対する後続のクエリは、ORA-26040エラーを受け取ります。
だから、これを回避する方法は？さて、NOLOGGINGの直接ロードの直後に常にバックアップを取る必要があります。ロギングなしのロード後に作成されたバックアップから復元/復元する場合、データは復元されたファイルのデータブロックにあるため、問題はありません。
それが明確であることを願っています、
-マーク
SELECT 内のクエリは、ダイレクト パス挿入を使用すると、必要に応じて複雑にすることができます。direct-path は宛先テーブルのみを参照します。データが読み取られたり処理されたりする方法とは関係ありません。
ダイレクト パス挿入を実行している場合は、テーブルの最高水準点より上に新しいデータを挿入するように Oracle に要求しているため、新しい行を挿入するために既存のブロックの領域を再利用する通常のコードをバイパスします。また、ダイレクトパス挿入中にテーブルの最高水準点を変更できないため、他の挿入をブロックする必要があります。ロードを実行するダウンタイム ウィンドウがある場合、これはおそらく大したことではありませんが、ロード中に既存のテーブルを他のアプリケーションで使用できるようにする場合は、非常に問題になります。
はい、クエリの複雑さに恣意的な制限を設けるべきではありません。
/*+ APPEND */ を target_table に挿入する場合は、source1、source2...、sourceN から .... を選択します。
それはうまくいくはずです。ただし、ロードのパフォーマンスはそのクエリのパフォーマンスによって制限されることを考慮してください。したがって、優れたパフォーマンスが期待される場合は、十分に調整してください。
最後に、ターゲット表に NOLOGGING を設定するとパフォーマンスが大幅に向上するかどうかを検討してください。ただし、NOLOGGING を実装する場合は、バックアップ リカバリへの影響も考慮してください。
それが役立つことを願って、
-マーク