データベースシステム論13 － データベースの運用
•
1 like•3,481 views
静岡大学情報学部「データベースシステム論」講義スライド 第13回：データベースの運用
![データベースシステム論
2016年度 前期 水曜 1･2時限 情24教室
担当：横山昌平
データベースシステム論 第 回2016 [ 13 ] 1p.](https://image.slidesharecdn.com/13-140127104247-phpapp01/85/13-1-320.jpg)
![講義計画
• 関係データベースの歴史と基本概念
• SQLの基礎と応用(演習を含めつつ)
• データベースの設計と構成
• SQL問い合わせ処理とそれを支える技術
• 関係データモデル以外のデータベース
データベースシステム論 第 回2016 [ 13 ] 2p.
※現時点での予定です。進捗に応じて変更します。
27Apr.
20Apr.
13Apr.
25May
18May
11May
1June
8June
22June
15June
6July
29July
20July
27July
模
試 13July
質
問](data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7)
More Related Content
What's hot
What's hot (20)
Viewers also liked
Viewers also liked (20)
Similar to データベースシステム論13 － データベースの運用
Similar to データベースシステム論13 － データベースの運用 (20)
More from Shohei Yokoyama
データベースシステム論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. 期末テスト対策