idexを再構築するための保守計画後にトランザクションログが巨大になりました
数日前、SQL Server 2008のメンテナンスプランを使用していくつかのテストを行いました。
インデックスを再構築し、毎週完全バックアップを取るために1つ作成しました。 （私が知っている、今日私が見つけた悪いこと）。
問題は、トランザクションログが大幅に増加したため（約80 GB、DBが60 GB）、バックアップが実行されなかったことです。現在、トランザクションログを以前のサイズ（200 MBなど）に縮小する方法があるかどうかを確認するために、一日中探し回っています。
更新
これは私たちの本番サーバー上にあり、メンテナンス計画は次のとおりでした：
インデックスを再構築
成功した場合はバックアップ完全データベース
成功した場合2週間より古いバックアップを削除します。
これは完了しませんでした。いつか壊れたため、インデックスの再構築に時間がかかりすぎたと思います。そのため、バックアップは行われませんでした。
また、トランザクションログも毎時間バックアップしています。
これは可能ですか？なぜこれが起こるのですか？再構築中にインデックスのコピーがトランザクションログなどに作成されることはわかっていますが、このコピーを削除することはできますか？
これは私がジョブ履歴に持っているものなので、インデックスを作成するときに何らかの理由で失敗したように見え、計画は成功していたため、そこで停止しました。
メッセージ：
ユーザーとして実行：SHOCKLOGIC\DB1 $。 ... ress：2013-08-05 03：01：03.43 Source：Rebuild Index Task Querying Executing query "ALTER INDEX [PK_ActivitiesPerGroup] ON [dbo]。[Acti ..." .: 12％complete End Progress Progress：2013- 08-05 03：01：03.43出典：クエリ「USE [Eventlogic]」を実行するインデックスタスクの再構築：12％完了終了進行状況：2013-08-05 03：01：03.52出典：クエリを実行するインデックスタスクの再構築 "ALTER INDEX [PK_ActivitiesPerHotelCat] ON [dbo]。[A ... ".: 12％完了終了進行状況：2013-08-05 03：01：03.52ソース：再構築インデックスタスククエリ「USE [Eventlogic]」を実行しています。：12％終了の進行状況の完了：2013-08-05 03：01：03.69ソース：インデックスの再構築タスククエリ「ALTER INDEX [PK_ActivitiesPerHotelCat_OLD] ON [dbo ...」の実行：12％終了の進行状況の完了：2013-08-05 03 ：01：03.69ソース：クエリ「USE [Eventlogic]」を実行するインデックスタスクの再構築。：12％完了進行状況の進捗：2013-08-05 03：01：08.61ソース：インデックスタスクを実行するクエリの再構築。 ".: 13％完了En d Progress Progress：2013-08-05 03：01：08.61 Source：Rebuild Index Task Executing query "USE [Eventlogic]"。：13％complete End Progress Progress：2013-08-05 03：01：12.85 Source：Rebuild Indexタスク実行クエリ "ALTER INDEX [_dta_index_ActivitiesPerPerson_10_292 ..." .: 13％complete End Progress Progress：2013-08-05 03：01：12.85 Source：Rebuild Index Task Executing query "USE [Eventlogic]"。：13％complete End進行状況進行状況：2013-08-05 03：01：20.44ソース：インデックスの再構築タスククエリを実行しています "ALTER INDEX [IX_ActivitiesPerPerson] ON [dbo]。[Act ..." .: 13％完了終了進行状況進行状況：2013-08- 05 03：01：20.44 Source：Rebuild Index Task Executing query "USE [Eventlogic]"。：13％complete End Progress Progress：2013-08-05 03：01：57.55 Source：Rebuild Index Task Executing query "ALTER INDEX [PK_ActivitiesPerPerson ] ON [dbo]。[Act ... ".: 13％完了終了進行状況：2013-08-05 03：01：57.55ソース：インデックスの再構築タスククエリ「USE [Eventlogic]」を実行しています。：14％完了終了進行状況進行状況：201 3-08-05 03：01：57.58ソース：クエリを実行するインデックスタスクの再構築 "ALTER INDEX [PK_ActivityGroupInputTypes] ON [dbo] ...." .: 14％完了終了進行状況：2013-08-05 03:01： 57.58ソース：インデックスの再構築タスク実行クエリ "USE [Eventlogic]"。：14％完了終了進行状況：2013-08-05 03：01：57.65ソース：インデックスの再構築タスク実行クエリ "ALTER INDEX [PK_ActivityGroupTypes] ON [dbo] 。[Acti ... ".: 14％完了完了進行状況：2013-08-05 03：01：57.66ソース：インデックスの再構築タスククエリ" USE [Eventlogic] "を実行しています。：14％完了完了進行状況：2013- 08-05 03：01：57.66ソース：インデックスの再構築タスククエリ "ALTER INDEX [PK_ActivityGroupTypeForGroups] ON [db ..."を実行しています。：14％完了終了進行状況：2013-08-05 03：01：57.66ソース：再構築インデックスタスク実行クエリ "USE [Eventlogic]"。：14％完了終了進行状況：2013-08-05 03：01：57.74ソース：再構築インデックスタスク実行クエリ "ALTER INDEX [PK_ActivityInputTypes] ON [dbo]。[Acti。 .. ".: 15％完了終了進行状況P rogress：2013-08-05 03：01：57.74 Source：Rebuild Index Task Executing query "USE [Eventlogic]"。：15％complete End Progress Progress：2013-08-05 03：01：57.77 Source：Rebuild Index Task Executingクエリ "ALTER INDEX [PK _Activity _ B7BCF0184055F19F] ON [d ..." .: 15％complete End Progress Progress：2013-08-05 03：01：57.77 Source：Rebuild Index Task Executing query " USE [Eventlogic] "。：15％完了終了の進行状況：2013-08-05 03：01：57.88ソース：インデックスの再構築タスククエリの実行" ALTER INDEX [PK_AddressConfirmationScreenFieldsLan ... ".: 15％完了終了の進行状況：2013 -08-05 03：01：57.88 Source：Rebuild Index ...パッケージ実行fa ...ステップは失敗しました。
インデックスを再構築するには、新しいインデックスを作成するために十分なスペースが必要です。単純化した経験則では、元のインデックスが使用する領域の約120％が必要であるようです。これは、SORT_IN_TEMPDBがオンかオフかに応じて、データベースまたはtempdbに存在する可能性があります。
可能であれば、SORT_IN_TEMPDB = ONを使用して、実行されるロギングの一部を減らします。
LOGバックアップの間にすべてのインデックスを再構築すると、すべてのインデックスのインデックスを再作成するためのすべてのログがログファイルに記録されます。したがって、大規模な再編成には、ディスク領域、ログ領域などの適切なリソースが必要です。 （たとえば、一度に1つのテーブルを再編成し、それぞれの後にログバックアップを実行する場合があります。）
インデックススペースが必要な場合： http://msdn.Microsoft.com/en-us/library/ms191183（v = sql.110）.aspx トランザクションログの場合： http：// msdn.Microsoft.com/en-us/library/ms184246.aspx
SIMPLEやBULK_LOGGEDなどの最小限のログが記録された復旧モデルに変更してみてください。ただし、運用データベースの場合は、マイナスの副作用を比較検討し、最適なものを決定する必要があります。 （databsseを再編成するためにSIMPLEに変更した後、おそらくFULLに変更してFULLバックアップを実行する必要があります。）
ログファイルは縮小できますが、上位ページがログバックアップによって解放された後でなければなりません。 （これは通常、バックアップログ、DBCC SHRINKFILEのサイクルであり、スペースを確認してから再試行してください。）
ログファイルを圧縮する場合は、DBCC SHRINKDATABASEを使用しないようにします。 DBCC SHRINKFILE（logfilename、targetsize）を使用します。
インデックスを再構築し、毎週完全バックアップを取るために1つ作成しました。 （私が知っている、今日私が見つけた悪いこと）。
正しい。
これらのプロセスは分離して、独立して実行できるようにする必要があります。確かに、インデックスの再構築が成功したか失敗したかに関係なく、バックアッププロセスは続行されます。しかし、それを修正しようとしないでください。
常に完全にインデックスを再構築する必要はほとんどなく、通常は非常にコストがかかります。まず、インデックスが断片化されているかどうかとその程度を判断してから適切なアクションを実行する、よりインテリジェントなプロセスを使用することをお勧めします。私は個人的にこれを使用するために Ola Hallengrenのスクリプト を使用して推奨しています。
問題は、トランザクションログが大幅に増加したため（約80 GB、DBが60 GB）、バックアップが実行されなかったことです。現在、トランザクションログを以前のサイズ（200 MBなど）に縮小する方法があるかどうかを確認するために、一日中探し回っています。
コメントであなたが私に言ったことに基づいて、「失敗した」（実行されなかった）バックアップはfullバックアップでした。 トランザクションログバックアップがすべて成功したと仮定すると、DBCC SHRINKFILE（またはSSMS GUI、より簡単）を使用してログファイルを元に戻すことができます。合理的なサイズ。
再構築中にインデックスのコピーがトランザクションログなどに作成されることはわかっていますが、このコピーを削除することはできますか？
そもそもそれが作成されるのを防ぐことはできません。そのため、常に再構築を行うのは非常にコストがかかります。また、前述のスクリプトを使用することをお勧めします。
トランザクションログがバックアップされると、使用されたスペースを再利用するか、SHRINKFILEの一部としてO/Sに解放できます。
スペースを解放するには、最初に復旧モデルを完全から単純に変更する必要があります。次に、前述のようにスペースを解放できます。完了後、単純から完全に戻すことができますが、これは一時的な修正です。ログは最終的に遅かれ早かれ再び成長します。