0

Microsoft Sync Framework 2.1 を使用して、多数の同時エンド ユーザーを中央データベース サーバーと同期しています。

環境：

  • 1 つの中央データベース サーバーに接続する 1500 の同時クライアント
  • Web サービスはサーバー側の SyncProvider として使用されます
  • 2.000.000 レコードを超える複数のテーブルがあります

問題
SelectChanges SP は定期的に時間切れになります (CommandTimeout = 60)。
おそらく非常に遅い理由：

  • Sync Framework は local_update_peer_timestamp 列にインデックスを作成しますが、まったく使用しません。
    • 統計を再作成した後でも、インデックスは使用されません
    • インデックス ヒントは、シーク操作の代わりにフル インデックス スキャンを引き起こします (指定されたタイムスタンプが最大の local_update_peer_timestamp 値よりもはるかに大きい場合でも)

質問 私の意見では、何かが本当にうまくいっていません。MS Sql Server 2008 R2 は適切な実行計画を作成できるはずです

  • Select Changes を改善するにはどうすればよいですか?
    • 8.000.000 レコードを超える可能性のあるテーブルを考慮する
    • SQL Serverがインデックスを使用して実行計画を構築していることを確認する
  • このクエリが遅すぎるその他の潜在的な理由はありますか?
4

2 に答える 2

1

にはCommandTimeoutプロパティがあるSqlSyncProviderため、かかる時間が気にならない場合は、最長の selectchanges クエリにかかる時間を超えるようにコマンドのタイムアウトを設定することで、この問題を回避できます。

selectchanges ストアド プロシージャにもパフォーマンスの問題があることに気付きました。追跡テーブルのクエリに関して、SQL は遅いようです。通常の操作では追跡テーブルにクエリを実行しないため、これの少なくとも一部はメモリ不足であると思われます。それらには更新/挿入がありますが、それらによって適切なインデックスの適切な部分がメモリにロードされるとは思いません。通常の操作が行われていない隔離された環境では、selectchanges 手順がはるかに高速になります。

追跡テーブルに列を追加して (フィルター列のリストに列を追加することによって)、カスタム インデックスを設定し、カスタム インデックスを使用するようにストアド プロシージャを変更してみてください。私はそれを行うことである程度の改善を得ることができましたが、関連するすべての努力を正当化するには不十分かもしれません.

于 2012-04-16T16:12:38.623 に答える
1

フィルター句を使用している場合、フィルター基準は where 句に含まれます。つまり、SQL サーバーが select の各行に対して where 句を実行することを選択する可能性があり、重大なパフォーマンスの問題が発生します。

この場合にできることは、結合でフィルタ条件を適用する独自のバージョンの selectchanges sproc を作成することです。これにより、パフォーマンスが向上します。

于 2014-03-07T19:02:22.460 に答える