web-dev-qa-db-ja.com

メンテナンスプランを使用したトランザクションログサイズの管理

SQL Server 2008でメンテナンスプランを構成するためのベストプラクティスはありますか？現在、データベースのバックアップと40時間以上前のトランザクションログを削除してからバックアップしています。私が見た問題は、トランザクションログがまだ非常に大きいということです。データベース計画の縮小タスクを含める必要がありますか？

sql-serversql-server-2008transaction-logmaintenance-plans
7
Neil Knight

ログファイルのサイズが大きくなっている場合は、次のことの少なくとも1つを間違っています。

  • ポイントインタイムリカバリが必要な場合は、ログ（およびおそらくデータベースも）を十分な頻度でバックアップしていません。おそらく、データベースを毎日または毎週バックアップする保守計画を作成しましたが、ログをバックアップする保守計画を構成していません。
  • ポイントインタイムリカバリが必要ない場合は、完全復旧モデルを使用していますが、必要ありません。データベースの復旧モデルをシンプルに切り替えることができるはずです。これは、最後の完全バックアップまたは差分バックアップの時点までしか回復できないことを意味しますが、ログファイル自体がチェックされたままになることも意味します。
  • どちらの復旧モデルでも、非常に長時間実行されるトランザクションがあることが問題である可能性があります。のように、誰かがBEGIN TRANSACTION、彼らのワークステーションをロックして、休暇に行きました。

これに関するより多くの詳細はこの質問で見ることができます：

現時点でログを圧縮するために、完全復旧モデルを使用していて、その状態を維持したい場合は、次の手順を実行してログチェーンを再起動し、安全を確保する必要があります。

USE [master];
GO
ALTER DATABASE db_name SET SINGLE_USER WITH ROLLBACK IMMEDIATE;
GO
-- if you are already in simple, remove this line:
ALTER DATABASE db_name SET RECOVERY SIMPLE;
GO
CHECKPOINT;
GO
-- if you're already in simple, or want to stay that way, remove this line:
ALTER DATABASE db_name SET RECOVERY FULL;
GO
BACKUP DATABASE db_name TO DISK = 'path' WITH INIT, COMPRESSION;
GO
USE db_name;
GO
DBCC SHRINKFILE(N'db_name_log', 30); -- pick some size that makes sense
GO
USE [master];
GO
-- if recovery is full, re-init log chain, otherwise remove this line:
BACKUP LOG db_name TO DISK = 'path' WITH INIT, COMPRESSION;
GO
ALTER DATABASE db_name SET MULTI_USER;
GO

既にシンプルになっている（可能性が非常に低い）場合、またはシンプルに切り替えたい場合は、削除する必要がある行にコメントしました。

5
Aaron Bertrand

スケジュールされたファイルの縮小は絶対に望みません。そうしないと、恐ろしいディスクの断片化が発生します。ケースバイケースで手動で実行します。たとえば、ログバックアップの実行の失敗、または定期的に発生するとは考えられない大規模なETLなどが原因で、過度の増加が一時的なものであることが確実な場合のみ。

ビジネス/アプリケーションの保持要件を満たすのに十分な頻度でバックアップを作成します（そして、バックアップを十分に長く保持します）。また、トランザクションログを許容サイズ内に保つのに十分な頻度でログバックアップを作成する必要があることも考慮してください。私の場合、私は平日に1時間ごとにログバックアップを実行していますが、ニーズに合わせてスケジュールを調整する余地はたくさんあります。ログの肥大化を減らすためにそれらをより頻繁に実行し、ログシーケンスを復元することの苦痛を少なくするためにそれほど頻繁に実行しません。

4
db2

おそらくアクティビティの量が原因で、トランザクションログは非常に大きくなっています。特定の時点（完全復旧モード）に復元してトランザクションログを制御できるようにしたい場合は、トランザクションログのバックアップをより頻繁に行うことが答えです。

300 GB OLTP 30 GBのログスペースが割り当てられたデータベースがあります。30分ごとにログバックアップを実行するジョブがあり、割り当てられたスペースの下でもログファイルを保持します（月次インデックスの再構築。ただし、再構築中のログバックアップサイズは大きくなります）。

縮小は良い習慣ではありません。

0
RK Kuppala

メンテナンスプランを使用して、SQL ServerでDBバックアップをスケジュールします。

  • ポイントインタイムリカバリの場合、Fullスケジュールされたデータベースバックアップdaily（午前0時）とトランザクションログバックアップスケジュール4時間ごとを作成します。

  • ポイントインタイムリカバリを使用しない場合は、データベースリカバリモデルを[〜＃〜] simple [〜＃〜]としてデータベースバックアップをスケジュールdaily（午前0時）に変更します。

  • DBCC opentranを使用して開いているトランザクションを確認し、次にKILL SPIDを使用してそのトランザクションを強制終了することもできます。

  • DBCC sqlperf（logspace）を使用して、ログファイルサイズのステータスと、このログファイルで使用されている実際のスペースを取得します。空き領域がデータベースログファイルを圧縮する以上の場合。

0
dsingh

メンテナンスバックアップ計画でも、GUIやネイティブジョブのサポートなどの利点がありますが、注意が必要な欠点もあります。一貫性を維持し、プロセスの衝突を回避するために、メンテナンスバックアップ計画とエージェントジョブの両方を維持する必要があります。また、衝突の検出は行われず、同じデータベースで同時にタスクがスケジュールされている場合、タスクが失敗する可能性があります。したがって、メンテナンスプランを変更するセットを設定するたびに、詳細なテストを実行する必要があります。

0
Ivan Stankovic