静岡大学情報学部「データベースシステム論」講義スライド 第13回：データベースの運用

1. データベースシステム論
2016年度 前期 水曜 1･2時限 情24教室
担当：横山昌平
データベースシステム論 第 回2016 [ 13 ] 1p.

2. 講義計画
• 関係データベースの歴史と基本概念
• SQLの基礎と応用(演習を含めつつ)
• データベースの設計と構成
• SQL問い合わせ処理とそれを支える技術
• 関係データモデル以外のデータベース
データベースシステム論 第 回2016 [ 13 ] 2p.
※現時点での予定です。進捗に応じて変更します。
27Apr.
20Apr.
13Apr.
25May
18May
11May
1June
8June
22June
15June
6July
29July
20July
27July
模
試 13July
質
問

3. データベースシステム論
第１３回 データベースの運用
データベースシステム論 第 回2016 [ 13 ] 3p.

4. • 論理的に分割できない一連の処理の塊
• 例
• 複数人がプリンタで複数ページの書類を同時印刷
トランザクション
データベースシステム論 第 回2016 [ 13 ] 4p.
p.1 p.2 p.3 p.4 p.5
p.1 p.2 p.3 p.4 p.5
p.1
p.1 p.2
p.2 p.3
p.3
p.4 p.5
p.4 p.5
トランザクション

5. ＤＢとトランザクション
データベースシステム論 第 回2016 [ 13 ] 5p.
複数人が同時に利用するデータベースは、
それぞれの人の処理が混合してしまうと、
保持するデータの整合性が取れなくなっ
てしまう。つまりDBMSとして「トラン
ザクション」が適正に処理されることを
保障する事は、最も重要な要件である。
ACID特性トランザクション処理に求められる性質

6. Atomicity 原子性
データベースシステム論 第 回2016 [ 13 ] 6p.
ある一連の処理の実行時に、以下の二つ
の状態のどちらかである事を保障
• 一連の処理が全て処理されている
• 一連の処理が全く処理されていない
処理前 処理中 処理後処理１ 処理２
２つのデータ更新処理からなるトランザクションにおいて、
処理２が失敗し、データが「処理中」の状態になってしまっ
たとしても、「処理前」の状態に戻す(ロールバック)。

7. ワインID 名前 産地ID 価格
1 シャブリ A 2400
7 コンチャ・イ・トロ E 980
価格
1400
-20
Consistency 一貫性
データベースシステム論 第 回2016 [ 13 ] 7p.
データの持つルール(制約等)を満たさな
くする処理が与えられた時に、その処理
を失敗させる(実行しない)事を保障。
タイムセール1000円引き！
あり得ない！
商品値段の価格は負の値にはならない。これはSQLでは
CREATE TABLE文のCHECK句において定義できる。DBMSは
一貫性を保障する為に、下記のような「結果として価格が負
になる」UPDATE文が与えられたとしても処理を失敗させる。

8. Isolation 独立性
データベースシステム論 第 回2016 [ 13 ] 8p.
トランザクション中の過程が他のトラン
ザクションから隠ぺいされる事を保障。
例えば購入したワインを一件ずつ在庫テーブルから在庫数を
減らすトランザクションを考える。その際、別のユーザのト
ランザクション中の中間状態のデータが、他のトランザク
ションから見えてしまったら問題が生じてしまう。
赤 ロゼ 白
1 1 1
0 1 1
0 0 1
赤1つ
ロゼ1つ 処理後の状態
中間状態
赤とロゼを一本
ずつ買おう～
ロゼと白を一本
ずつ買おう～

9. Durability 耐久性
データベースシステム論 第 回2016 [ 13 ] 9p.
一旦トランザクションの成功を返したら、
その後システムクラッシュ等のトラブル
が発生したとしても、成功時点の状態が
データベースに反映されている事を保障。
データ データ
トランザクション成功！
障害発生

10. ACID特性
•Atomicity 原子性
•Consistency 一貫性
•Isolation 独立性
•Durability 耐久性
データベースシステム論 第 回2016 [ 13 ] 10p.
DBMSを使えば、トランザクションの処理にお
いて、これら四つの特性が(一応…)保障される。

