0

シミュレートされたSQL2005dbを実行しているSQL2008を備えたWebサーバーがあり、テスト環境用のローカルSQL2005dbがあります。

これにより、2008サーバーのバックアップは2005サーバーに復元されないため、テスト用のデータのバックアップ/復元にスクリプトを使用します。

このSQLクエリを実行して、運用Web SQL Server（2008）のテーブルのサイズを縮小すると

 DELETE FROM TickersDay
 WHERE (DATEDIFF(day, TickersDay.[date], GETDATE()) >= 8)
 GO

このメッセージが表示されます：

 Msg 9002, Level 17, State 4, Line 3
 The transaction log for database 'VTNET' is full. To find out why space in the log
 cannot be reused, see the log_reuse_wait_desc column in sys.databases

スクリプトを公開するときにも出てきます。

このSQLコマンドを実行すると、次の結果が得られます。

 SELECT [name], recovery_model_desc, log_reuse_wait_desc
 FROM sys.databases

結果：

 [name]      recovery_model_desc       log_reuse_wait_desc

 VTNET  SIMPLE                     ACTIVE_TRANSACTION

これが私の質問と問題です：

  1. わかりました。ロールバックコマンドが必要なトランザクションステートメントがあります。

<if @@ Trancount>0ロールバック>..しかし、100個のストアドプロシージャがあるので、それを行う前に...。

  1. その間に...どうすればこの問題を根絶できますか？SHRINKINGを試し、Dbのバックアップを試しました...

  2. ご覧のとおり、SIMPLEモードです... LOG ONLYファイルをバックアップする方法がわかりません...（その方法がわかりません）...

4

1 に答える 1

1

削除が必要な日付のみのインデックスを使用して、SQLがテーブル全体を処理しないようにするだけで、この問題を回避できる場合があります。インデックスに適していると言い換えます

DELETE FROM TickersDay
WHERE TickersDay.[date] <= DATEADD(day, -8, GETDATE())
GO

これを十分な頻度で（少なくとも毎日）実行する場合、フィールドでDATEDIFFを使用する場合は、テーブル全体を調べるのではなく、TickersDay（[Date]）のインデックスを介して1/9以下を処理するだけで済みます。

それでもこれが発生する場合：

データベース「VTNET」のトランザクションログがいっぱいです

ログサイズは自動拡張に設定されておらず、この操作には十分な大きさではないと思われるため、実際にログサイズを増やす必要があります。それか、削除のバッチ処理を検討し始めます（ここでも、日付にインデックスがあると仮定しているため、これは100行のみを効率的に対象とします）。

DELETE TOP (100) FROM TickersDay
WHERE TickersDay.[date] <= DATEADD(day, -8, GETDATE())
GO

ループするか（@@ rowcount> 0の場合）、バックグラウンドの削除としてより頻繁にスケジュールすることができます。

于 2011-01-12T21:11:10.593 に答える