単純に見えるクエリに問題がありますが、開発環境では多くの問題を引き起こしています。
私がやろうとしているのは、新しいテーブルにある新しい記事 ID で articleID を変更することです。
+-----------------+ | | コメント | +-----------------+ | | シド | 記事ID | +-----------------+ | | 1 | 1 | +-----------------+ | | 2 | 1 | +-----------------+ | | 3 | 2 | +-----------------+ +------------------------+ | | 新しいコメント | +------------------------+ | | コメント ID | 記事ID | +------------------------+ | | 1 | 10 | +------------------------+ | | 2 | 10 | +------------------------+ | | 3 | 32 | +------------------------+
そして、テーブルの「コメント」が次のように終わることを望みます:
+-----------------+ | | コメント | +-----------------+ | | シド | 記事ID | +-----------------+ | | 1 | 10 | +-----------------+ | | 2 | 10 | +-----------------+ | | 3 | 32 | +-----------------+
だから私はこのクエリを実行します:
UPDATE comments SET comments.articleID = new_comments.articleID_new
FROM comments INNER JOIN new_comments
ON comments.cid = new_comments.comment_id;
問題は、ここではディスクに 20GB の空き容量があることです。このクエリを実行すると、トランザクション ログが大きくなり始め、クエリが終了する前に利用可能なすべての空き容量を使用してしまいます。6 分で、ディスクの 20GB の空き容量がなくなります。
リカバリモードをシンプルに変更しました。ただし、問題は解決せず、トランザクション ログは増え続けます。
ここでスタックオーバーフローで見た次のクエリを使用して、データベースのトランザクション ログが大きくなっているのを確認できます。
SELECT (size * 8.0)/1024.0 AS size_in_mb,
CASE
WHEN max_size = -1 THEN 9999999 -- Unlimited growth, so handle this how you want
ELSE (max_size * 8.0)/1024.0
END AS max_size_in_mb
FROM MyDatabase.sys.database_files
WHERE data_space_id = 0;
クエリがそのような量の情報をトランザクションログに書き込むのを防ぐために、どのようなオプションがあるか、または何ができるかを知っている人はいますか?