データセットクエリでNOLOCKヒントを設定するためのオプション


7

いくつかのコンテキスト:
最初に、クエリにロックのヒントを含まず、レポートを「まっすぐ」に書きました。より大きなレポートでは、これによりロックの問題が発生することがあります。で、最初の私たちは、使用してこれを是正WITH (NOLOCK)クエリ内のテーブルのためのヒントを。

それはテーブルのいずれかのヒントを忘れることは簡単です、非常に目障りだし、(b)は()ので、私たちは第二のアプローチの設定に移動TRANSACTION ISOLATION LEVELREAD UNCOMMITTED、各データセットのクエリの先頭に(罰金です)。

ご想像のとおり、いずれかのデータセットのヒントは忘れがちです。だからこれは質問につながります:


質問:ヒントをレポートクエリと共に送信するためのオプションは何NOLOCKですか?

PS。これはある程度XY問題(クエリの最適化、運用データベースに関するレポートの作成など、他の多くのXオプション)であることに気付きましたが、それでもそれ自体を有効な質問にしようとしました。


オプション:
上記のオプションを以下に示します。機能するかどうかについて知りたいオプションが追加されています。

  1. WITH (NOLOCK)各テーブルのヒントを設定します。(目障りで、非常に忘れやすい)
  2. READ UNCOMMITTEDクエリ全体に対して分離レベルをに設定します。(まだ忘れやすい)
  3. これをレポートレベルで指定することはできますか?たとえば、1つのレポートのすべてのデータセットクエリがロックなしで実行されるようにします。
  4. これを他のSSRSレベルで指定することは可能ですか?たとえば、これを特定のレポートフォルダに設定したり、拡張機能を利用したりできますか?
  5. これをデータソース/接続文字列レベルで指定することは可能ですか?たとえば、関連するすべてのレポートで特定の「No-lock-data-source」を使用していますか?
  6. 前のオプションに関連:特定の「no-lock-sql-user」(接続で使用されるもの)にデフォルトのロックヒントを指定することはおそらく可能ですか?
  7. ???

実行可能なオプションはどれですか?私が見逃したオプションはありますか?


すべての場所でnolocksを実行するか、分離を変更して全面的にコミットされていない状態で読み取ることに関する問題は、データ品質の問題です。ダーティーリードを取得するだけでなく、同じデータを2回返すか、データを完全に見逃す可能性があります。設計を調べて、別のレポートデータベースを作成する時期かどうかを確認することをお勧めします。この質問を
マイクウォルシュ

@MikeWalsh同意する。それは、XY問題についても少し触れたいところです。それでも、ロックヒントを使用するオプションと場所がいつであるかを知ることは、注意して使用する場合に有益です。
Jeroen、2012年

回答:


5

簡単な答え:

  1. ご指摘のとおり、機能します。
  2. ご指摘のとおり、機能します。
  3. これは機能していないようです。私はオプションを手元に表示していませんでした。その質問が尋ねられるたびに、答えは常にストアドプロシージャの分離レベルの設定に戻ります
  4. 私はそうは思いません。SSRSはデータベースエンジンよりも上位の抽象化レイヤーにあるため、ある意味では、分離レベルが「気になりません」。結局のところ、レポートで非RDBMSソリューションを使用できます。
  5. これは動作しません。 接続文字列で分離レベルを設定することはできません
  6. これはうまくいくかもしれません。 ログイントリガーを作成できます

レポートが最適化され、それでも問題を引き起こしている場合に実行可能ないくつかのオプションがあります。

  1. SQL 2012を使用している場合は、Always Onを使用します。SSRSレポートで使用できる読み取り専用のレプリカを作成できます。
  2. レプリケーションを使用する:リアルタイムが必要ない場合はスナップショット、リアルタイムに近い必要がある場合はトランザクション。
  3. Always Onの予算がない場合、またはレプリケーションを処理するための忍耐力がない場合は、安価な方法でレプリケーションを実行します。レポートに適したスキーマを作成します(つまり、テーブルを非正規化し、レポートを実行しやすい形式にする)、SSISを使用してそのレポートスキーマをフィードします。これは、エンドユーザーが「古い」データを使用できる場合(たとえば、毎時間または5分ごとに更新する場合)に機能します。欠点は、データモデルを2回設計することです。1つはOLTPモデル用、もう1つは疑似ウェアハウスモデル用です。有利な点は、一元化されたデータウェアハウスの方向に移動する場合、これは非常に役立つ演習です。

6

READ_COMMITTED_SNAPSHOTデータベースの行のバージョン管理を検討しましたか?

Kim Trippの良い記事がhttp://msdn.microsoft.com/en-us/library/ms345124%28v=sql.90%29.aspxにあります。

READ_COMMITTED_SNAPSHOTWITH (NOLOCK)ロックの競合が減少するため、スループットが向上し、長時間実行される集約またはクエリに絶対的なポイントインタイム整合性を提供するよりも優れた機能が可能になります。

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.