特定の操作がさまざまな復旧モデルでどのようにログに記録されるかをテストしています。以下は、これまでに実行した手順です。
1.完全復旧モデルでデータベースを作成する
2。バックアップを取る
3。テーブルを作成し、1,000万レコードを挿入します
4。ログのバックアップを取り、VLFカウントを確認して、ログ領域の空き率を確認します
5。次に、インデックスの再構築を行い、fn_dblog関数を使用して生成されたレコードを確認します
6.今、私はバルクリカバリモデルに切り替えました
7。バックアップを取った
8。ログのバックアップを取ります
9。インデックスの再構築を行いました
奇妙なことに、インデックスの再構築は以下のエラーで失敗します。
ステートメントは終了されました。メッセージ9002、レベル17、状態2、行1 'LOG_BACKUP'により、データベース 'bulklogging'のトランザクションログがいっぱいです。
それは真実ではありません
1.logスペースの自動拡張が制限されない
2.ログファイルが保存されている場所のスペース
スペースがあり、自動拡張が制限されていなくても、エラーが発生する理由を理解できる人がいますか?
インデックスサイズの画像を追加しています。
問題は解決しましたが、この変更がどのように違いをもたらしたかはわかりません。
コメントは2つの長いと言っています-したがって、ここに投稿します...
復旧モデルを変更した後、インデックスを再度スクリプト化し、それが機能しました。さらに、スクリプト化されたインデックスの前後がまったく同じままで、セッションのみが変更されました。しかし、これがどのように機能したかはわかりません。
前:
USE [bulklogging]
GO
ALTER INDEX [PK__bcc__3213E83FAC9DB5ED] ON [dbo].[bcc]
REBUILD PARTITION = ALL WITH (PAD_INDEX = OFF,
STATISTICS_NORECOMPUTE = OFF, SORT_IN_TEMPDB = OFF, ONLINE = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON)
GO
後:
USE [bulklogging]
GO
ALTER INDEX [PK__bcc__3213E83FAC9DB5ED] ON [dbo].[bcc]
REBUILD PARTITION = ALL WITH (PAD_INDEX = OFF,
STATISTICS_NORECOMPUTE = OFF, SORT_IN_TEMPDB = OFF, ONLINE = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON)
GO
この質問を閉じるための更新:
Fn_dblogを使用してログレコードをチェックしています。これには、説明されているように隠れたバグがあるようです here 、これは私のログの増加に影響している可能性があります。
編集8/15/13:注意してください– Jonathanは、fn_dump_dblogが呼び出されるたびに、新しい隠しSQLOSスケジューラーと最大3つのスレッドを作成することを発見しました。サーバーが再起動するまで)。これは、SQLチームが修正する予定のバグであり、警告が出されています。注意して使用してください。
編集5/15/15:SQL Server 2012 SP2 +およびSQL Server 2014で修正されました。この修正は以前のバージョンではバックポートされません。
このエラーは、LOG_BACKUPが原因でトランザクションログがいっぱいになるために発生します。したがって、このデータベースではアクションを実行できません。この場合、SQL Serverデータベースエンジンで9002エラーが発生します。
この場合、あなたはしなければなりません
注:縮小操作は、縮小コマンドの実行中にSQL Serverのパフォーマンスに影響します。また、インデックスの断片化を引き起こし、インデックスの範囲を検索するクエリのパフォーマンスを低下させる可能性があります。
したがって、運用開始前に、ログファイルを頻繁にバックアップして LOG_BACKUPメンテナンスプラン を準備し、本番環境での圧縮操作を回避することをお勧めします。
詳細については、 を確認してください。LOG_BACKUP により、データベース「SharePoint_Config」のトランザクションログがいっぱいです
これがあなたを助けることを願っています