オンプレミスの SQL Server を Azure に移植しています。それを Azure に移植して微調整を行った後、同期ストアド プロシージャにかかる時間が大幅に長くなったことに気付きました。現在のセットアップは、さまざまな Web サービスを呼び出して中間テーブルにデータをダウンロードすることから始めます (すべての Web サービスにテーブルが必要なため、一時テーブルやテーブル変数ではなく、通常のテーブルです)。これらのすべての Web サービスが完了したら、このテーブルには約 25K のレコードがあります。
中間テーブルの準備ができたら、sync ストアド プロシージャを呼び出します。これは、ほとんど計算を行わず、この中間テーブルのいくつかの列を更新します。中間テーブルが更新されると、メイン テーブルが削除され、新しい値が挿入されます。このストアド プロシージャは、以前のシステムでは 30 秒だったのに対し、Azure では約 5 分かかります。テーブルで通常の No Lock を試したり、サマリー テーブルなどを使用したりしましたが、あまり改善されませんでした。実行計画を確認した後、ボトルネックがクラスター化インデックスのスキャンと更新であることに気付きました。多くの手順を実行するため、メイン データ テーブルにこのクラスター インデックスが必要ですが、中間テーブルにこのクラスター化インデックスを配置する必要はまったくありません。
Azure では、すべてのテーブルにクラスター化インデックスが必要であり、これを中間テーブルに配置すると、パフォーマンスが大幅に低下します。このボトルネックを改善する方法が思いつかないので、フィードバックをいただければ幸いです。
UPDATE 更新プロセスはますます遅くなり、最終的にデータベース全体がロックされるようになりました。何時間も掘り下げた後、次のことがわかりました。
SQL Azure - 更新と挿入のために DB 全体をロックする 1 つのセッション
データベースをバックアップし、別の Azure サーバーに復元した後、問題は解決したようです。クラウドの高可用性について、または上記の投稿で述べたように:
「基本的に、Sql Azure を高可用性にしている側面は、データベースをランダムに利用できなくすることです。それが私たちを殺していなければ、私は皮肉なことに笑います。」