1

SQL Serverデータベースに対していくつかのクエリを実行してから、削除します。理想的には、これはすべてトランザクション内（つまりアトミック）で発生します。

ただし、実際には、データがバッファから削除されてから長い時間が経過しているため、SQL Serverは、トランザクションT-SQLを完了するために多くの物理IOを実行する必要があります。バッチ全体の実行に30秒以上かかる場合、ユーザーはタイムアウトの問題を経験するため、これは問題になる可能性があります。

selectを分割して実行すると、最終的なSQLを実行するたびに、SQLServerが必要なデータでバッファをいっぱいにすることに気付きました。例えば：

最初の実行：

 BEGIN TRANSACTION
 SELECT ... WHERE ...
 ROLLBACK

2回目の実行：

 BEGIN TRANSACTION
 SELECT ... WHERE ...
 SELECT ... WHERE ...
 ROLLBACK

..。

n回目の実行：

BEGIN TRANSACTION
SELECT ... WHERE ...
SELECT ... WHERE ...
...
SELECT ... WHERE ...
ROLLBACK

そして、私が最終的な実行に到達するまでに：

BEGIN TRANSACTION
SELECT ... WHERE ...
SELECT ... WHERE ...
...
SELECT ... WHERE ...
DELETE FROM ... WHERE ...
COMMIT

バッファが事前に入力されているため、バッチ全体が高速に実行されます。

SET NOEXEC ONSQL Serverが実際のデータ変更を実行せず、ロックを取得せず、必要なデータでバッファーをいっぱいにするSQL Serverのモード（つまり）はありますか？例えば

SET NOEXEC ON
EXECUTE ThatThingYouDo

SET NOEXEC OFF
EXECUTE ThatThingYouDo

また

SET DRYRUN ON
EXECUTE ThatThingYouDo

SET DRYRUN OFF
EXECUTE ThatThingYouDo
4

2 に答える 2

1

問題を解決するために通常とはまったく異なることをしようとするときはいつでも、基本的な設計が問題である可能性が高いことがわかりました。これは非常に正常ではありません。

おそらく、非常に時間がかかるDELETE（テーブルサイズ、アクティビティ、インデックス、削除する行、実行中の他のプロセスなど）に関する詳細情報を提供でき、インデックスやロックなどを使用して対処する従来のソリューションがあります。 。

于 2010-03-03T20:02:20.467 に答える
1

いいえ
。挿入された行にINSERTの後にUPDATEが続くとします。挿入された行が存在しないため、UPDATEをエミュレートすることはできません。さて、この場合、なぜトランザクションで選択するのですか？デフォルトでは（つまり、HOLDLOCKなどを使用しない限り）、トランザクションの期間中は行をロックしません。

バッファプール（別名データキャッシュ）が「フル」であると思われる場合は、RAMを増やすか、その他のアップグレード/スケールアップが必要です。

于 2010-03-03T20:07:03.610 に答える