はじめに
この記事は、ダウンタイムのない24時間年中無休の情報システムのデータベースを使用した主な定期メンテナンスと、MSSQLServerでの実行方法の簡単なレビューです。
記事へのコメントや更新は大歓迎です。
定期メンテナンス
私が指摘したい次の定期メンテナンスがあります：
- 復元せずにさらに検証してスケジュールされたバックアップ
- パフォーマンスを検証するためのバックアップのスケジュールされた復元
- システムと必要なすべてのデータベースを含むデータストレージデバイスの分析
- 必要なサービスのスケジュールされたテスト
- システムパフォーマンスのスケジュールされた最適化
- データの整合性のスケジュールされたメンテナンス
- データ検証のスケジュールされたメンテナンス
最初の3つのポイントは、さまざまな障害の後にシステムを復元するために最も重要です。ただし、ユーザーが安心して作業できるように（したがって、すべてのクエリを高速に実行する必要があります）、すべてのレポートシステムでデータを検証できるように、少なくとも3つのポイントも実行することをお勧めします。
スケジュールされたメンテナンスを自動化するために、そのパーツをエージェントまたはWindowsスケジューラに配置することができます。
6番目のポイントはCHECKDBコマンドに基づいています。
7番目のポイントは、情報システムで使用されるドメイン領域に向けて実装されます。
最初の5つのポイントについて詳しくお話します。
復元せずにさらに検証してスケジュールされたバックアップ
このトピックに関する記事はたくさんあるので、この定期メンテナンスはメインサーバーではなくバックアップサーバーで定期的に実行する必要があることに注意してください。このバックアップサーバーには、最新のデータ（たとえば、レプリケーションで取得されたデータ）が含まれている必要があります。さらに、MS SQL Serverの各インスタンスですべてのシステムデータベース（tempdbを除く）をバックアップする必要があります。
バックアップが失敗した場合、またはバックアップスキャンで問題が特定された場合は、この情報を管理者に報告する必要があります。たとえば、メールで送信できます。
次の質問に答えるバックアップの戦略を決定することが重要です。
- データ（完全、差分、トランザクションログ）をバックアップする頻度とタイミングは？
- バックアップを削除する期間と時期は？
パフォーマンスを検証するためのバックアップのスケジュールされた復元
この手順は、サードパーティのユーティリティまたは RESTOREを備えたバックアップサーバーで実行することをお勧めします。 コマンド。
バックアップの復元に失敗した場合は、この情報を管理者に報告する必要があります。たとえば、メールで送信できます。
また、システムデータベースのバックアップを復元する必要があります。これを行うには、システムデータベースの名前とは異なる名前の通常のユーザーデータベースとしてそれらを復元する必要があります。
システムと必要なすべてのデータベースを含むデータストレージデバイスの分析
各データベースに必要なスペース、ファイルサイズの変化、およびストレージデバイス全体の空きスペースのサイズの変化を分析する必要があります。たとえば、MS SQLServerのオペレーティングシステムのデータベースファイルと論理ドライブに関する自動データ収集を使用して、このタスクを部分的に実行できます。
このチェックを毎日実行して、結果を送信できます。いつものように、あなたはそれらを電子メールに送ることができます。
また、すべてが正しく機能することを確認するために、システムデータベースを監視する必要があります。
さらに、ストレージデバイスをテストして、減価償却や不良セクタがないかどうかを確認することが重要です。
テスト中はデバイスを動作停止にし、テストによってデバイスが大幅に読み込まれるため、すべてのデータを別のデバイスにコピーする必要があることに注意してください。
このタスクはシステム管理者の職務に厳密に関連しているため、脇に置いておきます。ケースを完全に制御するには、メールレポートの配信を自動化する必要があります。
このテストは年に2回実行することをお勧めします。
必要なサービスのスケジュールされたテスト
サービスのダウンタイムは悪い習慣です。したがって、障害が発生した場合に備えて、バックアップサーバーが動作します。それでも、時々ログをチェックする必要があります。さらに、電子メールを送信して管理者にさらに通知する自動データ収集を考えることもできます。
MSSQLServerで完了したタスクに関する自動データ収集を使用してSQLServerエージェントまたはWindowsスケジューラのタスクを確認する必要があります。
システムパフォーマンスのスケジュールされた最適化
次の側面が含まれます：
- MSSQLServerデータベースでのインデックスの最適化の自動化
- MSSQLServerのデータベーススキームの変更に関するデータ収集の自動化。たとえば、dbForgeを使用して、バックアップを復元し、変更を比較できます。
- MSSQLServerでスタックしたプロセスのクリーンアップを自動化する
- プロシージャキャッシュをクリーンアップします。ここでは、いつ、何をクリーンアップする必要があるかを判断する必要があります
- パフォーマンス指標の実装
- クラスター化インデックスの開発と変更
さらに、 AUTO_CLOSEをオフにすることをお勧めします 機能。
場合によっては、さまざまな理由で、オプティマイザがクエリを並列化しますが、これは常に最適であるとは限りません。
したがって、覚えておくべきいくつかの推奨事項があります：
- 大量のデータを取得する場合は、並列処理を残してください。
- 取得するデータが少ない場合は、並列処理を使用しないでください。
並列処理を担当するSQLServerインスタンス設定には、次の2つのパラメーターがあります。
- 最大並列度。並列処理をオフにするには、値として「1」を設定します。これは、1つのプロセッサのみがコードを実行することを意味します。
- 並列処理のコストしきい値。デフォルトで設定する必要があります。
2つのメインキューがあります：
- CPU時間のキュー（QCPUキュー）。クエリが有効になっていて、プロセッサがクエリを実行するのを待っているときに発生します。
- リソースのキュー（QRキュー）。これは、プロセスを実行するためにリソースがバインド解除されるのをクエリが待機しているときに発生します。
次の式は、クエリの実行（T）を示しています。
T =TP + TQR + TCPU + TQCPU、ここで：
- TPは計画の時間をまとめています
- TQRはリソースのキュー時間（QRキュー）です
- TQCPUは、リソースがバインド解除されるまでのキュー時間です（QCPUキュー）
- TCPUはクエリを実行する時間です
sys.dm_exec_query_statsシステムビュー：
- total_worket_time =TP + TCPU + TQCPU
- total_elapsed_time =TQR + TCPU
組み込みのツールでは、クエリの実行時間を正確に評価することはできません。
ほとんどの場合、 total_elapsed_time クエリの実行時間に近い時間を提供します。
トレースを使用すると、クエリの実行時間をより正確に判断できます。または、クエリの開始時刻と終了時刻をログに記録することもできます。トレースはシステムに大きな負荷をかけるため、注意してください。したがって、バックアップサーバーで実行し、メインサーバーからデータを収集することをお勧めします。この場合、ネットワークのみがロードされます。
並列化する場合、SQL ServerはN個のプロセスをクエリに割り当てます（Standart n <=4のエディション）。各プロセスは、クエリを実行するためにCPU時間を必要とします（1つのプロセスが各コアで常に実行されるとは限りません）。
プロセスが多ければ多いほど、一部が他のプロセスに置き換えられる可能性が高くなり、TQCPUが増加します。
次の場合、並列化するときにクエリの実行にさらに時間がかかることがあります。
- ディスクサブシステムのスループットが低い。この場合、クエリの分解にははるかに時間がかかります。
- プロセスのためにデータがブロックされる可能性があります。
- 述語のインデックスがないため、テーブルスキャンが発生します。
備考：
大量の選択を実行する必要がないサーバーでは、並列クエリを無効にする必要があります（total_worket_timeを短縮する必要があります） TCPUおよびTQCPUが減少する可能性があるため）。これを行うには、1つのプロセッサのみが機能するように、最大並列度機能を「1」に設定する必要があります。
さらに、他のフレームワークを使用して、データベースの高速パフォーマンスを決定するシステムを構築できます。 。これらのフレームワークがどのように機能し、取得した数値をどのように解釈するかを理解することが重要です。
インデックス、つまりクラスター化インデックスの開発と変更に関しては、インデックスのロジックがどのように設定され、どのように機能するかを理解することが重要です。
主キーとクラスター化キーは同じ意味ではないことに注意してください：
主キー は列または列のセットであり、テーブル内でレコードを一意にします。主キーには、一意のクラスター化インデックスまたは非クラスター化インデックスのいずれかを作成できます。主キーは、データの整合性を提供するための外部キーとして他のテーブルで使用されます。
クラスター化されたインデックス Bツリーまたはその変更です。ノードがインデックス情報を保持している間、リーフにはデータ自体が含まれます。さらに、クラスター化されたインデックスは一意でない場合もあります。それでも、ユニークにすることをお勧めします。
Bツリーは、クラスター化インデックスによってフィルター処理された順序でデータを格納する構造であることを思い出してください。したがって、クラスター化インデックスとして選択されたフィールドを降順または昇順でグループ化することが重要です。クラスタ化されたインデックスの場合、データと時間だけでなく、整数（ID）の列を使用できます。それでも、一意の識別子などの列は適切ではありません。後者はBツリーの定期的な再構築につながり、データベースが配置されているストレージデバイスの読み取りとレコードの量が増えるためです。
さらに、インデックスがsys.dm_db_index_usage_statsシステムビューで使用されていることを確認する必要があります。
P.S.バックアップサーバー上のデータが最新であるかどうかを確認する必要があります。また、このデータを同期するシステム（レプリケーションなど）も確認する必要があります。
また読む：
MSSQLServerデータベースでのインデックスの最適化の自動化
MSSQLServerでのデータベーススキーマ変更の自動データ収集
MSSQLServerでスタックしたプロセスの自動削除
MSSQLServerでの長時間実行クエリのトラブルシューティング
パフォーマンス指標の実装