スケジュールに従ってトランザクションログをバックアップおよび切り捨てる最良の方法
私はDBAではありませんが、DBAの帽子をかぶってSQL Serverインスタンスのメンテナンスプランをセットアップする必要があります。 だから、わたしは自分のSSISの一晩のプロセスが実行されたされてきた一方でSQLタスクを実行してバックアップを実行するために-基本的に実行されているmaster.dbo.xp_create_subdirフォルダが、その後存在し、先を確保するためにBACKUP DATABASE [DbName] TO DISK = 'G:\Backups\DbName\DbName.bak' WITH INIT。 そのタスクが失敗すると、残りのプロセスは中止され、通知が届き、翌朝、トランザクションログのドライブがいっぱいになり、手動で切り捨てて先に進みます。 ..ストーリーが繰り返され、トランザクションログが再び使用可能なディスク領域を超えてしまうまで。 「手動切り捨て」スクリプトは次のようになります。 use Staging; alter database Staging set recovery simple alter database Staging set recovery full dbcc shrinkfile ('Staging_log', 0, truncateonly); go だから私はこれに飽きてきており、代わりに適切にやってみることを決心し、ここの手順に従って実際のメンテナンス計画を作成しました： ことは、私はこれを以前に行ったことがないので、いくつか質問があります。 このようなトランザクションログをバックアップすると、自動的に切り捨てられますか、それとも他に何かする必要がありますか？ データとトランザクションログのバックアップを同時に実行しても大丈夫ですか？そうでない場合、これを行う適切な方法は何ですか？ バックアップファイルは、サーバー上のすべてのファイルを取得して別の場所に保存する別のプロセスによって夜間に取得されます。2日後にバックアップセットを期限切れにするのは良い考えでしょうか。それらを完全に期限切れにする必要がありますか？ クリーンアップタスクは、のサブフォルダの下にある「古い」.bakファイルと.trnファイルをそれぞれ削除しますG:\Backups。それは理にかなっていますか？ バックアップが失敗した場合や失敗した場合にETLを失敗させることができるように、SSISでこれを行う方が良いでしょうか？それとも私のETLプロセスは気にすべきですか？ これが1つの投稿に対して多すぎる質問の場合は申し訳ありません。必要に応じて、編集して複数の質問をします。それらはすべて密接に関連していると思います。