単一ディスクでのSQLServer 2008DBのパフォーマンス
SQL Server 2008に、サイズが約20GBのデータベースがあります。そしてそれは急速に増加しています。
どういうわけか私はIOパフォーマンスを向上させるために複数の独立したハードディスクを追加することはできません。
別のファイルグループに大きなテーブルを追加する場合、単一ディスクのパフォーマンスを向上させるのに役立ちますか？
または、パフォーマンスを向上させるためのヒントがありますか？
ありがとうございました
まず、現在の状況を知るために、パフォーマンスのベースラインを収集します。パフォーマンスを監視し続けて、退化の傾向があるかどうかを確認します。パフォーマンスが問題になると思われる場合は、やるべきことがいくつかあります。
パフォーマンス不足の根本原因を特定します。サーバーのメモリ不足が期限切れになっていますか、IO待機または高いCPU使用率ですか？通りの言葉は ブレントのパフォーマンスチューニングページ を見てクイックスタートすることです。
優れたDB設計を見落とさないでください。欠落しているインデックス、古い統計、および不適切に記述されたクエリに対してDBを確認します。これらの問題のいずれかがあなたが得たすべての鉄を使い果たし、次にいくつかを食い尽くす可能性があります。
編集：
複数のファイルグループを使用すると、特定の状況でパフォーマンスを向上させることができます。 Microsoftのドキュメントでさえ パフォーマンス上の利点 と主張しています。残念ながら、あなたのシナリオでは、余分なディスクがないため、そうではありません。
ファイルグループの考え方は、データベースの内容を複数のファイルに分割することです。ファイルグループを使用すると、ホットテーブルを高性能ストレージに配置できます。これには、システムに欠けている高度なストレージ構成が必要です。テーブルのパーティション分割では、この方法でもストレージを利用できます。
バックアップ/復元などの管理タスクは、ファイルグループを使用するとより管理しやすくなります。通常、このような利点を得るには、VLDB（非常に大規模なデータベース）が必要です。もう1つの典型的な例は、読み取り専用データを処理し、それを独自のファイルグループに分離することです。データは変更されないため、データベースの他の部分よりもほとんどバックアップできません。
複数のファイルグループを単一のディスクに展開する場合、パフォーマンスの向上はありません。その理由は、まだ1つのディスク、1つのスピンドル、1セットの読み取り/書き込みヘッドがあるためです。データにアクセスするには、ディスクがヘッドを適切な場所に移動する必要があります。同時に2つの場所に配置することはできないため、ファイルグループを追加してもパフォーマンスは向上しません。
サーバーがディスクにバインドされている（飽和している）場合、（同じディスク上の）より多くのファイルに分割してもパフォーマンスは向上しません。ただし、状況によっては（スレッド/ CPUにバインドされていて、十分なディスクスループットがある場合）、役立つ場合があります。 （@vonPryzがすでに言ったように）パフォーマンス調査をしなければ、あなたは本当に知りません。
（ハードウェアの制約などのために）ディスク構成を拡張することが許可されていない場合は、RAMの追加を検討できます。大きなメリットにはなりませんが、RAMを追加すると、パフォーマンスが向上する場合があります（取得するトラフィックのタイプによって異なります）。これは主に読み取りに役立ちます（書き込みにはあまり役立ちません）。 。DBが急速に成長していることを考えると、追加のRAMは、インデックスが大きくなるとき、またはOSが頻繁にスワップ/ページングする場合に確かに役立ちます。
もちろん、トラフィックやハードウェア、構成などについて何も知らなくても、他の場所でより深刻なボトルネックがある場合は、RAMを追加することもお金の無駄になる可能性があることを指摘しておく必要があります。パフォーマンス調査を行うことによってのみそれを知っています。推測にお金を使うことはあまり専門的ではありません。
データが（内部またはファイルシステムレベルで）ひどく断片化されていないことを確認する以外に、単一のスピンドルセットのパフォーマンスを向上させるためにディスク/ファイルでできることは何もありません。
couldは、SQL Serverのチェックポイント動作を微調整して、ディスクへの書き込みの実行方法からもう少しパフォーマンスを引き出すことを試みます（ http：//を参照） msdn.Microsoft.com/en-us/library/ms189573.aspx および http://sqlblog.com/blogs/linchi_shea/archive/2007/11/01/best-and-worst-checkpoint -performance.aspx ）しかし、テスト環境で十分なベンチマークを行わずに、実際に考えを悪化させるのではなく改善していることを確認するために、それらをいじることはお勧めしません。回復を妨げないように注意する必要があります。水からモデル化します。
マシンにあるメモリの量と表示されるワークロードの種類は重要な要素です。データとインデックスの大部分がRAMに収まり、ワークロードの読み取りが非常に多い場合（ほとんどは））そうすれば、主にRAMから実行することになり、心配する必要はありません（ディスクに頻繁にアクセスしない場合、ファイル/ディスク配置の速度は比較的小さな問題です）。インデックスの選択が十分に検討されていることを確認すると、DBが使用可能なRAMよりもはるかに大きい場合でも、共通の作業セットがうまく収まることがわかります。それでもIO最適化についてあまり心配する必要はありません。20Gbは最新のマシンのDBにとってそれほど大きくないので、優れたインデックス設計では、主に読み取られるワークロードが=でブロックされるべきではありません。 IOアプリが単一のクエリで数百Mb以上を定期的に引き出す場合を除いて、かなりの量です。