SQL Azure データベースの奇妙な動作が発生しています。ストアド プロシージャが突然タイムアウトを開始した理由を調査しているときに (問題なく通常の作業を数か月行った後)、次の動作を見つけました (コードは、ストアド プロシージャからではなく、SQL Server mgmt studio コンソールからのものであり、実際のテーブル/フィールド名です)交換されましたが、問題を示しています)
私は非常に単純なクエリを実行しています
select * from dbo.mytable with (nolock) where field1 = 'somevalue'
クエリがそこでハングアップし、ステータス バーのインジケーターが回転し、ステータスが「クエリの実行中」になり、何も起こりません。実験として、何時間も実行したままにしましたが、何も起こりませんでした。SQL Azure モニターにデッドロックは表示されません。
他のフィールドによるフィルターを使用した同様のクエリは、すぐに実行されます。しかし、興味深いのは、sql mgmgt studio で別のウィンドウを開き、最初のクエリがハングしている間に同じデータベースで同じクエリを実行すると、問題なく即座に実行されることです。最初のウィンドウでクエリをキャンセルするとすぐに、2 番目のウィンドウでクエリを実行すると停止し、並列ウィンドウで実行された他のインスタンスは正常に実行されます。これまでのところ、これは 1 つのテーブルのみで、この特定のフィールドでフィルタリングした場合にのみ発生しています。残念ながら、これはデータベースのメイン テーブルです。
sys.dm_exec_requests のクエリを実行すると、クエリの wait_type が SE_REPL_SLOW_SECONDARY_THROTTLE であり、ステータスが最初はrunningであることが示されますが、その後suspendedに変わります。その間、他のウィンドウで同じクエリがSOS_SCHEDULER_YIELDのwait_typeで実行されています。しかし、それは実行されており、最初のものは実行されていません。
背景情報:
SQL Azure インスタンス、1 GB、使用済みスペース 35 MB、36 個のアクティブな接続 mytable
- 61K 行、15 列、30 MB、ID プライマリ キーにクラスター化インデックス、日付フィールドに非クラスター化インデックスがあります。
field1は varchar(16) null から派生したユーザー定義のデータ型ですが、フィールド自体は null ではないと定義されています。
mytable には同じデータ型で null ではない他のフィールドがあり、それらによるフィルタリングには問題はありません。
mytable にはアプリケーションのトランザクション情報が含まれており、挿入率が高くなっています。挿入は小さなトランザクションで発生しています。ロックの問題はありません。トランザクション外のすべての読み取りは、nolock ヒントを使用して行われます。
そのように動作するのは選択クエリだけではなく、その特定のフィールドを含むそのテーブルのあらゆる種類のクエリです。
このデータベースを他のサーバーに作成し、データをコピーして、問題が解決しないかどうかを確認しますが、データベース インスタンスに問題があるように感じます。
ありがとう