11. 「一連の処理」とは
• ロワール(did=c)のワインはもう売るのを辞めよう！
データベースシステム論 第 回2016 [ 13 ] 11p.
wid name did price
1 シャブリ A 2400
2 ジュヴレシャンベルタン A 3000
3 サンテミリオン B 5800
4 オーメドック B 2200
5 サンセール C 2800
6 シャンパン D 4000
7 コンチャ・イ・トロ E 980
did district
A ブルゴーニュ
B ボルドー
C ロワール
D シャンパーニュ
E チリ
wine vineyard
1. wineテーブルからdidがCの行を削除
2. vineyardテーブルからdidがCの行を削除
ト
ラ
ン
ザ
ク
シ
ョ
ン

12. ACID特性が無いと起こる問題
データベースシステム論 第 回2016 [ 13 ] 12p.
1. wineテーブルからdidがCの行を削除
2. vineyardテーブルからdidがCの行を削除
1. wineテーブルにミュスカデを追加～♪
wid name did price
1 シャブリ A 2400
2 ジュヴレシャンベルタン A 3000
3 サンテミリオン B 5800
4 オーメドック B 2200
5 サンセール C 2800
6 シャンパン D 4000
1000 コンチャ・イ・トロ E 980
1001 ミュスカデ C 2100
did district
A ブルゴーニュ
B ボルドー
C ロワール
D シャンパーニュ
E チリ
wine vineyard
1001 ミュスカデ C 2100

13. トランザクションを定義
データベースシステム論 第 回2016 [ 13 ] 13p.
1. トランザクションを始めます
4. トランザクションを失敗(アボート)させます
2. wineテーブルからdidがCの行を削除
3. vineyardテーブルからdidがCの行を削除
4. トランザクションを成功(コミット)させます
START TRANSACTION;
トランザクション開始
前の状態に戻す
トランザクションに
よる変更を確定する。
もしくは・・・
ROLLBACK;
COMMIT;
START TRANSACTION

14. つまり・・・
データベースシステム論 第 回2016 [ 13 ] 14p.
START TRANSACTION;
ROLLBACK;
COMMIT;
処理処理
処理
処理
処理
処理
処理
処理
処理
処理
処理
ACIDが保障される！

15. 試してみよう
• psqlを二つ使おう。
データベースシステム論 第 回2016 [ 13 ] 15p.
A
B

16. ROLLBACKの動作
• トランザクションの開始
• wineテーブル全行削除
• 確認(コミット前)
• トランザクションをアボート
• 確認(コミット後)
データベースシステム論 第 回2016 [ 13 ] 16p.
START TRANSACTION;
DELETE FROM wine;
SELECT * FROM wine;
ROLLBACK;
SELECT * FROM wine;
A
A
A
A
A

17. ROLLBACKの動作 － 結果
データベースシステム論 第 回2016 [ 13 ] 17p.
dbsys=# START TRANSACTION;;
START TRANSACTION
dbsys=# DELETE FROM wine;
DELETE 8
dbsys=# SELECT * FROM wine;
wid | name | did | price
-----+------+-----+-------
(0 行)
dbsys=# ROLLBACK;
ROLLBACK
dbsys=# SELECT * FROM wine;
wid | name | did | price
------+------------------------+-----+-------
1 | シャブリ | A | 2400
2 | ジュヴレシャンベルタン | A | 3000
3 | サンテミリオン | B | 5800
4 | オーメドック | B | 2200
5 | サンセール | C | 2800
6 | シャンパン | D | 4000
7 | コンチャ・イ・トロ | E | 980
(7 行)

18. COMMITの動作
• トランザクションの開始
• wineテーブル一行追加
• 確認①
• トランザクションをコミット
• 確認②
データベースシステム論 第 回2016 [ 13 ] 18p.
START TRANSACTION;
INSERT INTO wine VALUES(8,’ミュスカデ’,’C’,2100);
SELECT * FROM wine;
COMMIT;
SELECT * FROM wine;
A
A
A
A
A
SELECT * FROM wine; B
SELECT * FROM wine; B

