C# と VB.NET の質問掲示板

ASP.NET、C++/CLI、Java 何でもどうぞ

C# と VB.NET の入門サイト

Re[1]: ＳＥＬＥＣＴ文の共有ロックについて


(過去ログ 29 を表示中)
掲示板トップ C# と VB.NET 入門 新規作成 利用方法/規約 トピック表示 ランキング 記事検索 過去ログ

[トピック内 5 記事 (1 - 5 表示)]　 << 0 >>

■13718 / inTopicNo.1) 　ＳＥＬＥＣＴ文の共有ロックについて
  ▼■
□投稿者/ NORTH (17回)-(2008/02/03(Sun) 02:27:05)

分類:[データベース全般]　

2008/02/03(Sun) 02:38:15 編集(投稿者)

SQLサーバー2005

以下状況でSELECTした場合について教えて下さい。

テーブル　社員マスタ

社員コード　名前　部署コード
0001　　　　A氏　　001
0002　　　　B氏　　002
0003　　　　C氏　　003
プライマリーキーは社員コード
インデックスは
①社員コード
②部署コード
の２つ

BEGIN　TRANSACTION
UPDATE　社員マスタ
SET　部署コード='004'
FROM 社員マスタ
WHERE　社員コード='0003'
ここでわざとCommitしないで社員コード'0003'のレコードに排他ロック
がかかった状況を作ります。

この状況で
SELECT　*
FROM　社員マスタ
WHERE　社員コード='0002'を実行
問題なく結果が返ってくる。

SELECT　*
FROM　社員マスタ
WHERE　部署コード='002'を実行
排他ロック解除まちになり結果が返ってこない。
（WITH(NOLOCK)を指定すると当然返ってくる）

質問①
上のSELECT文は結果が返ってきて下は返ってこないのは
なぜですか？上は検索キーがプライマリーキーだから？

質問②
下のSELECT文実行後のテーブルの状態は
社員コード'0001'と'0002'は共有ロック状態ですか？
もしそうだとすればなぜですか？

SQLサーバーの設定は既定です。

質問③
マネージメントスタジオでテーブルのインデックスを
作成するときオプションに
"レコードロックする"というチェックボックスがありますが
これはどういう意味ですか？ここにチェックをいれないと
アクセスしたときテーブルロックしちゃいますか？

質問④
レコードのロックとインデックスは密接に関係してますか。
詳しい方は、説明お願いします。
引用返信 編集キー/
■13720 / inTopicNo.2) 　Re[1]: ＳＥＬＥＣＴ文の共有ロックについて
▲▼■
□投稿者/ はつね (422回)-(2008/02/03(Sun) 06:56:31)
はつね さんの Web サイト
■No13718 (NORTH さん) に返信
> 詳しい方は、説明お願いします。

SQL Serverのロックは行ロックじゃない場合もありますしインデックスがあると更に複雑になってしまうため、図なしで説明する自身がないので関連情報だけ。

情報１：
Enterprise Managerの[管理]-[現在の状況]メニューでロックの状況がみれたと思うのですがどうでしょうか。

情報２：
http://www.atmarkit.co.jp/fdotnet/entwebapp/entwebapp09/entwebapp09_01.html
引用返信 編集キー/
■13721 / inTopicNo.3) 　Re[2]: ＳＥＬＥＣＴ文の共有ロックについて
▲▼■
□投稿者/ 片桐 (67回)-(2008/02/03(Sun) 11:17:26)
片桐 さんの Web サイト
んー、簡単に言っちゃうと、

ある図書館で、ある一冊の本があるかどうかを探したい、とします。

その図書館では、索引目録があり、
その本の図書番号（プライマリーキー）が記録されていますから、探すにはそれだけを読めば場所を特定できます
図書番号が判らない場合には本棚まで行って、他の情報で本を探す必要があります

というときに、

図書番号で判っている→索引目録だけを見れば良い→今本棚で誰がその本を読んでいても問題ない
図書番号が判らない→本棚を探しに行く→今本棚で誰かがその本を見ている→その人が読み終わらないとその本を触れない

というのは想像できますか？

つまり、

SELECTクエリでインデックスサーチのみで処理できる→索引目録があればよいので本棚を探しにいかなくても良い
レコードロック→本棚で誰かがその本を見ているので、その人の用事がすむまで本棚の本を触れない
With No Lock →誰かがその本を見ていても、背表紙だけ覗き込んであったか無いかを探すことか許される

ということです。なので

インデックスにレコードロックをつける＝その図書館の索引目録は一冊だけで、誰かが使っていたらその人の用事がすむまで使えなくする、ということになります

実際には、もっと複雑なアルゴリズムが動いていますので、はつねさんが提示されている記事を参考に、自分で動きを確かめてみてください。現在の状況ページは書かれている意味がわかってくるとたくさんの勉強ができますですよ
引用返信 編集キー/
■13722 / inTopicNo.4) 　Re[1]: ＳＥＬＥＣＴ文の共有ロックについて
▲▼■
□投稿者/ やじゅ (86回)-(2008/02/03(Sun) 11:47:10)
やじゅ さんの Web サイト
■No13718 (NORTH さん) に返信
>
> 質問①
> 上のSELECT文は結果が返ってきて下は返ってこないのは
> なぜですか？上は検索キーがプライマリーキーだから？

下はインデックスにより行ロックがかかっているため。
上はプライマリーキーのみだから読取り可能

> 質問②
> 下のSELECT文実行後のテーブルの状態は
> 社員コード'0001'と'0002'は共有ロック状態ですか？
> もしそうだとすればなぜですか？

インデックスにより行ロックがかかっているため。

確かめてないが、下記によりロック行が分かるらしい、間違ってるかも(^^;
select * from 社員マスタ with (NOLOCK)
where 社員コード,部署コード not in (select 社員コード,部署コード from 社員マスタ with (READPAST))

> 質問③
> マネージメントスタジオでテーブルのインデックスを
> 作成するときオプションに
> "レコードロックする"というチェックボックスがありますが
> これはどういう意味ですか？ここにチェックをいれないと
> アクセスしたときテーブルロックしちゃいますか？

チェックをオフにすると、テーブルロックしちゃいます。

http://msdn2.microsoft.com/ja-jp/library/ms186872.aspx
[インデックスへのアクセス時に行ロックを使用する]
行レベルのロックを可能にします。
このチェック ボックスをオフにした場合、インデックスで行レベルのロックは使用されません。

> 質問④
> レコードのロックとインデックスは密接に関係してますか。
> 詳しい方は、説明お願いします。
>
インデックスは密接に関係しています。

詳しくは、はつねさんのリンク先でいいかと思います。
http://www.atmarkit.co.jp/fdotnet/entwebapp/entwebapp09/entwebapp09_01.html
引用返信 編集キー/
■13734 / inTopicNo.5) 　Re[1]: ＳＥＬＥＣＴ文の共有ロックについて
▲▼■
□投稿者/ 魔界の仮面弁士 (599回)-(2008/02/03(Sun) 21:23:32)
■No13718 (NORTH さん) に返信

こんなのとか。
http://www.unisys.co.jp/club/net_view/20030129.html
引用返信 編集キー/


トピック内ページ移動 / << 0 >>

このトピックに書きこむ

過去ログには書き込み不可

管理者用

- Child Tree -