スケジュールに従ってトランザクションログをバックアップおよび切り捨てる最良の方法

私は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つの投稿に対して多すぎる質問の場合は申し訳ありません。必要に応じて、編集して複数の質問をします。それらはすべて密接に関連していると思います。

夜間のみSSISが書き込みを行い、日中はすべて読み取りです-私は毎日の回復のみが必要です。

ビジネスニーズに基づいて復旧モデルを選択する必要があります。

• どのくらいの量のデータビジネスが失われ、同時に生き残ることができますか？

上記の回答に基づいて、データベース復旧モデルを慎重に選択する必要があります。

簡単に言えば（一括ログ復旧モデルについては説明していません）、

• 完全復旧モデルでは、ポイントインタイムの復旧を可能にするログバックアップが可能です。
  • トランザクションログのバックアップを取ると、ログの切り捨てが発生する可能性があります。つまり、ログファイルのスペースは、各ログバックアップの後に再利用され、膨張しなくなります。
• 単純復旧モデルでは、完全バックアップのみを実行できます。ポイントインタイムリカバリは不可能です。
  • ログの切り捨ては、チェックポイントが発生した場合（手動または自動）にのみ発生します。つまり、定期的な完全バックアップを実行するため、CHECKPOINTがログファイルの非アクティブな部分を再利用するため、トランザクションログについて心配する必要はありません。

ログの切り捨てはトランザクションログファイルのサイズの物理的な縮小ではないことに注意してください。これは、トランザクションログファイルの非アクティブな部分が再利用可能としてマークされていることを意味します。

したがって、トランザクションログファイル（およびデータファイル）を適切に事前設定する必要があります。ログファイルを拡張すると、自動拡張イベントが開始されます（データベースが最後の手段として自動拡張に設定されている場合）。私の答えをチェックしてください- 自動成長-使用率？

メンテナンスプランを廃止し、[スマートメンテナンスソリューション-簡単で柔軟性があり、ベストプラクティスに従う] -5を実装することを強くお勧めします。- オラのバックアップソリューション（およびインデックスのメンテナンス・ソリューションとしても）。

あなたの質問に答えましょう：

このようなトランザクションログをバックアップすると、自動的に切り捨てられますか、それとも他に何かする必要がありますか？

バックアップを追加したり、期限切れに設定したりしないでください。彼らは大きな混乱を引き起こします。INIT日時スタンプ付きの個別のログバックアップを使用して取得します。メンテナンスが簡単。Olaのバックアップソリューションを使用してください。このソリューションは、古いバックアップを削除することもできます。

データとトランザクションログのバックアップを同時に実行しても大丈夫ですか？そうでない場合、これを行う適切な方法は何ですか？

完全バックアップは、Tログバックアップには影響しません。完全バックアップには、必要なトランザクションログのみが含まれているため、復元の際に、データベースは、完全バックアップのデータ読み取り部分が完了した時間とトランザクションの一貫性を保つことができます。チェック- フルバックアップに含まれるトランザクションログの量

また、フルバックアップ中のログバックアップでは、トランザクションログは切り捨てられません。完全バックアップの完了後のログバックアップ（の組み合わせ）では、ログが切り捨てられます。

バックアップファイルは、サーバー上のすべてのファイルを取得して別の場所に保存する別のプロセスによって夜間に取得されます。2日後にバックアップセットを期限切れにするのは良い考えでしょうか。それらを完全に期限切れにする必要がありますか？

クリーンアップタスクはそれぞれ、G：\ Backupsのサブフォルダーの下にある「古い」.bakファイルと.trnファイルを削除します。それは理にかなっていますか？バックアップが失敗した場合や失敗した場合にETLを失敗させることができるように、SSISでこれを行う方が良いでしょうか？それとも私のETLプロセスは気にすべきですか？

上記の両方について、Olaのバックアップメンテナンスソリューションを使用します。古いファイルを削除します。