問題タブ [merge-statement]

マージ ステートメントで NULL を比較するために数十億のレコードを処理する場合、どのステートメントが完璧または優れているか。SET ANSI_NULLS OFF で試しましたが、マージ ステートメントでは機能しませんでした。これが私の2つの方法です

または

何か良い対処法があれば教えてください。比較する列が約15あるため。

このマージステートメントは、ORA-00905：missingキーワード例外を発生させます。何が問題になる可能性がありますか？WHEN MATCHEDブランチに何かありますか？

だから、別の質問の続き...

エンティティ間の1-1接続のみを表すことができる既存のテーブル（PROJECT）とN-1接続（ワーカー）を表すことができるテーブルからジャンクションテーブルの行を作成するタスクをマージしました（PROJECT- WORKER）、すべてのプロジェクトには専用のリーダーが必要であり、すべてのワーカーにはプロジェクトが必要ですが、今はnn接続が必要です...このマージは次のように機能します。

しかし残念ながら、multiple matched then insertブランチはSQLの「機能」ではありません。どうすればこの問題を解決できますか？元のクエリ---）

以下のようなマージステートメントがあります

最初のレコード セット (約 300,000) では、完全に機能し、わずか 30 秒で実行されます。しかし、2 番目のレコード セット (約 300,000) では、1 時間以上かかります。

2 日前、私はそのようなセットを 50 個ロードしましたが、同じクエリが非常に高速に動作していましたが、今日からは非常に遅くなります。何が問題なのかわかりません。

注: クエリ

SELECT FROM TABLEA WITH(NOLOCK) INNER JOIN TableB .....

すべてのシーンで 20 秒かかります。

私はこの声明をあまりにも長く見てきたと思います。このステートメントの更新部分が更新されない理由を誰か教えてもらえますか? or列を使用してテストすることで!=、必要な場合にのみ更新の原因を呼び出す必要があると思います-代わりに、意図せずに更新が不要な条件を作成したようです!

ステートメントを見る前に、次の 4 つのことを知っておく必要が
あります。 1. 一時テーブル #Facilities のデータには、複数のソースからの最新のデータが取り込まれます。このデータには、ボットの新しい (挿入) データと変更された (更新) データが含まれています。
2. Merge ステートメントを実行する前に、#Facility の内容にデータが含まれていることが確認されています。
3. マージ ステートメントの挿入部分が成功します。
4. ステートメントの更新部分は変更されたデータを更新しませんが、ステートメントは失敗しません。

次のストアド プロシージャのパフォーマンスが良くありません。それを Merge ステートメントに変更したかったのです。どうすればいいのですか？以前に Merge ステートメントを使用したことがありません。助けてください

test他のテーブルからいくつかの値をテーブルに挿入し、エラーをログに記録したいと考えています。また、err_test テーブルに挿入できなかったレコードの ID をログに記録したいと考えています。疑似コードでは、これは次のようになります。

src.idが不明であるため、上記は明らかに機能しません。しかし、挿入ステートメントとして機能するマージ ステートメントを使用して、上記の挿入を行うことができます。

上記を実行した後、エラーは err_table に記録されませんが、ユーザーに返されます。

弦が長すぎる？次に、err_mesg$ の連結なしで試します。

アウチ:

それはさらに良くなります：

今私は蹴られました：

何が起きてる？1 = 2が犯人のようです。

正常に動作し、(!!) エラーがerr_table

今では問題なく動作します。

誰かがここで何が起こっているのかを説明したり、ソーステーブルからの追加情報をORA_ERR_MESG$フィールドに記録する必要がある上記の問題を解決するためのより良いアプローチを提供したりできますか?

注：私が使用できるドキュメントによると1 = 2： すべてのソース行をテーブルに挿入するには、ON句条件で定数フィルター述語を使用できます。定数フィルター述語の例は、ON (0=1) です。

次の制約を持つ次のテーブルがあるとします。

私が次のことをするとしますMERGE：

上記は失敗しますかMERGE ？最初にs 、UPDATE次にINSERTs の場合、インデックス/制約は実行中に無効化されません。しかし、最初INSERTに s を実行してからUPDATEs を実行すると、インデックスが一時的に無効になり、ステートメントが失敗する可能性があります。

Oracle RDBMSがそのような問題をどのように処理するかを誰かが詳細に説明できますか(または正しい方向を指し示すことができますか)? また、LOG ERRORS INTO句を使用する場合の扱いは同じですか？

この質問をする主な理由と解決策が必要な理由: LOG ERRORS INTO 句を使用して MERGE ステートメントを数時間実行しています。エラーログは、自律的なトランザクションとして機能しているようです。いくつかの一意の制約エラー (一意のインデックスに基づく) は、ステートメントが upserting を完了するずっと前にログに記録され (特に、シーケンスが上に行くのが見えます)、その理由はわかりません (ただし、upserting の後、一意の制約は存在しないはずです)。無効）。ERROR テーブルを調べると、ORA-00001: INSERT 操作で一意の制約 (XXX.YYY) に違反しています。このレコードを ERROR テーブルからメイン テーブルに挿入しても、一意制約エラーは発生しません。そもそもなぜエラーがログに記録されるのだろうか。

編集:以下の回答は、ステートメントが実行されると、ステートメントの最後に制約が適用されることを主張しています。私は理解し、同意します (そのようなシナリオでのインデックスのメンテナンスについて詳しく知りたいのですが)。私が理解していないこと、およびこの質問がまだ回答されていない理由は、これらの ORA-00001: 一意の制約 (XXX.YYY) に違反しているエラーがログに記録されるべきではないのに記録されている理由です。エラー ログ メカニズムがアトミックな方法で動作しないようです。

EDIT2：

EDIT3： 少しプレイして、このエラーを再現できました：

最後に、select * from err_test;私はいつも得る: ORA-00001: unique constraint (XXX.CONSTR) violated. 奇妙なことに、実際の MERGE ステートメント (本番環境) は PARALLEL では機能しなくなりましたが、それでも時々このエラーが発生します...

EDIT4： 質問自体は完全には回答されていませんが、私が承認済みとしてマークした最良の回答。Oracle の単なるバグのようです。