基本情報技術者 試験情報＆徹底解説 -新制度に完全対応-

「ロックの粒度が大きい（ロックをかける範囲が大きい）と、ロックの管理は簡単になるが
ロックの競合によるロックの解除までの待ち時間が増え、処理効率（スループット）は下がり、1つのロックで広い範囲を制限できるので、トランザクション１つ当たりのロックの個数は減る。」
という理解をしているのですが、これはあっているでしょうか？
もしあっていた場合、ロックの個数は減るのにスループットが下がるのかぁと思ってしまっているのですが、１つ当たりのロックの個数が減るとスループットが下がる理由をどなたか教えていただきたいです。よろしくお願いします。

この投稿は投稿者により削除されました。(2023.09.07 21:57)

区役所で考えた場合に以下のような形になります。
・区役所＝テーブル
・窓口＝行（レコード）

いろいろな申請を出したいのに一人の人が処理を終えるまですべての人が待たされた場合、すごい行列が出来て永遠と待たされると思います。

その逆で各申請窓口がバラバラで処理してくれれば、行列の出来る人数は各窓口にバラけて待たされる時間は減ると思います。

コレと同じ事が発生してます。 

前者はロックをする番人の苦労は減りますが時間単位に処理（スループット）出来る人数は少なくなります。
後者はロックをする番人の苦労は増えますが時間単位の処理は多くできそうです。

３つ質問があります。
１，１つのトランザクションはテーブル上のある範囲であらわすことができると考えてもよいでしょうか？
２，1があっていた場合、その場合はその範囲は長方形でしょうか？
３，1があっていた場合、ロックが占める範囲は、複数のトランザクションが占めるテーブル上の範囲を跨ぐのではなく、テーブル上の１つトランザクションが占める範囲をはみ出さないような状態になりますですでしょうか？
よろしくお願いします。

重ねて質問失礼します。
例に出していただいたロックをする番人は、ここでは市役所の窓口に並ぶ人の列を整理する市役所の人と考えることはできますでしょうか？もし違えば、ロックをする番人が市役所の例でいうとどのような人か例を教えていただけると嬉しいです。
よろしくお願いします。

>１，１つのトランザクションはテーブル上のある範囲であらわすことができると考えてもよいでしょうか？
テーブル全体を取るロックとある特定の行だけを取るロックの２種類があると思っております。
「１」はある特定の行を表していると思われ、それはロックの粒度が細かいという状態だと思います。

>２，1があっていた場合、その場合はその範囲は長方形でしょうか？
１つのカラムだけで行うロック方法を私は知りませんのでおそらく行（長方形）が最小単位だと思います。
ここからは予測ですがDBは各行のユニーク情報（PKのような内部PKみたいなもの）をもっています。その単位でロックしているのではないでしょうか

>３，1があっていた場合、ロックが占める範囲は、複数のトランザクションが占めるテーブル上の範囲を跨ぐのではなく、テーブル上の１つトランザクションが占める範囲をはみ出さないような状態になりますですでしょうか？
複数のトランザクションが共有ロックされているテーブルを跨ぐ事はあると思います。
専有ロックであった場合ロックできるトランザクションはそもそも１つで「３」のはみ出さない状態となります。

>ここでは市役所の窓口に並ぶ人の列を整理する市役所の人と考えることはできますでしょうか？
私の想定ではあっています。
が、DBに合わせた時にロックの番人は各テーブルの担当ではなく、DBMSそのもののハズなのでちょっと合わないかもしれませんね。

重ねて質問失礼します。
>テーブル全体を取るロックとある特定の行だけを取るロックの２種類があると思っております。
ここでいう特定の行というのは1つの行だけのことではなく、
複数の連続する行のまとまりをとるロックもあるという理解はあっていますでしょうか？
よろしくお願いします。

>複数の連続する行のまとまりをとるロックもあるという理解はあっていますでしょうか？

あっています。
たとえばアップデート文でwhere句の書き方によっては複数行を対象に取れますよね

>ロックの個数は減るのにスループットが下がるのかぁと思ってしまっているのですが、１つ当たりのロックの個数が減るとスループットが下がる理由をどなたか教えていただきたいです

10行のレコードからなる表があった場合、トランザクションAは奇数行目（1,3,5,7,9行目の5個のロック）だけをロックすればいいけどめんどくさいから表全体の1個のロックにする。するとトランザクションAのロックの個数は5から1に減少するが、2行目のレコードをロックする必要があるトランザクションBがロックを掛けるときにトランザクションAのロックの解放を待たなければいけないなら、その待ち時間だけスループットが低下するということではないですか。

多くの質問に答えたいただき、ありがとうございます。
DBのロックの粒度についての理解がだいぶ深まった気がします。
ありがとうございました。

