DBAは、組織内で重要な役割を果たします。データの管理者として、高可用性、高速クエリ処理時間、リスクの軽減と障害復旧など、データベースパフォーマンスのすべての側面を管理する責任があります。さらに、DBAは、ROIとコスト削減を目的として、組織のデータベースを維持するというビジネス目標を担当します。
DBAはさまざまな帽子をかぶっているため、効率的に作業する必要があり、効果的な時間管理が彼らの親友です。効率を達成するための最良の方法は、データベースの最適なパフォーマンスを維持するのに役立つ主要なアクティビティに最初に焦点を当てることです。
ここに、すべてのDBAの「知っておくべき」リストの上位にあるべき4つのデータベース監視アクティビティがあります。
SQL Serverのデフォルト設定を調整する方法（および理由）
多くのDBAは、SQLServerをそのまま実行します。ただし、セキュリティまたはパフォーマンスの観点から、デフォルト構成が常に最良の選択であるとは限りません。すべての組織のデータベースは異なり、さまざまなビジネスニーズを満たすため、すべてのデータベースが同じように構成されているわけではないことは理にかなっています。
特定のデータベースのニーズと設定に応じて、変更したいデフォルトのSQLServer設定がいくつかあります。
- フィルファクター：フィルファクター値を指定せずにインデックスを作成すると、デフォルト値は0になります。これは、ページがいっぱいになり、挿入、削除、または更新によって、過度のページ分割や断片化が発生する可能性があることを意味します。
普遍的に「正しい」曲線因子値はありませんが、通常は80〜90が安全な選択です。この値の範囲では、ページの80〜90％を埋めることができ、10〜20％は空けられます。
- 並列処理のコストしきい値：並列処理のコストしきい値は、SQLServerエンジンがクエリの並列プランの実行を開始する値です。デフォルト値は5秒ですが、この値はかなり低く、不必要に複雑なクエリを大量に作成する可能性があり、パフォーマンスに悪影響を及ぼします。
20秒の設定から始めて、CXPACKETの待機時間とCPU使用率に基づいて必要に応じて調整します。
- データベースファイルの自動拡張：自動拡張は、SQLServerエンジンがデータベースファイルの容量が不足しているときにデータベースファイルのサイズを大きくしたときに発生するプロセスです。ファイルがどれだけ大きくなるかは、デフォルトでデータファイルの場合は1 MB、トランザクションログファイルの場合は10パーセントに設定されています。
すべてのデータベースは異なる速度で成長するため、データベースが成長すると思われる量を見積もり、それに応じて値を設定します。
- データベースリカバリモデル：デフォルトのリカバリモデルはそのままで完全ですが、すべてのデータベースで効率的というわけではありません。
ミッションクリティカルではないデータベースの場合は設定をSIMPLEに変更し、リスクの高い本番データベースの場合のみ設定をFULLのままにします。 - 最大サーバーメモリ：デフォルト値は2 TBです。これは、SQLServerがオペレーティングシステムからすべてのメモリを割り当てることを意味します。これにより、OSが使用するメモリが残りません。
SQL Serverプロセスで使用可能なメモリの量を最大化するように設定を調整しますが、必要に応じてOSが使用できるように少し残しておきます。 - 最大並列度（MAXDOP）：MAXDOPは、並列プランでクエリを実行するために使用されるプロセッサの数を制御します。デフォルトは0です。これは、SQLServerが使用できるプロセッサの数を決定することを意味します。並列処理のしきい値のコストをデフォルト値の5のままにすると、すべてのクエリですべてのCPUを使用することになります。
理想的なMAXDOP設定は特定のシステムによって異なりますが、Microsoftはここでいくつかの提案を提供しています。 - バックアップ圧縮：この機能のデフォルト設定はオフです。ただし、バックアップ圧縮はデータベースのバックアップ操作を高速化し、バックアップファイルのサイズを小さくするため、オンにすることをお勧めします。
SQL Serverの設定をデフォルト値から調整するための最後のヒント：設定を変更した後は、システムを常に徹底的にテストして、不注意で問題が発生していないことを確認してください。
SQLServerのボトルネックを解消する方法
SQL Serverのボトルネックは、SQL Serverがプロセッサを占有する、クエリの実行時間が長くなる、過剰なI / O、ディスクでの極端なアクティビティなど、パフォーマンスの問題の一般的な原因です。
データベースでこれらのパフォーマンスの問題が発生する可能性があるボトルネックではない理由はたくさんありますが、問題がSQL Serverのボトルネックに起因する場合、影響を受ける可能性のある3つの主要な領域があります。メモリ、I / O、およびCPUです。
メモリのボトルネックは、メモリリソースが不足しているか、SQLServerのアクティビティで使用可能なメモリが多すぎることが原因です。クエリの実行時間の延長、過剰なI / O、アプリケーションログのメモリ不足メッセージ、頻繁なシステムクラッシュに注意してください。
I / Oボトルネックは、tempDBなどの通常のデータベース操作をサポートするのに十分なストレージが利用できない場合に発生します。長い応答時間、アプリケーションの速度低下、頻繁なタスクのタイムアウトに注意してください。
CPUのボトルネックは、不十分なハードウェアリソースが原因で発生します。データベースの監視で、SQLServerが過剰なCPUを使用していることを示すログデータを確認してください。
tempDBの成長を防ぐ方法
TempDBは、中間オブジェクトと一時オブジェクトを作成および保持するために使用されるSQLServerインスタンスの一時ワークスペースです。 TempDBはSQLServer環境で最もアクティブなリソースの1つであるため、tempDBの過剰な増加を監視および制御することが重要です。
TempDBは、ユーザーオブジェクト、内部オブジェクト、およびバージョンストアを格納するために使用されるため、インスタンス内で頻繁に使用されます。 tempDBが過度に大きくなるとパフォーマンスの問題が発生する可能性があるため、大量のtempDBディスク領域を使用している大きなクエリ、一時テーブル、およびテーブル変数を追跡することが重要です。
tempDBのサイズと拡張を最適化するために、Microsoftは次のベストプラクティスを推奨しています。
- tempDBのリカバリモデルをSIMPLEに設定します
- 必要に応じてtempDBファイルを自動的に拡張できるようにする
- tempDBデータベースファイルの値が小さすぎるのを防ぐために、ファイルの増加の増分を適切なサイズに設定します。
- ファイルサイズを環境内の一般的なワークロードに対応するのに十分な大きさの値に設定して、すべてのtempDBファイルにスペースを事前に割り当てます。
- 各データファイルを同じサイズにします
SQL Server Management Studioを使用して、tempDBデータファイルのサイズと拡張パラメーターを調整できます。
総所有コストの計算方法
会社の予算について考えるのに多くの時間を費やすことはないかもしれませんが、CFOがそうしていると信じる方がよいでしょう。新しいパフォーマンス監視テクノロジーを求めるときは、要求をバックアップするためのハードデータを用意しておくのが賢明です。
提示できる最も影響力のあるデータの1つは、現在のソリューションに対する新しいテクノロジーの潜在的な総所有コスト（TCO）です。直接費に加えて、インフラストラクチャなどの間接費とメンテナンスなどのリソースコストを必ず考慮してください。
TCOの削減は、現在のデータベースパフォーマンス監視ツールの置き換えを検討しているDBAの一般的な目標であるため、考慮すべきいくつかの要因があります。前述のように、購入価格などの直接コストだけでなく、保管などの間接コストやトレーニングなどのリソースコストも考慮することが重要です。
新しいツールのTCOを決定するには、詳細をTCO計算機に接続し、コスト削減がある場合はそれを確認します。