19. COMMITの動作 － 結果
• コミット前
データベースシステム論 第 回2016 [ 13 ] 19p.
dbsys=# START TRANSACTION;
START TRANSACTION
dbsys=# INSERT INTO wine VALUES(1001,'ミュスカデ','C',2100);
INSERT 0 1
dbsys=# SELECT * FROM wine;
wid | name | did | price
------+------------------------+-----+-------
1 | シャブリ | A | 2400
2 | ジュヴレシャンベルタン | A | 3000
3 | サンテミリオン | B | 5800
4 | オーメドック | B | 2200
5 | サンセール | C | 2800
6 | シャンパン | D | 4000
7 | コンチャ・イ・トロ | E | 980
8 | ミュスカデ | C | 2100
(8 行)
dbsys=# commit;
COMMIT
dbsys=# select * from wine;
wid | name | did | price
------+------------------------+-----+-------
1 | シャブリ | A | 2400
2 | ジュヴレシャンベルタン | A | 3000
3 | サンテミリオン | B | 5800
4 | オーメドック | B | 2200
5 | サンセール | C | 2800
6 | シャンパン | D | 4000
7 | コンチャ・イ・トロ | E | 980
(7 行)
A
B
ACID - 独立性：トランザクションAのコミット前の変更はBから見えない

20. COMMITの動作 － 結果
• コミット後
データベースシステム論 第 回2016 [ 13 ] 20p.
dbsys=# START TRANSACTION;
START TRANSACTION
dbsys=# INSERT INTO wine VALUES(1001,'ミュスカデ','C',2100);
INSERT 0 1
dbsys=# SELECT * FROM wine;
wid | name | did | price
------+------------------------+-----+-------
1 | シャブリ | A | 2400
2 | ジュヴレシャンベルタン | A | 3000
3 | サンテミリオン | B | 5800
4 | オーメドック | B | 2200
5 | サンセール | C | 2800
6 | シャンパン | D | 4000
7 | コンチャ・イ・トロ | E | 980
8 | ミュスカデ | C | 2100
(8 行)
dbsys=# commit;
COMMIT
dbsys=# select * from wine;
wid | name | did | price
------+------------------------+-----+-------
1 | シャブリ | A | 2400
2 | ジュヴレシャンベルタン | A | 3000
3 | サンテミリオン | B | 5800
4 | オーメドック | B | 2200
5 | サンセール | C | 2800
6 | シャンパン | D | 4000
7 | コンチャ・イ・トロ | E | 980
8 | ミュスカデ | C | 2100
(8 行)
A
B
ACID - 独立性： Aがコミットした瞬間、Aによるデータの変更がBからも見える

21. 状態とその遷移
• トランザクションの状態を一般化して考える
データベースシステム論 第 回2016 [ 13 ] 21p.
active
partially
committed
failed
committed
terminated
start transaction
read/write
rollback
commit
rollback

22. SQLとトランザクション
• トランザクションの開始
• トランザクションのコミット
• トランザクションのアボート
データベースシステム論 第 回2016 [ 13 ] 22p.
START TRANSACTION mode [,mode];
COMMIT [WORK | TRANSACTION];
ROLLBACK [WORK | TRANSACTION];
※スライドはPostgreSQLでの例、標準SQLは教科書参照

23. トランザクションの種類
• 自動コミット(Autocommit)モード
• 明示的な(Explicit)モード
• 暗黙の(Implicit)モード
データベースシステム論 第 回2016 [ 13 ] 23p.
※教科書の記述が不明瞭ですがSTART TRANSACTION 文のmodeではありません
各SQL文が実行されるたびに、トランザクションがコ
ミットされる。(PostgreSQLのデフォルト動作)
START TRANSACTION文でトランザクションを開始し、
COMMIT/ROLLBACKで終了させる。
最初のSQL文の発行でトランザクションを自動で開始
し、COMMIT/ROLLBACKで終了させる。(標準SQL仕様)

