0

私たちは SQL Server 2012 EE を使用していますが、現在 R/O ミラーでクエリを実行するオプションはありませんが、それは私の長期的な目標ですが、ミラーがまた、私が照会しているデータを更新しています。

2 つのデータベースの複数のテーブルを結合するビューがあり、既存のデータからの請求に使用されます。これらのテーブルのうち 3 つも、進行中のトランザクションによって積極的に更新されます。このビューを使用するレポートを実行することは以前は問題ではありませんでしたが、データベースが大きくなり、タイムアウトの問題が発生しました。最初にクエリがタイムアウトしたため、コマンド タイムアウトを 0 に設定し、4 つの CPU すべてを 90 分間 100% 固定するクエリを再実行してから、強制終了しました。その間、アクティブなトランザクションに問題はありませんでした。クエリを確認したところ、インデックスが作成されていない参加しているフィールドが見つかったので、そのフィールドにインデックスを作成し、レポートを再実行しました。レポートは 3 分で終了し、すべての CPU はビジー状態でしたが、固定されていませんでした。両方の回で同じデータ量がクエリされました。私は問題が解決したと考えました。もちろんその後、私の上司は同様のクエリを実行しました。データは多少多いかもしれませんが、それほど多くはないかもしれません。クエリの実行中に、ライブ トランザクションが 100% タイムアウトし始めました。その間、CPU 使用率を確認する機会がありませんでした。

だから私の質問は2つです：

  1. ライブおよびアクティブなデータベースを使用する必要がある場合、アクティブなトランザクションを継続できるように長い R/O クエリを実行する適切な方法は何ですか? NO LOCK を検討していますが、より良い標準的な方法があることを願っています。

  2. そして、sqlserver が 100% ビジー状態で 4 つの CPU をペグアウトし、ライブ トランザクションのタイムアウトを引き起こさない可能性がありますが、上司がクエリを実行したときに、インデックスを追加してクエリがはるかにうまく実行された後、ライブ更新トランザクションが 100% タイムアウトし始めます。 ?

これは多くの情報ではないことはわかっています。私はSQLプロファイリングとパフォーマンス監視にあまり詳しくありませんが、この動作はかなり奇妙に思え、ベストプラクティスが正しい回避策になることを望んでいます.

4

2 に答える 2

2

SELECTトランザクション分離レベルでのクエリの既定の動作は、READ_COMMITTEDクエリの実行中に共有ロックを取得して、要求されたデータの一貫性を提供することです (コミットされたデータの読み取りのみ)。これらのロックは通常、行レベルであり、クエリの実行中に各行が読み取られた直後にすぐに解放されます。また、ページ レベルとテーブル レベルでのインテント ロックの粒度が低いため、読み取り中のデータの同時更新が防止されます。実行計画の詳細によっては、クエリの実行中にテーブル レベルで共有ロックが保持される場合もあります。これにより、クエリの実行中にテーブルが更新されなくなり、リーダーがライターをブロックすることになります。

データベース オプションを設定すると、 READ_COMMITTED_SNAPSHOTSQL Server はロックの代わりに行のバージョン管理を使用して、同じ読み取りの一貫性を提供します。行バージョン ストアは tempdb で維持されるため、クエリによって要求された行がクエリの開始以降に変更された場合、代わりに最新のコミットされた行バージョンが返されます。この行のバージョン管理動作により、ロックが回避され、クエリが開始された時点のデータベースのステートメント レベルのスナップショットが効果的に提供されます。リーダーはライターをブロックせず、ライターはリーダーをブロックしません。READ_COMMITTED_SNAPSHOTデータベース オプションとSNAPSHOT分離レベルを混同しないでください(よくある間違いです)。

を設定することの欠点はREAD_COMMITTED_SNAPSHOT、リソースの使用量が増えることです。データベース オプションが有効になると、行ごとに追加の 14 バイトのストレージ オーバーヘッドが発生します。更新と削除により、tempdb に行バージョンが生成されます。これらのバージョンは、実行時間の最も長いクエリの実行中に tempdb 領域を必要とし、バージョン ストアの維持にオーバーヘッドがあります。また、リーダー - ブロック - ライターのロック動作に依存する既存のアプリケーションがあるかどうかも検討してください。このオーバーヘッドにもかかわらず、並行性の利点により、ワークロードによっては全体的なパフォーマンスが向上し、読み取りの整合性が提供される場合があります。詳細については、 http://technet.microsoft.com/en-us/library/ms188277.aspxを参照してください。

于 2014-10-04T14:42:05.263 に答える