24時間365日と夜間の時間枠

年中無休の運用に移行する方法に関するリソースはどこにありますか？大きなデータベースを持つ大企業はどのようにこれを達成しますか？次のような夜間の仕事

1. 古いデータを消去する
2. 再インデックス
3. 統計を更新する

すべてがシステムに重大な影響を与えるようです（つまり、オンラインユーザーとリアルタイムデータフィード）。このテーマに関連する本をAmazonで探しましたが、今のところ何も見つかりませんでした。

24時間365日のデータベースの維持は、考慮すべき多くのオプションがあるかなり大きなトピックです。この広範なトピックには考慮すべき多くの項目がありますが、いくつかの重要なポイントに基づいて試してみることができます。

最初に特定したいのは、多くの操作が24時間年中無休であるが、通常はアクティビティが少ない時間があることです。これらの時間を活用してメンテナンスを実行すると、データベースに与える干渉を減らすことができます。2つ目は、完全な停止（サービスパックやデータベースの移行など）のために時間を確保する必要があるため、管理者と完全なメンテナンスウィンドウについて交渉する必要があることです。特定のアイテムについては、各アイテムを考慮して計画する必要があり、ツールを適切に活用する必要があります。重要なのは、これらのそれぞれを計画する必要があるということです。私が提供する例はすべて、「あなたのマイルは異なる場合があります」。

バックアップ

通常、バックアップはワークロードに大きな影響を与えませんが、大量のI / Oを消費する可能性があるため、考慮する必要があります。これらを適切にスケジュールし、完了するまでにかかる時間を監視する必要があります。ここでの最大のハードルは、24時間年中無休の運用では、1週間の夜間に完全な夜間バックアップを実行できない可能性が高いことです。満杯になる時期、差分を取る時期、およびこれらの両方の保存期間をログバックアップと組み合わせて計画することをお勧めします。

例として、日曜日の夜（アクティビティが最も少ない）にすべてのデータベースの完全バックアップを実行し、他のすべての夜（月曜日から土曜日）に差分を実行します。過去2週間のフルと差分をディスクに保存し、過去2日間のログを記録します。これにより、リカバリに十分な柔軟性が得られますが、必要に応じてテープからバックアップをリカバリする必要がある場合があります。

インデックス/統計のメンテナンス

これは、対処しなければならないアクティブメンテナンスの最も一般的なタイプです。それを避けることはできませんが、影響を緩和することはできます。最初の経験則では、それを必要とするオブジェクトのみを保守する必要があります。一般的なガイドラインは、断片化が30％を超え、1000ページを超えるインデックスのみを再構築することです。統計の自動更新がある場合、これは統計のメンテナンスのほとんどを処理しますが、物事の同期を保つための夜間の仕事は悪い考えではありません。

Enterprise Editionを使用している場合は、メンテナンスを管理するためのその他のオプションにもアクセスできます。最も重要なのはOnline Index Rebuildsです。これにより、インデックスがまだ使用されているときにインデックスを再構築できます（基本的には、インデックスを並べて構築してからスワップします）。また、「大きな」テーブルのパーティション分割を活用して、必要な再構築時間を短縮することもできます。

これらのベストプラクティスを処理するカスタムスクリプトがない場合、このタイプのメンテナンスの最善策は、Ola Hallengrenのメンテナンススクリプトを使用することです。これらのセットアップと構成は非常に簡単で、これらのガイドラインの多くが組み込まれています。

DBCC整合性チェック

全体的なワークロードに応じて、DBCCチェックが操作を中断させることがあります。データベースに対するDBCCの影響を最小限に抑えるには、2つの一般的な方法があります。

• PHYSICAL_ONLY-このオプションを実行すると、物理ページレベルでデータベースがチェックされ、より侵襲的な完全チェックが回避されます。これには、最も可能性の高いタイプの破損の特定が含まれます。
• 復元されたコピーの確認-スペースがあれば、データベースを別のインスタンスに復元し、復元されたコピーに対してDBCCチェックを実行できます。これにより、ライブデータベースに関する同じ話がわかりますが、アクティビティを妨害することはありません。ここでの他のいくつかの代替方法は、ログ配布コピーまたはミラーデータベースに対してDBCCを実行しています。

このブログ投稿では、オプションの詳細を説明しています。

バッチジョブ/ ETL

これは、プロセスをどのように設計するかにかかっています。ETLは常に（他のアプリケーションと同じように）ライブOLTPテーブルに干渉する可能性があるため、次の点に留意してください。

• このような作業は、他のメンテナンスに関連して、アクティビティの少ない期間にスケジュールしてください。
• 両方のパフォーマンスのためにバッチ処理されるように、また数時間テーブルをロックするほどバッチが大きくならないように、作業のサイズを調整します。スペクトルの終わりの例：行ごとの行（RBAR）対100万行の削除。
• ステージテーブルを使用し、必要に応じてデータ処理をオフラインにします。絶対に必要な場合にのみ、ライブのものに触れてください。

結論

繰り返しますが、ここには多くの根拠があります。これは包括的なガイドではなく、いくつかのアプローチの概要です。高可用性オプション（可用性グループやフェールオーバークラスタリングなど）についても説明していません。各項目を確認し、その処理方法の計画を立てる必要があります。また、多くの点で、前進しながら作業を繰り返して洗練する必要があります。

追加のリソース：

SQL Skills VLDBメンテナンスのベストプラクティス