24. トランザクション処理とは
否
データベースシステム論 第 回2016 [ 13 ] 24p.
単にある人のコマンド群が実行さ
れている間、別の人のコマンドの
処理をブロックしているだけ？
同時にできる処理は同時に走らせ
ないと、とてもじゃないが無駄な
待ち時間が大量に発生して、シス
テムのスループットが上がらない。

25. 同時実行制御 (Concurrency Control)
• 前提：一人ずつ利用すれば問題は起きない
• この時代、そんな悠長な事は言っていられない！
• トランザクション
• 複数を同時に実行しても破綻しない仕組み・概念
• 同時実行の利点
• CPUとI/Oは並列に実行できるのでディスクならび
にCPUが暇な(idle)時間の量を減らせる。
• 短いトランザクションと長いトランザクションをイ
ンターリーブ(interleave、交互に差し挟む)して実行
すると，通常は短いトランザクションのほうが早く
終わり，長いトランザクションの後回しになること
は少ない．
データベースシステム論 第 回2016 [ 13 ] 25p.

26. 同時実行による異常パターン①
• Dirty Read (Write-Read conflict)
データベースシステム論 第 回2016 [ 13 ] 26p.
T1 T2
read(x);
x = x – d;
write(x);
read(x);
y=x;
write(y);
abort;
ここでのxはT1によって更新
済みだが、後でT1はアボート
している事に注目！

27. 同時実行による異常パターン②
• Unrepeatable Read (Read-Write conflict)
データベースシステム論 第 回2016 [ 13 ] 27p.
T1 T2
read(x);
read(x);
x=x + d;
write(x);
read(x);
同じトランザクション内で
同じxを呼び出しているにも
関わらず得られる値が異なる。

28. 同時実行による異常パターン③
• Lost Update (Write-Write conflict)
データベースシステム論 第 回2016 [ 13 ] 28p.
T1 T2
read(x);
read(x);
x=x + d;
write(x);
x = x – d;
write(x); T2の方で行われた更新が、T1の
更新によってロストしてしまう。

29. 同時実行による異常パターン④
• Phantom Read
データベースシステム論 第 回2016 [ 13 ] 29p.
T1 T2
read(X);
delete(X[n]);
read(X);
T2により集合Xの要素nが消去され
た、それによりT1の最初のreadで
現れた要素nが二番目のreadでは
現れないという現象が起こる

30. 用語
• スケジュール
• 直列スケジュール
• 直列可能
• 競合直列可能スケジュール
データベースシステム論 第 回2016 [ 13 ] 30p.
複数のトランザクション(T1,T2,…,Tn)に含まれる操作の列
並列実行した場合と直列に実行した場合で結果が等しい場合、そ
の操作は直列可能であるという。
トランザクションを並列実行した場合に直列スケジュールと等価
の結果を得られるスケジュール
トランザクションを1つずつ逐次的に処理するスケジュール

31. 同時実行の利点
[前提]
• もし、全く関係の無いリソースへのアクセスな
らば、処理は(何も考えず)同時に実行する事で、
CPUを効果的に酷使する事ができる。
データベースシステム論 第 回2016 [ 13 ] 31p.
T1 T2
read(x);
処理Ｘ
write(x);
read(y);
処理Ｙ
write(y);
T1 T2
read(x);
処理Ｘ read(y);
write(x) 処理Ｙ
write(y)

32. 先行グラフ(直列可能性グラフ)
データベースシステム論 第 回2016 [ 13 ] 32p.
T1 T2
read(x);
write(x);
read(x);
write(x);
T1 T2
read(x);
read(x);
write(x)
write(x)
ルール：トランザクションTiに対してノードを割り当てる。Tiがx
をwriteした後にTjがxをwriteもしくはreadしたか、Tiがxをreadし
た後にTjがxをwriteしたら、TiからTjにエッジを作る。
T1 T2
T1 T2
閉
路
閉路がなければ競合直列可能

33. 競合直列可能にスケジュール
• 並列性を保ちつつ、右のようなスケジュールを
避け、左のようなスケジュールを得るには？
データベースシステム論 第 回2016 [ 13 ] 33p.
T1 T2
read(x);
write(x);
read(x);
write(x);
T1 T2
read(x);
read(x);
write(x)
write(x)
ロック

