アプリ版:「スタンプのみでお礼する」機能のリリースについて

SQL Server 2005 Express Editionを使用しています。

データベースは単純復旧モデルなのですが、トランザクション ログがすぐ満杯になり、9002 エラーが発行され、困っています。データベース、トランザクション ログ共にバックアップは取っていません。自動拡張もしていません。

ネットで調べると、単純復旧モデルは自動的にトランザクション ログを切り捨てるので、ログの肥大化を心配する必要はないと書いてあります。なぜ満杯になるのか不明。
(圧縮される量よりも、ログが貯まる量のほうが多い?)

トランザクションログは、ログ領域を5GBにしているのに1時間程度で満杯になり、9002 エラーが発行され困っています。

対策としては、ジョブでDBCC SHRINKFILEを定期的に発行して、トランザクション ログを削除する
案を考えていますが、イレギュラーな気がしています。他にもっといい対策案(簡単、確実)はないでしょうか?

A 回答 (1件)

単純復旧モードにしていれば、コミットされたトランザクションはトランザクションログに残らず解放されます。


しかし、コミットされていないトランザクションは解放されていません。

今回のケースですと、何か長いバッチ処理がはしっていませんか?
もしくは、大量のデータを一気に更新する処理をしていませんか?

例えば2時間かかるバッチ処理をワントランザクションで実行していると、
1時間経過して5GB使用してしまいまんぱんになることはあります。

上記のクエスチョンどちらのケースでも、DBCC SHRINKFILEしても意味がありません。
対応としては、コミット粒度の見直しか、例えばバッチ処理で必要な容量までは
トランザクションログを確保するとかでしょうか。

ワントランザクションで10GBトランザクションログが必要なら、
ワントランザクションを維持するには、ログを10GBにするしかありません。
トランザクション粒度を見なおして、1トランザクションで必要な容量を
数GBにするとかでしょうか。


ちなみに以下のケースもあるので、ご注意。

1 データ更新料は少ないが、数時間かかるトランザクション
2 10分程度でおわるがデータ更新料が多いトランザクション
3 それいがいのトランザクション

1〜3の順番にトランザクションが実行されると、1がコミットされるまでは、
2と3の分のトランザクションログは解放できないのです。
    • good
    • 0
この回答へのお礼

ご回答ありがとうございます。
大変参考になりました。

お礼日時:2015/07/05 10:40

お探しのQ&Aが見つからない時は、教えて!gooで質問しましょう!

関連するカテゴリからQ&Aを探す