Azure SQL（SQL Server）データベースが一度に一定期間データIOで過負荷になるのはなぜですか？[閉まっている]

S2エディション（50 DTU）でAzure SQLデータベースを実行しています。サーバーの通常の使用では、通常、約10％のDTUがハングします。ただし、このサーバーは定期的にデータベースのDTU使用率を85〜90％に数時間送信する状態になります。その後、突然、通常の10％の使用量に戻ります。

この過負荷状態の間、アプリケーションからのサーバーに対するクエリは、まだ高速に動作しているようです。

サーバーをS2 =>何からでもスケーリングできます（たとえば、S3）=> S2。サーバーがハングしている状態をすべてクリアするように見えます。しかし、数時間後、同じ過負荷状態のサイクルが繰り返されます。私が気付いたもう1つの奇妙なことは、このサーバーをS3プラン（100 DTU）で24時間年中無休で実行した場合、この動作は観察されなかったことです。データベースをS2プラン（50 DTU）にダウンスケールした場合にのみ発生するようです。S3プランでは、私は常に5-10％DTU使用率で座っています。明らかに十分に活用されていません。

不正なクエリを探してAzure SQLクエリレポートをチェックインしましたが、実際に異常なものは見られず、期待どおりにリソースを使用してクエリが表示されます。

ここでわかるように、使用法はすべてData IOからのものです。ここでパフォーマンスレポートを変更して、MAXごとの上位のデータIOクエリを表示すると、次のようになります。

これらの長期にわたる要求を見ると、統計の更新が指摘されているようです。私のアプリケーションから実際には何も実行されていません。たとえば、クエリ16302には次のように表示されます。

SELECT StatMan([SC0], [SC1], [SC2], [SB0000]) FROM (SELECT TOP 100 PERCENT [SC0], [SC1], [SC2], step_direction([SC0]) over (order by NULL) AS [SB0000]  FROM (SELECT [UserId] AS [SC0], [OrganizationId] AS [SC1], [Id] AS [SC2] FROM [dbo].[Cipher] TABLESAMPLE SYSTEM (1.250395e+000 PERCENT) WITH (READUNCOMMITTED) ) AS _MS_UPDSTATS_TBL_HELPER ORDER BY [SC0], [SC1], [SC2], [SB0000] ) AS _MS_UPDSTATS_TBL  OPTION (MAXDOP 16)

ただし、この場合も、これらのクエリはサーバー上のデータIO使用率のごく一部（<4％）しか使用していないこともレポートに示しています。また、定期的なメンテナンスの一環として、統計情報の更新（およびインデックスの再構築）を毎週データベース全体で実行しています。

これは、リソース使用量の多いインシデントの間のみ数時間をカバーするタイムスパンのMAXデータIOクエリを示す別のレポートです。

ご覧のとおり、重要なデータIOの使用状況を報告するクエリは実際にはありません。

また、私は走っているsp_who2と、sp_whoisaciveデータベース上と（私はこれらのツールを持つ専門家ではないよ認めるでしょうが）本当に何が私に飛び出し表示されません。

ここで何が起こっているのかをどのように理解できますか？私のアプリケーションクエリのどれもがこのリソースの使用に責任があるとは思わず、サーバーのバックグラウンドで実行されている内部プロセスが強制終了しているように感じます。

スパイク中のログアクティビティが最小限であることを考えると、DUIが実行されていない（または多くない）と想定できます。

ある時点で、スパイクがパフォーマンスに影響を及ぼさないと述べ、別の時点でスパイクが影響を与えると述べました。どっち？

また、これはスケール操作の後でなくなることにも言及しています。これは、すべてのプロセスなどを効果的に終了させるオンプレミスの再起動に類似しているため、理にかなっています。

このデータベースがアプリケーション層からアクセスされていると推測して、正しく推測できますか？その場合は、接続が適切に閉じられていないようです。ガベージコレクターはこれらを最終的に処理することになっています（これに依存することはできません）が、アプリ層からの閉じられていない接続が原因でこの正確な状況が発生するのを見てきました。私たちの場合、アプリケーションが非常にビジーだったため、結局は同時接続エラーが発生しました。

スパイク中に次のクエリを試してください。

SELECT
    c.session_id, c.net_transport, c.encrypt_option,
    s.status,
    c.auth_scheme, s.host_name, s.program_name,
    s.client_interface_name, s.login_name, s.nt_domain,
    s.nt_user_name, s.original_login_name, c.connect_time,
    s.login_time
FROM sys.dm_exec_connections AS c
JOIN sys.dm_exec_sessions AS s
    ON c.session_id = s.session_id
ORDER BY c.connect_time ASC

私が正しければ、ステータスがSleeping、またはそれよりも悪い状態で返された一連のレコードがすべて見つかりますRunning。その場合、アプリ層でさらに大きな問題が発生します。

これをさらにデバッグするには、データベースをコピーし、次のクエリ（基本階層を使用して過度のコストを回避）を使用し、この動作を監視します。

CREATE DATABASE Database1_copy AS COPY OF Database1 ( EDITION = 'basic' );