問題タブ [nolock]

SQL Server 2005 で SQL ステートメントを記述する場合、READUNCOMMITTED クエリ ヒントは NOLOCK を意味しますか、それとも手動で指定する必要がありますか?

そうです：

と同じ：

Omar のブログでこの興味深い記事を読んでください。Linq to SQL は、コミットされていない読み取りを使用してトランザクションのデッドロックとクエリのタイムアウトの問題を解決します。

ここで解決しようとしている問題は、SQL の意味から、NOLOCK で Select ステートメントを使用するか、SET TRANSACTION LEVEL READ UNCOMMITTED を使用する必要があることです。そうしないと、DB の大量の行がロックされ、エラーが発生します。Omar が使用しているテクノロジは Linq2Sql です。問題は、C# データ アクセス コードでこれをどのように実現して、上記のことが起こらないようにするかということです。

基本的に、この投稿では、Omar は実際のサイトで作業し、SqlProfiler などのツールを使用してテストすることで解決策にたどり着きますが、Javed Hasan は MSDN ドキュメントや Scott Hanselman のブログ投稿などを使用して解決策にたどり着きます。

Omar は、次の使用を提案しています。

ジャベド・ハサンが提案するのに対し

StatckOverflow のようなボリュームの多いサイトで、この特定の問題について皆さんが何をしたか、またはこの点に関してジェフとその関係者が何をしたかを知りたいです。

編集: 最初の投稿を読んだ後、Omar の投稿でいくつか指摘したいことがあります。

1. 彼は彼のアプローチで接続の問題に遭遇しましたが、彼はそれを解決しました。彼の投稿を参照してください。
2. さらに重要なことに、彼は ADO.NET トランザクションの使用方法を試し、Scott Hanselman が彼のブログに書いたことを試してみたと述べましたが、大量のサイトでは機能せず、パフォーマンスがかなり低下します。Omar 氏は次のように述べています。量のウェブサイト。」

実行時間の長いクエリでタイムアウトの問題やデッドロックが発生することがあります。

NOLOCK をいつどこで使用するのが最も適切なのか疑問に思っています。

更新と挿入で使用しますか? または読み取りますか？

私は Kimball スタイルの DW (スター モデルのファクトとディメンション - 後から到着するファクトの行や列はなく、タイプ 2 のゆっくりと変化するディメンションの一部としての有効期限を除いて、ディメンションが変化する列はありません) を持っており、行を挿入および更新するための重い毎日の処理 (新しい日付) および月次および日次のレポート プロセス。古いデータを簡単にロールオフできるように、ファクト テーブルは日付ごとに分割されます。

コミットされていないデータが読み取られる可能性があることは理解してWITH(NOLOCK)いますが、ETL プロセスが失敗したりブロックされたりする原因となるロックを作成したくありません。

すべての場合において、DW から読み取るときは、変更されない日付のファクト テーブル (ファクト テーブルは日付によって分割されます) と、リンクされているファクトの属性が変更されないディメンション テーブルから読み取ります。 .

それで - 欠点はありますか？- おそらく実行計画、またはSELECT同じテーブルから並行して実行されるそのような -only クエリの操作で。

私はミッションクリティカルではないウェブサイトやアプリケーションを作成するビジネスをしています->例：銀行のソフトウェア、宇宙飛行、集中治療監視アプリケーションなど。あなたはアイデアを得ることができます。

それで、その大規模な免責事項で、いくつかのSQLステートメントでNOLOCKヒントを使用するのは悪いですか？数年前、SQL管理者の仲間から、「ダーティリード」に満足している場合は、NOLOCKを使用するように提案されました。これにより、各リードがロックされないため、システムのパフォーマンスが少し向上します。テーブル/行/何でも。

また、デッドロックが発生している場合は、これが優れたソリューションであると言われました。それで、SQLの第一人者がランダムなコードを手伝ってくれて、SQLコードのすべてのNOLOCKに気付くまで、私はその考えを数年間続け始めました。私は丁寧に叱られ、彼はそれを私に説明しようとしました（なぜそれが良くないのか）そして私はちょっと迷子になりました。彼の説明の本質は、「より深刻な問題に対するバンドエイドの解決策である」と感じました。特に、デッドロックが発生している場合はそうです。そのため、問題の根本を修正してください。

私は最近それについてグーグルをして、この投稿に出くわしました。

だから、いくつかのSQLデータベースの第一人者の先生は私を教えてくれますか？

まず第一に、NOLOCK を使用する必要があるかどうかを尋ねているわけではありません。それを乗り越えましょう。

問題は、SQLサーバーがデータを書き込む方法に帰着すると思いますか? 行全体が一度に書き込まれますか、それとも一度に列ごとに書き込まれますか?

NOLOCKヒントを検討中なのでお願いします。行全体が返される (または返されない) 限り、ダーティ リードは問題ありません。部分的に書き込まれた行は受け入れられません。

nolock と with(nolock) を使用した SQL ステートメントを見てきました。

と

上記の説明のうち、正しいものはどれですか?その理由は?

私たちは EF4 を評価していますが、私の DBA は、すべての SELECT ステートメントで NOLOCK ヒントを使用する必要があると言います。そのため、EF4を使用するときにこれを実現する方法を検討しています。

EF4 でこれを実現する方法に関するさまざまなアイデアを読みましたが、すべて回避策のようであり、Microsoft または EF4 によって認可されていません。LINQ-to-SQL / LINQ-to-Entities および EF4 を使用するときに SELECT ステートメントに NOLOCK ヒントを含めたいという人への「公式の Microsoft」応答は何ですか?

ちなみに、私が見つけた最高の情報はここにあり、このトピックに関心のあるすべての人にこのスレッドを読むことをお勧めします.

ありがとう。