34. ロックとは
• リソースに鍵をかけ、他のトランザクションか
らアクセスを許さない事
• 共有ロック (Shared LockまたはRead Lock)
• 専有ロック (Exclusive LockまたはWrite Lock)
データベースシステム論 第 回2016 [ 13 ] 34p.
他のトランザクションから同じリソースを共有ロックする事は
できるが、専有ロックはできない状態のロック。データの読み込
みの際にリソースをロックする場合に利用する。
他のトランザクションから同じリソースを共有ロック・専有ロッ
クいずれもできない状態のロック。データを書き込む際にリソー
スをロックする場合に利用する。
※他のトランザクションはリソースがアンロックされるまで、処理を待つ必要がある。

35. DBにおけるロックのレベル
• データベース
• データベース全体に対して１つのトランザクションのみ
が処理を許される状態。
• システムのバージョンアップ等に利用
• テーブルスペース
• 複数のテーブルをロック
• テーブル
• １つのテーブル全体をロック
• ブロック、ページ、エクステント
• 物理的な領域に対するロック
• 行
• 特定の行のみのロック
• 検索し、外部プログラムで値を変更し、更新する場合等
データベースシステム論 第 回2016 [ 13 ] 35p.

36. ロックを使うにあたって
• 使用上の注意
• 実際にはもう少しロックの種類があります(p.127)
• また、DBMSによっても異なります。
• 例：PostgreSQL
• http://www.postgresql.jp/document/9.3/html/explicit-
locking.html
• さらに明示的なロックの構文はDBMS毎に異なって
いるので注意が必要です。
• 例えばテーブル単位のロックを提供するLock Table
文は標準SQLでは定義されていません。
データベースシステム論 第 回2016 [ 13 ] 36p.

37. テーブルのロック
データベースシステム論 第 回2016 [ 13 ] 37p.
LOCK TABLE テーブル名
IN lockmode MODE;
求するロック
モード
現在のロックモード
ACCESS
SHARE
ROW SHARE
ROW
EXCLUSIVE
SHARE
UPDATE
EXCLUSIVE
SHARE
SHARE ROW
EXCLUSIVE
EXCLUSIVE
ACCESS
EXCLUSIVE
ACCESS
SHARE
X
ROW SHARE X X
ROW
EXCLUSIVE
X X X X
SHARE
UPDATE
EXCLUSIVE
X X X X X
SHARE X X X X X
SHARE ROW
EXCLUSIVE
X X X X X X
EXCLUSIVE X X X X X X X
ACCESS
EXCLUSIVE
X X X X X X X X

38. テーブルのロック － SQL
• ワインテーブルをロックし確認
• 結果からロックが機能している事を確認せよ
• トランザクション終了と共にロックは解除
• 解除された事を確認せよ(どうやって？)
データベースシステム論 第 回2016 [ 13 ] 38p.
START TRANSACTION;
LOCK wine IN ACCESS EXCLUSIVE MODE;
SELECT * FROM wine;
SELECT * FROM wine;
A
B
A
COMMIT; もしくは ROLLBACK;
A

39. 行のロック
• UPDATE
• 専有ロック
• ここで得られた行に対して後でUPDATEする場合
• SHARE
• 共有ロック
データベースシステム論 第 回2016 [ 13 ] 39p.
SELECT *
FROM テーブル名 ・・・
FOR [UPDATE,SHARE];

40. 行のロック－ SQL
• ワインテーブルのある行をロックし確認
• wid=1の行のみがロックされている事を確認
• 次にその行の価格を更新する
• トランザクション終了と共にロックは解除
• BのブロックされたSELECT文の出力はprice=100000？
データベースシステム論 第 回2016 [ 13 ] 40p.
START TRANSACTION;
SELECT * FROM wine WHERE wid = 1 FOR UPDATE;
START TRANSACTION;
SELECT * FROM wine WHERE wid = 2 FOR UPDATE;
SELECT * FROM wine WHERE wid = 1 FOR UPDATE; B
A
UPDATE wine SET price = 100000 WHERE wid = 1;
COMMIT;A

