![SQL Server の可用性の問題: 大きなクエリにより他の接続が停止する](https://rvso.com/image/515035/SQL%20Server%20%E3%81%AE%E5%8F%AF%E7%94%A8%E6%80%A7%E3%81%AE%E5%95%8F%E9%A1%8C%3A%20%E5%A4%A7%E3%81%8D%E3%81%AA%E3%82%AF%E3%82%A8%E3%83%AA%E3%81%AB%E3%82%88%E3%82%8A%E4%BB%96%E3%81%AE%E6%8E%A5%E7%B6%9A%E3%81%8C%E5%81%9C%E6%AD%A2%E3%81%99%E3%82%8B.png)
私は、MS SQL 2008 を実行する高性能 (マルチコア、RAID) サーバーを所有しており、そのサーバーには複数のデータベースがあります。定期的に DB の 1 つから少量の情報を必要とする低スループットのプロセスがあり、コードは正常に動作しているようです。
ただし、同僚の 1 人が他の DB に対して大規模なクエリを実行すると、マシンの CPU 使用率が最大になり、アプリからの接続がタイムアウトすることがあります。
なぜこのようなことが起こるのでしょうか? 多数のコアとハードディスク (巧みに作成された DB サーバーと併用) があれば、少なくとも一部のリソースを他のアプリ用に空けておくことができるはずだと思います。クエリに複数の接続を使用していないことは確かです。
これを防ぐにはどうすればよいですか?
編集
ハードウェアについてはあまり詳しくありません。Server 2k3 で RAID された通常の HDD を使用しています。おそらく 2 年ほど前の HP です。基本的に、ハードウェアに問題があるというのは私には理解できないので、何か間違った構成をしたのではないかと思いました。
答え1
これは、クエリが非常に最適ではないことを意味します。よくある原因:
- インデックスがない、またはインデックスが不良
- WHERE 句内の列に対する関数 (= 無視されるインデックス)
- データ型変換/優先順位(= 無視されるインデックス)
- SELECT 句でテーブル アクセスを行うスカラー UDF (= CURSOR の影響)
- ビューのクエリ/ビューとの結合(ビューは展開するマクロです)
また、単純なリソースの問題である可能性もあります。返されたデータはデータベース全体にアクセスし、メモリを大量に使用してページングが発生しているのでしょうか。または、クライアントが結果を適切な速度で受け入れていないことを意味する ASYNC_NETWORK_IO 待機が発生しているのでしょうか。
通常、サーバーが最大限に機能している場合、それは DB エンジンではなく、コードや設計の不良です。
答え2
できる限り最適化したと確信しているのであれば、並列処理の設定を確認するとよいでしょう。デフォルトでは、並列クエリにすべてのプロセッサを使用しますが、プロセッサの数に応じて、最大限に低い数値に変更することができます。クエリの実行には少し時間がかかるかもしれませんが、ログイン要求を処理するのに十分な処理能力が確保されるはずです。問題がこの 1 つのクエリに限定されている場合は、システム全体の設定を変更するのではなく、同僚に MAXDOP オプションを追加してクエリを変更してもらい、それが役立つかどうかを確認できます。