データベース
第 12 回 DB の運用、管理、保守
鈴木幸市
今日の内容
情報管理とデータベース運用
サーバの運用とは
バックアップ
リカバリ
クラッシュリカバリ、アーカイブリカバリ、ディザス
タリカバリ
運転監視
性能、負荷、 SQL プラン
インデックスやテーブルのメンテナンス
システム運用
ストレージサイズ
CPU/ ストレージ性能監視
情報管理とデータベース運用 (1)
組織の情報管理ポリシーがまず重要
情報の分類
重要なものかそうでないのか
災害の場合などでもなくてはならない情報は「重要」
どこまで見せるか
関係者限り、社内限り
情報の保管方法
暗号化するかどうか
鍵をかけて保管するか ( 紙、 CD-ROM などの媒体 )
情報の保管期間
情報の廃棄方法
普通に「ごみ」として捨てる ( 産業廃棄物 )
人目に触れないように溶解処分する
シュレッダーで処分する
ディスクなどは、内容を完全消去して処分する
情報管理とデータベース運用 (2)
データベースの運用も組織の情報管理ポリシーに
合わせて行わなければならない
サーバをどこに置くか
オフィスの中
サーバルームの中
入退出を制限する/しない
データセンター
サーバの操作を制限するか
管理者の制限
操作できるクライアントの制限
記録をどうとるか
操作ログ
ビデオでの記録
データベースの運用とは
放っておいてもサーバは動き続けない
定期的に行う仕事がある
情報の更新
プログラムの入れ替え
システムのアップグレード
セキュリティ対策
時々出てくる仕事
故障した部品の交換
クラッシュした場合は元に戻さないといけない (リ
カバリ )
定期的なアプリケーションの起動
月締め、半期締めなどの経理処理
データベースも放っておいては動かない
安全に安定してデータの読み書きが続けら
れることが最も重要
運用基準や人的な体制を決めて初めて運転を
継続できる
データ管理者の役目
データベースがきちんと動いていることを
監視
まずいところがあれば手直ししていく
クラッシュしたらデータベースを復旧しなけ
ればならない ( リカバリ )
システムの管理部門や人員配置
情報統括役員 (CIO, Chief Information Officer)
の役割 システムのデータ管理ポリ
シーの制定
サーバの設置場所
サーバへのアクセス方法
認証方法
操作記録の取得と保存方法
バックアップの方針
障害 ( 事故・故障 ) 発生時
の対処方針
実施管理監督
データベース管理者、シス
テム管理者の仕事の管理
管理ポリシーへのフィード
バック
障害発生時の対応指示
システム管理者の役割
サーバの運転監視
リソース利用状況
CPU使用率
ストレージ使用率
ネットワーク使用率
ソフトウェアの運転監視
エラーログ監視
OS
データベース
WWWサーバ
その他のミドルウェアやアプリケー ション
セキュリティ監視
ウィルス監視
不正アクセス監視
外部からのアタック
その他不正利用
バックアップ
ファイルバックアップ
定期的に実施
ハードウェアの保守点検
クラッシュ後のシステム復旧(リカバ
リ )
データベース管理者よりも
守備範囲は広い
日常のシステムの運転監視
データベース管理者 (DBA: Database Administrator)
の役割 データベースの設計
アプリケーションからの要件定義
データベースサイズ
トランザクション
運転管理方式
バックアップ方式
バックアップの頻度
ログの保存
障害対応
リカバリ方式
データベースチューニング
DBMSの運転パラメータの調整
メモリ
チェックポイントなどの間隔
SQLチューニング
インデックスの作成・削除
テーブルの分割などの管理
その他データベースの問題解決のすべて
データベースのバックアップ
バックアップとは
障害復旧に備えてデータを安全な場所にコピーしてお
くこと
コールドバックアップとホットバック
アップ
コールドバックアップ
データベースを停止させてデータベースをバックアップ
システムによっては容認できないこともある
どんな DBMS でも可能な方法
ホットバックアップ
データベースを運転しながらデータベースをバックアップ
できるかどうかは DBMS に依存
データベース本体とログをセットでバックアップする
リカバリにはログも必要
バックアップはサーバリソースを消費する (CPU 、 I/O 、
ネットワーク )
運転に影響がないようにスケジュールを組み必要がある
夜間時間帯など、負荷が少ない時間帯で行うなど
運用条件に合わせてバックアップのツールを作ってお
く
ログもバックアップする
バックアップ後のデータベースの変更を保存
データベース自身のバックアップよりは小さい
(一般的に)
リカバリ
障害が起こった場合にデータベースはどうなるか
メモリに残った情報は消えてしまう
ファイルの中身は処理の途中状態
↓
そのままではデータベースは運転できない
そこで、リカバリが必要になる
バックアップをつかってデータベースをバックアップ
時点まで戻す
やることもやらないことも→次のスライド
ログを使ってその後の変更を反映させる
障害時に実行途中だったトランザクションをアボート
する ( なかったことにする )
リカバリの種類
クラッシュリカバリ
バックアップを使わずに行うリカバリ
アーカイブリカバリ
バックアップを使って行うリカバリ
ディザスタリカバリ
災害などでサーバ設備が破壊された場合のシステムの復
旧
設備再建などがまず先
別な場所でサーバを立て直したりすることがある
クラッシュリカバリ
データファイルへの破損は
ない状態 (内容は矛盾して
いるかもしれない )
バックアップを使わなくて
も、ログを使ってデータ
ベースを最新状態に戻せる
通常は、データベースの運
転を開始すればクラッシュ
リカバリは自動的に実行さ
れる
データベース運転開始
に少し時間がかかるか
もしれない程度
データベースの運転ロ
グには記録される
アーカイブリカバリ
バックアップを使ってデータベースを復旧する
データベースをバックアップからコピー
バックアップしておいたログ (アーカイブログ )をコピー
サーバに残っている最新のログ (アクティブログ )とあーカーブログの内容をデータベースに 書き込む
アクティブログが破壊されていることもある
アクティブログのデータが書き込めないのでデータベースは古い状態のままになってしまう
最後の部分は手動でデータベースを復旧する
アクティブログを最初から二重に書いておく
運転監視
データベースの運転状況を把握、問題を解決する
極端に遅い SQL はないか
対応方法
インデックスの整備
ビューの定義を変更して効率を上げる
SQLの変更を提案
システム開発/保守者と連携することが大事
処理のピークでもきちんと応答しているか
対応方法
ボトルネックの特定
システム保守者への報告
アプリケーションの改善
ハードウェア設備の更改
バッチ処理 (毎月、半期ごとなどで大量の処理が必要なときに流す ) がきち
んと実行できているか
定期的に経理の帳簿や報告書などを作成することがある
アプリケーションの改善
ハードウェアの更改
日常の監視をきちんとおこなうこと
問題が小さなうちに解決を図る
ハードウェアの更改計画は月単位から年単位の時間がかかる(お金もかか
データベースの保守
データベースの保守
データベースの再構成
データベース内のデータ配置を最適にする
空き領域の最適化
タプルの格納順序の最適化
ツールを使って行うことができる
セキュリティ関連
データベースの利用ユーザの追加・削除・変更
データベースを利用するクライアントの追加・削除・変更
データベースの運転条件の保守
タイミングなど
チェックポイントの間隔
キャッシュの変更分を何分おきにデータベースに書き戻すか
ログの量、性能、リカバリ時間に影響する