1

SQL Server の記事の多くで、物理ディスク上で複数のファイル グループを使用して、ディスクの競合やディスク スピンドルの問題を回避することがベスト プラクティスであると言及されています。したがって、私のクエリは次のとおりです。

1:複数のファイル グループを持つという同じ理論は、仮想マシンにも当てはまりますか?
2: temp db を別のディスクに作成する必要がありますか? また、複数の temp db ファイルを作成して、本番環境用の仮想マシン セットアップで同じ temp db ファイルに対する大規模な読み取り/書き込み操作を回避する必要がありますか?

推奨事項と推論は、ベスト プラクティスを決定するのに役立ちます。ありがとう。

4

2 に答える 2

1
  1. はい、仮想サーバーには引き続き適用されます。競合の問題の一部は、グローバル アロケーション マップ (GAM) または共有グローバル アロケーション マップ (SGAM) にアクセスすることです。これらはデータベース ファイルごとに存在し、一度に 1 つのプロセスまたはスレッドのみがアクセスできます。これが「ラッチ待ち」の問題です。
  2. 2 番目のディスクが実際に別のスピンドルにある場合は、はい。データベース ファイルが異なる論理ディスク上にあるが同一のスピンドル上にある場合、それはあまり重要ではありません。

MSの推奨事項は、サーバー上の論理プロセッサごとに 1 つのデータベース ファイルを作成することです (最大 8 つまで)。8 つを超えるデータベース ファイルを追加する前に、tempdb でラッチの競合に関する問題が見つかるかどうかをテストする必要があります。

tempdb ログファイルは順番に使用されるため、複数の tempdbログファイルを作成する必要はありません (通常は作成しないでください) 。常に次のページに書き込みを行っているため、ディスクの競合を分割する方法はありません。

于 2016-09-12T03:41:52.857 に答える
0

質問には、あなたの環境についてもう少し情報が必要です。VM のドライブがどこかの SAN でホストされていて、VM に提供されるドライブがすべて SAN 上の同じ物理ディスクに分散している場合、競合を回避することはできません。ただし、ドライブが同じ物理ドライブ上にない場合は、改善が見られることがあります。SAN チームがそれについてアドバイスする必要があります。

そうは言っても、ログ ファイルをデータ ファイルから分割し、tempDB を独自のドライブに配置することをお勧めします。その理由は、クエリが計画どおりに進まない場合、ログ ファイル ドライブがいっぱいになり、そのデータベースがオフラインになる可能性がありますが、他のデータベースは引き続き実行できる可能性があるためです (ログ ファイルに十分な空き領域があると仮定します)。 .

再び tempDB を使用すると、それがいっぱいになると、トランザクションはエラーになり、他のすべては介入なしで実行し続ける必要があります。

于 2016-09-12T03:39:03.300 に答える