41. デッドロック
• ロックにつきものの忌まわしい問題
• 例
データベースシステム論 第 回2016 [ 13 ] 41p.
二つのリソースに対してロックをかける二つのトランザクション
が、互いにアンロックを待って先に進めなくなる状態。
※二つ以上でも可
T1 T2
lock(x);
lock(y);
lock(y);
lock(x);
T2がyのロックを解除するのを待つ
T1がyのロックを解除するのを待つ
一生ストップ！

42. デッドロック－ SQL
• wineとvineyardを使ってデッドロックを起こす
データベースシステム論 第 回2016 [ 13 ] 42p.
START TRANSACTION;
LOCK wine IN ACCESS EXCLUSIVE MODE;
START TRANSACTION;
LOCK vineyard IN ACCESS EXCLUSIVE MODE;
A
B
A
LOCK vineyard IN ACCESS EXCLUSIVE MODE;
LOCK wine IN ACCESS EXCLUSIVE MODE;
B
どうなった？

43. デッドロック－ 結果
データベースシステム論 第 回2016 [ 13 ] 43p.
dbsys=# START TRANSACTION;
START TRANSACTION
dbsys=# LOCK wine IN ACCESS EXCLUSIVE MODE;
LOCK TABLE
dbsys=# LOCK vineyard IN ACCESS EXCLUSIVE MODE;
ERROR: デッドロックを検出しました
DETAIL: プロセス 9284 は AccessExclusiveLock を データベース16393のリレーション
24616 で待機していましたが、プロセス 5712 でブロックされました
プロセス 5712 は AccessExclusiveLock を データベース16393のリレーション24621 で
待機していましたが、プロセス 9284 でブロックされました
HINT: クエリーの詳細はサーバログを参照してください
作為的にデッドロックを起こすと、すぐに
PostgreSQLがそのデッドロックを検知してエ
ラーを返すとともに、ロックを解除してくれた。

44. デッドロックの検出
• wait-forグラフ（待ちグラフ）
• ノード：各トランザクション
• エッジ：ロック解除を待つ方向
• 閉路=デッドロックの発生→どちらかをアボート
データベースシステム論 第 回2016 [ 13 ] 44p.
T1 T2
lock(x);
lock(y);
lock(y);
lock(x);
T1 T2
閉
路
y
x
x

45. トランザクションの隔離レベル
• SERIALIZABLE
• REPEATEABLE READ
• READ COMMITTED ※PostgreSQLのデフォルト
• READ UNCOMMITTED
データベースシステム論 第 回2016 [ 13 ] 45p.
※順番がだいぶ前後しますがこちらがSTART TRANSACTION 文のmodeです。
個別のリソースを明示的にロックするのではなく、トランザク
ションの利用形態を開始時に示しDBMSがロックの制御をする。
トランザクションを最大限隔離し直列可能性を保証する。このトランザク
ションがread/writeしたデータはコミットされるまで、他のトランザクション
によって変更できない。
SERIALIZABLEに比べて、INSERされた値は他のトランザクションから見える。
Phantom Readが発生しうる。
さらにUPDATEされた値は他のトランザクションから見える。Phantom Read
とUnrepeatable Readが発生しうる。
Read onlyなトランザクション隔離レベル。Phantom ReadとUnrepeatable
Readに加えてDirty Readも発生しうる。

46. 隔離レベル vs 異常と性能
Dirty Read Unrepeatable
Read
Phantom
Read
Read Uncommitted ○ ○ ○
Read Committed × ○ ○
Reputable Read × × ○
Selealizable × × ×
データベースシステム論 第 回2016 [ 13 ] 46p.
パフォーマンス 安全性

47. 次回予告
第１４回 総復習！
データベースシステム論 第 回2016 [ 13 ] 47p.

48. 第14回 総復習！
• 予習
• 対応箇所：教科書全部
• 関連個所：PostgreSQL 9.3.1文書 全部
• 最終回(第15回)
• ロックの続きとRDB以外のデータベース
• この回の話は期末試験範囲外とします
データベースシステム論 第 回2016 [ 13 ] 48p.
期末テスト対策