✅ Oracle Databaseのバックアップとリカバリー
🔷 1. 想定される障害と対処
種類 | 説明 | 対応方法 |
---|---|---|
ステートメント障害 | 単一SQL(SELECT/INSERTなど)が失敗 | 特に問題なければ放置、必要なら権限や構文を見直す |
ユーザープロセス障害 | セッションが異常終了 | 通常はDBA介入不要だが、頻発時は調査 |
ネットワーク障害 | 接続切れやリスナー停止など | 冗長化(複数NIC、Backupリスナー)で対応 |
人的ミス | テーブル削除や誤データ入力 | コミット前はROLLBACK、後はRMANやFlashbackで対応 |
インスタンス障害 | サーバ・プロセス異常停止 | 自動リカバリ(REDOログ適用)+調査必要 |
データ障害 | データファイル欠損、破損 | バックアップから復旧+設定見直し |
ディスク障害 | ストレージ自体の損傷 | RMANによる復旧が必要 |
データセンター全体の障害 | 災害や停電で拠点全体停止 | Oracle Data Guard で他拠点に待機系構築 |
🔷 2. データ保護のための基本設定
✅ Fast Recovery Area(FRA)
-
バックアップやアーカイブログを集中管理する専用領域。
-
設定すべきパラメータ:
-
DB_RECOVERY_FILE_DEST
: 保存先パス -
DB_RECOVERY_FILE_DEST_SIZE
: 使用可能サイズ(例:10GB)
-
-
容量不足になるとDB停止の危険 → 監視が重要
-
モニタ用ビュー:
-
V$RECOVERY_FILE_DEST
-
V$RECOVERY_AREA_USAGE
-
🔷 3. コントロールファイルの多重化(Multiplex)
-
コントロールファイルはDB構造を定義する重要ファイル。
-
最低でも2つ以上のコピーを異なるディスクに保存。
-
バックアップコマンド:
🔷 4. REDOログの多重化とアーカイブログ
✅ REDOロググループ
-
トランザクションの記録用ログ。
-
グループごとに2ファイル以上で構成するのが望ましい(ミラーリング)。
-
ALTER DATABASE ADD LOGFILE MEMBER
で追加可能。 -
V$LOG
とV$LOGFILE
で状態確認。 -
手動ログスイッチで新メンバーを有効化。
✅ アーカイブログモード
-
過去のREDOログをアーカイブ(保存)し、リカバリ時に使用可能。
-
**Point-in-Time Recovery(特定時点復旧)**が可能になる。
-
常にON推奨。
🔷 5. Oracle Recovery Manager(RMAN)の概要
機能 | 内容 |
---|---|
バックアップ管理 | フル/増分バックアップ、部分バックアップなど |
ストレージ対応 | ディスク/テープ両対応(テープはMedia Management Libraryが必要) |
パフォーマンス | 並列処理、重複排除、圧縮などに対応 |
コマンドライン | rman target / で接続、SHOW ALL で設定確認 |
🔷 6. バックアップの種類
種類 | 内容 | 特徴 |
---|---|---|
フルバックアップ | 全データブロックをバックアップ | 復旧が簡単 |
増分バックアップ | 変更されたデータブロックのみ | Level 0(初回)/Level 1(差分or累積) |
レベル | 対象 | コマンド例 |
---|---|---|
Level 0 | フルバックアップと同じ | BACKUP INCREMENTAL LEVEL 0 DATABASE |
Level 1(差分) | 直近の増分以降の変更分 | BACKUP INCREMENTAL LEVEL 1 DATABASE |
Level 1(累積) | 直近のLevel 0以降の変更分 | BACKUP INCREMENTAL LEVEL 1 CUMULATIVE DATABASE |
🔷 7. バックアップ形式
種類 | 説明 | 特徴 |
---|---|---|
Backup Sets | データが圧縮されるOracle独自形式 | 空ブロックを保存しない=省スペース |
Image Copies | OSレベルのコピー(バイト単位) | 復旧が高速/サイズが大きい |
🔷 8. RMANの設定パラメータ例(SHOW ALL
)
パラメータ | 意味 |
---|---|
RETENTION POLICY TO REDUNDANCY 1 | 同一バックアップ1世代を保持 |
BACKUP OPTIMIZATION ON | 重複ファイルのバックアップをスキップ |
DEFAULT DEVICE TYPE TO DISK | ディスク保存をデフォルトに |
CONTROLFILE AUTOBACKUP ON | コントロールファイル自動バックアップ |
MAXSETSIZE | バックアップセットの最大サイズ |
COMPRESSION ALGORITHM BASIC | 圧縮アルゴリズムの設定 |
ARCHIVELOG DELETION POLICY TO NONE | アーカイブログの削除ポリシーなし(全保存) |
1. 基本的なバックアップコマンド
-
BACKUP DATABASE PLUS ARCHIVELOG
→ CDBのルートに接続して実行。全PDBのデータファイルや制御ファイル、SPFILE、アーカイブログも含む。 -
BACKUP DATABASE ROOT
→ ルートコンテナのみバックアップ。 -
個別PDBに接続して
BACKUP DATABASE
→ そのPDBのみバックアップされる。
2. バックアップにタグを付ける
バックアップに TAG
を指定することで、後で識別しやすくなります。
3. 増分バックアップ
-
INCREMENTAL LEVEL 0
(フルバックアップ相当) -
INCREMENTAL LEVEL 1
(差分バックアップ)-
Differential:前回の差分 or 累積バックアップ以降の変更ブロックをバックアップ
-
Cumulative:前回のLevel 0以降のすべての変更ブロックをバックアップ(復元時の手間が減るが、容量が大きい)
-
4. Oracle推奨のバックアップ戦略
-
最初に
LEVEL 0
のイメージコピーを作成し、以降LEVEL 1
バックアップでロールフォワード(更新) -
RECOVER COPY OF DATABASE
→ イメージコピーを最新に更新 -
BACKUP INCREMENTAL LEVEL 1
→ 前日以降の変更をバックアップ -
タグ管理が重要
5. シェルスクリプトとcronで自動化
-
シェルスクリプト内で
RUN {}
ブロックを使いRMAN操作 -
cronに登録して毎日自動で5:01AMにバックアップ実行
-
MAILTO
変数にメールアドレスを指定すれば結果を受信可
6. RMANのバックアップ確認
-
LIST BACKUP
で全バックアップを確認
→ タグ、ステータス、サイズ、PDB名などを表示 -
LIST BACKUP SUMMARY
で要約表示 -
特定のPDBやデータファイル、アーカイブログなど絞り込み可
7. バックアップ監視のためのSQL
-
V$BACKUP_SET
やV$RMAN_STATUS
などのビューを使用 -
例:2日間バックアップのないPDBを検出して通知
8. 不要なバックアップの管理
-
Obsolete(不要):RMAN設定の保持期間を超えたもの
-
例:冗長性1に設定 → 2個目以降は不要
-
DELETE OBSOLETE
で削除
-
-
Expired(消失):OS上から手動で削除されたファイル
-
CROSSCHECK BACKUP
→ 状態を更新 -
DELETE EXPIRED BACKUP
でメタ情報からも削除
-
⚠️ バックアップファイルはOSから直接削除しないこと!
9. アーカイブログの管理
-
BACKUP ARCHIVELOG ALL
→ アーカイブログのみバックアップ -
DELETE BACKUP OF ARCHIVELOG ALL
→ バックアップ削除 -
DELETE ARCHIVELOG ALL
→ バックアップが存在していないと削除されない(安全設計)
10. バックアップの整合性チェック
-
VALIDATE DATABASE CHECK LOGICAL
→ データファイルの論理・物理破損を検出 -
VALIDATE BACKUPSET
→ バックアップファイルが壊れていないか検証
【1】インスタンスの起動とマウント
-
STARTUP
コマンドを実行すると、Oracle インスタンスは初期化パラメータファイル(init.ora
またはspfile
)を読み込み、MOUNT
状態へ移行します。 -
MOUNT状態では制御ファイル(control file)の整合性を確認。1つでも欠損・破損していると起動に失敗します。
-
OPEN
状態に移行する際は、REDOログとデータファイルの存在確認が行われ、欠落があるとエラーが出てMOUNT状態に留まります。
【2】障害検出とリカバリ確認
-
データファイル欠落時には
V$RECOVER_FILE
ビューで確認可能。 -
RMAN
(Recovery Manager)には Data Recovery Advisor(DRA)ツールがあり、自動で障害を分析・修復提案します(※ただし、RAC未対応)。
【3】PDBのデータファイル喪失とリカバリ手順
-
ファイルを移動しPDB起動失敗を再現 →
RMAN
でフルバックアップから復旧 →RESETLOGS
付きでOPEN。
【4】コントロールファイルの喪失
-
複数構成していれば残っているファイルをコピーして再利用可能。全損失時は別の方法が必要。
【5】REDOログメンバーの破損
-
複数メンバー構成の場合、1つが壊れても影響はない。
-
壊れたファイルは
ALTER DATABASE DROP LOGFILE MEMBER
とADD LOGFILE MEMBER
で再作成可能。
【6】完全リカバリ(Complete Recovery)
-
例:18:00のバックアップ+その後のアーカイブログで最新状態に復旧。
【7】不完全リカバリ(Point-in-Time Recovery)
-
特定の時点に戻す復旧。途中のトランザクションは失われる。
-
例:19:00のアプリ更新がバグを含む → 18:59:59 に戻す。
-
必ず
RESETLOGS
オプションでデータベースを開く必要がある。
【8】CDB/PDBのポイントインタイム・リカバリ
-
CDB全体を戻す場合は、すべてのPDBも同様に巻き戻される。
-
SET UNTIL TIME
とRESETLOGS
を併用。
🔹チェックポイントとインスタンスリカバリの仕組み
-
チェックポイント(Checkpoint) は、バッファキャッシュの変更済みデータをディスクのデータファイルに同期する仕組み。
-
COMMIT
は REDOログに書かれるだけで、データファイルには即座に反映されない。 -
ログスイッチ 時にチェックポイントがトリガーされ、どこからリカバリを始めるかの「位置情報」が記録される。
-
インスタンスリカバリ では、データファイルのヘッダにあるSCNと制御ファイル内のSCNを比較して、必要に応じてREDOログを適用。
-
最後にロールバックを行い、未コミットトランザクションを取り消す。
🔹MTTR(平均復旧時間)設定
-
FAST_START_MTTR_TARGET
パラメータを設定することで、Oracleが自動的にチェックポイント間隔を調整。 -
小さい値にすると復旧は早いが、IO負荷が上がる。大きすぎると復旧が遅くなる。
-
実際の推定復旧時間は
V$INSTANCE_RECOVERY
ビューで確認可能。