すみません。追加で３つ質問したいです。
１，表はDBのメモリ容量と同じように考えることができて、まーぼさんのお話のようにトランザクションAが実行中に別のトランザクションBが実行されても、仮にDBがもつ表のの広さが十分であれば、そもそも競合せずスループットも下がらないということは起き得ますでしょうか？
２，１が正しい場合、１つのトランザクションを実行する際は、ロック以外の操作のためにも、表のメモリを使うという認識はあっていますでしょうか？
３，1と2が正しい場合、まーぼさんがご説明していただいた例では、トランザクションAは奇数行目（1,3,5,7,9行目の5個のロック）だけをロックすればよく、トランザクションBは少なくとも2行目のレコードをロックする必要があると思いますが、このとき、トランザクションAを実行させるためのロック及びロック以外の操作のためには2行目のレコードは使用しないという認識はあっていますでしょうか？
よろしくお願いします。

次の2つのテーブルが格納されている1つのデータベースに対して、


あるトランザクションが次のSQL文を実行する場合を想定する。
UPDATE 注文
SET   数量 = 数量 + 1
WHERE 製品コード = 'P1';

(1) データベース単位のロック機能しかサポートしないDBMS
あるトランザクションが上記のUPDATE文を実行すると、
データベース全体（注文表も製品表も）に排他ロックがかけられる。
このトランザクションの実行中は、
製品表の行を追加/更新/削除する別のトランザクションは実行できないし、
注文表の製品コード='P1'以外の行を追加/更新/削除する別のトランザクションも実行できない。

(2) テーブル単位のロック機能をサポートするDBMS
あるトランザクションが上記のUPDATE文を実行すると、
注文表全体に排他ロックがかけられる。
このトランザクションの実行中は、
製品表の行を追加/更新/削除する別のトランザクションは実行できるけれど、
注文表の製品コード='P1'以外の行を追加/更新/削除する別のトランザクションは実行できない。

(3) 行単位のロック機能をサポートするDBMS
あるトランザクションが上記のUPDATE文を実行すると、
注文表の(4月15日, P1, 100), (5月6日, P1, 100)の2行に対して排他ロックがかけられる。
このトランザクションの実行中に同時並行して、
注文表の製品コード='P1'以外の行を追加/更新/削除する別のトランザクションが実行できる。

>２，１が正しい場合、１つのトランザクションを実行する際は、ロック以外の操作のためにも、表のメモリを使うという認識はあっていますでしょうか？

こちら表のメモリというのが私がデータベースに疎いので申し訳ないですが、近いもので表領域と受け取っておきます。

表領域は複数テーブルを管理する目的で利用されている領域と認識しておりデータ及びテーブルの管理情報（キーやインデックスやシノニムなど）やトランザクションによる更新情報や更新前情報なども含んでいると思っています。

ロック以外のどのような操作でこの辺が使われいるのかという質問だと思いますが、基本情報レベルではおそらくちゃんとした回答がいただけないと思うので、せっかく良い疑問だと思うのでデータベーススペシャリストの方で質問されたほうが良いと思います。
※あちらも丁度試験が近く質問板が活発なので

山本さんの一連の発言に目を通していて、

(a)テーブル単位のロック
と
(b)行単位のロック（ただし全行が更新対象）

を区別できているだろうかと、ちょっと心配になりました。
ロックの粒度（ロックの単位）が大きいのは(a)です。

(3) 行単位のロック機能をサポートするDBMS  において
UPDATE 注文
SET   数量 = 数量 + 1;
というSQLを実行すると、注文表の全体がロック範囲になりますけれど、
全行が更新対象なのだからこれは当然の結果といえます。
これは (a)テーブル単位のロック とはまったく別です。

皆様  お答え頂いてありがとうございました。

この投稿は投稿者により削除されました。(2023.09.08 17:46)

>表はDBのメモリ容量と同じように考えることができて
そもそも、表領域自体はハードディスクで物理ディスクにあって、メモリ（データバッファ）の内容はクエリの結果を一時保存しておくものだから、表領域がメモリにあるという考え方は違います

>(3) 行単位のロック機能をサポートするDBMS  において
結局、この前提においても、where条件が索引探索可能（条件左辺にインデックスが貼られていて、条件左辺で関数未使用であり、複数列インデックスであれば指定列がインデックス順であること、とかいろいろあるが）かどうかで不可能なら表ロック（表探索）になるので、whereで絞ればそれで何でもかんでも行ロックなんだ、ということにはなりません
あくまで行ロックになるかは、対象のエンティティ（表）の索引とクエリの兼ね合いがあっているか、の問題です

※このあたりはDBSPの平成23年午後1問3とかを参照してください