web-dev-qa-db-ja.com

Ola Hallengrenスクリプトを使用したSQL Serverの推奨バックアップスケジュール

私たちは新しいAlwaysOn SQL Server 2016データベースクラスターを構築しており、Ola Hallengren（ https://ola.hallengren.com ）バックアップスクリプトを使用してバックアップをセットアップしている最中です。次のタスクを実行するのに最適な場合のアドバイス：

DatabaseIntegrityCheck - SYSTEM_DATABASES
DatabaseIntegrityCheck - USER_DATABASES
IndexOptimize - USER_DATABASES

現在、バックアップには次のスケジュールを使用する予定です。

DatabaseBackup - SYSTEM_DATABASES - FULL @ 23:30 every day
DatabaseBackup - USER_DATABASES - FULL @  23:00 every day
DatabaseBackup - USER_DATABASES - DIFF @ Every hour starting at 00:00 to 22:00
DatabaseBackup - USER_DATABASES - LOG @ Every 5 mins starting at 00:03 to 23:59:59

提案を読むことで、バックアップの前にデータベースの整合性チェックを行うことになったので、メインバックアップの30分前に、負荷が既知の時間にインデックス最適化を実行すると思いました。 SQL Serverバックアップのスケジュールとしてそれは理にかなっていますか？

sql-serverbackupjobssql-server-2016ola-hallengren
2
Ollie

[T]彼の提案は、バックアップの前にデータベースの整合性チェックを行うことでした。そのため、メインバックアップの30分前に、負荷が既知の時間にインデックス最適化を実行すると思いました。 SQL Serverバックアップのスケジュールとしてそれは理にかなっていますか？

いくつかの考え：

  • インデックスのメンテナンスは、思ったほど頻繁には必要ないかもしれません。通常、インデックスの断片化による最新のハードウェアのパフォーマンスへの影響は非常に低く、特にインデックスの再構築に関連するすべてのログを可用性グループのセカンダリに送信する必要があることを考慮すると、 Olaのメンテナンスソリューションを使用して、毎日（またはさらに頻繁に）統計更新を検討することをお勧めします。彼のサイトからこの例を必ず使用してください（インデックスの断片化にNULLsに注意してください）。

D.すべてのユーザーデータベースの変更された統計を更新する

EXECUTE dbo.IndexOptimize
@Databases = 'USER_DATABASES',
@FragmentationLow = NULL,
@FragmentationMedium = NULL,
@FragmentationHigh = NULL,
@UpdateStatistics = 'ALL',
@OnlyModifiedStatistics = 'Y'

  • インデックスの断片化がパフォーマンスの問題の原因であることがわかった場合、またはそれらをまともな形で維持したい場合は、それをより少ない頻度でスケジュールできます。データベースとインデックスのサイズに応じて、おそらく週1回または月1回です。

  • これにより、整合性チェックのためのバックアップの30分前の「推定」に答えることになります。実際にプロセスを実行するまではわかりません。毎月のインデックスメンテナンスに3時間かかる場合は、統計の更新よりも早く開始することをお勧めします。 CHECKDBに5時間かかる場合は、AGセカンダリで実行するようにスケジュールするか、データベースをスタンドアロンサーバーに復元してそこで実行します（「CHECKDBのオフロード」を検索）。

  • 差分バックアップ私の意見では、毎時間はやり過ぎです。通常、1日1回、環境によっては1日2回実行します。ログのバックアップがあり、差分は増分ではないであることを覚えておく必要があります。前回の完全バックアップ以降のすべての変更を追跡するため、次の完全バックアップまで成長し続けます。場合によっては、差分バックアップが完全バックアップのサイズを超えることがあります。このような場合は、完全バックアップが差分バックアップよりも優れているかどうかを評価する必要があります。

  • 5分を維持するのに十分なディスク領域がありますトランザクションログのバックアップ？それはビジネスに必要なものですか（SLA、RTO、RPO）？あなたは6分で逃げることができますか？ 3か月の間に、その余分な1分間は、保存するファイルの数に大きな違いをもたらします。多くの場合、ほとんどのクライアントは、10分または15分のログバックアップのトレードオフに満足しています。

  • フルバックアップは毎日行うことができますが、保持ポリシー、および復旧時間目標と復旧ポイント目標によっては、ユーザーデータベースの毎週のフルバックアップ、毎日のフルバックアップに満足できる場合があります。システムデータベースのバックアップ、および必要に応じて差分を埋めることができます。

