2

オンプレミスの SQL Server を Azure に移植しています。それを Azure に移植して微調整を行った後、同期ストアド プロシージャにかかる時間が大幅に長くなったことに気付きました。現在のセットアップは、さまざまな Web サービスを呼び出して中間テーブルにデータをダウンロードすることから始めます (すべての Web サービスにテーブルが必要なため、一時テーブルやテーブル変数ではなく、通常のテーブルです)。これらのすべての Web サービスが完了したら、このテーブルには約 25K のレコードがあります。

中間テーブルの準備ができたら、sync ストアド プロシージャを呼び出します。これは、ほとんど計算を行わず、この中間テーブルのいくつかの列を更新します。中間テーブルが更新されると、メイン テーブルが削除され、新しい値が挿入されます。このストアド プロシージャは、以前のシステムでは 30 秒だったのに対し、Azure では約 5 分かかります。テーブルで通常の No Lock を試したり、サマリー テーブルなどを使用したりしましたが、あまり改善されませんでした。実行計画を確認した後、ボトルネックがクラスター化インデックスのスキャンと更新であることに気付きました。多くの手順を実行するため、メイン データ テーブルにこのクラスター インデックスが必要ですが、中間テーブルにこのクラスター化インデックスを配置する必要はまったくありません。

Azure では、すべてのテーブルにクラスター化インデックスが必要であり、これを中間テーブルに配置すると、パフォーマンスが大幅に低下します。このボトルネックを改善する方法が思いつかないので、フィードバックをいただければ幸いです。

UPDATE 更新プロセスはますます遅くなり、最終的にデータベース全体がロックされるようになりました。何時間も掘り下げた後、次のことがわかりました。

SQL Azure - 更新と挿入のために DB 全体をロックする 1 つのセッション

http://social.technet.microsoft.com/Forums/en-US/c3003a28-8beb-4860-85b2-03cf6d0312a8/substantial-increase-in-sereplslowsecondarythrottle-wait-type-to-the-point-we-cant-任意の実行

データベースをバックアップし、別の Azure サーバーに復元した後、問題は解決したようです。クラウドの高可用性について、または上記の投稿で述べたように:

「基本的に、Sql Azure を高可用性にしている側面は、データベースをランダムに利用できなくすることです。それが私たちを殺していなければ、私は皮肉なことに笑います。」

4

1 に答える 1

0

増加する ID 列をクラスター化インデックスとして使用する人工キーを使用してみましたか? クラスター化インデックスとして別の値を使用してページを常に分割している場合は、インデックスのメンテナンスに貢献している可能性があります。クラスターとして増加し続けるインデックスは、それを減らします。

于 2013-09-06T01:14:49.627 に答える