- DBMSの役割
データを効率よく管理し、障害時にはデータを復旧し、不正アクセスからデータを保護したりするためには、いくつもの高度な技術を組み合わせなければなりません。データベースの利用者が常にこれらの対処方法を熟知し運用することは至難の業です。そこでこのような一連の機能を一手に引き受けてくれるのが「DBMS」と呼ばれるソフトウェアです。このおかげで利用者はデータがどのように管理されているかを考える必要がなくなり、取得したデータの活用方法だけに考えを集中できるようになります。
- データ保護機能
トラブルの予防、復旧
- 機密保護
・ユーザ認証（ID,パスワード）
・アクセス権（参照、更新）
・利用状況の記録（ログ）
・盗聴防止（暗号化）
- 排他制御
データへの同時アクセス制御
・トランザクション処理
DBへの一連の処理単位
確定（コミット）、取消し（ロールバック）
※トランザクション成功時自動コミット(手動も可能)
OLTP（On-Line Transaction Processing）
（ACID特性）
| 原子性（Atomicity） |
コミットまたはロールバック |
| 一貫性（Consistency） |
更新に矛盾がない |
| 隔離性（Lsolation） |
他のトランザクションに干渉しない |
| 持続性（Durability） |
障害時も結果が失われない |
・ロック
| 種類 |
用途 |
参照 |
更新 |
| 共有ロック |
参照時 |
○ |
× |
| 占有ロック |
更新時 |
× |
× |
↓
複数プログラムが解除待ち
| A |
資源X |
資源Y |
B |
| → |
Aロック |
Bロック |
← |
|
→Y |
X← |
|
|
（相互にロックできない） |
|
| デッドロック |
(回避策)
| ロック順序を決める |
|
| タイムアウト |
|
| 楽観的方式 |
|
タイムスタンプ
(時刻印) |
トランザクション開始時刻と
データ更新時刻を比較
（開始＞更新：変更されていない） |
（その他）
並列トランザクションの問題
| ロストアップデート |
更新したのに他のトランザクションで上書きされる |
| ダーティーリード |
取り消した更新を読み込んでしまう |
| ノンリピータブルリード |
同じトランザクションで1回目と2回目で読み込んだ値が異なる |
| ファントムリード |
他のトランザクションによって読み込むデータが異なる |
- 負荷軽減
ストアドプロシージャ
・定型SQLを専用形式に変換(中間言語)
・DBMSへ登録（クライアントから呼び出し）
↓
処理時間、ネットワークトラフィックの軽減
- 障害復旧
・バックアップファイル（定期：全データ） ※差分、増分
・ジャーナルファイル（適時：更新内容） ※ログファイル
※ログは未確定時はメモリ(バッファ)上
→コミット時にディスク(確定)：OracleではREDOログ
(参考)
http://www.atmarkit.co.jp/flinux/rensai/oracle03/oracle03.html
（障害種別）
- 論理的障害（プログラムエラー）
ロールバック（UNDO)
ジャーナルの”更新前”情報参照
↓
トランザクション開始時点の状態
※DBMSが自動で行う（エマージェンシーリスタート）
- 物理的障害（ディスク破損）
ロールフォワード（REDO)
バックアップファイル（直前）
＋ ジャーナルの”更新後”情報参照
↓
障害直前の状態
※人が手動で行う（ウォーム/コールドリスタート）
（チェックポイント） ※セーブポイント、同期点
メモリ(データ)→ディスク反映
（トランザクション実行時：不完全）
※処理速度向上
システム障害対策などの復旧時間の短縮
| コミット(適時) |
→ |
メモリ(キャッシュ、バッファログ)データの更新
ジャーナルファイルの確定 |
チェックポイント
(定期)
|
→ |
ディスク(DBファイル)への更新
・トランザクション情報(実行中、完了)
・DB状態出力(メモリ内容)
・コミット済みジャーナルのクリア
・未コミットジャーナルの保存 |
※DBMSにより実装は異なる
(例)
システム障害発生時の システム障害発生
チェックポイント ｜
――――┼――――――――――――――┼―――――→
Ｔ１ ｜ ｜ 時間
├――┤｜ ｜
｜ Ｔ２ ｜
├―┼――――――――――――――┼………┤
｜Ｔ３ ｜
├――┼――――┤ ｜
｜ ｜
ロールフォワードによって障害回復をしなければならないトランザクションは「T3」
（参照元）
http://www.shunzei.com/mm/backnumber/vol_378_20000621.txt |
┌───────┬───────────────────┐
│トランザクション │データベースに対するRead回数とWrite回数 │
┝━━━━━━━┿━━━━━━━━━━━━━━━━━━━┥
│ T1，T2 │ Read 10回，Write 20回 │
│ T3，T4 │ Read 100回 │
│ T5，T6 │ Read 20回，Write 10回 │
└───────┴───────────────────┘
───────────────────→ 時間
┌─┐ │
T1 ───-●│ │ │
│チ│ │
T2 ───┤ェ├──● │障
│ッ│ │
T3 │ク│ ───────┤害
│ポ│ │
T4 ────┤イ├────────┤発
│ン│ │
T5 │ト│──────● │生
│ │ │
T6 │ │ ───────┤
└─┘ │
●はトランザクションがコミットされたことを示す。
┌─────┬─────┐
│前進復帰 │後退復帰 │
│─────┼─────┤
│T2，T5 │T6 │
└─────┴─────┘
(参照元)
http://www.melma.com/backnumber_189_3168389/ |
(参考問題)
http://homepage3.nifty.com/shinoburin/SV0609.html
（2層コミットメント制御）
・分散データベース更新
↓
同期（セキュア状態）
※更新状態確認
↓
コミット／ロールバック
- メンテナンス
フラグメンテーション解消
↓
再編成
- スキーマモデル
データの独立性の向上
・スキーマ
データベースを構成する定義情報
メタデータ（データの意味）、データ構造(枠組み)など
※データと構造を別にすることで独立性向上
・3層スキーマ
（ANSI/X3/SPARC：米国規格協会/標準化計画委員会が提案)
↓
↓
|
- 外部スキーマ(副：サブスキーマ)
利用目的に応じて作成
（アプリケーション、ユーザ用インタフェース）
例：ビュー（概念スキーマの一部、組合せ）
※アプリケーション依存
- 概念スキーマ
データの論理構造（データ項目、属性）
論理データモデルに従って表現
（ツリー、ネットワーク、リレーショナル）
※システム非依存
例：テーブル（RDB)、セット（NWDB)
- 内部スキーマ(記憶スキーマ)
データの物理構造（データ記録、編成法）
例：ISAM編成
※DBMSによって異なる
|
※COBOL（CODASYL)：副→スキーマ→記憶
（モデルとスキーマの関係）
| 概念データモデル｜ |
論理データモデル｜ |
物理データモデル |
| −−−−−−−−− |
−−−−−−−− |
−−−−−−− |
|
|