最終的に、これはすべて、企業がサービスレベル契約を社内外で満たすために必要なものに依存します。レポート/ OLAPスタイルのデータベースをOLTPソースから2時間で再生成できる場合は、次のように心配する必要はありません。 OLTPデータベース。

これがあなたのビジネスに適切な戦略を立てるのに役立つことを願っています。それがこれらの決定を推進するものです。

4
Randolph West

データベースの大きさは？また、バックアップはどのくらいの期間保管しますか？

DatabaseBackup - SYSTEM_DATABASES - FULL @ 23:30 every day

MasterデータベースにはDIFFバックアップを作成できないため、これは必須であり、これが毎日のバックアップを作成する唯一の方法です。

DatabaseBackup - USER_DATABASES - FULL @  23:00 every day
DatabaseBackup - USER_DATABASES - DIFF @ Every hour starting at 00:00 to 22:00

私は通常、これをそれぞれ週に1回と1日1回行います。しかし、ここが複雑になります。

ほとんどのデータベースはこれで問題なく処理できますが、10TBのモンスターが1日あたり数百MBの変更しかなく、特別な処理が必要になる場合があります。あるいは、毎日完全に循環する1TBのデータベースがあり、DIFFバックアップは時間の無駄です。

私の意見では、1週間後にmsdb.dob.backupsetデータを標準化して集計し、グラフ化して、最悪の最悪のものを特定し、そのためだけに特別な手順を設定します。整頓されていれば、月に1回実行するレビュープロセスドキュメントとスクリプトを作成します。 scripts todetermin this がありますが、時間を最大限に活用するのは、それを吸って見ることです。

DatabaseBackup - USER_DATABASES - LOG @ Every 5 mins starting at 00:03 to 23:59:59

これは問題ありませんが、何も起こらなくても、データベースごとに1日あたり288のログファイルを生成します（非圧縮75k、圧縮6k）。これらの数値は、環境のサイズと保持期間に応じてすぐに加算されます。

しかし、最悪の部分はそれらを復元しています。 （もちろんスクリプトを使用して）288個のログファイルのバックアップを続けて復元したことがあるかどうかはわかりませんが、何もない場合でも 、それぞれが完了するまでに数秒以上かかります。ボトルネックがどこにあるかはわかりません（SAN、SMBプロトコル、ネットワーク遅延、サーバー、SQL復元コード、または何））。 「アプリケーションがすべてを破壊したので、今すぐ完全な復元が必要です！」

その時でさえ。 50個のデータベースを持つサーバーが1つしかない場合でも。サーバーで何かが発生し、その日の14,400件のログバックアップを他のすべてのものに復元する必要がある場合...スクリプトは問題ありません。遅れは！

もちろん、これを「15分のデータまたはデータを失った」と「5分のデータを失った」と比較すると、結果が異なる場合があります。

どちらに行くにしても、当たるのは、蓄積された愚かなテキストログです。はい、CommandLogでエラーを見つけるのは面倒なので、何が起こったのかを理解するためだけにそのディレクトリにある100万のテキストファイルをスキャンする必要があるので、私はそれらを愚かと呼びます。

でもお楽しみください。ハレングレンを使用します。しかし、今日それをやり直すことができれば、ミニオンに切り替えるかもしれません。同じ物理的な問題の多くはまだ当てはまりますが、管理とトラブルシューティングの方が簡単かもしれません。

0
Cody Konior