Oracle® Database

バックアップおよびリカバリ・ユーザーズ・ガイド

11gリリース2 (11.2)

B56269-05(原本部品番号:E10642-08)

2015年5月

RMANによるバックアップとリカバリ、RMANによるデータ転送、Oracleフラッシュバック技術およびユーザー管理のバックアップとリカバリを含む、Oracle Databaseのバックアップとリカバリについてのマニュアル

Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド11gリリース2(11.2)

B56269-05

Copyright © 2003, 2015, Oracle and/or its affiliates.All rights reserved.

原本著者: Lance Ashdown

協力者: Katherine Weill、Tammy Bednar、Anand Beldalker、Timothy Chien、Mark Dilman、Raymond Guzman、Stephan Haisley、Wei Hu、Alex Hwang、Ashok Joshi、Vasudha Krishnaswamy、J.William Lee Valarie Moore、Muthu Olagappan、Vsevolod Panteleenko、Francisco Sanchez、Vinay Srihari、Margaret Susairaj、Mike Stewart、Steven Wertheimer、Wanli Yang、Rob Zijlstra

このソフトウェアおよび関連ドキュメントの使用と開示は、ライセンス契約の制約条件に従うものとし、知的財産に関する法律により保護されています。ライセンス契約で明示的に許諾されている場合もしくは法律によって認められている場合を除き、形式、手段に関係なく、いかなる部分も使用、複写、複製、翻訳、放送、修正、ライセンス供与、送信、配布、発表、実行、公開または表示することはできません。このソフトウェアのリバース・エンジニアリング、逆アセンブル、逆コンパイルは互換性のために法律によって規定されている場合を除き、禁止されています。

ここに記載された情報は予告なしに変更される場合があります。また、誤りが無いことの保証はいたしかねます。誤りを見つけた場合は、オラクル社までご連絡ください。

このソフトウェアまたは関連ドキュメントを、米国政府機関もしくは米国政府機関に代わってこのソフトウェアまたは関連ドキュメントをライセンスされた者に提供する場合は、次の通知が適用されます。

U.S. GOVERNMENT END USERS: Oracle programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, delivered to U.S. Government end users are "commercial computer software" pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations.As such, use, duplication, disclosure, modification, and adaptation of the programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, shall be subject to license terms and license restrictions applicable to the programs.No other rights are granted to the U.S. Government.

このソフトウェアもしくはハードウェアは様々な情報管理アプリケーションでの一般的な使用のために開発されたものです。このソフトウェアもしくはハードウェアは、危険が伴うアプリケーション(人的傷害を発生させる可能性があるアプリケーションを含む)への用途を目的として開発されていません。このソフトウェアもしくはハードウェアを危険が伴うアプリケーションで使用する際、安全に使用するために、適切な安全装置、バックアップ、冗長性(redundancy)、その他の対策を講じることは使用者の責任となります。このソフトウェアもしくはハードウェアを危険が伴うアプリケーションで使用したことに起因して損害が発生しても、オラクル社およびその関連会社は一切の責任を負いかねます。

OracleおよびJavaはOracle Corporationおよびその関連企業の登録商標です。その他の名称は、それぞれの所有者の商標または登録商標です。

Intel、Intel Xeonは、Intel Corporationの商標または登録商標です。すべてのSPARCの商標はライセンスをもとに使用し、SPARC International, Inc.の商標または登録商標です。AMD、Opteron、AMDロゴ、AMD Opteronロゴは、Advanced Micro Devices, Inc.の商標または登録商標です。UNIXは、The Open Groupの登録商標です。

このソフトウェアまたはハードウェア、そしてドキュメントは、第三者のコンテンツ、製品、サービスへのアクセス、あるいはそれらに関する情報を提供することがあります。適用されるお客様とOracle Corporationとの間の契約に別段の定めがある場合を除いて、Oracle Corporationおよびその関連会社は、第三者のコンテンツ、製品、サービスに関して一切の責任を負わず、いかなる保証もいたしません。適用されるお客様とOracle Corporationとの間の契約に定めがある場合を除いて、Oracle Corporationおよびその関連会社は、第三者のコンテンツ、製品、サービスへのアクセスまたは使用によって損失、費用、あるいは損害が発生しても一切の責任を負いかねます。

目次

例一覧

図一覧

表一覧

タイトルおよび著作権情報

はじめに

- 対象読者

- ドキュメントのアクセシビリティについて

- 関連ドキュメント

- 場所が変更されたドキュメント

- 表記規則

バックアップおよびリカバリの新機能

- Oracle 11gリリース2の新しいバックアップおよびリカバリ機能

第I部 バックアップおよびリカバリの概要

1 バックアップおよびリカバリの概要

- バックアップおよびリカバリの目的

- データ保護

- メディア障害

- ユーザー・エラー

- アプリケーション・エラー

- データの保持

- データ送信

- Oracleのバックアップおよびリカバリのソリューション

- Oracle Flashbackテクノロジ

- 論理フラッシュバック機能

- フラッシュバック・データベース

- データ・リカバリ・アドバイザ

- バックアップおよびリカバリのドキュメント・ロードマップ

- Recovery Managerのドキュメント・ロードマップ

- ユーザー管理のバックアップおよびリカバリのドキュメント・ロードマップ

2 RMANの概要

- RMAN環境の概要

- RMANの起動およびデータベースへの接続

- RMANのデフォルト構成の表示

- データベースのバックアップ

- ARCHIVELOGモードでのデータベースのバックアップ

- NOARCHIVELOGモードでのデータベースのバックアップ

- 一般的なバックアップ・オプション

- 増分バックアップの作成

- 増分更新バックアップの作成

- データベース・ファイルおよびバックアップの検証

- RMAN操作のスクリプト化

- RMAN操作に関するレポート

- バックアップの表示

- データベース・ファイルおよびバックアップに関するレポート

- RMANバックアップの保持

- バックアップのクロスチェック

- 不要なバックアップの削除

- データ・リカバリ・アドバイザを使用した障害の診断および修復

- 障害の表示および修復オプションの決定

- 障害の修復

- フラッシュバック・データベースを使用したデータベースの巻戻し

- データベース・ファイルのリストアおよびリカバリ

- データベース・ファイルのリストアおよびリカバリの準備

- データベース全体のリカバリ

- 表領域のリカバリ

- 個々のデータ・ブロックのリカバリ

第II部 RMANとフラッシュバック・データベースの起動および構成

3 Recovery Managerのアーキテクチャ

- RMAN環境

- RMANコマンドライン・クライアント

- RMANチャネル

- チャネルおよびデバイス

- 自動チャネルおよび手動チャネル

- RMANリポジトリ

- メディア管理

- RMANとメディア・マネージャの相互作用

- Oracle Secure Backup

- Backup Solutions Program

- 高速リカバリ領域

- Data Guard環境でのRMAN

- Data Guard環境でのRMANの構成

- Data Guard環境でのRMANによるファイル管理

- Data Guard環境でのバックアップの互換性

- Data Guard環境でのバックアップの関連付け

- Data Guard環境でのバックアップのアクセシビリティについて

4 RMAN クライアントの起動および操作

- RMANの起動および終了

- RMAN出力の場所の指定

- RMANのグローバリゼーション・サポート環境変数の設定

- RMANコマンドの入力

- RMANプロンプトでのRMANコマンドの入力

- RMANでのコマンド・ファイルの使用

- RMANコマンド・ファイルへのコメントの入力

- コマンド・ファイルでの置換変数の使用

- RMAN構文の確認

- コマンドラインでのRMAN構文の確認

- コマンド・ファイル内のRMAN構文の確認

- RMANによるデータベース接続の確立

- RMANによるデータベース接続

- RMANによるデータベース接続の認証

- オペレーティング・システムのコマンドラインからのRMANによるデータベース接続の確立

- RMANプロンプトからのデータベース接続の確立

- RMANによる補助データベースへの接続

- コマンド・ファイル内でのRMANによるデータベース接続の確立

- RMANによる接続で発生した問題の診断

- ターゲット・データベースおよび補助データベースへの接続時に発生した問題の診断

- リカバリ・カタログへの接続時に発生した問題の診断

- RMANのパイプ・インタフェースの使用

- パイプを介した複数のRMANコマンドの連続実行の例

- パイプを介したRMANコマンドの単一ジョブでの実行の例

5 RMAN環境の構成

- RMANバックアップの環境の構成

- RMANの永続的な構成の表示およびクリア

- バックアップ用のデフォルト・デバイスの構成: ディスクまたはSBT

- バックアップ用のデフォルト・タイプの構成: バックアップ・セットまたはコピー

- チャネルの構成

- チャネルの構成

- ディスクのチャネルの構成

- ディスクおよびSBTデバイス用のパラレル・チャネルの構成

- 構成済チャネルの手動での変更

- 制御ファイルおよびサーバー・パラメータ・ファイルの自動バックアップの構成

- 制御ファイルの自動バックアップ書式の構成

- 構成済の制御ファイルの自動バックアップ書式の上書き

- メディア・マネージャにバックアップするためのRMANの構成

- RMANをメディア・マネージャとともに使用するための前提条件

- メディア管理ライブラリの場所の確認

- RMANのバックアップに対するメディア管理ソフトウェアの構成

- メディア・マネージャ・ライブラリが正常に統合されたかどうかのテスト

- メディア・マネージャでのALLOCATE CHANNELのテスト

- メディア・マネージャでのバックアップおよびリストア操作のテスト

- メディア・マネージャで使用するSBTチャネルの構成

- メディア・マネージャのバックアップ・ピース名

- 自動SBTチャネルの構成

- 高速リカバリ領域の構成

- 高速リカバリ領域の概要

- Oracle Managed Filesおよび自動ストレージ管理

- Oracleによる高速リカバリ領域でのディスク領域の管理方法

- 高速リカバリ領域の有効化

- 高速リカバリ領域のサイズを設定する場合の考慮事項

- 高速リカバリ領域の場所を設定する場合の考慮事項

- 高速リカバリ領域の場所および初期サイズの設定

- 高速リカバリ領域の無効化

- 制御ファイルおよびREDOログの場所の構成

- オンラインREDOログの場所の構成

- 制御ファイルの場所の構成

- アーカイブREDOログの場所の構成

- 高速リカバリ領域内でのRMANによるファイル作成の構成

- バックアップの保存方針の構成

- 冗長性に基づく保存方針の構成

- リカバリ期間に基づく保存方針の構成

- 保存方針の無効化

- バックアップの最適化およびCONFIGUREコマンド

- バックアップの最適化の概要

- SBTバックアップのバックアップの最適化への保存方針の影響

- リカバリ期間に基づく保存方針によるSBTバックアップのバックアップの最適化

- 冗長性に基づく保存方針によるSBTバックアップのバックアップの最適化

- バックアップの最適化の構成

- アーカイブREDOログの削除方針の構成

- アーカイブREDOログの削除方針

- アーカイブREDOログの削除方針が無効になっている場合

- アーカイブREDOログの削除方針が有効になっている場合

- アーカイブREDOログの削除方針の有効化

- Data Guard環境でのRMANの構成

6 RMAN環境の構成: 高度なトピック

- 高度なチャネル・オプションの構成

- チャネル制御オプション

- 固有のチャネル・パラメータの構成

- 固有のチャネルの構成の例

- CONFIGURE CHANNELとパラレル化設定の関係

- 高度なバックアップ・オプションの構成

- バックアップ・セットの最大サイズの構成

- バックアップ・ピースの最大サイズの構成

- バックアップの多重化の構成

- データベース全体のバックアップから除外する表領域の構成

- 圧縮オプションの構成

- 圧縮前のブロック処理

- Basic Compressionオプション

- Advanced Compressionオプション

- バックアップの暗号化の構成

- バックアップの暗号化

- RMANバックアップの暗号化モードの構成

- バックアップ暗号化アルゴリズムの構成

- 補助インスタンスのデータファイル名の構成

- スナップショット制御ファイルの場所の構成

- スナップショット制御ファイルの構成場所の表示

- スナップショット制御ファイルの場所の設定

- 共有サーバーで使用するためのRMANの構成

- 消失書込みの検出の有効化

7 フラッシュバック・データベースおよびリストア・ポイントの使用

- フラッシュバック・データベース、リストア・ポイントおよび保証付きリストア・ポイントについて

- フラッシュバック・データベース

- フラッシュバック・データベース・ウィンドウ

- フラッシュバック・データベースの制約

- 通常のリストア・ポイント

- 保証付きリストア・ポイント

- 保証付きリストア・ポイントとストレージ・スナップショットの比較

- フラッシュバック・データベースおよび保証付きリストア・ポイントのロギング

- 保証付きリストア・ポイントおよび高速リカバリ領域の領域使用状況

- フラッシュバック・ロギングが無効になっている状態での保証付きリストア・ポイントのロギング

- 保証付きリストア・ポイントが定義された状態でのフラッシュバック・データベースのロギング

- フラッシュバック・データベースおよび保証付きリストア・ポイントの前提条件

- 通常のリストア・ポイントと保証付きリストア・ポイントの使用

- 通常のリストア・ポイントと保証付きリストア・ポイントの作成

- リストア・ポイントの表示

- リストア・ポイントの削除

- データベースのフラッシュバックの使用

- フラッシュバック・データベースの有効化

- フラッシュバック・データベースのロギングの無効化

- 最適なフラッシュバック・データベースのパフォーマンスのための環境の構成

- フラッシュバック・データベースのパフォーマンスに対する影響の監視

- I/Oエラーが発生した場合のフラッシュバック・ライター(RVWR)の動作

第III部 データのバックアップおよびアーカイブ

8 RMANバックアップの概要

- RMANの一貫性バックアップおよび非一貫性バックアップ

- 一貫性バックアップ

- 非一貫性バックアップ

- オンライン・バックアップおよびバックアップ・モード

- バックアップ・セット

- バックアップ・セットおよびバックアップ・ピース

- バックアップ・セットのブロックの圧縮

- 未使用ブロックの圧縮

- NULLブロックの圧縮

- バックアップ・セットのバイナリ圧縮

- UNDOのバックアップ

- バックアップ・セットの暗号化

- バックアップ・ピースのファイル名

- バックアップ・ピースの数およびサイズ

- バックアップ・セットの数およびサイズ

- 多重バックアップ・セット

- プロキシ・コピー

- イメージ・コピー

- RMANで作成したイメージ・コピー

- ユーザー管理イメージ・コピー

- RMANを使用したバックアップの複数のコピー

- 多重バックアップ・セット

- バックアップのバックアップ

- バックアップ・セットのバックアップ

- イメージ・コピーのバックアップ

- 制御ファイルおよびサーバー・パラメータ・ファイルの自動バックアップ

- RMANが制御ファイルの自動バックアップを実行する場合

- RMANによる制御ファイルの自動バックアップの実行方法

- 増分バックアップ

- マルチレベル増分バックアップ

- 差分増分バックアップ

- 累積増分バックアップ

- ブロック・チェンジ・トラッキング

- 増分バックアップのアルゴリズム

- 増分バックアップを使用したリカバリ

- バックアップの保存方針

- リカバリ期間

- バックアップ冗長性

- 不要なバックアップのバッチ削除

- バックアップ保存方針および高速リカバリ領域の削除規則

9 データベースのバックアップ

- RMANバックアップの概要

- RMANバックアップの目的

- RMANバックアップの基本的な概念

- バックアップ出力オプションの指定

- RMANバックアップ用のデバイス・タイプの指定

- ディスクへのRMANバックアップ用のバックアップ・セットまたはバックアップ・コピーの指定

- RMANバックアップのフォーマットの指定

- ディスク・バックアップの複数のフォーマットの指定

- RMANバックアップのタグの指定

- バックアップ・タグ

- バックアップ・セットおよびイメージ・コピーのタグの指定

- 圧縮バックアップの作成

- RMANを使用したデータベース・ファイルのバックアップ

- RMANを使用したデータベース全体のバックアップ

- RMANを使用した表領域およびデータファイルのバックアップ

- RMANを使用した制御ファイルのバックアップ

- 制御ファイルの手動バックアップの作成

- RMANを使用したサーバー・パラメータ・ファイルのバックアップ

- NOARCHIVELOGモードでのデータベースのバックアップ

- RMANを使用したアーカイブREDOログのバックアップ

- アーカイブREDOログのバックアップ

- アーカイブREDOログ・フェイルオーバー

- オンラインREDOログ・スイッチ

- アーカイブREDOログ・ファイルのバックアップ

- バックアップが必要なアーカイブREDOログのみのバックアップ

- バックアップ後のアーカイブREDOログの削除

- 増分バックアップの作成および更新

- 増分バックアップの目的

- 増分バックアップ計画の設計

- 増分バックアップの作成

- VSSスナップショットの増分バックアップの作成

- 増分更新バックアップ

- 増分更新バックアップ: 基本例

- 増分更新バックアップ: 高度な例

- ブロック・チェンジ・トラッキングを使用した、増分バックアップのパフォーマンスの向上

- ブロック・チェンジ・トラッキング

- ブロック・チェンジ・トラッキングの有効化および無効化

- ブロック・チェンジ・トラッキングの無効化

- チェンジ・トラッキングが有効かどうかの確認

- ブロック・チェンジ・トラッキング・ファイルの場所の変更

- 長期格納用のデータベース・バックアップの作成

- アーカイブ・バックアップの目的

- アーカイブ・バックアップの基本的な概念

- 長期格納用のアーカイブ・バックアップの作成

- アーカイブ・バックアップの作成

- 一時的なアーカイブ・バックアップの作成

- RMANバックアップのバックアップ

- バックアップのバックアップ

- バックアップ・セットの複数のコピー

- バックアップをバックアップする場合のバックアップの保存方針の影響

- RMANを使用したバックアップ・セットのバックアップ

- RMANを使用したイメージ・コピーのバックアップ

10 データベースのバックアップ: 高度なトピック

- RMANバックアップ・セットのサイズの制限

- バックアップ・セットのサイズ

- BACKUP ... MAXSETSIZEを使用したバックアップ・セットのサイズの制限

- セクションへの大規模なデータファイルのバックアップの分割

- バックアップの最適化を使用したファイルのスキップ

- 1つのテープへの毎日のアーカイブ・ログ・バックアップの最適化の例

- 複数のメディア・ファミリへの毎日のアーカイブ・ログ・バックアップの最適化の例

- アーカイブ・ログの週ごとのセカンダリ・バックアップの作成の例

- オフライン・ファイル、読取り専用ファイルおよびアクセスできないファイルのスキップ

- バックアップ・セットの多重化

- CONFIGURE BACKUP COPIESを使用したバックアップ・セットの多重化

- BACKUP ... COPIESを使用したバックアップ・セットの多重化

- RMANを使用したミラーの分割によるバックアップの実行

- RMANバックアップの暗号化

- RMANバックアップの暗号化設定

- 透過モード暗号化バックアップの作成

- パスワード・モード暗号化バックアップの作成

- デュアル・モード暗号化バックアップの作成

- RMANバックアップの再開

- 再開可能バックアップ

- 部分的に完了したバックアップの再開

- バックアップ期間の管理

- バックアップ期間

- バックアップ期間の指定

- バックアップ期間での部分バックアップの許可

- バックアップの負荷および時間の最小化

第IV部 RMANのバックアップの管理

11 RMAN操作に関するレポート

- RMANレポートの概要

- RMANレポートの目的

- RMANレポートの基本的な概念

- Data Guard環境でのレポート

- バックアップおよびリカバリ関連オブジェクトの表示

- LISTコマンド

- すべてのバックアップおよびコピーの表示

- 選択したバックアップおよびコピーの表示

- データベース・インカネーションの表示

- バックアップおよびデータベース・スキーマに関するレポート

- RMANバックアップに関するレポート

- 保存方針に基づくバックアップが必要なファイルに関するレポート

- 様々な保存方針でのRMANのREPORT NEED BACKUPの使用

- 表領域およびデータファイルでのRMANのREPORT NEED BACKUPの使用

- テープまたはディスク上のバックアップのみでのREPORT NEED BACKUPの使用

- リカバリ不能な操作によって影響を受けるデータファイルに関するレポート

- 不要なバックアップに関するレポート

- データベース・スキーマに関するレポート

- V$ビューを使用したバックアップ・メタデータの問合せ

- 過去および現行のRMANジョブの詳細の問合せ

- バックアップ・ピースの暗号化ステータスの確認

- リカバリ・カタログ・ビューの問合せ

- リカバリ・カタログ・ビュー

- 登録されているデータベースの一意の識別子

- Data Guard環境の一意の識別子

- カタログ・ビューへのターゲットDB_KEY値またはDBID値の問合せ

- RC_BACKUP_FILESの問合せ

12 RMANバックアップおよびリポジトリ・レコードのメンテナンス

- RMANバックアップおよびリポジトリのメンテナンスの概要

- バックアップおよびリポジトリのメンテナンスの目的

- バックアップおよびリポジトリのメンテナンスの基本的な概念

- メンテナンス・コマンドおよびRMANリポジトリ・メタデータ

- Data Guard環境でのメンテナンス・コマンド

- 制御ファイルのリポジトリのメンテナンス

- 制御ファイル・レコード

- 高速リカバリ領域および制御ファイル・レコード

- 制御ファイル・レコードの消失の防止

- 制御ファイルの保護

- 高速リカバリ領域のメンテナンス

- 高速リカバリ領域の規則の削除

- 高速リカバリ領域の領域使用状況の監視

- 高速リカバリ領域でのフラッシュバック・ログの領域の管理

- 高速リカバリ領域が一杯になった場合の対応

- 新しい場所への高速リカバリ領域の変更

- 高速リカバリ領域の無効化

- ファイル作成時のインスタンスのクラッシュへの対応

- RMANリポジトリの更新

- RMANリポジトリのクロスチェック

- RMANのクロスチェック

- すべてのバックアップおよびコピーのクロスチェック

- 特定のバックアップ・セットおよびコピーのクロスチェック

- バックアップおよびコピーのリポジトリ・ステータスの変更

- AVAILABLEまたはUNAVAILABLEへのバックアップのステータスの更新

- アーカイブ・バックアップのステータスの変更

- RMANリポジトリへのバックアップ・レコードの追加

- カタログ操作

- カタログへのユーザー管理データファイルのコピーの追加

- カタログへのバックアップ・ピースの追加

- カタログへのディスクの場所内のすべてのファイルの追加

- RMANリポジトリからのレコードの削除

- カタログからの削除操作

- オペレーティング・システム・ユーティリティを使用して削除したファイルのレコードの削除

- RMANバックアップおよびアーカイブREDOログの削除

- RMANの削除の概要

- RMANの削除コマンド

- アーカイブREDOログの削除

- すべてのバックアップおよびコピーの削除

- 指定したバックアップおよびコピーの削除

- BACKUP ... DELETEを使用した指定ファイルの削除

- 期限切れのRMANバックアップおよびコピーの削除

- 保存方針に基づく不要なRMANバックアップの削除

- KEEP UNTIL TIMEに指定した期限が切れた場合のDELETE OBSOLETEの動作

- データベースの削除

13 リカバリ・カタログの管理

- リカバリ・カタログの概要

- リカバリ・カタログの目的

- リカバリ・カタログの基本的な概念

- データベースの登録

- ベース・リカバリ・カタログでのメタデータの集中化

- リカバリ・カタログの再同期化

- ストアド・スクリプト

- Data Guard環境でのリカバリ・カタログ

- リカバリ・カタログの管理の基本手順

- リカバリ・カタログの作成

- リカバリ・カタログ・データベースの構成

- リカバリ・カタログ・スキーマのサイズの計画

- リカバリ・カタログ・データベースのディスク領域の割当て

- リカバリ・カタログのスキーマ所有者の作成

- CREATE CATALOGコマンドの実行

- リカバリ・カタログへのデータベースの登録

- リカバリ・カタログへのデータベースの登録

- スタンバイ・データベースの登録

- REGISTER DATABASEコマンドを使用したデータベースの登録

- リカバリ・カタログへのバックアップの追加

- 仮想プライベート・カタログの作成および管理

- 仮想プライベート・カタログ

- 仮想プライベート・カタログ所有者の作成および権限の付与

- 仮想プライベート・カタログの作成

- 仮想プライベート・カタログ所有者からの権限の取消し

- 仮想プライベート・カタログの削除

- リカバリ・カタログの保護

- リカバリ・カタログのバックアップ

- リカバリ・カタログの頻繁なバックアップ

- 適切な物理バックアップ方法の選択

- ターゲット・データベースからのリカバリ・カタログの分離

- 論理バックアップ用のリカバリ・カタログ・データのエクスポート

- リカバリ・カタログのリカバリ

- ストアド・スクリプトの管理

- ストアド・スクリプト

- ストアド・スクリプトの作成

- ストアド・スクリプトの置換え

- ストアド・スクリプトの実行

- 動的ストアド・スクリプトの作成および実行

- ストアド・スクリプトの出力

- ストアド・スクリプト名の表示

- ストアド・スクリプトの削除

- RMANの起動時のストアド・スクリプトの実行

- リカバリ・カタログのメンテナンス

- リカバリ・カタログのメンテナンス

- リカバリ・カタログの再同期化

- リカバリ・カタログの再同期化

- リカバリ・カタログを再同期化するタイミングの決定

- リカバリ・カタログの手動での再同期化

- DB_UNIQUE_NAMEを変更した後のリカバリ・カタログの更新

- リカバリ・カタログからのターゲット・データベースの登録の解除

- Data Guard環境外のターゲット・データベースの登録の解除

- スタンバイ・データベースの登録の解除

- リカバリ・カタログのデータベース・インカネーションの再設定

- リカバリ・カタログのアップグレード

- リカバリ・カタログのアップグレード

- リカバリ・カタログのスキーマ・バージョンの確認

- UPGRADE CATALOGコマンドの使用

- リカバリ・カタログのインポートおよび移動

- リカバリ・カタログのインポート

- リカバリ・カタログのインポートの前提条件

- リカバリ・カタログのインポート

- リカバリ・カタログの移動

- リカバリ・カタログの削除

第V部 障害の診断および対応

14 RMANのデータ修復の概要

- RMANのデータ修復の概要

- データ修復が必要な問題

- ユーザー・エラー

- アプリケーション・エラー

- メディア障害

- RMANのデータ修復方法

- RMANのリストア操作

- バックアップの選択

- リストア・フェイルオーバー

- RMANのリストア操作およびASMの概要

- リストアの最適化

- RMANのメディア・リカバリ

- 増分バックアップおよびアーカイブREDOログの選択

- データベース・インカネーション

- OPEN RESETLOGS操作

- データベース・インカネーション間の関係

- 孤立したバックアップ

15 データ・リカバリ・アドバイザを使用した障害の診断および修復

- データ・リカバリ・アドバイザの概要

- データ・リカバリ・アドバイザの目的

- データ・リカバリ・アドバイザの基本的な概念

- データ・リカバリ・アドバイザのユーザー・インタフェース

- データ整合性チェック

- 障害

- 手動処理および自動修復オプション

- サポートされているデータベースの構成

- 障害の診断および修復の基本手順

- 障害の表示

- すべての障害の表示

- 障害のサブセットの表示

- データベースの検証によるブロック破損の確認

- 修復オプションの決定

- すべての障害に対する修復オプションの決定

- 障害のサブセットに対する修復オプションの決定

- 障害の修復

- 障害の修復の概要

- 障害の修復

- 障害のステータスおよび優先順位の変更

16 データベース・ファイルおよびバックアップの検証

- RMANの検証の概要

- RMANの検証の目的

- RMANの検証の基本的な概念

- チェックサムおよび破損ブロック

- 物理および論理ブロック破損

- RMANバックアップの破損ブロックの制限

- ブロック破損の検出

- VALIDATEコマンドによるブロック破損の確認

- BACKUP VALIDATEを使用したデータベース・ファイルの検証

- リストアする前のバックアップの検証

17 データベースの完全リカバリの実行

- データベースの完全リカバリの概要

- データベースの完全リカバリの目的

- この章の概要

- データベースの完全リカバリの準備

- リストアまたはリカバリするデータファイルの識別

- 消失した制御ファイルの識別

- メディア・リカバリが必要なデータファイルの識別

- データベースのDBIDの確認

- リストア操作で使用されるバックアップのプレビュー

- オフサイト・バックアップのリコール

- リストアする前のバックアップの検証

- リカバリに必要なアーカイブREDOログのリストア

- 新しい場所へのアーカイブREDOログのリストア

- 複数の場所へのアーカイブREDOログのリストア

- データベースの完全リカバリの実行

- データベースの完全リカバリ

- デフォルト以外の場所へのデータファイルのリストア

- バックアップの復号化

- データベース全体の完全リカバリの実行

- 表領域の完全リカバリの実行

- コピーへの切替え後の完全リカバリの実行

- データファイルのコピーへの切替え

- データベースのコピーへの切替え

18 フラッシュバックおよびデータベースのPoint-in-Timeリカバリの実行

- Oracleフラッシュバック技術およびデータベースのPoint-in-Timeリカバリの概要

- フラッシュバックおよびデータベースのPoint-in-Timeリカバリの目的

- Point-in-Timeリカバリおよびフラッシュバック機能の基本的な概念

- データベースのPoint-in-Timeリカバリの基本的な概念

- フラッシュバック技術の基本的な概念

- フラッシュバック表を使用した表の巻戻し

- フラッシュバック表の前提条件

- フラッシュバック表操作の実行

- フラッシュバック表中のトリガーの有効状態の保持

- フラッシュバック・ドロップを使用したDROP TABLE操作の巻戻し

- フラッシュバック・ドロップ

- フラッシュバック・ドロップの前提条件

- フラッシュバック・ドロップ操作の実行

- 元の名前が同じオブジェクトが複数存在する場合のオブジェクトの取出し

- フラッシュバック・データベースを使用したデータベースの巻戻し

- フラッシュバック・データベースの前提条件

- フラッシュバック・データベース操作の実行

- フラッシュバック・データベースの監視

- データベースのPoint-in-Timeリカバリの実行

- データベースのPoint-in-Timeリカバリの前提条件

- データベースのPoint-in-Timeリカバリの実行

- フラッシュバックおよびデータベースのPoint-in-Timeリカバリの例

- フラッシュバック・データベースを使用したOPEN RESETLOGS操作の巻戻し

- フラッシュバック・データベースを使用したスタンバイ・データベースでのOPEN RESETLOGSの取消し

- 取り消されたインカネーション・ブランチ内のSCNへのデータベースの巻戻し

- 祖先インカネーションへのデータベースのリカバリ

19 ブロック・メディア・リカバリの実行

- ブロック・メディア・リカバリの概要

- ブロック・メディア・リカバリの目的

- ブロック・メディア・リカバリの基本的な概念

- 破損ブロックの識別

- ブロック・リカバリ時に欠落しているREDO

- ブロック・メディア・リカバリの前提条件

- 個々のブロックのリカバリ

- V$DATABASE_BLOCK_CORRUPTION内のすべてのブロックのリカバリ

20 RMANのリカバリの実行: 高度な例

- 増分バックアップを使用したNOARCHIVELOGモードのデータベースのリカバリ

- サーバー・パラメータ・ファイルのリストア

- 制御ファイルの自動バックアップからのサーバー・パラメータ・ファイルのリストア

- RMANを使用した初期化パラメータ・ファイルの作成

- バックアップ制御ファイルを使用したリカバリの実行

- バックアップ制御ファイルを使用したリカバリの実行

- 制御ファイルの場所

- リカバリ・カタログを使用したリカバリおよび使用しないリカバリ

- 高速リカバリ領域を使用している場合のリカバリ

- バックアップ制御ファイルを使用してリカバリ・カタログを使用しないリカバリの実行

- 障害リカバリの実行

- 障害リカバリの前提条件

- 障害発生後のデータベースのリカバリ

- 新しいホストへのデータベースのリストア

- 新しいホストへのデータベースのリストアの準備

- 新しいホストへのディスク・バックアップのリストア

- 新しいホストへのデータベースのリストアのテスト

21 RMANの表領域のPoint-in-Timeリカバリ(TSPITR)の実行

- RMANのTSPITRの概要

- RMANのTSPITRの目的

- RMANのTSPITRの基本的な概念

- 共通の用語

- RMANのTSPITRのモード

- RMAN管理の補助インスタンスを使用したRMANのTSPITRの仕組み

- TSPITRの制限、特殊事例および制約

- TSPITRの制約

- リカバリ・カタログを使用しない場合の特別な考慮事項

- TSPITRの計画および準備

- 手順1: TSPITRでの正しい目標時点の選択

- 手順2: リカバリ・セットの決定

- プライマリ・データベースの依存性の確認および解決

- 手順3: TSPITRの実行後に消失するオブジェクトの確認および保存

- 完全に自動化されたRMANのTSPITRの実行

- RMAN管理の補助インスタンスを使用したRMANのTSPITRに対するデフォルトの変更

- SET NEWNAMEを使用したTSPITRのリカバリ・セットのデータファイル名の変更

- TSPITRの補助セットのデータファイル名の指定

- TSPITRのOMF補助セット・ファイルの名前変更時の考慮事項

- SET NEWNAMEを使用した補助セットのデータファイル名の指定

- DB_FILE_NAME_CONVERTを使用した補助セットのデータファイル名の指定

- イメージ・コピーを使用したRMANのTSPITRの高速化

- リカバリ・セットのイメージ・コピーでのSET NEWNAMEの使用

- 補助セットのイメージ・コピーでのSET NEWNAMEおよびCONFIGURE AUXNAMEの使用

- CONFIGURE AUXNAMEおよびイメージ・コピーを使用したTSPITRの実行の例

- TSPITRにおける自動補助インスタンスの初期化パラメータのカスタマイズ

- TSPITRにおける補助インスタンスの制御ファイルの格納場所の指定

- TSPITRにおける補助インスタンスのアーカイブ・ログの指定

- TSPITRにおける補助インスタンスのオンライン・ログの格納場所の指定

- 独自の補助インスタンスを使用したRMANのTSPITRの実行

- RMANのTSPITRに使用する独自の補助インスタンスの準備

- 手順1: 補助インスタンス用のOracleパスワード・ファイルの作成

- 手順2: 補助インスタンス用の初期化パラメータ・ファイルの作成

- 手順3: Oracle Netから補助インスタンスへの接続性の確認

- 独自の補助インスタンスを使用したTSPITRに使用するRMANコマンドの準備

- 独自の補助インスタンスを使用したTSPITRに使用するチャネルの計画

- 独自の補助インスタンスのデータファイル名の計画: SET NEWNAME

- 独自の補助インスタンスを使用したTSPITRの実行

- 手順1: NOMOUNTモードでの補助インスタンスの起動

- 手順2: ターゲット・インスタンスおよび補助インスタンスへのRMANクライアントの接続

- 手順3: RECOVER TABLESPACEコマンドの実行

- 独自の補助インスタンスを使用したTSPITRの実行例

- RMANのTSPITRのトラブルシューティング

- ファイル名の競合のトラブルシューティング

- UNDOセグメントを含む表領域の識別のトラブルシューティング

- TSPITRの失敗後の手動による補助インスタンスの再起動のトラブルシューティング

第VI部 チューニングおよびトラブルシューティング

22 RMANのパフォーマンスのチューニング

- RMANのパフォーマンスのチューニングの目的

- RMANのパフォーマンスのチューニングの基本的な概念

- 読取りフェーズ

- 入力ディスク・バッファの割当て

- 同期ディスクI/Oと非同期ディスクI/O

- ディスクI/Oスレーブ

- チャネルのRATEパラメータ

- コピー・フェーズ

- システム・バックアップ・テープ(SBT)への書込みフェーズ

- SBTへの書込みフェーズにおけるRMANの構成要素

- SBTへの書込みフェーズにおけるメディア・マネージャの構成要素

- ディスクへの書込みフェーズ

- RMANのパフォーマンスの問題を診断するためのV$ビューの使用方法

- V$SESSION_LONGOPSによるRMANジョブの進捗状況の監視

- V$BACKUP_SYNC_IOおよびV$BACKUP_ASYNC_IOによるボトルネックの特定

- 同期I/Oのボトルネックの特定

- 非同期I/Oのボトルネックの特定

- RMANのバックアップのパフォーマンスのチューニング

- 手順1: チャネル設定からのRATEパラメータの削除

- 手順2: 同期ディスクI/Oを使用する場合のDBWR_IO_SLAVESの設定

- 手順3: 共有メモリーの割当てに失敗する場合のLARGE_POOL_SIZEの設定

- 手順4: 読取り、書込みおよびコピーのフェーズのチューニング

- バックアップの検証を使用した読取りと書込みのボトルネックの識別

- 読取りフェーズのチューニング

- コピーおよび書込みのフェーズのチューニング

23 RMAN操作のトラブルシューティング

- RMANのメッセージ出力の解釈

- メッセージ出力タイプの識別

- RMANのエラー・メッセージ・スタックの識別

- エラー・コードの識別

- RMANのエラー・メッセージ番号

- ORA-19511: メディア・マネージャ・エラー

- RMANエラー・スタックの解釈

- RMANエラーの解釈の例

- サーバー・エラーの解釈の例

- SBT 2.0のメディア管理エラーの解釈の例

- SBT 1.1のメディア管理エラーの解釈の例

- RMANのリターン・コードの識別

- RMANのトラブルシューティングでのV$ビューの使用

- RMANとメディア・マネージャの相互作用の監視

- サーバー・セッションとRMANチャネルの関連付け

- アクティブなRMANセッションが1つの場合のサーバー・セッションとチャネルの一致

- RMANセッションが複数の場合のサーバー・セッションとチャネルの一致

- Media Management APIのテスト

- sbttestユーティリティの入手

- sbttestユーティリティのオンライン・ドキュメントの取得

- sbttestユーティリティの使用

- RMANコマンドの終了

- ALTER SYSTEM KILL SESSIONによるセッションの終了

- オペレーティング・システム・レベルでのセッションの終了

- メディア・マネージャで応答しなくなったRMANセッションの終了

- RMANセッションの構成要素

- ジョブの一時停止中のプロセス動作

- RMANセッションの終了の基本手順

第VII部 RMANを使用したデータの送信

24 データベースの複製

- RMANデータベースの複製の概要

- データベースの複製の目的

- データベースの複製の基本的な概念

- データベースの複製方法

- 複製データベースの内容

- RMANによるデータベースの複製方法

- データベースの複製の基本手順

- データベースの複製の準備

- 手順1: 複製方法の選択

- 手順2: 複製ファイルの名前の指定方法の選択

- 手順3: 複製インスタンスからバックアップへのアクセス可能化

- 補助インスタンスからSBTバックアップへのアクセス可能化

- 補助インスタンスからディスク・バックアップへのアクセス可能化

- 手順4: データベースへのリモート・アクセスの準備

- 必要な場合の接続の確立

- 補助インスタンス用のパスワード・ファイルの作成

- 手順5: 初期化パラメータ・ファイルの作成と補助インスタンスの起動

- ソース・データベースの適切な設定

- RMANの起動およびデータベースへの接続

- 複製で使用するためのRMANチャネルの構成

- アクティブなデータベースの複製のためのチャネル構成

- バックアップベースの複製のためのチャネル構成

- データベースの複製

- ターゲット接続を行わないバックアップベースの複製の例

- ターゲット接続を行うバックアップベースの複製の例

- ターゲット接続およびリカバリ・カタログ接続を行わないバックアップベースの複製の例

- 失敗後のDUPLICATEの再実行

25 データベースの複製: 高度なトピック

- 複製データベース・ファイルの代替名の指定

- 複製データベース・ファイルの非OMFまたは非ASM代替名の指定

- SET NEWNAMEを使用したファイル・システム・データファイルおよび一時ファイルの名前の指定

- CONFIGURE AUXNAMEを使用したファイル・システム・データファイルおよびOMF/ASMターゲット・データファイルの名前の指定

- 複製データベース・ファイルに対するOMFまたはASM代替名の指定

- OMF初期化パラメータの設定および制限事項

- ASMの初期化パラメータの設定

- SET NEWNAMEを使用したOMFまたはASMファイルの作成

- DB_FILE_NAME_CONVERTを使用した非OMFまたはASMデータファイルの名前の生成

- LOG_FILE_NAME_CONVERTを使用した非OMFまたはASMログ・ファイルの名前の生成

- 共有ディスクを使用しないディスク・バックアップのアクセス可能化

- サーバー・パラメータ・ファイルが存在しない場合のデータベースの複製

- サーバー・パラメータ・ファイルが存在しない場合の補助インスタンスの起動

- ソース・データベース表領域のサブセットの複製

- 指定した表領域の除外

- 指定した表領域の追加

26 トランスポータブル表領域セットの作成

- トランスポータブル表領域セットの作成の概要

- トランスポータブル表領域セットの作成の目的

- トランスポータブル表領域セットの基本的な概念

- トランスポータブル表領域セットの作成の基本手順

- 補助インスタンスの初期化パラメータのカスタマイズ

- 補助インスタンスの初期化パラメータの設定

- 補助インスタンスのパラメータ・ファイルの場所の設定

- トランスポータブル表領域セットの作成

- トランスポータブル表領域セットの作成のトラブルシューティング

- トランスポータブル表領域セットの使用例

- 指定した時点またはSCNでのトランスポータブル表領域セットの作成

- データ・ポンプ・ファイルの場所の指定

- 補助ファイルの場所の指定

- 補助データファイルに対するSET NEWNAMEの使用

- 補助データファイルに対するCONFIGURE AUXNAMEの使用

- AUXILIARY DESTINATIONを使用した補助ファイルの場所の指定

- 初期化パラメータを使用した補助ファイル名の指定

27 プラットフォーム間でのデータ転送

- クロス・プラットフォーム・データ・トランスポートの概要

- クロス・プラットフォーム・データ・トランスポートの目的

- クロス・プラットフォーム・データ転送の基本的な概念

- 表領域およびデータファイルの変換

- データベースの変換

- ソース・ホストでのクロス・プラットフォーム表領域変換の実行

- 転送先ホストでのクロス・プラットフォーム・データファイル変換の実行

- 転送先ホストでのクロス・プラットフォーム・データファイル変換

- CONVERT DATAFILEを使用したデータファイル形式の変換

- クロス・プラットフォーム・データベース変換の前のデータベースの確認

- データベースをトランスポートする場合のソース・ホストでのデータファイルの変換

- データベースをトランスポートする場合の宛先ホストでのデータファイルの変換

- ソース・ホストでのデータファイル初期変換手順の実行

- 転送先ホストでのデータファイルの変換

第VIII部 ユーザー管理のバックアップおよびリカバリの実行

28 ユーザー管理データベース・バックアップの作成

- V$ビューの問合せによるバックアップ情報の取得

- バックアップ前のデータベース・ファイルの表示

- オンライン表領域バックアップのデータファイルのステータスの確認

- データベース全体のユーザー管理バックアップの作成

- 表領域およびデータファイルのユーザー管理バックアップの作成

- オフラインの表領域およびデータファイルのユーザー管理バックアップの作成

- オンラインの表領域およびデータファイルのユーザー管理バックアップの作成

- オンラインの読取り/書込み表領域のユーザー管理バックアップの作成

- オンラインの読取り/書込み表領域の複数のユーザー管理バックアップの作成

- インスタンス障害またはSHUTDOWN ABORT後のバックアップの終了

- 読取り専用表領域のユーザー管理バックアップの作成

- 制御ファイルのユーザー管理バックアップの作成

- 制御ファイルのバイナリ・ファイルへのバックアップ

- 制御ファイルのトレース・ファイルへのバックアップ

- アーカイブREDOログのユーザー管理バックアップの作成

- SUSPENDモードでのユーザー管理バックアップの作成

- 一時停止/再開機能

- 一時停止中のデータベースのバックアップの作成

- RAWデバイスへのユーザー管理バックアップの作成

- LinuxおよびUNIXでのRAWデバイスへのバックアップ

- LinuxおよびUNIXでのddユーティリティを使用したバックアップの例

- WindowsでのRAWデバイスへのバックアップ

- OCOPYを使用したバックアップの例

- OCOPYの-bおよび-rオプションの指定の例

- Volume Shadow Copy Service(VSS)を使用したバックアップの作成

- ユーザー管理データファイル・バックアップの検証

- データファイル・バックアップのリストアのテスト

- DBVERIFYユーティリティの実行

29 ユーザー管理のデータベースのフラッシュバックおよびリカバリの実行

- SQL*Plusでのデータベースのフラッシュバックの実行

- ユーザー管理のメディア・リカバリの概要

- ユーザー管理のリストアおよびリカバリ

- RECOVERコマンドを使用した自動リカバリ

- SET AUTORECOVERYを使用した自動リカバリ

- RECOVERコマンドのAUTOMATICオプションを使用した自動リカバリ

- アーカイブ・ログがデフォルトの場所にある場合のリカバリ

- アーカイブ・ログがデフォルト以外の場所にある場合のリカバリ

- アーカイブ・ログの場所の再設定

- アーカイブ・ログの場所の変更

- リカバリの取消し

- パラレル・メディア・リカバリ

- データベースの完全リカバリの実行

- クローズしているデータベースのリカバリの実行

- オープンしているデータベースのリカバリの実行

- データベースの不完全リカバリの実行

- 取消しベースの不完全リカバリの実行

- 時間ベースまたは変更ベースの不完全リカバリの実行

- NOARCHIVELOGモードでのデータベースのリカバリ

- メディア・リカバリのトラブルシューティング

- ユーザー管理のメディア・リカバリの問題

- メディア・リカバリの問題の調査: フェーズ1

- ブロックを破損させない修正の試行: フェーズ2

- リカバリでブロックの破損とマークできるようにするかどうかの決定: フェーズ3

- リカバリでのブロックの破損の許可: フェーズ4

- 試行リカバリの実行

- 試行リカバリの仕組み

- RECOVER ... TEST文の実行

30 ユーザー管理のリカバリの実行: 高度な例

- 現行の制御ファイルのサブセットが消失した場合の対応

- 多重制御ファイルのデフォルトの場所へのコピー

- 多重制御ファイルのデフォルト以外の場所へのコピー

- 現行の制御ファイルがすべて消失した場合のリカバリ

- デフォルトの場所でのバックアップ制御ファイルを使用したリカバリ

- デフォルト以外の場所でのバックアップ制御ファイルを使用したリカバリ

- バックアップ制御ファイルを使用したデータファイルの追加を伴うリカバリ

- バックアップ制御ファイルを使用した読取り専用表領域のリカバリ

- 制御ファイルの再作成

- 作成された制御ファイルを使用したRESETLOGSを伴うリカバリ

- 再作成された制御ファイルを使用した読取り専用ファイルのリカバリ

- バックアップが利用できない場合のデータファイルの再作成

- NOLOGGING表および索引のリカバリ

- トランスポータブル表領域のリカバリ

- オンラインREDOログ・ファイルが消失した後のリカバリ

- 多重オンラインREDOログ・グループの一部のメンバーが消失した後のリカバリ

- オンラインREDOログ・グループのすべてのメンバーが消失した後のリカバリ

- 非アクティブのオンラインREDOログ・グループの消失

- アクティブなオンラインREDOログ・グループの消失

- 複数のREDOログ・グループの消失

- フラッシュバック機能を使用しない、削除された表のリカバリ

- SQL*Plusでのデータベースの削除

用語集

索引

例一覧

- 2-1 LIST FAILUREおよびADVISE FAILURE

- 2-2 REPAIR FAILURE

- 4-1 無効な構文が含まれているコマンド・ファイルの構文の確認

- 4-2 システム・プロンプトからのターゲット・データベースへの接続

- 4-3 システム・プロンプトからのターゲット・データベースへの接続

- 4-4 システム・プロンプトからのターゲット・データベースおよびカタログ・データベースへの接続

- 4-5 RMANプロンプトからのターゲットおよび補助データベースへの接続

- 5-1 SHOW ALLコマンド

- 5-2 デフォルト以外のバックアップ場所の構成

- 5-3 ASMディスクの場所の構成

- 5-4 SBTデバイスのパラレル化の構成

- 5-5 SBTデバイスのバックアップ・タイプの構成

- 5-6 Oracle Secure BackupのPARMS設定

- 5-7 テープへのサーバー・パラメータ・ファイルのバックアップ

- 5-8 テープからのサーバー・パラメータ・ファイルのリストア

- 6-1 テープ・デバイスのチャネルのパラレル化の構成

- 6-2 バックアップのBasic Compressionの構成

- 8-1 DB_FILE_NAME_CONVERTを使用したファイル名の指定

- 8-2 テープへのバックアップ・セットのバックアップ

- 8-3 領域割当ての管理

- 9-1 デバイス・タイプDISKの指定

- 9-2 イメージ・コピーの作成

- 9-3 バックアップ・セットの作成

- 9-4 バックアップ・セットへのタグの適用

- 9-5 イメージ・コピーへのタグの適用

- 9-6 出力コピーへのタグの割当て

- 9-7 圧縮バックアップの作成

- 9-8 NOARCHIVELOGモードでのデータベースのバックアップ

- 9-9 基本的な増分更新スクリプト

- 9-10 高度な増分更新スクリプト

- 9-11 一時的なアーカイブ・バックアップの作成

- 10-1 バックアップの最適化の構成

- 10-2 複数のメディア・ファミリへのアーカイブREDOログのバックアップ

- 10-3 RMANバックアップ時のファイルのスキップ

- 10-4 BACKUP DURATIONでのMINIMIZE TIMEの使用

- 10-5 BACKUP DURATIONでのMINIMIZE LOADの使用

- 12-1 高速リカバリ領域の領域消費量

- 15-1 修復スクリプトのサンプル

- 17-1 BACKUP VALIDATE DATABASE

- 17-2 RESTORE ... PREVIEWの出力

- 18-1 同じ名前の複数オブジェクトの削除

- 18-2 削除された表の名前の変更

- 18-3 フラッシュバック・データベースの進捗状況の追跡(リストア・フェーズ)

- 20-1 制御ファイルの自動バックアップからのサーバー・パラメータ・ファイルのリストア

- 20-2 DBIDの設定および自動バックアップからの制御ファイルのリストア

- 20-3 新しいホストへのデータベースのリストア

- 21-1 表領域のサブセットに対するDBMS_TTS.TRANSPORT_SET_CHECKの問合せ

- 21-2 TS_PITR_OBJECTS_TO_BE_DROPPEDの問合せ

- 21-3 SCNおよびTS_PITR_OBJECTS_TO_BE_DROPPEDの使用

- 21-4 2つの表領域に対するTSPITRの実行

- 21-5 リカバリ・セットのファイル名の変更

- 21-6 ASMファイルのリダイレクト

- 21-7 TSPITRでの補助セットのOracle Managed Files(OMF)の名前の変更

- 21-8 SET NEWNAMEの使用

- 23-1 RMAN構文エラー

- 24-1 同じディレクトリ構造を持つホストへの複製(アクティブ)

- 24-2 過去の特定の時点までのデータベースの複製(バックアップベース)

- 24-3 バックアップベースの複製におけるアーカイブ・バックアップの使用

- 24-4 過去の特定の時点までのデータベースの複製(バックアップベース)

- 24-5 ターゲット接続およびリカバリ・カタログ接続を行わない場合のデータベースの複製(バックアップベース)

- 24-6 過去の特定の時点までのデータベースの複製(バックアップベース)

- 25-1 SET NEWNAME FOR DATAFILEを使用した複製

- 25-2 SET NEWNAME FOR DATAFILEおよびSET NEWNAME FOR TABLESPACEを使用した複製

- 25-3 SET NEWNAME FOR DATABASEを使用した複製

- 25-4 ファイル・システムからASMへの複製(アクティブ)

- 25-5 ASMからASMへの複製(アクティブ)

- 25-6 SET NEWNAME FOR DATAFILEおよびSET NEWNAME FOR TABLESPACEを使用した複製

- 25-7 SET NEWNAMEを使用したASMディスク・グループでのファイルの作成

- 25-8 補助インスタンス用のサンプル初期化パラメータ・ファイル

- 25-9 読取り専用表領域の除外

- 25-10 指定した表領域の除外

- 25-11 指定した表領域の追加

- 25-12 指定した表領域の追加

- 26-1 補助インスタンスのパラメータ・ファイルの指定

- 26-2 トランスポータブル表領域セットの作成

- 26-3 終了SCNの指定

- 26-4 終了リストア・ポイントの指定

- 26-5 終了時刻の指定

- 26-6 ファイルの出力場所の指定

- 26-7 SET NEWNAME FOR DATAFILEを使用した補助データファイル名の指定

- 27-1 DBMS_TDB.CHECK_DBの実行

- 27-2 DBMS_TDB.CHECK_EXTERNALの実行

- 27-3 ソース・ホスト上のデータベースの変換

- 27-4 CONVERT DATABASE ON DESTINATION PLATFORMの実行

図一覧

- 1-1 バックアップおよびリカバリのドキュメント・ロードマップ

- 3-1 RMAN環境の例

- 3-2 チャネルの割当て

- 8-1 データファイルの多重化

- 8-2 差分増分バックアップ

- 8-3 累積増分バックアップ

- 8-4 リカバリ期間1

- 8-5 リカバリ期間2

- 12-1 メディア・マネージャのクロスチェック

- 13-1 リカバリ・カタログのバックアップのリポジトリとしての制御ファイルの使用

- 14-1 データベース・インカネーションの履歴

- 15-1 データ・リカバリ・アドバイザ

- 19-1 RMANのメディア・リカバリの実行

- 22-1 ディスクへのマルチチャネル・バックアップのフェーズ

- 22-2 テープへのマルチチャネル・バックアップのフェーズ

- 22-3 ディスク・バッファの割当て

- 22-4 テープ・バッファの割当て

- 22-5 同期テープI/O

- 22-6 非同期テープI/O

- 24-1 複製方法

- 24-2 アクティブなデータベースの複製

- 24-3 ターゲット接続を行わない場合のバックアップベースの複製

- 24-4 ターゲット接続およびリカバリ・カタログ接続を行わないバックアップベースの複製

- 24-5 ターゲット接続を行う場合のバックアップベースの複製

- 26-1 バックアップからのRMANトランスポータブル表領域: アーキテクチャ

表一覧

- 1-1 バックアップ方法の機能比較

- 2-1 一般的なバックアップ・オプション

- 2-2 FOR RECOVER OF COPYのオプション

- 2-3 バックアップ用のLISTオプション

- 2-4 追加のLISTオプション

- 2-5 REPORTのオプション

- 3-1 RMAN環境の構成要素

- 4-1 RMANによるデータベース接続の概要

- 4-2 例の値

- 5-1 デフォルトのデバイス・タイプを構成するコマンド

- 5-2 高速リカバリ領域内のファイル

- 5-3 高速リカバリ領域の初期化パラメータ

- 5-4 同一ファイルかどうかを判断する基準

- 5-5 バックアップの最適化への冗長性設定の影響

- 6-1 チャネル制御オプション

- 7-1 V$SYSSTAT統計

- 9-1 アーカイブREDOログ・レコードの例

- 9-2 基本スクリプトを毎日実行した場合の影響

- 9-3 高度なスクリプトを毎日実行した場合の影響

- 10-1 日次スクリプトおよび週次スクリプトの効果

- 10-2 BACKUP ... SKIPのオプション

- 11-1 LISTの対象となるオブジェクト

- 11-2 最も一般的なLISTのオプション

- 11-3 REPORTのオプション

- 12-1 RMANの削除コマンド

- 13-1 1年間での一般的なリカバリ・カタログ領域要件

- 16-1 ブロックの破損の検出、修復および監視

- 21-1 RMANのTSPITRのエンティティ

- 21-2 TS_PITR_OBJECTS_TO_BE_DROPPEDビュー

- 21-3 ファイル名を指定する場合の優先順位

- 21-4 RMAN管理の補助インスタンスに対するデフォルトの初期化パラメータ

- 21-5 ユーザー管理の補助インスタンスの初期化パラメータ

- 22-1 データファイルの読取りバッファのサイズを決定するアルゴリズム

- 22-2 RMANに関連するV$SESSION_LONGOPSの列

- 22-3 多重化のレベルの調整

- 23-1 メッセージ出力タイプ

- 23-2 RMANのエラー・メッセージの範囲

- 23-3 メディア・マネージャのエラー・メッセージの範囲

- 23-4 トラブルシューティングで有効なV$ビュー

- 25-1 SET NEWNAMEの置換変数

- 25-2 例25-3 SET NEWNAME DATABASEコマンドの結果

- 25-3 Oracle Managed Filesの初期化パラメータ

- 25-4 Oracle Managed Filesの初期化パラメータの制限事項

- 25-5 補助インスタンスの初期化パラメータ

- 25-6 複製データベースの表領域のサブセットを指定するためのオプション

- 26-1 補助インスタンスに対するデフォルトの初期化パラメータ

- 27-1 CHECK_DBファンクションのパラメータ

- 28-1 ddの使用に重要なデータベースの詳細

- 28-2 ddコマンドのオプション

- 28-3 ddバックアップのシナリオ

- 28-4 OCOPYのオプション

- 29-1 ユーザー管理のリストア操作

- 29-2 アーカイブREDOログの消失

- 29-3 データ・ディクショナリと制御ファイルの間の矛盾

- 29-4 メディア・リカバリの問題

- 29-5 メディア・リカバリの解決方法

- 29-6 リカバリでブロックの破損を許可するためのガイドライン

- 30-1 制御ファイルが消失した場合のシナリオ

- 30-2 制御ファイルの作成のオプション

- 30-3 V$LOGのSTATUS列

- 30-4 オンラインREDOログ・グループが消失した後のリカバリ

はじめに

ここでは、次の項目について説明します。

- 対象読者

- ドキュメントのアクセシビリティについて

- 関連ドキュメント

- 場所が変更されたドキュメント

- 表記規則

対象読者

『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』は、次の作業を実行するデータベース管理者を対象としています。

- Oracle Databaseのバックアップ、リストアおよびリカバリ

- データベース・ファイルのバックアップのメンテナンス

- Oracle Databaseをインストールする際のファイル・システムとASM間またはプラットフォーム間でのデータ送信

このマニュアルを使用するには、次の知識が必要です。

- リレーショナル・データベースの概念および基本的なデータベース管理(『Oracle Database概要』および『Oracle Database管理者ガイド』を参照)

- データベースを実行するオペレーティング・システム環境

ドキュメントのアクセシビリティについて

Oracleのアクセシビリティについての詳細情報は、Oracle Accessibility ProgramのWebサイト(http://www.oracle.com/pls/topic/lookup?ctx=acc&id=docacc)を参照してください。

Oracle Supportへのアクセス

サポートをご購入のOracleのお客様は、My Oracle Supportにアクセスして電子サポートを受けることができます。詳細情報は(http://www.oracle.com/pls/topic/lookup?ctx=acc&id=info)か、聴覚に障害のあるお客様は(http://www.oracle.com/pls/topic/lookup?ctx=acc&id=trs)を参照してください。

関連ドキュメント

バックアップとリカバリの詳細は、次のOracleドキュメントを参照してください。

- 『Oracle Databaseバックアップおよびリカバリ・リファレンス』

- 『Oracle Databaseユーティリティ』

- 『Oracle Databaseストレージ管理者ガイド』

Backup Solutions Program(BSP)については、次のWebサイトを参照してください。

http://www.oracle.com/technetwork/database/features/availability/bsp-088814.html

ドキュメント・セットの多くのマニュアルでは、Oracle Databaseとともにデフォルトでインストールされる、シード・データベースのサンプル・スキーマを使用しています。これらのスキーマがどのように作成され、ユーザーがどのように使用できるかについては、『Oracle Databaseサンプル・スキーマ』を参照してください。

場所が変更されたドキュメント

次の章は、場所が変更されています。

- 第24章「トランスポータブル表領域セットの作成」。『Oracle Database管理者ガイド』を参照してください。

- 第26章「ASMでのデータの移行の実行」。『Oracle Databaseストレージ管理者ガイド』を参照してください。

表記規則

このマニュアルでは次の表記規則を使用します。

規則

意味

太字

太字は、操作に関連するGraphical User Interface要素、または本文中で定義されている用語および用語集に記載されている用語を示します。

イタリック体

イタリックは、ドキュメントのタイトル、強調またはユーザーが特定の値を指定するプレースホルダ変数を示します。

固定幅フォント

固定幅フォントは、段落内のコマンド、URL、サンプル内のコード、画面に表示されるテキスト、または入力するテキストを示します。

バックアップおよびリカバリの新機能

この項では、Oracle Database 11gリリース2のバックアップおよびリカバリの新機能について説明し、追加情報の参照先を示します。

このリリースのRMAN(RMAN)によって、Oracle Databaseのバックアップおよびリカバリの信頼性、効率性および可用性が引き続き向上しています。特に、今回のリリースでは、Oracle Database Backup Cloud(Oracle Secure Backup(OSB)Cloud Moduleと呼ばれる)の導入、拡張バックアップ圧縮レベルの追加および複数の複製データベース・コマンドの拡張が行われています。

Oracle 11gリリース2の新しいバックアップおよびリカバリ機能

Oracle Database 11gリリース2(11.2)では、次のバックアップおよびリカバリ機能が新しく導入されています。

- Oracle Secure Backup(OSB) Cloud Module
RMANのバックアップおよびリカバリ・タスクに、Amazon Simple Storage Service(Amazon S3)によって提供されるインターネット・ベースのデータ・ストレージ・サービスを利用できます。OSB Cloud Moduleインタフェースは、Amazon S3の機能を拡張して、管理しやすく、コスト効率のよい、スケーラブルな組織内データ・ストレージのメンテナンス手法および完全に構成されたローカルのバックアップ・インフラストラクチャを提供します。

参照:
『Oracle Databaseバックアップおよびリカバリ・リファレンス』の「付録C」を参照してください。

- 複製データベース・コマンドの拡張
ターゲット・データベースに接続することなく、データベースを複製できます。この操作の唯一の要件は、カタログおよび補助データベースに接続することです。この新しい機能は、ターゲット・データベースが常に使用可能ではない場合に役立ちます。

ターゲット・データベースおよびリカバリ・カタログに接続することなく、データベースを複製することもできます。この場合の唯一の要件は、ディスクのバックアップ場所を提供することです。この場所に、データベース複製のためのすべてのバックアップ、データファイルのコピー、アーカイブ・ログ、および制御ファイルのコピーを格納します。このデータベース複製の拡張は、ターゲット・データベースおよびリカバリ・カタログに接続できない場合に有効です。

ターゲット・データベースを複製する場合、RMANによって、複製操作の開始前に、除外された表領域にSYS-が所有するオブジェクトやマテリアライズド・ビューが含まれていないかどうかが確認され、自己完結型以外の表領域が識別されます。

参照:
関連するDUPLICATEコマンド・オプションNOREDOおよびUNDO TABLESPACEについては、第24章「データベースの複製」および『Oracle Databaseバックアップおよびリカバリ・リファレンス』を参照してください。

- RMANの表領域のPoint-in-Timeリカバリ(TSPITR)の拡張
TSPITRを使用すると、削除された表領域をリカバリしたり、表領域がオンラインになる前の時点へのPoint-in-Timeリカバリを実行できます。Point-in-Timeリカバリは、必要に応じて繰り返し実行できます。

注意:
今回より前のリリースでは、削除された表領域に対する操作をTSPITRで実行することはできませんでした。

- 自動ブロック修復
破損ブロックの検出が拡張されたため、ブロック修復がより効率的になり可用性が向上します。自動ブロック修復の拡張は、Oracle Database 11gリリース1のブロック破損の自動検出を補完します。

(ユーザーのSQL問合せなどによって)検出された破損ブロックが、フィジカル・スタンバイ・データベースの正常なブロックを使用して、自動的に修復されるようになりました。自動ブロック修復では、ユーザーが破損ブロックでデータを問い合せても、破損ブロックのエラー・メッセージが表示されません(ORA-01578)。かわりに、破損ブロックが修復される間動作が一時停止され、次にSQL問合せの結果が戻されます。自動ブロック修復は、修復が失敗しないかぎり、ユーザーに対して透過的です。フィジカル・スタンバイ・データベースから取得されたブロックに対してREDOを適用する必要がなくなるため、ブロックをより高速にリカバリできます。

フィジカル・スタンバイ・データベース上でリアルタイム問合せモードが有効である必要があるため、自動ブロック修復には、Oracle Active Data Guardライセンスが必要です。

この操作は自動的に行われますが、RMANのRECOVER BLOCKコマンドを使用して明示的に起動することもできます。

参照:
第19章「ブロック・メディア・リカバリの実行」および『Oracle Databaseバックアップおよびリカバリ・リファレンス』のRECOVERコマンドを参照してください。

- SET NEWNAMEのオプション
SET NEWNAMEコマンドは、より効果的かつ簡単に使用できます。このコマンドは、特定の表領域、またはデータファイルおよび一時ファイル全体に使用できます。また、データベース内の複数のファイルの名前を変更することもできます。

新しい文字列書式の識別子%bによって、より簡単にファイルを移動できます。書式識別子%bとともにSET NEWNAMEを使用すると、ディレクトリ・パスを含めずにファイル名を指定できます。このオプションは、データファイルを、同じ名前のまま別のディレクトリの場所に移動する場合に特に役立ちます。

参照:

- 第25章「データベースの複製: 高度なトピック」

- 例25-2「SET NEWNAME FOR DATAFILEおよびFOR TABLESPACEを使用した複製」

- 拡張されたSET NEWNAME機能については、『Oracle Databaseバックアップおよびリカバリ・リファレンス』のSETオプションを参照してください。

- CONVERT DATABASEのオプション
新しいオプションSKIP UNNECESSARY DATAFILESがCONVERT DATABASEコマンドでサポートされるようになりました。このオプションが起動されると、指定されたプラットフォーム間での転送で、RMANによる処理が必要なデータファイルのみが変換されます。残りのデータファイルは、共有ストレージまたはパス名を介して転送先データベースによって使用できます。UNDOセグメントを含まないデータファイルの変換をスキップすると、データベースの転送時間全体を短縮できます。このオプションは、ソースでの変換時またはON DESTINATION PLATFORMの変換時に使用できます。

参照:
『Oracle Databaseバックアップおよびリカバリ・リファレンス』のCONVERT DATABASEオプションを参照してください。

- 拡張バックアップ圧縮レベル
RMANでは、Advanced Compressionオプション(ACO)によるさらに幅広い圧縮レベルが利用可能になりました。既存のBASIC圧縮オプションは、ほとんどの環境に適していますが、ACOのバックアップ圧縮レベル(LOW、MEDIUMおよびHIGH)を試して、より優れたパフォーマンスまたは高い圧縮率を得ることができます。

参照:
「バックアップ・セットのバイナリ圧縮」および『Oracle Databaseバックアップおよびリカバリ・リファレンス』のCONFIGURE ... COMPRESSION ALGORITHMコマンド・オプションに関する説明を参照してください。

- INCARNATION指定子の拡張
インカネーションを使用して、BACKUP、RESTOREおよびLISTコマンドのアーカイブREDOログ範囲をさらに修飾できるようになりました。アーカイブ・ログの範囲を表示する場合に、ALL、CURRENTまたは特定のインカネーション番号を指定できるようになりました。

参照:
設定および例については、『Oracle Databaseバックアップおよびリカバリ・リファレンス』を参照してください。

- BACKUPコマンドにTO DESTINATION構文が追加されました。これにより、ディスクにバックアップする場合に特定のディレクトリの場所を指定できます。この構文は、主にBACKUP RECOVERY AREAコマンドで使用します。バックアップの最適化が有効な場合、RMANは、TO DESTINATIONオプションで指定されたディレクトリの場所にある同一のファイルのバックアップのみをスキップします。

参照:
BACKUPコマンドおよび新しい設定の例については、『Oracle Databaseバックアップおよびリカバリ・リファレンス』を参照してください。

RMANの機能または前提条件における変更事項

Oracle Active Data Guardオプションのライセンスを付与されている場合にのみ、フィジカル・スタンバイ・データベースでブロック・チェンジ・トラッキング機能を使用できます。

第I部

バックアップおよびリカバリの概要

この部の章では、バックアップおよびリカバリの概要を示し、バックアップおよびリカバリ計画の立案方法について説明します。

- 第1章「バックアップおよびリカバリの概要」

- 第2章「RMANの概要」

1 バックアップおよびリカバリの概要

この章では、Oracle Databaseのバックアップとリカバリについて説明し、Oracleソリューションの概要を示します。この章の内容は次のとおりです。

- バックアップおよびリカバリの目的

- Oracleのバックアップおよびリカバリのソリューション

- Oracle Flashbackテクノロジ

- データ・リカバリ・アドバイザ

- バックアップおよびリカバリのドキュメント・ロードマップ

注意:
Recovery Manager (RMAN)をすぐに使用する場合は、第2章「RMANの概要」に進みます。

バックアップおよびリカバリの目的

バックアップ管理者の主な責務は、バックアップおよびリカバリ計画を立案、実装および管理することです。通常、バックアップおよびリカバリ計画の目的は、データの消失からデータベースを保護し、データの消失後にデータベースを再構築することです。バックアップ管理者の通常のタスクには、次のものがあります。

- 様々な障害に対する対策の計画およびテスト

- バックアップおよびリカバリ用のデータベース環境の構成

- バックアップ・スケジュールの設定

- バックアップおよびリカバリ環境の監視

- バックアップに関する問題のトラブルシューティング

- 必要に応じたデータの消失からのリカバリ

バックアップ管理者は、バックアップおよびリカバリに関する次のような他の責務を求められることもあります。

- 長期格納用データベース・コピーを作成する場合のデータ保持

- 1つのデータベースまたはホストから別のデータベースまたはホストにデータを移動する場合のデータ送信

このマニュアルでは、前述のタスクの実行方法について説明します。

データ保護

バックアップ管理者は、主にデータ保護用のバックアップを作成および監視します。バックアップとは、データを再構築するために使用可能なデータベースのデータのコピーのことです。バックアップは、物理バックアップまたは論理バックアップのいずれかです。

物理バックアップとは、データベースを保存およびリカバリするために使用する物理ファイルのコピーのことです。これらのファイルには、データファイル、制御ファイル、アーカイブREDOログなどがあります。つまり、データベース情報を別の場所(ディスク、またはテープなどのオフライン・ストレージ・メディア)に保存するファイルのコピーは、すべて物理バックアップになります。

論理バックアップには、表やストアド・プロシージャなどの論理データが含まれています。Oracle Data Pumpを使用すると、論理データをバイナリ・ファイルにエクスポートし、後でそのバイナリ・ファイルをデータベースにインポートできます。データ・ポンプのコマンドライン・クライアントであるexpdpおよびimpdpでは、DBMS_DATAPUMPおよびDBMS_METADATA PL/SQLパッケージが使用されます。

物理バックアップは、適切なバックアップおよびリカバリ計画の基礎となります。論理バックアップは、様々な状況で物理バックアップを補足するために役立ちますが、物理バックアップがなければデータ消失に十分に対処することはできません。

特に明記されていないかぎり、バックアップおよびリカバリのドキュメントで使用されているバックアップという用語は、物理バックアップを指します。データベースのバックアップとは、物理バックアップを作成する作業のことです。バックアップおよびリカバリのドキュメント・セットでは、ほとんどの場合、物理バックアップについて重点が置かれています。

Oracle Databaseの通常の操作を中断したり、データベースのI/O操作に影響を及ぼす問題はいくつかありますが、通常、DBAの介入やデータ・リカバリが必要となるのは、メディア障害、ユーザー・エラーおよびアプリケーション・エラーのみです。 他の障害で、データが消失しないDBAの介入、またはバックアップからのリカバリが不要なDBAの介入が必要になる場合もあります。たとえば、インスタンスの障害が発生した後にデータベースを再起動したり、データファイルが一杯になったことが原因で文の実行が失敗した後にディスク領域をさらに割り当てる必要がある場合があります。

メディア障害

メディア障害とは、データベースの実行に必要なディスク・ファイルの読取りまたは書込みの障害を発生させる、ディスクでの物理的な問題のことです。すべてのデータベース・ファイルで、メディア障害が発生する危険性があります。メディア障害が発生した後の適切なリカバリ技術は、影響を受けているファイルおよび使用可能なバックアップのタイプによって異なります。

バックアップおよびリカバリの特に重要な側面は、障害リカバリ計画を立案して、データベース・ホスト全体の消失などの重大なデータ消失を回避することです。

ユーザー・エラー

ユーザー・エラーは、アプリケーション・ロジックのエラーまたは手作業の誤りによって、データベース内のデータが誤って変更されたり、削除された場合に発生します。ユーザー・エラーは、データベースの停止時間を発生させる最も大きな原因であるとみなされています。

ユーザー・エラーによるデータの消失は、局所的な場合または広範囲に及ぶ場合があります。局所的な損害の例としては、従業員表から誤った人を削除してしまった場合などがあります。このタイプの損害には、的確な検出および修復が必要です。広範囲に及ぶ損害の例としては、現在の月の会社の注文を削除するバッチ・ジョブなどがあります。この場合は、データベースの停止時間が長くならないようにするために、思い切った処置が必要となります。

ユーザー・トレーニングや権限の慎重な管理によってほとんどのユーザー・エラーは回避できますが、ユーザー・エラーによってデータが消失した場合に、消失したデータを正常にリカバリできるかどうかは、バックアップ計画にかかっています。

アプリケーション・エラー

ソフトウェアの障害によってデータ・ブロックが破損する場合もあります。物理的な破損(メディア破損とも呼ばれます)の場合、ブロックがデータベースで認識されません。チェックサムが無効か、ブロック内容がすべて0(ゼロ)か、またはブロックのヘッダーとフッターが一致していません。破損が広範囲に及んでいない場合は、 ブロック・メディア・リカバリを使用して簡単に修復できることがあります。

関連項目:

- 第9章「データベースのバックアップ」

- データ・ポンプを使用する方法の詳細は、『Oracle Databaseユーティリティ』を参照してください。

データの保持

データの保持は、データの保護と関連していますが、目的が異なります。たとえば、ビジネスの四半期の終わりに存在していたデータベースのコピーを保持する必要がある場合があります。このバックアップは、障害リカバリ計画の一部ではありません。多くの場合、これらのバックアップが書き込まれるメディアは、バックアップの完了後に使用できません。火災の危険性がない保管場所にテープを送ったり、テスト施設にポータブル・ハード・ドライブを発送する場合などです。RMANには、バックアップを作成し、バックアップの保存方針からそのバックアップを除外する有効な方法が備えられています。このタイプのバックアップは、 アーカイブ・バックアップと呼ばれます。

関連項目:
「長期格納用のデータベース・バックアップの作成」

データ送信

状況によっては、データベースまたはデータベース・コンポーネントのバックアップを作成し、それを別の場所に移動する必要がある場合があります。たとえば、Recovery Manager (RMAN)を使用すると、データベース・コピーの作成、別のデータベースにインポート可能な表領域コピーの作成、またはプラットフォーム間でのデータベース全体の移動を行うことができます。これらのタスクは、厳密にはバックアップおよびリカバリ計画の一部ではありませんが、データベースのバックアップを使用する必要があるため、バックアップ管理者の責務に含まれる場合があります。

関連項目:
第I部「RMANを使用したデータの送信」の章を参照してください。

Oracleのバックアップおよびリカバリのソリューション

バックアップおよびリカバリ計画の実装中に、次のソリューションを使用できます。

- Recovery Manager (RMAN)
Recovery Managerは、Oracle Databaseと完全に統合されており、一連のバックアップおよびリカバリ・アクティビティ(バックアップに関する履歴データのRMANリポジトリのメンテナンスなど)を実行します。RMANには、コマンドラインまたはOracle Enterprise Managerを介してアクセスできます。

- ユーザー管理のバックアップおよびリカバリ
このソリューションでは、ホスト・オペレーティング・システム・コマンドとSQL*Plusリカバリ・コマンドを組み合せて、バックアップおよびリカバリを実行します。管理者は、バックアップおよびリカバリを実行するタイミングと方法を詳細に決定する必要があります。

これらのソリューションはOracleによってサポートされており、完全に文書化されていますが、データベースのバックアップおよびリカバリのためのソリューションとしてはRMANを使用することをお薦めします。RMANでは、様々なホスト・オペレーティング・システム間で共通のバックアップ・タスク用インタフェース、およびユーザー管理の方法では使用できない複数のバックアップの方法が提供されています。

このマニュアルのほとんどの部分では、RMANベースのバックアップおよびリカバリについて説明しています。ユーザー管理のバックアップおよびリカバリの方法については、「ユーザー管理のバックアップおよびリカバリの実行」を参照してください。これらの機能の主なものを次に示します。

- 増分バックアップ
増分バックアップでは、前回のバックアップ以降に変更されたブロックのみが格納されます。このため、より圧縮されたバックアップおよび高速なリカバリが可能になり、データファイルのメディア・リカバリ中にREDOを適用する必要が少なくなります。ブロック・チェンジ・トラッキングを有効にした場合は、各入力データファイルで全体スキャンが行われないようにすることによって、パフォーマンスを向上させることができます。増分バックアップを実行するには、BACKUP INCREMENTALコマンドを使用します。

- ブロック・メディア・リカバリ
少数の破損データ・ブロックのみが含まれているデータファイルは、オフラインにしたりバックアップからリストアしたりせずに修復することができます。ブロック・メディア・リカバリを実行するには、RECOVER BLOCKコマンドを使用します。

- バイナリ圧縮
Oracle Databaseに統合されているバイナリ圧縮メカニズムによって、バックアップのサイズが削減されます。

- 暗号化バックアップ
RMANは、Oracle Databaseに統合されているバックアップの暗号化機能を使用して、暗号化された形式でバックアップ・セットを格納します。ディスクに暗号化バックアップを作成するには、データベースでAdvanced Security Optionを使用している必要があります。暗号化バックアップをテープに直接作成するには、RMANでOracle Secure Backup SBTインタフェースを使用している必要があります。

- 自動化されたデータベースの複製
ASMデータベース間での直接の複製を含む様々なストレージ構成をサポートしており、データベースのコピーを簡単に作成できます。

- クロス・プラットフォームのデータ変換

RMANまたはユーザー管理の方法のいずれを使用しても、データ・ポンプ・エクスポート・ユーティリティを使用して作成したスキーマ・オブジェクトの論理バックアップで物理バックアップを補助できます。リストアおよびリカバリ後に、データ・ポンプ・インポートを使用してデータを再作成できます。論理バックアップの大部分は、バックアップおよびリカバリに関するドキュメントでは説明されていません。

表1-1に、様々なバックアップ方法の機能の概要を示します。

表1-1 バックアップ方法の機能比較

機能

Recovery Manager

ユーザー管理

データ・ポンプ・エクスポート

クローズ状態のデータベース・バックアップ

サポートされています。インスタンスをマウントする必要があります。

サポートされています。

サポートされていません。

オープン状態のデータベース・バックアップ

サポートされています。BEGIN/END BACKUP文を使用する必要はありません。

サポートされています。BEGIN/END BACKUP文を使用する必要があります。

一貫性バックアップの生成にはロールバックまたはUNDOセグメントが必要です。

増分バックアップ

サポートされています。

サポートされていません。

サポートされていません。

破損ブロックの検出

サポートされています。破損ブロックを識別してV$DATABASE_BLOCK_CORRUPTIONに記録します。

サポートされていません。

サポートされています。エクスポート・ログで破損ブロックを識別します。

バックアップに含めるファイルの自動指定

サポートされています。バックアップするすべてのファイル(データベース全体、表領域、データファイル、制御ファイルなど)の名前および場所を指定します。

サポートされていません。バックアップするファイルを手動で検索し、コピーする必要があります。

該当なし。

バックアップ・リポジトリ

サポートされています。バックアップは、RMANメタデータのメイン・リポジトリである制御ファイルに記録されます。また、このメタデータを別のデータベースのスキーマであるリカバリ・カタログに格納することもできます。

サポートされていません。DBAは、独自のバックアップ・レコードを保持する必要があります。

サポートされていません。

メディア・マネージャへのバックアップ

サポートされています。メディア・マネージャとのインタフェースとして機能します。また、RMANは、プロキシ・コピーもサポートしています。プロキシ・コピーは、メディア・マネージャでディスクとバックアップ・メディア間のデータの転送を完全に管理できるようにする機能です。

サポートされています。テープへのバックアップは、手動で行うか、またはメディア・マネージャによって制御されます。

サポートされていません。

初期化パラメータ・ファイルのバックアップ

サポートされています。

サポートされています。

サポートされていません。

パスワードおよびネットワーク・ファイルのバックアップ

サポートされていません。

サポートされています。

サポートされていません。

プラットフォームに依存しないバックアップ用言語

サポートされています。

サポートされていません。

サポートされています。

Oracleフラッシュバック技術

『Oracle Database概要』で説明されているように、Oracleフラッシュバック技術は、物理バックアップおよびリカバリ計画を補完します。この機能セットによって、データ保護の追加レイヤーが提供されます。具体的には、Oracleフラッシュバックの様々な機能を使用すると、バックアップのリストアまたはPoint-in-Timeリカバリを実行せずに、過去の状態のデータを表示したり、データベースを巻き戻すことができます。通常、フラッシュバック機能が適用されるほとんどの場合は、フラッシュバック機能の方がメディア・リカバリより効率的で簡単です。

論理フラッシュバック機能

Oracleのほとんどのフラッシュバック機能は論理レベルで実行されるため、データベース・オブジェクトの表示および操作を行うことができます。Oracleの論理レベルのフラッシュバック機能は、RMANに依存しないため、バックアップ計画でRMANを使用するかどうかに関係なく使用できます。Oracle Flashback Dropを除き、論理フラッシュバック機能はUNDOデータに依存しています。UNDOデータは、各データベースの更新の影響およびその更新によって上書きされる値に関するレコードです。

Oracle Databaseには、次の論理フラッシュバック機能が含まれています。

- Oracle Flashback Query
目標時点を指定して、データベースに対する問合せを実行し、目標時点に表示される結果を確認できます。表への更新などの不要な変更からリカバリするには、エラー発生前の目標時点を選択し、消失した行の内容を取得する問合せを実行します。この機能の使用方法の詳細は、『Oracle Databaseアドバンスト・アプリケーション開発者ガイド』を参照してください。

- Oracle Flashback Version Query
指定した時間間隔で1つ以上の表に存在していたすべての行のすべてのバージョンを表示できます。様々なバージョンの行に関するメタデータ(バージョンを作成したトランザクションの開始時刻、終了時刻、操作、トランザクションIDなど)を取得することもできます。この機能を使用すると、消失したデータ値をリカバリし、問い合せた表に対する変更を監査できます。この機能の使用方法の詳細は、『Oracle Databaseアドバンスト・アプリケーション開発者ガイド』を参照してください。

- Oracle Flashback Transaction Query
単一のトランザクションによって行われた変更、または特定の期間にすべてのトランザクションによって行われた変更を表示できます。この機能の使用方法の詳細は、『Oracle Databaseアドバンスト・アプリケーション開発者ガイド』を参照してください。

- Oracle Flashback Transaction
トランザクションを無効にできます。Oracle Databaseによって、トランザクション間の依存性が判別され、不要な変更を無効にする補正トランザクションが実際に作成されます。データベースは、トランザクション、およびそのトランザクションに依存している他のすべてのトランザクションが発生しなかった場合と同様の状態まで巻き戻されます。この機能の使用方法の詳細は、『Oracle Databaseアドバンスト・アプリケーション開発者ガイド』を参照してください。

- Oracle Flashback Table
データベースのいずれの部分もオフラインにすることなく、表または表のセットを過去の指定した時点にリカバリできます。ほとんどの場合、フラッシュバック表を使用すると、より複雑なPoint-in-Timeリカバリ操作を行う必要がなくなります。フラッシュバック表では、表がリストアされ、同時に現在の索引、トリガーおよび制約などの関連する属性が自動的にメンテナンスされます。これによって、ユーザーはデータベース固有のプロパティを検索してリストアすることを回避できます。この機能の使用方法については、「フラッシュバック表を使用した表の巻戻し」を参照してください。

- Oracle Flashback Drop
DROP TABLE文の結果を無効にできます。この機能の使用方法については、「フラッシュバック・ドロップを使用したDROP TABLE操作の巻戻し」を参照してください。

フラッシュバック・データ・アーカイブでは、一部の論理フラッシュバック機能を使用して、非常に古いデータにアクセスできます。フラッシュバック・データ・アーカイブは、1つ以上の表領域または表領域の一部で構成されています。フラッシュバック・データ・アーカイブを作成する場合は、名前、保存期間および表領域を指定します。デフォルトのフラッシュバック・データ・アーカイブを指定することもできます。保持期間を経過すると、古い履歴データは自動的に消去されます。

フラッシュバック・アーカイブは、個々の表に対して有効または無効にすることができます。デフォルトでは、フラッシュバック・アーカイブはすべての表に対して無効になっています。

参照:

- フラッシュバック表およびフラッシュバック・ドロップを実行する方法については、第18章「フラッシュバックおよびデータベースのPoint-in-Timeリカバリの実行」を参照してください。

- 論理フラッシュバック機能の詳細は、『Oracle Databaseアドバンスト・アプリケーション開発者ガイド』を参照してください。

フラッシュバック・データベース

物理レベルでは、Oracle Flashback Databaseを使用すると、データベースのPoint-in-Timeリカバリ(DBPITR)より効率的なデータ保護を行うことができます。現行のデータファイルに不要な変更が含まれている場合は、RMANコマンドFLASHBACK DATABASEを使用して、データファイルを過去の時点の内容に戻すことができます。最終的に生成される結果はDBPITRの結果に類似していますが、バックアップからデータファイルをリストアする必要はなく、メディア・リカバリと比較するとREDOを使用する必要が少ないため、通常、はるかに短時間で戻されます。

フラッシュバック・データベースでは、過去のバージョンのデータ・ブロックへのアクセスにフラッシュバック・ログを使用します。また、アーカイブREDOログに含まれている情報も使用します。フラッシュバック・データベースを使用するには、データベース用の高速リカバリ領域を構成する必要があります。フラッシュバック・ログは、この領域にのみ格納できるためです。デフォルトでは、フラッシュバック・ロギングは有効になっていません。フラッシュバック・ログに使用される領域は、データベースによって自動的に管理され、高速リカバリ領域内の他のファイルに必要な領域との間でバランスが取られています。

Oracle Databaseでは、フラッシュバック・データベース、バックアップおよびリカバリとともにリストア・ポイントも使用できます。リストア・ポイントは、システム変更番号(SCN)に対応する別名です。データベースの一部またはすべてを任意の時点の内容に戻す必要が予測される場合は、リストア・ポイントをその時点に作成できます。保証付きリストア・ポイントによって、フラッシュバック・データベースを使用してデータベースをリストア・ポイントの時点に戻すことができます。

参照:
FLASHBACK DATABASEコマンドを使用してフラッシュバック・データベースを実行する方法については、「フラッシュバック・データベースを使用したデータベースの巻戻し」を参照してください。

データ・リカバリ・アドバイザ

Oracle Databaseには、データ・リカバリ・アドバイザ・ツールが含まれています。このツールは、永続的なデータの障害を自動的に診断し、適切な修復オプションを提示して、ユーザーの要求に応じて修復を実行します。データ・リカバリ・アドバイザによって、すべてのOracleバックアップおよびリカバリのソリューション用のシングル・ポイント・エントリが提供されます。データ・リカバリ・アドバイザは、Enterprise ManagerのDatabase ControlまたはGrid Controlのコンソール、あるいはRMANのコマンドライン・クライアントを介して使用できます。

通常、データベース障害は、エラー・メッセージ、アラート、トレース・ファイル、トレース・ダンプ、データ整合性チェックの失敗などの様々な症状を示します。データ・リカバリ・アドバイザは、自動的に診断を行い、これらの障害に関してユーザーに通知します。データ・リカバリ・アドバイザでは、障害とは、一連の修復処置に直接マップできる永続的なデータの破損のことです。各障害には、OPENまたはCLOSEDのステータスがあります。また、各障害には、CRITICAL、HIGHまたはLOWの優先順位があります。

障害は、データ整合性チェックによって検出されます。データ整合性チェックとは、データベースまたはそのコンポーネントの状態を評価するために実行する診断手順のことです。データ整合性チェックによって障害が検出された場合、データ・リカバリ・アドバイザは一連の障害による影響を自動的に評価し、一連の修復オプションに結果をマップします。通常、データ・リカバリ・アドバイザは自動修復オプションおよび手動修復オプションの両方を提示します。

データ・リカバリ・アドバイザは、最適な自動修復オプションおよびデータベースへのその影響を判断します。修復オプションには、データファイルのリストアおよびリカバリ、メディア・リカバリ、フラッシュバック・データベースなどの修復が含まれています。データ・リカバリ・アドバイザは、自動修復オプションを提示する前に、特定の環境でのそのオプションの妥当性、および提示する修復の実行に必要なメディア・コンポーネントの可用性を検証します。

自動修復オプションを選択すると、RMANによってOracle Databaseでのセッションが調整され、修復が自動的に実行されます。データ・リカバリ・アドバイザ・ツールは、修復が成功したことを確認し、該当する障害をクローズします。

関連項目:
データ・リカバリ・アドバイザの使用方法については、第15章「データ・リカバリ・アドバイザを使用した障害の診断および修復」を参照してください。

バックアップおよびリカバリのドキュメント・ロードマップ

図1-1に、バックアップおよびリカバリのドキュメントにナビゲートする場合の推奨方法を示します。ロードマップは、RMANによるバックアップとリカバリ、およびユーザー管理によるバックアップとリカバリの2つのメイン・パスに分かれています。それぞれのメイン・パスから分岐し、再度結合するオプションのパスも示されています。

Oracle Databaseについて十分な知識がなく、バックアップ・リカバリについて学習する必要がある場合は、『Oracle Database 2日でデータベース管理者』を参照してください。バックアップおよびリカバリに関する章で、Oracle Enterprise Managerを使用して基本的な操作を実行する方法が説明されています。また、必要に応じて、『Oracle Database概要』の関連する章を読むことによって、バックアップおよびリカバリの基本的な原則に関する知識を深めることができます。

図1-1 バックアップおよびリカバリのドキュメント・ロードマップ

図1-1に示すように、バックアップおよびリカバリ計画の実装には、RMANを使用する方法(推奨)、またはユーザー管理ツールを使用する方法を使用できます。

Recovery Managerのドキュメント・ロードマップ

RMANを基本的なバックアップおよびリカバリ・ソリューションとして使用する場合は、最初に「RMANの概要」を参照してください。この章は、RMANの最も基本的な方法について説明しており、目的に適しています。RMANを使用したバックアップおよびリカバリ計画の実装方法の包括的な説明は、次の順序に従って各章を参照してください(オプションの章は示されていません)。

1. 第4章「RMANクライアントの起動および操作」を参照してください。
この章では、RMANクライアントを起動してデータベースに接続する方法について説明します。

2. 第5章「RMAN環境の構成」を参照してください。
この章では、高速リカバリ領域、バックアップの保存方針およびアーカイブREDOログの削除方針の構成などの基本的なタスクの実行方法について説明します。

3. 第9章「データベースのバックアップ」を参照してください。
この章では、基本的なバックアップ計画を実装する方法について説明します。

4. 第11章「RMAN操作に関するレポート」を参照してください。
この章では、RMANのバックアップおよびリカバリ操作の監視方法について説明します。具体的には、レポート・コマンド(LIST、REPORTおよびSHOW)および関連するV$ビューとリカバリ・カタログ・ビューの使用方法について説明します。

5. 第12章「RMANバックアップおよびリポジトリ・レコードのメンテナンス」を参照してください。
この章では、バックアップの存在の確認、バックアップのリポジトリ・ステータスの変更、バックアップの削除、他のメンテナンス・タスクの実行を行う方法について説明します。

6. 第15章「データ・リカバリ・アドバイザを使用した障害の診断および修復」を参照してください。
この章では、データ・リカバリ・アドバイザ・ツールの使用方法について説明します。このツールを使用して、障害の表示、それらの障害への対応に関するアドバイスの入手、および状況によっては障害に対する自動修復を行うことができます。

7. 第18章「フラッシュバックおよびデータベースのPoint-in-Timeリカバリの実行」を参照してください。
この章では、FLASHBACK DATABASEコマンドの使用方法、およびRECOVER DATABASEコマンドを使用したPoint-in-Timeリカバリの実行方法について説明します。

8. 第17章「データベースの完全リカバリの実行」を参照してください。
この章では、個々の表領域またはデータベースのリカバリ方法について説明します。

ユーザー管理のバックアップおよびリカバリのドキュメント・ロードマップ

RMANを基本的なバックアップおよびリカバリ・ソリューションとして使用しない場合は、サード・パーティのツールを使用してバックアップを作成し、SQLまたはSQL*Plusのコマンドを使用してリカバリを実行する必要があります。次の順序に従って各章を参照してください。

1. 第28章「ユーザー管理データベース・バックアップの作成」を参照してください。
この章では、サード・パーティのツールを使用したバックアップの作成方法について説明します。

2. 第29章「ユーザー管理のデータベースのフラッシュバックおよびリカバリの実行」を参照してください。
この章では、SQL文FLASHBACK DATABASEの使用方法、およびSQL*PlusのRECOVERコマンドを使用したリカバリの実行方法について説明します。

3. 第30章「ユーザー管理のリカバリの実行: 高度な例」を参照してください。
この章では、様々なリカバリ・シナリオについて説明します。

2 RMANの概要

この章は、このマニュアルの各章の詳細を最初に読まずに、RMANをすぐに使用し始める必要がある新しいユーザーを対象としています。この章では、RMANの最も重要な概念とタスクについてできるかぎり簡潔に説明します。この章を他のバックアップおよびリカバリのドキュメント・セットのかわりにすることはできません。

この章の内容は次のとおりです。

- RMAN環境の概要

- RMANの起動およびデータベースへの接続

- RMANのデフォルト構成の表示

- データベースのバックアップ

- RMAN操作に関するレポート

- RMANバックアップの保持

- データ・リカバリ・アドバイザを使用した障害の診断および修復

- フラッシュバック・データベースを使用したデータベースの巻戻し

- データベース・ファイルのリストアおよびリカバリ

RMAN環境の概要

Recovery Manager(RMAN)とは、データベースでバックアップおよびリカバリ・タスクを実行し、バックアップ計画の管理を自動化するOracle Databaseクライアントのことです。Recovery Managerによって、データベースのバックアップ、リストアおよびリカバリが大幅に簡単になります。

RMAN環境は、データのバックアップに使用されるユーティリティとデータベースで構成されます。RMANの環境には、最低限次のコンポーネントが含まれている必要があります。

- ターゲット・データベース
RMANがTARGETキーワードで接続されているOracle Database。ターゲット・データベースは、RMANがバックアップおよびリカバリ操作を実行するデータベースです。RMANは、常にデータベースの操作に関するメタデータをデータベースの制御ファイルに保持します。RMANのメタデータは、RMANリポジトリと呼ばれます。

- RMANクライアント
コマンドを解釈し、それらのコマンドを実行するようにサーバー・セッションに指示し、そのアクティビティをターゲット・データベースの制御ファイルに記録するOracle Database実行可能ファイル。このRMAN実行可能ファイルは、データベースとともに自動的にインストールされ、通常、他のデータベース実行可能ファイルと同じディレクトリに配置されます。たとえば、Linuxの場合、RMANクライアントは$ORACLE_HOME/binに配置されています。

一部の環境では、次のオプションのコンポーネントが使用されます。

- 高速リカバリ領域
バックアップおよびリカバリに関連するファイルをデータベースで格納および管理できるディスクの場所。高速リカバリ領域の場所およびサイズは、DB_RECOVERY_FILE_DESTおよびDB_RECOVERY_FILE_DEST_SIZE初期化パラメータを使用して設定します。

- メディア・マネージャ
RMANがテープ・ライブラリなどのシーケンシャル・メディア・デバイスと対話するために必要なアプリケーション。メディア・マネージャは、バックアップおよびリカバリ中にこれらのデバイスを制御し、メディアのロード、ラベル付けおよびアンロードを管理します。メディア管理デバイスはSBT(テープへのシステム・バックアップ)デバイスと呼ばれる場合があります。

- リカバリ・カタログ
1つ以上のターゲット・データベースに対するRMANアクティビティを記録するために使用する個別のデータベース・スキーマ。リカバリ・カタログは、制御ファイルが消失した場合にRMANリポジトリ・メタデータを保持することで、制御ファイル消失後のリストアおよびリカバリを簡単に実行できるようにします。データベースは制御ファイル内の古いレコードを上書きする場合がありますが、RMANはユーザーがレコードを削除しないかぎり、カタログ内にレコードを永久に保持します。

この章では、リカバリ・カタログまたはメディア・マネージャを使用しない最も基本的な構成でRMANを使用する方法について説明します。

関連項目:

- RMAN環境の詳細は、第3章「Recovery Managerのアーキテクチャ」を参照してください。

- BACKUPコマンドの構文およびセマンティクスについては、『Oracle Databaseバックアップおよびリカバリ・リファレンス』を参照してください。

RMANの起動およびデータベースへの接続

Recovery Managerクライアントは、オペレーティング・システムのコマンド・プロンプトでrmanコマンドを発行して起動します。起動すると、次の例に示すようなコマンド・プロンプトが表示されます。

% rman
RMAN>

RMANによるデータベースへの接続は、SQL*Plusによるデータベースへの接続と同じ方法で指定および認証します。RMANによるターゲット・データベースまたは補助データベースへの接続にはSYSDBA権限が必要である点のみが異なります。AS SYSDBAキーワードは、暗黙的に指定され、明示的には指定できません。SQL*Plusのデータベース接続オプションについては、『Oracle Database管理者ガイド』を参照してください。

注意:
適切なセキュリティ・プラクティスとして、コマンドラインにパスワードを入力するときは、プレーン・テキストで入力しないでください。RMANでは、RMANプロンプトで要求された場合にのみパスワードを入力してください。パスワード保護については、『Oracle Databaseセキュリティ・ガイド』を参照してください。

データベースには、コマンドライン・オプションまたはCONNECT TARGETコマンドを使用して接続できます。次の例では、RMANを起動し、Oracle Netを介してターゲット・データベースに接続します。AS SYSDBAは暗黙的であるため、指定されていません。RMANによってパスワードの入力を求められます。

% rman
RMAN> CONNECT TARGET SYS@prod

target database Password: password
connected to target database: PROD (DBID=39525561)

次の例では、RMANを起動してから、オペレーティング・システム認証を使用してターゲット・データベースに接続します。

% rman
RMAN> CONNECT TARGET /

connected to target database: PROD (DBID=39525561)

RMANクライアントを終了するには、RMANプロンプトでEXITと入力します。

RMAN> EXIT

一般的なRMANコマンドライン・オプションの構文

RMAN
[ TARGET connectStringSpec
| { CATALOG connectStringSpec }
| LOG ['] filename ['] [ APPEND ]
.
.
.
]...

connectStringSpec::=
['] [userid] [/ [password]] [@net_service_name] [']

次の例では、/tmp/msglog.logにあるテキスト・ファイルにRMANセッションの出力を追加します。

% rman TARGET / LOG /tmp/msglog.log APPEND

関連項目:
RMANクライアントの起動および操作の詳細は、第4章「RMANクライアントの起動および操作」を参照してください。

RMANのデフォルト構成の表示

RMANのバックアップおよびリカバリ環境は、ターゲット・データベースごとに事前構成されます。この構成は、RMANを終了して再起動した場合でも永続し、このターゲット・データベースで行うその後のすべての操作に適用されます。

RMANの構成済の設定では、バックアップ・デバイスを指定し、バックアップ・デバイスへの接続(チャネルと呼ばれる)、バックアップ計画に影響する方針などを構成できます。ほとんどの場合は、デフォルトの構成で十分です。

データベースの現行の構成を表示する手順

1. RMANを起動し、ターゲット・データベースに接続します。

2. SHOW ALLコマンドを実行します。
たとえば、RMANプロンプトでコマンドを次のように入力します。

RMAN> SHOW ALL;

出力には、この構成を再作成するためのCONFIGUREコマンドが表示されます。

関連項目:
RMAN環境の構成方法については、第5章「RMAN環境の構成」および第6章「RMAN環境の構成: 高度なトピック」を参照してください。

データベースのバックアップ

ファイルをバックアップするには、BACKUPコマンドを使用します。RMANは、要求されたバックアップのタイプ用に構成されているデフォルトのデバイスにデータをバックアップします。デフォルトでは、RMANはディスクにバックアップを作成します。高速リカバリ領域が有効になっていて、FORMATパラメータ(表2-1を参照)を指定していない場合、RMANは、リカバリ領域にバックアップを作成し、自動的に一意の名前を指定します。

デフォルトでは、RMANはイメージ・コピーではなくバックアップ・セットを作成します。バックアップ・セットは、1つ以上のバックアップ・ピースで構成されています。バックアップ・ピースとは、RMANのみがアクセス可能な形式で書き込まれた物理ファイルのことです。多重バックアップ・セットには、複数の入力ファイルからのブロックが含まれています。RMANは、バックアップ・セットをディスクまたはテープに書き込むことができます。

BACKUP AS COPYを指定すると、RMANは各ファイルをイメージ・コピーとしてコピーします。イメージ・コピーは、ディスクに作成されたデータベース・ファイルのビットごとのコピーです。イメージ・コピーは、LinuxのcpやWindowsのCOPYなどのオペレーティング・システム・コマンドで作成したコピーと同じですが、RMANのリポジトリに記録されるため、RMANで使用できます。RMANを使用すると、データベースがオープンしている間にイメージ・コピーを作成できます。

関連項目:

- RMANバックアップの概念については、第8章「RMANバックアップの概要」を参照してください。

- RMANでデータベース・ファイルをバックアップする方法については、第9章「データベースのバックアップ」を参照してください。

- BACKUPコマンドの構文およびセマンティクスについては、『Oracle Databaseバックアップおよびリカバリ・リファレンス』を参照してください。

ARCHIVELOGモードでのデータベースのバックアップ

データベースは、ARCHIVELOGモードで稼働している場合、オープン状態でバックアップできます。このバックアップは、データベースを一貫性のある状態にするためにリカバリ時にREDOが必要となるため、非一貫性バックアップと呼ばれます。オープン状態のデータベースのバックアップは、バックアップのリカバリに必要なアーカイブREDOログが存在する場合、データ保護の手段として一貫性バックアップと同様に効率的です。

データベースをオープンした状態でデータベースおよびアーカイブREDOログをバックアップする手順

1. RMANを起動し、ターゲット・データベースに接続します。

2. BACKUP DATABASEコマンドを実行します。
たとえば、RMANプロンプトで次のコマンドを入力して、データベースおよびすべてのアーカイブREDOログ・ファイルをデフォルトのバックアップ・デバイスにバックアップします。

RMAN> BACKUP DATABASE PLUS ARCHIVELOG;

NOARCHIVELOGモードでのデータベースのバックアップ

データベースがNOARCHIVELOGモードで稼働している場合、有効なデータベースのバックアップは一貫性バックアップのみです。バックアップに一貫性を持たせるには、データベースを一貫性のある状態で停止させた後でマウントする必要があります。バックアップをリストアした後で、リカバリを実行する必要はありません。

一貫性のあるデータベースのバックアップを作成する手順

1. RMANを起動し、ターゲット・データベースに接続します。

2. データベースを一貫した状態で停止してから、データベースをマウントします。
たとえば、バックアップのためにデータベースを確実に一貫性のある状態にするには、次のコマンドを入力します。

RMAN> SHUTDOWN IMMEDIATE;
RMAN> STARTUP FORCE DBA;
RMAN> SHUTDOWN IMMEDIATE;
RMAN> STARTUP MOUNT;

3. BACKUP DATABASEコマンドを実行します。
たとえば、RMANプロンプトで次のコマンドを入力して、データベースをデフォルトのバックアップ・デバイスにバックアップします。

RMAN> BACKUP DATABASE;

次のコマンドは、データベース内のすべてデータファイルのイメージ・コピー・バックアップを作成します。

RMAN> BACKUP AS COPY DATABASE;

4. データベースをオープンして、通常の操作を再開します。
データベースをオープンするには、次のコマンドを入力します。

RMAN> ALTER DATABASE OPEN;

一般的なバックアップ・オプション

BACKUPコマンドには、バックアップの出力を制御する多くのオプション、パラメータおよび句が含まれています。表2-1に、一般的なバックアップ・オプションの一部を示します。

表2-1 一般的なバックアップ・オプション

オプション

説明

例

FORMAT

バックアップ・ピースおよびコピー用の位置と名前を指定します。置換変数を使用して一意のファイル名を生成する必要があります。

最も一般的な置換変数は、一意の名前を生成する%Uです。その他の置換変数には、DB_NAMEを示す%d、バックアップ・セットのタイムスタンプを示す%t、バックアップ・セット番号を示す%sおよびバックアップ・ピース番号を示す%pがあります。

BACKUP
FORMAT 'AL_%d/%t/%s/%p'
ARCHIVELOG LIKE '%arc_dest%';

TAG

バックアップ用のラベルとしてユーザー定義文字列を指定します。タグを指定しない場合、RMANは、日付と時刻を含むデフォルト・タグを割り当てます。RMANリポジトリでは、タグは常に大文字で格納されます。

BACKUP
TAG 'weekly_full_db_bkup'
DATABASE MAXSETSIZE 10M;

関連項目:
「バックアップ出力オプションの指定」

増分バックアップの作成

BACKUP INCREMENTALを指定すると、RMANはデータベースの増分バックアップを作成します。増分バックアップでは、前回の増分バックアップ後に行われたデータベースへのブロックレベルの変更が取得されます。通常、増分バックアップは、データベースの全体バックアップより小さく、高速です。増分バックアップを使用したリカバリは、REDOログのみを使用したバックアップより高速です。

増分バックアップ方針の開始点は、レベル0の増分バックアップ(データベースのすべてのブロックのバックアップ)です。レベル0の増分バックアップの内容は全体バックアップと同じです。ただし、レベル0のバックアップは、全体バックアップと異なり、増分バックアップ計画の一部とみなされます。

レベル1の増分バックアップには、前回の増分バックアップ後に変更されたブロックのみが格納されます。レベル1のバックアップの実行時に現行または親のデータベース・インカネーションにレベル0のバックアップが存在しない場合は、RMANによってレベル0のバックアップが自動的に作成されます。

注意:
増分バックアップは、一貫性のある状態での停止の後にデータベースをマウントする場合は作成できますが、NOARCHIVELOGデータベースをオープンしている場合は作成できません。

レベル1のバックアップは、累積増分バックアップ(最新のレベル0のバックアップ後に変更されたブロックをすべて含む)または差分増分バックアップ(最新の増分バックアップ後に変更されたブロックのみを含む)のいずれかにできます。デフォルトでは、増分バックアップは、差分バックアップに設定されています。

増分バックアップからのリストア時には、レベル0のバックアップが開始点として使用され、その後、変更をREDOから1つずつ再適用することを回避できるレベル1のバックアップに基づいて、変更されたブロックが更新されます。増分バックアップを使用したリカバリでは、ユーザーがその他の作業を行う必要はありません。増分バックアップが使用可能な場合、RMANはリカバリ時に増分バックアップを使用します。

データベースの増分バックアップを作成する手順

1. RMANを起動し、ターゲット・データベースに接続します。

2. BACKUP INCREMENTALコマンドを実行します。
次の例では、増分バックアップ計画の基礎となるレベル0の増分バックアップを作成します。

BACKUP INCREMENTAL LEVEL 0 DATABASE;

次の例では、レベル1の累積増分バックアップを作成します。

BACKUP INCREMENTAL LEVEL 1 CUMULATIVE DATABASE;

次の例では、レベル1の差分増分バックアップを作成します。

BACKUP INCREMENTAL LEVEL 1 DATABASE;

関連項目:
増分バックアップの概念の詳細は、「増分バックアップ」および「増分バックアップの作成および更新」を参照してください。

増分更新バックアップの作成

RMANの増分更新バックアップ機能は、効率的な増分バックアップ計画です。この計画の主な機能は、次のとおりです。

- この計画では、基礎としてレベル0のデータファイル・コピーが必要です。このコピーには、システム定義またはユーザー定義のタグがあります。

- レベル0のデータファイル・コピーと同じタグを使用して、レベル1の差分バックアップが定期的に作成されます。BACKUP FOR RECOVER OF COPYコマンドは、同じタグが含まれている最新の増分バックアップ以降に変更されたブロックのみが増分バックアップに含まれるよう指定します。

- 増分バックアップがレベル0のデータファイル・コピーに定期的に適用されます。データファイル・コピーが最新の変更によって更新されているため、必要なメディア・リカバリが削減されます。

表2-2に、増分更新バックアップ計画の実装のために、FOR RECOVER OF COPYで使用するオプションを示します。

表2-2 FOR RECOVER OF COPYのオプション

BACKUPオプション

説明

例

FOR RECOVER OF COPY WITH TAG 'tag_name'

TAGを使用して、バックアップ計画の基礎となるデータファイル・コピーのタグを識別します。RMANは、このコピーのレベル1のバックアップすべてに自動的に同じタグを割り当てます。

指定したタグが付けられたデータファイル・コピーが現行または親のデータベース・インカネーションに存在しない場合は、指定したタグが付けられたレベル0のデータファイル・コピーがRMANによって作成されます。

BACKUP
INCREMENTAL LEVEL 1
FOR RECOVER OF COPY
WITH TAG 'incr_update'
DATABASE;

FOR RECOVER OF COPY DATAFILECOPY FORMAT 'format'

データファイル・コピーがない場合は、RMANがコピーを作成する場所を指定します。データベースに新しいデータファイルを追加すると、RMANが増分バックアップ・ルーチンに必要なレベル0のコピーを自動的に作成するため、スクリプトを変更する必要がありません。

BACKUP
INCREMENTAL LEVEL 1
FOR RECOVER OF COPY
DATAFILECOPY FORMAT
'/disk2/df1.cpy'
DATABASE;

増分更新バックアップ計画を実装する手順

1. RMANを起動し、ターゲット・データベースに接続します。

2. RECOVER COPYおよびBACKUP INCREMENTALコマンドを実行します。
増分更新バックアップに基づく計画を実装するには、次のスクリプトを定期的に実行する必要があります。

RECOVER COPY OF DATABASE
WITH TAG 'incr_update';
BACKUP
INCREMENTAL LEVEL 1
FOR RECOVER OF COPY WITH TAG 'incr_update'
DATABASE;

関連項目:
「増分更新バックアップ」

データベース・ファイルおよびバックアップの検証

VALIDATEコマンドを使用すると、すべてのデータベース・ファイルが適切な場所に存在しており、物理的に破損していないかどうかを確認できます。CHECK LOGICALオプションを指定すると、論理ブロックの破損も確認できます。

データベース・ファイルを検証する手順

1. RMANを起動し、ターゲット・データベースに接続します。

2. 目的のファイルに対してBACKUP VALIDATE ...コマンドを実行します。
たとえば、すべてのデータベース・ファイルおよびアーカイブREDOログ・ファイルの物理的および論理的な破損を検証するには、次のコマンドを入力します。

BACKUP VALIDATE CHECK LOGICAL
DATABASE ARCHIVELOG ALL;

次の例に示すように、VALIDATEコマンドを使用すると、個々のデータ・ブロックを検証することもできます。

VALIDATE DATAFILE 4 BLOCK 10 TO 13;

次の例に示すように、バックアップ・セットを検証することもできます。

VALIDATE BACKUPSET 3;

バックアップ・セットの指定には、LIST BACKUPコマンドの出力に表示されるプライマリ・キーを使用します。

関連項目:

- 第16章「データベース・ファイルおよびバックアップの検証」

- VALIDATEコマンドの構文およびセマンティクスについては、『Oracle Databaseバックアップおよびリカバリ・リファレンス』を参照してください。

RMAN操作のスクリプト化

RMANでは、週次バックアップなどの繰り返し行うタスクを管理するためのコマンド・ファイルを使用できます。コマンド・ファイルとは、RMANプロンプトで入力するRMANコマンドと同じコマンドが含まれているクライアント側のテキスト・ファイルのことです。任意のファイル拡張子を指定できます。RUNコマンドを使用すると、スクリプト内の処理のフローをある程度制御できます。

コマンド・ファイルを作成して実行する手順

1. テキスト・エディタを使用してコマンド・ファイルを作成します。
たとえば、次の内容でコマンド・ファイルを作成します。

# my_command_file.txt
CONNECT TARGET /
BACKUP DATABASE PLUS ARCHIVELOG;
LIST BACKUP;
EXIT;

2. RMANを起動して、RMANプロンプトで@コマンドを実行することによってコマンド・ファイルの内容を実行します。

% rman
RMAN> @/my_dir/my_command_file.txt  # runs specified command file

次に示すように、実行するコマンド・ファイルを使用してRMANを起動することもできます。

% rman @/my_dir/my_command_file.txt

関連項目:
コマンド・ファイルの詳細は「RMANでのコマンド・ファイルの使用」、コマンド・ファイルで置換変数を使用して実行時にパラメータを渡す方法は「コマンド・ファイルでの置換変数の使用」を参照してください。

RMAN操作に関するレポート

RMANのLISTおよびREPORTコマンドでは、RMANのリポジトリに基づいて、バックアップ・アクティビティに関するレポートを生成します。SHOW ALLコマンドを使用すると、RMANの現行の構成が表示されます。

バックアップの表示

リポジトリに含まれているバックアップおよびデータファイル・コピーに関する情報を表示するには、LIST BACKUPおよびLIST COPYコマンドを実行します。バックアップに対しては、表2-3および表2-4に示すオプションを使用して、LISTの出力形式を制御できます。

表2-3 バックアップ用のLISTオプション

オプション

例

説明

BY BACKUP

LIST BACKUP OF DATABASE BY BACKUP

バックアップ・セットごとに出力を編成します。これがデフォルトの表示モードです。

BY FILE

LIST BACKUP BY FILE

バックアップされたファイルに従ってバックアップを表示します。

SUMMARY

LIST BACKUP SUMMARY

サマリー出力を表示します。

バックアップおよびコピーの両方に、表2-4に示す追加オプションがあります。

表2-4 追加のLISTオプション

オプション

例

説明

EXPIRED

LIST EXPIRED COPY

RMANリポジトリに記録されているが、前回のCROSSCHECKコマンドの実行時にディスクまたはテープ上の適切な場所に存在していなかったバックアップを表示します。期限切れのバックアップは、オペレーティング・システムのユーティリティによって削除された可能性があります。

RECOVERABLE

LIST BACKUP RECOVERABLE

RMANリポジトリのステータスがAVAILABLEであり、リストアおよびリカバリも行うことができるデータファイルのバックアップまたはコピーを表示します。

バックアップおよびコピーを表示する手順

1. RMANを起動し、ターゲット・データベースに接続します。

2. RMANプロンプトで、LISTコマンドを実行します。
次の例に示すように、特定のオブジェクトを表示できます。

LIST BACKUP OF DATABASE;
LIST COPY OF DATAFILE 1, 2;
LIST BACKUP OF ARCHIVELOG FROM SEQUENCE 10;
LIST BACKUPSET OF DATAFILE 1;

関連項目:

- LISTコマンドの詳細は、「バックアップおよびリカバリ関連オブジェクトの表示」を参照してください。

- LISTコマンドの構文については、『Oracle Databaseバックアップおよびリカバリ・リファレンス』を参照してください。

データベース・ファイルおよびバックアップに関するレポート

REPORTコマンドは、LISTより複雑な分析を実行します。表2-5に、主なオプションの一部を示します。

表2-5 REPORTのオプション

オプション

例

説明

NEED BACKUP

REPORT NEED BACKUP DATABASE

現行の保存方針に従ってバックアップする必要があるファイルを表示します。オプションのREDUNDANCYおよびRECOVERY WINDOWパラメータを使用して、様々な条件を指定します。

OBSOLETE

REPORT OBSOLETE

構成済のバックアップの保存方針に従って不要となっているバックアップを表示します。オプションのREDUNDANCYおよびRECOVERY WINDOWパラメータを使用して、デフォルトを上書きします。

SCHEMA

REPORT SCHEMA

現時点(デフォルト)または別の時点でデータベースにある表領域とデータファイルをレポートします。

UNRECOVERABLE

REPORT UNRECOVERABLE

データファイルの前回のバックアップ以降に、データファイル内のオブジェクトに対してリカバリ不能な操作が実行されているすべてのデータファイルを表示します。

データベース・ファイルおよびバックアップのレポートを生成する手順

1. RMANを起動し、ターゲット・データベースに接続します。

2. RMANプロンプトで、REPORTコマンドを実行します。
次の例では、現在構成されているバックアップ保存方針に従って不要となったバックアップをレポートします。

REPORT OBSOLETE;

次の例では、データベースのデータファイルおよび一時ファイルをレポートします。

REPORT SCHEMA;

関連項目:
RMANのレポートにREPORTコマンドを使用する方法は、「バックアップおよびデータベース・スキーマに関するレポート」を参照してください。

RMANバックアップの保持

RMANリポジトリ・メタデータは、ターゲット・データベースの制御ファイルに常に格納されます。このメタデータは、バックアップの管理時にRMANのメンテナンス・コマンドで使用されます。

バックアップのクロスチェック

CROSSCHECKコマンドでは、RMANバックアップおよびコピーの論理レコードをストレージ・メディアのファイルと同期化します。バックアップがディスク上に存在する場合は、CROSSCHECKによって、そのファイルのヘッダーが有効かどうかが判別されます。バックアップがテープ上に存在する場合は、RMANによって、バックアップ・ピースの名前と場所の問合せがRMANリポジトリに対して実行されます。この場合、バックアップおよびコピーは、クロスチェックしてから削除することをお薦めします。

ディスク上のすべてのバックアップおよびコピーをクロスチェックする手順

1. RMANを起動し、ターゲット・データベースに接続します。

2. 次の例に示すように、CROSSCHECKコマンドを実行します。

CROSSCHECK BACKUP;
CROSSCHECK COPY;

関連項目:
RMANバックアップをクロスチェックする方法については、「RMANリポジトリのクロスチェック」を参照してください。

不要なバックアップの削除

DELETEコマンドでは、ディスクおよびテープからRMANのバックアップおよびコピーを削除し、制御ファイル・リポジトリ内のファイルのステータスをDELETEDに更新し、リカバリ・カタログからレコードを削除します(カタログを使用している場合)。RMANを対話形式で実行し、NOPROMPTオプションを指定しなかった場合は、DELETEによってファイルのリストが表示され、リスト内のファイルを削除する前に確認を求められます。

RMANリポジトリに記録されているバックアップおよびデータファイルのコピーのうち不要なものが削除されるため、DELETE OBSOLETEコマンドは特に役に立ちます。DELETEコマンドでオプションを使用して不要なものを指定するか、または構成済のバックアップの保存方針を使用することができます。

不要なバックアップおよびコピーを削除する手順

1. RMANを起動し、ターゲット・データベースに接続します。

2. 次の例に示すように、DELETE OBSOLETEコマンドを実行します。

DELETE OBSOLETE;

関連項目:
DELETEコマンドの使用方法については、「RMANバックアップおよびアーカイブREDOログの削除」を参照してください。

データ・リカバリ・アドバイザを使用した障害の診断および修復

データベースに関する問題を診断して修復する最も簡単な方法は、データ・リカバリ・アドバイザを使用する方法です。このOracle Databaseツールによって、永続的なデータの障害を診断し、ユーザーに修復オプションを提示して、修復を自動的に実行するインフラストラクチャが提供されます。

関連項目:
「データ・リカバリ・アドバイザの概要」

障害の表示および修復オプションの決定

障害とは、状態モニターによって検出される永続的なデータの破損のことです。例としては、物理的および論理的なデータ・ブロックの破損やデータファイルの欠落などがあります。各障害には、障害優先順位および障害ステータスがあります。優先順位は、CRITICAL、HIGHまたはLOWのいずれかになります。ステータスは、OPENまたはCLOSEDのいずれかになります。

LIST FAILUREコマンドを実行すると、すべての既知の障害を表示できます。障害が存在する場合は、同じセッションでADVISE FAILUREコマンドを実行し、手動および自動の修復オプションを決定します。次に、これらの2つのコマンドの例を示します(出力例も示します)。

例2-1 LIST FAILUREおよびADVISE FAILURE

RMAN> LIST FAILURE;

List of Database Failures
=========================

Failure ID Priority Status    Time Detected Summary
---------- -------- --------- ------------- -------
142        HIGH     OPEN      23-APR-07     One or more non-system datafiles are missing
101        HIGH     OPEN      23-APR-07     Datafile 1: '/disk1/oradata/prod/system01.dbf'
contains one or more corrupt blocks

RMAN> ADVISE FAILURE;

List of Database Failures
=========================

Failure ID Priority Status    Time Detected Summary
---------- -------- --------- ------------- -------
142        HIGH     OPEN      23-APR-07     One or more non-system datafiles are missing
101        HIGH     OPEN      23-APR-07     Datafile 1: '/disk1/oradata/prod/system01.dbf'
contains one or more corrupt blocks

analyzing automatic repair options; this may take some time
using channel ORA_DISK_1
analyzing automatic repair options complete

Mandatory Manual Actions
========================
no manual actions available

Optional Manual Actions
=======================
1. If file /disk1/oradata/prod/users01.dbf was unintentionally renamed or moved, restore it

Automated Repair Options
========================
Option Repair Description
------ ------------------
1      Restore and recover datafile 28; Perform block media recovery of
block 56416 in file 1
Strategy: The repair includes complete media recovery with no data loss
Repair script: /disk1/oracle/log/diag/rdbms/prod/prod/hm/reco_660500184.hm

ADVISE FAILUREの出力には、手動および自動の両方の修復オプションが示されています。まず、手動での問題の解決を試行します。問題を手動で解決できない場合は、自動修復に関するセクションを参照してください。

自動修復オプションには、1つ以上の障害に関するサーバー管理の修復が記載されています。修復は、可能な場合は統合されているため、1回の修復で複数の障害を解決できます。修復オプションには、実行する修復およびその修復操作の実行によってデータが失われるかどうかが示されます。

例2-1の出力には、RMANコマンドが含まれている修復スクリプトのファイル名が示されています。データ・リカバリ・アドバイザを使用して障害を自動的に修復しない場合は、このスクリプトをリカバリ計画の基礎として使用します。

関連項目:
「障害の表示」および「修復オプションの決定」を参照してください。

障害の修復

RMANセッションでLIST FAILUREおよびADVISE FAILUREを実行した後、REPAIR FAILUREを実行して修復オプションを実行できます。他のコマンド・オプションを指定せずにREPAIR FAILUREを実行すると、RMANは、現在のセッションで最新のADVISE FAILUREコマンドの最初の修復オプションを使用します。最新のADVISE FAILUREコマンドで取得した修復オプション番号を指定することもできます。例2-2に、例2-1で検出された障害の修復方法を示します。

例2-2 REPAIR FAILURE

RMAN> REPAIR FAILURE;

デフォルトでは、REPAIR FAILUREの実行を開始する前に確認を求められます。修復を実行した後、データ・リカバリ・アドバイザは、障害が修復されている可能性に関してすべての既存の障害を再評価します。データ・リカバリ・アドバイザは、障害が存在しているかどうかを常に確認し、修復されている障害を自動的にクローズします。エラーのため修復を完了できなかった場合は、そのエラーが原因で新しい評価が実行され、既存の障害および修復が再評価されます。

関連項目:
「障害の修復」

フラッシュバック・データベースを使用したデータベースの巻戻し

Oracle Flashback Databaseを使用すると、データベース全体を過去の時点に巻き戻すことができます。メディア・リカバリとは異なり、データファイルをリストアしてデータベースを過去の状態に戻す必要はありません。

RMANのFLASHBACK DATABASEコマンドを使用するには、フラッシュバック・ログが生成されるように、データベースを事前に構成しておく必要があります。この構成タスクの詳細は、「フラッシュバック・データベース」を参照してください。フラッシュバック・データベースによって、コマンドの実行時に存在しているデータファイルに対する変更が巻き戻されます。このコマンドを使用してメディア障害またはデータファイルの欠落を修復することはできません。

FLASHBACK DATABASEを発行する場合は、データベースがマウントされている必要があります。以前に作成したリストア・ポイントがフラッシュバック・データベース・ウィンドウ内にある場合は、そのリストア・ポイントにフラッシュバックできます。

フラッシュバック・データベースを使用してデータベースを巻き戻す手順

1. RMANを起動し、ターゲット・データベースに接続します。

2. データベースがマウント状態であることを確認します。
次のコマンドを実行して、データベースを停止してからマウントします。

SHUTDOWN IMMEDIATE;
STARTUP MOUNT;

3. FLASHBACK DATABASEコマンドを実行します。
次の例は、このコマンドの様々な形式を示しています。

FLASHBACK DATABASE TO SCN 861150;

FLASHBACK DATABASE
TO RESTORE POINT BEFORE_CHANGES;

FLASHBACK DATABASE
TO TIMESTAMP TO_DATE(04-DEC-2009  03:30:00','DD-MON-YYYY HH24:MI:SS');

4. フラッシュバック・データベースを実行した後、SQL*Plusを使用してデータベースを読取り専用でオープンし、いくつかの問合せを実行して、データベースの内容を検証します。
次のように入力して、データベースを読取り専用でオープンします。

SQL "ALTER DATABASE OPEN READ ONLY";

5. 結果が適切である場合は、次の一連のコマンドを実行してデータベースを停止してからオープンできます。

SHUTDOWN IMMEDIATE;
STARTUP MOUNT;
ALTER DATABASE OPEN RESETLOGS;

関連項目:
「フラッシュバック・データベースを使用したデータベースの巻戻し」

データベース・ファイルのリストアおよびリカバリ

物理データベース・ファイルをRMANでリストアおよびリカバリするには、RESTOREおよびRECOVERコマンドを使用します。データファイルをリストアすると、バックアップからリカバリ操作に必要なデータファイルが取得されます。メディア・リカバリは、リストアしたデータファイルにREDOログおよび増分バックアップに含まれている変更を適用して、データファイルを目的のSCNまたは目標時点の状態にします。

関連項目:
第17章「データベースの完全リカバリの実行」

データベース・ファイルのリストアおよびリカバリの準備

メディア障害によってデータベース・ファイルが破損したため、データベースをリカバリする必要がある場合は、必要なバックアップがあることを最初に確認する必要があります。RESTORE ... PREVIEWコマンドを使用すると、指定した時点にリストアするためにRMANで使用可能なバックアップをレポートすることはできますが、リストアすることはできません。RMANは、メタデータは問い合せますが、実際にバックアップ・ファイルは読み取りません。このコマンドは、データベースをオープンしているときにも実行できます。

データベースのリストアおよびリカバリを確認する手順

1. RMANを起動し、ターゲット・データベースに接続します。

2. 必要に応じて、次のコマンドで示すように、現行の表領域およびデータファイルを表示します。

RMAN> REPORT SCHEMA;

3. PREVIEWオプションを指定してRESTORE DATABASEコマンドを実行します。
次のコマンドでは、バックアップのメタデータが冗長モードで表示されないようにSUMMARYを指定します(出力例も示します)。

RMAN> RESTORE DATABASE PREVIEW SUMMARY;

Starting restore at 21-MAY-07
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=80 device type=DISK

List of Backups
===============
Key     TY LV S Device Type Completion Time #Pieces #Copies Compressed Tag
------- -- -- - ----------- --------------- ------- ------- ---------- ---
11      B  F  A DISK        18-MAY-07       1       2       NO         TAG20070518T181114
13      B  F  A DISK        18-MAY-07       1       2       NO         TAG20070518T181114
using channel ORA_DISK_1

List of Archived Log Copies for database with db_unique_name PROD
=====================================================================

Key     Thrd Seq     S Low Time
------- ---- ------- - ---------
47      1    18      A 18-MAY-07
Name: /disk1/oracle/dbs/db1r_60ffa882_1_18_0622902157.arc

Media recovery start SCN is 586534
Recovery must be done beyond SCN 587194 to clear datafile fuzziness
validation succeeded for backup piece
Finished restore at 21-MAY-07

データベース全体のリカバリ

データベース全体をリカバリするには、RESTORE DATABASEおよびRECOVER DATABASEコマンドを使用します。必要なすべてのファイルのバックアップを事前に作成しておく必要があります。このシナリオでは、すべてのデータファイルを元の場所にリストアできることを想定しています。元の場所にアクセスできない場合は、「デフォルト以外の場所へのデータファイルのリストア」の説明に従ってSET NEWNAMEコマンドを使用します。

データベース全体をリカバリする手順

1. 「データベース・ファイルのリストアおよびリカバリの準備」の説明に従ってリカバリを準備します。

2. データベースをマウント状態にします。
次の例では、(起動されている場合は)データベース・インスタンスを終了し、データベースをマウントします。

RMAN> STARTUP FORCE MOUNT;

3. データベースをリストアします。
次の例では、事前構成されたディスク・チャネルを使用して、データベースをリストアします。

RMAN> RESTORE DATABASE;

4. 次の例に示すように、データベースをリカバリします。

RMAN> RECOVER DATABASE;

5. 次の例に示すように、データベースをオープンします。

RMAN> ALTER DATABASE OPEN;

表領域のリカバリ

データベースがオープンされている場合は、個々の表領域に対してRESTORE TABLESPACEおよびRECOVER TABLESPACEコマンドを使用します。この場合、リカバリが必要な表領域をオフラインにしてリストアし、表領域をリカバリしてからオンラインに戻す必要があります。

データファイルを新しい場所にリストアする必要がある場合は、RMANのSET NEWNAMEコマンドをRUNコマンド内で使用して、新しいファイル名を指定します。その後、SQL文のALTER DATABASE RENAME FILEと同等のSWITCH DATAFILE ALLコマンドを使用して制御ファイルを更新し、RUNコマンドでSET NEWNAMEが発行されたすべてのデータファイルの新しい名前を反映します。

ユーザー管理のメディア・リカバリとは異なり、オンラインの表領域をバックアップ・モードにする必要はありません。ユーザー管理ツールとは異なり、RMANでは、データ・ブロックの形式が認識されるため、追加のロギングまたはバックアップが必要ありません。

データベースがオープンされている場合に個々の表領域をリカバリする手順

1. 「データベース・ファイルのリストアおよびリカバリの準備」の説明に従ってリカバリを準備します。

2. リカバリする表領域をオフラインにします。
USERS表領域をオフラインにするには、次のように入力します。

RMAN> SQL 'ALTER TABLESPACE users OFFLINE';

3. 表領域をリストアおよびリカバリします。
RMANプロンプトで次のRUNコマンドを実行すると、USERS表領域にデータファイルの新しい名前が設定されます。

RUN
{
SET NEWNAME FOR DATAFILE '/disk1/oradata/prod/users01.dbf'
TO '/disk2/users01.dbf';
RESTORE TABLESPACE users;
SWITCH DATAFILE ALL;   # update control file with new file names
RECOVER TABLESPACE users;
}

4. 次の例に示すように、データベースをオンラインにします。

RMAN> SQL 'ALTER TABLESPACE users ONLINE';

データファイル・レベルのリカバリには、RESTORE DATAFILEおよびRECOVER DATAFILEを使用することもできます。

関連項目:

- 「表領域の完全リカバリの実行」

- 「オンライン・バックアップおよびバックアップ・モード」

個々のデータ・ブロックのリカバリ

RMANは、破損した個々のデータファイル・ブロックをリカバリできます。RMANがバックアップ用のファイルの完全なスキャンを実行する場合、破損したすべてのブロックが V$DATABASE_BLOCK_CORRUPTIONに表示されます。通常、破損は、アラート・ログ、トレース・ファイルまたはSQL問合せの結果に記録されます。

データ・ブロックをリカバリする手順

1. 破損したブロックのブロック番号がわからない場合は、これらの番号を取得します。
トレース・ファイルおよびアラート・ログを検索する最も簡単な方法は、SQL*Plusをターゲット・データベースに接続し、次の問合せを実行する方法です。

SQL> SELECT NAME, VALUE
2  FROM V$DIAG_INFO;

2. RMANを起動し、ターゲット・データベースに接続します。

3. RECOVERコマンドを実行してブロックを修復します。
次のRMANコマンドによって、破損したすべてのブロックがリカバリされます。

RMAN> RECOVER CORRUPTION LIST;

次の例に示すように、個々のブロックをリカバリすることもできます。

RMAN> RECOVER DATAFILE 1 BLOCK 233, 235 DATAFILE 2 BLOCK 100 TO 200;

関連項目:
第19章「ブロック・メディア・リカバリの実行」

第II部

RMANとフラッシュバック・データベースの起動および構成

この部の章では、RMAN環境の基本的な構成要素およびその構成方法について説明します。この部に含まれる章は、次のとおりです。

- 第3章「Recovery Managerのアーキテクチャ」

- 第4章「RMANクライアントの起動および操作」

- 第5章「RMAN環境の構成」

- 第6章「RMAN環境の構成: 高度なトピック」

- 第7章「フラッシュバック・データベースおよびリストア・ポイントの使用」

3 Recovery Managerのアーキテクチャ

この章では、Recovery Manager (RMAN)のインタフェースおよびRMAN環境の基本的な構成要素について説明します。この章の内容は次のとおりです。

- RMAN環境

- RMANコマンドライン・クライアント

- RMANチャネル

- RMANリポジトリ

- メディア管理

- 高速リカバリ領域

- Data Guard環境でのRMAN

RMAN環境

Recovery Manager環境は、バックアップおよびリカバリ計画で使用される様々なアプリケーションおよびデータベースから構成されます。

表3-1に、通常のRMAN環境の構成要素の一部を示します。

表3-1 RMAN環境の構成要素

構成要素

説明

RMANクライアント

ターゲット・データベースに対するバックアップおよびリカバリ操作を管理するクライアント・アプリケーション。RMANクライアントは、Oracle Netを使用してターゲット・データベースに接続できるため、Oracle Netを介してターゲット・ホストに接続された任意のホスト上に配置できます。

ターゲット・データベース

RMANによってバックアップまたはリストアされる制御ファイル、データファイルおよびオプションのアーカイブREDOログが含まれているデータベース。RMANは、ターゲット・データベースの制御ファイルを使用して、ターゲット・データベースに関するメタデータを収集します。また、RMANの操作に関する情報は、制御ファイルに格納されます。バックアップおよびリカバリ操作は、ターゲット・データベース上で動作するサーバー・セッションによって実行されます。

リカバリ・カタログ・データベース

リカバリ・カタログが含まれているデータベース。バックアップおよびリカバリを実行するためにRMANで使用されるメタデータが含まれています。複数のターゲット・データベースのRMANメタデータが含まれている1つのリカバリ・カタログを作成することができます。RMANをフィジカル・スタンバイ・データベースで使用しないかぎり、RMAN使用時のリカバリ・カタログはオプションです。RMANでは、メタデータが各ターゲット・データベースの制御ファイルに格納されるためです。

リカバリ・カタログ・スキーマ

リカバリ・カタログ・データベース内のユーザー。RMANによってメンテナンスされるメタデータ表を所有します。RMANは、定期的に、ターゲット・データベースの制御ファイルからリカバリ・カタログにメタデータを伝播します。

フィジカル・スタンバイ・データベース

プライマリ・データベースのコピー。プライマリ・データベースによって作成されたアーカイブREDOログを使用して更新されます。フィジカル・スタンバイ・データベースのDBIDおよびDB_NAME値はプライマリ・データベースと同じですが、DB_UNIQUE_NAMEは異なります。プライマリ・データベースにアクセスできなくなった場合、スタンバイ・データベースにフェイルオーバーできます。

スタンバイ・データベースは、RMANを使用して作成、バックアップまたはリカバリできます。スタンバイ・データベースで作成したバックアップは、同じ本番データベースのプライマリ・データベースまたは別のスタンバイ・データベースでも使用できます。Data Guard環境でRMANを使用する場合は、リカバリ・カタログが必要です。

注意: RMANでは、ロジカル・スタンバイ・データベースは別のデータベースとして処理されます。プライマリ・データベースとはDBIDが異なるためです。

参照:Data Guard環境でのRMANの使用方法については、『Oracle Data Guard概要および管理』を参照してください。

複製データベース

テスト目的で使用するプライマリ・データベースのコピー。コピー元のデータベースとはDBIDが異なります。

高速リカバリ領域

制御ファイルのコピー、オンラインREDOログのコピー、アーカイブREDOログ、フラッシュバック・ログ、RMANバックアップなどのリカバリ関連ファイルの格納のために使用可能なディスクの場所。高速リカバリ領域内のファイルは、Oracle DatabaseおよびRMANによって自動的に管理されます。

メディア・マネージャ

RMANでストレージ・システム(テープなど)へのバックアップを実行するための、ベンダー固有のアプリケーション

メディア管理カタログ

メディア管理アプリケーションについてのメタデータを格納するベンダー固有のリポジトリ

Oracle Enterprise Manager

データベースに対するブラウザベースのインタフェース(RMANによるバックアップおよびリカバリにも使用できます)

RMAN環境に必須の構成要素は、ターゲット・データベースおよびRMANクライアントのみですが、実際の構成はより複雑です。たとえば、複数のメディア・マネージャに接続しているRMANクライアント、複数のターゲット・データベースおよび複数の補助データベースが存在し、それらがすべてEnterprise Managerを介してアクセスされる環境を構成します。

図3-1に、RMAN環境での構成要素の例を示します。この例では、プライマリ・データベース、スタンバイ・データベースおよびリカバリ・カタログ・データベースがすべて別々のコンピュータ上に配置されています。プライマリ・データベースおよびスタンバイ・データベースのホストでは、ローカル接続されたテープ・ドライブが使用されます。RMANクライアントおよびEnterprise Managerコンソールは、別のコンピュータ上で実行されます。

図3-1 RMAN環境の例

関連項目:
Oracle Netの詳細は、『Oracle Database Net Services管理者ガイド』を参照してください。

RMANコマンドライン・クライアント

RMANコマンドライン・クライアントを使用すると、バックアップおよびリカバリ操作を詳細に管理するためのコマンドを入力できます。RMANは、コマンドを対話モードまたはバッチ・モードで実行できるコマンド言語インタプリタを使用します。RMANの上位に構築されたEnterprise Managerでバックアップおよびリカバリ機能を使用している場合でも、RMANクライアントがバックグラウンドで実行されています。

RMANチャネル

RMANクライアントは、データベース・サーバー・セッションに、すべてのバックアップおよびリカバリ作業を実行するように指示します。セッションの構成は、オペレーティング・システムによって異なります。たとえば、Linuxでは、サーバー・セッションはサーバー・プロセスに対応しますが、Windowsでは、データベース・サービス内のスレッドに対応します。

RMANクライアント自体は、バックアップ、リストアまたはリカバリ操作を実行しません。RMANクライアントをターゲット・データベースに接続すると、RMANは、サーバー・セッションをターゲット・インスタンスに割り当て、操作を実行するようにサーバー・セッションに指示します。

RMANのチャネルは、デバイス・タイプに対する1つのデータ・ストリームであり、1つのデータベース・サーバー・セッションに対応します。チャネルは、データをPGAメモリーに読み取り、処理して出力デバイスに書き込みます。チャネルの基本的な動作については、「RMANのパフォーマンスのチューニングの基本的な概念」を参照してください。

大部分のRMANコマンドはチャネルによって実行されます。チャネルは、RMANセッション間にわたって保持されるように構成するか、または手動で各RMANセッションに割り当てる必要があります。図3-2に示すように、チャネルは、ターゲット・データベースまたは補助データベースのインスタンス上でサーバー・セッションを開始することによって、RMANクライアントからそれらのインスタンスへの接続を確立します。

図3-2 チャネルの割当て

チャネルおよびデバイス

RMANでサポートされているデバイス・タイプは、ディスクおよびSBT(テープへのシステム・バックアップ)です。SBTデバイスは、サード・パーティのメディア・マネージャによって制御されます。通常、SBTデバイスはテープ・ライブラリおよびテープ・ドライブです。

バックアップにディスク・チャネルを使用すると、チャネルによって、ディスク上の、バックアップを作成しているターゲット・データベース・インスタンスのファイル名領域にバックアップが作成されます。バックアップは、データファイルを格納できる任意のデバイスに作成できます。RMANは、ディスク・バックアップの作成時にメディア・マネージャをコールしません。

ディスク以外のメディアにバックアップを作成するには、Oracle Secure Backupなどのメディア管理ソフトウェアを使用して、このソフトウェアでサポートされるチャネルを割り当てる必要があります。RMANは、割り当てられたチャネル・タイプがディスクでない場合は常にメディア・マネージャと通信します。SBTチャネルを使用した場合にメディア・マネージャがリソースを割り当てる方法およびタイミングは、ベンダーによって異なります。コマンドが発行された時点でリソースを割り当てるメディア・マネージャや、読取り用または書込み用にファイルをオープンしてからリソースを割り当てるメディア・マネージャがあります。

関連項目:
「バックアップ用のデフォルト・デバイスの構成: ディスクまたはSBT」

自動チャネルおよび手動チャネル

CONFIGURE CHANNELコマンドを使用して、複数のRMANセッションでディスクまたはテープ用に使用するチャネルを構成できます。この方法は、自動チャネル割当てと呼ばれます。RMANでは、ディスクへのバックアップに使用できるDISKチャネルが1つ、事前に構成されています。

自動チャネルを使用できるコマンドを実行すると、RMANによって、CONFIGUREコマンドで指定したオプションに基づいてチャネルが自動的に割り当てられます。BACKUPコマンドの場合は、指定したメディアにバックアップするために必要なチャネルのタイプのみがRMANにより割り当てられます。RESTOREコマンドおよびRMANのメンテナンス・コマンドの場合は、コマンドを実行するために必要なデバイス・タイプ用の必要なすべてのチャネルが割り当てられます。自動チャネル用の名前は、RMANによって決定されます。

また、チャネルを手動で割り当てることもできます。手動で割り当てられた各チャネルは、データベースに個別に接続します。手動でチャネルを割り当てる場合は、dev1、ch2などのユーザー定義の名前を指定します。

コマンドの実行時にデバイスで使用できるチャネルの数によって、コマンドの実行中にRMANがこのデバイスに対する読取りまたは書込みをパラレルに行うかどうかが決まります。処理がパラレルで行われる場合、ファイルのバックアップが複数のチャネルで実行されます。各チャネルで複数のファイルをバックアップできますが、マルチセクション・バックアップを実行しないかぎり、ファイルは複数のチャネルでバックアップされません。

関連項目:

- ALLOCATE CHANNELの構文については、『Oracle Databaseバックアップおよびリカバリ・リファレンス』を参照してください。

- ALLOCATE CHANNEL FOR MAINTENANCEについては、『Oracle Databaseバックアップおよびリカバリ・リファレンス』を参照してください。

- 「ディスクのチャネルの構成」および「メディア・マネージャで使用するSBTチャネルの構成」を参照してください。

RMANリポジトリ

RMANリポジトリは、RMANがバックアップ、リカバリおよびメンテナンスに使用する、ターゲット・データベースに関するメタデータのコレクションです。RMANは常にそのメタデータを制御ファイルに格納します。制御ファイル内のこのメタデータは、データベースのRMANバックアップに関する正式なレコードです。このため、制御ファイルの保護は、バックアップ計画において重要です。RMANは、RMANリポジトリ情報を格納した制御ファイルのみを使用して、必要なすべてのバックアップおよびリカバリ操作を実行することができ、構成された保存方針を満たすために必要なすべてのレコードをメンテナンスします。

また、リカバリ・カタログも作成できます。リカバリ・カタログは、Oracle Databaseスキーマに格納されるRMANメタデータのリポジトリです。制御ファイルにバックアップ・アクティビティを記録する場合は領域に制限がありますが、リカバリ・カタログにはより長期の履歴を格納できます。すべてのデータベースのRMANメタデータが含まれているリカバリ・カタログを1つ作成することによって、バックアップおよびリカバリを簡単に管理できます。

リカバリ・カタログの所有者は、他のデータベース・ユーザーに対してカタログへの制限つきアクセス権の付与および取消しを行うことができます。制限付きユーザーは、それぞれ仮想プライベート・カタログと呼ばれる独自のメタデータへの完全な読取り/書込み権限を持っています。データベースに1つ以上の仮想プライベート・カタログが存在する場合、そのデータベースには1セットのカタログ表が含まれています。これらの表は、ベース・リカバリ・カタログの所有者によって所有されています。ベース・リカバリ・カタログの所有者は、各仮想プライベート・カタログ・ユーザーがアクセスできるデータベースを制御します。

一部のRMAN機能は、リカバリ・カタログを使用している場合にのみ機能します。たとえば、リカバリ・カタログにストアド・スクリプトを作成し、このスクリプトでRMANジョブを実行できます。それ以外のRMANコマンドが、特にリカバリ・カタログの管理に関連している場合もあります。これらのコマンドは、RMANがリカバリ・カタログに接続されていない場合は使用できません(また、使用する必要はありません)。

リカバリ・カタログは、RMANによってのみメンテナンスされます。ターゲット・データベース・インスタンスがカタログに直接アクセスすることはありません。RMANは、リポジトリを更新するなんらかの操作が終了した後、および特定の操作が行われる前に、データベース構造についての情報、アーカイブREDOログ、バックアップ・セット、およびデータファイルのコピーを、ターゲット・データベースの制御ファイルからリカバリ・カタログに伝播します。

関連項目:
第12章「RMANバックアップおよびリポジトリ・レコードのメンテナンス」および第13章「リカバリ・カタログの管理」を参照してください。

メディア管理

オラクル社提供のメディア管理レイヤー(MML)APIを使用すると、サード・パーティ・ベンダーはメディア・マネージャを構築できます。メディア・マネージャとは、RMANとともにベンダーのハードウェアで動作し、シーケンシャル・メディア・デバイス(テープ・ドライブなど)へのバックアップを可能にするソフトウェアです。メディア・マネージャは、テープなどのシーケンシャル・メディアのロード、アンロードおよびラベル付けを処理します。シーケンシャル・メディア・デバイスでRMANを使用するには、メディア・マネージャ・ソフトウェアをインストールする必要があります。

バックアップまたはリストア時、RMANクライアントは、ターゲット・データベース・インスタンスに接続して、メディア・マネージャに要求を送信するようにインスタンスに指示します。RMANクライアントとメディア・マネージャが直接通信することはありません。

RMANとメディア・マネージャの相互作用

メディア・マネージャにバックアップまたはリストアを実行する前に、メディア・マネージャとの通信を処理する1つ以上のチャネルを割り当てておく必要があります。メディア・マネージャ用にデフォルトのチャネルも構成できます。デフォルトのチャネルは、メディア・マネージャを使用し、チャネルを明示的に割り当てていないすべてのバックアップおよびリカバリ作業で使用されます。

RMANは、テープのロード、ラベル付けまたはアンロードを行う固有のコマンドを発行しません。バックアップ時、RMANは、メディア・マネージャにバイト・ストリームを渡し、そのストリームに一意の名前を関連付けます。バックアップをリストアする必要がある場合、RMANは、メディア・マネージャにバイト・ストリームの取得を要求します。ストリームの格納方法および格納場所の詳細は、メディア・マネージャによって管理されます。たとえば、メディア・マネージャは、テープおよび各テープ上のファイルの名前をラベル付けして管理し、テープを自動的にロードおよびアンロードしたり、テープをロードおよびアンロードするようにオペレータに通知します。

メディア・マネージャの中には、プロキシ・コピー機能をサポートしているものがあります。この機能を使用すると、メディア・マネージャが、データファイルとバックアップ・デバイス間のデータの移動全体を処理します。 これらの製品では、ストレージ・サブシステムとメディア・サブシステム間で高速接続などの技術を使用して、プライマリ・データベース・サーバーの負荷を軽減している場合があります。RMANは、バックアップまたはリストアが必要なファイルのリストをメディア・マネージャに提供し、メディア・マネージャは、データを移動する方法およびタイミングに関するすべての決定を行います。

関連項目:
「メディア・マネージャで使用するSBTチャネルの構成」

Oracle Secure Backup

Oracle Secure Backupは、ファイル・システムをテープにバックアップすることによって信頼性の高い安全なデータ保護を提供するメディア・マネージャです。SAN、ギガビット・イーサネットおよびSCSI環境のすべての主要なテープ・ドライブおよびライブラリがサポートされています。

Oracle Secure Backupは、データベースのバックアップおよびリカバリのアルゴリズムに関する専用の機能は備えていませんが、SBTインタフェースを介してRMANのメディア管理レイヤーとして機能できます。この機能で、Oracle Secure Backupは、サポートされている他のサード・パーティのSBTライブラリと同じサービスをRMANに提供します。ただし、Oracle Secure Backupは、他のメディア・マネージャにはない機能も備えています。

関連項目:
Oracle Secure Backupの使用方法については、『Oracle Secure Backup管理者ガイド』を参照してください。

Backup Solutions Program

Oracle PartnerNetworkの一部であるOracle Backup Solutions Program(BSP)には、オラクル社のMML仕様に準拠した製品を生産している、メディア・マネージャのベンダーが参加しています。ベンダーのメディア管理製品を、ご使用のプラットフォームで使用できる場合があります。詳細は、Oracleサポート・サービスに連絡して使用可能な製品のリストを入手するか、または各ベンダーに連絡して参加を確認してください。あるいは、次に示すBackup Solutions ProgramのWebサイトにアクセスしてください。

http://www.oracle.com/technetwork/database/features/availability/bsp-088814.html

オラクル社は、RMANとの互換性に関してメディア・マネージャ・ベンダーを認証しているわけではありません。可用性、バージョンの互換性および機能については、オラクル社ではなく、メディア・マネージャ・ベンダーに問い合せてください。

高速リカバリ領域

バックアップおよびリカバリ関連の様々なファイルを作成するコンポーネントは、互いを認識しません。また、それぞれのデータが格納されるファイル・システムのサイズも認識しません。ディスクベースの自動バックアップおよびリカバリでは、高速リカバリ領域(リカバリ領域とも呼ばれる)を作成できます。バックアップ関連のファイルは、高速リカバリ領域によって自動的に管理されます。

高速リカバリ領域を使用すると、バックアップ関連のファイル用のディスク領域の管理および異なるタイプのファイル間での領域使用の均衡化を手動で行う必要性が最小限に抑えられます。このような点から、高速リカバリ領域を使用すると、データベースの継続的な管理が簡単になります。リカバリ領域を有効にしてバックアップ管理を簡単にすることをお薦めします。

リカバリ領域の作成時には、ディスク上の場所を選択し、記憶領域の上限を設定します。また、バックアップ・ファイルがリカバリに必要となる期間を制御するバックアップの保存方針も設定します。データベースは、この領域内で、データベースのバックアップ、アーカイブREDOログおよびその他のリカバリ関連ファイルに使用されるストレージを管理します。不要になったファイルは、RMANが新しいファイル用の領域を要求したときに削除されます。

関連項目:
高速リカバリ領域およびその構成方法については、「高速リカバリ領域の構成」を参照してください。

Data Guard環境でのRMAN

Data Guard環境でRMANを使用する場合は、リカバリ・カタログが必要です。リカバリ・カタログには、すべてのプライマリ・データベースおよびスタンバイ・データベースのメタデータを格納できます。

Data Guard環境のデータベースは、初期化パラメータ・ファイル内のDB_UNIQUE_NAMEパラメータによって一意に識別されます。Data Guard環境でRMANが正しく動作するようにするには、同じDBIDを持つすべてのデータベース間でDB_UNIQUE_NAMEが一意になるようにする必要があります。

関連項目:
Data Guard環境でのRMANの使用方法については、『Oracle Data Guard概要および管理』を参照してください。

Data Guard環境でのRMANの構成

バックアップおよびリカバリでのRMANの継続的な使用を簡単にするには、プライマリ・データベースおよびフィジカル・スタンバイ・データベースのそれぞれにいくつかの永続構成を設定します。これらの設定によって、RMANの動作の様々な点が制御されます。たとえば、バックアップの保存方針、テープまたはディスクへのバックアップのデフォルトの格納先、デフォルトのバックアップ・デバイス・タイプなどを構成できます。

CONFIGUREコマンドでFOR DB_UNIQUE_NAME句を指定すると、スタンバイ・データベースまたはプライマリ・データベースにTARGETとして接続しなくても、Data Guard環境のデータベースの永続的な構成を作成できます。たとえば、RMANをリカバリ・カタログに接続し、SET DBIDコマンドを実行します。その後、フィジカル・スタンバイ・データベースの作成前にその構成を作成できます。これにより、データベースが作成されたときに、RMANの構成が適用されるようになります。

RMANは、TARGETとしてデータベースに接続されている場合、リカバリ・カタログの再同期化中にデータベースの制御ファイルを更新します。ただし、データベースにTARGETとして接続されていない場合、このデータベースに対してFOR DB_UNIQUE_NAMEを使用すると、RMANはリカバリ・カタログ内の構成のみを変更します。

関連項目:
「Data Guard環境でのRMANの構成」

Data Guard環境でのRMANによるファイル管理

RMANは、リカバリ・カタログを使用して、Data Guard環境内のすべてのデータベース・ファイルのファイル名を追跡します。また、カタログには、オンラインREDOログ・ファイル、スタンバイREDOログ・ファイル、一時ファイル、アーカイブREDOログ・ファイル、バックアップ・セットおよびイメージ・コピーが作成される場所も記録されます。

Data Guard環境でのバックアップの互換性

RMANコマンドは、リカバリ・カタログのメタデータを使用して、Data Guard環境内の異なる物理データベース間で透過的に動作します。たとえば、表領域をフィジカル・スタンバイ・データベースにバックアップして、プライマリ・データベースにリストアおよびリカバリすることができます。また、表領域をプライマリ・データベースにバックアップして、フィジカル・スタンバイ・データベースにリストアおよびリカバリすることもできます。

注意:
ロジカル・スタンバイ・データベースのバックアップは、プライマリ・データベースでは使用できません。

スタンバイ制御ファイルのバックアップと非スタンバイ制御ファイルのバックアップには互換性があります。たとえば、スタンバイ制御ファイルをプライマリ・データベースにリストアし、プライマリ制御ファイルをフィジカル・スタンバイ・データベースにリストアできます。この互換性は、制御ファイルのバックアップをData Guard環境の1つのデータベースにオフロードできることを意味します。データベース・ファイルのファイル名は、データベースのリストアおよびリカバリ中にRMANによって自動的に更新されます。

Data Guard環境でのバックアップの関連付け

リカバリ・カタログは、すべてのデータベース・ファイルまたはバックアップ・ファイルをDB_UNIQUE_NAMEに関連付けることによって、Data Guard環境内のファイルを追跡します。ファイルを作成するデータベースは、そのファイルに関連付けられます。たとえば、RMANでstandby1という一意の名前を持つデータベースをバックアップすると、standby1がこのバックアップに関連付けられます。CHANGE ...RESET DB_UNIQUE_NAMEコマンドを使用して、対象のバックアップに別のデータベースを関連付けないかぎり、そのバックアップはそれを作成したデータベースに関連付けられたままになります。

Data Guard環境でのバックアップのアクセシビリティについて

バックアップのアクセシビリティは、その関連付けとは異なります。Data Guard環境では、関連付けられたデータベースのみがディスク・バックアップにアクセスできるとリカバリ・カタログによってみなされますが、1つのデータベースに作成されたテープ・バックアップにはすべてのデータベースがアクセスできます。バックアップ・ファイルがいずれのデータベースにも関連付けられていない場合、リカバリ・カタログ・ビュー内のバックアップ・ファイルに関する行のSITE_KEY列にnullが表示されます。デフォルトでは、RMANは、TARGETとして接続されているデータベースにSITE_KEYがnullのファイルを関連付けます。

BACKUP、RESTORE、CROSSCHECKなどのRMANコマンドは、すべてのアクセス可能なバックアップで動作します。たとえば、RECOVER COPY操作の場合、RMANでは、データベースに関連付けられているイメージ・コピーのみがリカバリの対象とみなされます。RMANでは、ディスクおよびテープ上の増分バックアップが、イメージ・コピーのリカバリ対象とみなされます。データベース・リカバリでは、RMANによって、データベースおよびテープ上のすべてのファイルに対応付けられたディスク・バックアップのみがリストアの対象とみなされます。

バックアップのアクセシビリティの相違点を説明するために、データベースPRODとSTANDBY1が異なるホストに存在していると想定します。RMANは、PROD上のデータファイル1を本番ホスト上の/prmhost/disk1/df1.dbfおよびテープにバックアップします。RMANは、STANDBY1上のデータファイル1をスタンバイ・ホスト上の/sbyhost/disk2/df1.dbfおよびテープにバックアップします。RMANがprodデータベースに接続している場合、RMANコマンドを使用しても、スタンバイ・ホストにある/sbyhost/disk2/df1.dbfバックアップでは操作を実行できません。ただし、RMANでは、STANDBY1で作成されたテープ・バックアップはリストアの対象とみなされます。

注意:
スタンバイ・ホストからプライマリ・ホスト(またはその逆)にバックアップを転送し、対象のホスト上のデータベースにTARGETとして接続した後、CATALOGコマンドを使用してバックアップをカタログに追加できます。ターゲット・データベースによってファイルがカタログに追加されると、そのファイルはターゲット・データベースに関連付けられます。

関連項目:

- Data Guard環境でのRMANバックアップおよびリカバリの実行方法については、『Oracle Data Guard概要および管理』を参照してください。

- 「Data Guard環境でのメンテナンス・コマンド」

- Data Guard環境でのリカバリ・カタログの管理方法については、第13章「リカバリ・カタログの管理」を参照してください。

- CONFIGUREの構文については、『Oracle Databaseバックアップおよびリカバリ・リファレンス』を参照してください。

4 RMANクライアントの起動および操作

この章では、RMANコマンドライン・インタフェースを起動する方法およびデータベースに接続する方法について説明します。この章の内容は次のとおりです。

- RMANの起動および終了

- RMAN出力の場所の指定

- RMANのグローバリゼーション・サポート環境変数の設定

- RMANコマンドの入力

- RMANによるデータベース接続の確立

- RMANのパイプ・インタフェースの使用

RMANの起動および終了

このRMAN実行可能ファイルは、データベースとともに自動的にインストールされ、通常、他のデータベース実行可能ファイルと同じディレクトリに配置されます。たとえば、Linuxの場合、RMANクライアントは$ORACLE_HOME/binに配置されています。RMANを起動する場合、次の基本的なオプションがあります。

- オペレーティング・システムのコマンドラインで、接続オプションを指定せずにRMAN実行可能ファイルを起動します。次に例を示します。

% rman

- ターゲット・データベースおよび(場合によっては)リカバリ・カタログに接続している間に、オペレーティング・システムのコマンドラインでRMAN実行可能ファイルを起動します。次に例を示します。

% rman TARGET /                       # operating system authentication
% rman TARGET SYS@prod NOCATALOG      # RMAN prompts for SYS password
% rman TARGET / CATALOG rco@catdb     # RMAN prompts for rco password

注意:
ほとんどのRMANコマンドでは、有効な作業を実行するためにRMANが1つ以上のターゲット・データベースに接続している必要があります。RMANを様々なタイプのデータベースに接続する方法の詳細は、「RMANによるデータベース接続の確立」を参照してください。

RMANやプログラムを終了するには、RMANプロンプトでEXITまたはQUITと入力します。

RMAN> EXIT

関連項目:
RMANコマンドラインの構文については、『Oracle Databaseバックアップおよびリカバリ・リファレンス』を参照してください。

RMAN出力の場所の指定

デフォルトでは、RMANはコマンド出力を標準出力に書き込みます。出力をログ・ファイルにリダイレクトするには、次の例に示すように、RMANの起動時にコマンドラインでLOGパラメータを入力します。

% rman LOG /tmp/rman.log

この場合、RMANによってコマンド入力は表示されますが、RMAN出力は表示されません。RMAN出力をログ・ファイルと標準出力の両方に送信する場合は、Linuxのteeコマンドまたは同等のコマンドを使用する方法が最も簡単です。たとえば、次の方法で、入力と出力の両方をRMANコマンドライン・インタフェース内に表示できます。

% rman | tee rman.log
RMAN>

関連項目:
RMANコマンドライン・オプションについては、『Oracle Databaseバックアップおよびリカバリ・リファレンス』を参照してください。

RMANのグローバリゼーション・サポート環境変数の設定

RMANを起動する前に、NLS_DATE_FORMATおよびNLS_LANG環境変数を設定すると役立つ場合があります。これらの変数では、RMANのRESTORE、RECOVER、REPORTなどのコマンドの時間パラメータに使用される書式を決定します。

次に、一般的な言語および日付書式の設定例を示します。

NLS_LANG=american
NLS_DATE_FORMAT='Mon DD YYYY HH24:MI:SS'

RMANを使用してマウントされていないデータベースに接続し、その後、RMANが接続された状態でそのデータベースをマウントする場合は、NLS_LANG環境変数にデータベースが使用するキャラクタ・セットを指定してください。

マウントされていないデータベースのキャラクタ・セットは、デフォルトのUS7ASCIIとみなされます。キャラクタ・セットがデフォルトと異なる場合、RMANは、データベースのマウント後にエラーを戻します。たとえば、キャラクタ・セットがWE8DECの場合は、NLS_LANG変数を次のように設定してエラーを回避できます。

NLS_LANG=american_america.we8dec

環境変数NLS_DATE_FORMATを適用して、サーバー初期化ファイル内のサーバーのデフォルト設定を上書きするには、環境変数NLS_LANGの設定も必要です。

参照:

- NLS_LANGおよびNLS_DATE_FORMATパラメータの詳細は、『Oracle Databaseリファレンス』を参照してください。

- Oracle Databaseグローバリゼーション・サポート・ガイド

RMANコマンドの入力

RMANコマンドは、RMANプロンプトから直接入力するか、またはテキスト・ファイルから読み取ることができます。

この項の内容は、次のとおりです。

- RMANプロンプトでのRMANコマンドの入力

- RMANでのコマンド・ファイルの使用

- RMANコマンド・ファイルへのコメントの入力

- コマンド・ファイルでの置換変数の使用

- RMAN構文の確認

RMANプロンプトでのRMANコマンドの入力

RMANクライアントでコマンドを受け入れる準備が整うと、次の例に示すようなコマンド・プロンプトが表示されます。

RMAN>

RMANで実行するコマンドを入力します。次に例を示します。

RMAN> CONNECT TARGET
RMAN> BACKUP DATABASE;

RMANのほとんどのコマンドでは、いくつかのパラメータを使用し、末尾にセミコロンを付ける必要があります。STARTUP、SHUTDOWN、CONNECTなどのいくつかのコマンドは、セミコロンの有無に関係なく使用できます。

完全なコマンドではないテキスト行を入力すると、RMANは、行番号を表示して入力の継続を求めます。次に例を示します。

RMAN> BACKUP DATABASE
2> INCLUDE CURRENT
3> CONTROLFILE
4> ;

RMANでのコマンド・ファイルの使用

繰返し作業の場合は、RMANコマンドを含むテキスト・ファイルを作成し、@引数の後にファイル名を続けてRMANクライアントを起動します。たとえば、現行のディレクトリに次のテキスト行を含むテキスト・ファイルcmdfile1を作成します。

BACKUP DATABASE PLUS ARCHIVELOG;

このコマンド・ファイルをコマンドラインから実行すると、コマンド・ファイルに含まれているコマンドが実行されます。次に例を示します。

% rman TARGET / @cmdfile1

コマンドの完了後、RMANは終了します。

また、RMANコマンド・プロンプトで@コマンドを使用すると、RMANセッション中にコマンド・ファイルの内容を実行できます。RMANは、ファイルを読み取って、その中のコマンドを実行します。次に例を示します。

RMAN> @cmdfile1

RMANは、コマンド・ファイル内のコマンドの実行後、次のメッセージを表示します。

RMAN>  **end-of-file**

オペレーティング・システムのコマンドラインからコマンド・ファイルを実行した場合と異なり、RMANは終了しません。

関連項目:
RMANコマンドラインの構文については、『Oracle Databaseバックアップおよびリカバリ・リファレンス』を参照してください。

RMANコマンド・ファイルへのコメントの入力

RMANでのコメント文字は、シャープ記号(#)です。行のシャープ記号から最後までのテキストはすべて無視されます。たとえば、次のコマンド・ファイルの内容は、データベースおよびアーカイブREDOログをバックアップし、コメントを追加します。

# Command file name: mybackup.rman
# The following command backs up the database
BACKUP DATABASE;
# The following command backs up the archived redo logs
BACKUP ARCHIVELOG ALL;

次の例では、単一のRMANコマンドを複数の行に分割できることを示します。

RMAN> BACKUP # this is a comment
2> SPFILE;

Starting backup at 30-APR-07
allocated channel: ORA_DISK_1
.
.
.

コマンド・ファイルでの置換変数の使用

コマンド・ファイルの実行時に、コマンド・ファイル内の置換変数で使用される1つ以上の値をUSING句に指定できます。この方法で、コマンド・ファイルを動的にすることができます。

SQL*Plusの場合と同様に、&1は最初の値を配置する場所を示し、&2は2番目の値を配置する場所を示します。それ以降も同様です。置換変数の構文では、&integerの後にオプションのピリオドが続きます。たとえば、&1.3のようになります。オプションのピリオドは変数の一部であり、値と置換されます。したがって、置換テキストの直後に別の整数を続けることができます。たとえば、値mybackupを変数&1.3を含むコマンド・ファイルに渡すと、置換の結果はmybackup3になります。

次の手順では、置換変数を含むコマンド・ファイルをコールする動的シェル・スクリプトを作成および使用する方法について説明します。

動的シェル・スクリプトを作成および使用する手順

1. 置換変数を使用するRMANコマンド・ファイルを作成します。
次に、四半期ごとに実行されるquarterly_backup.cmdという名前のコマンド・ファイルの内容の例を示します。このスクリプトでは、テープ・セットの名前、FORMAT指定内の文字列および作成するリストア・ポイントの名前の置換変数が使用されています。

# quarterly_backup.cmd
CONNECT TARGET /
RUN
{
ALLOCATE CHANNEL c1
DEVICE TYPE sbt
PARMS 'ENV=(OB_MEDIA_FAMILY=&1)';
BACKUP DATABASE
TAG &2
FORMAT '/disk2/bck/&1%U.bck'
KEEP FOREVER
RESTORE POINT &3;
}
EXIT;

2. 前の手順で作成したRMANコマンド・ファイルを実行するために使用できるシェル・スクリプトを作成します。
次の例では、runbackup.shというシェル・スクリプトを作成します。この例では、書式およびリストア・ポイント名のシェル変数を作成し、これらの変数の値をスクリプトへのコマンドライン引数として受け入れます。

#!/bin/tcsh
# name: runbackup.sh
# usage: use the tag name and number of copies as arguments
set media_family = $argv[1]
set format = $argv[2]set restore_point = $argv[3]
rman @'/disk1/scripts/whole_db.cmd' USING $media_family $format $restore_point

3. 前の手順で作成したシェル・スクリプトを実行します。コマンドラインで適切な引数を指定します。
次の例では、runbackup.shシェル・スクリプトを実行し、メディア・ファミリ名としてarchival_backup、書式文字列としてbck0906、リストア・ポイント名としてFY06Q3を渡します。

% runbackup.sh archival_backup bck0906 FY06Q3

関連項目:
@の構文については、『Oracle Databaseバックアップおよびリカバリ・リファレンス』を参照してください。

RMAN構文の確認

RMANコマンドを実行せずに、その構文の正しさをテストする必要がある場合があります。コマンドライン引数CHECKSYNTAXを使用して、RMANクライアントを起動します。これによって、入力したコマンドの解析のみが行われ、有効なRMAN構文ではないコマンドに対してRMAN-00558エラーが戻されます。

関連項目:
CHECKSYNTAXコマンドライン・オプションについては、『Oracle Databaseバックアップおよびリカバリ・リファレンス』を参照してください。

コマンドラインでのRMAN構文の確認

コマンドを実際には実行せずに、RMANコマンドの構文を対話形式で確認できます。

RMAN構文をコマンドラインで確認する手順

1. CHECKSYNTAXパラメータを使用して、RMANを起動します。
たとえば、次のコマンドを入力します。

% rman CHECKSYNTAX

2. 確認するRMANコマンドを入力します。
次に、対話形式のセッションの例を示します。ユーザーが入力するテキストは太字になっています。

RMAN> run [ backup database; ]

RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-00558: error encountered while parsing input commands
RMAN-01006: error signaled during parse
RMAN-02001: unrecognized punctuation symbol "["

RMAN> run { backup database; }

The command has no syntax errors

RMAN>

コマンド・ファイル内のRMAN構文の確認

コマンド・ファイル内のコマンドをテストするには、CHECKSYNTAXパラメータを指定してRMANを起動し、@コマンドを使用して、渡すコマンド・ファイルの名前を指定します。

コマンド・ファイル内のコマンドをテストする手順

1. テキスト・エディタを使用してコマンド・ファイルを作成します。
次の内容の/tmp/goodcmdfileを作成するとします。

# command file with legal syntax
RESTORE DATABASE;
RECOVER DATABASE;

次の内容の別のコマンド・ファイル/tmp/badcmdfileを作成するとします。

# command file with bad syntax commands
RESTORE DATABASE
RECOVER DATABASE

2. RMANプロンプトから次の形式でコマンド・ファイルを実行します。ここで、filenameはコマンド・ファイルの名前です。

% rman CHECKSYNTAX @filename

次の例は、CHECKSYNTAXを使用して/tmp/goodcmdfileを実行した場合の出力を示しています。

RMAN> # command file with legal syntax
2> restore database;
3> recover database;
4>
The cmdfile has no syntax errors

Recovery Manager complete.

これに対して、次の例は、CHECKSYNTAXを使用して/tmp/badcmdfileを実行した場合の出力を示しています。

RMAN> #command file with syntax error
2> restore database
3> recover
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS===============
RMAN-00571: ===========================================================
RMAN-00558: error encountered while parsing input commands
RMAN-01005: syntax error: found "recover": expecting one of: "archivelog,
channel, check, controlfile, clone, database, datafile, device,
from, force, high, (, preview, ;, skip, spfile, standby, tablespace,
until, validate"
RMAN-01007: at line 3 column 1 file: /tmp/badcmdfile

「コマンド・ファイルでの置換変数の使用」の説明に従って、置換変数を使用してコマンド・ファイルを動的にします。置換変数を含むコマンド・ファイルの構文を確認する場合は、RMANによって値を入力するように求められます。例4-1は、動的コマンド・ファイルの構文を確認する際に無効な値を入力した場合を示しています。太字のテキストは、プロンプトとして入力されたテキストを示しています。

例4-1 無効な構文が含まれているコマンド・ファイルの構文の確認

RMAN> CONNECT TARGET *
2> BACKUP TAG
Enter value for 1: mybackup
abc COPIES
Enter value for 2: mybackup
abc
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-00558: error encountered while parsing input commands
RMAN-01009: syntax error: found "identifier": expecting one of: "integer"
RMAN-01008: the bad identifier was: mybackup
RMAN-01007: at line 2 column 25 file: /tmp/whole_db.cmd

文字列mybackupはCOPIESの有効な引数ではないため、RMANは構文エラーを示します。

RMANによるデータベース接続の確立

この項では、ターゲット・データベースにRMANクライアントを接続する方法について説明します。この項では次の項目を取り上げます。

- RMANによるデータベース接続

- RMANによる補助データベースへの接続

- コマンド・ファイル内でのRMANによるデータベース接続の確立

- RMANによる接続で発生した問題の診断

RMANによるデータベース接続

適切な作業を行うために、RMANクライアントをデータベースに接続する必要があります。次の表に、RMANで確立できるデータベース接続のタイプを示します。

表4-1 RMANによるデータベース接続の概要

データベース接続のタイプ

キーワード

説明

ターゲット・データベース

TARGET

RMANによってバックアップまたはリストアされるデータベース

リカバリ・カタログ・データベース

CATALOG

制御ファイルとは別の、RMANリポジトリのオプションのバックアップ先となるデータベース

補助インスタンスまたは補助データベース

AUXILIARY

フィジカル・スタンバイ・データベース、または複製データベースの作成、表領域のトランスポート、表領域のPoint-in-Timeリカバリ(TSPITR)の実行などの特定の作業を実行するために作成されたデータベース・インスタンス

補助データベースを使用する多くのタスクとして、RMANは、タスク実行中に使用する自動補助インスタンスを作成し、そのインスタンスに接続してタスクを実行し、タスクの完了時にそのインスタンスを破棄します。自動補助インスタンスに接続するために明示的なコマンドは指定しません。

RMANによるデータベース接続の認証

RMANによるデータベースへの接続は、SQL*Plusによるデータベースへの接続と同じ方法で指定および認証します。RMANによるターゲット・データベースまたは補助データベースへの接続にはSYSDBA権限が必要である点のみが異なります。AS SYSDBAキーワードは、ターゲット接続および補助接続に対して暗黙的に指定され、明示的には指定できません。

リカバリ・カタログへの接続では、SYSDBA権限は必要ありません。カタログ・スキーマの所有者には、RECOVERY_CATALOG_OWNERロールを付与する必要があります。

関連項目:
SQL*Plusを使用する場合のデータベース接続オプションについては、『Oracle Database管理者ガイド』を参照してください。

オペレーティング・システムを使用した、RMANによるデータベース接続の認証

オペレーティング・システム認証を使用してデータベースに接続するには、Oracle SIDを指定する環境変数を設定する必要があります。たとえば、UNIXシェルでSIDをprodに設定するには、次のように入力します。

% ORACLE_SID=prod; export ORACLE_SID

オペレーティング・システム認証を使用すると、特別なオペレーティング・システム・グループによってSYSDBA接続が制御されます。通常、このグループはOSDBAと呼ばれます。このグループは、データベースのインストール・プロセスの一環として作成され、特定の名前が割り当てられます。この特定の名前は、オペレーティング・システムによって異なります。

現行のオペレーティング・システム・ユーザーがOSDBAグループのメンバーで、Oracle SIDが設定されている場合は、次のように入力すると、RMANがSYSDBA権限でこのデータベースに接続できます。

% rman TARGET /

パスワード・ファイルを使用した、RMANによるデータベース接続の認証

データベースでパスワード・ファイルが使用されている場合、RMANはパスワードを使用してこのデータベースに接続できます。パスワード・ファイルは、ローカルまたはリモート・アクセスに使用します。ネット・サービス名を指定してSYSDBAでリモート接続する場合は、パスワード・ファイルを使用する必要があります。

注意:
適切なセキュリティ・プラクティスとして、コマンドラインにパスワードを入力するときは、プレーン・テキストで入力しないでください。RMANでは、RMANプロンプトで要求された場合にのみパスワードを入力してください。パスワード保護については、『Oracle Databaseセキュリティ・ガイド』を参照してください。

RMANは、次の例のように、接続文字列にパスワードを含めずに起動できます。

% rman TARGET SYS@prod

target database Password: password
connected to target database: PROD1 (DBID=39525561)

RMANによってパスワードの入力が求められますが、文字はエコーされません。

オペレーティング・システムのコマンドラインからのRMANによるデータベース接続の確立

オペレーティング・システムのコマンドラインからターゲット・データベースに接続するには、rmanコマンドの後に接続情報を続けて入力します。RMANプロンプトが表示されたら、コマンドの実行を開始できます。

表4-2に、この章の例で使用される一般的な値の意味を示します。

表4-2 例の値

例で使用される値

意味

SYS

SYSDBA権限を持つユーザー

prod

ターゲット・データベースのネット・サービス名。

rco

リカバリ・カタログのスキーマを所有するユーザー。このユーザーは、RECOVERY_CATALOG_OWNERロールが付与されているリカバリ・カタログ・データベースで定義されています。

catdb

リカバリ・カタログ・データベースのネット・サービス名。

aux

補助インスタンスのネット・サービス名。

例4-2は、オペレーティング・システム認証を使用するターゲット・データベースへの接続を示しています。NOCATALOGオプションは、セッションでリカバリ・カタログが使用されないことを示します。

例4-2 システム・プロンプトからのターゲット・データベースへの接続

% rman TARGET / NOCATALOG

connected to target database: PROD (DBID=39525561)
using target database control file instead of recovery catalog

RMAN>

例4-3は、Oracle Net認証を使用するターゲット・データベースへの接続を示しています。RMANによってパスワードの入力を求められます。

例4-3 システム・プロンプトからのターゲット・データベースへの接続

% rman TARGET SYS@prod NOCATALOG

target database Password: password
connected to target database: PROD (DBID=39525561)

RMAN>

CATALOGキーワードを使用してリカバリ・カタログに接続します。例4-4は、ターゲット・データベースおよびリカバリ・カタログ・データベースに対してOracle Net認証を使用する接続を示しています。いずれの場合も、RMANによってパスワードの入力を求められます。

例4-4 システム・プロンプトからのターゲット・データベースおよびカタログ・データベースへの接続

% rman TARGET SYS@prod CATALOG rco@catdb

target database Password: password
connected to target database: PROD (DBID=39525561)
recovery catalog database Password: password
connected to recovery catalog database

RMAN>

NOCATALOGまたはCATALOGを指定せずにRMANを起動することもできます。コマンドラインでNOCATALOGを指定しない場合、およびRMANの起動後にCONNECT CATALOGを指定しない場合、RMANリポジトリの使用を必要とするコマンドを初めて実行したときに、RMANはデフォルトでNOCATALOGモードになります。

注意:
RMANリポジトリを使用するコマンドをNOCATALOGモードで実行した後で、リカバリ・カタログに接続するには、RMANを終了して再起動する必要があります。

オペレーティング・システムのコマンドラインでターゲット・データベースに接続する場合は、RMANプロンプトが表示された後で、コマンドの実行を開始できます。

RMANプロンプトからのデータベース接続の確立

ターゲット・データベースに接続せずにRMANを起動する場合は、RMANプロンプトでCONNECT TARGETコマンドを発行してターゲット・データベースに接続してから、便利な処理の実行を開始する必要があります。

RMANプロンプトからデータベース接続を確立する手順

1. オペレーティング・システムのコマンドラインで、データベース接続を確立せずにRMANクライアントを起動します。たとえば、rmanを次のように入力します。

% rman
RMAN>

2. RMANプロンプトで、1つ以上のCONNECTコマンドを入力します。
次の例では、オペレーティング・システム認証を使用してターゲット・データベースに接続します。

RMAN> CONNECT TARGET /

次の例では、ターゲット・データベースに接続した後、リカバリ・カタログに接続します。ターゲット接続ではオペレーティング・システム認証が使用され、カタログ・データベース接続ではOracle Net認証が使用されます。RMANによって、リカバリ・カタログ・ユーザーのパスワードの入力を求められます。

RMAN> CONNECT TARGET /
RMAN> CONNECT CATALOG rco@catdb

recovery catalog database Password: password
connected to recovery catalog database

次の例では、データベース・レベルの資格証明でターゲット・データベースに接続します。RMANによってSYSパスワードの入力を求められます。

% rman
RMAN> CONNECT TARGET SYS@prod

target database Password: password
connected to target database: PROD (DBID=39525561)

関連項目:
CONNECTコマンドの詳細は、『Oracle Databaseバックアップおよびリカバリ・リファレンス』を参照してください。

RMANによる補助データベースへの接続

DUPLICATEコマンドを使用するには、補助インスタンスに接続する必要があります。RMANの表領域のPoint-in-Timeリカバリ(TSPITR)を実行する場合も、補助インスタンスへの接続が必要になることがあります。

注意:
DUPLICATE ... FROM ACTIVE DATABASEコマンドを使用する場合は、ネット・サービス名が必要です。詳細は、「手順5: 初期化パラメータ・ファイルの作成と補助インスタンスの起動」を参照してください。

補助接続の形式はターゲット・データベース接続と同じですが、TARGETキーワードのかわりにAUXILIARYキーワードを使用します。例4-5では、RMANプロンプトからターゲット・データベースおよび補助インスタンスに接続しています。

例4-5 RMANプロンプトからのターゲットおよび補助データベースへの接続

% rman
RMAN> CONNECT TARGET /
RMAN> CONNECT AUXILIARY SYS@aux

auxiliary database Password: password
connected to auxiliary database: PROD (DBID=30472568)

関連項目:

- DUPLICATEコマンドの使用方法の詳細は、第24章「データベースの複製」を参照してください。

- TSPITRの実行方法の詳細は、第21章「RMANの表領域のPoint-in-Timeリカバリ(TSPITR)の実行」を参照してください。

コマンド・ファイル内でのRMANによるデータベース接続の確立

CONNECTコマンドとともにデータベース・レベルの資格証明(ユーザー名とパスワード)を使用するRMANコマンド・ファイルを作成した場合、このファイルへの読取りアクセスを持つすべてのユーザーがパスワードを知ることができます。CONNECT文字列とパスワードをコマンド・ファイルに組み込む安全な方法はありません。

CONNECTコマンドを使用するRMANコマンド・ファイルを作成した場合に、@コマンドを使用してそのコマンド・ファイルを実行すると、RMANは接続文字列をエコーしません。この動作により、RMANの出力を含むどのログ・ファイルにも接続文字列が記録されなくなります。たとえば、次のように、コマンド・ファイルlistbkup.rmanを作成するとします。

cat > listbkup.rman << EOF
CONNECT TARGET /
LIST BACKUP;
EOF

RMANを@コマンドライン・オプションを指定して実行し、このスクリプトを実行します。

% rman @listbkup.rman

このコマンド・ファイルを実行すると、次の出力に示すように、接続文字列がアスタリスクに置き換えられます。

RMAN> CONNECT TARGET *
2> LIST BACKUP;
3>
connected to target database: RDBMS (DBID=771530996)

using target database control file instead of recovery catalog

List of Backup Sets
===================
. . .

RMANによる接続で発生した問題の診断

ターゲット・データベース、カタログ・データベースおよび補助データベースへの接続時にRMANで発生したエラーを診断する際、SQL*Plusを使用してこれらのデータベースに直接接続すると、接続情報またはデータベースに関する根本的な問題を検出できます。

ターゲット・データベースおよび補助データベースへの接続時に発生した問題の診断

RMANは、常にSYSDBA権限を使用してターゲット・データベースおよび補助データベースに接続します。このため、SQL*Plusを使用してターゲット・データベースおよび補助データベースへの接続時に発生した問題を診断する場合は、SYSDBA接続を要求して、RMANの動作を再現します。

たとえば、次のRMANコマンドで接続エラーが発生したとします。

RMAN> CONNECT TARGET /

この場合、次のSQL*Plusコマンドを使用して前の接続操作を再現します。

SQL> CONNECT / AS SYSDBA

リカバリ・カタログへの接続時に発生した問題の診断

RMANでリカバリ・カタログ・データベースに接続する場合、SYSDBA権限は使用されません。そのため、SQL*Plusを使用してリカバリ・カタログ・データベースへの接続時に発生した問題を診断する場合は、RMANに入力したものと同じデータベース接続文字列を入力する必要があります。AS SYSDBAは指定しないでください。

RMANのパイプ・インタフェースの使用

RMANにコマンドを発行してそれらのコマンドから出力を受信するかわりに、RMANのパイプ・インタフェースを使用できます。このインタフェースを使用すると、RMANは、オペレーティング・システム・シェルではなくDBMS_PIPE PL/SQLパッケージによってコマンドを取得し、出力を送信します。このインタフェースを使用することによって、RMANへのポータブル・プログラム・インタフェースを作成できます。

パイプ・インタフェースを起動するには、RMANクライアントのPIPEコマンドライン・パラメータを使用します。RMANは2つのプライベート・パイプを使用します。1つはコマンドの受信用、もう1つは出力の送信用です。パイプの名前はPIPEパラメータの値から導出されます。たとえば、次のコマンドでRMANを起動できます。

% rman PIPE abc TARGET /

RMANは、ターゲット・データベースで2つのパイプをオープンします。ORA$RMAN_ABC_INはユーザー・コマンドの受信に使用するパイプ、ORA$RMAN_ABC_OUTはすべての出力をRMANに戻すために使用するパイプです。入力と出力の両方のパイプでは、すべてのメッセージはVARCHAR2型です。

セキュリティの問題が発生する可能性があるため、RMANでは、パイプ・インタフェースをパブリック・パイプで使用することはできません。パブリック・パイプの場合、パイプ名を知っているすべてのユーザーが、RMANにコマンドを送信してその出力を取得できます。

パイプは、初期化されていない場合はプライベート・パイプとして作成されます。 RMANの起動前に入力パイプにコマンドを入力する場合は、DBMS_PIPE.CREATE_PIPEをコールして最初にパイプを作成しておく必要があります。パイプは、プライベート・パイプとして明示的に作成しないと、そのパイプへの最初のアクセス時に自動的にパブリック・パイプとして作成されます。RMANでパブリック・パイプを使用しようとすると、エラーが戻されます。

注意:
複数のRMANセッションをターゲット・データベースに対して実行する場合は、各RMANセッションに一意のパイプ名を使用する必要があります。一意のパイプ名を生成する方法の1つとして、DBMS_PIPE.UNIQUE_SESSION_NAMEファンクションを使用できます。

パイプを介した複数のRMANコマンドの連続実行の例

この例では、RMANを制御するアプリケーションで複数のコマンドを連続実行します。パイプに各コマンドが送信および実行されて出力が戻されると、RMANは一時停止して次のコマンドを待機します。

パイプを介してRMANコマンドを実行する手順

1. ターゲット・データベースに接続し(必須)、PIPEオプションを指定してRMANを起動します。たとえば、次のように入力します。

% rman PIPE abc TARGET /

TIMEOUTオプションを指定することもできます。このオプションを指定すると、指定した時間内(秒単位)に入力パイプから入力を受信しなかった場合、RMANが強制終了されます。たとえば、次のように入力します。

% rman PIPE abc TARGET / TIMEOUT 60

2. ターゲット・データベースに接続し、DBMS_PIPE.PACK_MESSAGEおよびDBMS_PIPE.SEND_MESSAGEを使用して目的のコマンドを入力パイプに入力します。パイプ・モードでは、RMANで入力の受入れ準備が完了すると、標準RMANプロンプトではなくRMAN-00572メッセージが表示されます。

3. DBMS_PIPE.RECEIVE_MESSAGEおよびDBMS_PIPE.UNPACK_MESSAGEを使用して、出力パイプからRMAN出力を読み取ります。

4. 手順2と3を繰り返し、手順1で起動したRMANインスタンスで他のコマンドを実行します。

5. RMANの起動時にTIMEOUTオプションを使用した場合は、指定した時間内に入力を受信しなければRMANが自動的に終了します。すぐにRMANを終了するには、EXITコマンドを送信します。

パイプを介したRMANコマンドの単一ジョブでの実行の例

この例では、RMANを制御するアプリケーションで1つ以上のコマンドを単一ジョブとして実行します。パイプに入力されたコマンドの実行後、RMANが終了します。

パイプを介して単一ジョブでRMANコマンドを実行する手順

1. ターゲット・データベースへの接続後、パイプを作成します(ORA$RMAN_pipe_INという名前のパイプが存在しない場合)。

2. 目的のコマンドを入力パイプに入力します。パイプ・モードでは、RMANで入力の受入れ準備が完了すると、標準RMANプロンプトではなくRMAN-00572メッセージが表示されます。

3. PIPEオプションを使用してRMANを起動し、TIMEOUT 0を指定します。たとえば、次のように入力します。

% rman PIPE abc TARGET / TIMEOUT 0

4. DBMS_PIPE.PACK_MESSAGEおよびDBMS_PIPE.SEND_MESSAGEを使用して、パイプに入力されたコマンドを読み取り、実行します。入力パイプのすべてのコマンドを実行すると、RMANはすぐに終了します。

5. DBMS_PIPE.RECEIVE_MESSAGEおよびDBMS_PIPE.UNPACK_MESSAGEを使用して、出力パイプからRMAN出力を読み取ります。

関連項目:
DBMS_PIPEパッケージのドキュメントについては、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。

5 RMAN環境の構成

この章では、RMANを構成する場合の基本的なタスクについて説明します。この章の内容は次のとおりです。

- RMANバックアップの環境の構成

- メディア・マネージャにバックアップするためのRMANの構成

- 高速リカバリ領域の構成

- バックアップの保存方針の構成

- バックアップの最適化およびCONFIGUREコマンド

- アーカイブREDOログの削除方針の構成

- Data Guard環境でのRMANの構成

関連項目:

- この章で説明していない構成オプション(バックアップの圧縮やバックアップの暗号化など)については、第6章「RMAN環境の構成: 高度なトピック」を参照してください。

- Oracle Secure Backup(OSB)Cloud Module用にRMANを構成する方法については、『Oracle Databaseバックアップおよびリカバリ・リファレンス』の付録Cを参照してください。

RMANバックアップの環境の構成

RMANには、バックアップに必要なほとんどのパラメータに対して、基本的なバックアップおよびリカバリを実行できる適切なデフォルトが備えられています。RMANベースのバックアップ計画を実装する場合、最も一般的な構成を理解すると、RMANを効果的に使用できます。

RMANの継続的な使用を簡単にするには、各ターゲット・データベースにいくつかの永続構成を設定します。これらの設定によって、RMANの動作の様々な点が制御されます。たとえば、バックアップの保存方針、バックアップのデフォルトの格納先、デフォルトのバックアップ・デバイス・タイプなどを構成できます。SHOWおよびCONFIGUREコマンドを使用して、RMANの構成を表示および変更できます。

この項では、RMAN構成の概要およびCONFIGUREコマンドを使用してRMANのデフォルトの動作をバックアップとリカバリ環境用に変更する方法について説明します。また、使用可能な主な設定および一般的な設定値についても説明します。

注意:
テープへのバックアップを計画している場合は、「メディア・マネージャにバックアップするためのRMANの構成」を参照してください。

この項の内容は、次のとおりです。

- RMANの永続的な構成の表示およびクリア

- バックアップ用のデフォルト・デバイスの構成: ディスクまたはSBT

- バックアップ用のデフォルト・タイプの構成: バックアップ・セットまたはコピー

- チャネルの構成

- 制御ファイルおよびサーバー・パラメータ・ファイルの自動バックアップの構成

関連項目:
CONFIGUREの構文については、『Oracle Databaseバックアップおよびリカバリ・リファレンス』を参照してください。

RMANの永続的な構成の表示およびクリア

SHOWコマンドを使用すると、ターゲット・データベース用に設定されたRMANの現在の値を表示できます。これらのコマンドが、現在デフォルト値に設定されているかどうかを表示することもできます。

CONFIGUREコマンド設定を表示または変更する手順

1. RMANを起動し、ターゲット・データベースおよびリカバリ・カタログ(使用している場合)に接続します。

2. RMANのSHOWコマンドを実行します。
たとえば、例5-1に示すように、SHOW ALLを実行します(出力例も示します)。出力には、変更したパラメータとデフォルトに設定されたパラメータの両方が含まれています。構成は、構成の再作成に必要な一連のRMANコマンドとして表示されます。出力をテキスト・ファイルに保存したり、このコマンド・ファイルを使用して同じまたは別のデータベースに構成を再作成することができます。

例5-1 SHOW ALLコマンド

SHOW ALL;

RMAN configuration parameters for database with db_unique_name PROD1 are:
CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF 3 DAYS;
CONFIGURE BACKUP OPTIMIZATION ON;
CONFIGURE DEFAULT DEVICE TYPE TO DISK; # default
CONFIGURE CONTROLFILE AUTOBACKUP ON;
CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE SBT_TAPE TO '%F'; # default
CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO '%F'; # default
CONFIGURE DEVICE TYPE 'SBT_TAPE' PARALLELISM 2 BACKUP TYPE TO COMPRESSED BACKUPSET;
CONFIGURE DEVICE TYPE DISK PARALLELISM 1 BACKUP TYPE TO BACKUPSET; # default
CONFIGURE DATAFILE BACKUP COPIES FOR DEVICE TYPE SBT_TAPE TO 1; # default
CONFIGURE DATAFILE BACKUP COPIES FOR DEVICE TYPE DISK TO 1; # default
CONFIGURE ARCHIVELOG BACKUP COPIES FOR DEVICE TYPE SBT_TAPE TO 1; # default
CONFIGURE ARCHIVELOG BACKUP COPIES FOR DEVICE TYPE DISK TO 1; # default
CONFIGURE CHANNEL DEVICE TYPE 'SBT_TAPE' PARMS 'ENV=(OB_DEVICE=tape1)';
CONFIGURE MAXSETSIZE TO UNLIMITED; # default
CONFIGURE ENCRYPTION FOR DATABASE OFF; # default
CONFIGURE ENCRYPTION ALGORITHM 'AES128'; # default
CONFIGURE ARCHIVELOG DELETION POLICY TO NONE; # default
CONFIGURE SNAPSHOT CONTROLFILE NAME TO '/disk1/oracle/dbs/snapcf_ev.f'; # default

SHOWコマンドは、特定の構成の名前を指定して使用することもできます。たとえば、次のように入力すると、保存方針およびデフォルトのデバイス・タイプを表示できます。

SHOW RETENTION POLICY;
SHOW DEFAULT DEVICE TYPE;

3. 必要に応じて、CONFIGURE ... CLEARコマンドを使用して構成をデフォルト値に戻します。次に例を示します。

CONFIGURE BACKUP OPTIMIZATION CLEAR;
CONFIGURE RETENTION POLICY CLEAR;
CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK CLEAR;

関連項目:
SHOWの構文については、『Oracle Databaseバックアップおよびリカバリ・リファレンス』を参照してください。

バックアップ用のデフォルト・デバイスの構成: ディスクまたはSBT

バックアップ先のデバイス・タイプが指定されていないバックアップは、構成済のデフォルト・デバイスに格納されます。RMANは、デフォルトのデバイス・タイプとしてディスクを使用するように事前構成されています。追加の構成は必要ありません。

デフォルトのデバイス・タイプをディスクからテープに変更したり、テープからディスクに戻す必要がある場合があります。表5-1に、デフォルトのデバイスを構成するコマンドを示します。

表5-1 デフォルトのデバイス・タイプを構成するコマンド

コマンド

説明

CONFIGURE DEFAULT DEVICE TYPE TO DISK

バックアップをデフォルトでディスクに格納するように指定します。

リカバリ領域が有効になっている場合、バックアップ場所はデフォルトで高速リカバリ領域になります。リカバリ領域が有効になっていない場合、バックアップ場所はデフォルトでディスク上のオペレーティング・システム固有のディレクトリになります。

ディスクにバックアップする場合、データベース・ファイルの論理ブロック・サイズは、バックアップ先のデバイスの物理ブロック・サイズの倍数である必要があります。たとえば、ブロック・サイズが2KBのDISKタイプのデバイスは、論理ブロック・サイズが2KB、4KB、6KBなどのデータベース・ファイルのバックアップ先としてのみ使用できます。ほとんどのディスク・ドライブの物理ブロック・サイズは512バイトであるため、この制限が、ディスク・ドライブへのバックアップに影響を及ぼすことはほとんどありません。ただし、書込み可能なDVDまたは物理ブロック・サイズが大きいデバイスにバックアップする場合は、この制限の影響を受ける可能性があります。

CONFIGURE DEFAULT DEVICE TYPE TO sbt

バックアップをデフォルトでテープに格納するように指定します。

メディア・マネージャで使用するRMANの設定方法については、「メディア・マネージャにバックアップするためのRMANの構成」を参照してください。RMANがメディア・マネージャと通信できるようになった後、テープにバックアップが作成されるようにRMANを構成し、デフォルトのデバイス・タイプとしてSBTを指定します。

次の例に示すように、BACKUPコマンドのDEVICE TYPE句を使用して、デフォルト・デバイスを常に上書きできます。

BACKUP DEVICE TYPE sbt DATABASE;
BACKUP DEVICE TYPE DISK DATABASE;

構成済のデフォルトのデバイス・タイプを変更する手順

1. RMANを起動し、ターゲット・データベースおよびリカバリ・カタログ(使用している場合)に接続します。

2. SHOW ALLコマンドを実行して、現在構成されているデフォルトのデバイスを表示します。

3. TO DISKまたはTO sbtのいずれかを指定して、CONFIGURE DEFAULT DEVICE TYPEコマンドを実行します。

関連項目:
DEVICE TYPE句を指定したBACKUPコマンドを使用する方法の詳細は、『Oracle Databaseバックアップおよびリカバリ・リファレンス』を参照してください。

バックアップ用のデフォルト・タイプの構成: バックアップ・セットまたはコピー

BACKUPコマンドでは、バックアップ・セットまたはイメージ・コピーのいずれかを作成できます。ディスクの場合、CONFIGURE DEVICE TYPE DISK BACKUP TYPE TOコマンドを使用すると、デフォルトのバックアップ・タイプとしてバックアップ・セットまたはイメージ・コピーを作成するようにRMANを構成できます。ディスクのデフォルトのバックアップ・タイプは、圧縮されていないバックアップ・セットです。

注意:
RMANはディスクにのみイメージ・コピーを書き込むことができるため、テープのバックアップ・タイプはバックアップ・セットのみになります。

RMANはバイナリ圧縮を使用してバックアップ・セットを作成できます。BACKUP TYPE TO ... BACKUPSET句にCOMPRESSEDオプションを指定すると、デバイス・タイプに対してデフォルトで圧縮バックアップ・セットを使用するようにRMANを構成できます。圧縮を無効にするには、他の必要な設定を示す引数を指定してCONFIGURE DEVICE TYPEコマンドを使用しますが、COMPRESSEDキーワードは省略します。

バックアップのデフォルト・タイプを構成する手順

1. RMANを起動し、ターゲット・データベースおよびリカバリ・カタログ(使用している場合)に接続します。

2. バックアップ・セットまたはコピーをデフォルトのバックアップ・タイプとして構成します。
次の例では、ディスク・バックアップのバックアップ・タイプをコピーおよびバックアップ・セットに構成しています。

CONFIGURE DEVICE TYPE DISK BACKUP TYPE TO COPY; # image copies
CONFIGURE DEVICE TYPE DISK BACKUP TYPE TO BACKUPSET; # uncompressed

次の例では、バックアップ・セットの圧縮を構成しています。

CONFIGURE DEVICE TYPE DISK BACKUP TYPE TO COMPRESSED BACKUPSET;
CONFIGURE DEVICE TYPE sbt BACKUP TYPE TO COMPRESSED BACKUPSET;

関連項目:

- バックアップ・セット

- 圧縮バックアップの作成

チャネルの構成

「RMANチャネル」で説明されているように、RMANチャネルとは、データベース・サーバー・セッションへの接続のことです。RMANは、ほとんどのタスクの実行にチャネルを使用します。

チャネルの構成

ディスクまたはSBTチャネルのオプションを構成するには、CONFIGURE CHANNELコマンドを使用します。CONFIGURE CHANNELでは、ALLOCATE CHANNELコマンドでワンタイム・オプションを指定するときに使用するものと同じオプションを使用します。デバイス・タイプに汎用チャネル設定を構成できます。汎用チャネル設定は、デバイスの構成済設定に基づいて作成されるチャネルで使用されるテンプレートです。

注意:
この項では、ディスク・チャネルの構成について説明します。テープのチャネルを構成する方法については、「メディア・マネージャで使用するSBTチャネルの構成」を参照してください。

CONFIGURE CHANNELを使用してデバイスの汎用チャネル設定を指定すると、以前の設定は競合がない場合でも破棄されます。たとえば、2番目のCONFIGURE CHANNELコマンドで構成済のディスク・チャネルに対してFORMATのみを指定すると、ディスク・チャネルのMAXPIECESIZEがデフォルト値に戻されます。

CONFIGURE CHANNEL DEVICE TYPE DISK MAXPIECESIZE 2G;
CONFIGURE CHANNEL DEVICE TYPE DISK FORMAT /tmp/%U;

ディスクのチャネルの構成

デフォルトでは、RMANは、1つのディスク・チャネルをすべての操作に割り当てます。このチャネルに対して、バックアップ用の新しいデフォルトの場所などの他のオプションを指定する必要がある場合があります。例5-2では、ディスク・バックアップを/disk1ディレクトリに書き込むようにRMANを構成し、相対ファイル名にデフォルト以外の書式を指定します。

例5-2 デフォルト以外のバックアップ場所の構成

CONFIGURE CHANNEL DEVICE TYPE DISK FORMAT '/disk1/ora_df%t_s%s_s%p';

例5-2では、RMANは、書式指定子%tを4バイトのタイムスタンプに、%sをバックアップ・セット番号に、%pをバックアップ・ピース番号に自動的に置換します。

注意:
ディスク・チャネルに明示的な書式を構成すると、RMANは、デフォルトでは高速リカバリ領域にバックアップを作成しません。この場合、高速リカバリ領域のディスク領域管理機能は失われます。

例5-3に示すように、ASMディスクの場所を指定することもできます。

例5-3 ASMディスクの場所の構成

CONFIGURE CHANNEL DEVICE TYPE DISK FORMAT '+dgroup1';

関連項目:
バックアップを作成する方法については、「RMANを使用したデータベース・ファイルのバックアップ」を参照してください。

ディスクおよびSBTデバイス用のパラレル・チャネルの構成

コマンドの実行時にデバイス・タイプで使用できるチャネルの数によって、RMANが読取りまたは書込みをパラレルで行うかどうかが決まります。通常、コマンドの実行に使用するチャネルの数は、アクセスされるデバイスの数と一致する必要があります。したがって、テープ・バックアップの場合は、テープ・ドライブごとに1つのチャネルを割り当てます。ディスク・バックアップの場合は、物理ディスクごとに1つのチャネルを割り当てます。ただし、複数のチャネルを使用して、ディスク・サブシステム・アーキテクチャ用にバックアップを最適化できる場合は除きます。適切な数のチャネルが割り当てられない場合、I/O操作中のRMANのパフォーマンスが低下します。

CONFIGURE DEVICE TYPE sbtを使用すると、SBTデバイスに対してチャネルのパラレル化設定、バックアップ・セットのバイナリ圧縮などのオプションを構成できます。デバイス・タイプの構成は、チャネルの構成とは別に設定できます。

例5-4では、RMANで2つのテープ・ドライブをパラレルに使用してメディア・マネージャにバックアップできるようにSBTデバイスを変更します(出力例も示します)。構成済の各SBTチャネルは、データの合計の約半分ずつをバックアップします。

例5-4 SBTデバイスのパラレル化の構成

RMAN> CONFIGURE DEVICE TYPE sbt PARALLELISM 2;

old RMAN configuration parameters:
CONFIGURE DEVICE TYPE 'SBT_TAPE' BACKUP TYPE TO COMPRESSED BACKUPSET PARALLELISM 1;
new RMAN configuration parameters:
CONFIGURE DEVICE TYPE 'SBT_TAPE' PARALLELISM 2 BACKUP TYPE TO COMPRESSED BACKUPSET;
new RMAN configuration parameters are successfully stored

例5-5では、SBTデバイスのデフォルトのバックアップ・タイプを、圧縮されていないバックアップ・セットに変更します(出力例も示します)。

例5-5 SBTデバイスのバックアップ・タイプの構成

RMAN> CONFIGURE DEVICE TYPE sbt BACKUP TYPE TO BACKUPSET;

old RMAN configuration parameters:
CONFIGURE DEVICE TYPE 'SBT_TAPE' PARALLELISM 2 BACKUP TYPE TO COMPRESSED BACKUPSET;
new RMAN configuration parameters:
CONFIGURE DEVICE TYPE 'SBT_TAPE' BACKUP TYPE TO BACKUPSET PARALLELISM 2;
new RMAN configuration parameters are successfully stored

この例で使用されているCONFIGURE DEVICE TYPEコマンドは、パラレル化とバックアップ・タイプのみに影響し、指定されていない設定値には影響しません。例5-4では、パラレル化設定を変更しても、圧縮済バックアップ・セットのデフォルトのバックアップ・タイプは変更されていません。例5-5では、デフォルトのバックアップ・タイプを変更しても、複数のテープ・ドライブをパラレルに使用する機能には影響していません。

関連項目:

- ディスク・バックアップをパラレル化する方法については、「ディスク・バックアップの複数のフォーマットの指定」を参照してください。

- BACKUPコマンドのCHANNELパラメータの詳細は、『Oracle Databaseバックアップおよびリカバリ・リファレンス』を参照してください。

- Oracle Real Application Clusters(Oracle RAC)構成でパラレル操作を活用する方法については、『Oracle Real Application Clusters管理およびデプロイメント・ガイド』を参照してください。

構成済チャネルの手動での変更

ジョブの実行中にチャネルを手動で割り当てると、構成済チャネルのすべての設定が無視されます。たとえば、デフォルトのデバイス・タイプがSBTに構成された状態で、次のコマンドを実行するとします。

RUN
{
ALLOCATE CHANNEL c1 DEVICE TYPE DISK;
BACKUP TABLESPACE users;
}

この場合、RMANでは、RUNコマンド内で手動で割り当てたディスク・チャネルのみが使用され、CONFIGURE DEVICE TYPE、CONFIGURE DEFAULT DEVICEまたはCONFIGURE CHANNEL設定を使用して設定されたデフォルトは上書きされます。

関連項目:

- 構成済チャネルおよび割当て済チャネルについては、「RMANチャネル」を参照してください。

- ALLOCATE CHANNELの構文については、『Oracle Databaseバックアップおよびリカバリ・リファレンス』を参照してください。

- CONFIGUREの構文については、『Oracle Databaseバックアップおよびリカバリ・リファレンス』を参照してください。

制御ファイルおよびサーバー・パラメータ・ファイルの自動バックアップの構成

「制御ファイルおよびサーバー・パラメータ・ファイルの自動バックアップ」で説明されているように、RMANは、制御ファイルおよびサーバー・パラメータ・ファイルを自動的にバックアップするように構成することができます。自動バックアップは、バックアップ・レコードが追加されるたびに実行されます。 また、データベースがARCHIVELOGモードで実行されている場合も、自動バックアップは、制御ファイル内のデータベース構造メタデータが変更されるたびに実行されます。制御ファイルの自動バックアップによって、RMANは、現行の制御ファイル、リカバリ・カタログおよびサーバー・パラメータ・ファイルが消失した場合でも、データベースをリカバリできます。

自動バックアップのファイル名は標準書式に従っているため、RMANは、リポジトリにアクセスせずにこのファイルを検索し、サーバー・パラメータ・ファイルをリストアできます。リストアされたサーバー・パラメータ・ファイルを使用してインスタンスを起動すると、RMANは、自動バックアップから制御ファイルをリストアできます。制御ファイルをマウントすると、RMANリポジトリが使用可能になり、RMANは、データファイルをリストアし、アーカイブREDOログが検索できるようになります。

次のコマンドを実行すると、自動バックアップ機能を有効にできます。

CONFIGURE CONTROLFILE AUTOBACKUP ON;

次のコマンドを実行すると、自動バックアップ機能を無効にできます。

CONFIGURE CONTROLFILE AUTOBACKUP OFF;

関連項目:
CONFIGUREの構文については、『Oracle Databaseバックアップおよびリカバリ・リファレンス』を参照してください。

制御ファイルの自動バックアップ書式の構成

デフォルトでは、構成済のすべてのデバイスの自動バックアップ・ファイルの書式は、FORMAT句では置換変数%Fになります。この変数の書式は、c-IIIIIIIIII-YYYYMMDD-QQに変換されます。プレースホルダは次のように定義されます。

- IIIIIIIIIIは、DBIDを表します。

- YYYYMMDDは、バックアップが生成された日のタイム・スタンプです。

- QQは、00から始まる16進の順序です。最大値はFFです。

次のコマンドを使用すると、デフォルトの書式を変更できます。ここで、deviceSpecifierは有効なデバイス・タイプです。'string'は指定したデバイスに対する有効なハンドルであり、この中に置換変数%Fが含まれている必要があります(他の置換変数を含めることはできません)。

CONFIGURE CONTROLFILE AUTOBACKUP FORMAT
FOR DEVICE TYPE deviceSpecifier TO 'string';

たとえば、次のコマンドを実行すると、制御ファイルの自動バックアップにデフォルト以外のファイル名を指定できます。ファイル名で、?はORACLE_HOMEを表します。

CONFIGURE CONTROLFILE AUTOBACKUP FORMAT
FOR DEVICE TYPE DISK TO '?/oradata/cf_%F';

次の例では、自動ストレージ管理ディスク・グループに書き込まれるように自動バックアップを構成します。

CONFIGURE CONTROLFILE AUTOBACKUP FORMAT
FOR DEVICE TYPE DISK TO '+dgroup1/%F';

注意:
制御ファイルの自動バックアップに有効な書式は、%D、%I、%M、%Y、%F、%T、%dおよび%nです。これら以外の書式を使用すると、制御ファイルの自動バックアップをリストアできない場合があります。

デバイスに対する制御ファイルの自動バックアップの書式をクリアするには、次のコマンドを使用します。

CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK CLEAR;
CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE sbt CLEAR;

データベースに高速リカバリ領域が設定されている場合、ディスクに対する制御ファイルの自動バックアップ書式をクリアすると、制御ファイルの自動バックアップを高速リカバリ領域に格納することができます。

注意:
高速リカバリ領域のすべてのファイルはOracle Databaseによって管理され、関連するファイル名はOracle Managed Files(OMF)形式で管理されます。

構成済の制御ファイルの自動バックアップ書式の上書き

RUNコマンド内またはRMANプロンプトのいずれかでSET CONTROLFILE AUTOBACKUP FORMATコマンドを指定すると、現在のセッションのみで構成済の自動バックアップ書式が上書きされます。優先順位は次のとおりです。

1. SET CONTROLFILE AUTOBACKUP FORMAT(RUNブロック内)

2. SET CONTROLFILE AUTOBACKUP FORMAT(RMANプロンプト)

3. CONFIGURE CONTROLFILE AUTOBACKUP FORMAT

次の例では、2つの形式のSET CONTROLFILE AUTOBACKUP FORMATの相互作用を示します。

SET CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO 'controlfile_%F';
BACKUP AS COPY DATABASE;
RUN
{
SET CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO '/tmp/%F.bck';
BACKUP AS BACKUPSET
DEVICE TYPE DISK
DATABASE;
}

最初のSET CONTROLFILE AUTOBACKUP FORMATは、制御ファイルのすべての構成済自動バックアップ書式より優先され、RMANクライアントが終了するまで制御ファイルの自動バックアップの名前を制御します。RUNブロック内のSET CONTROFILE AUTOBACKUP FORMATでは、RUNブロックが有効なかぎり、RUNブロックの外にあるSET CONTROLFILE AUTOBACKUP FORMATは上書きされます。

メディア・マネージャにバックアップするためのRMANの構成

ほとんどのプラットフォームでは、テープなどのシーケンシャル・メディアにバックアップしたり、これらのメディアからリストアしたりする場合には、Oracle Databaseとメディア・マネージャを統合する必要があります。テープに対するデータベースとファイル・システムの両方のバックアップをサポートしているOracle Secure Backupをメディア・マネージャとして使用できます。特にOracle Secure Backupとともに使用するためにRMANを設定する方法については、『Oracle Secure Backup管理者ガイド』を参照してください。

Oracle Secure Backupを使用しない場合は、サード・パーティのメディア・マネージャを使用できます。この項では、サード・パーティのメディア・マネージャとともに使用するためにRMANを構成する一般的な手順について説明します。実際の手順は、インストールしたメディア管理製品およびデータベースを実行するプラットフォームによって異なります。Oracle Secure Backup以外のメディア・マネージャとともにRMANを使用する場合は、製品固有のすべての情報をベンダーから入手する必要があります。

メディア・マネージャを構成する際、次の項を順に参照してください。

1. RMANをメディア・マネージャとともに使用するための前提条件

2. メディア管理ライブラリの場所の確認

3. RMANのバックアップに対するメディア管理ソフトウェアの構成

4. メディア・マネージャ・ライブラリが正常に統合されたかどうかのテスト

5. メディア・マネージャで使用するSBTチャネルの構成

関連項目:
メディア管理ソフトウェアの概要およびRMANが受ける影響の概要は、「メディア管理」を参照してください。

RMANをメディア・マネージャとともに使用するための前提条件

RMANをサード・パーティのメディア・マネージャとともに使用するには、メディア・マネージャをインストールし、RMANと通信できるようにする必要があります。詳細は、メディア管理ベンダーのソフトウェアのドキュメントを参照してください。

通常、まず、メディア管理ソフトウェアをターゲット・ホストまたは本番ネットワークにインストールして構成します。オペレーティング・システム・ファイルのRMAN以外のバックアップをターゲット・データベース・ホスト上に作成できることを確認します。この手順に従って、メディア・マネージャとターゲット・ホストの基本的な統合が正常に完了したことを確認すると、後で行うトラブルシューティングが簡単になります。RMANを使用しないでメディア・マネージャにファイルをバックアップする方法については、メディア管理ソフトウェアのドキュメントを参照してください。

次に、サード・パーティのメディア管理モジュールを入手してインストールし、データベース・サーバーと統合します。このモジュールには、Oracle Databaseがメディア・マネージャへのアクセス時にロードおよび使用するメディア管理ライブラリが含まれています。このモジュールは通常、別ライセンスのサード・パーティ製品です。詳細は、メディア管理ベンダーに問い合せてください。

メディア管理ライブラリの場所の確認

メディア・マネージャとともにRMANを使用する前に、メディア管理ライブラリの場所を指定します。RMANでメディア・マネージャとの通信に使用するチャネルの割当てまたは構成を行う場合は、ALLOCATE CHANNELまたはCONFIGURE CHANNELコマンドにSBT_LIBRARYパラメータを指定する必要があります。SBT_LIBRARYパラメータには、ライブラリへのパスを指定します。

次に、チャネルの構文の例を示します。ここで、pathnameは、ライブラリの絶対ファイル名です。

CONFIGURE CHANNEL DEVICE TYPE sbt
PARMS 'SBT_LIBRARY=pathname';

RMANは、メディア・マネージャと通信するためのチャネルを割り当てる場合、SBT_LIBRARYパラメータで指定されたライブラリをロードします。

割当て済または事前構成済のチャネルでSBT_LIBRARYパラメータの値を指定しない場合、RMANは、プラットフォーム固有の安全なデフォルトの場所を検索します。

LinuxおよびUNIXでは、SBTライブラリは次の場所からロードされます。

/opt/oracle/extapi/[32,64]/{SBT}/{VENDOR}/{VERSION}/libobk.so

SBTライブラリのファイル名の拡張子名はプラットフォームによって異なります。

- HP-UXの場合は.so、.sl

- AIXの場合は.a

Windowsでは、SBTライブラリは次の場所からロードされます。

%SYSTEM_DRIVE%\oracle\extapi\[32,64]\{SBT}\{VENDOR}\{VERSION}\orasbt.dll

RMANが安全なデフォルトの場所を使用できないか、またはOracle Database 11g以下を使用している場合、RMANは、環境変数PATHまたはLIBPATHで指定されている場所からSBTライブラリをロードします。

組織に、環境変数PATHまたはLIBPATHを使用してライブラリ・ディレクトリを指定することを禁止するセキュリティ要件または法規制順守の要件がある場合があります。この動作を無効にするには、PARMS文字列をSBT_SECURE=1に設定します。

注意:
デフォルトのメディア管理ライブラリ・ファイルは、標準のデータベース・インストールには含まれません。サード・パーティのメディア管理ソフトウェアをインストールした場合にのみ含まれます。

関連項目:
プラットフォーム上でメディア・マネージャを統合する方法については、オペレーティング・システム固有のデータベース・ドキュメントおよびメディア・ベンダーが提供するドキュメントを参照してください。

RMANのバックアップに対するメディア管理ソフトウェアの構成

メディア管理ソフトウェアのインストール後、RMANでバックアップを受け入れることができるように、ベンダーの要件に従ってソフトウェアを構成します。インストールしたメディア管理ソフトウェアのタイプによっては、メディア・プールの定義、ユーザーおよびクラスの構成などが必要になる場合があります。

適切なRMAN設定については、メディア管理ベンダーのドキュメントを参照してください。PARMSパラメータは、メディア・マネージャに指示を送信します。PARMSの値がALLOCATE CHANNELまたはCONFIGURE CHANNELコマンドで必要な場合、またはFORMAT文字列がBACKUPまたはCONFIGUREコマンドで推奨される場合は、その情報についてベンダーのドキュメントを参照してください。

例5-6に、Oracle Secure BackupのPARMS設定を示します。このPARMS設定は、datafile_mfという一連のテープにバックアップを行うようにメディア・マネージャに指示します。PARMS設定は、常にベンダー固有です。

例5-6 Oracle Secure BackupのPARMS設定

CONFIGURE CHANNEL DEVICE TYPE 'SBT_TAPE'
PARMS 'ENV=(OB_MEDIA_FAMILY=datafile_mf)';

参照:

- ALLOCATE CHANNELの構文については、『Oracle Databaseバックアップおよびリカバリ・リファレンス』を参照してください。

- チャネル制御オプションについては、『Oracle Databaseバックアップおよびリカバリ・リファレンス』を参照してください。

- Oracle Secure Backupに対するRMAN固有のパラメータ設定については、『Oracle Secure Backupリファレンス』を参照してください。

メディア・マネージャ・ライブラリが正常に統合されたかどうかのテスト

データベース・サーバーでメディア管理ライブラリをロードできることを確認した後、RMANでメディア・マネージャにバックアップできるかどうかをテストします。

メディア・マネージャでのALLOCATE CHANNELのテスト

次の手順では、ALLOCATE CHANNELコマンドを使用して、RMANとメディア・マネージャの基本的な通信テストを実行します。

チャネルの割当てをテストする手順

1. RMANを起動し、ターゲット・データベースおよびリカバリ・カタログ(使用している場合)に接続します。

2. メディア管理ソフトウェアの要件に従って、PARMSを指定してALLOCATE CHANNELコマンドを実行します。
次のRUNコマンドは、ベンダー固有のPARMS設定の例を示しています。

RUN
{
ALLOCATE CHANNEL c1 DEVICE TYPE sbt
PARMS 'SBT_LIBRARY=/mydir/lib/libobk.so,
ENV=(OB_DEVICE=drive1,OB_MEDIA_FAMILY=datafile_mf)';
}

3. RMAN出力を確認します。
エラー・メッセージが表示されない場合、データベースはメディア管理ライブラリを正常にロードしています。ORA-27211エラーが発生した場合、メディア管理ライブラリはロードされていません。

RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03009: failure of allocate command on c1 channel at 11/30/2007 13:57:18
ORA-19554: error allocating device, device type: SBT_TAPE, device name:
ORA-27211: Failed to load Media Management Library
Additional information: 25

この場合、メディア管理ソフトウェアの使用環境にメディア管理ライブラリが正常にインストールされているかどうかを確認し、SBT_LIBRARYパラメータの値(「メディア管理ライブラリの場所の確認」を参照)を再確認します。

SBT_LIBRARYパラメータに指定された場所またはデフォルトの場所でデータベースがメディア管理ライブラリを検出できない場合、RMANはORA-27211エラーを発行して終了します。

チャネルの割当てに失敗すると、データベースは、常に自動診断リポジトリ(ADR)・ホーム・ディレクトリのTRACEサブディレクトリにトレース・ファイルを書き込みます。出力例を次に示します。

SKGFQ OSD: Error in function sbtinit on line 2278
SKGFQ OSD: Look for SBT Trace messages in file /oracle/rdbms/log/sbtio.log
SBT Initialize failed for /oracle/lib/libobk.so

関連項目:
自動診断リポジトリを使用してデータベース操作を監視する方法については、『Oracle Database管理者ガイド』を参照してください。

メディア・マネージャでのバックアップおよびリストア操作のテスト

メディア・マネージャでチャネルの割当てをテストした後、テスト・バックアップを作成し、リストアします。たとえば、例5-7の(メディア管理ベンダーで要求されているチャネル設定に置き換える)コマンドを使用すると、メディア・マネージャにバックアップを作成できるかどうかをテストできます。データベースでサーバー・パラメータ・ファイルが使用されていない場合は、かわりに、現行の制御ファイルをバックアップします。

例5-7 テープへのサーバー・パラメータ・ファイルのバックアップ

RUN
{
ALLOCATE CHANNEL c1 DEVICE TYPE sbt
PARMS 'SBT_LIBRARY=/mydir/lib/libobk.so,
ENV=(OB_DEVICE=drive1,OB_MEDIA_FAMILY=datafile_mf)';
BACKUP SPFILE;
# If your database does not use a server parameter file, use:
# BACKUP CURRENT CONTROLFILE;
}

バックアップが正常に完了した後、サーバー・パラメータ・ファイルを初期化パラメータ・ファイルとしてリストアします。例5-8では、例5-7で作成したバックアップを一時ディレクトリにリストアします。

例5-8 テープからのサーバー・パラメータ・ファイルのリストア

RUN
{
ALLOCATE CHANNEL c1 DEVICE TYPE sbt
PARMS 'SBT_LIBRARY=/mydir/lib/libobk.so,
ENV=(OB_DEVICE=drive1,OB_MEDIA_FAMILY=datafile_mf)';
RESTORE SPFILE TO PFILE '/tmp/test_restore.f';
# If your database does not use a server parameter file, use:
# RESTORE CURRENT CONTROLFILE TO '/tmp/test_restore.f';
}

バックアップおよびリストア操作が正常に完了すると、RMANでメディア・マネージャを使用できます。バックアップの失敗には、次の状況が考えられます。

- バックアップが中断する。
バックアップが中断した場合、通常はメディア・マネージャがテープのマウントを待機していることを示します。テープ・マウント要求モードのメディア・マネージャ・ジョブの有無を確認し、問題を修正します。「メディア・マネージャにバックアップするためのRMANの構成」の手順を正しく実行していることを確認します。

- バックアップが「ORA-27211: メディア管理ライブラリのロードに失敗しました」を戻して失敗する。
このエラーは、メディア管理ソフトウェアが正しく構成されていないことを示します。「メディア・マネージャにバックアップするためのRMANの構成」の手順を正しく実行していることを確認します。また、メディア管理ソフトウェアの要件に従って、PARMSおよびFORMAT文字列を設定していることも確認します。

関連項目:
「Media Management APIのテスト」および第23章「RMAN操作のトラブルシューティング」を参照してください。

メディア・マネージャで使用するSBTチャネルの構成

この項では、メディア・マネージャで使用するチャネルを構成する方法について説明します。構成済チャネルの概要およびその使用方法については、「高度なチャネル・オプションの構成」を参照してください。

メディア・マネージャのバックアップ・ピース名

バックアップ・ピース名は、BACKUPコマンド、CONFIGURE CHANNELコマンドまたはALLOCATE CHANNELコマンドで指定するFORMAT文字列によって決まります。メディア・マネージャではバックアップ・ピース名はバックアップ・ファイルの名前とみなされるため、すべてのバックアップ・ピースはメディア管理カタログ内で一意の名前を持つ必要があります。

FORMATパラメータ内の置換変数を使用すると、一意のバックアップ・ピース名を生成できます。たとえば、%dにはデータベース名を指定し、%tにはバックアップ・タイムスタンプを指定します。ほとんどの用途に対して%Uを使用できます。この場合、RMANは一意なファイル名を自動的に生成します。バックアップ・ピース名の例としては、12i1nk47_1_1があります。FORMATパラメータを指定しない場合、RMANは%U置換変数を含む一意のファイル名を自動的に生成します。

使用しているメディア・マネージャで、ファイルの名前およびサイズに制限がある場合があります。この場合、バックアップ・ピース名がメディア・マネージャの制限に従うように、バックアップ・ピース名の指定をより制御する必要があります。たとえば、14文字のバックアップ・ピース名のみをサポートするメディア・マネージャ、特別なFORMAT文字列を必要とするメディア・マネージャなどが存在します。%U置換変数によって生成される一意の名前は、14文字を超えません。

一部のメディア・マネージャでは、バックアップまたはリストア可能なファイルの最大サイズが制限されている場合があります。RMANがこの制限を超えるバックアップ・セットを生成しないようにする必要があります。バックアップ・ピースのサイズを制限するには、CONFIGURE CHANNELおよびALLOCATE CHANNELコマンドに設定可能なパラメータMAXPIECESIZEを使用します。

関連項目:

- MAXPIECESIZEを設定する方法については、『Oracle Databaseバックアップおよびリカバリ・リファレンス』および「バックアップ・ピースの数およびサイズ」を参照してください。

- BACKUPコマンドのFORMAT文字列に使用可能な変数の完全なリストは、『Oracle Databaseバックアップおよびリカバリ・リファレンス』を参照してください。

- メディア・マネージャでの文字列の文字制限については、メディア管理ソフトウェアのドキュメントを参照してください。

自動SBTチャネルの構成

メディア・マネージャをバックアップする最も簡単な方法は、SBTチャネルを構成する方法です。「バックアップ用のデフォルト・デバイスの構成: ディスクまたはSBT」で説明されているように、テープ・デバイスをデフォルトのバックアップ先として使用できます。

メディア・マネージャで使用するチャネルを構成する手順

1. 一般的なSBTチャネルを構成します。
この構成では、「メディア・マネージャでのバックアップおよびリストア操作のテスト」でテストしたすべてのパラメータを入力します。次の例では、ベンダー固有のチャネル・パラメータを構成し、デフォルト・デバイスを設定します。

CONFIGURE CHANNEL DEVICE TYPE sbt
PARMS 'ENV=(OB_RESOURCE_WAIT_TIME=1minute,OB_DEVICE=tape1)';

2. 次のコマンドを実行して、デフォルトのデバイス・タイプをSBTに設定します。

CONFIGURE DEFAULT DEVICE TYPE TO sbt;

複数のテープ・デバイスを使用する場合は、チャネルのパラレル化を指定する必要があります(「ディスクおよびSBTデバイス用のパラレル・チャネルの構成」を参照)。次のように構成すると、2つのテープ・ドライブにパラレルにバックアップできます。

CONFIGURE DEVICE TYPE sbt PARALLELISM 2;

必要に応じて、次のコマンドを実行してチャネルの構成を確認します。

SHOW CHANNEL FOR DEVICE TYPE sbt;

3. テープへのテスト・バックアップを実行します。
次のコマンドを実行すると、サーバー・パラメータ・ファイルがテープにバックアップされます。

BACKUP SPFILE;

4. バックアップのリストを表示して、テスト・バックアップがメディア・マネージャに移動したことを確認します。

LIST BACKUP OF SPFILE;

高速リカバリ領域の構成

「高速リカバリ領域」で説明されているように、高速リカバリ領域機能を使用すると、バックアップおよびリカバリに関連する様々なファイルの作成と管理をデータベースで実行可能なディスク領域を設定できます。高速リカバリ領域を使用することをお薦めします。バックアップ計画を実装する場合の最初の手順の1つとして、高速リカバリ領域を構成することを検討してください。

この項では、高速リカバリ領域の機能の概要、この領域に格納されているファイルの識別方法、ファイル管理の規則および最も重要な構成オプションの概要について説明します。この項の内容は、次のとおりです。

- 高速リカバリ領域の概要

- 高速リカバリ領域の有効化

- 高速リカバリ領域の無効化

- 制御ファイルおよびREDOログの場所の構成

- 高速リカバリ領域内でのRMANによるファイル作成の構成

関連項目:
「高速リカバリ領域のメンテナンス」

高速リカバリ領域の概要

高速リカバリ領域には、制御ファイル、オンラインREDOログ、アーカイブREDOログ、フラッシュバック・ログおよびRMANバックアップを含めることができます。リカバリ領域内のファイルは、永続的なファイルまたは一時的なファイルに分類されます。永続的なファイルとは、データベース・インスタンスで使用されるアクティブなファイルのことです。永続的でないすべてのファイルは一時的なファイルとなります。通常、Oracle Databaseでは、バックアップの保存方針に従って不要になった一時的なファイルまたはテープにバックアップされた一時的なファイルは最終的に削除されます。

高速リカバリ領域とは、RMANのディスク・バックアップ、制御ファイルの自動バックアップおよびアーカイブREDOログ・ファイルを保持するために使用できるOracle Database管理領域です。この場所に配置されたファイルはOracle Databaseによってメンテナンスされ、生成されたファイル名はOracle Managed Files(OMF)形式でメンテナンスされます。

表5-2に、リカバリ領域内のファイル、各ファイルの分類(永続的または一時的)およびデータベースの可用性への影響を示します。

表5-2 高速リカバリ領域内のファイル

ファイル

タイプ

高速リカバリ領域にアクセスできない場合のデータベースの動作

現行の制御ファイルの多重コピー

永続的

データベースで高速リカバリ領域に格納されている制御ファイルの多重コピーに書き込むことができない場合は、インスタンスで障害が発生します。アクセス可能な多重コピーがリカバリ領域外にある場合でも障害が発生します。

参照: リカバリ領域で制御ファイルを構成する方法については、「制御ファイルの場所の構成」を参照してください。

オンラインREDOログ・ファイル

永続的

高速リカバリ領域外のアクセス可能な場所にオンラインREDOログのミラー化されたコピーが存在している場合、インスタンスの可用性は影響を受けません。そうでない場合、インスタンスで障害が発生します。

参照: リカバリ領域でオンラインREDOログ・ファイルを構成する方法については、「オンラインREDOログの場所の構成」を参照してください。

アーカイブREDOログ・ファイル

一時的

高速リカバリ領域外のアクセス可能な場所にログがアーカイブされる場合、インスタンスの可用性は影響を受けません。そうでない場合、データベースは、オンラインREDOログをアーカイブできないため最終的に停止します。

参照: リカバリ領域でアーカイブREDOログ・ファイルを構成する方法については、「アーカイブREDOログの場所の構成」を参照してください。

外部のアーカイブREDOログ・ファイル

一時的

インスタンスの可用性は影響を受けません。

注意: 外部のアーカイブREDOログ・ファイルは、LogMinerセッション用のロジカル・スタンバイ・データベースによって受信されます。通常のアーカイブ・ログとは異なり、外部のアーカイブREDOログは別のDBIDに関連付けられます。このため、ロジカル・スタンバイ・データベース上ではバックアップまたはリストアできません。

データファイルおよび制御ファイルのイメージ・コピー

一時的

インスタンスの可用性は影響を受けません。

バックアップ・ピース

一時的

インスタンスの可用性は影響を受けません。

フラッシュバック・ログ

一時的

保証付きリストア・ポイントが定義されていない場合、インスタンスの可用性は影響を受けません。この場合、データベースによって、フラッシュバック・データベースが自動的に無効となり、アラート・ログにメッセージが書き込まれてデータベース処理が続行されます。保証付きリストア・ポイントが構成されている場合、インスタンスはフラッシュバック・ログとの相互依存関係が原因で失敗します。

フラッシュバック・ログは、データベースのPoint-in-Timeリカバリ(DBPITR)にかわる有効な機能を提供するOracle Flashback Database機能によって生成されます。これらのログは一時的なファイルであり、高速リカバリ領域に格納する必要があります。他の一時的なファイルとは異なり、フラッシュバック・ログは他のメディアにバックアップできません。高速リカバリ領域にフラッシュバック・ログを格納できる十分な領域がなく、リカバリ領域が他のバックアップ保存要件を満たしている場合、そのリカバリ領域では、フラッシュバック・ログを削除することができます。

参照: フラッシュバック・ロギングを有効にする方法については、「フラッシュバック・データベースの有効化」を参照してください。

Windowsプラットフォームを使用している場合は、Volume Shadow Copy Service(VSS)をOracle VSSライターとともに使用できます。この場合、高速リカバリ領域によって、VSSスナップショットにバックアップされているファイルの管理が自動化され、必要に応じてそれらのファイルが削除されます。

関連項目:

- 第18章「フラッシュバックおよびデータベースのPoint-in-Timeリカバリの実行」

- VSS環境でバックアップを作成する方法については、『Oracle Databaseプラットフォーム・ガイドfor Microsoft Windows』を参照してください。

Oracle Managed Filesおよび自動ストレージ管理

高速リカバリ領域は、Oracle Managed Files(OMF)および自動ストレージ管理(ASM)とともに使用できます。高速リカバリ領域は、OMFの上に構築されるため、OMFを格納できるすべての場所に格納できます。リカバリ領域は、ASMで使用することもできます。

ASMストレージに高速リカバリ領域を設定しない場合でも、Oracle Managed Filesを使用してASMディスク・グループでバックアップ・ファイルを管理することができます。しかし、新しいバックアップで領域が必要となった場合にリカバリ可能目標を達成するためにファイルを自動削除する必要がなくなるため、高速リカバリ領域の主要なメリットのうちの1つ(ファイルの自動削除)が失われます。ただし、OMFの他の自動機能は動作します。

バックアップを格納する場合、高速リカバリ領域を使用せずにASMでOMFを使用することはできますが、お薦めしません。ASM下のファイルは直接操作しにくいためです。

Oracleによる高速リカバリ領域でのディスク領域の管理方法

高速リカバリ領域内の領域は、保存方針に従って保持する必要があるバックアップおよびアーカイブ・ログと、削除される可能性がある他のファイルの間でバランスが取られています。Oracle Databaseでは、他の目的のために領域の再利用が必要になるまで、対象のファイルは高速リカバリ領域から削除されません。多くの場合、最近テープに移されたファイルはディスクでリカバリに使用できます。リカバリ領域は、テープに対するキャッシュとして使用できます。Oracle Databaseでは、高速リカバリ領域が一杯になると、リカバリ領域内の領域を再利用するために必要に応じて対象のファイルが自動的に削除されます。

関連項目:
「高速リカバリ領域の削除の規則」および「高速リカバリ領域が一杯になった場合の対応」を参照してください。

高速リカバリ領域の有効化

高速リカバリ領域を有効化するには、2つの初期化パラメータを設定します。これらのパラメータを使用すると、データベース・インスタンスを停止して再起動することなく高速リカバリ領域を有効化できます。

まず、DB_RECOVERY_FILE_DEST_SIZEパラメータを使用して高速リカバリ領域のサイズを設定します。次に、DB_RECOVERY_FILE_DESTパラメータを使用してフラッシュ・リカバリ・ファイルの物理的な場所を設定します。

表5-3は、高速リカバリ領域の有効化に必須のパラメータおよびオプションのパラメータを示しています。

Oracle Real Application Clusters(Oracle RAC)データベースでは、すべてのインスタンスでこれらの初期化パラメータの値が同じである必要があります。この場所は、クラスタ・ファイル・システム、ASMまたは共有ディレクトリ上である必要があります。

表5-3 高速リカバリ領域の初期化パラメータ

初期化パラメータ

必須

説明

DB_RECOVERY_FILE_DEST_SIZE

該当

ディスク割当て制限を指定します。ディスク割当て制限は、このデータベースのリカバリ領域で使用されるデータの最大格納量をバイト単位で示したものです。このパラメータは、DB_RECOVERY_FILE_DESTの前に設定する必要があります。

DB_RECOVERY_FILE_DEST_SIZE設定には、次のディスク・オーバーヘッドは含まれていません。

- ブロック0、つまり各Oracle Databaseファイルのオペレーティング・システム・ブロック・ヘッダーは含まれません。
高速リカバリ領域に必要となる実際のディスク使用量を計算する場合は、このデータに対して10%の追加を見込みます。

- 基礎となるファイル・システムがミラー化または圧縮されている場合、あるいはOracle Databaseでは認識されないオーバーヘッドの影響を受けている場合、DB_RECOVERY_FILE_DEST_SIZEは、ディスクを占有している実際のサイズを示しません。
たとえば、リカバリ領域が2方向ミラー化ASMディスク・グループ上に存在する場合、xバイトの各ファイルは、ASMディスク・グループの2xバイトを占有します。この場合、DB_RECOVERY_FILE_DEST_SIZEは、ASMディスク・グループのディスクのサイズの半分以下に設定します。同様に、3方向ミラー化ASMディスク・グループを使用する場合、DB_RECOVERY_FILE_DEST_SIZEは、ディスク・グループ内のディスクのサイズの3分1以下にする必要があります。

DB_RECOVERY_FILE_DEST

該当

リカバリ領域の場所を指定します。ファイル・システム上のディレクトリまたはASMディスク・グループを指定することができますが、RAWディスクは指定できません。この場所は、ディスク割当て制限に対応できる十分な大きさである必要があります。

DB_FLASHBACK_RETENTION_TARGET

該当せず

データベースをフラッシュバックできる時点の上限(分)を指定します。このパラメータは、フラッシュバック・データベースでのみ必要です。

このパラメータによって、リカバリ領域で保持されるフラッシュバック・ログ・データのサイズが間接的に決定されます。ただし、データベースによって生成されるフラッシュバック・ログのサイズは、データベース・ワークロードによって大幅に異なる可能性があります。一定期間に行われるデータベース更新によって影響を受けるブロックが増えると、この期間に生成されるフラッシュバック・ログ・データによって使用されるディスク領域も増えます。

関連項目:
ALTER SYSTEMの構文については、『Oracle Database SQL言語リファレンス』を参照してください。データベース初期化パラメータを設定および変更する方法の詳細は、『Oracle Database管理者ガイド』を参照してください。

高速リカバリ領域のサイズを設定する場合の考慮事項

高速リカバリ領域は、大きいほど便利になります。高速リカバリ領域は、表5-2に示されているファイルを格納できる十分なサイズにすることをお薦めします。リカバリ領域には、データベース内のすべてのデータファイルのコピーおよび選択したバックアップ計画で使用される増分バックアップを格納できる必要があります。

前述のサイズの領域を保持することが難しい場合は、最も重要な表領域のバックアップ、およびテープにまだコピーされていないすべてのアーカイブ・ログを保持できるサイズの領域を作成することをお薦めします。最低限、高速リカバリ領域は、テープにコピーされていないアーカイブREDOログを格納できるサイズにする必要があります。リカバリ領域に新しいフラッシュバック・ログを格納できる十分な領域がなく、リカバリ領域が他のバックアップ保存要件を満たしている場合、そのリカバリ領域では、古いフラッシュバック・ログを削除して領域を確保することができます。

有効な高速リカバリ領域のサイズを判断する方法は、次の状況によって異なります。

- データベースに、頻繁に変更されるデータ・ブロックが少数含まれているか、多数含まれているか

- バックアップをディスクにのみ格納するか、ディスクおよびテープに格納するか

- 冗長性に基づいたバックアップの保存方針を使用するか、リカバリ期間に基づいた保存方針を使用するか

- 論理エラーに対応する場合のPoint-in-Timeリカバリの代替方法として、フラッシュバック・データベースの使用を計画するか、保証付きリストア・ポイントの使用を計画するか

フラッシュバック・ロギングを有効にする場合、生成されるフラッシュバック・ログのサイズは、生成されるREDOログのサイズと同程度になります。たとえば、DB_FLASHBACK_RETENTION_TARGETを24時間に設定し、1日に20GBのREDOがデータベースで生成される場合は、目安として20から30GBのディスク領域をフラッシュバック・ログに使用できるようにします。フラッシュバック・ロギングが有効になっている場合、同じ目安が保証付きリストア・ポイントに適用されます。たとえば、毎日20GBのREDOがデータベースで生成され、保証付きリストア・ポイントが1日保持される場合は、20GBから30GBのディスク領域を割り当てます。

バックアップの保存方針がREDUNDANCY 1に設定されている場合に高速リカバリ領域のサイズを決定し、増分更新バックアップの使用に関してOracle推奨の計画に従うとします。この例では、次の式を使用して、ディスク割当て制限を見積もります。nは、増分更新の間隔(日)です。yは、ロジカル・スタンバイ・データベースでの外部のアーカイブREDOログの適用の遅延です。

Disk Quota =
Size of a copy of database +
Size of an incremental backup +
Size of (n+1) days of archived redo logs +
Size of (y+1) days of foreign archived redo logs (for logical standby) +
Size of control file +
Size of an online redo log member * number of log groups +
Size of flashback logs (based on DB_FLASHBACK_RETENTION_TARGET value)

高速リカバリ領域の場所を設定する場合の考慮事項

高速リカバリ領域は、データファイル、制御ファイル、オンラインREDOログなどのアクティブなデータベース・ファイルがデータベースによって保持されているデータベース領域とは別のディスクに配置します。データベース領域と同じディスクに高速リカバリ領域を設定している場合、メディアで障害が発生すると、アクティブなデータベース・ファイルとバックアップの両方を失う可能性があります。

DB_RECOVERY_FILE_DESTは、DB_CREATE_FILE_DEST初期化パラメータまたはDB_CREATE_ONLINE_LOG_DEST_n初期化パラメータのいずれとも異なる値に設定することをお薦めします。DB_RECOVERY_FILE_DESTがこれらのパラメータと同じ場合は、データベースによってアラート・ログに警告が書き込まれます。

次のいずれかの条件を満たす場合、複数のデータベースでDB_RECOVERY_FILE_DESTに同じ値を指定できます。

- DB_UNIQUE_NAME初期化パラメータが指定されている2つのデータベースで、DB_UNIQUE_NAMEの値が同じではない。

- DB_UNIQUE_NAMEが指定されていないデータベースで、2つのデータベースのDB_NAMEの値が同じではない。

このように、複数のデータベースで1つのリカバリ領域を共有する場合、リカバリ領域の場所は、すべてのデータベースのリカバリ・ファイルを保持できるサイズにする必要があります。データベースのDB_RECOVERY_FILE_DEST_SIZEの値を追加し、ミラー化または圧縮などのオーバーヘッドを見込みます。

高速リカバリ領域の場所および初期サイズの設定

表5-3は、高速リカバリ領域を有効にするために設定する必要がある初期化パラメータを示しています。この項では、リカバリ領域の場所の指定方法およびその初期サイズの設定方法について説明します。

高速リカバリ領域の最適なサイズを決定する手順

1. フラッシュバック・ロギングまたは保証付きリストア・ポイントを使用する場合は、V$ARCHIVED_LOGを問い合せて、DB_FLASHBACK_RETENTION_TARGETに設定する時間にデータベースで生成されるREDOのサイズを決定します。

2. リカバリ領域のサイズを設定します。
フラッシュバック・ロギングまたは保証付きリストア・ポイントを使用する場合は、手順1で取得したサイズの値が設定に組み込まれていることを確認します。次のいずれかの方法で、DB_RECOVERY_FILE_DEST_SIZE初期化パラメータを設定します。

- データベースを停止して、データベースの初期化パラメータ・ファイルにDB_RECOVERY_FILE_DEST_SIZEパラメータを設定します。次に例を示します。

DB_RECOVERY_FILE_DEST_SIZE = 10G

- データベースがオープン状態のときに、SQL文ALTER SYSTEM SETを使用してパラメータを指定します。次に例を示します。

ALTER SYSTEM SET
DB_RECOVERY_FILE_DEST_SIZE = 10G
SCOPE=BOTH SID='*';

- Database Configuration Assistantを使用してサイズを設定します。

3. リカバリ領域の場所を設定します。
次のいずれかの方法で、初期化パラメータを設定します。

- データベースの初期化パラメータ・ファイルにDB_RECOVERY_FILE_DESTを設定します。次に例を示します。

DB_RECOVERY_FILE_DEST = '/u01/oradata/rcv_area'

- データベースがオープン状態のときに、SQL文ALTER SYSTEM SETを使用してDB_RECOVERY_FILE_DESTを指定します。次に例を示します。

ALTER SYSTEM SET
DB_RECOVERY_FILE_DEST = '+disk1'
SCOPE=BOTH SID='*';

- Database Configuration Assistantを使用して場所を設定します。

フラッシュバック・ロギングを使用しない場合は、データベースをオープンし(クローズしている場合)、残りの手順は実行しないでください。

4. フラッシュバック・ロギングが有効になっている場合は、DB_FLASHBACK_RETENTION_TARGETで指定された期間、通常のワークロードでデータベースを実行します。
これによって、データベースでフラッシュバック・ログの代表的なサンプルを生成できます。

5. V$FLASHBACK_DATABASE_LOGビューを次のように問い合せます。

SELECT ESTIMATED_FLASHBACK_SIZE
FROM   V$FLASHBACK_DATABASE_LOG;

フラッシュバック・データベースが有効になっているため、データベース・ワークロードに基づいて、現在のフラッシュバック保存目標を達成するために必要なディスク領域の見積りが結果として表示されます。

6. 必要に応じて、DB_FLASHBACK_RETENTION_TARGETで指定された期間に生成された実際のフラッシュバック・ログのサイズに基づいて、フラッシュバック・ログ領域要件を調整します。

関連項目:
「高速リカバリ領域でのフラッシュバック・ログの領域の管理」

高速リカバリ領域の無効化

フラッシュバック・データベースが有効になっている場合、またはアーカイブ・ログに高速リカバリ領域を使用している場合は、次の中から適切な手順を実行します。それ以外の場合は、手順3に進みます。

1. フラッシュバック・データベースが有効になっている場合は、高速リカバリ領域を無効にする前に無効にします。

ALTER DATABASE FLASHBACK OFF;

2. アーカイブ・ログに高速リカバリ領域を使用している場合は、初期化パラメータLOG_ARCHIVE_DEST_nを設定し、高速リカバリ領域外の場所を使用します。
たとえば、LOG_ARCHIVE_DEST_1用の高速リカバリ領域を高速リカバリ領域外の場所に変更するには、ALTER SYSTEM SETコマンドを使用します。

LOG_ARCHIVE_DEST_1='LOCATION=USE_DB_RECOVERY_FILE_DEST'

ALTER SYSTEM SET LOG_ARCHIVE_DEST_1='LOCATION=/ORACLE/DBS/';

3. 高速リカバリ領域の初期化パラメータの無効化

ALTER SYSTEM SET DB_RECOVERY_FILE_DEST='';

制御ファイルおよびREDOログの場所の構成

「高速リカバリ領域の概要」で説明されているように、現行の制御ファイルおよびオンラインREDOログの多重コピーのみが永続的なファイルです。この項では、これらのファイルおよびアーカイブ・ログの場所の設定方法について説明します。

オンラインREDOログの場所の構成

オンラインREDOログ・ファイルが作成される場所を決定する初期化パラメータは、DB_CREATE_ONLINE_LOG_DEST_n、DB_RECOVERY_FILE_DESTおよびDB_CREATE_FILE_DESTです。これらのパラメータの組合せによるオンラインREDOログの作成への影響の詳細は、『Oracle Database SQL言語リファレンス』のCREATE DATABASE文のLOGFILE句に関する説明を参照してください。

次のSQL文を使用すると、高速リカバリ領域にオンラインREDOログを作成できます。

- CREATE DATABASE

- ALTER DATABASE ADD LOGFILE

- ALTER DATABASE ADD STANDBY LOGFILE

- ALTER DATABASE OPEN RESETLOGS

高速リカバリ領域に作成されるオンライン・ログのデフォルトのサイズは100MBです。ログ・メンバーのファイル名は、データベースによって自動的に生成されます。

制御ファイルの場所の構成

初期化パラメータCONTROL_FILES、DB_CREATE_ONLINE_LOG_DEST_n、DB_RECOVERY_FILE_DESTおよびDB_CREATE_FILE_DESTが相互に作用して、データベース制御ファイルが作成される場所が決まります。これらのパラメータの相互作用の詳細は、『Oracle Database SQL言語リファレンス』のCREATE CONTROLFILEのセマンティクスに関する説明を参照してください。

データベースによってOracle管理の制御ファイルが作成され、そのデータベースでサーバー・パラメータ・ファイルが使用されている場合は、そのサーバー・パラメータ・ファイルにCONTROL_FILES初期化パラメータが設定されます。このデータベースでクライアント側の初期化パラメータ・ファイルが使用されている場合は、初期化パラメータ・ファイルにCONTROL_FILES初期化パラメータを手動で設定する必要があります。

アーカイブREDOログの場所の構成

アーカイブ・ログはデータベースによって自動的に管理されるため、アーカイブの場所として高速リカバリ領域を使用することをお薦めします。高速リカバリ領域内のアーカイブ・ログに対して生成されるファイル名はOracle Managed Files用のファイル名であり、LOG_ARCHIVE_FORMATでは決定されません。どのアーカイブ・スキームを選択した場合も、常にアーカイブREDOログの複数のコピーを作成することをお薦めします。

次に、アーカイブREDOログ用の基本的なオプションを推奨順に示します。

1. 高速リカバリ領域に対してのみアーカイブを有効にし、ディスクをミラー化してアーカイブREDOログの保護に必要な冗長性を作成します。
DB_RECOVERY_FILE_DESTを指定し、LOG_ARCHIVE_DEST_nを指定しない場合は、LOG_ARCHIVE_DEST_10が暗黙的にリカバリ領域に設定されます。LOG_ARCHIVE_DEST_10を空の文字列に設定すると、この動作を無効にできます。

2. 高速リカバリ領域に対してアーカイブを有効にし、他のLOG_ARCHIVE_DEST_n初期化パラメータを高速リカバリ領域外の場所に設定します。
高速リカバリ領域が構成されている場合は、LOG_ARCHIVE_DEST_nパラメータをLOCATION=USE_DB_RECOVERY_FILE_DESTに設定すると、高速リカバリ領域をアーカイブ先として追加できます。

3. 高速リカバリ領域外の場所にのみアーカイブされるように、LOG_ARCHIVE_DEST_n初期化パラメータを設定します。

高速リカバリ領域を使用する場合、LOG_ARCHIVE_DESTおよびLOG_ARCHIVE_DUPLEX_DEST初期化パラメータは使用できません。これらのパラメータを使用すると、インスタンスを開始できなくなります。かわりに、LOG_ARCHIVE_DEST_nパラメータを設定します。データベースでLOG_ARCHIVE_DEST_nが使用されている場合は、リカバリ領域を構成できます。

また、アーカイブを有効にしており、LOG_ARCHIVE_DEST、LOG_ARCHIVE_DEST_nまたはDB_RECOVERY_FILE_DESTのいずれの値も設定していない場合、REDOログはプラットフォーム固有のデフォルトの場所にアーカイブされることにも注意してください。たとえば、Solarisでのデフォルトの場所は?/dbsです。

関連項目:
LOG_ARCHIVE_DEST_nパラメータのセマンティクスの詳細は、『Oracle Databaseリファレンス』を参照してください。

高速リカバリ領域内でのRMANによるファイル作成の構成

この項では、高速リカバリ領域でファイルを作成するためのRMANコマンドまたは暗黙的な処理(制御ファイルの自動バックアップなど)について説明します。また、コマンドによって高速リカバリ領域または別の場所のいずれかにファイルを作成するかどうかを制御する方法について説明します。コマンドを次に示します。

- BACKUP
ディスク・バックアップの目的でFORMAT句を指定していない場合、RMANは、Oracle Managed Filesの名前形式の名前が付いたバックアップ・ピースおよびイメージ・コピーを高速リカバリ領域に作成します。高速リカバリ領域が有効になっていて、BACKUPまたはチャネルでFORMATを指定している場合、RMANは、リカバリ領域ではなくプラットフォーム固有の場所にバックアップを作成します。

- 制御ファイルの自動バックアップ
RMANは、制御ファイルの自動バックアップを高速リカバリ領域に作成できます。RMANコマンドCONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK CLEARを使用すると、ディスク上での制御ファイルの自動バックアップ場所を指定したすべての構成済書式オプションをクリアできます。他の格納場所が構成されていない場合、RMANは高速リカバリ領域に制御ファイルの自動バックアップを作成します。

- RESTORE ARCHIVELOG
LOG_ARCHIVE_DEST_nパラメータのいずれかをLOCATION=USE_DB_RECOVERY_FILE_DESTに明示的または暗黙的に設定します。SET ARCHIVELOG DESTINATIONを指定してこの動作を無効にしない場合、RMANはアーカイブREDOログ・ファイルを高速リカバリ領域にリストアします。

- RECOVER DATABASEまたはRECOVER TABLESPACE、RECOVER ... BLOCK、およびFLASHBACK DATABASE
これらのコマンドを使用すると、コマンドからの要求に応じて、メディア・リカバリ中に使用されるアーカイブREDOログ・ファイルをバックアップからリストアできます。RMANは、これらの操作中に必要なすべてのREDOログ・ファイルを高速リカバリ領域にリストアし、メディア・リカバリ中に適用した後で削除します。

リストアされたアーカイブ・ログを高速リカバリ領域に格納するには、LOG_ARCHIVE_DEST_nパラメータのいずれかをLOCATION = USE_DB_RECOVERY_FILE_DESTに設定します。リストアされたログを他の場所に格納するためのSET ARCHIVELOG DESTINATIONを使用していないことを確認してください。

バックアップの保存方針の構成

「バックアップの保存方針」で説明されているように、バックアップの保存方針では、データのリカバリ要件に従って保存する必要があるバックアップを指定します。この保存方針は、リカバリ期間または冗長性のいずれに基づいていてもかまいません。保存方針を指定するには、CONFIGURE RETENTION POLICYコマンドを使用します。

関連項目:
CONFIGUREの構文については、『Oracle Databaseバックアップおよびリカバリ・リファレンス』を参照してください。

冗長性に基づく保存方針の構成

CONFIGURE RETENTION POLICYコマンドのREDUNDANCYパラメータでは、RMANが保持する必要がある各データファイルおよび制御ファイルの全体またはレベル0のバックアップの数を指定します。特定のデータファイルまたは制御ファイルの全体またはレベル0のバックアップの数がREDUNDANCYの設定を超えると、RMANは余分なバックアップを不要とみなします。デフォルトの保存方針は、REDUNDANCY 1です。

作成するバックアップが増えるに従い、RMANは保存するバックアップおよび不要なバックアップを記録します。RMANは、不要でないバックアップのリカバリに必要なすべてのアーカイブ・ログおよび増分バックアップを保持します。

月曜日、火曜日、水曜日および木曜日にデータファイル7の全体バックアップを作成するとします。このデータファイルの全体バックアップは4つになります。REDUNDANCYが2の場合、月曜日と火曜日のバックアップは不要になります。金曜日にもう1つのバックアップを作成すると、データファイル7の水曜日のバックアップが不要となります。

REDUNDANCYが1であるという別の場合を想定します。月曜日の正午にレベル0のデータベース・バックアップを実行し、火曜日と水曜日の正午にレベル1の累積バックアップを、木曜日の正午にレベル0のバックアップを実行します。それぞれの日次バックアップの直後にDELETE OBSOLETEコマンドを実行します。水曜日にDELETEコマンドを実行しても、火曜日のレベル1のバックアップは冗長でないため、削除されません。火曜日のレベル1のバックアップは、火曜日の正午から水曜日の正午までの時点に月曜日のレベル0のバックアップをリカバリするために使用できます。ただし、木曜日のDELETEコマンドでは、以前のレベル0およびレベル1のバックアップが削除されます。

次の例のように、RMANプロンプトでCONFIGURE RETENTION POLICYコマンドを実行します。

CONFIGURE RETENTION POLICY TO REDUNDANCY 3;

関連項目:
「保存方針に基づく不要なRMANバックアップの削除」

リカバリ期間に基づく保存方針の構成

CONFIGUREコマンドのRECOVERY WINDOWパラメータでは、現時点と最初のリカバリ可能ポイント間の日数を指定します。RMANは、全体バックアップまたはレベル0の増分バックアックがリカバリ期間内にある場合はいずれのバックアップも不要とみなしません。また、RMANは、リカバリ期間内のランダムな時点までリカバリする必要があるすべてのアーカイブ・ログおよびレベル1増分バックアップを保持します。

RMANプロンプトでCONFIGURE RETENTION POLICYコマンドを実行します。次の例では、先週の任意の時点までデータベースをリカバリできます。

CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF 7 DAYS;

RMANは、リカバリ期間によって不要とみなされたバックアップを自動的には削除しません。かわりに、REPORT OBSOLETEの出力やV$BACKUP_FILESのOBSOLETE列に、OBSOLETEとして表示します。DELETE OBSOLETEコマンドを実行すると、RMANは不要なファイルを削除します。

関連項目:
「保存方針に基づく不要なRMANバックアップの削除」

保存方針の無効化

保存方針を無効にすると、RMANはすべてのバックアップを必要とみなします。保存方針を無効にするには、次のコマンドを実行します。

CONFIGURE RETENTION POLICY TO NONE;

保存方針をNONEに構成することは、保存方針を消去することとは異なります。保存方針を消去すると、デフォルトのREDUNDANCY 1の設定に戻りますが、NONEでは保存方針が完全に無効になります。

保存方針を無効にし、保存方針オプションをコマンドに渡さずにREPORT OBSOLETEまたはDELETE OBSOLETEを実行すると、不要なバックアップを判断する保存方針が存在しないため、RMANはエラーを発行します。

注意:
高速リカバリ領域を使用している場合は、保存方針が無効になっている状態でデータベースを実行しないでください。ファイルが不要とみなされないと、ファイルを高速リカバリ領域から削除できるのは、そのファイルが他のディスクの場所またはテープなどの3次ストレージ・デバイスにバックアップされた場合のみになります。このアクションによって、リカバリ領域内のすべての領域が使用され、データベースの通常の操作に影響を及ぼす可能性があります。「Oracleによる高速リカバリ領域でのディスク領域の管理方法」を参照してください。

バックアップの最適化およびCONFIGUREコマンド

CONFIGUREコマンドを実行して、バックアップの最適化の有効と無効を切り替えます。バックアップを最適化すると、同じファイルまたは同じバージョンのファイルがバックアップされている場合などの特定の状況においてファイルのバックアップがスキップされます。

バックアップの最適化の概要

バックアップの最適化を有効にすると、BACKUPコマンドは、同一のファイルが指定のデバイス・タイプにすでにバックアップされている場合に、ファイルのバックアップをスキップします。表5-4に、バックアップされているファイルと同一かどうかを判断するためにRMANで使用される基準を示します。

表5-4 同一ファイルかどうかを判断する基準

ファイル・タイプ

同一ファイルかどうかを判断する基準

データファイル

すでにバックアップに含まれているデータファイルと同じDBID、チェックポイントSCN、作成SCN、およびRESETLOGSのSCNと時刻。データファイルは、NORMALモードでオフラインにされているか、読取り専用か、または正常にクローズされている必要があります。

アーカイブ・ログ

同じDBID、スレッド、順序番号、およびRESETLOGSのSCNと時刻

バックアップ・セット

同じDBID、バックアップ・セット・レコードIDおよびスタンプ

ファイルが同一でありバックアップされているとRMANが判断した場合、そのファイルはスキップ対象になります。 ただし、RMANは、ファイルをスキップするかどうかについて、さらに詳細な確認を行う必要があります。これは、RMANが指定されたデバイス・タイプに十分なバックアップを保持しているかどうかを判断するアルゴリズムに、保存方針とバックアップ多重化機能の両方の要素があるためです。

RMANは、次の条件を満たしている場合にバックアップの最適化を使用します。

- CONFIGURE BACKUP OPTIMIZATION ONコマンドを実行し、バックアップの最適化を有効にしている。

- BACKUP DATABASE、ALLまたはLIKEオプションを指定したBACKUP ARCHIVELOG、BACKUP BACKUPSET ALL、BACKUP RECOVERY AREA、BACKUP RECOVERY FILESあるいはBACKUP DATAFILECOPYを実行する。

注意:
BACKUP RECOVERY AREAまたはBACKUP RECOVERY FILESと組み合せてTO DESTINATIONを使用すると、RMANは、指定したTO DESTINATIONの場所に同じバックアップを持つファイルのバックアップのみをスキップします。

- 1つのタイプのチャネルのみを割り当てている(1つのBACKUPコマンドでディスクとSBTチャネルを併用していない)。

注意:
UNDOのバックアップの最適化では、RMANは、すでにコミットされているトランザクションの(バックアップのリカバリに不要となった)UNDOの変更を除外します。バックアップの最適化を有効または無効にすることができますが、UNDOのバックアップの最適化は組込み動作です。

たとえば、バックアップの最適化を構成したと想定します。これらのコマンドは、データベース、すべてのアーカイブ・ログおよびすべてのバックアップ・セットをテープにバックアップします。

BACKUP DEVICE TYPE sbt DATABASE PLUS ARCHIVELOG;
BACKUP DEVICE TYPE sbt BACKUPSET ALL;

バックアップされたすべてのファイルが最後のバックアップ以降に変更されていない場合、RMANはこれらのファイルを再度バックアップしません。また、RMANは、ファイルがすでにバックアップされているため、コマンドで指定されたすべてのファイルをスキップする場合、エラーを通知しません。

BACKUPコマンドにFORCEオプションを指定すると、いつでも最適化を無効にできます。たとえば、次のコマンドを実行します。

BACKUP DATABASE FORCE;
BACKUP ARCHIVELOG ALL FORCE;

関連項目:
バックアップの最適化の規則の詳細は、『Oracle Databaseバックアップおよびリカバリ・リファレンス』のCONFIGUREエントリに関する項を参照してください。

SBTバックアップのバックアップの最適化への保存方針の影響

バックアップの最適化は、SBTデバイスへのバックアップ時に常に適用されるわけではありません。リカバリ期間および冗長性に基づく保存方針の通常のバックアップの最適化の動作の例外については、以降の項を参照してください。

注意:
メディア・マネージャで独自の内部期限切れ方針を使用している場合、バックアップの最適化を有効にするには、注意が必要です。定期的にCROSSCHECKコマンドを実行して、RMANリポジトリをメディア・マネージャと同期化してください。同期化を実行しないと、RMANは、テープ上に格納されたバックアップがメディア・マネージャによって廃棄されたことを認識できず、最適化によってバックアップをスキップする場合があります。

リカバリ期間に基づく保存方針によるSBTバックアップのバックアップの最適化

バックアップの最適化が有効になっていて、リカバリ期間に基づくバックアップの保存方針が構成されているとします。この場合、SBTバックアップを実行すると、RMANは、最新のバックアップがリカバリ期間の前に作成されているデータファイルを常にバックアップします。たとえば、次の例を想定します。

- 現在の時点は2月21日です。

- リカバリ期間は7日です。

- 表領域toolsのテープへの最新のバックアップは1月3日に作成されています。

- 表領域toolsは読取り専用です。

2月21日に、表領域toolsをテープにバックアップするコマンドを発行します。この表領域は読取り専用であるため、1月3日のバックアップ以降も変更されていませんが、RMANはバックアップを実行します。これは、7日間のリカバリ期間内にこの表領域のバックアップが存在しないためです。

この動作によって、メディア・マネージャは古いテープを期限切れにすることができます。この動作が行われない場合、メディア・マネージャは、表領域toolsの1月3日のバックアップを無期限に保持し続けることになります。2月21日に表領域toolsのより新しいバックアップを作成することによって、メディア・マネージャは、1月3日のバックアップを含むテープを期限切れとして処理できます。

冗長性に基づく保存方針によるSBTバックアップのバックアップの最適化

冗長性に基づく保存方針を構成するとします。この場合、RMANは、SBTへのオフラインまたは読取り専用のデータファイルのバックアップがr + 1個存在する場合にのみ、これらのファイルのバックアップをスキップします。ここで、rはCONFIGURE RETENTION POLICY TO REDUNDANCY rで設定された値です。

たとえば、バックアップの最適化を有効にして、次の保存方針を設定するとします。

CONFIGURE DEFAULT DEVICE TYPE TO sbt;
CONFIGURE BACKUP OPTIMIZATION ON;
CONFIGURE RETENTION POLICY TO REDUNDANCY 2;

この例では、RMANは、3つの同一のファイルがすでにバックアップされている場合にのみ、バックアップをスキップします。ここで、これまでにバックアップしたことのない読取り/書込み表領域usersに対して、1週間の間に表5-5に示す処理を実行するとします。

表5-5 バックアップの最適化への冗長性設定の影響

曜日

処理

結果

冗長バックアップ

月曜日

usersをNORMALモードでオフラインにします。

火曜日

BACKUP DATABASE

users表領域がバックアップされます。

水曜日

BACKUP DATABASE

users表領域がバックアップされます。

木曜日

BACKUP DATABASE

users表領域がバックアップされます。

火曜日のバックアップ

金曜日

BACKUP DATABASE

users表領域はバックアップされません。

火曜日のバックアップ

土曜日

BACKUP DATABASE

users表領域はバックアップされません。

火曜日のバックアップ

日曜日

DELETE OBSOLETE

火曜日のバックアップが削除されます。

月曜日

BACKUP DATABASE

users表領域がバックアップされます。

水曜日のバックアップ

火曜日、水曜日および木曜日のバックアップによって、オフライン表領域usersがバックアップされ、3つ(冗長性設定+ 1)のバックアップが存在する必要があるという条件を満たします。金曜日および土曜日のバックアップでは、バックアップの最適化のため、users表領域のバックアップは行われません。usersの火曜日のバックアップは、木曜日以降に不要となります。

日曜日にすべての不要なバックアップを削除すると、usersの火曜日のバックアップも削除されます。火曜日のバックアップは、保存方針設定によって不要となります。月曜日のデータベース全体のバックアップによって、users表領域がバックアップされ、3つ(冗長性設定+ 1)のバックアップが存在する必要があるという条件を満たします。この方法で、時間の経過とともにテープを再利用できます。

関連項目:
「バックアップの最適化およびCONFIGUREコマンド」

バックアップの最適化の構成

デフォルトでは、バックアップの最適化はOFFに構成されています。SHOW BACKUP OPTIMIZATIONコマンドを使用すると、バックアップの最適化の現行の設定を表示できます。

バックアップの最適化を構成する手順

1. RMANを起動し、ターゲット・データベースおよびリカバリ・カタログ(使用している場合)に接続します。

2. SHOW BACKUP OPTIMIZATIONコマンドを実行して、最適化が現在有効になっているかどうかを確認します。
たとえば、次のコマンドを入力します。

SHOW BACKUP OPTIMIZATION;

SHOW BACKUP OPTIMIZATIONの出力例を次に示します。

RMAN configuration parameters for database with db_unique_name PROD1 are:
CONFIGURE BACKUP OPTIMIZATION OFF;

3. 次のコマンドを実行して、バックアップの最適化を有効にします。

CONFIGURE BACKUP OPTIMIZATION ON;

関連項目:
RMANバックアップを最適化する方法の例は、「バックアップの最適化を使用したファイルのスキップ」を参照してください。

アーカイブREDOログの削除方針の構成

RMANを使用すると、アーカイブREDOログがディスクからの削除対象となる場合を制御する永続的な構成を作成できます。

アーカイブREDOログの削除方針

CONFIGURE ARCHIVELOG DELETION POLICYコマンドを使用すると、アーカイブREDOログが削除対象になる場合を指定できます。この削除方針は、高速リカバリ領域を含むすべてのアーカイブ先に適用されます。

アーカイブREDOログは、データベースによって自動的に削除されるか、またはユーザーが実行したRMANコマンドによって削除されます。高速リカバリ領域内のログのみが、データベースによって自動的に削除されます。高速リカバリ領域内のアーカイブREDOログ・ファイルの場合は、データベースによってできるかぎり保存され、追加のディスク領域が必要になると対象となるログが削除されます。高速リカバリ領域の内部にあるか外部にあるかに関係なく、BACKUP ... DELETE INPUTまたはDELETE ARCHIVELOGコマンドを発行すると、どの場所からも対象のログを手動で削除できます。

アーカイブREDOログの削除方針が無効になっている場合

デフォルトでは、アーカイブREDOログの削除方針はありません。そのためアーカイブREDOログの方針はNONE句に設定されています。この特定の場合、高速リカバリ領域は、ディスクまたはSBTに1回以上バックアップされているとき、またはバックアップ保存方針に従ってログが不要になったときに、リカバリ領域内のアーカイブREDOログ・ファイルを削除対象であるとみなします。バックアップ保存方針では、ログは保証付きリストア・ポイントで不要である場合およびOracle Flashback Databaseで不要である場合にのみ不要とみなされます。アーカイブREDOログは、ログがSYSDATE-'DB_FLASHBACK_RETENTION_TARGET'より後に作成された場合にフラッシュバック・データベースで必要とされます。

関連項目:

- 方針のオプションの詳細は、『Oracle Databaseバックアップおよびリカバリ・リファレンス』のCONFIGURE ARCHIVELOG DELETION POLICYエントリを参照してください。

- Data Guard環境でのアーカイブ・ログの削除方針の構成方法については、『Oracle Data Guard概要および管理』を参照してください。

アーカイブREDOログの削除方針が有効になっている場合

CONFIGURE ARCHIVELOG DELETION POLICY BACKED UP integer TIMES TO DEVICE TYPEコマンドを使用すると、アーカイブ・ログの削除方針を有効化できます。この構成では、指定した数のアーカイブ・ログのバックアップが指定したデバイス・タイプに存在する場合にのみアーカイブ・ログが削除対象になるように指定されます。

削除方針がBACKED UP integer TIMES句で構成されている場合、指定したデバイス・タイプ上にinteger個のバックアップがすでに存在していないかぎり、BACKUP ARCHIVELOGコマンドはログをコピーします。ログのinteger個のバックアップが存在している場合、BACKUP ARCHIVELOGコマンドはログをスキップします。これによって、アーカイブ・ログの削除方針は、デフォルトのBACKUP ARCHIVELOGコマンドのNOT BACKED UP integer TIMES句として機能します。BACKUPコマンドにFORCEオプションを指定すると、削除方針を無効にできます。

アーカイブ・ログの削除方針には、Data Guard環境固有のオプションもあります。たとえば、APPLIED ON STANDBY句を指定すると、RMANは、すべての必須のリモート転送先でログが適用された後、ログを削除します。SHIPPED TO STANDBYを指定すると、RMANは、すべての必須のスタンバイ転送先にログが転送された後、ログを削除します。

関連項目:

- 方針のオプションの詳細は、『Oracle Databaseバックアップおよびリカバリ・リファレンス』のCONFIGURE ARCHIVELOG DELETION POLICYエントリを参照してください。

- Data Guard環境でのアーカイブ・ログの削除方針の構成方法については、『Oracle Data Guard概要および管理』を参照してください。

アーカイブREDOログの削除方針の有効化

この項では、アーカイブREDOログの削除方針の構成方法について説明します。デフォルトでは、削除方針はNONEに設定されています。

アーカイブREDOログの削除方針を有効にする手順

1. RMANを起動し、ターゲット・データベースおよびリカバリ・カタログ(使用している場合)に接続します。

2. 必要なオプションを指定して、CONFIGURE ARCHIVELOG DELETION POLICYコマンドを実行します。
次の例では、アーカイブREDOログが2回以上テープにバックアップされた場合、アーカイブREDOログが高速リカバリ領域およびすべてのローカルのアーカイブ先からの削除の対象となるように指定しています。

CONFIGURE ARCHIVELOG DELETION POLICY
TO BACKED UP 2 TIMES TO SBT;

関連項目:

- 「バックアップ後のアーカイブREDOログの削除」

- Data Guard環境でのアーカイブREDOログの管理方法については、『Oracle Data Guard概要および管理』を参照してください。

- CONFIGURE ARCHIVELOG DELETION POLICYコマンドの詳細およびアーカイブ・ログが削除対象となる条件については、『Oracle Databaseバックアップおよびリカバリ・リファレンス』を参照してください。

Data Guard環境でのRMANの構成

Data Guard環境でRMANを使用する場合、CONFIGUREコマンドを使用すると、この環境での物理データベースの設定の登録および構成を行うことができます。RMANは、DB_UNIQUE_NAME初期化パラメータを使用して、データベースを別のデータベースと区別します。したがって、Data Guard環境でDB_UNIQUE_NAMEの一意性を維持することが重要です。

Data Guard環境内のデータベースに構成を作成または変更する場合、RMANはリカバリ・カタログに接続している必要があります。SET DBIDコマンドを使用して、RMANセッションでDBIDを設定する場合は、Data Guard環境でRMANがTARGETとしてデータベースに接続されていなくても、スタンバイ・データベースを構成できます。この場合は、作成されていないスタンバイ・データベースに構成を作成することもできます。

次の形式のCONFIGUREコマンドを使用できます。

- CONFIGURE DB_UNIQUE_NAMEを使用すると、フィジカル・スタンバイ・データベースへの接続が定義され、新しいデータベースが暗黙的に登録されます。
RMANがTARGETとして初めてスタンバイ・データベースに接続する場合は、新しいスタンバイ・データベースも自動的に登録されます。

- CONFIGURE FOR DB_UNIQUE_NAMEを使用すると、Data Guard環境でのデータベースの設定が構成されます。
たとえば、環境内の指定したデータベースまたはすべてのデータベースに対して、チャネルやデフォルトのデバイスなどを構成できます。SHOW ALL FOR DB_UNIQUE_NAMEを使用すると、特定のスタンバイ・データベースの構成を表示でき、SHOW ALL FOR DB_UNIQUE_NAME ALLを使用すると、認識されるすべてのデータベースの構成を表示できます。

Data Guard環境には、Data Guardにのみ関連する多くの考慮事項があります。たとえば、アーカイブ・ログがスタンバイ・データベースに転送されたか、適用されたかに基づいて、アーカイブREDOログの削除方針を構成できます。

関連項目:

- スタンバイ・データベースで使用するためにRMAN環境を構成する方法については、『Oracle Data Guard概要および管理』を参照してください。

- CONFIGURE ARCHIVELOG DELETION POLICYコマンドの詳細およびアーカイブ・ログが削除対象となる条件については、『Oracle Databaseバックアップおよびリカバリ・リファレンス』を参照してください。

6 RMAN環境の構成: 高度なトピック

この章では、設定および構成作業を実行する方法について説明します。この章の内容は次のとおりです。

- 高度なチャネル・オプションの構成

- 高度なバックアップ・オプションの構成

- 補助インスタンスのデータファイル名の構成

- スナップショット制御ファイルの場所の構成

- 共有サーバーで使用するためのRMANの構成

- 消失書込みの検出の有効化

高度なチャネル・オプションの構成

「チャネルの構成」ではチャネルの構成の基本が説明されていますが、この項では、より高度なチャネルのトピックについて説明します。この項の内容は、次のとおりです。

- チャネル制御オプション

- 固有のチャネル・パラメータの構成

関連項目:
チャネルの構成および割当ての概要については「RMANチャネル」、CONFIGURE構文については『Oracle Databaseバックアップおよびリカバリ・リファレンス』を参照してください。

チャネル制御オプション

チャネルを手動で割り当てる場合も自動チャネル割当てを使用する場合も、チャネル・コマンドおよびオプションを使用して、チャネルの動作を制御できます。表6-1に、チャネルの動作を制御する方法の概要を示します。特に明記されていないかぎり、CONFIGURE CHANNELとALLOCATE CHANNELコマンドの両方ですべてのチャネル・パラメータがサポートされています。

表6-1 チャネル制御オプション

チャネル制御のタイプ

コマンド

I/O帯域幅消費に対する制限

バックアップの制限メカニズムとして機能するRATEチャネル・パラメータを使用します。

バックアップ・セットおよびバックアップ・ピースに対する制限

MAXPIECESIZEチャネル・パラメータを使用して、バックアップ・ピースのサイズに制限を設定します。また、BACKUPおよびCONFIGUREコマンドでMAXSETSIZEパラメータを使用して、バックアップ・セットのサイズの制限を設定することもできます。

ベンダー固有の手順

PARMSチャネル・パラメータを使用して、メディア・マネージャに関するベンダー固有の情報を指定します。SENDコマンドを使用して、ベンダー固有のコマンドをメディア・マネージャに送信することもできます。

チャネルのパラレル化によるバックアップおよびリストア操作

CONFIGURE DEVICE TYPE ... PARALLELISMを使用して永続的にチャネルをパラレル化するか、または複数のALLOCATE CHANNELコマンドを使用してジョブ・レベルでパラレル化します。

データベース・インスタンスの接続設定

CONNECTチャネル・パラメータを使用して、操作を実行するインスタンスを指定します。

関連項目:
ALLOCATE CHANNELの構文については、『Oracle Databaseバックアップおよびリカバリ・リファレンス』を参照してください。CONFIGUREの構文については、『Oracle Databaseバックアップおよびリカバリ・リファレンス』を参照してください。

固有のチャネル・パラメータの構成

特定のタイプのすべてのチャネルに適用されるパラメータの構成に加えて、特定のチャネルに適用されるパラメータを構成することもできます。特定のチャネルを構成するには、CONFIGURE CHANNEL n(nは255未満の正の整数)コマンドを実行します。

チャネルに手動で番号を割り当てる場合、チャネルごとに1つ以上のチャネル・オプション(たとえば、MAXPIECESIZEやFORMAT)を指定する必要があります。番号を割り当てた特定のチャネルをバックアップで使用する場合、そのチャネルに構成した設定が構成済の汎用チャネル設定のかわりに使用されます。

各チャネルに設定されたパラメータを個別に制御する必要がある場合は、固有のチャネルを番号ごとに構成します。この方法は、次のような場合に実行する必要があります。

- 個々のノードがバックアップの完全なセットにアクセスできないOracle Real Application Clusters(Oracle RAC)構成を実行している場合。すべてのバックアップに1つ以上のチャネルでアクセスできるように、ノード固有の接続文字列を使用して各チャネルを構成する必要があります。

- 各チャネルで異なるPARMS設定が必要なメディア・マネージャを使用している場合。

関連項目:
Oracle RAC環境でのRMANバックアップについては、『Oracle Real Application Clusters管理およびデプロイメント・ガイド』を参照してください。

固有のチャネルの構成の例

次の例では、ディスク・バックアップを2つのディスクに送信します。ディスク・チャネルを次のように構成します。

CONFIGURE DEFAULT DEVICE TYPE TO disk;        # backup goes to disk
CONFIGURE DEVICE TYPE disk PARALLELISM 2;     # two channels used in parallel
CONFIGURE CHANNEL 1 DEVICE TYPE DISK FORMAT '/disk1/%U' # 1st channel to disk1
CONFIGURE CHANNEL 2 DEVICE TYPE DISK FORMAT '/disk2/%U' # 2nd channel to disk2
BACKUP DATABASE; # backup - first channel goes to disk1 and second to disk2

2つのテープ・ドライブがあり、各テープ・ドライブで異なるテープ・メディア・ファミリのテープを使用するという別の場合を想定します。デフォルトの出力デバイスおよびデフォルトのテープ・チャネルを例6-1のように構成して、パラレル・データベース・バックアップを使用します。

例6-1 テープ・デバイスのチャネルのパラレル化の構成

CONFIGURE DEFAULT DEVICE TYPE TO sbt;    # backup goes to sbt
CONFIGURE DEVICE TYPE sbt PARALLELISM 2; # two sbt channels allocated by default
# Configure channel 1 to pool named first_pool
CONFIGURE CHANNEL 1 DEVICE TYPE sbt
PARMS 'ENV=(OB_MEDIA_FAMILY=first_pool)';
# configure channel 2 to pool named second_pool
CONFIGURE CHANNEL 2 DEVICE TYPE sbt
PARMS 'ENV=(OB_MEDIA_FAMILY=second_pool)';
BACKUP DATABASE; # first stream goes to 'first_pool' and second to 'second_pool'

例6-1では、バックアップ・データは2つのテープ・デバイス間で分割されます。構成済の各チャネルは、データの合計の約半分ずつをバックアップします。

CONFIGURE CHANNELとパラレル化設定の関係

PARALLELISM設定は、固有に構成したチャネルの数に制約を受けません。たとえば、20の異なるテープ・デバイスにバックアップを実行する場合、20の異なるSBTチャネルを構成できます。各チャネルには、手動で番号(1から20まで)を割り当て、個別の一連のチャネル・オプションを設定します。このような場合、PARALLELISMにデバイス数(この例では20)以下の任意の値を設定できます。

パラレル・チャネルには、常に、RMANによって1から順にPARALLELISM設定の値までの番号が付けられます。たとえば、デフォルト・デバイスがSBTで、パラレル化が3に設定されている場合、チャネルの名前は次のようになります。

ORA_SBT_TAPE_1
ORA_SBT_TAPE_2
ORA_SBT_TAPE_3

DEVICE TYPE sbt(シノニムsbt_tapeではない)を構成した場合でも、RMANでは常にORA_SBT_TAPE_nという名前が使用されます。また、チャネルを個別に構成した場合はそのチャネルを使用し、構成していない場合は汎用チャネルを使用して、常に、PARALLELISMに指定したチャネルの番号が割り当てられます。パラレル化設定より大きい数で特定のチャネルを構成した場合、この設定は、RMANによるチャネルの使用を防止します。

関連項目:
チャネルの詳細は、「RMANチャネル」を参照してください。

高度なバックアップ・オプションの構成

バックアップを作成するようにRMANを構成する方法の基本については、「RMANバックアップの環境の構成」を参照してください。この項では、より高度な構成オプションについて説明します。この項の内容は、次のとおりです。

- バックアップ・セットの最大サイズの構成

- バックアップ・ピースの最大サイズの構成

- バックアップの多重化の構成

- データベース全体のバックアップから除外する表領域の構成

- 圧縮オプションの構成

- バックアップの暗号化の構成

バックアップ・セットの最大サイズの構成

テープ・バックアップでは、複数のテープにまたがって多重バックアップ・セットを使用できます。つまり、バックアップ・セットの各データファイルにあるブロックは、複数のテープに書き込まれます。マルチボリュームのバックアップ・セットのいずれかのテープで障害が発生すると、1つのテープのみでなく、すべてのテープ上のデータが失われます。バックアップがマルチセクション・バックアップでない場合、バックアップ・セットには、データファイルの一部ではなくデータファイル全体が常に含まれます。MAXSETSIZEを使用すると、各バックアップ・セットが複数のテープにまたがるのではなく、1つのテープに収まるように指定できます。

CONFIGURE MAXSETSIZEコマンドラインでは、チャネルに作成されるバックアップ・セットのサイズを制限します。このCONFIGURE設定は、チャネルが手動割当てによるものか、構成済のものであるかにかかわらず、BACKUPコマンドを使用してバックアップ・セットを作成するときに任意のチャネルに適用されます。デフォルト値はバイト単位で指定されており、最小KB値に切り捨てられます。

CONFIGURE MAXSETSIZEコマンドで設定した値は、指定したチャネルのデフォルトになります。構成済のMAXSETSIZE値は、個別のBACKUPコマンドにMAXSETSIZEオプションを指定して上書きできます。

RMANプロンプトで次のコマンドを発行するとします。

CONFIGURE DEFAULT DEVICE TYPE TO sbt;
CONFIGURE CHANNEL DEVICE TYPE sbt PARMS 'ENV=(OB_MEDIA_FAMILY=first_pool)';
CONFIGURE MAXSETSIZE TO 7500K;
BACKUP TABLESPACE users;
BACKUP TABLESPACE tools MAXSETSIZE 5G;

結果は次のとおりです。

- users表領域のバックアップには、構成済チャネルSBTおよび構成済のMAXSETSIZEのデフォルト設定である7500Kが使用されます。

- tools表領域のバックアップには、BACKUPコマンドで指定したMAXSETSIZEの設定値5Gが使用されます。

関連項目:

- 「BACKUP ... MAXSETSIZEを使用したバックアップ・セットのサイズの制限」

- BACKUPの構文については、『Oracle Databaseバックアップおよびリカバリ・リファレンス』を参照してください。

バックアップ・ピースの最大サイズの構成

バックアップ・ピースのサイズがファイル・システムまたはメディア管理ソフトウェアで許容される最大ファイル・サイズを超えると、問題が発生します。CONFIGURE CHANNELまたはALLOCATE CHANNELコマンドのMAXPIECESIZEパラメータを使用すると、バックアップ・ピースのサイズを制限できます。

たとえば、バックアップ・ピースのサイズを2GB以下に制限するには、自動DISKチャネルを次のように構成して、BACKUP DATABASEを実行します。

CONFIGURE CHANNEL DEVICE TYPE DISK MAXPIECESIZE 2G;
BACKUP DATABASE;

注意:
バージョン2.0のMedia Management APIでは、メディア・マネージャに書込み可能なバックアップ・ピースの最大サイズを指定できるのはメディア管理ベンダーです。RMANは、MAXPIECESIZEに構成する設定に関係なく、この制限を優先します。

関連項目:
CONFIGURE CHANNEL ... MAXPIECESIZEコマンドの詳細は、『Oracle Databaseバックアップおよびリカバリ・リファレンス』を参照してください。

バックアップの多重化の構成

CONFIGURE ... BACKUP COPIESコマンドを使用して、指定したタイプのファイルについて、指定したデバイス・タイプ上に各バックアップ・ピースのコピーをいくつ作成するかを指定できます。このタイプのバックアップは、多重バックアップ・セットと呼ばれます。多重化を行うためのCONFIGURE設定は、バックアップ・セットへのデータファイル、制御ファイルおよびアーカイブ・ログのバックアップにのみ影響し、イメージ・コピーには影響しません。

注意:
制御ファイルの自動バックアップは、多重化されません。

RMANでは、ディスクまたはテープにバックアップを多重化できますが、テープとディスクにバックアップを同時に多重化することはできません。テープへのバックアップ時に、コピーの数が、使用可能なテープ・デバイスの数を超えないようにしてください。多重化の構成の例を次に示します。

# Makes 2 disk copies of each data file and control file backup set
# (autobackups excluded)
CONFIGURE DATAFILE BACKUP COPIES FOR DEVICE TYPE DISK TO 2;
# Makes 3 copies of every archived redo log backup to tape
CONFIGURE ARCHIVELOG BACKUP COPIES FOR DEVICE TYPE sbt TO 3;

BACKUP COPIES構成をデフォルト値に戻すには、同じCONFIGUREコマンドにCLEARオプションを指定して実行します。次に例を示します。

CONFIGURE DATAFILE BACKUP COPIES FOR DEVICE TYPE sbt CLEAR;

デフォルトでは、各デバイス・タイプのCONFIGURE ... BACKUP COPIESが1に設定されています。

注意:
永続的なコピーの構成を作成しない場合は、BACKUP COPIESおよびSET BACKUP COPIESコマンドを使用してコピーを指定できます。

関連項目:

- バックアップの多重化の概要は、「RMANを使用したバックアップの複数のコピー」を参照してください。

- 多重バックアップの作成方法については、「バックアップ・セットの多重化」を参照してください。

- BACKUPの構文については、『Oracle Databaseバックアップおよびリカバリ・リファレンス』を参照してください。

- CONFIGUREの構文については、『Oracle Databaseバックアップおよびリカバリ・リファレンス』を参照してください。

- SETの構文については、『Oracle Databaseバックアップおよびリカバリ・リファレンス』を参照してください。

データベース全体のバックアップから除外する表領域の構成

場合によっては、指定した表領域を定期的なバックアップ・スケジュールから除外できます。考えられるいくつかの例を次に示します。

- 表領域の再構築が簡単であるため、毎日バックアップするより再構築した方がコスト効率がよい場合。

- 表領域に、バックアップする必要がない一時データまたはテスト・データが含まれている場合。

- 表領域が頻繁に変更されないため、他のバックアップとは別のスケジュールでバックアップする必要がある場合。

CONFIGURE EXCLUDE FOR TABLESPACEを実行して、指定した表領域をBACKUP DATABASEコマンドから除外できます。除外条件は、今後この表領域に追加するすべてのデータファイルに適用されます。

たとえば、テスト表領域cwmliteおよびexampleをデータベース全体のバックアップから除外するには、次のコマンドを実行します。

CONFIGURE EXCLUDE FOR TABLESPACE cwmlite;
CONFIGURE EXCLUDE FOR TABLESPACE example;

次のコマンドを実行すると、cwmliteおよびexample以外のデータベース内のすべての表領域がバックアップされます。

BACKUP DATABASE;

除外されるように構成した表領域は、BACKUPコマンドでそれらの表領域を明示的に指定するか、またはBACKUP DATABASEコマンドでNOEXCLUDEオプションを指定して、バックアップすることができます。たとえば、次のコマンドのいずれかを入力します。

BACKUP DATABASE NOEXCLUDE; #backs up database, including cwmlite and example
BACKUP TABLESPACE cwmlite, example;  # backs up only cwmlite and example

cwmliteおよびexampleに対する除外機能を無効にするには、次のコマンドを実行します。

CONFIGURE EXCLUDE FOR TABLESPACE cwmlite CLEAR;
CONFIGURE EXCLUDE FOR TABLESPACE example CLEAR;

これらの表領域は、これ以降に実行されるデータベース全体のバックアップでバックアップされます。

関連項目:

- BACKUPおよびCONFIGUREの構文については、『Oracle Databaseバックアップおよびリカバリ・リファレンス』を参照してください。

圧縮オプションの構成

RMANでは、バックアップ・セットの圧縮前の処理およびバイナリ圧縮がサポートされています。

圧縮前のブロック処理

各データ・ブロックの空き領域を統合し、その空き領域をバイナリのゼロに設定することによって、より高いバックアップ圧縮率を得ることができます。この圧縮前の処理段階は、削除や挿入操作が多いデータ・ブロックで最もメリットがあります。逆に、初期のロード状態を保っているデータ・ブロックには影響がありません。

OPTIMIZE FOR LOADオプションは、圧縮前の処理を制御します。デフォルトのOPTIMIZE FOR LOAD TRUEを指定すると、RMANでCPU使用率が最適化され、圧縮前のブロック処理が防止されます。OPTIMIZE FOR LOAD FALSEを指定すると、RMANで追加のCPUリソースを使用して圧縮前のブロック処理が実行されます。

関連項目:

- CONFIGUREおよびSETの構文については、『Oracle Databaseバックアップおよびリカバリ・リファレンス』を参照してください。

Basic Compressionオプション

次の構文で、基本の圧縮アルゴリズムを構成できます。この場合、Advanced Compressionオプションは必要ありません。

例6-2 バックアップのBasic Compressionの構成

CONFIGURE COMPRESSION ALGORITHM 'BASIC';

Advanced Compressionオプション

Oracle Database 11gリリース2 Advanced Compressionオプションを有効にすると、次のいずれかの圧縮レベルを選択できます。

圧縮レベル

パフォーマンスのメリットとデメリット

HIGH

ネットワーク速度が制限事項となる、速度の遅いネットワークでのバックアップに最適です。

MEDIUM

ほとんどの環境で推奨されます。圧縮率と速度の優れた組合せが得られます。

LOW

バックアップ・スループットへの影響が最小です。

基本的に圧縮率はLOWからHIGHへと高くなります。ただし、圧縮率の上昇に応じて、消費されるCPUリソースが多くなります。

様々な圧縮レベルのパフォーマンスはデータベースのデータ、ネットワーク構成、システム・リソースおよびコンピュータ・システムの種類と機能によって異なるため、パフォーマンスについて広く当てはまる統計を示すことはできません。環境に最適な圧縮レベルは、CPUへの帯域幅およびCPUの実際の速度に関するご使用のシステムのバランスによって異なります。ご使用の環境で、データに対して様々な圧縮レベルをテストすることを強くお薦めします。バックアップ・セットの圧縮レベルが組織のパフォーマンス要件および該当する品質保証契約を満たすようにするには、環境、ネットワーク・トラフィックの特徴(ワークロード)およびデータセットに基づいて圧縮レベルを選択します。

注意:

- バックアップ先がテープであり、テープ・デバイスで独自の圧縮が実行される場合、RMANによるバックアップ・セットの圧縮とメディア・マネージャ・ベンダーによる圧縮の両方は使用しないでください。詳細は、第22章「RMANのパフォーマンスのチューニング」のRMANによるテープ・バックアップのパフォーマンス・チューニングに関する項を参照してください。

- 圧縮バックアップのリストアはインラインで実行され、解凍は必要ありません。

バックアップの暗号化の構成

セキュリティを向上させるために、RMANバックアップ・セットに対してバックアップの暗号化を構成できます。暗号化バックアップは、不正なユーザーが取得しても読み取ることができません。この機能を使用するには、Enterprise Editionのデータベースが必要です。

バックアップの暗号化

V$RMAN_ENCRYPTION_ALGORITHMSビューには、RMANでサポートされている暗号化アルゴリズムのリストが含まれます。暗号化アルゴリズムを指定しない場合のデフォルトの暗号化アルゴリズムは128ビットのAdvanced Encryption Standard(AES)です。RMANでの暗号化では、ターゲット・データベースのCOMPATIBLE初期化パラメータを10.2.0以上にする必要があります。

RMANには、次の暗号化モードがあります。

- バックアップの透過的暗号化
これがデフォルトのモードで、Oracleウォレットが使用されます。ウォレットは、認証および署名資格証明(秘密鍵、証明書、SSLで必要な信頼できる証明書など)の格納に使用されるパスワード保護されたコンテナです。

- バックアップのパスワード暗号化
このモードでは、パスワード保護のみが使用されます。暗号化バックアップを作成およびリストアする場合、パスワードを入力する必要があります。

- バックアップのデュアル・モード暗号化
このモードでは、ウォレットまたはパスワードが必要です。

注意:
ウォレットベースの暗号化は、パスワードが必要ないため、パスワードベースの暗号化より安全です。パスワードベースの暗号化は、バックアップをトランスポータブルにする必要があるため絶対に必要な場合にのみ使用してください。

暗号化バックアップは、必要な復号化キーが使用可能な場合に、リストアおよびリカバリ中に自動的に復号化されます。バックアップ・セットごとに別々のキーが取得されます。キーは、暗号化形式でバックアップ・ピースに格納されます。バックアップは、ユーザーが指定するパスワードまたはOracleウォレットによって取得されたキーを使用して復号化されます。

RMANを使用してディスクに暗号化バックアップを作成するには、データベースでAdvanced Security Optionを使用している必要があります。Oracle Secure Backup SBTは、暗号化RMANバックアップをテープに直接作成するためにサポートされている唯一のインタフェースです。Oracle Secure Backup以外のSBTライブラリを使用して暗号化RMANバックアップを作成しようとすると、RMANはORA-19916エラーを発行します。Advanced Security Optionは、Oracle Secure Backup SBTを使用して暗号化バックアップを作成する場合は必要ありません。

暗号化されたバックアップ・セットに対してBACKUP BACKUPSETコマンドを使用すると、バックアップ・セットは暗号化形式でバックアップされます。BACKUP BACKUPSETは暗号化されたバックアップ・セットをディスクまたはテープにコピーするため、BACKUP BACKUPSET操作中に復号化鍵は不要です。この操作のどの段階でも、データの復号化が行われることはありません。バックアップ・セットは、BACKUP BACKUPSETコマンドによって暗号化されることも復号化されることもありません。

関連項目:
Oracleウォレットの構成の詳細は、『Oracle Database Advanced Security管理者ガイド』を参照してください。

バックアップの透過的暗号化

透過的暗号化では、必要なOracleキー管理インフラストラクチャが使用可能な場合にかぎり、DBAの介入なしで暗号化バックアップを作成およびリストアできます。透過的暗号化は、日次バックアップ操作(バックアップを作成元と同じデータベースにリストア)に最適です。透過的暗号化は、RMANの暗号化のデフォルトです。

透過的暗号化を使用する場合は、まず、『Oracle Database Advanced Security管理者ガイド』の説明に従って、各データベースにOracleウォレットを構成する必要があります。バックアップの透過的暗号化では、暗号化形式および自動ログイン形式のOracleウォレットがサポートされています。Oracleウォレットを使用する場合は、バックアップの暗号化を実行する前にウォレットがオープンされている必要があります。自動ログイン・ウォレットを使用する場合は、暗号化バックアップの操作をいつでも行うことができます。自動ログイン・ウォレットは常にオープンしているためです。

注意:
自動ログイン・ウォレットを使用する場合は、暗号化バックアップ・データとともにバックアップしないようにしてください。バックアップと自動ログイン・ウォレットの両方を取得すると、暗号化バックアップの読取りが可能になるためです。Oracleウォレットはウォレット・パスワードがないと使用できないため、この形式のウォレットはバックアップを作成しても安全です。

Oracleウォレットを構成した後は、DBAの介入なしで暗号化バックアップを作成およびリストアできます。透過的データ暗号化を使用して暗号化されているデータベース内のいくつかの列をバックアップの暗号化を使用してバックアップすると、バックアップ中にそれらの列に対して2度目の暗号化が行われます。バックアップ・セットがリストア操作中に復号化されると、暗号化された列は元の暗号化形式に戻ります。

Oracleキー管理インフラストラクチャによって以前のすべてのマスター・キーがOracleウォレットにアーカイブされるため、現行のデータベース・マスター・キーを変更または再設定しても、以前のマスター・キーを使用して実行された暗号化バックアップは引き続きリストアできます。データベース・マスター・キーはいつでも再設定できます。RMANは、このデータベースによって作成されたすべての暗号化バックアップをリストアできます。

注意:
Oracleウォレットを失うと、透過的に暗号化されたバックアップをリストアできません。

バックアップのパスワード暗号化

パスワード暗号化では、暗号化バックアップを作成およびリストアする場合に、DBAがパスワードを入力する必要があります。パスワード暗号化バックアップをリストアするには、バックアップを作成する場合に使用したパスワードと同じパスワードが必要となります。

パスワード暗号化は、リモートの場所でリストアし、送信中は保護されている必要があるバックアップに有効です。パスワード暗号化は、永続的には構成できません。パスワード暗号化を排他的に使用する場合は、Oracleウォレットを構成する必要はありません。

注意:
パスワード暗号化バックアップを暗号化するときに使用したパスワードを忘れた(または失った)場合は、バックアップをリストアできません。

パスワード暗号化を使用するには、RMANスクリプトでSET ENCRYPTION ON IDENTIFIED BY password ONLYコマンドを使用します。

バックアップのデュアル・モード暗号化

デュアル・モード暗号化バックアップでは、透過的なリストアまたはパスワードを指定したリストアのいずれかを実行できます。デュアル・モード暗号化バックアップは、通常はOracleウォレットを使用してオンサイトでリストアされるが、Oracleウォレットを使用できないオフサイトでリストアする必要がある場合もあるバックアップを作成する場合に有効です。

デュアル・モード暗号化バックアップをリストアする場合は、Oracleウォレットまたは復号化用のパスワードのいずれかを使用できます。

注意:
デュアル・モード暗号化バックアップを暗号化するときに使用したパスワードを忘れ(または失い)、Oracleウォレットも失った場合は、バックアップをリストアできません。

デュアル・モード暗号化バックアップ・セットを作成するには、RMANスクリプトでSET ENCRYPTION ON IDENTIFIED BY passwordコマンドを指定する必要があります。

RMANバックアップの暗号化モードの構成

CONFIGUREコマンドを使用すると、バックアップの透過的暗号化を永続的に構成できます。このコマンドを使用して、次の内容を指定できます。

- すべてのデータベース・ファイルのバックアップに透過的暗号化を使用するかどうか

- 特定の表領域のバックアップに透過的暗号化を使用するかどうか

- バックアップの暗号化にどのアルゴリズムを使用するか

SET ENCRYPTIONコマンドを使用して、次の処理を実行することもできます。

- CONFIGURE ENCRYPTIONコマンドで指定した暗号化設定を上書きします。たとえば、SET ENCRYPTION OFFを使用すると、暗号化バックアップを作成するようにデータベースが構成されている場合でも、暗号化されていないバックアップが作成されます。

- RMANクライアントが終了するまで保持される、バックアップの暗号化のパスワードを設定します。パスワードは機密情報であるため、RMANの複数のセッションにわたってパスワードが保持される構成は、RMANでは許可されていません。

永続的な構成設定を使用するかどうかによって、アーカイブREDOログのバックアップを暗号化するかどうかが制御されます。アーカイブREDOログ・ファイルを含むバックアップ・セットは、次のいずれかの条件が満たされている場合に暗号化されます。

- アーカイブ・ログのバックアップの作成時にSET ENCRYPTION ONが有効である。

- データベース全体または1つ以上の表領域のバックアップに対して暗号化が構成されている。

この動作によって、データファイルの暗号化バックアップに関連付けられているREDOも暗号化されます。

すべてのRMANバックアップが暗号化されるように環境を構成する手順

1. 『Oracle Database Advanced Security管理者ガイド』の説明に従って、Oracleウォレットを設定します。

2. 次のRMANコマンドを発行します。

CONFIGURE ENCRYPTION FOR DATABASE ON;

この段階では、デフォルトで、このデータベースによって作成されるすべてのRMANバックアップ・セットで透過的暗号化が使用されます。

次のコマンドを使用すると、RMANセッションの永続的な暗号化構成を明示的に上書きできます。

SET ENCRYPTION ON;

暗号化設定は、RMANセッション中にSET ENCRYPTION OFFコマンドを発行するか、または次のコマンドを使用して永続的な設定を再度変更するまで有効です。

CONFIGURE ENCRYPTION FOR DATABASE OFF;

バックアップ暗号化アルゴリズムの構成

CONFIGUREコマンドを使用すると、バックアップ・セットの書込み時に、暗号化に使用するデフォルト・アルゴリズムを永続的に構成できます。指定可能な値は、V$RMAN_ENCRYPTION_ALGORITHMSに表示されます。デフォルト・アルゴリズムは、128ビットAESです。

デフォルトのバックアップ暗号化アルゴリズムを構成する手順

1. RMANを起動し、ターゲット・データベースおよびリカバリ・カタログ(使用している場合)に接続します。

2. ターゲット・データベースがマウントまたはオープンされていることを確認します。

3. V$RMAN_ENCRYPTION_ALGORITHMS.ALGORITHM_NAMEから有効な値を指定して、CONFIGURE ENCRYPTION ALGORITHMコマンドを実行します。
次の例では、アルゴリズムを256ビットAES暗号化に構成します。

CONFIGURE ENCRYPTION ALGORITHM TO 'AES256';

補助インスタンスのデータファイル名の構成

表領域のPoint-in-Timeリカバリ(TSPITR)を実行するか、またはRMANを使用してデータ転送を実行するとします。この場合、TSPITRまたはデータベースの複製を開始する前に、補助インスタンスのデータファイルの名前を設定する必要がある場合があります。 コマンドで、次のように、datafileSpecにはデータファイルの元の名前または番号を指定し、filenameには指定したファイルの新しいパスを指定します。

CONFIGURE AUXNAME FOR datafileSpec TO 'filename';

たとえば、データファイル2の新しい補助ファイル名を次のように構成するとします。

CONFIGURE AUXNAME FOR DATAFILE 2 TO '/newdisk/datafiles/df2.df';

他の設定と同様に、CONFIGUREコマンド設定は、次の例に示すようにCONFIGURE ... CLEARでクリアするまで、複数のRMANセッションに継続的に使用されます。

CONFIGURE AUXNAME FOR DATAFILE 2 CLEAR;

TSPITRを行うか、DUPLICATEコマンドを実行する場合は、CONFIGURE AUXNAMEを使用することによって、プロシージャ中に手動で補助ファイル名を指定しなくても、補助データベースで使用するファイル名を事前に構成できます。

DUPLICATEコマンドでファイル名を変更する場合は、SET NEWNAMEコマンドのかわりにCONFIGURE AUXNAMEを使用します。違いは、最初にAUXNAMEを設定すると、別のDUPLICATEコマンドを発行するときにファイル名を再設定する必要がないことです。AUXNAME設定は、CONFIGURE AUXNAME ... CLEARを発行するまで有効になっています。これとは対照的に、SET NEWNAMEコマンドは、ファイル名を変更するたびに再発行する必要があります。

TSPITRとCONFIGURE AUXNAMEを併用する方法の詳細は第21章「RMANの表領域のPoint-in-Timeリカバリ(TSPITR)の実行」、データベース複製の実行時にCONFIGURE AUXNAMEを使用する方法の詳細は第24章「データベースの複製」を参照してください。

スナップショット制御ファイルの場所の構成

RMANでは、リカバリ・カタログを読取り一貫性バージョンの制御ファイルと再同期化する必要がある場合、一時スナップショット制御ファイルが作成されます。リカバリ・カタログとの再同期化または現行の制御ファイルのバックアップを実行する場合、スナップショット制御ファイルが必要になります。

スナップショット制御ファイルのデフォルトの場所はプラットフォーム固有であり、各ターゲット・データベースのOracleホームによって異なります。たとえば、一部のLinuxプラットフォームでのデフォルトのファイル名は、$ORACLE_HOME/dbs/snapcf_@.fとなります。ターゲット・データベースに対して高速リカバリ領域が構成されている場合、スナップショット制御ファイルのデフォルトの場所はその高速リカバリ領域内ではありません。

スナップショット制御ファイルの構成場所の表示

SHOWコマンドを実行して、現在のスナップショットの場所を確認できます。次の例は、デフォルトの規則によって決定されるスナップショットの場所を示しています。

RMAN> SHOW SNAPSHOT CONTROLFILE NAME;
CONFIGURE SNAPSHOT CONTROLFILE NAME TO '/oracle/dbs/snapcf_trgt.f'; # default

次の例では、デフォルト以外のファイル名を持つスナップショット制御ファイルを示します。

RMAN> SHOW SNAPSHOT CONTROLFILE NAME;
CONFIGURE SNAPSHOT CONTROLFILE NAME TO '/oracle/oradata/trgt/snap_trgt.ctl';

スナップショット制御ファイルの場所の設定

CONFIGURE SNAPSHOT CONTROLFILE NAME TO 'filename'コマンドを使用して、スナップショット制御ファイルの名前を変更します。これ以降にRMANで作成されるスナップショット制御ファイルには、指定したファイル名が使用されます。

たとえば、RMANを起動して次のコマンドを入力するとします。

CONFIGURE SNAPSHOT CONTROLFILE NAME TO '/oracle/oradata/trgt/snap_trgt.ctl';

また、スナップショット制御ファイル名をRAWデバイスに設定することもできます。

スナップショット制御ファイルの場所をデフォルトにリセットするには、CONFIGURE SNAPSHOT CONTROLFILE NAME CLEARコマンドを実行します。

関連項目:

- 「リカバリ・カタログの再同期化」

- Oracle RAC構成でのスナップショット制御ファイルの処理の詳細は、『Oracle Real Application Clusters管理およびデプロイメント・ガイド』を参照してください。

共有サーバーで使用するためのRMANの構成

RMANは、共有サーバー・ディスパッチャを介しては、ターゲット・データベースに接続できません。RMANには専用サーバー・プロセスが必要です。ターゲット・データベースが共有サーバー用に構成されている場合、Oracle Net構成を変更し、RMAN接続専用のサーバー・プロセスを指定する必要があります。

ターゲット・データベースが共有サーバー用に構成されている場合にRMANをディスパッチャに接続しないようにするには、RMANで使用するネット・サービス名の接続文字列のCONNECT_DATA属性に(SERVER=DEDICATED)を含める必要があります。

Oracle Net構成は、システムによって大幅に異なります。次に、多くの構成方法の一例を示します。この例では、tnsnames.oraファイル内の次のサービス名が共有サービス・アーキテクチャを使用してターゲット・データベースに接続するものと想定しています。ここで、inst1は、SERVICE_NAMES初期化パラメータの値です。

inst1_shs =
(DESCRIPTION=
(ADDRESS=(PROTOCOL=tcp)(HOST=inst1_host)(port=1521))
(CONNECT_DATA=(SERVICE_NAME=inst1)(SERVER=shared))
)

RMANを共有サーバーで使用する手順

1. tnsnames.oraファイルに、共有されないSIDに接続するネット・サービス名を作成します。たとえば、次のように入力します。

inst1_ded =
(DESCRIPTION=
(ADDRESS=(PROTOCOL=tcp)(HOST=inst1_host)(port=1521))
(CONNECT_DATA=(SERVICE_NAME=inst1)(SERVER=dedicated))
)

2. SQL*Plusを起動し、共有サーバー・サービス名と専用サーバー・サービス名の両方を使用して接続することで、各セッションのモードを確定します。
たとえば、SYSDBA権限でinst1_dedに接続してから、次のSELECT文を実行します(出力例も示します)。

SQL> SELECT SERVER
2  FROM   V$SESSION
3  WHERE  SID = (SELECT DISTINCT SID FROM V$MYSTAT);

SERVER
---------
DEDICATED
1 row selected.

共有サーバー・セッションに接続するには、SYSDBA権限でinst1_shsに接続してから、次のSELECT文を実行します(出力例も示します)。

SQL> SELECT SERVER
2  FROM   V$SESSION
3  WHERE  SID = (SELECT DISTINCT SID FROM V$MYSTAT);

SERVER
---------
SHARED
1 row selected.

3. RMANを起動し、専用サービス名を使用してターゲット・データベースに接続します。必要に応じて、リカバリ・カタログに接続します。たとえば、次のように入力します。

% rman
RMAN> CONNECT TARGET SYS@inst1_ded

target database Password: password
connected to target database: INST1 (DBID=39525561)

RMAN> CONNECT CATALOG rman@catdb

関連項目:
Oracle Netの接続文字列構文の詳細は、プラットフォーム固有のOracleマニュアルおよび『Oracle Database Net Servicesリファレンス』を参照してください。

消失書込みの検出の有効化

データ・ブロックの消失書込みは、永続ストレージで書込みが行われなかったにもかかわらず、I/Oサブシステムでブロック書込みの完了が確認された場合に発生します。この後のブロック読取りでは、失効したデータ・ブロックがI/Oサブシステムによって戻されます。このデータ・ブロックを使用してデータベースの他のブロックを更新すると、ブロックが破損する場合があります。

DB_LOST_WRITE_PROTECT初期化パラメータをTYPICALまたはFULLに設定して、データベースでバッファ・キャッシュ・ブロック読取りがREDOログに記録されるようにすることができます。デフォルト設定はNONEです。このパラメータをTYPICALに設定すると、読取り/書込み表領域のバッファ・キャッシュ読取りはインスタンスによってREDOログに記録されますが、読取り専用表領域は記録されません。FULLに設定すると、読取り専用表領域の読取りもインスタンスによって記録されます。TYPICALモードでのパフォーマンス・オーバーヘッドは約5から10%で、FULLモードではそれ以上になる可能性があります。

消失書込みの検出は、Data Guardとともに使用すると最も効果的です。この場合、プライマリ・データベースとスタンバイ・データベースの両方にDB_LOST_WRITE_PROTECTを設定します。スタンバイ・データベースは、管理リカバリ中にREDOを適用する際、対応するブロックを読み取ってSCNをREDOログ内のSCNと比較します。プライマリ・データベースのブロックSCNがスタンバイ・データベースのブロックSCNより小さい場合は、プライマリ・データベース上の消失書込みを検出し、外部エラー(ORA-752)をスローします。SCNが大きい場合は、スタンバイ・データベース上の消失書込みを検出し、内部エラー(ORA-600 [3020])をスローします。いずれの場合も、スタンバイ・データベースは障害の理由をアラート・ログおよびトレース・ファイルに書き込みます。

消失書込みをプライマリ・データベースで修復するには、スタンバイ・データベースへのフェイルオーバーを開始する必要があります。消失書込みをスタンバイ・データベースで修復するには、スタンバイ・データベース全体を再作成するか、または影響を受けたファイルのみのバックアップをリストアする必要があります。

Data Guardを使用しない場合も、消失書込みの検出を有効にすると役に立ちます。この場合、消失書込みは、通常のデータベース操作中またはメディア・リカバリ中に発生する可能性があります。前者の場合は、エラーを検出する直接的な方法はありません。表に一貫性がないなどの間接的な兆候を、消失書込みに明確に結び付けることはできません。ただし、消失書込みが発生した可能性がある時点以前に作成したバックアップを保持している場合は、そのバックアップを代替の場所にリストアしてリカバリできます。問題を診断するには、失効したブロック読取りのSCNまでデータベースまたは表領域をリカバリします。これによって、消失書込みエラー(ORA-752)が生成されます。

メディア・リカバリ中に消失書込みエラーが発生した場合は、データベースをRESETLOGSオプションでオープンする対応のみが可能です。データベースは一貫性のある状態ですが、RESETLOGS SCNより後のすべてのデータは消失しています。データベース作成後に作成したバックアップを使用してリカバリする場合は、他の失効したブロックによってデータベースが破損していない保証はありません。 これは、リストアするバックアップが、消失書込みが発生した後に作成された可能性があるためです。消失書込みによってデータベースが破損していないことを保証するには、データベース作成からのメディア・リカバリを実行する必要があります。ただし、この方法は、ほとんどのデータベース環境で現実的ではありません。

関連項目:

- 消失書込みの検出および修復のためにスタンバイ・データベースを使用する方法については、『Oracle Data Guard概要および管理』を参照してください。

- DB_LOST_WRITE_PROTECT初期化パラメータについては、『Oracle Databaseリファレンス』を参照してください。

7 フラッシュバック・データベースおよびリストア・ポイントの使用

この章では、フラッシュバック・データベースおよびリストア・ポイントについて説明します。この章では、全体的なデータ保護計画の一環としてこれらの機能を構成、監視およびメンテナンスする方法を示します。

この章の内容は次のとおりです。

- フラッシュバック・データベース、リストア・ポイントおよび保証付きリストア・ポイントについて

- フラッシュバック・データベースおよび保証付きリストア・ポイントのロギング

- フラッシュバック・データベースおよび保証付きリストア・ポイントの前提条件

- 通常のリストア・ポイントと保証付きリストア・ポイントの使用

- データベースのフラッシュバックの使用

関連項目:
フラッシュバック・データベースおよび通常のリストア・ポイントと保証付きリストア・ポイントを使用するリカバリ・シナリオの詳細は、第18章「フラッシュバックおよびデータベースのPoint-in-Timeリカバリの実行」を参照してください。

フラッシュバック・データベース、リストア・ポイントおよび保証付きリストア・ポイントについて

Oracle Flashback Databaseおよびリストア・ポイントは、関連するデータ保護機能です。これらの機能を使用すると、データを特定の時点まで巻き戻して、指定の期間中に論理的なデータ破損またはユーザー・エラーによって生じた問題を解決できます。これらの機能は、Point-in-Timeリカバリの効率的な代替手段となり、リストア対象のデータベースの事前バックアップを必要としません。その効果は、データベースのPoint-in-Timeリカバリ(DBPITR)を使用した場合と同様です。フラッシュバック・データベースおよびリストア・ポイントは、従来のデータベース・リカバリ状況で効果的に使用できるだけでなく、データベースのアップグレード・シナリオ、アプリケーションのデプロイメント・シナリオ、およびテスト・データベースをすばやく作成したり、再作成する必要があるテスト・シナリオでも役立ちます。また、フラッシュバック・データベースは、Data Guardフェイルオーバーの後に、障害が発生したプライマリ・データベースを再構築するかわりとしても効率的に使用できます。

関連項目:
『Oracle Data Guard概要および管理』

リストア・ポイントには、フラッシュバック・データベースおよびその他のメディア・リカバリ操作に関連する機能が備えられています。特に、任意のシステム変更番号(SCN)で作成された保証付きリストア・ポイントによって、フラッシュバック・データベースを使用してデータベースをこのSCNに確実に巻き戻せるようになります。リストア・ポイントおよびフラッシュバック・データベースは、別々に使用することも、一緒に使用することもできます。

フラッシュバック・データベースにアクセスするには、RMANのコマンドFLASHBACK DATABASEまたはSQL文FLASHBACK DATABASEを使用します。いずれかのコマンドを使用して、論理的なデータ破損またはユーザー・エラーからデータベースをすばやくリカバリできます。次の例では、データベースを指定したSCNまたはリストア・ポイントに戻します。

FLASHBACK DATABASE TO RESTORE POINT 'before_upgrade';
FLASHBACK DATABASE TO SCN 202381;

フラッシュバック・データベース

フラッシュバック・データベースにアクセスするには、RMANのコマンドおよびSQL文FLASHBACK DATABASEを使用します。いずれかのコマンドを使用して、論理的なデータ破損またはユーザー・エラーからデータベースをすばやくリカバリできます。

フラッシュバック・データベースは、従来のPoint-in-Timeリカバリと類似しています。フラッシュバック・データベースを使用すると、データベースを直前の状態に戻すことができます。フラッシュバック・データベースは、Point-in-Timeリカバリよりはるかに高速です。フラッシュバック・データベースでは、バックアップからデータファイルをリストアする必要がなく、アーカイブREDOログから変更をほとんど適用する必要がないためです。

データファイルが影響を受けていない場合、フラッシュバック・データベースを使用して、データベースに対する最も不要な変更を無効にすることができます。データベースを直前のインカネーションの状態に戻したり、ALTER DATABASE OPEN RESETLOGS文の効果を元に戻すことができます。FLASHBACK DATABASEコマンドを使用してデータベースの変更を無効にする方法については、「フラッシュバック・データベースを使用したデータベースの巻戻し」を参照してください。

フラッシュバック・データベースでは、独自のロギング・メカニズムによってフラッシュバック・ログが作成され、高速リカバリ領域に格納されます。フラッシュバック・データベースは、フラッシュバック・ログが使用可能な場合にのみ使用できます。フラッシュバック・データベースを使用するには、フラッシュバック・ログが作成されるようにデータベースを事前に設定しておく必要があります。

フラッシュバック・データベースを有効にするには、高速リカバリ領域を構成し、フラッシュバック保存目標を設定します。この保存目標では、フラッシュバック・データベースを使用してデータベースをどの程度巻き戻すかを指定します。

その時点以降、一定間隔で、すべてのデータファイル内の変更されている各ブロックのイメージがフラッシュバック・ログにコピーされます。これらのブロック・イメージを後で再利用して、ログが取得された時点のデータファイルの内容を再構築できます。

フラッシュバック・データベースを使用してデータベースを過去の目標時点に巻き戻すと、コマンドによって、目標時点以降に変更されたブロックが判別され、フラッシュバック・ログからリストアされます。データベースでは、目標時点の直前の各ブロックのバージョンがリストアされます。次に、データベースでは、REDOログを使用して、これらのブロックがフラッシュバック・ログに書き込まれた後に行われた変更が再適用されます。

ディスクまたはテープ上のREDOログは、フラッシュバック・ログに記録されている期間中、使用可能である必要があります。たとえば、フラッシュバック保存目標が1週間の場合は、過去1週間のすべての変更が含まれているオンラインREDOログおよびアーカイブREDOログに、アクセスできるようにしておく必要があります。実際にPoint-in-Timeリカバリをサポートするには、通常、REDOログはフラッシュバック保存目標より長い期間必要とされます。

フラッシュバック・データベース・ウィンドウ

FLASHBACK DATABASEコマンドをサポートするための十分なフラッシュバック・ログ・データが現在存在するSCNの範囲をフラッシュバック・データベース・ウィンドウと呼びます。フラッシュバック・データベース・ウィンドウは、使用可能なフラッシュバック・ログの最も古いSCNより前に延長することはできません。

注意:
表領域の削除やデータファイルの縮小などの一部のデータベース操作は、フラッシュバック・データベースで無効にできません。詳細は、「フラッシュバック・データベースの制約」を参照してください。

フラッシュバック・ログは、高速リカバリ領域外の場所にはバックアップできません。フラッシュバック・データベース・ウィンドウを満たすための十分なフラッシュバック・ログが保存される可能性を高くするために、高速リカバリ領域を増加することができます(「高速リカバリ領域の初期化パラメータ」を参照)。

高速リカバリ領域が、保存方針に必要なフラッシュバック・ログおよびアーカイブREDOログや他のバックアップなどのファイルを保持できるサイズでない場合、データベースでは、最も古いSCNからフラッシュバック・ログを削除して他のファイル用に領域を確保することができます。この結果、フラッシュバック・データベース・ウィンドウは、高速リカバリ領域のサイズ、保存する必要がある他のバックアップおよび必要なフラッシュバック・ロギング・データの量に応じてフラッシュバック保存目標より短くなる可能性があります。フラッシュバック保存目標は目標であり、フラッシュバック・データベースが使用可能であることを保証するものではありません。

フラッシュバック・データベース・ウィンドウの長さが十分でないためFLASHBACK DATABASEを使用できないときは、ほとんどの場合、同様の目的でデータベースのPoint-in-Timeリカバリ(DBPITR)を使用できます。フラッシュバック・データベースを使用して特定の時点に戻すか、またはフラッシュバック・ウィンドウのサイズを確保できるようにする場合は、保証付きリストア・ポイントが唯一の方法となります。

関連項目:

- フラッシュバック・データベースについては、「フラッシュバック・データベースを使用したデータベースの巻戻し」を参照してください。

- DBPITRについては、「データベースのPoint-in-Timeリカバリの実行」を参照してください。

フラッシュバック・データベースの制約

フラッシュバック・データベースでは、コマンド実行時に存在した、データファイルに対する変更が取り消されるため、次の制約があります。

- フラッシュバック・データベースでは、Oracle Databaseで行われたデータファイルに対する変更のみを元に戻すことができます。メディア障害の修復またはデータファイルの誤った削除からのリカバリには使用できません。

- フラッシュバック・データベースを使用して、データファイルの縮小操作を元に戻すことはできません。ただし、縮小されたファイルをオフラインにして、データベースの残りの部分をフラッシュバックし、その後、縮小されたデータファイルをリストアおよびリカバリすることはできます。

- フラッシュバック・データベースのみを使用して、削除されたデータファイルを回復することはできません。削除されたデータファイルがデータベースに存在していた時点にデータベースをフラッシュバックした場合、データファイル・エントリが制御ファイルに追加されるだけです。削除されたデータファイルをリカバリできるのは、RMANを使用してデータファイルを完全にリストアおよびリカバリした場合のみです。

- データベース制御ファイルがバックアップからリストアされるか、または再作成されると、すべての累積フラッシュバック・ログ情報が破棄されます。制御ファイルのリストアまたは再作成前の時点に戻すためにFLASHBACK DATABASEを使用することはできません。

- NOLOGGING操作が実行中だった時点を目標時点としてフラッシュバック・データベースを使用する場合、NOLOGGING操作によって影響を受けたデータベース・オブジェクトおよびデータファイルに、ブロック破損が残る可能性があります。たとえば、ダイレクト・パスINSERT操作をNOLOGGINGモードで2005年4月3日9:00から9:15に実行したとします。その後、フラッシュバック・データベースを使用して同じ日の9:07の目標時点に戻す場合、ダイレクト・パスINSERTによって更新されたオブジェクトおよびデータファイルは、フラッシュバック・データベース操作が完了した後も、ブロック破損状態のままである可能性があります。
可能な場合、NOLOGGING操作と同時の目標時点またはSCNでフラッシュバック・データベースを使用することを避けてください。また、NOLOGGING操作を実行したら、その直後に、影響を受けたデータファイルの全体バックアップまたは増分バックアップを実行して、操作後の時点へのリカバリが可能になるようにしてください。フラッシュバック・データベースを使用して、ダイレクト・パスINSERTなどの操作中の時点に戻す予定がある場合、操作をLOGGINGモードで実行することを検討してください。

関連項目:
NOLOGGINGモードをサポートしている操作の詳細は、Oracle Database SQLリファレンスのLOGGING_CLAUSEの説明を参照してください。

通常のリストア・ポイント

通常のリストア・ポイントを作成すると、リストア・ポイント名がSCNまたは特定の時点に割り当てられます。これによって、リストア・ポイントはこのSCNのブックマークまたは別名として機能します。通常のリストア・ポイントは、無効にする必要がある操作を実行する前に作成できます。制御ファイルに、リストア・ポイント名およびSCNが格納されます。

フラッシュバック機能またはPoint-in-Timeリカバリを使用する場合は、時刻またはSCNのかわりに、リストア・ポイント名を使用します。次のコマンドでは、リストア・ポイントをこの方法で使用できます。

- RMANのRECOVER DATABASEおよびFLASHBACK DATABASEコマンド

- SQLのFLASHBACK TABLE文

通常のリストア・ポイントを作成すると、事前に手動でSCNを記録する必要がありません。つまり、問題が発生した後でフラッシュバック問合せなどの機能を使用して適切なSCNを判別します。

通常のリストア・ポイントは軽量です。制御ファイルには、データベースのパフォーマンスに大きな影響を与えることなく、数千もの通常のリストア・ポイントの記録を保持できます。通常のリストア・ポイントは、手動で削除しない場合でも、最終的には制御ファイルからエージ・アウトされるため、継続的なメンテナンスは不要です。

参照:
フラッシュバック問合せの使用方法については、『Oracle Databaseアドバンスト・アプリケーション開発者ガイド』を参照してください。

保証付きリストア・ポイント

通常のリストア・ポイントと同様に、保証付きリストア・ポイントは、リカバリ操作でSCNの別名として機能します。保証付きリストア・ポイントは、制御ファイルからエージ・アウトされず、明示的に削除する必要がある点が主な違いとなります。通常、保証付きリストア・ポイントは、通常のリストア・ポイントで動作するすべてのコマンドで、SCNの別名として使用できます。特に明記されていないかぎり、通常のリストア・ポイントの使用箇所および使用方法に関する情報は、保証付きリストア・ポイントにも適用されます。

保証付きリストア・ポイントによって、フラッシュバック・ログが無効になっている場合でも、フラッシュバック・データベースを使用してデータベースをリストア・ポイントSCNの状態に巻き戻すことができます。フラッシュバック・ロギングが有効になっている場合は、保証付きリストア・ポイントによって、最も古い保証付きリストア・ポイント以降の任意のSCNまで、フラッシュバック・データベースに必要なフラッシュバック・ログが保存されます。したがって、フラッシュバック・ロギングが有効になっている場合は、データベースを1つのSCNにのみ巻き戻すのではなく、連続したいずれかのSCNに巻き戻すことができます。

注意:
フラッシュバック・ロギングが無効になっている場合は、FLASHBACK DATABASEを使用して、保証付きリストア・ポイントと現時点の間にあるSCNに直接データベースをフラッシュバックすることはできません。ただし、最初に保証付きリストア・ポイントにフラッシュバックしてから、保証付きリストア・ポイントと現時点の間にあるSCNにリカバリすることはできます。

必要なログを格納できる十分なディスク領域がリカバリ領域にある場合は、保証付きリストア・ポイントを使用して、数日前または数週間前の良好な状態にデータベース全体を巻き戻すことができます。フラッシュバック・データベースの場合と同様に、ダイレクト・ロード・インサートなどのNOLOGGING操作の影響も、保証付きリストア・ポイントを使用して無効にすることができます。

注意:
フラッシュバック・データベースに適用される制限事項は、保証付きリストア・ポイントにも適用されます。たとえば、データファイルの縮小または表領域の削除を行うと、その影響を受けるデータファイルは、保証付きリストア・ポイントまでフラッシュバックされません。詳細は、「フラッシュバック・データベースの制約」を参照してください。また、データベースに保証付きリストア・ポイントが存在する場合は、データベース互換性パラメータを上位のデータベース・バージョンに設定できません。設定すると、エラーが発生します。このように制限されるのは、現在、フラッシュバック・データベースでは互換性初期化パラメータを使用してデータベース・バージョンの増加を無効にできないためです。

保証付きリストア・ポイントとストレージ・スナップショットの比較

実際、保証付きリストア・ポイントは、ストレージ・スナップショットにかわる有効な機能です。多くの場合、ストレージ・スナップショットは、大規模なデータベースの更新、アプリケーションのパッチの適用やアップグレードなどの危険を伴う操作の前に、データベースを保護するために使用します。操作のテスト用にスナップショットまたは複製データベースを作成するかわりに、プライマリ・データベースまたはフィジカル・スタンバイ・データベースに保証付きリストア・ポイントを作成できます。これによって、必要なフラッシュバック・ログが確実に保存される状態で、危険を伴う操作を実行できます。

フラッシュバック・データベースおよび保証付きリストア・ポイントのロギング

フラッシュバック・データベースおよび保証付きリストア・ポイントのロギングでは、変更が適用される前のデータファイル・ブロックのイメージを取得する必要があります。FLASHBACK DATABASEコマンドでは、これらのイメージを使用して、データファイルを前の状態に戻すことができます。

通常のフラッシュバックのロギングと保証付きリストア・ポイントのロギングの主な違いは、ブロックをロギングするタイミング、および高速リカバリ領域で領域圧迫に応じてログを削除できるかどうかに関連しています。これらの違いは、ログに対する領域の使用状況およびデータベースのパフォーマンスに影響します。

リカバリ可能目標によって、フラッシュバック・データベースのロギングを有効にするかどうか、または保証付きリストア・ポイントを使用するかどうか、あるいはその両方を行うかどうかが部分的に決定されます。これらの機能を個別に使用した場合および同時に使用した場合のパフォーマンスおよび領域の使用状況への影響も、決定を行う場合の要因として考慮する必要があります。

保証付きリストア・ポイントおよび高速リカバリ領域の領域使用状況

次の規則によって、高速リカバリ領域でのフラッシュバック・ログの作成、保存、上書きおよび削除が制御されます。

- フラッシュバック・ログは、高速リカバリ領域に十分な領域がある場合、フラッシュバック保存目標の達成に必要になると常に作成されます。

- フラッシュバック・ログは、フラッシュバック保存目標の達成に不要になるほど古くなると、再利用されます。

- データベースでフラッシュバック・ログを作成する必要がある場合に、高速リカバリ領域が一杯になるか、またはディスク領域がなくなると、かわりに最も古いフラッシュバック・ログが再利用されます。

注意:
最も古いフラッシュバック・ログを再利用すると、フラッシュバック・データベース・ウィンドウは短くなります。ディスク領域の不足が原因で、多くのフラッシュバック・ログが再利用されると、フラッシュバック保存目標が達成されない場合があります。

- 高速リカバリ領域が一杯になると、他のファイル用の領域を確保するために、高速リカバリ領域規則に従って再利用可能なアーカイブREDOログが高速リカバリ領域によって自動的に削除される場合があります。この場合、FLASHBACK DATABASEを使用するために、そのREDOログ・ファイルを使用する必要があるフラッシュバック・ログも削除されます。

注意:
高速リカバリ領域規則では、次のいずれかの条件が満たされた場合にファイルが再利用可能となります。

- ファイルは、不要およびフラッシュバック・データベースで必要なしとしてレポートされます。たとえば、ファイルはDB_FLASHBACK_RETENTION_TARGETパラメータの範囲外となります。このファイルはテープにバックアップされます。

- 高速リカバリ領域内のファイルは、保証付きリストア・ポイントを満たすために必要な場合は削除対象になりません。保証付きリストア・ポイントを満たすために必要なアーカイブREDOログは、ディスクまたはテープにバックアップ後に削除できる場合があります。RMAN FLASHBACK DATABASEコマンドを使用する際に、指定した保証付きリストア・ポイントを満たすために必要なアーカイブREDOログが高速リカバリ領域で使用できない場合、それらはバックアップからリストアされます。
バックアップ保存方針を満たすために必要なファイルに加えて、保証付きリストア・ポイントを満たすために必要なフラッシュバック・ログおよびその他のファイルを保存すると、高速リカバリ領域が完全に一杯になる場合があります。高速リカバリ領域が一杯になった場合は、「高速リカバリ領域が一杯になった場合の対応」を参照してください。

保証付きリストア・ポイントを作成する場合は、フラッシュバック・データベースの完全なロギングを有効にしているかどうかに関係なく、高速リカバリ領域で使用可能な領域を監視する必要があります。高速リカバリ領域のディスク領域の使用状況を監視する方法については、「高速リカバリ領域でのフラッシュバック・ログの領域の管理」を参照してください。

注意:
保存方針の要件および保証付きリストア・ポイントのため、高速リカバリ領域からの削除対象となるファイルがない場合、データベースはディスクが一杯になった場合と同様に動作します。多くの場合、これによってデータベースは停止します。「高速リカバリ領域が一杯になった場合の対応」を参照してください。

フラッシュバック・ロギングが無効になっている状態での保証付きリストア・ポイントのロギング

フラッシュバック・データベースのロギングが無効になっているときに保証付きリストア・ポイントを作成するとします。この場合、保証付きリストア・ポイントの時点以降にデータファイル・ブロックが初めて変更されると、データベースによって、変更前のブロックのイメージがフラッシュバック・ログに格納されます。このため、フラッシュバック・ログには、保証付きリストア・ポイントが作成された時点で変更されているすべてのデータ・ブロックの内容が保持されます。同じブロックに対するこれ以降の変更では、そのブロックが最後に変更されてから別の保証付きリストア・ポイントが作成されない、または以降のフラッシュバック・データベース操作がブロックの元のコンテンツにリストアされないかぎり、その内容が再度ロギングされることはありません。フラッシュバック・データベースを使用してデータベースを同じリストア・ポイントに複数回リストアする場合、保証付きリストア・ポイントを毎回削除して再作成するのが一般的です。これにより古いフラッシュバック・ログは削除され、高速リカバリ領域の領域割当て制限を超えないことも保証されます。

このロギング方法には、次の重要な効果があります。

- FLASHBACK DATABASEを使用すると、ブロック・イメージを使用して、保証付きリストア・ポイントの時点でのデータファイルの内容を再作成できます。

- 同じデータを繰り返し変更するワークロードでは、ディスク領域の使用量が、通常のフラッシュバック・ロギングより少なくなる可能性があります。変更された各ブロックは1回のみロギングされるため、必要な領域が少なくなります。このディスク領域の節約は、小さいボリュームが挿入されたアプリケーションでは有効な場合があります。大きいボリュームまたは大きいバッチが挿入されたアプリケーションでは、このメリットはあまりありません。また、フラッシュバック・データベース・ロギングを行わずに保証付きリストア・ポイントをロギングした場合のパフォーマンスのオーバーヘッドも小さくなる可能性があります。

保証付きリストア・ポイントが作成された時点にデータベースを戻すことが第一の目標であるとします。この場合は、通常、フラッシュバック・ロギングを無効にして、保証付きリストア・ポイントのみを使用する方がより効率的です。たとえば、週末にデータベース・ホストに対してアプリケーション・アップグレードを実行するとします。アップグレードの開始時に、保証付きリストア・ポイントを作成します。アップグレードに失敗した場合は、FLASHBACK DATABASEコマンドを使用して変更を無効にします。

保証付きリストア・ポイントが定義された状態でのフラッシュバック・データベースのロギング

フラッシュバック・データベースを有効にし、1つ以上の保証付きリストア・ポイントを定義すると、データベースで通常のフラッシュバック・ロギングが実行されます。この場合、現時点と現在定義されている最も古い保証付きリストア・ポイントの間の任意の時点にフラッシュバックするために必要なフラッシュバック・ログが、リカバリ領域に保存されます。フラッシュバック・ログは、保証を実現するために必要な場合、領域圧迫に応じて削除されることはありません。

フラッシュバック・ロギングでは、パフォーマンスのオーバーヘッドが発生します。また、データベースでのアクティビティのパターンに応じて、高速リカバリ領域で著しい領域圧迫が発生する場合もあります。したがって、高速リカバリ領域で使用される領域を監視する必要があります。

フラッシュバック・データベースおよび保証付きリストア・ポイントの前提条件

フラッシュバック・データベースおよび保証付きリストア・ポイントの操作を正常に行うには、いくつかの重要なデータベース・オプションを最初に設定する必要があります。

フラッシュバック・データベース

フラッシュバック・データベースを有効にする前に、次のデータベース設定を構成します。

- フラッシュバック・データベースの操作ではアーカイブ・ログが使用されるため、データベースをARCHIVELOGモードで実行している必要があります。

- フラッシュバック・ログは高速リカバリ領域にのみ格納可能なため、高速リカバリ領域を有効にする必要があります。

- Oracle Real Application Clusters(Oracle RAC)データベースの場合、高速リカバリ領域はクラスタ・ファイル・システムまたはASM内にある必要があります。

保証付きリストア・ポイント

保証付きリストア・ポイントを使用するには、データベースが追加の前提条件を満たす必要があります。つまり、COMPATIBLE初期化パラメータが10.2.0以上に設定されている必要があります。

注意:
通常のリストア・ポイントを使用する場合は、設定が必要な特別な前提条件はありません。

通常のリストア・ポイントと保証付きリストア・ポイントの使用

この項では、通常のリストア・ポイントおよび保証付きリストア・ポイントに関して使用する様々なコマンドおよび監視機能について説明します。

通常のリストア・ポイントと保証付きリストア・ポイントの作成

通常のリストア・ポイントまたは保証付きリストア・ポイントを作成するには、SQL文CREATE RESTORE POINTを使用します。このとき、リストア・ポイントの名前を入力し、それを保証付きリストア・ポイントにするか通常のリストア・ポイント(デフォルト)にするかを指定します。

リストア・ポイントを作成する手順

1. SQL*Plusをターゲット・データベースに接続します。

関連項目:
SQL*Plusを使用してデータベースに接続する方法については、『Oracle Database管理者ガイド』を参照してください。

2. データベースがオープンまたはマウントされていることを確認します。データベースがマウントされている場合、(フィジカル・スタンバイ・データベースでないかぎり)正しく停止されている必要があります。

3. CREATE RESTORE POINT文を実行します。
次に、SQL*Plusで通常のリストア・ポイントを作成する方法の例を示します。

SQL> CREATE RESTORE POINT before_upgrade;

次に、保証付きリストア・ポイントの作成方法の例を示します。

SQL> CREATE RESTORE POINT before_upgrade GUARANTEE FLASHBACK DATABASE;

関連項目:

- SQLのCREATE RESTORE POINT文の詳細は、『Oracle Database SQL言語リファレンス』を参照してください。

- リストア・ポイントを表示する方法については、「リストア・ポイントの表示」を参照してください。

- リストア・ポイントを削除する方法については、「リストア・ポイントの削除」を参照してください。

リストア・ポイントの表示

LISTコマンドを使用して、特定のリストア・ポイント、またはRMANリポジトリで認識されるすべてのリストア・ポイントを表示できます。このコマンドの例を次に示します。

LIST RESTORE POINT restore_point_name;
LIST RESTORE POINT ALL;

RMANは、リストア・ポイントのSCNおよび時刻、リストア・ポイントのタイプおよびリストア・ポイントの名前を表示します。出力例を次に示します。

RMAN> LIST RESTORE POINT ALL;

using target database control file instead of recovery catalog
SCN              RSP Time  Type       Time      Name
---------------- --------- ---------- --------- ----
341859           28-JUL-06            28-JUL-06 NORMAL_RS
343690           28-JUL-06 GUARANTEED 28-JUL-06 GUARANTEED_RS

現在定義されているすべてのリストア・ポイント(通常および保証付き)のリストを表示するには、次の問合せでV$RESTORE_POINT制御ファイル・ビューを使用します。

SQL> SELECT NAME, SCN, TIME, DATABASE_INCARNATION#,
GUARANTEE_FLASHBACK_DATABASE,STORAGE_SIZE
FROM V$RESTORE_POINT;

ビューからの出力は次のとおりです。

- 各リストア・ポイントの名前(保証付きおよび通常)

- SCN

- リストア・ポイントの作成日時とその時点のデータベース・インカネーション番号

- リストア・ポイントのタイプ(通常または保証付き)

- そのリストア・ポイントに対するフラッシュバック・データベース操作に必要な情報をサポートするために使用される高速リカバリ領域の領域量

通常のリストア・ポイントの場合、STORAGE_SIZEが0(ゼロ)になります。保証付きリストア・ポイントの場合、STORAGE_SIZEは、高速リカバリ領域のディスク領域の容量を示します。この領域は、そのリストア・ポイントに対するFLASHBACK DATABASEを保証するために必要なログの保持に使用されます。

関連項目:

- V$RESTORE_POINTの詳細は、『Oracle Databaseリファレンス』を参照してください。

- 「フラッシュバック・データベースを使用したデータベースの巻戻し」

リストア・ポイントの削除

既存のリストア・ポイントが不要であることを確認した場合、または既存のリストア・ポイントの名前を使用してリストア・ポイントを作成する必要がある場合は、SQL*Plus文DROP RESTORE POINTを使用して、リストア・ポイントを削除できます。次に例を示します。

SQL> DROP RESTORE POINT before_app_upgrade;
Restore point dropped.

通常のリストア・ポイントおよび保証付きリストア・ポイントの両方の削除に、同じ文を使用します。

注意:
通常のリストア・ポイントは、明示的に削除しなくても、最終的には制御ファイルからエージ・アウトされます。制御ファイル内のリストア・ポイントは、次の規則に基づいて保存されます。

- 最新の2048個のリストア・ポイントは、その保存期間に関係なく、常に制御ファイルに保存されます。

- CONTROL_FILE_RECORD_KEEP_TIMEの値よりも新しいリストア・ポイントは、定義されているリストア・ポイント数に関係なく、いずれも保持されます。

これらの条件のどちらも満たさない通常のリストア・ポイントは、制御ファイルからエージ・アウトされる可能性があります。

保証付きリストア・ポイントは制御ファイルからエージ・アウトされません。明示的に削除されるまで残ります。

参照:
SQLのDROP RESTORE POINT文の詳細は、『Oracle Database SQL言語リファレンス』を参照してください。

フラッシュバック・データベースの使用

この項では、フラッシュバック・データベース用の基本的なコマンドについて説明します。また、フラッシュバック・データベースのパフォーマンスを最適化するためのガイドラインを示します。

フラッシュバック・データベースの有効化

フラッシュバック・データベースを有効にするには、次の手順に従います。

フラッシュバック・ロギングを有効にする手順

1. データベース・インスタンスがオープンまたはマウントされていることを確認します。インスタンスがマウントされている場合、フィジカル・スタンバイ・データベースでないかぎり、データベースが正しく停止されている必要があります。その他のOracle RACインスタンスは、どのモードでもかまいません。

2. オプションで、DB_FLASHBACK_RETENTION_TARGETに、フラッシュバックの期間の長さを分単位で設定します。

ALTER SYSTEM SET DB_FLASHBACK_RETENTION_TARGET=4320; # 3 days

デフォルトでは、DB_FLASHBACK_RETENTION_TARGETは1日(1440分)に設定されます。

3. データベース全体でフラッシュバック・データベース機能を有効にします。

ALTER DATABASE FLASHBACK ON;

4. 必要に応じて、特定の表領域のフラッシュバック・ロギングを無効にします。
デフォルトでは、すべての永続表領域に対してフラッシュバック・ログが生成されます。特定の表領域のフラッシュバック・ロギングを無効にして、オーバーヘッドを軽減できます。次に例を示します。

ALTER TABLESPACE tbs_3 FLASHBACK OFF;

表領域のフラッシュバック・ロギングは、次のコマンドを使用して、後で再度有効にできます。

ALTER TABLESPACE tbs_3 FLASHBACK ON;

表領域に対してフラッシュバック・データベースを無効にする場合は、FLASHBACK DATABASEを実行する前に、データファイルをオフラインにする必要があります。

データベースをオープンした状態でフラッシュバック・データベースを有効にする場合、まれに、コマンドが必要なメモリーを取得できないことがあります。この理由でコマンドが失敗した場合、しばらくしてからコマンドを再試行するか、インスタンスを停止し再起動してからコマンドを再試行します。

フィジカル・スタンバイ・データベースでフラッシュバック・データベースを有効にすると、スタンバイ・データベースをフラッシュバックできます。スタンバイ・データベースのフラッシュバック・データベースには、Data Guard環境で使用可能ないくつかのアプリケーションがあります。詳細は、『Oracle Data Guard概要および管理』を参照してください。

フラッシュバック・データベースのロギングの無効化

マウントまたはオープンされた状態のいずれかのデータベース・インスタンスで、次のコマンドを発行します。

ALTER DATABASE FLASHBACK OFF;

最適なフラッシュバック・データベースのパフォーマンスのための環境の構成

フラッシュバック・ログをメンテナンスすると、データベース・インスタンスで発生するオーバーヘッドが比較的制限されます。変更されたブロックがメモリーからフラッシュバック・ログに比較的低い頻度で定期的に書き込まれ、プロセスおよびI/Oオーバーヘッドが制限されます。

フラッシュバック・データベースが有効になっている大規模な本番データベースのパフォーマンスを向上させるには、次のガイドラインに従うことをお薦めします。

- 高速リカバリ領域には、可能な場合、オペレーティング・システムのファイル・キャッシュを使用せずに高速なファイル・システムを使用します。
通常、データベースによって高速リカバリ領域に作成されるファイル(フラッシュバック・ログなど)は、サイズが大きくなります。オペレーティング・システムのファイル・キャッシュは、通常、これらのファイルに対しては有効ではなく、実際には、このファイル・キャッシュによって、これらのファイルに対する読取り/書込みを行った場合のCPUオーバーヘッドが増加する場合があります。したがって、オペレーティング・システムのファイル・キャッシュが行われないASMなどのファイル・システムを使用することをお薦めします。

- 高速リカバリ領域を保持するファイル・システムに、十分なディスク・スピンドルを構成します。
大規模な本番データベースでは、データベースでフラッシュバック・ログを効果的に書き込むために必要となるディスク・スループットをサポートするために、複数のディスク・スピンドルが必要な場合があります。

- 高速リカバリ領域の保持に使用されるストレージ・システムに非揮発性RAMがない場合は、ストライプ化されたストレージ・ボリュームにファイル・システムを構成します。
比較的小さなストライプ・サイズ(128KBなど)を使用します。この方法では、フラッシュバック・ログへのそれぞれの書込みを複数のスピンドルに分散することによって、パフォーマンスを向上できます。

- 大規模なデータベースでは、初期化パラメータLOG_BUFFERを8MB以上に設定します。

フラッシュバック・データベースのロギングで発生するオーバーヘッドは、データベース・ワークロードでの読取りと書込みの組合せによって異なります。ワークロードが書込み集中型の場合、データベースのすべての変更を記録する必要があるため、フラッシュバック・データベースのロギングのオーバーヘッドが増加します。問合せによってデータは変更されないため、フラッシュバック・データベースのロギング・アクティビティには影響しません。

フラッシュバック・データベースのパフォーマンスに対する影響の監視

自動ワークロード・リポジトリ(AWR)では、データベースの問題検出および自己チューニングのためにパフォーマンス統計の収集、処理および保持を行うことによって、データベースの統計収集が自動化されています。システムにおけるフラッシュバック・データベースのワークロードの監視を行う場合、そのデータ分析方法は複数あります。たとえば、フラッシュバック・データベースを有効にする前と後で、AWRレポートを比較できます。また、AWRスナップショットを参照して、フラッシュバック・ロギングによって発生するシステムの使用状況を明確にすることもできます。たとえば、flashback buf free by RVWRが最上位の待機イベントとして表示されている場合は、Oracle Databaseではフラッシュバック・ログへの迅速な書込みを行うことができないことを示しています。したがって、「最適なフラッシュバック・データベースのパフォーマンスのための環境の構成」で説明したいずれかの方法で、高速リカバリ領域に使用されているファイル・システムおよび記憶域をチューニングすることをお薦めします。

V$FLASHBACK_DATABASE_STATビューには、データベースによって記録されたフラッシュバック・データのバイト数が表示されます。ビューの各行には、(通常は1時間にわたって)累積された統計が表示されます。FLASHBACK_DATAおよびREDO_DATA列には、一定期間中に書き込まれたフラッシュバック・データおよびREDOデータのバイト数がそれぞれ示されます。DB_DATA列には、読取りおよび書込みが行われたデータ・ブロックのバイト数が示されます。FLASHBACK_DATAおよびREDO_DATA列は順次書込みに対応し、DB_DATA列はランダム読取りおよび書込みに対応しています。

順次I/OとランダムI/Oの違いのため、I/Oオーバーヘッドは、フラッシュバック・ログに対して発行されたI/O操作の数によってより明確に示されます。表7-1に示すV$SYSSTAT統計は、様々な目的のためにインスタンスによって発行されたI/O操作の数を示しています。

表7-1 V$SYSSTAT統計

列名

列の意味

physical write I/O request

データ・ブロックの書込みのために発行された書込み操作の数

Physical read I/O request

データ・ブロックの読取りのために発行された読取り操作の数

Redo writes

REDOログへの書込みのために発行された書込み操作の数

Flashback log writes

フラッシュバック・ログへの書込みのために発行された書込み操作の数

Flashback log write bytes

このインスタンスから書き込まれたフラッシュバック・データベース・データの合計バイト・サイズ

関連項目:

- V$SYSSTATビューの列の詳細は、『Oracle Databaseリファレンス』を参照してください。

- AWRの詳細は、『Oracle Databaseパフォーマンス・チューニング・ガイド』を参照してください。

- AWRレポートの詳細は、『Oracle Database 2日でパフォーマンス・チューニング・ガイド』を参照してください。

I/Oエラーが発生した場合のフラッシュバック・ライター(RVWR)の動作

フラッシュバックが有効になっている場合、または保証付きリストア・ポイントが存在する場合は、バックグラウンド・プロセスRVWRによって、高速リカバリ領域内のフラッシュバック・データベース・ログにフラッシュバック・データが書き込まれます。RVWRでI/Oエラーが発生した場合は、次の動作が予測されます。

- 保証付きリストア・ポイントが定義されている場合は、RVWRでI/Oエラーが発生すると、インスタンスで障害が発生します。

- 保証付きリストア・ポイントが定義されていない場合は、RVWRでI/Oエラーが発生しても、インスタンスは影響を受けません。次の場合に注意してください。

- プライマリ・データベースでは、データベースをオープンしている間はフラッシュバック・データベースが自動的に無効になります。既存のすべてのトランザクションおよび問合せは、影響を受けずに続行されます。これは、シングル・インスタンス・データベースおよびOracle RACデータベースの両方で予測される動作です。

- フィジカル・スタンバイ・データベースまたはロジカル・スタンバイ・データベースでは、RVWRが応答を停止してI/Oを定期的に再試行しているように見えます。最終的に、これによってロジカル・スタンバイ・データベース、またはフィジカル・スタンバイ・データベースの管理リカバリが一時停止する場合があります。(Oracle Databaseでは、スタンバイ・インスタンスの障害は発生しません。最大保護モードでプライマリ・データベースの障害が発生しないようにするためです)。この問題を解決するには、SHUTDOWN ABORTまたはALTER DATABASE FLASHBACK OFFコマンドを発行します。

第III部

データのバックアップおよびアーカイブ

この部の章では、RMANユーティリティを使用して拡張バックアップおよびリカバリ操作を実行する方法について説明します。また、RMANのパフォーマンス・チューニングおよびトラブルシューティングについて説明します。

この部に含まれる章は次のとおりです。

- 第8章「RMANバックアップの概要」

- 第9章「データベースのバックアップ」

- 第10章「データベースのバックアップ: 高度なトピック」

8 RMANバックアップの概要

この章では、すべてのタイプのRMANバックアップを作成するために理解しておく必要がある一般的な概念について説明します。この章の内容は次のとおりです。

- RMANの一貫性バックアップおよび非一貫性バックアップ

- オンライン・バックアップおよびバックアップ・モード

- バックアップ・セット

- イメージ・コピー

- RMANを使用したバックアップの複数のコピー

- 制御ファイルおよびサーバー・パラメータ・ファイルの自動バックアップ

- 増分バックアップ

- バックアップの保存方針

RMANの一貫性バックアップおよび非一貫性バックアップ

バックアップを作成するためのRMANのコマンドはBACKUPです。RMANのBACKUPコマンドでは、次のタイプのファイルのバックアップがサポートされています。

- データファイルおよび制御ファイル

- サーバー・パラメータ・ファイル

- アーカイブREDOログ

- RMANバックアップ

データベースは、ネットワーク構成ファイル、パスワード・ファイル、Oracleホームの内容などの他のタイプのファイルに依存していますが、これらのファイルはRMANではバックアップできません。同様に、Oracle Databaseの一部の機能(外部表など)には、データファイル、制御ファイルおよびREDOログ以外のファイルが必要な場合があります。RMANでは、これらのファイルをバックアップできません。リストにないファイルについては、RMAN以外の方法でバックアップします。

RMANでBACKUPコマンドを実行すると、出力は常に1つ以上のバックアップ・セットまたは1つ以上のイメージ・コピーになります。バックアップ・セットはRMANに固有の独自の形式ですが、イメージ・コピーはファイルのビットごとのコピーです。デフォルトでは、RMANはバックアップ・セットを作成します。

一貫性バックアップ

BACKUPコマンドを使用すると、データベースの一貫性バックアップおよび非一貫性バックアップを作成できます。一貫性バックアップは、データベースが一貫性のある状態のときに実行します。SHUTDOWN NORMAL、SHUTDOWN IMMEDIATEまたはSHUTDOWN TRANSACTIONALコマンドを使用して停止すると、データベースは一貫性のある状態になります。一貫性のある状態での停止では、すべてのREDOがデータファイルに確実に適用されています。データベースをマウントし、この時点でバックアップを作成すると、後でデータベース・バックアップをリストアし、メディア・リカバリを実行せずにオープンすることができます。

非一貫性バックアップ

一貫性のないデータベース・バックアップを非一貫性バックアップといいます。インスタンスでの障害の発生後またはSHUTDOWN ABORTコマンドの実行後に作成されたバックアップと同様に、データベースがオープンされているときに作成されたバックアップには一貫性がありません。非一貫性バックアップからデータベースをリストアする場合、Oracle Databaseでは、データベースをオープンする前に、メディア・リカバリを実行し、REDOログ内の保留中の更新情報を適用する必要があります。

注意:
データベースがNOARCHIVELOGモードの場合、RMANで非一貫性バックアップを作成することはできません。NOARCHIVELOGモードのデータベースに対してユーザー管理のバックアップ方法を使用する場合、このデータベースの非一貫性バックアップは作成しないでください。

データベースがARCHIVELOGモードで実行されているときに、アーカイブREDOログおよびデータファイルをバックアップする場合、非一貫性バックアップを適切なバックアップおよびリカバリ計画の基礎にすることができます。非一貫性バックアップでは、データベースを完全に保護するバックアップを作成するためにデータベースを停止する必要がないため、優れた可用性が実現されます。

オンライン・バックアップおよびバックアップ・モード

オンラインの表領域またはデータベースのユーザー管理のバックアップを実行すると、データベース・ライター(DBWR)によるファイルの更新と同時に、オペレーティング・システム・ユーティリティによってデータファイルのバックアップが作成される場合があります。ユーティリティは、更新途中の状態のブロックを読み取ることができるため、バックアップ・メディアにコピーされるブロックの前半は更新されていても、後半には古いデータが含まれていることがあります。このタイプの論理的な破損は、分裂ブロックと呼ばれます。つまり、SCNに関して一貫性のないブロックです。このバックアップを後でリストアし、ブロックをリカバリする必要がある場合は、ブロックを使用できないため、リカバリは失敗します。

ユーザー管理のオンライン・バックアップを実行する場合は、BEGIN BACKUP句を指定してALTER DATABASEまたはALTER TABLESPACE文を使用して、データファイルをバックアップ・モードにする必要があります。表領域がバックアップ・モードに設定されている場合、データベースは、ブロックを変更する前に、ブロック全体の変更前のイメージをREDOストリームに書き込みます。データベースは、ブロックに対する変更をオンラインREDOログに記録もします。また、バックアップ・モードでは、ファイルがバックアップ・モードから削除されるまで、データファイル・チェックポイントがフリーズされます。Oracle Databaseでは、サード・パーティのバックアップ・ツールでデータ・ブロックのコピーの前にファイル・ヘッダーがコピーされることを保証できないため、このようなセーフガードが実行されます。

ユーザー管理ツールとは異なり、RMANでは、データ・ブロックの形式が認識されるため、追加のロギングまたはバックアップが必要ありません。RMANでは、分裂ブロックがバックアップされないことが保証されています。RMANによるバックアップ中、データベース・サーバー・セッションは各データ・ブロックを読み取り、ブロック・ヘッダーとフッターを比較することによって、分裂していないかどうかを確認します。ブロックが分裂している場合、セッションはそのブロックを再度読み取ります。同じ分裂が検出された場合、ブロックは永続的に破損しているとみなされます。また、RMANでは、ブロックが読み取られる順序が認識されているため、データファイルのヘッダーのチェックポイントをフリーズする必要がなく、このため、そのファイルに最適なチェックポイントを取得できます。

関連項目:
RMANを使用しない場合にオンラインの表領域をバックアップする方法については、「オンラインの表領域およびデータファイルのユーザー管理バックアップの作成」を参照してください。

バックアップ・セット

RMANでBACKUPコマンドを実行すると、1つ以上のバックアップ・セットまたはイメージ・コピーを作成できます。デフォルトでは、出力先がディスクの場合もメディア・マネージャの場合も、バックアップ・セットが作成されます。

注意:
通常、データファイルのバックアップ・セットはデータファイルのイメージ・コピーよりサイズが小さく、書込みにかかる時間が短くなります。

この項の内容は、次のとおりです。

- バックアップ・セットおよびバックアップ・ピース

- バックアップ・セットのブロックの圧縮

- バックアップ・セットのバイナリ圧縮

- UNDOのバックアップ

- バックアップ・セットの暗号化

- バックアップ・ピースのファイル名

- バックアップ・ピースの数およびサイズ

- バックアップ・セットの数およびサイズ

- 多重バックアップ・セット

- プロキシ・コピー

バックアップ・セットおよびバックアップ・ピース

RMANは、バックアップ・データをバックアップ・セット(RMANバックアップの最小単位)と呼ばれる論理構造に格納できます。バックアップ・セットには、1つ以上のデータファイル、アーカイブREDOログ、制御ファイルまたはサーバー・パラメータ・ファイルのデータが含まれます。バックアップ・セットは、RMANによってテープ・ドライブやテープ・ライブラリなどのメディア・マネージャにバックアップを書き込むことができる唯一の形式です。

バックアップ・セットには、1つ以上のバイナリ・ファイルがRMAN固有の形式で含まれます。各ファイルは、バックアップ・ピースと呼ばれます。1つのバックアップ・セットに、複数のデータファイルを含めることができます。たとえば、1つのバックアップ・ピースで構成される1つのバックアップ・セットに、10個のデータファイルをバックアップできます。この場合、RMANでは、1つのバックアップ・ピースが出力として作成されます。バックアップ・セットには、このバックアップ・ピースのみが含まれます。

BACKUPコマンドにSECTION SIZEパラメータを指定すると、RMANによってマルチセクション・バックアップが作成されます。これは、複数のチャネルでパラレルに作成される単一の大規模なファイルのバックアップです。各チャネルによって、1つのバックアップ・ピースが作成されます。各バックアップ・ピースには、バックアップされるファイルのファイル・セクションが1つ含まれます。

マルチセクション・バックアップ以外のバックアップでは、RMANは、正常に完了したバックアップ・セットのみをリポジトリに記録します。部分バックアップ・セットのようなものはありません。これは、RMANメタデータに部分的なバックアップ・セットのレコードが含まれる可能性がある失敗したマルチセクション・バックアップとは異なります。後者の場合は、DELETEコマンドを使用して、部分的なバックアップ・セットを削除する必要があります。

注意:
RMANは、部分的なバックアップをリストアおよびリカバリの候補とみなしません。

関連項目:
第9章「データベースのバックアップ」

バックアップ・セットのブロックの圧縮

バックアップ・セットの作成時に、RMANでは、2種類のブロックの圧縮が使用されます。

- 未使用ブロックの圧縮(ディスク・バックアップおよびOracle Secure Backupテープ・バックアップをサポート)

- NULLブロックの圧縮(すべてのバックアップをサポート)

ブロックの圧縮と呼ばれていますが、ブロックのスキップと考えるとわかりやすくなります。RMANは、データをブロックに圧縮するのではなく、ブロックをバックアップから完全に削除します。RMANでは、データファイルからブロックが読み取られ、バックアップ・セットにブロックが書き込まれます。未使用ブロックの圧縮を有効にすると、RMANでは、現在データベース・セグメントに属しているエクステント内のデータファイルのブロックのみが読み取られます。未使用ブロックの圧縮は、領域がローカルで管理されている表領域をバックアップする場合にのみ使用できます。未使用ブロックの圧縮を使用しない場合、RMANでは、データファイルのすべてのブロックが読み取られます。RMANは、バックアップ・セットにブロックを書き込む前にNULLブロック・テストを適用し、ブロックが一度も使用されていない場合は、このブロックをバックアップ・セットに書き込みません。

未使用ブロックの圧縮

未使用ブロックの圧縮では、RMANは各ブロックを確認しません。かわりに、RMANは現在割り当てられているブロックを示すビットマップを読み取った後、現在割り当てられているブロックのみを読み取ります。

未使用ブロックの圧縮は、次の5つの条件がすべて満たされている場合に自動的に実行されます。

- COMPATIBLE初期化パラメータが10.2以上に設定されている。

- 現在、データベースに定義されている保証付きリストア・ポイントがない。

- データファイルがローカルで管理されている。

- データファイルが、全体バックアップまたはレベル0の増分バックアップの一部としてバックアップ・セットにバックアップされている。

- ディスクにバックアップ・セットが作成されているか、またはOracle Secure Backupがメディア・マネージャである。

NULLブロックの圧縮

NULLブロックの圧縮では、RMANは、データが含まれていたことがあるかどうか、各ブロックを確認します。データが含まれていたことのないブロックはバックアップされません。現在または過去にデータが含まれていたことのあるブロックは、バックアップされます。

バックアップ・セットのバイナリ圧縮

RMANでは、バックアップ・セットのバイナリ圧縮がサポートされています。バイナリ圧縮は、BACKUPコマンドでAS COMPRESSED BACKUPSETを指定した場合、またはCONFIGURE DEVICE TYPE <DISK | SBT> BACKUP TYPE TO COMPRESSED BACKUPSETコマンドを使用した場合(1回のみ)に有効になります。バイナリ圧縮には2つのオプションがあります。

- BASIC圧縮アルゴリズムを使用できます。この場合、Advanced Compressionオプションは必要ありません。この設定を使用すると、MEDIUMに相当する圧縮率を得られますが、CPU使用率は増加します。

- Oracle Database 11gリリース2 Advanced Compressionオプションを有効にすると、「Advanced Compressionオプション」に示す圧縮レベルのいずれかを選択できます。

関連項目:

- 「圧縮オプションの構成」

- BACKUP AS BACKUPSETおよびCONFIGURE COMPRESSION ALGORITHMの詳細は、『Oracle Databaseバックアップおよびリカバリ・リファレンス』を参照してください。

UNDOのバックアップ

UNDOのバックアップの最適化では、RMANは、トランザクションがコミットされているためバックアップのリカバリに不要となったUNDOを除外します。UNDOのバックアップの最適化は、レベル0および全体のディスク・バックアップおよびOracle Secure Backup(OSB)テープ・バックアップに機能します。バックアップの最適化とは異なり、UNDOのバックアップの最適化は構成不可能です。

バックアップ・セットの暗号化

RMANでは、バックアップ・セットのバックアップの暗号化がサポートされています。ウォレットベースの透過的暗号化またはパスワードベースの暗号化(あるいはその両方)を使用できます。CONFIGURE ENCRYPTIONコマンドを使用すると、永続的な透過的暗号化を構成できます。パスワードベースの暗号化を指定するには、RMANセッション・レベルでSET ENCRYPTIONコマンドを使用します。

注意:
ウォレットベースの暗号化は、パスワードが必要ないため、パスワードベースの暗号化より安全です。パスワードベースの暗号化は、バックアップをトランスポータブルにする必要があるため絶対に必要な場合にのみ使用してください。

RMANを使用してディスクに暗号化バックアップを作成するには、データベースでAdvanced Security Optionを使用している必要があります。Oracle Secure Backup SBTは、暗号化RMANバックアップをテープに直接作成するためにサポートされている唯一のインタフェースです。

関連項目:

- 「バックアップの暗号化の構成」

- 「RMANバックアップの暗号化」

バックアップ・ピースのファイル名

バックアップ・ピースの一意の名前をRMANに決定させることも、FORMAT句を使用して名前を指定することもできます。FORMATパラメータを指定しない場合、RMANは、%U置換変数を含む一意のファイル名をデフォルトのバックアップ場所に自動的に生成します。

%UによってRMANで生成されるSBTバックアップ・ピース名の例は、次のとおりです。

2i1nk47_1_1

ディスクの非Oracle Managed File(OMF)バックアップ・ピースの例は、次のとおりです。

/backups/TEST/2i1nk47_1_1

FORMAT句では、一意のファイル名を生成するために%U以外の置換変数がサポートされています。たとえば、データベースの名前を生成するために%d、DBID用に%I、タイムスタンプ用に%tなどを使用できます。

最大4つのFORMATパラメータを指定できます。複数のFORMATパラメータを指定すると、複数のコピーを指定する場合にのみRMANで複数のFORMATパラメータを使用できます。BACKUP ... COPIES、SET BACKUP COPIESまたはCONFIGURE ... BACKUP COPIESコマンドを使用すると、複数のコピーを作成できます。

注意:
メディア・マネージャを使用する場合のFORMATの制限(名前のサイズ、ネーミング規則など)については、ベンダーのドキュメントを参照してください。

関連項目:

- 「RMANバックアップのフォーマットの指定」

- FORMAT句およびその置換変数については、『Oracle Databaseバックアップおよびリカバリ・リファレンス』を参照してください。

バックアップ・ピースの数およびサイズ

デフォルトでは、バックアップ・セットは、1つのバックアップ・ピースで構成されます。各バックアップ・ピースのサイズを制限するには、CONFIGURE CHANNELまたはALLOCATE CHANNELコマンドのMAXPIECESIZEオプションを指定します。このオプションによって、バックアップ・ピースのサイズが指定したバイト数に制限されます。バックアップ・セットの合計サイズが指定したバックアップ・ピースのサイズを超えた場合、RMANは、バックアップ・セットの内容を保持する複数の物理ピースを作成します。

このオプションは、複数のテープにまたがるバックアップ・ピースを管理できないメディア・マネージャに使用できます。たとえば、最大容量が10GBのテープに、80GBのデータを保持するバックアップ・セットを作成する必要がある場合、メディア・マネージャで使用するテープに格納できる10GBのバックアップ・ピースを作成するように、RMANに指示する必要があります。この場合、バックアップ・セット・メディアは8つのテープから構成されます。SBT 2.0をサポートしているメディア・マネージャの場合、サポートするバックアップ・ピースの最大サイズを示す値をRMANに戻すことができるため、RMANはその値をバックアップ・アクティビティの計画に使用できます。

BACKUPコマンドにSECTION SIZEパラメータを指定すると、RMANによってマルチセクション・バックアップを作成できます。この場合、1つのバックアップ・セットに複数のバックアップ・ピースを含めることができます。各バックアップ・ピースにはファイル・セクションが含まれます。マルチセクション・バックアップの目的は、複数のチャネルで大規模なファイルをパラレルでバックアップできるようにすることです。

関連項目:

- 「バックアップ・ピースの最大サイズの構成」

- ALLOCATE CHANNELの構文については、『Oracle Databaseバックアップおよびリカバリ・リファレンス』を参照してください。

- CONFIGUREの構文については、『Oracle Databaseバックアップおよびリカバリ・リファレンス』を参照してください。

バックアップ・セットの数およびサイズ

BACKUPコマンドのbackupSpec句を使用すると、バックアップするオブジェクトを指定できます。backupSpec句を1つ指定するごとに、1つ以上のバックアップ・セットが作成されます。

バックアップ・セットの合計数および合計サイズは、主にRMANの内部アルゴリズムに基づいています。ただし、CONFIGUREまたはBACKUPコマンドのMAXSETSIZEパラメータを使用して、RMANの動作に影響を及ぼすことができます。このパラメータを使用してバックアップ・セットのサイズを制限することによって、セット内のファイル数を間接的に制限でき、場合によっては、RMANに追加のバックアップ・セットを作成させることができます。また、BACKUP ... FILESPERSETを指定して、各バックアップ・セット内のファイルの最大数を指定することもできます。

関連項目:

- 「バックアップ・セットのサイズ」

- RMANのバッファ管理については、第22章「RMANのパフォーマンスのチューニング」を参照してください。

- backupSpec句の構文については、『Oracle Databaseバックアップおよびリカバリ・リファレンス』を参照してください。

多重バックアップ・セット

バックアップ・セットの作成時に、RMANは、ディスクから複数のファイルを同時に読み取って、同じバックアップ・セットにそれらのブロックを書き込むことができます。たとえば、RMANは、2つのデータファイルから同時に読取りを行って、それらのデータファイルのブロックを単一のバックアップ・ピースに組み合せることができます。複数のファイルからのブロックの組合せは、バックアップの多重化と呼ばれます。これに対して、イメージ・コピーは多重化されません。

注意:
RMANによってデータファイルのマルチセクション・バックアップが作成された場合、そのデータファイルは他のすべてのデータファイルまたはファイル・セクションとは多重化されません。

図8-1に示すように、RMANは、1つのバックアップ・ピースのみを含むバックアップ・セットに3つのデータファイルをバックアップできます。このバックアップ・ピースには、3つの入力データファイルのデータ・ブロックが組み合されて格納されます。

図8-1 データファイルの多重化

RMANによる多重化は、複数の要因によって決定されます。たとえば、各バックアップ・セットに格納されるデータファイルの数は、BACKUPコマンドのFILESPERSETパラメータによって決定されます。RMANが同時に読み取ることができるデータファイルの数は、ALLOCATE CHANNELまたはCONFIGURE CHANNELのMAXOPENFILESパラメータによって定義されます。基本的な多重化アルゴリズムは、次のとおりです。

- 各バックアップ・セット内のファイルの数
この数は、FILESPERSET設定および各チャネルによって読み込まれるファイル数の最小値です。FILESPERSETのデフォルトは64です。

- 多重化レベル
これは、同時に読み取られ、同じバックアップ・ピースに書き込まれる入力ファイルの数です。多重化のレベルは、MAXOPENFILESおよび各バックアップ・セット内のファイル数の最小値です。MAXOPENFILESのデフォルトは8です。

FILEPERSETが4に設定されている場合に、1つのチャネルで12のデータファイルをバックアップするとします。多重化のレベルは、この数と8の小さい方になります。したがって、ブロックは、チャネルによって4つのデータファイルから各バックアップ・ピースに同時に書き込まれます。

次に、1つのチャネルで50のデータファイルをバックアップするとします。各バックアップ・セット内のファイル数は50です。多重化のレベルは、この数と8の小さい方になります。したがって、ブロックは、チャネルによって8つのデータファイルから各バックアップ・ピースに同時に書き込まれます。

RMANによるバックアップ・セットの多重化は、メディア・マネージャによる多重化とは異なります。メディア・マネージャによる多重化のタイプの1つとして、メディア・マネージャが、複数のRMANチャネルからの同時出力を単一のシーケンシャル・デバイスに書き込んだ場合に発生するものがあります。また、別のタイプとして、バックアップによって同じテープ上にデータベース・ファイルとデータベース以外のファイルが混在した場合に発生するものもあります。

注意:
RMANバックアップには、メディア・マネージャによる多重化を使用しないことをお薦めします。

関連項目:

- バックアップ時に多重化がディスク・バッファの割当てに及ぼす影響については、「入力ディスク・バッファの割当て」を参照してください。

- BACKUPの構文については、『Oracle Databaseバックアップおよびリカバリ・リファレンス』を参照してください。

プロキシ・コピー

プロキシ・コピーでは、RMANは、プロキシ・コピー機能をサポートしているメディア・マネージャに、データ送信の制御を移します。プロキシ・コピーはこの機能をサポートしているメディア・マネージャでのみ使用でき、タイプがDISKのチャネルでは使用できません。BACKUPコマンドのPROXYオプションを使用して、バックアップでプロキシ・コピーを実行することを指定します。

BACKUP PROXYコマンドでバックアップするファイルごとに、RMANは、プロキシ・コピーを実行できるかどうかをメディア・マネージャに問い合せて確認します。メディア・マネージャがファイルのプロキシ・コピーを実行できない場合、RMANは、PROXYオプションを使用しなかった場合と同様にファイルをバックアップします。(PROXY ONLYオプションを使用している場合に、プロキシ・コピーが実行できない場合は、RMANはバックアップを行いません。)

制御ファイルはプロキシ・コピーではバックアップされません。制御ファイルのバックアップ操作でPROXYオプションを指定した場合、このオプションは自動的に無視され、制御ファイルのバックアップが行われます。

関連項目:

- V$PROXY_DATAFILEビューおよびV$PROXY_ARCHIVEDLOGビューの詳細は、『Oracle Databaseリファレンス』を参照してください。

- BACKUPコマンドおよびPROXYオプションについては、『Oracle Databaseバックアップおよびリカバリ・リファレンス』を参照してください。

イメージ・コピー

イメージ・コピーは、1つのデータファイル、アーカイブREDOログ・ファイルまたは制御ファイルの正確なコピーです。 イメージ・コピーはRMAN固有の形式では格納されません。これらは、オペレーティング・システム・コマンドでファイルをコピーした場合と同じ形式で格納されます。イメージ・コピーは、RMANのリストアおよびリカバリ操作中に使用できます。また、RMAN以外のリストアおよびリカバリ方法でもイメージ・コピーを使用できます。

RMANで作成したイメージ・コピー

イメージ・コピーを作成してRMANリポジトリに記録するには、RMANのRMAN BACKUP AS COPYコマンドを実行します。また、ディスクのデフォルトのバックアップ・タイプをイメージ・コピーとして構成することもできます。コピーの作成には、データベース・サーバー・セッションが使用されます。このサーバー・セッションが、ファイル内のブロックの検証やRMANリポジトリへのイメージ・コピーの記録などの処理を実行します。

バックアップ・ピースの場合と同様に、FORMAT変数を使用してイメージ・コピーの名前を指定します。イメージ・コピーの場合は、デフォルトの書式%U(「バックアップ・ピースのファイル名」を参照)の定義が異なります。次に、%Uによって生成されるデータファイル2の名前の例を示します。

/d1/oracle/work/orcva/RDBMS/datafile/o1_mf_sysaux_2qylngm3_.dbf

イメージ・コピーを作成する場合は、 BACKUPコマンドのDB_FILE_NAME_CONVERTパラメータで、出力コピーに名前を指定することもできます。このパラメータの動作は、DB_FILE_NAME_CONVERT初期化パラメータと同一です。ファイル名の接頭辞のペアを指定すると、出力ファイルの名前が変更されます。 ファイルがペアのいずれによっても変換されない場合、FORMAT仕様が使用されます。FORMATが指定されていない場合、デフォルトの書式%Uが使用されます。

例8-1では、ファイル名の先頭に/maindisk/oradata/usersが付くデータファイルを、先頭に/backups/users_tsが付くファイル名に変更してコピーします。

例8-1 DB_FILE_NAME_CONVERTを使用したファイル名の指定

BACKUP AS COPY
DB_FILE_NAME_CONVERT ('/maindisk/oradata/users',
'/backups/users_ts')
TABLESPACE users;

RESTOREコマンドを実行すると、デフォルトでは、イメージ・コピー・バックアップをコピーすることによって、データファイルまたは制御ファイルが元の場所にリストアされます。イメージ・コピーが選択されるのは、バックアップ・セットを使用すると、リストアするファイルを検索するためにバックアップ・セット全体が読み取られ、オーバーヘッドが増加するためです。

現行のデータファイルをリストアおよびリカバリする必要があり、ディスク上に使用可能なイメージ・コピーが存在する場合は、RMANでイメージ・コピーを元の場所にコピーする必要はありません。リストア対象のデータファイルのかわりに、イメージ・コピーを使用できます。このタスクの実行方法については、「コピーへの切替え後の完全リカバリの実行」を参照してください。

関連項目:

- バックアップ・セットまたはイメージ・コピーのいずれかをRMANバックアップのデフォルト・タイプにする方法については、「バックアップ用のデフォルト・タイプの構成: バックアップ・セットまたはコピー」を参照してください。

- 「ディスクへのRMANバックアップ用のバックアップ・セットまたはバックアップ・コピーの指定」

- イメージ・コピーでの%Uの意味については、『Oracle Databaseバックアップおよびリカバリ・リファレンス』を参照してください。

ユーザー管理イメージ・コピー

RMANでは、ディスク上にファイルのイメージ・コピーを作成するオペレーティング・システム固有のファイル・コピー・コマンドや、サード・パーティ・ユーティリティなど、RMAN以外のメカニズムで作成したイメージ・コピーを使用できます。このタイプのコピーは、ユーザー管理バックアップまたはオペレーティング・システムのバックアップと呼ばれます。

CATALOGコマンドを使用して既存のイメージ・コピーを検査し、そのメタデータをRMANリポジトリに入力できます。ただし、CATALOGコマンドでは、次の処理は行われません。

- 破損がないことを保証するためのデータファイルのコピー内のすべてのブロックの読取り

- イメージ・コピーがバックアップ・モードで正常に作成されたことの保証

これらのファイルをカタログに追加した後、それらをRESTOREまたはSWITCHコマンドで使用できます。これは、RMANによって生成されるイメージ・コピーの場合と同様です。

ミラー化されたディスク・ボリューム上にデータファイルを格納しているサイトでは、ミラー化の解除によってイメージ・コピーの作成が可能になります。ミラー化を解除した後で、新しいユーザー管理コピーが存在することをRMANに通知して、そのコピーをバックアップの対象にします。CHANGE ... UNCATALOGコマンドを使用することによってコピーを今後利用できなくした場合は、RMANに通知する必要があります。

関連項目:

- 第28章「ユーザー管理データベース・バックアップの作成」

- データファイルおよびアーカイブ・ログのイメージ・コピーをカタログに追加する方法については、「RMANリポジトリへのバックアップ・レコードの追加」を参照してください。

- 「RMANを使用したミラーの分割によるバックアップの実行」

- CHANGEの構文については、『Oracle Databaseバックアップおよびリカバリ・リファレンス』を参照してください。

RMANを使用したバックアップの複数のコピー

RMANでは、次の方法を使用して、バックアップの同じコピーを複数作成できます。

- BACKUP ... COPIESコマンドでバックアップを多重化しますが、この場合、RMANは各バックアップ・セットの複数のコピーを作成します。

- ファイルをバックアップ・セットまたはイメージ・コピーとしてバックアップしてから、RMANのBACKUP BACKUPSETまたはBACKUP COPY OFコマンドで、そのバックアップ・セットまたはイメージ・コピーをバックアップします。

多重バックアップ・セット

データファイル、アーカイブREDOログ・ファイル、サーバー・パラメータ・ファイルおよび制御ファイルをバックアップ・ピースにバックアップする場合、RMANは、多重バックアップ・セットを作成して、1つのBACKUPコマンドで、異なるバックアップ先にバックアップ・セットの各バックアップ・ピースの同じコピーを最大4つ作成できます。イメージ・コピーを作成するバックアップ操作では、多重化はサポートされていません。

BACKUPコマンドの使用時に、CONFIGURE、SETまたは BACKUPコマンドでCOPIESパラメータを使用して、バックアップ・セットの多重化を指定できます。RMANでは、ディスクまたはテープにバックアップを多重化できますが、テープとディスクにバックアップを同時に多重化することはできません。テープへのバックアップ時に、コピーの数が、使用可能なテープ・デバイスの数を超えないようにしてください。

BACKUPコマンドのFORMATパラメータでは、多重バックアップの出力先を指定します。次の例では、データファイル7のバックアップのコピーを3つ作成します。

BACKUP DEVICE TYPE DISK COPIES 3 DATAFILE 7
FORMAT '/disk1/%U','?/oradata/%U','?/%U';

この場合、RMANは、各バックアップ・ピースの最初のコピーを/disk1に、2番目のコピーを?/oradataに、3番目のコピーをOracleホームに格納します。RMANは、それぞれ異なる一意のバックアップ・セット・キーを持つ3つのバックアップ・セットを作成するわけではありません。RMANは、一意のキーを持つ1つのバックアップ・セットを作成して、そのバックアップ・セット内の各バックアップ・ピースの同じコピーを3つ生成します。

関連項目:

- 「バックアップの多重化の構成」

- 「バックアップ・セットの多重化」

- CONFIGUREの構文については、『Oracle Databaseバックアップおよびリカバリ・リファレンス』を参照してください。

- SETの構文については、『Oracle Databaseバックアップおよびリカバリ・リファレンス』を参照してください。

バックアップのバックアップ

BACKUPコマンドを使用すると、既存のバックアップ・セットおよびイメージ・コピーをバックアップできます。

バックアップ・セットのバックアップ

RMANのBACKUP BACKUPSETコマンドを使用すると、ディスク上に作成したバックアップ・セットをバックアップできます。このコマンドは、複数のメディア間でバックアップを実行する場合に有効です。

バックアップ・セットのいずれかのコピーが破損または欠落していることが検出された場合、RMANは、同じバックアップ・セットの他のコピーを検索します。この動作は、複数のアーカイブ先に存在するアーカイブREDOログをRMANがバックアップする際の動作に似ています。

例8-2は、本番バックアップ・スケジュールの一部として、週に1回BACKUPコマンドを実行する方法を示しています。この方法では、すべてのバックアップがディスクとテープの両方に作成されます。

例8-2 テープへのバックアップ・セットのバックアップ

BACKUP DEVICE TYPE DISK AS BACKUPSET
DATABASE PLUS ARCHIVELOG;
BACKUP
DEVICE TYPE sbt
BACKUPSET ALL; # copies backup sets on disk to tape

注意:
自動チャネルを使用したsbtへのバックアップでは、最初にCONFIGURE DEVICE TYPE sbtコマンドを実行する必要があります。

BACKUP BACKUPSETを使用して、バックアップ領域の割当てを管理することもできます。例8-3では、1週間以上前に作成されたバックアップ・セットをディスクからテープにバックアップして、それらをディスクから削除しています。

例8-3 領域割当ての管理

BACKUP
DEVICE TYPE sbt
BACKUPSET COMPLETED BEFORE 'SYSDATE-7'
DELETE INPUT;

ここで使用しているDELETE INPUTは、DELETE ALL INPUTと同等であり、RMANは、バックアップ・セットのすべての既存のコピーを削除します。バックアップを4つの場所に多重化している場合、RMANは、バックアップ・セットのピースのコピーを4つともすべて削除します。

関連項目:
「RMANバックアップのバックアップ」

イメージ・コピーのバックアップ

BACKUP COPY OFコマンドを使用すると、データベース・ファイルの既存のイメージ・コピーをバックアップ・セットまたはイメージ・コピーのいずれかとしてバックアップできます。このコマンドを使用する際は、コマンドで指定するすべてのデータファイルのイメージ・コピーが存在している必要があります。1つのデータファイルに複数のコピーが存在する場合は、最新のコピーが使用されます。表領域またはデータベース全体を指定すると、データベースまたは表領域にデータファイルがあり、対応するイメージ・コピーのバックアップがない場合、RMANはエラーを発行します。

制御ファイルおよびサーバー・パラメータ・ファイルの自動バックアップ

制御ファイルおよびサーバー・パラメータ・ファイルの最新のバックアップを作成しておくと、多くのリカバリ状況で非常に役立ちます。これらのファイルのバックアップを確実に作成するために、データベースには、制御ファイルおよびサーバー・パラメータ・ファイルの自動バックアップ機能が備わっています。自動バックアップは、BACKUPコマンドで明示的に要求された現行の制御ファイルのバックアップとは関係なく行われます。

制御ファイルの自動バックアップによって、RMANは、現行の制御ファイル、リカバリ・カタログおよびサーバー・パラメータ・ファイルにアクセスできない場合でも、データベースをリカバリできます。自動バックアップの格納に使用されるパスは標準的な書式に準拠しているため、RMANは、その自動バックアップからサーバー・パラメータ・ファイルを検索してリストアできます。リストアされたサーバー・パラメータ・ファイルを使用してインスタンスを起動すると、RMANによって自動バックアップから制御ファイルがリストアされます。制御ファイルをマウントした後、マウントされた制御ファイル内のRMANリポジトリを使用して、データファイルをリストアします。

RMANが制御ファイルの自動バックアップを実行する場合

CONFIGURE CONTROLFILE AUTOBACKUPがONに設定されている場合、RMANは、正常なBACKUPコマンドの最後に、制御ファイルおよび現行のサーバー・パラメータ・ファイル(データベースの起動に使用された場合)を自動的にバックアップします。データベースがARCHIVELOGレベルで実行されている場合、データベースの構造上の変更によって制御ファイルの内容が影響を受けると、RMANは、制御ファイルの自動バックアップを作成します。

注意:
Oracle Database 11gリリース2以降では、スクリプトに含まれている複数の構造変更(表領域の追加、表領域またはデータファイルの状態の変更、新しいオンラインREDOログの追加、ファイルの名前変更など)が適用されている場合、RMANは、制御ファイルの自動バックアップを1つのみ実行します。

RMANによる制御ファイルの自動バックアップの実行方法

自動バックアップは、バックアップ・ジョブ中に割り当てられた最初のチャネルによって作成され、独自のバックアップ・セットに格納されます。データベースの構造変更後の自動バックアップの場合は、構造変更に関連付けられたサーバー・プロセスによってバックアップが作成されます。

サーバー・パラメータ・ファイルがデータベースによって使用されている場合は、RMANによって、制御ファイルの自動バックアップと同じバックアップ・セットにバックアップされます。自動バックアップが完了すると、バックアップ・ピースの完全パスおよびデバイス・タイプを含むメッセージが、データベースによって自動診断リポジトリ(ADR)にあるアラート・ログに書き込まれます。

注意:
制御ファイルの自動バックアップは多重化されません。

制御ファイルの自動バックアップのファイル名には、すべてのデバイス・タイプのデフォルトの書式%Fが使用されるため、RMANは、リポジトリを使用しなくても、ファイルの場所を判断してそのファイルをリストアできます。CONFIGURE CONTROLFILE AUTOBACKUP FORMATコマンドを使用すると、別の書式を指定できます。ただし、すべての自動バックアップの書式に%F変数を含める必要があります。デフォルトの書式を使用しない場合は、障害リカバリ中に、自動バックアップの生成に使用された書式を指定する必要があります。そうしない場合、RMANは自動バックアップをリストアできません。

関連項目:

- 「制御ファイルおよびサーバー・パラメータ・ファイルの自動バックアップの構成」

- CONFIGUREの構文については、『Oracle Databaseバックアップおよびリカバリ・リファレンス』を参照してください。

- BACKUPの構文については、『Oracle Databaseバックアップおよびリカバリ・リファレンス』を参照してください。

- 置換変数%Fの詳細は、『Oracle Databaseバックアップおよびリカバリ・リファレンス』を参照してください。

増分バックアップ

デフォルトでは、RMANは全体バックアップを作成します。データファイルの全体バックアップには、バックアップするファイルのすべての割当て済ブロックが含まれます。 データファイルの全体バックアップは、イメージ・コピーである場合があります。この場合は、すべてのデータ・ブロックがバックアップされます。また、バックアップ・セットに格納される場合もあります。この場合は、使用されていないデータファイル・ブロックはスキップされます。

全体バックアップは、RMANバックアップのデフォルト・タイプです。全体バックアップは、後続の増分バックアップには影響せず、増分バックアップ計画の一部とはみなされません。イメージ・コピーにはデータファイル内のすべてのデータ・ブロックが含まれるため、イメージ・コピーは常に全体バックアップとなります。 バックアップ・セットにはデータファイル内のすべてのデータ・ブロックが含まれる可能性があるため、バックアップ・セットはデフォルトでは全体バックアップとなります。ただし、未使用ブロックの圧縮は、未使用のブロックは除外され、現在使用されていないブロックが除外される場合もあることを意味します(「バックアップ・セットのブロック圧縮」を参照)。

全体バックアップに対し、増分バックアップでは、以前のバックアップ以降に変更されたデータ・ブロックのみがコピーされます。RMANを使用して、データファイル、表領域またはデータベース全体の増分バックアップを作成できます。全体バックアップを増分バックアップ計画に含めて、後続の増分バックアップの親として指定することはできません。

マルチレベル増分バックアップ

RMANでは、マルチレベル増分バックアップを作成できます。各増分レベルは、0または1の値で示されます。レベル0の増分バックアップは、後続の増分バックアップの基本となるバックアップであり、データが含まれるすべてのブロックをコピーします。レベル0のデータベース・バックアップは、バックアップ・セットまたはイメージ・コピーとして作成できます。

レベル0の増分バックアップと全体バックアップの違いは、全体バックアップは増分計画には含まれないという点のみです。したがって、レベル0の増分バックアップは、レベルが0より大きい増分バックアップの親である全体バックアップです。

レベル1の増分バックアップは、次のいずれかのタイプです。

- 差分増分バックアップ: レベル1またはレベル0の最新の増分バックアップ以降に変更されたすべてのブロックをバックアップします。

- 累積増分バックアップ: レベル0の最新の増分バックアップ以降に変更されたすべてのブロックをバックアップします。

デフォルトでは、増分バックアップは、差分バックアップに設定されています。

注意:
リカバリ時間がディスク領域より重要である場合は、差分バックアップより累積バックアップをお薦めします。これは、リカバリ中に適用する必要がある増分バックアップが少ないためです。

バックアップ・ファイルのサイズは、変更されたブロック数、増分バックアップ・レベルおよび増分バックアップのタイプ(差分または累積)によって異なります。

差分増分バックアップ

レベル1の差分バックアップでは、RMANは、レベル1(累積または差分)またはレベル0の最新の増分バックアップ以降に変更されたすべてのブロックをバックアップします。たとえば、レベル1の差分バックアップでは、RMANはレベル1の最新のバックアップを確認して、そのバックアップ以降に変更されたすべてのブロックをバックアップします。レベル1のバックアップが使用できない場合、RMANは、レベル0の基本バックアップ以降に変更されたすべてのブロックをコピーします。

現行または親のインカネーションでレベル0のバックアップが使用できない場合の動作は、互換性モード設定によって異なります。互換性が10.0.0以上の場合、RMANは、ファイルの作成以降に変更されたすべてのブロックをコピーします。それ以外の場合、RMANは、レベル0のバックアップを生成します。

図8-2 差分増分バックアップ

図8-2に示す例では、毎週、次のアクティビティが実行されます。

- 日曜日
レベル0の増分バックアップによって、このデータベースでこれまでに使用されたすべてのブロックがバックアップされます。

- 月曜日から土曜日
月曜日から土曜日には、レベル1の差分増分バックアップによって、レベル1またはレベル0の最新の増分バックアップ以降に変更されたすべてのブロックが毎日バックアップされます。つまり、月曜日のバックアップでは、日曜日のレベル0のバックアップ以降に変更されたブロックがコピーされ、火曜日のバックアップでは、月曜日のレベル1のバックアップ以降に変更されたブロックがコピーされる、というように実行されます。

累積増分バックアップ

レベル1の累積バックアップでは、RMANは、現行または親のインカネーションでレベル0の最新の増分バックアップ以降に使用されたすべてのブロックをバックアップします。累積増分バックアップでは、特定のレベルの1つの増分バックアップのみが必要となるため、リストア操作に必要な作業が軽減されます。累積バックアップでは、同じレベルの以前のバックアップによって実行された作業が繰り返されるため、差分バックアップよりも多くの領域および時間が必要です。

図8-3に示す例では、毎週、次のアクティビティが実行されます。

- 日曜日
レベル0の増分バックアップによって、このデータベースでこれまでに使用されたすべてのブロックがバックアップされます。

- 月曜日から土曜日
レベル1の累積増分バックアップによって、レベル0の最新のバックアップ以降に変更されたすべてのブロックがコピーされます。レベル0の最新のバックアップは日曜日に作成されているため、月曜日から土曜日まで毎日行われるレベル1のバックアップでは、日曜日のバックアップ以降に変更されたすべてのブロックがバックアップされます。

関連項目:
「増分バックアップの作成および更新」

図8-3 累積増分バックアップ

ブロック・チェンジ・トラッキング

増分バックアップのブロック・チェンジ・トラッキング機能を使用すると、各データファイル内の変更されたブロックをブロック・チェンジ・トラッキング・ファイルに記録することによって増分バックアップのパフォーマンスが向上します。このファイルは、データベース領域に格納される小さなバイナリ・ファイルです。REDOの生成時に、RMANは、変更されたブロックを追跡します。

ブロック・チェンジ・トラッキングを有効にした場合、RMANは、チェンジ・トラッキング・ファイルを使用して、増分バックアップ用の変更されたブロックを識別します。レベル0の増分バックアックにはすべてのブロックが含まれるため、増分レベルが0(ゼロ)より大きい場合にのみ、RMANはブロック・チェンジ・トラッキングを使用します。

関連項目:
「ブロック・チェンジ・トラッキングを使用した、増分バックアップのパフォーマンスの向上」

増分バックアップのアルゴリズム

RMANで増分バックアップの作成に使用されるアルゴリズムを理解するには、次の概念を理解しておく必要があります。

- チェックポイントSCN
すべてのデータファイルにデータファイル・チェックポイントSCNがあり、このSCNは、V$DATAFILE.CHECKPOINT_CHANGE#で参照できます。このSCNより小さいSCNを持つすべての変更がそのファイル内に存在することが保証されます。レベル0の増分バックアップがリストアされると、リストアされたデータファイルには、レベル0が作成されたときのチェックポイントSCNが含まれます。 レベル1の増分バックアップがファイルに適用されると、そのファイルのチェックポイントSCNは、レベル1の増分バックアップが作成されたときにファイルに含まれていたチェックポイントSCNに進みます。

- 増分開始SCN
このSCNは、レベル1の増分バックアップにのみ適用されます。バックアップには、SCNが増分開始SCN以上のすべてのブロックが含まれます。SCNが増分開始SCNより小さいブロックは、バックアップには含まれません。増分開始SCNは、多くの場合、レベル1のバックアップの親のチェックポイントSCNです。

- ブロックSCN
データファイルの各データ・ブロックには、ブロックに対する最新の変更が行われた時点のSCNが記録されます。

RMANは、ファイルのレベル1の増分バックアップの作成時に、ファイルを読み取り、すべてのブロックのSCNを確認し、SCNがこのバックアップの増分開始SCN以上であるブロックをバックアップします。差分バックアップの場合、増分開始SCNは最新のレベル1のバックアップのチェックポイントSCNです。累積バックアップの場合、増分開始SCNは最新のレベル0のバックアップのチェックポイントSCNです。

ブロック・チェンジ・トラッキングが有効になっている場合、RMANは、ビットマップを使用して、増分開始SCNからチェックポイントSCNまでの範囲内で変更されていないブロックの読取りを回避します。RMANは、読み取るすべてのブロックを確認し、ブロック内のSCNを使用してバックアップに含めるブロックを決定します。

増分バックアップ・アルゴリズムによって、RMANは、リカバリ中、変更されたデータが含まれるすべてのブロックを適用できます。これには、NOLOGGINGオプションで作成されたオブジェクトに対する変更も含まれます。したがって、NOLOGGINGの変更を行う前に作成されたバックアップをリストアする場合、これらの変更をリカバリする方法は、増分バックアップのみとなります。

関連項目:
NOLOGGINGモードの詳細は、『Oracle Database概要』を参照してください。

増分バックアップを使用したリカバリ

メディア・リカバリ中、RMANは、リストアされるファイルを確認し、増分バックアップを使用してそれらをリカバリできるかどうかを判断します。増分バックアップとアーカイブREDOログのいずれかを選択できる場合、RMANは常に増分バックアップを選択します。ブロック・レベルで変更を適用する方が、REDOを適用するより高速なためです。

RMANでは、リカバリ中、増分バックアップをデータファイルに適用するためにデータファイルの基本増分バックアップをリストアする必要はありません。たとえば、データファイルのイメージ・コピーをリストアし、増分バックアップを使用してそれらをリカバリできます。

関連項目:
「増分バックアップおよびアーカイブREDOログの選択」

バックアップの保存方針

CONFIGURE RETENTION POLICYコマンドを使用して、永続的かつ自動のバックアップの保存方針を作成できます。バックアップの保存方針が有効な場合、RMANは、CONFIGUREコマンドで指定された条件に従って、データファイルまたは制御ファイルのバックアップを不要なバックアップ(つまり、今後リカバリに不要)とみなします。REPORT OBSOLETEコマンドを使用して不要なファイルを表示したり、DELETE OBSOLETEコマンドを使用して不要なファイルを削除できます。

長期にわたってバックアップを作成していると、古いバックアップは保存方針を満たすために必要ではなくなります。RMANは、不要になったファイルを識別できますが、自動的には削除しません。DELETE OBSOLETEコマンドを使用して、保存方針を満たすために必要ではなくなったファイルを削除する必要があります。

高速リカバリ領域が構成されている場合、新しいファイル用にリカバリ領域がさらに必要になると、不要になったファイルまたはテープにバックアップされたファイルがデータベースによって自動的に削除されます。ディスク割当て制限の規則は、保存方針の規則とは異なりますが、ディスク割当て制限を満たすために、保存方針に違反してファイルが削除されることはありません。「高速リカバリ領域が一杯になった場合の対応」を参照してください。

バックアップが不要になるのは、REPORT OBSOLETEまたはDELETE OBSOLETEで、ユーザー定義の保存方針に基づいて、バックアップがリカバリに必要ないと判断された場合です。バックアップが期限切れのバックアップとみなされるのは、RMANがクロスチェックを実行してファイルを検出できない場合のみです。したがって、不要とはファイルが必要ないことを意味し、期限切れとはファイルが検出されないことを意味します。

バックアップ保存方針は、全体またはレベル0のデータファイルおよび制御ファイルのバックアップにのみ適用されます。データファイルのコピーおよびプロキシ・コピーの場合、RMANがコピーまたはプロキシ・コピーを不要と判断すると、それらのコピーを削除できます。データファイルのバックアップ・セットの場合、バックアップ・セット内のすべてのデータファイルのバックアップが不要になると、RMANはそのバックアップ・セットを削除できます。

保存方針は、不要なアーカイブREDOログおよびレベル1の増分バックアップの削除またはレンダリングには関係しません。これらのファイルは、それらを必要とする全体バックアップが存在しなくなった場合に不要となります。保存方針は、データファイルおよび制御ファイルの全体バックアップまたはレベル0のバックアップのみでなく、アーカイブREDOログおよびレベル1の増分バックアップにも影響します。まず、RMANは不要なデータファイルおよび制御ファイルのバックアップを判断します。次に、RMANは、保持する必要がある最も古いデータファイルまたは制御ファイルのバックアップをリカバリする際に必要ないすべてのアーカイブ・ログおよびレベル1の増分バックアップを、不要とみなします。

注意:
RMANを使用せずに(メディア・マネージャのテープの保存方針などによって)バックアップを削除すると、RMANは自動保存方針を実装できません。テープ上のすべてのRMANバックアップがメディア・マネージャのカタログから削除されるまで、メディア・マネージャがそのテープを期限切れにしないように設定することをお薦めします。

保存方針を実装する場合、冗長性とリカバリ期間という相互に排他的な2つのオプションがあります。

リカバリ期間

リカバリ期間とは、現在の時点からリカバリ可能ポイントまでの期間です。リカバリ可能ポイントは、想定されるPoint-in-Timeリカバリの最も早い時点(メディア障害後にリカバリ可能な最も早い時点)です。たとえば、1週間のリカバリ期間を実装した場合、RMANは、データベースを最大7日前までリカバリできるように、全体バックアップおよび必要な増分バックアップとアーカイブ・ログを保持します。この保存方針は、次のように構成します。

CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF 7 DAYS;

このコマンドを実行すると、各データファイルに対して、リカバリ可能ポイントより前のバックアップが1つ保持されます。たとえば、リカバリ期間が7の場合、次の条件を満たす各データファイルのバックアップが常に1つ存在する必要があります。

SYSDATE - BACKUP CHECKPOINT TIME >= 7

この条件を満たす最新のバックアップよりも古いすべてのバックアップは不要となります。

図8-4に示す保存方針を設定するとします。保存方針の内容は、次のとおりです。

- リカバリ期間は7日です。

- データベースのバックアップは2週間ごとにスケジュールされ、次の日付に実行されます。

- 1月1日

- 1月15日

- 1月29日

- 2月12日

- データベースはARCHIVELOGモードで実行され、アーカイブ・ログは、保存方針で必要とされる間のみ、ディスク上に保存されます。

図8-4 リカバリ期間1

図8-4に示すように、現在の時点は1月23日、リカバリ可能ポイントは1月16日です。このため、リカバリには、1月14日のバックアップおよびログ順序500から850のアーカイブ・ログが必要です。500より前のログおよび1月1日のバックアップは、期間内の時点へのリカバリには必要ありません。

図8-5に、1週間後の同じ例を示します。

図8-5 リカバリ期間2

この例では、現在の時点は1月30日、リカバリ可能ポイントは1月23日です。最新(1月28日)のバックアップがリカバリ期間に存在していますが、この場合でも1月14日のバックアップは不要ではありません。これは、1月28日のバックアップをリストアしても、期間の最初の時点(1月23日)にはリカバリできないためです。期間内のいずれの時点にもリカバリできるようにするために、1月14日のバックアップおよび順序500から1150のすべてのアーカイブ・ログを保存する必要があります。

関連項目:
「リカバリ期間に基づく保存方針の構成」

バックアップ冗長性

リカバリ期間を使用すると、保持する必要があるバックアップの数が一定ではなく、バックアップ・スケジュールによって異なるため、ディスク領域の計画が複雑になる場合があります。これに対して、冗長性に基づく保存方針では、データファイルごとに保持する必要があるバックアップ数を指定します。たとえば、次のように入力して冗長性を2に構成できます。

CONFIGURE RETENTION POLICY TO REDUNDANCY 2;

デフォルトの保存方針は、REDUNDANCY 1に構成されています。

関連項目:
「冗長性に基づく保存方針の構成」

不要なバックアップのバッチ削除

REPORT OBSOLETEコマンドを実行すると、保存方針に従って、現在不要なバックアップを確認できます。関連コマンドDELETE OBSOLETEを実行すると、保存方針に従って、不要なすべてのファイルを削除できます。DELETE OBSOLETEを定期的に実行して、不要なバックアップの格納によって消費される領域を最小限に抑えることができます。たとえば、週に1回実行するスクリプトでDELETE OBSOLETEを実行できます。

また、REPORTまたはDELETEコマンドでREDUNDANCYまたはRECOVERY WINDOWオプションを指定して、構成されている保存方針を無効にすることもできます。構成したリカバリ期間より短いリカバリ期間でDELETE OBSOLETEを使用すると、リカバリ可能な期間が事実上短縮されます。たとえば、構成した期間が14日にもかかわらず、DELETE OBSOLETE RECOVERY WINDOW OF 7 DAYSを実行した場合は、7日から14日前の間の時間にはリカバリできなくなります。

関連項目:

- レポートの生成方法およびバックアップの削除方法については、第11章「RMAN操作に関するレポート」を参照してください。

- DELETEの構文については、『Oracle Databaseバックアップおよびリカバリ・リファレンス』を参照してください。

- REPORTの構文については、『Oracle Databaseバックアップおよびリカバリ・リファレンス』を参照してください。

バックアップ保存方針および高速リカバリ領域の削除規則

RMANのステータスOBSOLETEは、常に保存方針に応じて決定されます。たとえば、RMANリポジトリ内のデータベースのバックアップがOBSOLETEとみなされる理由は、そのバックアップがリカバリ期間内の時点へのリカバリに必要ないか、または冗長であるためです。

高速リカバリ領域を構成している場合、内部アルゴリズムを使用して、高速リカバリ領域のファイルから、構成されている保存方針を満たす必要がなくなったファイルが選択されます。ステータスがOBSOLETEのバックアップは、ディスク割当て制限の規則によって削除対象となっています。ディスク割当て制限の規則に従って高速リカバリ領域から削除するファイルが決定される際に、保存方針が違反されることはありません。

高速リカバリ領域のOBSOLETEステータスの規則と、ディスク割当て制限で削除対象とする規則には、1つの重要な違いがあります。1000から2000のアーカイブ・ログがディスク上に存在し、現行のリカバリ期間に必要であるとします。これらのログをテープにバックアップする場合、保存方針では、ディスク上のログは必要であるとみなされます。一方、高速リカバリ領域のディスク割当て制限のアルゴリズムでは、ディスク上のログはテープにバックアップされているため、削除対象とみなされます。したがって、ディスク上のログはリポジトリではOBSOLETEステータスを持ちませんが、高速リカバリ領域では削除対象になります。

9 データベースのバックアップ

この章では、最も基本的なバックアップ作業の実行方法およびRMANを使用したバックアップ計画の実装方法について説明します。この章の内容は次のとおりです。

- RMANバックアップの概要

- バックアップ出力オプションの指定

- RMANを使用したデータベース・ファイルのバックアップ

- RMANを使用したアーカイブREDOログのバックアップ

- 増分バックアップの作成および更新

- 長期格納用のデータベース・バックアップの作成

- RMANバックアップのバックアップ

関連項目:

- バックアップの最適化、多重化、バックアップの暗号化、再開可能なバックアップなどの高度なトピックについては、第10章「データベースのバックアップ: 高度なトピック」を参照してください。

- Data Guard環境でのRMANバックアップおよびリカバリの実行方法については、『Oracle Data Guard概要および管理』を参照してください。

RMANバックアップの概要

この項では、RMANバックアップの概要について説明します。

RMANバックアップの目的

RMANバックアップの主要な目的は、データを保護することです。メディア障害が発生した場合は、バックアップをリストアして、消失した変更をリカバリできます。

また、バックアップを作成すると、「長期格納用のデータベース・バックアップの作成」の説明に従って長期アーカイブ用のデータを保存したり、第III部「RMANを使用したデータの送信」の章の説明に従ってデータを送信することができます。

RMANバックアップの基本的な概念

第8章「RMANバックアップの概要」で説明されているように、RMANクライアント内からBACKUPコマンドを実行して、データベース全体またはその一部をバックアップできます。この章で説明されている方法の多くは、Enterprise Managerによって提供されるOracle推奨のバックアップ計画でも使用され、『Oracle Database 2日でデータベース管理者』にも記載されています。

多くの場合、バックアップ計画に従ってデータベースを構成しておくと、RMANプロンプトで次のコマンドを入力してデータベースをバックアップできます。

RMAN> BACKUP DATABASE;

RMANは、構成された設定、以前のバックアップのレコードおよびデータベース構造の制御ファイル・レコードを使用して、効率的な一連のバックアップ手順を決定します。その後、それらの手順を実行します。

「Data Guard環境でのRMANによるファイル管理」で説明されているように、Data Guard環境の任意のデータベースでRMANバックアップを実行できます。バックアップにアクセスできる場合、環境内の任意のデータベースのすべてのバックアップを他のデータベースのリカバリに使用できます。データベース・ファイルのすべてのバックアップ(制御ファイルのバックアップを含む)をフィジカル・スタンバイ・データベースにオフロードすると、プライマリ・データベース上のリソースの消費を回避できます。

関連項目:

- BACKUPコマンドの詳細は、『Oracle Databaseバックアップおよびリカバリ・リファレンス』を参照してください。

- RMANでスタンバイ・データベースをバックアップする方法については、『Oracle Data Guard概要および管理』を参照してください。

バックアップ出力オプションの指定

BACKUP DATABASEなどのRMANのコマンドに最低限必要なオプションしか指定しないと、構成済の環境およびRMANの組込みのデフォルトに基づいて、バックアップ先のデバイス、バックアップ出力の場所およびバックアップ・タグが自動的に決定されます。

また、BACKUPに引数を指定して、これらのデフォルトを上書きすることもできます。次の項では、最も一般的なオプションについて説明します。

- RMANバックアップ用のデバイス・タイプの指定

- ディスクへのRMANバックアップ用のバックアップ・セットまたはバックアップ・コピーの指定

- RMANバックアップのフォーマットの指定

- RMANバックアップのタグの指定

- 圧縮バックアップの作成

関連項目:
バックアップの多重化や再開などの高度なバックアップ・オプションについては、第10章「データベースのバックアップ: 高度なトピック」を参照してください。

RMANバックアップ用のデバイス・タイプの指定

BACKUPコマンドでは、ディスクまたはテープ・デバイスのいずれにバックアップするかを指定するDEVICE TYPE句を使用します。例9-1は、ディスクにバックアップする場合の例です。

例9-1 デバイス・タイプDISKの指定

BACKUP DATABASE
DEVICE TYPE DISK;

DEVICE TYPE句を指定せずにBACKUPを実行すると、バックアップは構成済のデフォルト・デバイス(ディスクまたはSBT)に格納されます。デフォルト・デバイスは、「バックアップ用のデフォルト・デバイスの構成: ディスクまたはSBT」で説明されているCONFIGURE DEFAULT DEVICE TYPEコマンドを使用して設定します。

ディスクへのRMANバックアップ用のバックアップ・セットまたはバックアップ・コピーの指定

RMANは、イメージ・コピーまたはバックアップ・セットとしてバックアップをディスク上に作成できます。デフォルトのディスク・デバイスの構成方法については、「バックアップ用のデフォルト・タイプの構成: バックアップ・セットまたはコピー」を参照してください。このデフォルトは、AS COPY句またはAS BACKUPSET句を使用して上書きできます。イメージ・コピーとしてディスクにバックアップするには、例9-2に示すようにBACKUP AS COPYを使用します。

例9-2 イメージ・コピーの作成

BACKUP AS COPY
DEVICE TYPE DISK
DATABASE;

バックアップ・セットにデータをバックアップするには、AS BACKUPSET句を使用します。例9-3に示すように、バックアップ・セットは、構成されているデフォルト・デバイスに作成したり、ディスクまたはテープに明示的に格納できます。

例9-3 バックアップ・セットの作成

BACKUP AS BACKUPSET
DATABASE;

BACKUP AS BACKUPSET
DEVICE TYPE DISK
DATABASE;

BACKUP AS BACKUPSET
DEVICE TYPE SBT
DATABASE;

RMANバックアップのフォーマットの指定

RMANには、BACKUPコマンドで生成されるファイルに名前を指定するための様々なオプションが用意されています。RMANは、優先順位に従って示されている次のルール・セットを使用して、出力ファイル形式を決定します。

1. BACKUPコマンドでFORMATパラメータを指定すると、この設定により、生成されるファイル名が制御されます。
たとえば、次のコマンドに示すように、出力を特定の場所に格納することができます。

BACKUP DATABASE
FORMAT "/disk1/backup_%U";  # specifies a location on the file system

この場合、バックアップは、生成された一意のファイル名(/disk1/backup_という接頭辞付き)で格納されます。ファイル名のその部分に一意の文字列を生成するために使用される、置換変数%Uが必要です。

また、次の例に示すように、FORMATパラメータを使用して、バックアップ先としてASMディスク・グループを指定することもできます。

BACKUP DATABASE
FORMAT '+dgroup1';  # specifies an ASM disk group

この場合、必要に応じて自動ストレージ管理(ASM)で一意のファイル名が生成されるため、%Uは不要です。ただし、必要な場合は、%Uを指定できます。

注意:
高速リカバリ領域が有効になっている場合にFORMATを指定すると、RMANはFORMATの設定に従います。FORMAT句で場所を指定しなかった場合、RMANはプラットフォーム固有の場所にバックアップを作成します。

2. FORMAT設定がバックアップで使用される特定のチャネル用に構成されている場合、生成されるファイル名の制御はこの設定によって行われます。

3. FORMAT設定がバックアップで使用されるデバイス・タイプ用に構成されている場合、生成されるファイル名の制御はこの設定によって行われます。

4. ディスク・バックアップ中に高速リカバリ領域が有効になっていて、FORMATが指定されていない場合は、自動生成された名前で高速リカバリ領域にバックアップが作成されます。

5. このリストの他のいずれの条件も当てはまらない場合は、バックアップのデフォルトの場所およびファイル名の書式はプラットフォーム固有になります。

関連項目:
FORMAT句については、『Oracle Databaseバックアップおよびリカバリ・リファレンス』を参照してください。ご使用のプラットフォームのデフォルトのファイルの場所については、インストレーション・ガイドを参照してください。

ディスク・バックアップの複数のフォーマットの指定

通常、テープにバックアップする場合には、デフォルトの %U変数によってテープ・バックアップに一意のファイル名が生成されるため、フォーマットを指定する必要はありません。ただし、ディスクへのバックアップで、パフォーマンスを向上するために複数のドライブにバックアップを分散させる必要がある場合には、フォーマットを指定できます。この場合、ファイル名が異なるディスク上で生成されるように、ALLOCATE CHANNELコマンドでディスク・ドライブごとに1つのDISKチャネルを割り当てて、フォーマット文字列を指定します。たとえば、次のコマンドを発行します。

RUN
{
ALLOCATE CHANNEL disk1 DEVICE TYPE DISK FORMAT '/disk1/%d_backups/%U';
ALLOCATE CHANNEL disk2 DEVICE TYPE DISK FORMAT '/disk2/%d_backups/%U';
ALLOCATE CHANNEL disk3 DEVICE TYPE DISK FORMAT '/disk3/%d_backups/%U';
BACKUP AS COPY DATABASE;
}

チャネルを次のように構成すると、将来、デフォルトでこのようにバックアップを分散できるようになります。

CONFIGURE DEVICE TYPE DISK PARALLELISM 3;
CONFIGURE DEFAULT DEVICE TYPE TO DISK;
CONFIGURE CHANNEL 1 DEVICE TYPE DISK FORMAT '/disk1/%d_backups/%U';
CONFIGURE CHANNEL 2 DEVICE TYPE DISK FORMAT '/disk2/%d_backups/%U';
CONFIGURE CHANNEL 3 DEVICE TYPE DISK FORMAT '/disk3/%d_backups/%U';
BACKUP AS COPY DATABASE;

RMANバックアップのタグの指定

RMANは、バックアップを識別する方法として、作成するすべてのバックアップにtagと呼ばれる文字列を追加します。デフォルトのタグを受け入れるか、またはBACKUPコマンドのTAGパラメータで独自のタグを指定できます。

バックアップ・タグ

ユーザー指定のタグは、異なる種類のバックアップまたはコピーの目的や使用方法を示すのに役立ちます。バックアップ・セット、プロキシ・コピー、データファイル・コピーまたは制御ファイル・コピーにタグを付けることができます。たとえば、SWITCHコマンドで使用する予定のデータファイル・コピーにはfor_switch_onlyというタグを付け、RESTOREコマンドでのみ使用する必要があるファイル・コピーにはfor_restore_onlyというタグを付けることができます。

タグは一意である必要はないため、複数のバックアップ・セットまたはイメージ・コピーに同じタグ(weekly_backupなど)を付けることができます。特定のタグが含まれているバックアップからデータファイルをリストアするように指定するとします。要求したファイルの複数のバックアップにそのタグが含まれている場合、RMANは、RESTOREコマンドの制約内で、指定したタグが含まれている最新のバックアップをリストアします。

実際には、タグは、多くの場合、増分バックアップ計画などの1つの計画の一環として作成された一連のバックアップを区別する場合に使用されます。たとえば、週次の増分バックアップを作成し、BACKUP TAG weekly_incrementalなどのタグを付けることができます。BACKUPコマンドの多くの形式では、タグをバックアップに関連付けることができます。また、RESTOREおよびRECOVERコマンドの多くでは、RESTOREまたはRECOVER操作で使用するバックアップを制限するタグを指定できます。

BACKUPコマンドのTAGパラメータを使用して明示的にタグを指定しない場合は、RMANによって、バックアップ(制御ファイルの自動バックアップ以外)のデフォルト・タグが暗黙的に作成されます。タグの形式は、TAGYYYYMMDDTHHMMSSです。ここで、YYYYは年、MMは月、DDは日、HHは時間(24時間形式)、MMは分、SSは秒です。たとえば、データファイル1のバックアップには、タグTAG20070208T133437が割り当てられる場合があります。日時は、バックアップを実行するインスタンスのタイムゾーンで、RMANがバックアップを開始した日時です。1つのBACKUPコマンドによって複数のバックアップ・セットが作成される場合、各バックアップ・ピースには同じデフォルト・タグが割り当てられます。

入力時に使用した大/小文字に関係なく、タグは大文字で格納されます。バックアップ・タグの最大長は30バイトです。オペレーティング・システムの環境変数または%T、%Dなどの特殊な書式は、タグに使用できません。

関連項目:
BACKUP ... TAGのデフォルト形式については、『Oracle Databaseバックアップおよびリカバリ・リファレンス』を参照してください。

バックアップ・セットおよびイメージ・コピーのタグの指定

タグで使用する文字は、ターゲットのデータベース・ファイル・システムでファイル名として有効な文字に制限する必要があります。 たとえば、自動ストレージ管理(ASM)では、内部的に使用されるファイル名でのハイフン(-)の使用はサポートされていません。このため、ASMディスク・グループでのバックアップの場合、ハイフンが含まれているタグ(weekly-incrなど)は無効なタグ名になります。

バックアップ・セットにタグを指定すると、そのタグは、指定したバックアップ・セットのコピーに含まれる各バックアップ・ピースの属性になります。多重バックアップ・セットを作成すると、バックアップ・セットの各コピーに同じタグが割り当てられます。例9-4では、タグMONDAYBKPが指定されたバックアップ・セットを1つ作成します。

例9-4 バックアップ・セットへのタグの適用

BACKUP AS BACKUPSET
COPIES 1
DATAFILE 7
TAG mondaybkp;

イメージ・コピーにタグを指定すると、そのタグは各コピーに適用されます。例9-5では、表領域usersおよびtoolsのデータファイルのコピーに、タグMONDAYCPYを割り当てます。

例9-5 イメージ・コピーへのタグの適用

BACKUP AS COPY
TABLESPACE users, tools
TAG mondaycpy;

FROM TAGを使用して特定のタグが含まれているイメージ・コピーをコピーした後、TAGを使用して出力コピーに別のタグを割り当てることができます。例9-6では、タグfull_cold_copyが含まれている、データベースのすべてのイメージ・コピーのコピーを新しく作成し、その新しいコピーにnew_full_cold_copyを割り当てます。

例9-6 出力コピーへのタグの割当て

BACKUP AS COPY
COPY OF DATABASE
FROM TAG full_cold_copy
TAG new_full_cold_copy;

圧縮バックアップの作成

バックアップ・セットを作成するBACKUPコマンドを実行する場合は、RMANでサポートされている、バックアップ・セットのバイナリ圧縮を利用できます。BACKUPコマンドにAS COMPRESSED BACKUPSETオプションを指定します。

RMANは、バックアップ・セットの内容を圧縮してからディスクに書き込みます。使用されるバイナリ圧縮レベルの詳細が自動的にバックアップ・セットに記録されます。使用される圧縮のタイプやリカバリ操作でのバックアップ・セットの解凍方法を明示的に示す必要はありません。

例9-7では、データベース全体とアーカイブ・ログを、構成済のデフォルトのバックアップ先(ディスクまたはテープ)にバックアップし、圧縮バックアップ・セットを作成します。

例9-7 圧縮バックアップの作成

BACKUP
AS COMPRESSED BACKUPSET
DATABASE PLUS ARCHIVELOG;

バイナリ圧縮では、バックアップおよびリカバリ操作中に、パフォーマンスにある程度のオーバーヘッドが発生します。バイナリ圧縮はCPUリソースを消費するため、CPU使用率が高い場合は、圧縮バックアップはスケジュールしないでください。ただし、次の状況では、パフォーマンスが低下する可能性があります。

- 高速リカバリ領域またはその他のディスクベースのバックアップ先内のディスク領域が制限されている状況で、ディスクベースのバックアップを使用している場合

- CPU使用率よりネットワーク帯域幅を削減することのほうが重要となる状況で、ネットワークを介して特定のデバイスへのバックアップを実行している場合

- CD、DVDなどのアーカイブ・バックアップ・メディアを使用しており、バックアップ・サイズを削減することでメディア・コストおよびアーカイブ・ストレージを節約できる場合

関連項目:
バックアップ・セットに関するパフォーマンスの詳細は、「バックアップ・セットのバイナリ圧縮」および『Oracle Databaseバックアップおよびリカバリ・リファレンス』のBACKUPコマンドのAS COMPRESSED BACKUPSETオプションを参照してください。

RMANを使用したデータベース・ファイルのバックアップ

この項の内容は、次のとおりです。

- RMANを使用したデータベース全体のバックアップ

- RMANを使用した表領域およびデータファイルのバックアップ

- RMANを使用した制御ファイルのバックアップ

- RMANを使用したサーバー・パラメータ・ファイルのバックアップ

- NOARCHIVELOGモードでのデータベースのバックアップ

RMANを使用したデータベース全体のバックアップ

データベース全体のバックアップは、データベースをマウントまたはオープンした状態で実行できます。データベース全体のバックアップを実行するには、RMANプロンプトからBACKUP DATABASEコマンドを使用します。

必要に応じて、データベース全体のバックアップから指定した表領域を除外できます。「データベース全体のバックアップから除外する表領域の構成」で説明されているように、常にスキップする各表領域に対してCONFIGURE EXCLUDEコマンドを実行して、複数のRMANセッションで表領域を永続的にスキップできます。構成済の設定は、BACKUP ... NOEXCLUDEで上書きできます。

データベースをバックアップする手順

1. RMANを起動し、ターゲット・データベースおよびリカバリ・カタログ(使用している場合)に接続します。

2. データベースがマウントまたはオープンされていることを確認します。

3. RMANプロンプトでBACKUP DATABASEコマンドを発行します。
このコマンドの最も簡単な形式にはオプションまたはパラメータは必要ありません。

BACKUP DATABASE;

バックアップされるファイルのリスト(データファイル、制御ファイル、サーバー・パラメータ・ファイル)は、『Oracle Databaseバックアップおよびリカバリ・リファレンス』で、BACKUPコマンドのキーワードDATABASEを参照してください。

次の例では、データベースをバックアップし、オンラインREDOログを切り替え、アーカイブ・ログをバックアップに格納します。

BACKUP DATABASE PLUS ARCHIVELOG;

バックアップの直後にログをアーカイブすることによって、バックアップ時間全体のアーカイブ・ログの完全なセットを取得します。これによって、このバックアップのリストア後にメディア・リカバリを実行できることが保証されます。

関連項目:

- BACKUPコマンドについては、『Oracle Databaseバックアップおよびリカバリ・リファレンス』を参照してください。CONNECTコマンドについては、『Oracle Databaseバックアップおよびリカバリ・リファレンス』を参照してください。

- BACKUP ... SKIPを使用して、アクセスできないデータファイル、オフライン表領域内のデータファイルまたは読取り専用表領域内のデータファイルをスキップする方法については、「オフライン・ファイル、読取り専用ファイルおよびアクセスできないファイルのスキップ」を参照してください。

RMANを使用した表領域およびデータファイルのバックアップ

BACKUP TABLESPACEコマンドでは1つ以上の表領域、 BACKUP DATAFILEコマンドでは1つ以上のデータファイルをバックアップできます。表領域を指定すると、RMANは表領域の名前を一連のデータファイルに内部的に変換します。データベースは、マウントされている状態でもオープンされている状態でもかまいません。表領域は、読取り/書込みでも読取り専用でもかまいません。

注意:
以前のリリースと同様に、トランスポータブル表領域は、バックアップに対して読取り/書込みモードである必要はありません。

バックアップにデータファイル1が含まれている場合、RMANは、制御ファイルおよびサーバー・パラメータ・ファイル(インスタンスがサーバー・パラメータ・ファイルで起動されている場合)を自動的にバックアップします。制御ファイルの自動バックアップが有効になっている場合、RMANは、現行の制御ファイルおよびサーバー・パラメータ・ファイルを別の自動バックアップ・ピースに書き込みます。そうでない場合、RMANは、データファイル1が含まれているバックアップ・セットにこれらのファイルを書き込みます。

表領域またはデータファイルをバックアップする手順

1. RMANを起動し、ターゲット・データベースおよびリカバリ・カタログ(使用している場合)に接続します。

2. データベース・インスタンスが起動されていない場合は、データベースをマウントまたはオープンします。

3. RMANプロンプトで、BACKUP TABLESPACEコマンドまたはBACKUP DATAFILEコマンドを実行します。
次の例では、usersおよびtools表領域をテープにバックアップします。

BACKUP
DEVICE TYPE sbt
TABLESPACE users, tools;

次の例では、SBTチャネルを使用して、データファイル1から4および/tmp/system01.dbfに格納されているデータファイルのコピーをテープにバックアップします。

BACKUP
DEVICE TYPE sbt
DATAFILE 1,2,3,4
DATAFILECOPY '/tmp/system01.dbf';

RMANを使用した制御ファイルのバックアップ

制御ファイルは、データベースがマウントまたはオープンされた状態でバックアップできます。RMANは、スナップショット制御ファイルを使用して、読取り一貫性のバージョンを保証します。CONFIGURE CONTROLFILE AUTOBACKUPコマンドをON(デフォルトではOFF)に設定すると、各バックアップの実行後、およびデータベースの構造変更後に、RMANで制御ファイルとサーバー・パラメータ・ファイルが自動的にバックアップされます。制御ファイルの自動バックアップには、障害リカバリに不可欠な以前のバックアップに関するメタデータが含まれます。

注意:
1つのData Guardデータベースで作成された制御ファイルのバックアップを、環境内の他のすべてのデータベースにリストアすることができます。プライマリ制御ファイルのバックアップとスタンバイ制御ファイルのバックアップには互換性があります。RMANを使用してスタンバイ・データベースにリストアする方法については、『Oracle Data Guard概要および管理』を参照してください。

自動バックアップ機能が設定されていない場合は、次のいずれかの方法を使用して、手動で制御ファイルをバックアップする必要があります。

- BACKUP CURRENT CONTROLFILEを実行します。

- BACKUPコマンドのINCLUDE CURRENT CONTROLFILEオプションを使用して、制御ファイルのバックアップをいずれかのバックアップに含めます。

- データファイル1をバックアップします(制御ファイルおよびサーバー・パラメータ・ファイルは、RMANによって自動的にデータファイル1のバックアップに格納されるため)。

注意:
制御ファイルのブロック・サイズがデータファイル1のブロック・サイズと等しくない場合、制御ファイルをデータファイルと同じバックアップ・セットに書き込むことはできません。ブロック・サイズが異なる場合、RMANは、制御ファイルを単独で別のバックアップ・セットに書き込みます。V$CONTROLFILE.BLOCK_SIZEは制御ファイルのブロック・サイズを示し、DB_BLOCK_SIZE初期化パラメータはデータファイル1のブロック・サイズを示します。

制御ファイルの手動バックアップの作成

制御ファイルの手動バックアップは、制御ファイルの自動バックアップとは異なります。RMANは、BACKUPコマンドで指定されたファイルをバックアップした後、制御ファイルの自動バックアップを作成します。このため、制御ファイルの手動バックアップとは異なり、自動バックアップには、完了直後のバックアップに関するメタデータが含まれます。また、RMANは、リカバリ・カタログを使用しないで自動バックアップを自動的にリストアすることもできます。

手動バックアップを作成するには、他のファイルをバックアップする際にINCLUDE CURRENT CONTROLFILEを指定するか、またはBACKUP CURRENT CONTROLFILEを指定します。また、CONTROLFILECOPYパラメータを指定して、制御ファイルのコピーをディスクにバックアップすることもできます。

制御ファイルを手動でバックアップする手順

1. RMANを起動し、ターゲット・データベースおよびリカバリ・カタログ(使用している場合)に接続します。

2. ターゲット・データベースがマウントまたはオープンされていることを確認します。

3. 必要な制御ファイル句を指定してBACKUPコマンドを実行します。
次の例では、表領域usersをテープにバックアップし、そのバックアップに現行の制御ファイルを含めます。

BACKUP DEVICE TYPE sbt
TABLESPACE users
INCLUDE CURRENT CONTROLFILE;

次の例では、現行の制御ファイルをデフォルトのディスク・デバイスにバックアップします。

BACKUP AS COPY
CURRENT CONTROLFILE
FORMAT '/tmp/control01.ctl';

次の例では、前述の例で作成した制御ファイルのコピーをテープにバックアップします。

BACKUP AS COPY
CURRENT CONTROLFILE
FORMAT '/tmp/control01.ctl';
BACKUP DEVICE TYPE sbt
CONTROLFILECOPY '/tmp/control01.ctl';

制御ファイルの自動バックアップ機能が有効になっている場合、RMANは、これらの例で制御ファイルのバックアップを2つ作成します。1つはBACKUPコマンドで指定したファイルの明示的なバックアップで、もう1つは制御ファイルおよびサーバー・パラメータ・ファイルの自動バックアップです。

関連項目:
CONFIGURE CONTROLFILE AUTOBACKUPコマンドの詳細は、『Oracle Databaseバックアップおよびリカバリ・リファレンス』を参照してください。

RMANを使用したサーバー・パラメータ・ファイルのバックアップ

「RMANを使用した制御ファイルのバックアップ」で説明したとおり、RMANは、特定の状況下で、現行のサーバー・パラメータ・ファイルを自動的にバックアップします。BACKUP SPFILEコマンドは、パラメータ・ファイルを明示的にバックアップします。バックアップされるサーバー・パラメータ・ファイルは、インスタンスで現在使用されているサーバー・パラメータ・ファイルです。

サーバー・パラメータ・ファイルをバックアップする方法

1. RMANを起動し、ターゲット・データベースおよびリカバリ・カタログ(使用している場合)に接続します。

2. ターゲット・データベースがマウントまたはオープンされていることを確認します。
サーバー・パラメータ・ファイルを使用して、データベースを起動している必要があります。インスタンスがクライアント側の初期化パラメータ・ファイルを使用して起動されている場合にBACKUP ... SPFILEを実行すると、RMANによってエラーが発行されます。

3. BACKUP ... SPFILEコマンドを実行します。
次の例では、サーバー・パラメータ・ファイルがテープにバックアップされます。

BACKUP DEVICE TYPE sbt SPFILE;

NOARCHIVELOGモードでのデータベースのバックアップ

データベースが一貫した状態でクローズされている場合は、NOARCHIVELOGモードでのみデータベースをバックアップできます。例9-8に示すスクリプトを実行すると、データベースがデータベース全体の一貫性バックアップを行うための正しいモードになり、バックアップされます。このスクリプトでは、制御ファイルの自動バックアップがデータベースに対して有効になっていると想定されています。

例9-8 NOARCHIVELOGモードでのデータベースのバックアップ

SHUTDOWN IMMEDIATE;
# Start up the database in case it suffered instance failure or was
# closed with SHUTDOWN ABORT before starting this script.
STARTUP FORCE DBA;
SHUTDOWN IMMEDIATE;
STARTUP MOUNT;
# this example uses automatic channels to make the backup
BACKUP
INCREMENTAL LEVEL 0
MAXSETSIZE 10M
DATABASE
TAG 'BACKUP_1';
# Now that the backup is complete, open the database.
ALTER DATABASE OPEN;

読取り専用表領域などの表領域はスキップできますが、バックアップからデータベースをリストアする必要がある場合、最新のバックアップ以降にオフラインまたは読取り専用になっていなかった表領域はスキップすると消失します。

RMANを使用したアーカイブREDOログのバックアップ

アーカイブREDOログは、メディア・リカバリを正常に実行するために重要です。アーカイブREDOログは、定期的にバックアップする必要があります。

アーカイブREDOログのバックアップ

RMANバックアップのいくつかの機能は、アーカイブREDOログ専用です。たとえば、BACKUP ... DELETEを使用すると、アーカイブREDOログをバックアップ・セットにバックアップした後、そのアーカイブREDOログの1つのコピーまたはすべてのコピーをディスクから削除できます。

アーカイブREDOログ・フェイルオーバー

REDOログが複数のアーカイブ先にアーカイブされている場合でも、RMANを使用してアーカイブREDOログをバックアップすると、RMANはアーカイブREDOログ・ファイルのコピーを1つのみ選択してバックアップに含めます。同じログ順序番号を持つログは同一であるため、複数のログ・コピーを含める必要はありません。

アーカイブREDOログ・フェイルオーバー機能を使用すると、RMANは、一部のアーカイブ先でログが欠落している場合またはログに破損ブロックが存在する場合でも、バックアップを完了できます。特定のログ順序およびスレッドに対応する1つ以上のログが、高速リカバリ領域またはいずれかのアーカイブ先で使用可能な場合、RMANはそのログのバックアップを試みます。バックアップ中にログ・ファイルで破損ブロックが検出された場合、RMANは、他の出力先で破損ブロックのないそのログのコピーを検索します。

たとえば、/arch1および/arch2の2つのアーカイブ先に、ログ121から124をアーカイブするとします。表9-1に、制御ファイル内のアーカイブREDOログ・レコードを示します。

表9-1 アーカイブREDOログ・レコードの例

順序

/arch1でのファイル名

/arch2でのファイル名

121

/arch1/archive1_121.arc

/arch2/archive1_121.arc

122

/arch1/archive1_122.arc

/arch2/archive1_122.arc

123

/arch1/archive1_123.arc

/arch2/archive1_123.arc

124

/arch1/archive1_124.arc

/arch2/archive1_124.arc

ここで、あるユーザーが、RMANを使用せずに/arch1ディレクトリからログ122および124を削除したとします。その後、次のバックアップを実行したとします。

BACKUP ARCHIVELOG
FROM  SEQUENCE 121
UNTIL SEQUENCE 125;

フェイルオーバーによって、RMANは、/arch2のログ122および124を使用してバックアップを完了します。

オンラインREDOログ・スイッチ

RMANのもう1つの重要な機能は、自動オンラインREDOログ・スイッチです。最新のオンラインREDOログが含まれている、アーカイブREDOログのオープンされているデータベースのバックアップを作成するには、次のいずれかの句を指定してBACKUPコマンドを実行します。

- PLUS ARCHIVELOG

- ARCHIVELOG ALL

- ARCHIVELOG FROM ...

RMANは、バックアップを開始する前に、現行のREDOログ・グループからの切替えを行い、コマンドの発行時に最新だったREDOログ・グループまでのアーカイブされていないすべてのオンラインREDOログをアーカイブします。この機能によって、コマンド開始前に生成されたすべてのREDOがバックアップに含まれるようになります。

アーカイブREDOログをバックアップする最も効果的な方法の1つとして、BACKUP ... PLUS ARCHIVELOGコマンドを使用する方法があります。これによって、RMANで次の操作が実行されます。

1. ALTER SYSTEM ARCHIVE LOG CURRENT文を実行します。

2. BACKUP ARCHIVELOG ALLを実行します。バックアップの最適化が有効になっている場合、RMANは、指定したデバイスにすでにバックアップされているログをスキップします。

3. BACKUPコマンドに指定された残りのファイルをバックアップします。

4. ALTER SYSTEM ARCHIVE LOG CURRENT文を実行します。

5. バックアップ中に生成された残りのアーカイブ・ログをバックアップします。バックアップの最適化が有効になっていない場合、RMANは、ステップ1で生成されたログおよびバックアップ中に生成されたすべてのログをバックアップします。

前述のステップによって、コマンド実行中に作成されるデータファイルのバックアップを一貫性のある状態にリカバリできます。また、バックアップ終了時にオンラインREDOログがアーカイブされていない場合、そのバックアップでDUPLICATEを実行することはできません。

アーカイブREDOログ・ファイルのバックアップ

アーカイブ・ログをバックアップするには、BACKUP ARCHIVELOGコマンドを使用します。バックアップの最適化が有効になっている場合、RMANは、指定したデバイスにすでにバックアップされているアーカイブ・ログのバックアップをスキップします。

アーカイブREDOログ・ファイルをバックアップする手順

1. RMANを起動し、ターゲット・データベースおよびリカバリ・カタログ(使用している場合)に接続します。

2. ターゲット・データベースがマウントまたはオープンされていることを確認します。

3. BACKUP ARCHIVELOGまたはBACKUP ... PLUS ARCHIVELOGコマンドを実行します。
次の例では、データベースおよびすべてのアーカイブREDOログをバックアップします。

BACKUP DATABASE PLUS ARCHIVELOG;

次の例では、構成済のディスクまたはSBTのチャネルを使用して、すべてのアーカイブREDOログの各ログ順序番号のコピーを1つバックアップします。

BACKUP ARCHIVELOG ALL;

また、アーカイブREDOログの範囲を、時間、SCN、またはログ順序番号で指定することもできます。次に例を示します。

BACKUP ARCHIVELOG
FROM TIME  'SYSDATE-30'
UNTIL TIME 'SYSDATE-7';

バックアップが必要なアーカイブREDOログのみのバックアップ

RMANがアーカイブREDOログのバックアップを次の方法で自動的にスキップするように指定できます。

- バックアップの最適化を構成します。
「バックアップの最適化およびCONFIGUREコマンド」で説明されているように、バックアップの最適化を有効にすると、BACKUP ARCHIVELOGコマンドは、同一のアーカイブ・ログが指定のデバイス・タイプにすでにバックアップされている場合に、ファイルのバックアップをスキップします。DBID、スレッド、順序番号、およびRESETLOGSのSCNと時刻が同じアーカイブ・ログは同一であるとみなされます。

- アーカイブREDOログの削除方針の構成
「アーカイブREDOログの削除方針の構成」で説明されているように、削除方針がBACKED UP integer TIMES句で構成されている場合、指定したデバイス・タイプ上にinteger個のバックアップがすでに存在していないかぎり、BACKUP ARCHIVELOGコマンドはログをコピーします。ログのinteger個のバックアップが存在している場合、BACKUP ARCHIVELOGコマンドはログをスキップします。

BACKUP ... NOT BACKED UP integer TIMESコマンドを指定すると、RMANは、指定したデバイスにinteger回以上バックアップされていないアーカイブ・ログ・ファイルのみをバックアップします。ファイルのバックアップの数を決定する場合、RMANは、現行のバックアップと同じデバイス・タイプに作成されているバックアップのみを考慮します。

BACKED UP句は、指定したメディアにアーカイブ・ログをバックアップする場合に有効です。たとえば、RMANがテープに各アーカイブREDOログのコピーを2つ保持し、追加のバックアップをスキップするように指定できます。

バックアップが必要なアーカイブREDOログをバックアップする手順

1. RMANを起動し、ターゲット・データベースおよびリカバリ・カタログ(使用している場合)に接続します。

2. ターゲット・データベースがマウントまたはオープンされていることを確認します。

3. バックアップに適切なチャネルが構成されていることを確認します。

4. NOT BACKED UP句を指定してBACKUP ARCHIVELOGコマンドを実行します。

BACKUP ARCHIVELOG ALL NOT BACKED UP 2 TIMES;

関連項目:
NOT BACKED UPの使用例については、「バックアップの最適化を使用したファイルのスキップ」を参照してください。

バックアップ後のアーカイブREDOログの削除

BACKUP ARCHIVELOG ... DELETE INPUTコマンドは、アーカイブ・ログ・ファイルをバックアップした後、それらのファイルを削除します。このコマンドを使用すると、アーカイブREDOログを手動で削除する手順を実行する必要がなくなります。

DELETE INPUTを実行すると、RMANは、バックアップ・セットに選択されたアーカイブ・ログの特定のコピーのみを削除します。DELETE ALL INPUTを実行すると、RMANは、バックアップ済の各アーカイブREDOログ・ファイルを、ログのすべてのアーカイブ先から削除します。

「アーカイブREDOログの削除方針の構成」で説明されているように、BACKUP ... DELETE INPUTおよびDELETE ARCHIVELOGコマンドは、すべてのアーカイブ場所にあるログに関してアーカイブREDOログの削除方針に従います。たとえば、2回以上テープにバックアップされたログのみを削除するように指定した場合、BACKUP ... DELETEはこの方針に従います。

次の手順では、/arc_dest1、/arc_dest2および高速リカバリ領域にアーカイブすることを想定しています。

バックアップ後にアーカイブREDOログを削除する手順

1. RMANを起動し、ターゲット・データベースおよびリカバリ・カタログ(使用している場合)に接続します。

2. ターゲット・データベースがマウントまたはオープンされていることを確認します。

3. DELETE INPUT句を指定してBACKUPコマンドを実行します。
次のBACKUPコマンドを実行するとします。

BACKUP DEVICE TYPE sbt
ARCHIVELOG ALL
DELETE ALL INPUT;

この場合、RMANは、これらのアーカイブ場所にある各ログ順序番号のコピーを1つのみバックアップします。RMANは、高速リカバリ領域内と、他のアーカイブ先内の両方のバックアップ済のログのコピーをすべて削除します。

DELETE ALL INPUTではなくDELETE INPUTを指定すると、RMANは、バックアップ済の特定のアーカイブREDOログ・ファイルのみを削除します。たとえば、RMANは、/arc_dest1内のログがバックアップのソースとして使用された場合はそれらのファイルを削除しますが、/arc_dest2の内容はそのまま残します。

関連項目:

- スタンバイ・データベースでのアーカイブREDOログの管理については、『Oracle Data Guard概要および管理』を参照してください。

- CONFIGURE ARCHIVELOG DELETION POLICYコマンドの詳細は、『Oracle Databaseバックアップおよびリカバリ・リファレンス』を参照してください。

- DELETE ARCHIVELOGコマンドの詳細は、『Oracle Databaseバックアップおよびリカバリ・リファレンス』を参照してください。

- 「RMANバックアップおよびアーカイブREDOログの削除」

増分バックアップの作成および更新

「増分バックアップ」で説明されているように、増分バックアップでは、指定した以前のバックアップ以降に変更されたデータファイル・ブロックのみがコピーされます。増分バックアップは、累積増分バックアップまたは差分増分バックアップのいずれかです。

バックアップの内容は同じですが、BACKUP DATABASEとBACKUP INCREMENTAL LEVEL 0 DATABASEは異なります。全体バックアップは増分計画の一部として使用できませんが、レベル0の増分バックアップは増分計画の基礎となります。RMANコマンドでは、全体バックアップをレベル0の増分バックアップには変更できません。

RMANは、全体バックアップの場合と同様に、ARCHIVELOGモードでオープンされているデータベースの増分バックアップを作成できます。データベースがNOARCHIVELOGモードの場合、RMANは、一貫性のある状態でデータベースを停止した後でのみ、増分バックアップを作成できます。

増分バックアップの目的

増分バックアップを計画の一環として作成する主な理由は次のとおりです。

- ブロック・チェンジ・トラッキングを有効にすると、日次バックアップが高速になります(「ブロック・チェンジ・トラッキングを使用した、増分バックアップのパフォーマンスの向上」を参照)。

- データファイルのイメージ・コピーをロールフォワードする機能によって、リカバリ時間を短縮し、全体バックアップが繰り返されないようにするため

- ネットワークを介してバックアップする場合に帯域幅の消費を削減します。

- テープの書込みI/Oに使用するテープ帯域幅の集計がディスクの読取りI/Oに使用するディスク帯域幅の集計より少ない場合にパフォーマンスを向上させるため

- NOLOGGINGオプションで作成したオブジェクトへの変更をリカバリできるようにするため
たとえば、ダイレクト・ロード・インサートではREDOログ・エントリが作成されないため、ダイレクト・ロード・インサートによる変更はメディア・リカバリでは再作成できません。ただし、ダイレクト・ロード・インサートではデータ・ブロックが変更されるため、これらのブロックが増分バックアップによって取得されます。

- フィジカル・スタンバイ・データベースをプライマリ・データベースと同期化します。RMANのBACKUP INCREMENTAL FROM SCNコマンドを使用すると、スタンバイ・データベースの現行のSCNから始まるバックアップをプライマリ・データベースに作成できます。このバックアップを使用して、後でスタンバイ・データベースをロールフォワードできます。増分バックアップをスタンバイ・データベースに適用する方法については、『Oracle Data Guard概要および管理』を参照してください。

関連項目:
NOLOGGINGモードの詳細は、『Oracle Database管理者ガイド』を参照してください。

増分バックアップ計画の設計

許容可能なMTTR(平均リカバリ時間)に応じて、バックアップ計画を選択します。たとえば、3つのレベルのバックアップ・スキームを実装して、レベル0のバックアップを月に1回、レベル1の累積バックアップを週に1回、レベル1の差分バックアップを毎日作成するように設定できます。この計画では、完全リカバリのために、1日分を超えるREDOを適用する必要はありません。

レベル0のバックアップを実行する頻度の目安として、データの20%以上が変更された時点で、レベル0の新しいバックアップを実行するようにします。データベースへの変更率を予想できる場合は、増分バックアップのサイズを監視して、レベル0の新しいバックアップが必要な時点を判断できます。次のSQL問合せを実行すると、ブロックの20%以上がバックアップされている各データファイルの、レベル1の増分バックアップに書き込まれたブロックの数が表示されます。

SELECT   FILE#, INCREMENTAL_LEVEL, COMPLETION_TIME,
BLOCKS, DATAFILE_BLOCKS
FROM     V$BACKUP_DATAFILE
WHERE    INCREMENTAL_LEVEL > 0
AND      BLOCKS / DATAFILE_BLOCKS > .2
ORDER BY COMPLETION_TIME;

レベル1のバックアップのブロック数を、レベル0のバックアップと比較します。たとえば、レベル1の累積バックアップのみを作成する場合は、レベル1の最新のバックアップのサイズがレベル0のバックアップの約半分であれば、レベル0の新しいバックアップを作成します。

ディスク領域を節約する効果的な方法の1つとして、増分バックアップをディスクに作成してから、BACKUP AS BACKUPSETコマンドでバックアップをテープにオフロードする方法があります。通常、増分バックアップは全体バックアップより小さいため、テープに移動されるまでの格納に必要な領域は制限されます。ディスク上の増分バックアップをテープにバックアップすると、増分バックアップのすべてのブロックがテープにコピーされるため、テープがストリーム化する可能性があります。RMANでのデータファイル内の変更されたブロックの特定にかかる時間を原因とした遅延が発生する可能性はありません。

もう1つの方法としては、「増分更新バックアップ」で説明されている増分更新バックアップを使用する方法があります。この方法では、各データファイルのイメージ・コピーを作成した後、レベル1の増分バックアップを作成および適用して、定期的にこのコピーをロールフォワードします。これによって、データファイルの完全なイメージ・コピーを繰り返し作成することによって発生するオーバーヘッドが回避され、すべてのメリットを活用できるようになります。

Data Guard環境では、増分バックアップをフィジカル・スタンバイ・データベースにオフロードできます。スタンバイ・データベースの増分バックアップとプライマリ・データベースの増分バックアップには互換性があります。つまり、スタンバイ・データベースの増分バックアップをプライマリ・データベースに適用したり、プライマリ・データベースの増分バックアップをスタンバイ・データベースに適用することができます。

関連項目:
RMANでスタンバイ・データベースをバックアップする方法については、『Oracle Data Guard概要および管理』を参照してください。特に、第9章「フィジカルおよびスナップショット・スタンバイ・データベースの管理」を参照してください。

増分バックアップの作成

RMANを起動した後、RMANプロンプトで BACKUP INCREMENTALコマンドを実行します。デフォルトでは、増分バックアップは差分バックアップです。

増分バックアップを作成する手順

1. RMANを起動し、ターゲット・データベースおよびリカバリ・カタログ(使用している場合)に接続します。

2. ターゲット・データベースがマウントまたはオープンされていることを確認します。

3. 必要なオプションを指定してBACKUP INCREMENTALコマンドを実行します。
増分レベルを指定するには、LEVELパラメータを使用します。次の例では、データベースのレベル0の増分バックアップを作成します。

BACKUP
INCREMENTAL LEVEL 0
DATABASE;

次の例では、SYSTEMおよびtools表領域の差分増分バックアップをレベル1で作成します。レベル1またはレベル0の最新のバックアップ以降に変更されたデータ・ブロックのみがバックアップされます。

BACKUP
INCREMENTAL LEVEL 1
TABLESPACE SYSTEM, tools;

次の例では、users表領域の累積増分バックアップをレベル1で作成し、最新のレベル0のバックアップ以降に変更されたすべてのブロックをバックアップします。

BACKUP
INCREMENTAL LEVEL 1 CUMULATIVE
TABLESPACE users;

VSSスナップショットの増分バックアップの作成

Volume Shadow Copy Service(VSS)をOracle VSSライターとともに使用すると、データベース内のファイルのシャドウ・コピーまたはスナップショットを作成できます。Oracle VSSライターでVSSスナップショットを作成するには、RMANではなく、サード・パーティのバックアップ・プログラムを使用する必要があります。この場合、高速リカバリ領域によって、VSSスナップショットにバックアップされているファイルの管理が自動化され、必要に応じてそれらのファイルが削除されます。

RMANで BACKUP INCREMENTAL LEVEL 1 ... FROM SCNコマンドを使用すると、高速リカバリ領域に増分バックアップを作成できます。つまり、このコマンドを使用すると、VSSシャドウ・コピーのレベル1の増分バックアップを作成できます。RMANでは、リカバリ中に増分バックアップを透過的に適用できます。

関連項目:
RMANを使用してVSSバックアップを作成する方法については、『Oracle Databaseプラットフォーム・ガイドfor Microsoft Windows』を参照してください。

増分更新バックアップ

バックアップを増分更新することによって、データファイルの完全なイメージ・コピー・バックアップを作成する場合に発生するオーバーヘッドを回避できます。また、データベースのメディア・リカバリにかかる時間を最小限に抑えることもできます。たとえば、日次バックアップ・スクリプトを実行する場合、メディア・リカバリのために、1日分を超えるREDOを適用する必要はありません。

データファイルのバックアップを増分更新する手順

1. 指定したタグが含まれているデータファイルの完全なイメージ・コピー・バックアップを作成します。

2. 定期的(毎日など)に、データファイルのレベル1の差分増分バックアップを作成して、同じタグを基本データファイル・コピーとして使用します。

3. 増分バックアップを同じタグを持つ最新のバックアップに適用します。

この方法では、レベル1の増分バックアップが作成された時点にバックアップがロールフォワードされます。RMANは、この増分更新バックアップをリストアし、REDOログから変更を適用できます。この場合、最後に適用されたレベル1の増分バックアップのSCNで作成されたデータファイルのバックアップをリストアする場合と同じ結果になります。

注意:
UNTIL TIMEを指定せずにRECOVER COPYを毎日実行すると、イメージ・コピーは継続的に更新されるため、1日を超えるリカバリ期間を満たすことができません。増分更新バックアップ機能は、高速のメディア・リカバリを実現するための最適な方法です。

増分更新バックアップ: 基本例

増分更新バックアップ計画で使用する増分バックアップを作成するには、 BACKUP ... FOR RECOVER OF COPY WITH TAG形式のBACKUPコマンドを使用します。このコマンドについては、増分更新バックアップ計画を実装するサンプル・スクリプトを参照してください。

増分更新バックアップに基づいた計画を実装するには、例9-9のスクリプトを定期的に実行することのみが必要となります。

例9-9 基本的な増分更新スクリプト

RUN
{
RECOVER COPY OF DATABASE
WITH TAG 'incr_update';
BACKUP
INCREMENTAL LEVEL 1
FOR RECOVER OF COPY WITH TAG 'incr_update'
DATABASE;
}

このスクリプトおよび計画を理解するには、データファイルのコピーまたは増分バックアップが存在しない場合の、使用されている2つのコマンドの影響について理解する必要があります。次の2つの点に注意してください。

- 例9-9のBACKUPコマンドによって、常にレベル1の増分バックアップが作成されるわけではありません。

- 例9-9のRECOVERコマンドを実行すると、RMANによって、指定したタグが付いた利用可能なレベル1の増分バックアップが、同じタグが付いた一連のデータファイル・コピーに適用されます。

表9-2に、月曜日から毎日1回スクリプトを実行した場合の影響を示します。

表9-2 基本スクリプトを毎日実行した場合の影響

コマンド

月曜日

火曜日

水曜日

木曜日以降

RECOVER

増分バックアップまたはデータファイルのコピーが存在しないため、コマンドによってメッセージが生成されます(エラーは生成されません)。つまり、コマンドによる影響はありません。

データベースのコピーは存在しますが、そのコピーのリカバリに使用するレベル1の増分バックアップは存在しません。つまり、RECOVERコマンドによる影響はありません。

火曜日に作成されたレベル1の増分バックアップがデータベース・コピーに適用され、そのコピーがレベル1の増分バックアップのチェックポイントSCNまで戻されます。

昨日作成されたレベル1の増分バックアップがデータベース・コピーに適用され、そのコピーがレベル1の増分バックアップのチェックポイントSCNまで戻されます。

BACKUP

レベル0のイメージ・コピーが存在しないため、コマンドによってデータベースのイメージ・コピーが作成され、タグincr_updateが適用されます。このコピーが、増分更新のサイクルを開始するために必要となります。

注意: スクリプトによってDEVICE TYPE sbtが設定される場合は、最初の実行によって、テープ上ではなくディスク上にコピーが作成されます。後続の実行では、テープ上にレベル1の増分バックアップが作成されます。

コマンドによって、レベル1の増分バックアップが作成され、タグincr_updateが割り当てられます。このバックアップには、月曜日と火曜日の間に変更されたブロックが含まれます。

コマンドによって、レベル1の増分バックアップが作成され、タグincr_updateが割り当てられます。このバックアップには、火曜日と水曜日の間に変更されたブロックが含まれます。

コマンドによって、レベル1の増分バックアップが作成され、タグincr_updateが割り当てられます。このバックアップには、現在とタグincr_updateを含む最新のバックアップの間に変更されたブロックが含まれます。

例9-9についての次の追加事項に注意してください。

- データファイルがデータベースに追加されるたびに、新しいデータファイルのイメージ・コピーが、次のスクリプト実行時に作成されます。その次の実行では、追加されたデータファイルの、最初のレベル1の増分バックアップが作成されます。後続のすべての実行では、新しいデータファイルは他のデータファイルと同様に処理されます。

- 他のバックアップ計画に影響を与えないように、タグを使用して、この計画のデータファイルのコピーおよび増分バックアップを識別する必要があります。複数の増分バックアップ計画を使用している場合、レベル0のバックアップにタグを指定していないかぎり、RMANはレベル1の増分バックアップを確実に作成することはできません。
これらのイメージ・コピーに適用されるレベル1の増分バックアップは、データファイルのイメージ・コピーのタグおよび使用可能なレベル1の増分バックアップのタグに基づいて選択されます。タグは、そのレベルの増分バックアップを選択する場合に必ず必要になります。

- スクリプトの3回目の実行後は、次のファイルをPoint-in-Timeリカバリで使用できるようになります。

- 前回(24時間前に)スクリプトを実行したときのチェックポイントSCN時点でのデータベースのイメージ・コピー

- 前回実行したときのチェックポイントSCN以降に行われた変更の増分バックアップ

- イメージ・コピーのチェックポイントSCNと現在の時点の間で行われたすべての変更を含むアーカイブREDOログ

次の24時間の間にデータベースのリストアおよびリカバリが必要になった場合は、増分更新されたデータファイルのコピーからデータファイルをリストアできます。これによって、必要なSCNに達するまで、レベル1の最新の増分バックアップおよびREDOログから変更を適用できます。最大24時間分の適用対象のREDOがあるため、Point-in-Timeリカバリの終了にかかる時間は制限されます。

関連項目:
Enterprise Managerを使用したOracleバックアップ計画でこの方法を使用する方法については、『Oracle Database 2日でデータベース管理者』を参照してください。

増分更新バックアップ: 高度な例

例9-9の基本スクリプトを拡張すると、24時間を超える期間を高速でリカバリできます。例9-10に、RECOVERコマンドでリカバリ可能期間の開始時間を指定して、7日間保持する方法を示します。

例9-10 高度な増分更新スクリプト

RUN
{
RECOVER COPY OF DATABASE
WITH TAG 'incr_update'
UNTIL TIME 'SYSDATE - 7';
BACKUP
INCREMENTAL LEVEL 1
FOR RECOVER OF COPY WITH TAG 'incr_update'
DATABASE;
}

表9-3に、1月1日月曜日から毎日1回スクリプトを実行した場合の影響を示します。

表9-3 高度なスクリプトを毎日実行した場合の影響

コマンド

1月1日(月曜日)

1月2日(火曜日)から1月8日(月曜日)

1月9日(火曜日)

1月10日(水曜日)以降

RECOVER

増分バックアップまたはデータファイルのコピーが存在しないため、コマンドによってメッセージが生成されます(エラーは生成されません)。つまり、コマンドによる影響はありません。

データベースのコピーは存在しますが、SYSDATE-7は基本コピーが作成される前の時点を指定しています。たとえば、SYSDATE-7は、水曜日に1月1日月曜日よりも前の水曜日を指定しています。つまり、RECOVERコマンドによる影響はありません。

SYSDATE-7は、基本コピーが作成された後の日付を指定しています。1月1日月曜日に作成されたデータベースのコピーが、1月2日火曜日に作成された増分バックアップで更新され、そのコピーがレベル1の増分バックアップのチェックポイントSCNまで戻されます。

データベースのコピーが、7日前に作成された増分バックアップで更新され、そのコピーがレベル1の増分バックアップのチェックポイントSCNまで戻されます。

BACKUP

レベル0のイメージ・コピーが存在しないため、コマンドによってデータベースのイメージ・コピーが作成され、タグincr_updateが適用されます。このコピーが、増分更新のサイクルを開始するために必要となります。

注意: スクリプトによってDEVICE TYPE sbtが設定される場合は、最初の実行によって、テープ上ではなくディスク上にコピーが作成されます。後続の実行では、テープ上にレベル1の増分バックアップが作成されます。

コマンドによって、レベル1の増分バックアップが作成され、タグincr_updateが割り当てられます。このバックアップには、前日と本日の間に変更されたブロックが含まれます。

コマンドによって、レベル1の増分バックアップが作成され、タグincr_updateが割り当てられます。このバックアップには、1月8日月曜日と1月9日火曜日の間に変更されたブロックが含まれます。

コマンドによって、レベル1の増分バックアップが作成され、タグincr_updateが割り当てられます。このバックアップには、前日と本日の間に変更されたブロックが含まれます。

例9-9の基本スクリプトと同様に、データファイルのコピーのSCNと現在の間の任意の時点に高速でリカバリできます。RMANは、増分バックアップのブロック変更およびREDOログの個々の変更の両方を使用できます。レベル1の日次増分バックアップがあるため、1日分を超えるREDOを適用する必要はありません。

関連項目:
RECOVERコマンドの詳細は、『Oracle Databaseバックアップおよびリカバリ・リファレンス』を参照してください。

ブロック・チェンジ・トラッキングを使用した、増分バックアップのパフォーマンスの向上

増分バックアップのブロック・チェンジ・トラッキング機能を使用すると、データファイルごとに変更されたブロックを記録することによってバックアップのパフォーマンスが向上します。

ブロック・チェンジ・トラッキング

プライマリ・データベースまたはスタンバイ・データベースでブロック・チェンジ・トラッキングが有効になっている場合、RMANは、ブロック・チェンジ・トラッキング・ファイルを使用して、増分バックアップ用に変更されたブロックを識別します。この小さなビットマップ・ファイルを読み取り、変更されたブロックを確認することによって、バックアップしているデータファイルのすべてのブロックのスキャンを回避します。

ブロック・チェンジ・トラッキングは、デフォルトでは無効になっています。ただし、バックアップ中にデータファイル全体をスキャンする必要がなくなるというメリットは無視できません。バックアップを実行してから次のバックアップを実行するまでの間に変更されたデータ・ブロックが小量の場合は特にです。 バックアップ計画に増分バックアップが含まれている場合は、ブロック・チェンジ・トラッキングを有効にすることをお薦めします。ブロック・チェンジ・トラッキングによって、増分バックアップの実行に使用されるコマンドが変更されることはありません。初期構成後にチェンジ・トラッキング・ファイルにメンテナンスを行う必要はありません。

Oracle Active Data Guardオプションのライセンスが有効な場合にのみ、フィジカル・スタンバイ・データベースでブロック・チェンジ・トラッキングを有効にできます。

ブロック・チェンジ・トラッキング・ファイルの領域管理

チェンジ・トラッキング・ファイルには、バックアップ間のデータファイルの変更をマークするビットマップが保持されます。データベースでは、各バックアップの前にビットマップの切替えが実行されます。Oracle Databaseでは、最新の8つのバックアップに対応するブロック・チェンジ・データを保持するためにチェンジ・トラッキング・ファイルの領域が自動的に管理されます。最大8つのビットマップに達すると、最も古いビットマップは現行の変更を追跡するビットマップによって上書きされます。

最初のレベル0の増分バックアップでは、データファイル全体がスキャンされます。その後の増分バックアップでは、ブロック・チェンジ・トラッキング・ファイルを使用して、最後のバックアップの後に変更されたとマークされているブロックのみがスキャンされます。増分バックアップの最適化は、ブロック・チェンジ・トラッキング・ファイルの最も古いビットマップ以降に作成された親バックアップに基づいてのみ行われます。

増分バックアップ計画を作成する場合は、ビットマップ数の制限(8)を考慮してください。たとえば、レベル0のデータベース・バックアップを作成した後で7つの差分増分バックアップを作成すると、ブロック・チェンジ・トラッキング・ファイルには8つのビットマップが含まれます。次にレベル1の累積増分バックアップを作成すると、レベル0の親バックアップに対応するビットマップが現行の変更を追跡するビットマップで上書きされるため、RMANはバックアップを最適化できません。

ブロック・チェンジ・トラッキング・ファイルの場所

データベース全体に対して、1つのブロック・チェンジ・トラッキング・ファイルが作成されます。デフォルトでは、チェンジ・トラッキング・ファイルは、DB_CREATE_FILE_DEST初期化パラメータで指定された作成先にOracle Managed Filesとして作成されます。また、ブロック・チェンジ・トラッキングを有効にするときに名前を指定して、選択した場所にチェンジ・トラッキング・ファイルを配置することもできます。RAWデバイス(つまりファイル・システムのないディスク)をチェンジ・トラッキング・ファイルとして使用しないことをお薦めします。

注意:
Oracle RAC環境では、チェンジ・トラッキング・ファイルは、クラスタ内のすべてのノードからアクセスできる共有ストレージに格納する必要があります。

RMANでは、チェンジ・トラッキング・ファイルのバックアップおよびリカバリはサポートされていません。データベースは、チェンジ・トラッキング・ファイルが無効であると判断した場合、チェンジ・トラッキング・ファイルを再設定します。データベース全体またはサブセットをリストアおよびリカバリする場合、データベースは、ブロック・チェンジ・トラッキング・ファイルを再設定し、変更の追跡を再度開始します。レベル0の増分バックアップを作成した後の次の増分バックアップでは、チェンジ・トラッキング・データを使用できます。

ブロック・チェンジ・トラッキング・ファイルのサイズ

ブロック・チェンジ・トラッキング・ファイルのサイズは、データベースのサイズおよびREDOの有効になっているスレッドの数に比例します。ブロック・チェンジ・トラッキング・ファイルのサイズは、データベースの変更に応じて増減します。このサイズは、データベースの更新頻度とは関係ありません。

通常、シングル・インスタンスのブロック・チェンジ・トラッキングに必要な領域は、追跡するデータ・ブロックのサイズの約1/30,000です。Oracle RAC環境では、データベースのサイズの1/30,000×有効になっているスレッドの数です。

この見積りが示すサイズよりファイルが大きくなる場合の要因を次に示します。

- データベースの拡張に応じて領域を割り当てた場合にオーバーヘッドが発生しないようにするために、ブロック・チェンジ・トラッキング・ファイルのサイズは10MBから始まります。新しい領域は10MBずつ割り当てられます。つまり、ファイルのサイズは、約300GBまでのデータベースに対しては10MB以上、約600GBまでのデータベースに対しては20MB以上になります。

- データファイルのサイズとは関係なく、データファイルごとに320KB以上の領域がブロック・チェンジ・トラッキング・ファイルに割り当てられます。このため、比較的小さなデータファイルが多数ある場合は、同じデータを含む大きなデータファイルが少数ある場合よりチェンジ・トラッキング・ファイルのサイズが大きくなります。

ブロック・チェンジ・トラッキングの有効化および無効化

ブロック・チェンジ・トラッキングは、データベースがオープンまたはマウントされている場合に有効にできます。この項では、ブロック・チェンジ・トラッキングをOracle Managed Filesとしてデータベース領域に作成することを想定しています。データベース領域とは、データファイル、制御ファイル、オンラインREDOログ・ファイルなどのアクティブなデータベース・ファイルをデータベースが保持する場所です。データベース領域および高速リカバリ領域については、「高速リカバリ領域の概要」を参照してください。

ブロック・チェンジ・トラッキングを有効にする手順

1. SQL*Plusを起動し、管理者権限でターゲット・データベースに接続します。

2. DB_CREATE_FILE_DEST初期化パラメータが設定されていることを確認します。

SHOW PARAMETER DB_CREATE_FILE_DEST

パラメータが設定されておらず、データベースがオープンされている場合は、次の形式のALTER SYSTEM文を使用してパラメータを設定できます。

ALTER SYSTEM SET
DB_CREATE_FILE_DEST = '/disk1/bct/'
SCOPE=BOTH SID='*';

3. ブロック・チェンジ・トラッキングを有効にします。
次のALTER DATABASE文を実行します。

ALTER DATABASE ENABLE BLOCK CHANGE TRACKING;

また、次の形式のSQL文を使用して、自分で選択した場所にチェンジ・トラッキング・ファイルを作成することもできます。

ALTER DATABASE ENABLE BLOCK CHANGE TRACKING
USING FILE '/mydir/rman_change_track.f' REUSE;

REUSEオプションは、Oracle Databaseに、指定した名前を持つ既存のブロック・チェンジ・トラッキング・ファイルを上書きするように指示します。

ブロック・チェンジ・トラッキングの無効化

この項では、ブロック・チェンジ・トラッキング機能が現在有効になっていると想定しています。ブロック・チェンジ・トラッキングを無効にすると、データベースはオペレーティング・システムからブロック・チェンジ・トラッキング・ファイルを削除します。

ブロック・チェンジ・トラッキングを無効にする手順

1. SQL*Plusを起動し、管理者権限でターゲット・データベースに接続します。

2. ターゲット・データベースがマウントまたはオープンされていることを確認します。

3. ブロック・チェンジ・トラッキングを無効にします。
次のALTER DATABASE文を実行します。

ALTER DATABASE DISABLE BLOCK CHANGE TRACKING;

チェンジ・トラッキングが有効かどうかの確認

V$BLOCK_CHANGE_TRACKINGビューを問い合せて、チェンジ・トラッキングが有効になっているかどうかを確認し、有効になっている場合はブロック・チェンジ・トラッキング・ファイルのファイル名も調べることができます。

チェンジ・トラッキングが有効かどうかを確認する方法

SQL*Plusで次の問合せを入力します(出力例も示します)。

COL STATUS   FORMAT A8
COL FILENAME FORMAT A60

SELECT STATUS, FILENAME
FROM   V$BLOCK_CHANGE_TRACKING;

STATUS   FILENAME
-------- ------------------------------------------------------------
ENABLED  /disk1/bct/RDBMS/changetracking/o1_mf_2f71np5j_.chg

ブロック・チェンジ・トラッキング・ファイルの場所の変更

チェンジ・トラッキング・ファイルを移動するには、ALTER DATABASE RENAME FILE文を使用します。データベースはマウントされている必要があります。この文は、新しい場所を参照するように制御ファイルを更新し、チェンジ・トラッキング・ファイルの内容を保持します。データベースを停止できない場合は、ブロック・チェンジ・トラッキングを無効にしてから有効にすることができます。この場合、既存のブロック・チェンジ・トラッキング・ファイルの内容は消失します。

チェンジ・トラッキング・ファイルの場所を変更する手順

1. SQL*Plusを起動し、ターゲット・データベースに接続します。

2. 必要に応じて、チェンジ・トラッキング・ファイルの現在の名前を確認します。

SQL> SELECT FILENAME FROM V$BLOCK_CHANGE_TRACKING;

3. 可能な場合は、データベースを停止します。次に例を示します。

SQL> SHUTDOWN IMMEDIATE

データベースを停止する場合は、次の手順にスキップします。データベースを停止しない場合は、次のSQL文を実行し、残りの手順をすべてスキップします。

SQL> ALTER DATABASE DISABLE BLOCK CHANGE TRACKING;
SQL> ALTER DATABASE ENABLE BLOCK CHANGE TRACKING USING FILE 'new_location';

この場合、ブロック・チェンジ・トラッキング・ファイルの内容は消失します。次回レベル0の増分バックアップを完了するまで、RMANはファイル全体をスキャンする必要があります。

4. ホスト・オペレーティング・システムのコマンドを使用して、チェンジ・トラッキング・ファイルを新しい場所に移動します。

5. データベースをマウントして、より多くの領域がある場所にチェンジ・トラッキング・ファイルを移動します。次に例を示します。

ALTER DATABASE RENAME FILE
'/disk1/bct/RDBMS/changetracking/o1_mf_2f71np5j_.chg' TO
'/disk2/bct/RDBMS/changetracking/o1_mf_2f71np5j_.chg';

この文は、内容を保持した状態でチェンジ・トラッキング・ファイルの場所を変更します。

6. データベースをオープンします。

SQL> ALTER DATABASE OPEN;

関連項目:
ALTER DATABASE文およびALTER SYSTEM文については、『Oracle Database SQL言語リファレンス』を参照してください。

長期格納用のデータベース・バックアップの作成

この項では、長期格納用のバックアップを作成する場合の基本的な概念およびタスクについて説明します。

アーカイブ・バックアップの目的

BACKUP ... KEEPを使用して、バックアップの保存方針から除外する包括的なバックアップを作成できます。データベースのリストアおよびリカバリに必要なすべてのファイルが単一のディスクまたはテープにバックアップされるため、このバックアップは包括的になります。また、KEEPオプションは、保存方針からのバックアップの除外を永続的または指定した期間行うように指定します。BACKUP ... KEEPで作成されるバックアップの一般名はアーカイブ・バックアップです。

「データの保持」で説明されているように、バックアップおよびリカバリ計画の目的の1つは、データを保存することです。BACKUP ... KEEPを使用すると、保存方針に指定された期間より長くデータベースのバックアップを保持できます。たとえば、規定の要件を満たすために毎年元旦にデータベースをバックアップして、メディアをオフサイトに格納することができます。アーカイブ・バックアップを作成して数年後に、このバックアップをリストアおよびリカバリしてバックアップ時のデータの状態を問い合せることができます。

アーカイブ・バックアップのもう1つの目的は、テストのためにリストアするバックアップを作成し、後で削除することです。たとえば、データベースをバックアップしてテスト環境でリストアした後、テスト・データベースが操作可能になったらアーカイブ・バックアップを破棄することができます。また、これと関連して、別のユーザーまたはホストへの転送完了後に削除可能な自己完結型のバックアップを作成するという目的もあります。たとえば、別のユーザーが、レポートまたはテスト用にデータベースのコピーを必要とする場合があります。

アーカイブ・バックアップの基本的な概念

BACKUPコマンドでKEEPオプションを使用すると、バックアップを保存方針から除外できます。また、CHANGEコマンドのKEEPおよびNOKEEPオプションを使用して、既存のバックアップのステータスを変更することもできます。KEEP属性を使用したバックアップは、他のすべてのバックアップと同様にリカバリできる有効なバックアップです。

KEEP UNTIL TIME句を使用してアーカイブ・バックアップの終了日を指定したり、FOREVERを使用してバックアップを永続的に保持するように指定できます。UNTILを指定した場合、構成されている保存方針に関係なく、UNTILで指定した時間が経過すると、バックアップはRMANによって不要とマークされます。たとえば、KEEP UNTIL TIME '01-JAN-08'と指定すると、1月1日の深夜0時を1秒経過した後にバックアップが不要とマークされます。UNTIL TIMEを午後9時に指定すると、午後9時1分にバックアップが不要とマークされます。

BACKUPコマンドにKEEPを指定すると、RMANは複数のバックアップ・セットを生成します。BACKUP ... KEEPコマンドには次の特性があります。

- データファイル、制御ファイル(制御ファイルの自動バックアップが無効になっている場合でも)およびサーバー・パラメータ・ファイルが自動的にバックアップされます。

- データベースのバックアップを一貫性のある状態にリカバリできるように、アーカイブREDOログのバックアップが自動的に生成されます。

- FORMAT、POOLまたはTAGパラメータを指定した場合、これらのパラメータはすべてのバックアップに使用されます。このため、FORMAT文字列で、複数のバックアップ・ピースを作成できるようにする必要があります。%U置換変数を指定すると、最も簡単にこの要件を満たすことができます。

- 通常のリストア・ポイントを作成するオプションのRESTORE POINT句がサポートされています。通常のリストア・ポイントとは、バックアップを一貫性のある状態にするためにリカバリする必要がある時点のSCNのラベルのことです。SCNは、データファイルのバックアップが完了した直後に取得されます。RMANでは、リカバリ・カタログを使用してリストア・ポイントが再同期化され、バックアップが存在するかぎりそのリストア・ポイントが保持されます。リストア・ポイントの表示方法については、「リストア・ポイントの表示」を参照してください。

関連項目:
CHANGEの構文については、『Oracle Databaseバックアップおよびリカバリ・リファレンス』を参照してください。BACKUP ... KEEPの構文については、『Oracle Databaseバックアップおよびリカバリ・リファレンス』を参照してください。

長期格納用のアーカイブ・バックアップの作成

通常、アーカイブ・バックアップはテープに作成します。データ保護を目的としたバックアップは、アクセス可能な状態のままで再利用されるテープのセットに格納されることが多いため、アーカイブ・バックアップ用にテープのセットを取っておくことをお薦めします。この特別なテープのセットにアーカイブ・バックアップを書き込んだ後、オフサイトの保管場所に格納することができます。

動的更新を行うストアド・スクリプトまたはシェル・スクリプトを作成して、アーカイブ・バックアップを作成するための手順を変更できます。スクリプトを実行すると、リストア・ポイントの名前、バックアップ形式などを動的に設定できます。

関連項目:

- アーカイブ・バックアップをリストアする場合の推奨方法については、「ターゲット接続を行わないバックアップベースの複製の例」を参照してください。

- RMANコマンド・ファイルを使用してアーカイブ・バックアップを作成する方法については、「コマンド・ファイルでの置換変数の使用」および「動的ストアド・スクリプトの作成および実行」を参照してください。

アーカイブ・バックアップの作成

次の例では、QUARTERLYというバックアップのタグを使用して長期用のアーカイブ・バックアップを作成し、長期格納用に確保されているOracle Secure Backupの専用のテープ・ファミリに割り当てます。この例では、次の点に注意してください。

- FOREVERキーワードは、このバックアップがバックアップの保存方針による削除の対象にはならないことを示します。

- BACKUPコマンドでは、FY06Q4という名前のリストア・ポイントを作成します。そのリストア・ポイントは、このバックアップが一貫性を持つ時点におけるSCNに対応します。

長期用のアーカイブ・バックアップを作成する手順

1. RMANを起動し、ターゲット・データベースおよびリカバリ・カタログに接続します。
ターゲット・データベースは、オープンされている状態でもマウントされている状態でもかまいません。リカバリ・カタログは、KEEP FOREVERには必要ですが、その他のKEEPオプションには必要ありません。

2. BACKUP ... KEEPを実行して、バックアップを作成します。
次の例では、データファイルおよびアーカイブ・ログのバックアップを生成し、通常のリストア・ポイントを作成します。指定したリストア・ポイントは、すで存在していない必要があります。

ログのバックアップには、このバックアップを一貫性のある状態にリストアするためのアーカイブ・ログのみが含まれています。この新しいバックアップを一貫性のある状態するために必要な、現行のオンライン・ログにあるREDOをアーカイブするために、データベースでオンラインREDOログの切替えが実行されます。制御ファイルの自動バックアップにはリストア・ポイントのコピーが含まれているため、制御ファイルをリストアするとすぐにこのコピーを参照できます。

RUN
{
ALLOCATE CHANNEL c1
DEVICE TYPE sbt
PARMS 'ENV=(OB_MEDIA_FAMILY=archival_backup)';
BACKUP DATABASE
TAG quarterly
KEEP FOREVER
RESTORE POINT FY06Q4;
}

次の例では、バックアップを永続的にではなく、365日間保存します。1年が経過すると、バックアップ保存方針に関係なく、バックアップは不要とマークされます。

RUN
{
ALLOCATE CHANNEL c1 DEVICE TYPE sbt
PARMS 'ENV=(OB_MEDIA_FAMILY=archival_backup)';
BACKUP DATABASE
TAG quarterly
KEEP UNTIL TIME 'SYSDATE+365'
RESTORE POINT FY06Q4;
}

関連項目:
リストア・ポイントについては、「フラッシュバック・データベース、リストア・ポイントおよび保証付きリストア・ポイントについて」を参照してください。

一時的なアーカイブ・バックアップの作成

アーカイブ・バックアップの目的の1つは、テスト・データベースを作成することです。テスト・データベースの作成方法は、「長期格納用のアーカイブ・バックアップの作成」で説明されている方法と基本的に同じです。異なる点は、バックアップを、作成後すぐに削除することです。

BACKUP ... KEEP UNTILパラメータを使用すると、バックアップの一時的なステータスを指定できます。バックアップを作成後、そのバックアップを同じ日に新しいホストにリストアするとします。この場合、KEEP UNTIL TIME SYSDATE+1を指定して、1日間のみこのバックアップの保存方針を上書きするようにRMANに指示できます。1日が経過すると、構成されているバックアップ保存方針に関係なく、バックアップは不要とマークされます。

例9-11のコマンドは、タグTESTDBが含まれているアーカイブ・バックアップを一時ディスクに作成します。この例では、バックアップをリカバリする時点のラベルとなる通常のリストア・ポイントを作成します。バックアップ中にデータベースがオープンしている場合、RMANはアーカイブREDOログのみをバックアップします。アーカイブ・ログは、オフライン・バックアップでは必要ないためバックアップされません。

例9-11 一時的なアーカイブ・バックアップの作成

BACKUP DATABASE
FORMAT '/disk1/oraclebck/%U'
TAG TESTDB
KEEP UNTIL TIME 'SYSDATE+1'
RESTORE POINT TESTDB06;

アーカイブ・バックアップをリストアする場合の推奨方法は、DUPLICATEコマンドを使用することです。「ターゲット接続を行わないバックアップベースの複製の例」を参照してください。

RMANバックアップのバックアップ

この項では、バックアップ・セットおよびイメージ・コピーのバックアップ方法について説明します。

バックアップのバックアップ

BACKUP BACKUPSETコマンドを使用して、他のバックアップ・ジョブによって作成されたバックアップ・セットをバックアップできます。また、BACKUP RECOVERY AREAを使用すると、現行および以前のすべての高速リカバリ領域に作成されたリカバリ・ファイルをバックアップすることもできます。リカバリ・ファイルとは、全体および増分バックアップ・セット、制御ファイルの自動バックアップ、データファイルのコピーおよびアーカイブREDOログのことです。BACKUP RECOVERY AREAでは、SBTバックアップおよびディスク・バックアップがサポートされています。リカバリ・ファイルのディスク・バックアップの場合は、TO DESTINATIONオプションを使用する必要があります。

これらのコマンドは、特に次の場合に有効です。

- すべてのバックアップをディスクおよびテープの両方に存在させる場合。

- バックアップをディスクからテープに移動して、ディスク上の領域を解放する場合。このタスクは、必要に応じて領域を再利用できるようにデータベースで高速リカバリ領域を使用している場合、特に重要です。

また、BACKUP COPY OFコマンドを使用すると、データファイル、制御ファイルおよびアーカイブREDOログのイメージ・コピーをバックアップすることもできます。このコマンドでは、バックアップ・セットまたはイメージ・コピーのいずれかを出力できるため、イメージ・コピーからバックアップ・セットを生成できます。ディスク上にイメージ・コピーとして作成されたデータベースのバックアップをテープにバックアップするには、この形式のバックアップを使用します。

バックアップ・セットの複数のコピー

BACKUP BACKUPSETを実行すると、バックアップ・セットにバックアップ・ピースの追加コピーが作成されますが、新しいバックアップ・セットは作成されません。つまり、BACKUP BACKUPSETは、BACKUPのDUPLEXまたはMAXCOPIESオプションを使用する場合と類似しています(「バックアップ・セットの多重化」を参照)。他の形式のBACKUPコマンドによって生成されたバックアップ・セットのコピーが個別のバックアップ・セットにならないのと同様に、BACKUP BACKUPSETによって作成されたバックアップ・セットの追加コピーも新しいバックアップ・セットにはなりません。

バックアップをバックアップする場合のバックアップの保存方針の影響

冗長性に基づくバックアップの保存方針では、バックアップ・セットはバックアップの1つのインスタンスとみなされます。これは、バックアップ・セットを構成するバックアップ・ピースの複数のコピーが存在する場合(バックアップ・セットがディスクからテープにバックアップされている場合など)でも該当します。

リカバリ期間に基づく保存方針では、バックアップ・セットのすべてのコピーが不要とみなされるか、またはすべてが不要でないとみなされます。LISTおよびREPORTコマンドの出力を確認すると、この点を最も簡単に理解できます。

バックアップをバックアップする場合のバックアップの保存方針の影響を表示する手順

1. データファイルをバックアップします。
この例では、データファイル5をバックアップします。

BACKUP AS BACKUPSET DATAFILE 5;

2. 手順1で作成したデータファイルのバックアップに対してLISTコマンドを実行します。
たとえば、次のコマンドを実行します(出力例も示します)。

LIST BACKUP OF DATAFILE 5 SUMMARY;

List of Backups
===============
Key     TY LV S Device Type Completion Time #Pieces #Copies Compressed Tag
------- -- -- - ----------- --------------- ------- ------- ---------- ---
18      B  F  A DISK        04-AUG-07       1       1       NO         TAG20070804T160 134

3. 前の手順のバックアップ・セット・キーを使用して、バックアップ・セットをバックアップします。
たとえば、次のコマンドを入力します。

BACKUP BACKUPSET 18;

4. 手順2で実行したLISTコマンドを再度実行します。
たとえば、次のコマンドを実行します(出力例も示します)。

LIST BACKUP OF DATAFILE 5 SUMMARY;

List of Backups
===============
Key     TY LV S Device Type Completion Time #Pieces #Copies Compressed Tag
------- -- -- - ----------- --------------- ------- ------- ---------- ---
18      B  F  A DISK        04-AUG-07       1       2       NO         TAG20070804T160 134

この出力に表示されているバックアップ・セットは1つのみですが、これでバックアップ・セットのコピーは2つ存在しています。

5. レポートを生成して、冗長性に基づくバックアップの保存方針でのこれらのコピーの影響を確認します。
たとえば、次のコマンドを発行します。

REPORT OBSOLETE REDUNDANCY 1;

バックアップ・セットの両方のコピーのset_stampとset_countの値が同じであるため、いずれのコピーも不要とはみなされません。

6. レポートを生成して、リカバリ期間に基づくバックアップの保存方針でのこれらのコピーの影響を確認します。
たとえば、次のコマンドを発行します。

REPORT OBSOLETE RECOVERY WINDOW 1 DAY;

現在の時点と他のバックアップの可用性に関して、バックアップ・セットのいずれのコピーも不要であるとはみなされず、またこのバックアップ・セットのCHECKPOINT_CHANGE#に基づくとはみなされません。

関連項目:

- 「冗長性に基づく保存方針の構成」

- LISTおよびREPORTコマンドの使用方法については、第11章「RMAN操作に関するレポート」を参照してください。

RMANを使用したバックアップ・セットのバックアップ

この項では、BACKUP BACKUPSETコマンドを使用して、バックアップ・セットをディスクからテープにコピーする方法について説明します。この手順では、デフォルト・デバイスとしてSBTデバイスが構成されていることを想定しています。

ディスクからテープにバックアップ・セットをバックアップする手順

1. 使用可能なバックアップ・セットのサブセットをバックアップする場合は、LIST BACKUPSETコマンドを実行してそれらの主キーを取得します。
次の例では、バックアップ・セットをサマリー形式で表示します。

RMAN> LIST BACKUPSET SUMMARY;

List of Backups
===============
Key TY LV S Device Type Completion Time #Pieces #Copies Comp Tag
--- -- -- - ----------- --------------- ------- ------- ---- ---
1   B  F  A DISK        28-MAY-07       1       1       NO   TAG20070528T132432
2   B  F  A DISK        29-MAY-07       1       1       NO   TAG20070529T132433
3   B  F  A DISK        30-MAY-07       1       1       NO   TAG20070530T132434

次の例では、バックアップ・セット3の詳細を表示します。

RMAN> LIST BACKUPSET 3;

List of Backup Sets
===================

BS Key  Type LV Size       Device Type Elapsed Time Completion Time
------- ---- -- ---------- ----------- ------------ ---------------
3       Full    8.33M      DISK        00:00:01     30-MAY-07
BP Key: 3   Status: AVAILABLE  Compressed: NO  Tag: TAG20070530T132434
Piece Name: /disk1/oracle/dbs/c-35764265-20070530-02
Control File Included: Ckp SCN: 397221       Ckp time: 30-MAY-07
SPFILE Included: Modification time: 30-MAY-07
SPFILE db_unique_name: PROD

2. BACKUP BACKUPSETコマンドを実行します。
次の例では、ディスクのすべてのバックアップ・セットをテープにバックアップし、入力のディスク・バックアップを削除します。

BACKUP BACKUPSET ALL
DELETE INPUT;

次の例では、主キー1および2を含むバックアップ・セットのみをテープにバックアップし、入力ディスクのバックアップを削除します。

BACKUP BACKUPSET 1,2
DELETE INPUT;

3. 必要に応じて、LISTコマンドを実行して、バックアップ・セットとバックアップ・ピースのリストを確認します。
BACKUP BACKUPSETによって作成されたバックアップ・ピースのコピーを含むすべてのコピーが出力に含まれます。

RMANを使用したイメージ・コピーのバックアップ

この項では、BACKUPコマンドを使用してイメージ・コピーをテープにバックアップする方法について説明します。デフォルト・デバイスとしてSBTデバイスが構成されていることを想定しています。

データファイルの複数のコピーを含むイメージ・コピーをバックアップする場合は、バックアップにタグを指定すると、入力イメージ・コピーの識別が簡単になります。データファイルのすべてのイメージ・コピーにタグが指定されます。イメージ・コピーが新しいイメージ・コピーとしてバックアップされると、デフォルトで、そのイメージ・コピーのタグが継承されます。

ディスクからテープにイメージ・コピーをバックアップする手順

1. BACKUP ... COPY OFまたはBACKUP DATAFILECOPYコマンドを発行します。
次の例では、タグDBCopyが含まれているデータファイルのコピーをバックアップします。

BACKUP DATAFILE COPY FROM TAG monDBCopy;

次の例では、データベースの最新イメージ・コピーをテープにバックアップし、QUARTERLY_BACKUPというタグを割り当て、入力のディスク・バックアップを削除します。

BACKUP DEVICE TYPE sbt
TAG "quarterly_backup"
COPY OF DATABASE
DELETE INPUT;

2. 必要に応じて、LISTコマンドを発行して、バックアップ・セットのリストを確認します。出力には、BACKUP BACKUPSETコマンドによって作成されたバックアップ・ピースのコピーを含め、すべてのコピーが示されます。

10 データベースのバックアップ: 高度なトピック

この章では、RMANの高度なバックアップ手順について説明します。この章の内容は次のとおりです。

- RMANバックアップ・セットのサイズの制限

- バックアップの最適化を使用したファイルのスキップ

- オフライン・ファイル、読取り専用ファイルおよびアクセスできないファイルのスキップ

- バックアップ・セットの多重化

- RMANを使用したミラーの分割によるバックアップの実行

- RMANバックアップの暗号化

- RMANバックアップの再開

- バックアップ期間の管理

関連項目:
基本的なバックアップ手順については、第9章「データベースのバックアップ」を参照してください。

RMANバックアップ・セットのサイズの制限

「バックアップ・セットの最大サイズの構成」の説明に従ってCONFIGUREコマンドを使用すると、バックアップ・セットのサイズを制御する永続的な設定を作成できます。この制御は、大規模なファイルをバックアップする場合に有効です。バックアップ・セットのサイズを永続的に構成しない場合は、 BACKUP ... MAXSETSIZEコマンドを使用して、バックアップ・セットのサイズを制限することができます。

BACKUPコマンドではなく、CONFIGUREコマンドを使用すると、個々のバックアップ・ピースのサイズに制限を設定できます。この制御は、ファイル・サイズに制限があるメディア・マネージャを使用する場合、または大規模なファイルをバックアップする必要がある場合に特に有効です。詳細は、「バックアップ・ピースの最大サイズの構成」を参照してください。

バックアップ・セットのサイズ

BACKUPコマンドのMAXSETSIZEパラメータには、バイト(デフォルト)、KB、MBまたはGB単位でバックアップ・セットの最大サイズを指定します。したがって、バックアップ・セットのサイズを305MBに制限するには、MAXSETSIZE 305Mと指定します。RMANは、すべてのバックアップ・セットをこのサイズに制限します。

BACKUP ... MAXSETSIZEを使用して、データベースが複数のバックアップ・セットに分割されるように、バックアップ・セットのサイズを制限できます。バックアップの途中で障害が発生した場合は、再開可能バックアップ機能を使用して、前回バックアップされなかったファイルのみをバックアップできます。RMANバックアップを再起動する方法については、「RMANバックアップの再開」を参照してください。

場合によっては、MAXSETSIZEの値が小さすぎて、バックアップ中の最大のファイルを格納できない場合があります。MAXSETSIZEが小さすぎるかどうかを判断する場合、RMANは、圧縮後のファイル・サイズではなく元のデータファイルのサイズを使用します。RMANは、次のようなエラー・スタックを表示します。

RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of backup command at 11/03/06 14:40:33
RMAN-06182: archive log larger than MAXSETSIZE: thread 1 seq 1
/oracle/oradata/trgt/arch/archive1_1.dbf

関連項目:
CONFIGURE MAXSETSIZEコマンドの詳細は、『Oracle Databaseバックアップおよびリカバリ・リファレンス』を参照してください。

BACKUP ... MAXSETSIZEを使用したバックアップ・セットのサイズの制限

バックアップ・ピースのサイズがファイル・システムまたはメディア管理ソフトウェアの最大ファイル・サイズより大きい場合、問題が発生します。バックアップ・ピースのサイズを制限するには、CONFIGURE CHANNELコマンドまたはALLOCATE CHANNELコマンドのMAXSETSIZEパラメータを使用します。

バックアップ・セットのサイズを制限する手順

1. RMANを起動し、ターゲット・データベースおよびリカバリ・カタログ(使用している場合)に接続します。

2. MAXSETSIZEパラメータを指定してBACKUPコマンドを実行します。
次の例では、各バックアップ・セットのサイズを100MBに制限して、アーカイブ・ログをテープにバックアップします。

BACKUP DEVICE TYPE sbt
MAXSETSIZE 100M
ARCHIVELOG ALL;

セクションへの大規模なデータファイルのバックアップの分割

BACKUPコマンドにSECTION SIZEパラメータを指定すると、RMANによって、各バックアップ・ピースに1つのファイル・セクションのブロックが含まれているバックアップ・セットが作成されます。ファイル・セクションとは、ファイル内の連続するブロックの範囲のことです。このタイプのバックアップはマルチセクション・バックアップと呼ばれます。

注意:
SECTION SIZEは、MAXPIECESIZEとともに指定できません。

マルチセクション・バックアップの目的は、RMANチャネルが単一の大規模なファイルをパラレルでバックアップできるようにすることです。RMANは、複数のチャネルに作業を分割し、各チャネルでファイル内の1つのファイル・セクションをバックアップします。個別のセクションでファイルをバックアップすることによって、大規模データファイルのバックアップのパフォーマンスを向上させることができます。

マルチセクション・バックアップが正常に完了した場合は、バックアップ時に生成されたバックアップ・セットに、部分的なデータファイルは含まれません。マルチセクション・バックアップに失敗すると、RMANメタデータに部分的なバックアップ・セットのレコードが含まれる可能性があります。RMANは、部分的なバックアップをリストアおよびリカバリ対象とみなしません。DELETEコマンドを使用して、部分的なバックアップ・セットを削除する必要があります。

ファイルのサイズより大きいセクション・サイズを指定した場合、RMANはファイルのマルチセクション・バックアップを使用しません。小さなセクション・サイズを指定した結果、セクションの数が256を超えると、RMANは、正確に256になる値までセクション・サイズを増やします。

マルチセクション・バックアップを作成する手順

1. RMANを起動し、ターゲット・データベースおよびリカバリ・カタログ(使用している場合)に接続します。

2. 必要に応じて、RMANがバックアップをパラレル化できるように、チャネルのパラレル化を構成します。

3. SECTION SIZEパラメータを指定してBACKUPを実行します。
たとえば、users表領域に900MBの単一のデータファイルが含まれているとします。また、SBTデバイス・セットのパラレル化設定が3に設定され、3つのSBTチャネルが構成されているとします。この表領域内のデータファイルは、次の例に示すようにファイル・セクションに分割できます。

BACKUP
SECTION SIZE 300M
TABLESPACE users;

この例では、3つのSBTチャネルのそれぞれによって、usersデータファイルの300MBのファイル・セクションがバックアップされます。

関連項目:
大規模なデータファイルのセクションを検証する方法については、「データファイルの検証のパラレル化」を参照してください。

バックアップの最適化を使用したファイルのスキップ

「バックアップの最適化およびCONFIGUREコマンド」で説明されているように、CONFIGURE BACKUP OPTIMIZATIONコマンドを実行して、バックアップの最適化を有効にします。特定の条件が満たされている場合、RMANでは、すでにバックアップされているファイルと同一のファイルについてはバックアップをスキップします。

後続の例では、バックアップの最適化および保存方針を次の例のように構成していると想定しています。

例10-1 バックアップの最適化の構成

CONFIGURE DEFAULT DEVICE TYPE TO sbt;
CONFIGURE BACKUP OPTIMIZATION ON;
CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF 4 DAYS;

RMANを例10-1のように構成して、次のコマンドを毎晩実行し、データベースをテープにバックアップします。

BACKUP DATABASE;

バックアップの最適化が構成されているため、リカバリ期間内に最新のバックアップが実行されている場合のみ、RMANは、オフラインおよび読取り専用のデータファイルのバックアップをスキップします。最新のバックアップがリカバリ期間より前に実行されている場合、RMANはバックアップをスキップしません。たとえば、最適化を行うと、読取り専用データファイルを含むバックアップ・セットがリカバリ期間内に1つ存在しているかぎり、このデータファイルの新しいバックアップを毎晩実行する必要がなくなります。

関連項目:

- バックアップの最適化およびリカバリ期間に関連する例は、「リカバリ期間に基づく保存方針によるSBTバックアップのバックアップの最適化」を参照してください。

- ファイルが同一で、スキップできる可能性があるかどうかを判断するためにCONFIGURE BACKUP OPTIMIZATIONで使用される条件の詳細は、『Oracle Databaseバックアップおよびリカバリ・リファレンス』を参照してください。

1つのテープへの毎日のアーカイブ・ログ・バックアップの最適化の例

毎晩すべてのアーカイブ・ログをバックアップすると想定しています。ただし、各ログ順序番号の複数のコピーが作成されないようにします。RMANを例10-1のように構成して、次のコマンドをスクリプトで毎晩午前1時に実行します。

BACKUP DEVICE TYPE sbt
ARCHIVELOG ALL;

RMANは、24時間以内に生成されたログ以外のすべてのログをスキップします。この方法で、各アーカイブ・ログの1つのみのコピーをテープ上に保持できます。

複数のメディア・ファミリへの毎日のアーカイブ・ログ・バックアップの最適化の例

Oracle Secure Backupでは、メディア・ファミリは、共有のユーザー定義属性のセットが含まれている名前付きのボリューム・グループです。この例では、テープ上に存在しないログを1つのメディア・ファミリにバックアップし、同じログを別のメディア・ファミリにバックアップします。最後に、古いログを削除します。

RMANを例10-2に示すように構成して、毎晩同じ時刻に次のスクリプトを実行し、前日に生成されたログを2つの個別のメディア・ファミリにバックアップします。

例10-2 複数のメディア・ファミリへのアーカイブREDOログのバックアップ

# The following command backs up just the logs that are not on tape. The
# first copies are saved to the tapes from the media family "log_family1".
RUN
{
ALLOCATE CHANNEL c1 DEVICE TYPE sbt
PARMS 'ENV=(OB_MEDIA_FAMILY=log_family1)';
BACKUP ARCHIVELOG ALL;
}
# Make one more copy of the archived logs and save them to tapes from a
# different media family
RUN
{
ALLOCATE CHANNEL c2 DEVICE TYPE sbt
PARMS 'ENV=(OB_MEDIA_FAMILY=log_family2)';
BACKUP ARCHIVELOG
NOT BACKED UP 2 TIMES;
}

SBTに2回バックアップしたログをディスクから削除することが目標である場合は、アーカイブREDOログの削除方針を使用する方法が目標を達成する最も簡単な方法です。次のワンタイム構成では、テープに2つのアーカイブ・ログが存在する場合にアーカイブREDOログがディスクからの削除対象となるように指定されます。

CONFIGURE ARCHIVELOG DELETION POLICY
TO BACKED UP 2 TIMES TO DEVICE TYPE sbt;

例10-2のスクリプトを実行した後に、DELETE ARCHIVELOG ALLを実行すると、不要なログを削除できます。

アーカイブ・ログの週ごとのセカンダリ・バックアップの作成の例

アーカイブ・ログを毎日テープにバックアップするための、より高度な例を想定します。ただし、テープ破損を考慮して、週ごとにディスクからログを削除する前に、別々のテープに各ログ順序番号の複数のコピーが作成されるようにします。この例では、データベースで高速リカバリ領域が使用されていないことを想定しています。

まず、ワンタイム構成を次のように実行します。

CONFIGURE BACKUP OPTIMIZATION ON;
CONFIGURE DEVICE TYPE sbt PARALLELISM 1;
CONFIGURE default DEVICE TYPE TO sbt;
CONFIGURE CHANNEL DEVICE TYPE sbt PARMS 'ENV=(OB_MEDIA_FAMILY=first_copy);

最適化を有効にしているため、次のコマンドを毎晩実行して、バックアップされていないすべてのアーカイブ・ログをfirst_copyメディア・ファミリにバックアップできます。

BACKUP ARCHIVELOG ALL TAG first_copy;

毎週金曜日の夜に、すべてのアーカイブ・ログの追加のバックアップを別のメディア・ファミリに作成します。バックアップの終了時に、テープ上に2つ以上のコピーが作成されているすべてのアーカイブ・ログを削除します。これを行うには、次のスクリプトを実行します。

RUN
{
# manually allocate a channel, to specify that the backup run by this
# channel should go to both media families "first_copy" and "second_copy"
ALLOCATE CHANNEL c1 DEVICE TYPE sbt
PARMS 'ENV=(OB_MEDIA_FAMILY=second_copy)';
ALLOCATE CHANNEL c2 DEVICE TYPE sbt
PARMS 'ENV=(OB_MEDIA_FAMILY=first_copy)';
BACKUP
CHANNEL c1
ARCHIVELOG
UNTIL TIME 'SYSDATE'
NOT BACKED UP 2 TIMES # back up only logs without 2 backups on tape
TAG SECOND_COPY;
BACKUP
CHANNEL c2
ARCHIVELOG
UNTIL TIME 'SYSDATE'
NOT BACKED UP 2 TIMES # back up only logs without 2 backups on tape
TAG FIRST_COPY;
}

# now delete from disk all logs that have been backed up to tape at least twice
DELETE
ARCHIVELOG ALL
BACKED UP 2 TIMES TO DEVICE TYPE sbt;

次の表に、日次バックアップ・スクリプトおよび週次バックアップ・スクリプトの効果を示します。

表10-1 日次スクリプトおよび週次スクリプトの効果

スクリプト

スクリプト実行後のテープの内容

スクリプト実行後のディスクの内容

日次

バックアップされていないアーカイブ・ログは、この時点でメディア・ファミリfirst_copyに存在します。

最後にDELETEコマンドを実行した後に作成されたすべてのアーカイブ・ログは、ディスク上に存在します。

週次

テープに2つより少ないバックアップがあるアーカイブ・ログは、この時点でメディア・ファミリfirst_copyおよびsecond_copyに存在します。

2回以上テープにバックアップされたすべてのアーカイブ・ログが削除されます。

週次バックアップの後に、second_copyメディア・ファミリのテープをオフサイトのストレージに送信できます。このテープ・バックアップは、プールfirst_copyのプライマリ・テープが損傷した場合にのみ使用します。セカンダリ・テープはオフサイトに存在するため、RMANでのリカバリには使用しません。そのため、このバックアップには使用不可能のマークを付けることができます。

CHANGE BACKUP OF ARCHIVELOG TAG SECOND_COPY UNAVAILABLE;

関連項目:

- バックアップのステータスを変更する方法およびバックアップを削除する方法については、第12章「RMANバックアップおよびリポジトリ・レコードのメンテナンス」を参照してください。

- CHANGEコマンドおよびDELETEコマンドの詳細は、『Oracle Databaseバックアップおよびリカバリ・リファレンス』を参照してください。

オフライン・ファイル、読取り専用ファイルおよびアクセスできないファイルのスキップ

デフォルトでは、BACKUPコマンドでデータファイルにアクセスできない場合、このコマンドは終了します。表10-2に示すようにパラメータを指定すると、コマンドの終了を回避できます。

表10-2 BACKUP ... SKIPのオプション

指定するパラメータ

RMANによりスキップ...

SKIP INACCESSIBLE

RMANが読み取れないデータファイル。

SKIP OFFLINE

オフラインのデータファイル。一部のオフライン・データファイルは、ディスク上に残っているために読取りが可能です。ディスクから削除または移動されたデータファイルは読み取れないため、アクセス不可能になります。

SKIP READONLY

読取り専用表領域のデータファイル。

次の例では、自動チャネルを使用してデータベースをバックアップし、バックアップ・ジョブを終了させる可能性のあるデータファイルをすべてスキップします。

例10-3 RMANバックアップ時のファイルのスキップ

BACKUP DATABASE
SKIP INACCESSIBLE
SKIP READONLY
SKIP OFFLINE;

バックアップ・セットの多重化

RMANは、バックアップ・セットの最大4つのコピーを同時に作成できます。これらのコピーは、それぞれが完全な複製です。多重バックアップ・セットのコピーは、バックアップ・セットに含まれる各バックアップ・ピースのコピーで、各コピーに一意のコピー番号が付けられます(0tcm8u2s_1_1、0tcm8u2s_1_2など)。バックアップ・セットを高速リカバリ領域に多重化することはできません。

BACKUP ... COPIESまたはCONFIGURE ... BACKUP COPIESを使用して、バックアップ・セットを多重化できます。RMANでは、ディスクまたはテープにバックアップを多重化できますが、テープとディスクにバックアップを同時に多重化することはできません。DISKチャネルの場合は、FORMATオプションで複数の値を指定して、異なる物理ディスクに複数のコピーを作成します。SBTチャネルの場合は、バージョン2のSBT APIをサポートするメディア・マネージャを使用すると、そのメディア・マネージャによって各コピーが自動的に個別のメディア(個別のテープなど)に書き込まれます。テープへのバックアップ時に、コピーの数が、使用可能なテープ・デバイスの数を超えないようにしてください。

多重化はバックアップ・セットにのみ適用され、イメージ・コピーには適用されません。イメージ・コピー・バックアップの作成時にBACKUP ... COPIESを指定すると、エラーが発生します。また、イメージ・コピー・バックアップにCONFIGURE ... BACKUP COPIESを設定しても、この設定は無視されます。

関連項目:
RMANのバックアップ・コピーの概要は、「RMANを使用したバックアップの複数のコピー」を参照してください。

CONFIGURE BACKUP COPIESを使用したバックアップ・セットの多重化

「バックアップの多重化の構成」の説明に従ってCONFIGURE ... BACKUP COPIESコマンドを使用すると、指定したデバイス・タイプに作成する同じバックアップ・セットの数を指定できます。この設定は、制御ファイルの自動バックアップ(制御ファイルの自動バックアップでは常に1つのコピーが生成されるため)およびBACKUP BACKUPSETコマンドを使用してバックアップしたバックアップ・セットを除く、すべてのバックアップ・セットに適用されます。

CONFIGURE ... BACKUP COPIESを使用してバックアップを多重化する手順

1. 任意のデバイス・タイプのデータファイルおよびアーカイブREDOログに対して、任意のデバイス・タイプで作成するコピーの数を構成します。
デフォルトでは、各デバイス・タイプのCONFIGURE ... BACKUP COPIESが1に設定されています。次の例では、データファイルおよびアーカイブ・ログのテープへの多重化、およびデータファイル(アーカイブREDOログは含まない)のディスクへの多重化を構成しています。

CONFIGURE DEVICE TYPE sbt PARALLELISM 1;
CONFIGURE DEFAULT DEVICE TYPE TO sbt;
CONFIGURE CHANNEL DEVICE TYPE DISK FORMAT '/disk1/%U', '/disk2/%U';
CONFIGURE DATAFILE BACKUP COPIES FOR DEVICE TYPE sbt TO 2;
CONFIGURE ARCHIVELOG BACKUP COPIES FOR DEVICE TYPE sbt TO 2;
CONFIGURE DATAFILE BACKUP COPIES FOR DEVICE TYPE DISK TO 2;

2. BACKUPコマンドを実行します。
次のコマンドを実行すると、データベースおよびアーカイブ・ログがテープにバックアップされ、各データファイルおよびアーカイブ・ログのコピーが2つずつ作成されます。

BACKUP AS BACKUPSET DATABASE PLUS ARCHIVELOG;

ディスク・チャネル用のフォーマットが構成されているため、次のコマンドを実行すると、データベースがディスクにバックアップされ、生成されたバックアップ・セットの1つのコピーが/disk1ディレクトリに、もう1つのコピーが/disk2ディレクトリに格納されます。

BACKUP DEVICE TYPE DISK AS BACKUPSET DATABASE;

CONFIGURE CHANNNELにFORMAT句が構成されていない場合は、BACKUPコマンド自体にFORMATを指定します。たとえば、次のコマンドを発行します。

BACKUP AS BACKUPSET DATABASE
FORMAT '/disk1/%U',
'/disk2/%U';

3. LIST BACKUPコマンドを発行して、バックアップ・セットとバックアップ・ピースのリストを確認します。
たとえば、次のコマンドを入力します。

LIST BACKUP SUMMARY;

#Copies列には、多重化または複数のBACKUPコマンドによって生成されたバックアップ・セットの数が表示されます。

関連項目:
CONFIGURE BACKUP COPIESコマンドについては「バックアップの多重化の構成」、基本的なバックアップ構成オプションについては「RMANバックアップの環境の構成」を参照してください。

BACKUP ... COPIESを使用したバックアップ・セットの多重化

BACKUPコマンドのCOPIESオプションは、バックアップ・セットの多重化を制御する他のすべてのCOPIESまたはDUPLEXの設定より優先されます。

BACKUP ... COPIESを使用してバックアップを多重化する手順

1. BACKUPコマンドのCOPIESオプションを指定して、コピーの数を指定します。たとえば、次のコマンドを実行して、デフォルトの場所であるDISKに各バックアップ・セットのコピーを3つずつ作成します。

BACKUP AS BACKUPSET DEVICE TYPE DISK
COPIES 3
INCREMENTAL LEVEL 0
DATABASE;

BACKUPコマンドでCOPIESを指定しているため、CONFIGURE DATAFILE COPIESの設定に関係なく、各データファイルのバックアップ・セットが3つずつ作成されます。

2. LIST BACKUPコマンドを発行して、バックアップ・セットおよびバックアップ・ピースのリストを表示します(#Copies列には、多重化によって、またはBACKUPコマンドを複数回実行することによって生成されたコピーの数が表示されます)。たとえば、次のように入力します。

LIST BACKUP SUMMARY;

RMANを使用したミラーの分割によるバックアップの実行

多くのサイトでは、プライマリ・データベース上でメディア障害が発生したり、ユーザーが不適切な操作を行ってPoint-in-Timeリカバリが必要になった場合のために、データベースのバックアップがディスク上に格納されています。ディスク上のデータファイルのバックアップを使用すると、リカバリのリストア手順が簡単になり、リカバリの速度および信頼性が向上します。

注意:
オンラインREDOログのバックアップは(ミラーの分割または他のいずれの方法を使用しても)実行しないでください。オンラインREDOログのバックアップをリストアすると、順序番号が同じで内容が異なる2つのアーカイブ・ログが作成される場合があります。また、制御ファイルのバックアップを作成する場合は、ミラーの分割のかわりにBACKUP CONTROLFILEコマンドを使用することをお薦めします。

ディスク上にデータファイルのバックアップを作成する方法の1つは、ディスクのミラー化を使用する方法です。たとえば、オペレーティング・システムを使用して、データベースの各ファイルの3つのコピーを保持できます。この構成では、データベースのミラー化されたコピーを分割して、1つのバックアップとして使用できます。

RMANでは、自動的にミラーの分割は行われませんが、バックアップおよびリカバリで分割されたミラーを使用することができます。たとえば、RMANでは、データファイルの分割されたミラーをデータファイルのコピーとして処理し、このコピーをディスクまたはテープにバックアップできます。この項の手順では、ALTER SYSTEM SUSPEND/RESUME機能を使用してミラーの分割によるバックアップを作成する方法について説明します。

一部のミラー化技術では、ミラーを分割してバックアップとして使用する前に、Oracle DatabaseですべてのI/Oを一時停止する必要がありません。データベース・インスタンスでI/Oの一時停止が必要かどうかについては、ストレージ・マネージャ、ボリューム・マネージャまたはファイル・システムのドキュメントを参照してください。

SUSPEND/RESUMEを使用して表領域のミラーの分割によるバックアップを実行する手順

1. RMANを起動し、ALTER TABLESPACE ... BEGIN BACKUP文を使用してバックアップ対象の表領域をバックアップ・モードにします。(すべての表領域をバックアップ・モードにするには、かわりにALTER DATABASE BEGIN BACKUPを使用します。)
たとえば、表領域usersをバックアップ・モードにするには、RMANをターゲット・データベースに接続し、次のSQLコマンドを実行します。

SQL 'ALTER TABLESPACE users BEGIN BACKUP';

2. ミラー化するソフトウェアまたはハードウェアで必要な場合、I/Oを一時停止します。たとえば、RMANで次のコマンドを入力します。

SQL 'ALTER SYSTEM SUSPEND';

3. これらの表領域に含まれている基礎となるデータファイルのミラーを分割します。

4. データベースの一時停止を終了します。たとえば、RMANで次のコマンドを入力します。

SQL 'ALTER SYSTEM RESUME';

5. 表領域のバックアップ・モードを終了します。たとえば、次のように入力します。

SQL 'ALTER TABLESPACE users END BACKUP';

ALTER DATABASE END BACKUPを使用して、すべての表領域のバックアップ・モードを終了することもできます。

6. CATALOGコマンドを使用して、ユーザー管理のミラーのコピーをデータファイルのコピーとしてカタログに追加します。たとえば、次のように入力します。

CATALOG DATAFILECOPY '/dk2/oradata/trgt/users01.dbf'; # catalog split mirror

7. データファイル・コピーをバックアップします。たとえば、プロンプトでBACKUP DATAFILECOPYコマンドを実行します。

BACKUP DATAFILECOPY '/dk2/oradata/trgt/users01.dbf';

8. 分割されたミラーを復元する準備ができたら、最初にCHANGE ... UNCATALOGコマンドを使用して、手順6でカタログに追加したデータファイルのコピーをカタログから削除します。たとえば、次のように入力します。

CHANGE DATAFILECOPY '/dk2/oradata/trgt/users01.dbf' UNCATALOG;

9. 影響を受けたデータファイルの分割されたミラーを復元します。

関連項目:

- 「SUSPENDモードでのユーザー管理バックアップの作成」

- SUSPEND/RESUME機能の詳細は、『Oracle Database管理者ガイド』を参照してください。

- ALTER SYSTEM SUSPENDの構文については、『Oracle Database SQL言語リファレンス』を参照してください。

RMANバックアップの暗号化

「バックアップの暗号化の構成」で説明されているように、バックアップの暗号化でRMANバックアップ・セットを保護できます。暗号化バックアップは、不正なユーザーが取得しても読み取ることができません。RMANバックアップの暗号化機能を使用するには、Enterprise Editionのデータベースが必要です。

RMANバックアップの暗号化設定

バックアップの暗号化は、次のコマンドで指定される暗号化設定に基づいて実行されます。

- CONFIGURE ENCRYPTION
このコマンドを使用すると、透過的暗号化を永続的に構成できます。デュアル・モードまたはパスワード・モードの暗号化は永続的には構成できません。

- SET ENCRYPTION
このコマンドを使用すると、デュアル・モードまたはパスワード・モードの暗号化をRMANセッション・レベルで構成できます。

注意:
ウォレットベースの暗号化は、パスワードが必要ないため、パスワードベースの暗号化より安全です。パスワード・ベースの暗号化は、バックアップをトランスポータブルにする必要があるため、必要な場合のみ使用してください。

データベースでは、各暗号化バックアップに対して新しい暗号化キーが使用されます。バックアップ暗号化キーは、選択した暗号化モードに応じて、パスワードまたはデータベース・マスター・キー(あるいはその両方)を使用して暗号化されます。個々のバックアップ暗号化キーまたはパスワードは、クリアテキストでは格納されません。

1回のリストア操作で、異なるモードで暗号化されたバックアップを処理できます。RMANは、リストアするバックアップ・ピースごとに、それらが暗号化されているかどうかを確認します。透過的に暗号化されているバックアップは、Oracleウォレットがオープンしていて使用可能な場合、ユーザーの介入を必要としません。

パスワードの暗号化が検出された場合、RMANは、SET DECRYPTIONコマンドで入力したパスワードのリスト内の一致するキーを検索します。使用可能なキーが検出された場合、RMANはリストア操作を続行します。検出されなかった場合、RMANはOracleウォレット内のキーを検索します。RMANは、使用可能なキーが検出された場合はリストア操作を続行します。検出されなかった場合はバックアップ・ピースを復号化できないというエラーを通知します。

注意:
異なるパスワードを使用して作成されたバックアップのセットをRMANでリストアする場合は、必要なすべてのパスワードをSET DECRYPTIONに指定する必要があります。

RMANの暗号化はCPUに負荷のかかる操作であり、バックアップのパフォーマンスに影響を及ぼす可能性があります。暗号化の際の実際のCPU使用量は、ディスクおよびSBTの入力デバイスと出力デバイスにおけるデータの作成および消費が、CPUでのデータの暗号化より速いかどうかによって異なります。次に、CPUパフォーマンスを管理し、最大化するためのガイドラインを示します。

- 暗号化バックアップでは、暗号化されていないバックアップの場合より多くのCPUリソースが消費されるため、より多くのRMANチャネルを使用すると、ディスクへの暗号化バックアップのパフォーマンスを向上させることができます。システム内でCPUコアと同じ数のチャネルを使用することをお薦めします。たとえば、デュアルコア・プロセッサには、2つのチャネルを使用します。

- ディスク・サブシステムとSBTサブシステムの両方が高速な場合は、CPU使用率が非常に高くなることが予想されます。必要に応じて、RMANのREADRATEパラメータを設定して、バックアップ・レートの低速化を検討できます。たとえば、ブロックの読取り上限を設定して、RMANで過度のディスク帯域幅が消費され、それによりオンライン・パフォーマンスが低下するのを防止できます。

関連項目:

- パスワード暗号化バックアップをリストアする方法については、「データベースの完全リカバリの実行」を参照してください。

- 「バックアップ・ピースの暗号化ステータスの確認」

- SETコマンドのENCRYPTIONおよびDECRYPTIONオプションの詳細は、『Oracle Databaseバックアップおよびリカバリ・リファレンス』を参照してください。

透過モード暗号化バックアップの作成

「RMANバックアップの暗号化モードの構成」の説明に従って、CONFIGUREコマンドで透過的暗号化を構成してある場合、暗号化バックアップの作成に必要な追加のコマンドはありません。通常どおりに、RMANバックアップを作成します。

パスワード・モード暗号化バックアップの作成

SET ENCRYPTION BY PASSWORDコマンドを実行して、RMANセッションで暗号化パスワードを設定できます。透過的暗号化が構成されている場合は、構成されている透過的暗号化ではなく、パスワードでバックアップを保護することを示すためにONLYキーワードを指定します。

注意:
安全なパスワードを作成してください。詳細は、『Oracle Databaseセキュリティ・ガイド』を参照してください。

パスワード・モード暗号化バックアップを作成する手順

1. RMANを起動し、ターゲット・データベースおよびリカバリ・カタログ(使用している場合)に接続します。

2. SET ENCRYPTION ON IDENTIFIED BY password ONLYコマンドを実行します。
次の例では、バックアップ内のすべての表領域の暗号化パスワード(passwordは実際に入力するパスワードのプレースホルダ)を設定し、暗号化がパスワードのみであることを示すためにONLYを指定しています。

SET ENCRYPTION IDENTIFIED BY password ONLY ON FOR ALL TABLESPACES;

3. データベースをバックアップします。
たとえば、次のコマンドを入力します。

BACKUP DATABASE PLUS ARCHIVELOG;

デュアル・モード暗号化バックアップの作成

RMANプロンプトでSET ENCRYPTION BY PASSWORDコマンドを使用して、パスワード保護されたバックアップを作成します。透過的暗号化が構成されている場合は、パスワードおよび構成されている透過的暗号化でバックアップを保護することを示すためにONLYキーワードを省略します。

注意:
安全なパスワードを作成してください。詳細は、『Oracle Databaseセキュリティ・ガイド』を参照してください。

デュアル・モード暗号化バックアップを作成する手順

1. RMANを起動し、ターゲット・データベースおよびリカバリ・カタログ(使用している場合)に接続します。

2. ONLYキーワードを省略して、SET ENCRYPTION BY PASSWORDコマンドを実行します。
次の例では、バックアップ内のすべての表領域の暗号化パスワード(passwordは実際に入力するパスワードのプレースホルダ)を設定し、デュアル・モードの暗号化を示すためにONLYを省略しています。

SET ENCRYPTION IDENTIFIED BY password ON FOR ALL TABLESPACES;

3. データベースをバックアップします。
たとえば、次のコマンドを入力します。

BACKUP DATABASE PLUS ARCHIVELOG;

RMANバックアップの再開

再開可能バックアップ機能を使用すると、指定した日付以降にバックアップされていないファイルのみをバックアップできます。

再開可能バックアップ

再開可能最小単位はデータファイルです。ただし、バックアップ・セットに1つのバックアップ・ピースが含まれ、このピースに複数のデータファイルからのブロックが含まれている場合、再開可能単位はバックアップ・ピースになります。イメージ・コピーの再開可能単位はデータファイルです。

再開可能バックアップのメリットは、バックアップによって複数のバックアップ・セットが生成される場合、正常に完了したバックアップ・セットを再実行する必要がないことです。ただし、データベース全体が1つのバックアップ・セットに書き込まれる場合、途中でバックアップが失敗すると、バックアップ全体を再開する必要があります。

ファイルの読取り時またはバックアップ・ピースやイメージ・コピーへの書込み時にI/Oエラーが検出された場合、RMANは実行中のバックアップ・ジョブを終了します。たとえば、バックアップを試みたデータファイルがディスク上に存在しなかった場合、バックアップは終了します。ただし、複数のチャネルが使用されていたり、バックアップの冗長コピーが作成されている場合、RMANはユーザーの介入なしにバックアップを続行できる可能性があります。

RMANは、指定した日付以降にバックアップされていないファイルのみをバックアップできます。バックアップが失敗した場合にこの機能を使用すると、失敗したバックアップで処理されなかったデータベースの部分をバックアップできます。

BACKUPコマンドでSINCE TIME句を指定して、バックアップを再開できます。SINCE TIMEに完了時刻より後の値が設定されている場合、RMANはそのファイルをバックアップします。SINCE TIMEパラメータを指定せずにBACKUP DATABASE NOT BACKED UPを使用した場合、RMANは、一度もバックアップされていないファイルのみをバックアップします。

関連項目:
BACKUP ... NOT BACKED UPの構文については、『Oracle Databaseバックアップおよびリカバリ・リファレンス』を参照してください。

部分的に完了したバックアップの再開

BACKUPコマンドのSINCE TIMEパラメータを使用すると、その日付を過ぎると新しいバックアップが必要になる日付を指定できます。SINCE TIMEに完了時刻より後の値が設定されている場合、RMANはそのファイルをバックアップします。SINCE TIMEパラメータを指定せずにBACKUP DATABASE NOT BACKED UPを使用した場合、RMANは、一度もバックアップされていないファイルのみをバックアップします。

指定した日付以降にバックアップされていないファイルのみをバックアップする手順

1. RMANを起動し、ターゲット・データベースおよびリカバリ・カタログ(使用している場合)に接続します。

2. BACKUP ... NOT BACKED UP SINCE TIMEコマンドを実行します。
SINCE TIMEパラメータに有効な日付を指定します。次の例では、デフォルトの構成済チャネルを使用して、過去2週間にバックアップされていないすべてのデータベース・ファイルおよびアーカイブREDOログをバックアップします。

BACKUP
NOT BACKED UP SINCE TIME 'SYSDATE-14'
DATABASE PLUS ARCHIVELOG;

関連項目:
BACKUPコマンドを使用して完了していないバックアップを再開する方法の例については、『Oracle Databaseバックアップおよびリカバリ・リファレンス』を参照してください。

バックアップ期間の管理

この項では、バックアップ期間を使用して、バックアップ・ジョブを完了できる期間の制限を設定する方法について説明します。

バックアップ期間

バックアップ期間とは、バックアップを完了する必要がある時間の長さのことです。たとえば、データベースのバックアップを、システム上のユーザー・アクティビティが低下する時間帯(午前2時から6時など)に制限する場合があります。

RMANは、バックアップの日付が最も古いファイルを最初にバックアップします。デフォルトでは、RMANはファイルを可能なかぎり速くバックアップします。期間を指定しても、期間終了前にバックアップが完了するように通常より速くデータがバックアップされるわけではありません。

デフォルトでは、バックアップがDURATIONの時間内に完了しなかった場合、RMANはバックアップを中断し、エラーを通知します。BACKUPコマンドをRUNコマンド内で使用すると、RUNコマンドは終了します。バックアップ全体が完了しなかった場合でも、バックアップが完了したバックアップ・セットは保持され、リストア操作で使用できます。このため、実行可能な時間が終了して中断されたジョブを再試行すると、試行を繰り返すたびに、バックアップする必要があるファイルの処理が進行していきます。不完全なバックアップ・セットは廃棄されます。

バックアップ期間の指定

BACKUPコマンドのDURATIONパラメータを使用して、特定のバックアップ・ジョブの実行を許可する期間を指定します。

バックアップ期間を指定する手順

1. RMANを起動し、ターゲット・データベースおよびリカバリ・カタログ(使用している場合)に接続します。

2. BACKUP DURATIONコマンドを実行します。
たとえば、次のコマンドを午前2時に実行して、午前6時までバックアップを実行するように指定します。

BACKUP
DURATION 4:00
TABLESPACE users;

関連項目:
BACKUPコマンドの構文については、『Oracle Databaseバックアップおよびリカバリ・リファレンス』を参照してください。

バックアップ期間での部分バックアップの許可

PARTIALを指定すると、RMANは、バックアップ期間が終了してバックアップが中断された場合でも、エラーを通知しません。かわりに、バックアップされていないファイルを示すメッセージを表示します。BACKUPコマンドをRUNブロックで実行している場合、RUNブロック内の残りのコマンドは続行されます。

FILESPERSET 1を指定すると、RMANは各ファイルを独自のバックアップ・セットに格納します。バックアップ期間が終了してバックアップが中断されると、そのときバックアップ中であったファイルのバックアップのみが消失します。時間内に完了したすべてのバックアップ・セットは保存されるため、バックアップ期間の終了によって無効となる処理は最小限で済みます。

バックアップが部分的に完了した場合にRMANがエラーを通知しないようにする手順

1. RMANを起動し、ターゲット・データベースおよびリカバリ・カタログ(使用している場合)に接続します。

2. PARTIALオプションを指定してBACKUP DURATIONコマンドを実行します。
たとえば、次のコマンドを午前2時に実行して、午前6時までバックアップを実行し、各データファイルが個別のバックアップ・セットに格納されるように指定します。

BACKUP
DURATION 4:00 PARTIAL
TABLESPACE users
FILESPERSET 1;

バックアップの負荷および時間の最小化

DURATIONを使用すると、最高のパフォーマンスでバックアップを実行したり、割り当てられた時間内で可能なかぎり低速のバックアップを実行して、パフォーマンスへのバックアップ作業の影響を最小限に抑えることができます。最高のパフォーマンスでバックアップを実行するには、例10-4のように、DURATIONとともにMINIMIZE TIMEオプションを使用します。

例10-4 BACKUP DURATIONでのMINIMIZE TIMEの使用

BACKUP
DURATION 4:00 PARTIAL
MINIMIZE TIME
DATABASE
FILESPERSET 1;

使用可能なすべての時間を使用してバックアップを実行するには、例10-5のように、MINIMIZE LOADオプションを使用します。

例10-5 BACKUP DURATIONでのMINIMIZE LOADの使用

BACKUP
DURATION 4:00 PARTIAL
MINIMIZE LOAD
DATABASE
FILESPERSET 1;

例10-5では、RMANはバックアップの進捗状況を監視し、現在のレートでバックアップの完了に必要な時間を定期的に見積もります。バックアップ期間の終了前にバックアップが終了すると判断した場合、RMANは、使用可能なすべての時間が使用されるように、バックアップのレートを低下させます。これによって、データベースでバックアップに関連するオーバーヘッドが減少します。

DURATIONおよびMINIMIZE LOADをテープ・バックアップで使用する場合は、次の事項に注意してください。

- テープへの効率的なバックアップには、テープ・ストリームが必要です。MINIMIZE LOADを使用すると、RMANがバックアップのレートを低下させ、テープ・ストリームが最適ではなくなる場合があります。

- RMANは、バックアップ期間中、常にテープ・リソースを保持します。このため、バックアップ期間中は、テープ・リソースを他の目的に使用できません。

これらの点から、テープへのバックアップ時にはMINIMIZE LOADを使用しないことをお薦めします。

関連項目:
効率的なテープ処理の詳細は、「SBTへの書込みフェーズにおけるメディア・マネージャの構成要素」を参照してください。

第IV部

RMANのバックアップの管理

次の章では、RMANバックアップを管理する方法について説明します。この部に含まれる章は、次のとおりです。

- 第11章「RMAN操作に関するレポート」

- 第12章「RMANバックアップおよびリポジトリ・レコードのメンテナンス」

- 第13章「リカバリ・カタログの管理」

11 RMAN操作に関するレポート

この章では、RMAN操作に関してレポートする方法について説明します。この章の内容は次のとおりです。

- RMANレポートの概要

- バックアップおよびリカバリ関連オブジェクトの表示

- バックアップおよびデータベース・スキーマに関するレポート

- V$ビューを使用したバックアップ・メタデータの問合せ

- リカバリ・カタログ・ビューの問合せ

RMANレポートの概要

この項では、RMANレポートの目的および基本的な概念について説明します。

RMANレポートの目的

バックアップおよびリカバリ計画の一部として、バックアップした内容を示すレポートを定期的に実行する必要があります。バックアップが必要なデータファイルまたは最近バックアップされていないファイルを確認しておく必要があります。また、問題発生時にRMANでリストアする必要があるバックアップをプレビューすることもできます。

バックアップおよびリカバリのもう1つ重要な側面は、領域の使用状況の監視です。ディスクにバックアップする場合は、そのディスクが一杯になる可能性があるため、パフォーマンス上の問題が発生したり、データベースが停止することもあります。RMANを使用すると、バックアップが不要なバックアップで、削除可能かどうかを確認できます。

また、RMANジョブについての履歴情報を取得する必要がある場合もあります。たとえば、発行されたバックアップ・ジョブの数、各バックアップ・ジョブのステータス(失敗したか完了したかなど)、ジョブの開始日時と終了日時、および実行されたバックアップのタイプについて確認する必要がある場合があります。

RMANレポートの基本的な概念

RMANは、操作の実行対象となる各ターゲット・データベースの制御ファイルに、メタデータのRMANリポジトリを常に格納します。たとえば、RMANを使用して、prod1およびprod2データベースをバックアップするとします。RMANは、prod1のバックアップ用メタデータをprod1の制御ファイルに、prod2のバックアップ用メタデータをprod2の制御ファイルに格納します。

必要に応じて、リカバリ・カタログとともにRMANを使用できます。この場合、RMANは、別のリカバリ・カタログ・データベース内の一連の表に、追加のメタデータ・リポジトリを保持します。たとえば、prod3にリカバリ・カタログを作成するとします。このリカバリ・カタログには、複数のターゲット・データベースを登録できます。たとえば、prod1およびprod2をprod3に格納されているリカバリ・カタログに登録すると、RMANは、prod1およびprod2のバックアップに関するメタデータをリカバリ・カタログ・スキーマに格納します。

次に示す様々な方法で、RMANリポジトリからメタデータにアクセスできます。

- RMANのLISTおよびREPORTコマンドでは、使用可能なバックアップと、データベースをリストアおよびリカバリするためにそれをどのように使用できるかという詳細な情報が提供されます。
LISTコマンドについては「バックアップおよびリカバリ関連オブジェクトの表示」、REPORTについては「バックアップおよびデータベース・スキーマに関するレポート」を参照してください。

- データベースがオープンしている場合は、いくつかのV$ビューによって、各ターゲット・データベースの制御ファイル内にあるRMANリポジトリ・レコードに直接アクセスできます。
V$DATAFILE_HEADER、V$PROCESS、V$SESSIONなどの一部のV$ビューには、リカバリ・カタログ・ビューにはない情報が含まれています。V$ビューの詳細は、『Oracle Databaseリファレンス』を参照してください。

- データベースがリカバリ・カタログに登録されている場合は、RC_ビューによって、リカバリ・カタログに格納されているRMANリポジトリ・データに直接アクセスできます。
RC_ビューは、V$ビューとほぼ対応しています。RC_ビューの詳細は、『Oracle Databaseバックアップおよびリカバリ・リファレンス』を参照してください。

- RESTORE ... PREVIEWおよびRESTORE ... VALIDATE HEADERコマンドでは、指定した時間までRMANでリストア可能なバックアップが表示されます。
RESTORE ... PREVIEWは、メタデータを問い合せますが、バックアップ・ファイルを読み取りません。RESTORE ... VALIDATE HEADERコマンドでも同じ操作が実行されますが、リストアおよびリカバリ操作に必要なファイルの表示の他に、ディスク上またはメディア管理カタログ内のファイルがRMANリポジトリのメタデータに対応しているかどうかを確認するためにバックアップ・ファイル・ヘッダーが検証されます。これらのコマンドについては、「リストア操作で使用されるバックアップのプレビュー」を参照してください。

第12章「RMANバックアップおよびリポジトリ・レコードのメンテナンス」で説明されているように、RMANリポジトリがディスクおよびテープ上の実情を反映していない場合があります。たとえば、ユーザーがオペレーティング・システムのユーティリティを使用してバックアップを削除した場合、そのバックアップは、RMANリポジトリでは誤って使用可能と表示されます。

CHANGE、CROSSCHECK、DELETEなどのコマンドを使用すると、使用可能なバックアップの実際の状態を反映してRMANリポジトリを更新できます。そうしない場合、コマンドおよびビューの出力が誤って表示され、データベースをリストアおよびリカバリするためのバックアップをRMANで検出できない可能性があります。

関連項目:

- RMANリポジトリを最新の状態に保つ方法については、「RMANリポジトリのクロスチェック」を参照してください。

- LISTの構文については、『Oracle Databaseバックアップおよびリカバリ・リファレンス』を参照してください。

- REPORTの構文については、『Oracle Databaseバックアップおよびリカバリ・リファレンス』を参照してください。

- RESTOREの構文については、『Oracle Databaseバックアップおよびリカバリ・リファレンス』を参照してください。

Data Guard環境でのレポート

「Data Guard環境でのRMANによるファイル管理」で説明されているように、すべてのバックアップがそのバックアップを作成したプライマリ・データベースまたはスタンバイ・データベースに関連付けられています。たとえば、standby1のDB_UNIQUE_NAMEを使用してデータベースをバックアップすると、standby1データベースがこのバックアップに関連付けられます。

Data Guard環境では、Data Guardを使用しない場合と同様に、LIST、REPORTおよびSHOWコマンドを使用できます。FOR DB_UNIQUE_NAME句を指定してこれらのコマンドを実行すると、指定したデータベースに関連付けられているバックアップを表示できます。たとえば、次のコマンドでは、sfstandbyにのみ関連付けられているアーカイブREDOログが表示されます。

LIST ARCHIVELOG ALL FOR DB_UNIQUE_NAME sfstandby;

Data Guard環境でFOR DB_UNIQUE_NAME句を指定せずにLIST、REPORTおよびSHOWコマンドを使用すると、RMANによって、ターゲット・データベースでアクセス可能なファイルが表示されます。RMANでバックアップにアクセス可能であるとみなされる場合については、「Data Guard環境でのバックアップの関連付け」を参照してください。

Data Guard環境では、RMANをリカバリ・カタログとともに使用する必要があります。RMANでは、すべてのバックアップおよびリカバリ・ファイルのメタデータがリカバリ・カタログのData Guard環境に格納されます。RMANのレポート・コマンドの実行時に、マウントまたはオープンされているデータベースにRMANをTARGETとして接続するか、またはSET DBIDコマンドを使用してデータベースを識別することができます。

関連項目:
Data Guard環境でRMAN操作に関してレポートする方法については、『Oracle Data Guard概要および管理』を参照してください。

バックアップおよびリカバリ関連オブジェクトの表示

LISTコマンドは、RMANリポジトリの情報を使用して、バックアップやバックアップとリカバリに関連するその他のオブジェクトのリストを表示します。この項の内容は、次のとおりです。

- LISTコマンド

- すべてのバックアップおよびコピーの表示

- 選択したバックアップおよびコピーの表示

- データベース・インカネーションの表示

LISTコマンド

LISTコマンドの主な目的は、バックアップおよびコピーを表示することです。たとえば、次の内容を表示できます。

- データベース、表領域、データファイル、アーカイブREDOログまたは制御ファイルのバックアップおよびプロキシ・コピー

- 期限切れのバックアップ

- 時間、パス名、デバイス・タイプまたはリカバリ可能性で制限されているバックアップ

- アーカイブREDOログ・ファイルおよびディスク・コピー

RMANでは、バックアップおよびコピーのみでなく、他のタイプのデータも表示できます。表11-1に、表示できる有効なオブジェクトをいくつか示します。

表11-1 LISTの対象となるオブジェクト

リストの内容

コマンド

説明

バックアップ・セットおよびプロキシ・コピー

LIST BACKUP

データベース、表領域、データファイル、アーカイブREDOログ、制御ファイルまたはサーバー・パラメータ・ファイルのすべてのバックアップ・セット、コピーおよびプロキシ・コピーを表示できます。

イメージ・コピー

LIST COPY

データファイル・コピーおよびアーカイブREDOログ・ファイルを表示できます。デフォルトでは、LIST COPYによってすべてのデータベース・ファイルおよびアーカイブREDOログのコピーが表示されます。出力には、リストアできないイメージ・コピー、期限切れのイメージ・コピーまたは使用不可能なイメージ・コピーも含め、使用可能なイメージ・コピーおよび使用不可能なイメージ・コピーの両方が含まれます。

アーカイブREDOログ・ファイル

LIST ARCHIVELOG

アーカイブREDOログ・ファイルを表示できます。すべてのアーカイブREDOログ・ファイルを表示するか、SCN、時刻または順序番号の範囲で個々のアーカイブ・ログ・ファイルを指定できます。範囲を指定すると、インカネーション番号を指定することによって戻されるリストをさらに制限できます。

データベース・インカネーション

LIST INCARNATION

データベースのすべてのインカネーションを表示できます。RESETLOGSオプションを使用してオープンすると、新しいデータベース・インカネーションが作成されます。

Data Guard環境のデータベース

LIST DB_UNIQUE_NAME

Data Guard環境のデータベースは、そのDB_UNIQUE_NAME初期化パラメータ設定によって識別されます。同じDBIDを持つすべてのデータベースを表示できます。

Data Guard環境のプライマリ・データベースまたはスタンバイ・データベースのバックアップおよびコピー

LIST ... FOR DB_UNIQUE_NAME

Data Guard環境内の指定したデータベースまたはすべてのデータベースのすべてのバックアップおよびコピーを表示できます。

RMANでは、指定したDB_UNIQUE_NAMEを持つデータベースに排他的に関連付けられているファイルまたはオブジェクトに出力が制限されます。たとえば、FOR DB_UNIQUE_NAMEを指定してLISTを使用すると、特定のスタンバイ・データベースまたはプライマリ・データベースに関連付けられているアーカイブREDOログのリストを表示できます。データベースによって所有されていないオブジェクト(リカバリ・カタログ・ビューのSITE_KEY列がNULL)は表示されません。

リストア・ポイント

LIST RESTORE POINT

RMANリポジトリで認識されるリストア・ポイントを表示できます。

ストアド・スクリプトの名前

LIST SCRIPT NAMES

CREATE SCRIPTまたはREPLACE SCRIPTコマンドを使用して作成されたリカバリ・カタログ・スクリプトの名前を表示できます。リカバリ・カタログが必要です。

データ・リカバリ・アドバイザとともに使用する場合の障害

LIST FAILURE

障害とは、修復オプションにマッピングされている永続的なデータの破損のことです。ADVISEおよびREPAIRコマンドとともにLIST FAILUREを使用する方法については、第15章「データ・リカバリ・アドバイザを使用した障害の診断および修復」を参照してください。

LISTコマンドでは、出力の表示方法を制御できるいくつかのオプションがサポートされています。表11-2に、最も一般的なLISTのオプションを示します。

表11-2 最も一般的なLISTのオプション

LISTのオプション

説明

LIST EXPIRED

RMANリポジトリに記録されているバックアップまたはコピーで、最後にクロスチェックを実行したときに、ディスクまたはテープ上の予測した位置に存在しなかったものを表示します。このようなバックアップは、RMANの外部で削除された可能性があります。

LIST ... BY FILE

各データファイル、アーカイブREDOログ・ファイル、制御ファイルおよびサーバー・パラメータ・ファイルのバックアップを表示します。各行にファイルのバックアップの説明が示されます。

LIST ... SUMMARY

各バックアップの1行のサマリーを表示します。

前述の表に、すべてのLISTオブジェクトおよびオプションが示されているわけではありません。たとえば、時間、パス名、デバイス・タイプ、タグまたはリカバリ可能性で制限されたバックアップを表示できます。

関連項目:
LISTコマンドの詳細は、『Oracle Databaseバックアップおよびリカバリ・リファレンス』を参照してください。

すべてのバックアップおよびコピーの表示

listObjListまたはrecordSpec句(『Oracle Databaseバックアップおよびリカバリ・リファレンス』を参照)を使用して、必要なオブジェクトを指定します。オブジェクトを指定しないと、RMANは、すべてのデータベース・ファイルとアーカイブREDOログ・ファイルのコピーを表示します。

デフォルトでは、RMANは、各バックアップまたはプロキシ・コピーを連続して表示した後、そのバックアップに含まれているファイルを識別します。また、ファイルごとにバックアップを表示することもできます。

デフォルトでは、RMANは冗長モードで表示を行います。つまり、様々な情報を複数行にわたって表示します。冗長モードによる出力が多すぎる場合は、サマリー・モードでバックアップを表示することもできます。

バックアップおよびコピーを表示する手順

1. RMANを起動し、ターゲット・データベースおよびリカバリ・カタログ(使用している場合)に接続します。

2. すべてのバックアップおよびコピーのサマリー・レポートを表示するには、SUMMARYオプションを指定してLISTコマンドを実行します。
次のコマンドを実行すると、すべてのRMANバックアップのサマリーが出力されます。

LIST BACKUP SUMMARY;

出力例を次に示します。

List of Backups
===============
Key     TY LV S Device Type Completion Time #Pieces #Copies Compressed Tag
------- -- -- - ----------- --------------- ------- ------- ---------- ---
1       B  A  A SBT_TAPE    21-OCT-07       1       1       NO         TAG20071021T094505
2       B  F  A SBT_TAPE    21-OCT-07       1       1       NO         TAG20071021T094513
3       B  A  A SBT_TAPE    21-OCT-07       1       1       NO         TAG20071021T094624
4       B  F  A SBT_TAPE    21-OCT-07       1       1       NO         TAG20071021T094639
5       B  F  A DISK        04-NOV-07       1       1       YES        TAG20071104T195949

3. バックアップおよびコピーの詳細な出力を表示するには、SUMMARYオプションを指定せずにLISTコマンドを実行します。
次のコマンドを実行すると、デフォルトの詳細な出力でRMANバックアップおよびコピーが表示されます。

LIST BACKUP;
LIST COPY;

LIST BACKUPおよびLIST COPYの出力例を次に示します。

List of Backup Sets
===================

BS Key  Size       Device Type Elapsed Time Completion Time
------- ---------- ----------- ------------ ---------------
7       136M       DISK        00:00:20     04-NOV-06
BP Key: 7   Status: AVAILABLE  Compressed: NO  Tag: TAG20071104T200759
Piece Name: /d2/RDBMS/backupset/2007_11_04/o1_mf_annnn_TAG20071104T200759_ztjxx3k8_.bkp

List of Archived Logs in backup set 7
Thrd Seq     Low SCN    Low Time  Next SCN   Next Time
---- ------- ---------- --------- ---------- ---------
1    1       173832     21-OCT-06 174750     21-OCT-06
1    2       174750     21-OCT-06 174755     21-OCT-06
1    3       174755     21-OCT-06 174758     21-OCT-06

BS Key  Type LV Size       Device Type Elapsed Time Completion Time
------- ---- -- ---------- ----------- ------------ ---------------
8       Full    2M         DISK        00:00:01     04-NOV-06
BP Key: 8   Status: AVAILABLE  Compressed: NO  Tag: TAG20071104T200829
Piece Name: /disk1/oracle/dbs/c-774627068-20071104-01
Controlfile Included: Ckp SCN: 631510       Ckp time: 04-NOV-06
SPFILE Included: Modification time: 21-OCT-06

List of Datafile Copies
=======================

Key     File S Completion Time Ckp SCN    Ckp Time
------- ---- - --------------- ---------- ---------------
1       7    A 11-OCT-06       360072     11-OCT-06
Name: /work/orcva/RDBMS/datafile/o1_mf_tbs_2_2lv7bf82_.dbf
Tag: DF7COPY

2       8    A 11-OCT-06       360244     11-OCT-06
Name: /work/orcva/RDBMS/datafile/o1_mf_tbs_2_2lv7qmcj_.dbf
Tag: TAG20071011T184835

List of Control File Copies
===========================

Key     S Completion Time Ckp SCN    Ckp Time
------- - --------------- ---------- ---------------
3       A 11-OCT-06       360380     11-OCT-06
Name: /d2/RDBMS/controlfile/o1_mf_TAG20071011T185335_2lv80zqd_.ctl
Tag: TAG20071011T185335

List of Archived Log Copies for database with db_unique_name RDBMS
=====================================================================

Key     Thrd Seq     S Low Time
------- ---- ------- - ---------
1       1    1       A 11-OCT-06
Name: /work/arc_dest/arcr_1_1_603561743.arc

2       1    2       A 11-OCT-06
Name: /work/arc_dest/arcr_1_2_603561743.arc

3       1    3       A 11-OCT-06
Name: /work/arc_dest/arcr_1_3_603561743.arc

4. ファイルごとにバックアップを表示するには、表示するオブジェクトおよびオプションをBY FILEオプションとともに指定してLISTを実行します。たとえば、次のように入力します。

LIST BACKUP BY FILE;

出力例を次に示します。

List of Datafile Backups
========================

File Key     TY LV S Ckp SCN    Ckp Time  #Pieces #Copies Compressed Tag
---- ------- -  -- - ---------- --------- ------- ------- ---------- ---
1    5       B  F  A 631092     04-NOV-06 1       1       YES        TAG20071104T195949
2       B  F  A 175337     21-OCT-06 1       1       NO         TAG20071021T094513
2    5       B  F  A 631092     04-NOV-06 1       1       YES        TAG20071104T195949
2       B  F  A 175337     21-OCT-06 1       1       NO         TAG20071021T094513

... some rows omitted

List of Archived Log Backups
============================

Thrd Seq     Low SCN    Low Time  BS Key  S #Pieces #Copies Compressed Tag
---- ------- ---------- --------- ------- - ------- ------- ---------- ---
1    1       173832     21-OCT-06 7       A 1       1       NO         TAG20071104T200759
1       A 1       1       NO         TAG20071021T094505
1    2       174750     21-OCT-06 7       A 1       1       NO         TAG20071104T200759
1       A 1       1       NO         TAG20071021T094505
... some rows omitted
1    38      575472     03-NOV-06 7       A 1       1       NO         TAG20071104T200759
1    39      617944     04-NOV-06 7       A 1       1       NO         TAG20071104T200759

List of Controlfile Backups
===========================
CF Ckp SCN Ckp Time  BS Key  S #Pieces #Copies Compressed Tag
---------- --------- ------- - ------- ------- ---------- ---
631510     04-NOV-06 8       A 1       1       NO         TAG20071104T200829
631205     04-NOV-06 6       A 1       1       NO         TAG20071104T200432

List of SPFILE Backups
======================
Modification Time BS Key  S #Pieces #Copies Compressed Tag
----------------- ------- - ------- ------- ---------- ---
21-OCT-06         8       A 1       1       NO         TAG20071104T200829
21-OCT-06         6       A 1       1       NO         TAG20071104T200432

関連項目:
LIST出力の様々な列ヘッダーについては、『Oracle Databaseバックアップおよびリカバリ・リファレンス』を参照してください。

選択したバックアップおよびコピーの表示

様々な条件を指定して、LIST出力を制限できます。

選択したバックアップおよびコピーを表示する手順

1. RMANを起動し、ターゲット・データベースおよびリカバリ・カタログ(使用している場合)に接続します。

2. listObjListまたはrecordSpec句を指定して、LIST COPYまたはLIST BACKUPを実行します。たとえば、次のいずれかのコマンドを実行します。

# lists backups of all files in database
LIST BACKUP OF DATABASE;
# lists copy of specified datafile
LIST COPY OF DATAFILE 'ora_home/oradata/trgt/system01.dbf';
# lists specified backup set
LIST BACKUPSET 213;
# lists datafile copy
LIST DATAFILECOPY '/tmp/tools01.dbf';

maintQualifierまたはRECOVERABLE句を指定して、検索を制限することもできます。たとえば、次のいずれかのコマンドを実行します。

# specify a backup set by tag
LIST BACKUPSET TAG 'weekly_full_db_backup';
# specify a backup or copy by device type
LIST COPY OF DATAFILE 'ora_home/oradata/trgt/system01.dbf' DEVICE TYPE sbt;
# specify a backup by directory or path
LIST BACKUP LIKE '/tmp/%';
# specify a backup or copy by a range of completion dates
LIST COPY OF DATAFILE 2 COMPLETED BETWEEN '10-DEC-2002' AND '17-DEC-2002';
# specify logs backed up at least twice to tape
LIST ARCHIVELOG ALL BACKED UP 2 TIMES TO DEVICE TYPE sbt;

3. 出力を確認します。
出力は、LISTコマンドに指定したオプションによって異なります。たとえば、次のコマンドでは、バックアップ・セットに含まれるデータファイル1のコピーが表示されます。

RMAN> LIST BACKUP OF DATAFILE 1;

List of Backup Sets
===================

BS Key  Type LV Size       Device Type Elapsed Time Completion Time
------- ---- -- ---------- ----------- ------------ ---------------
2       Full    230M       SBT_TAPE    00:00:49     21-OCT-06
BP Key: 2   Status: AVAILABLE  Compressed: NO  Tag: TAG20071021T094513
Handle: 02f4eatc_1_1   Media: /smrdir
List of Datafiles in backup set 2
File LV Type Ckp SCN    Ckp Time  Name
---- -- ---- ---------- --------- ----
1       Full 175337     21-OCT-06 /oracle/dbs/tbs_01.f

BS Key  Type LV Size       Device Type Elapsed Time Completion Time
------- ---- -- ---------- ----------- ------------ ---------------
5       Full    233M       DISK        00:04:30     04-NOV-06
BP Key: 5   Status: AVAILABLE  Compressed: NO  Tag: TAG20071104T195949
Piece Name: /disk1/2007_11_04/o1_mf_nnndf_TAG20071104T195949_ztjxfvgz_.bkp
List of Datafiles in backup set 5
File LV Type Ckp SCN    Ckp Time  Name
---- -- ---- ---------- --------- ----
1       Full 631092     04-NOV-06 /oracle/dbs/tbs_01.f

関連項目:

- listObjListおよびrecordSpecの構文については、『Oracle Databaseバックアップおよびリカバリ・リファレンス』を参照してください。

- LIST出力の列については、『Oracle Databaseバックアップおよびリカバリ・リファレンス』を参照してください。

データベース・インカネーションの表示

データベースに対してOPEN RESETLOGS操作を実行するたびに、新しいデータベース・インカネーションが作成されます。データベース・インカネーションと、それによってデータベース・リカバリが受ける影響については、「データベース・インカネーション」を参照してください。

増分バックアップの実行時、RMANは、前回のインカネーションまたは現行のインカネーションからのバックアップを、後続の増分バックアップの基礎として使用できます。リストアおよびリカバリ操作の実行時、すべてのアーカイブ・ログが使用可能であれば、RMANは、現行のインカネーションからのバックアップを使用するのと同様に、前回のインカネーションからのバックアップを使用できます。

データベース・インカネーションを表示する手順

1. RMANを起動し、ターゲット・データベースおよびリカバリ・カタログ(使用している場合)に接続します。

2. 次の例に示すように、LIST INCARNATIONコマンドを実行します。

LIST INCARNATION;

リカバリ・カタログを使用している場合、および同じカタログに複数のターゲット・データベースを登録している場合は、OF DATABASEオプションを使用して、それらを区別することができます。

LIST INCARNATION OF DATABASE prod3;

LIST出力の様々な列ヘッダーについては、『Oracle Databaseバックアップおよびリカバリ・リファレンス』を参照してください。出力例を次に示します。

RMAN> LIST INCARNATION OF DATABASE trgt;

List of Database Incarnations
DB Key  Inc Key DB Name  DB ID            STATUS  Reset SCN  Reset Time
------- ------- -------- ---------------- ------  ---------- ----------
1       1       RDBMS    774627068        PARENT  1          21-OCT-06
2       2       RDBMS    774627068        CURRENT 173832     21-OCT-06

この出力例では、RESETLOGS操作が、SCN 164378でデータベースtrgtに対して実行され、新しいインカネーションが作成されたことが示されています。インカネーションは、インカネーション・キー(Inc Key列)で区別されます。

バックアップおよびデータベース・スキーマに関するレポート

RMANのREPORTコマンドを使用すると、使用可能なバックアップおよびデータベースが分析されます。この項の内容は、次のとおりです。

- RMANバックアップに関するレポート

- 保存方針に基づくバックアップが必要なファイルに関するレポート

- リカバリ不能な操作によって影響を受けるデータファイルに関するレポート

- 不要なバックアップに関するレポート

- データベース・スキーマに関するレポート

RMANバックアップに関するレポート

REPORTコマンドを使用すると、次の重要な質問に回答することができます。

- バックアップが必要なファイルはどれですか。

- リカバリ不能な操作を実行したファイルはどれですか。

- 不要なため削除可能なバックアップはどれですか。

- 過去のある時点でのターゲット・データベースまたはData Guard環境のデータベースの物理スキーマは何ですか。

- 最近バックアップされていないファイルはどれですか。

レポートを使用すると、バックアップおよびリカバリ計画が実際にデータベースのリカバリ可能性の要件を満たしていることを確認できます。データベースがリカバリ可能であるかどうかを判断するために使用するREPORTには、主に次の2つの形式があります。

- REPORT NEED BACKUP
構成済の保存方針または指定した保存方針を満たすためにバックアップする必要があるデータベース・ファイルがレポートされます。

- REPORT UNRECOVERABLE
ダイレクト・パス・インサートなどのNOLOGGING操作の影響を受けているためバックアップを必要とするデータベース・ファイルがレポートされます。

RMANリポジトリには、REPORTコマンドを使用してアクセスできる他の情報が含まれています。REPORTのオプションの概要は、表11-3を参照してください。

表11-3 REPORTのオプション

レポートの内容

コマンド

説明

不要なバックアップ

REPORT OBSOLETE

RMANリポジトリに記録され、不要になったため削除できる全体バックアップ、データファイルのコピーおよびアーカイブREDOログ

データベース・スキーマ

REPORT SCHEMA

指定した時点のターゲット・データベースに対するすべてのデータファイル(永続的および一時的)および表領域の名前。Data Guard環境でRMANを使用する場合は、指定したDB_UNIQUE_NAMEのスキーマをレポートできます。

関連項目:
REPORTコマンドの詳細は、『Oracle Databaseバックアップおよびリカバリ・リファレンス』を参照してください。

保存方針に基づくバックアップが必要なファイルに関するレポート

REPORT NEED BACKUPコマンドを使用して、特定の保存方針に基づくバックアップが必要なデータベース・ファイルを判断します。

引数を指定せずにREPORT NEED BACKUPを実行すると、現行の保存方針でバックアップが必要なオブジェクトがレポートされます。REDUNDANCY 1に設定されている構成済の保存方針の出力は、次の例のようになります。

RMAN> REPORT NEED BACKUP;

RMAN retention policy will be applied to the command
RMAN retention policy is set to redundancy 1
Report of files with less than 1 redundant backups
File #bkps Name
---- ----- -----------------------------------------------------
2    0     /oracle/oradata/trgt/undotbs01.dbf

注意:
CONFIGURE RETENTION POLICY TO NONEを使用して保存方針を無効にしている場合、REPORT NEED BACKUPはエラー・メッセージを戻します。これは、保存方針がないと、RMANはバックアップする必要のあるファイルを決定できないためです。

様々な保存方針でのRMANのREPORT NEED BACKUPの使用

次のいずれかの形式のコマンドを使用して、REPORT NEED BACKUPに様々な条件を指定できます。

- REPORT NEED BACKUP RECOVERY WINDOW OF n DAYS
バックアップがリカバリ期間ベースの保存方針を満たす必要があるオブジェクトが表示されます

- REPORT NEED BACKUP REDUNDANCY n
バックアップが冗長性ベースの保存方針を満たす必要があるオブジェクトが表示されます

- REPORT NEED BACKUP DAYS n
リカバリ用にn日分より多いアーカイブREDOログを必要とするファイルが表示されます

- REPORT NEED BACKUP INCREMENTAL n
リカバリ用にn個より多い増分バックアップの適用を必要とするファイルが表示されます

表領域およびデータファイルでのRMANのREPORT NEED BACKUPの使用

REPORT NEED BACKUPコマンドを使用して、データベース全体の確認、指定された表領域のスキップ、または様々な保存方針に対する特定の表領域またはデータファイルのみの確認を行うことができます。次に例を示します。

REPORT NEED BACKUP RECOVERY WINDOW OF 2 DAYS DATABASE SKIP TABLESPACE TBS_2;
REPORT NEED BACKUP REDUNDANCY 2 DATAFILE 1;
REPORT NEED BACKUP TABLESPACE TBS_3; # uses configured retention policy
REPORT NEED BACKUP INCREMENTAL 2; # checks entire database

関連項目:
REPORT NEED BACKUPの使用可能なすべてのオプションおよび出力の様々な列ヘッダーについては、『Oracle Databaseバックアップおよびリカバリ・リファレンス』を参照してください。

テープまたはディスク上のバックアップのみでのREPORT NEED BACKUPの使用

REPORT NEED BACKUPコマンドでテストするバックアップをディスクベースまたはテープベースのバックアップのみに制限できます。次に例を示します。

REPORT NEED BACKUP RECOVERY WINDOW OF 2 DAYS DATABASE DEVICE TYPE sbt;
REPORT NEED BACKUP DEVICE TYPE DISK;
REPORT NEED BACKUP TABLESPACE TBS_3 DEVICE TYPE sbt;

リカバリ不能な操作によって影響を受けるデータファイルに関するレポート

ダイレクト・ロード・インサートなどのリカバリ不能な操作によってデータファイルが変更されている場合、リカバリ不能な操作ではREDOが生成されないため、通常のメディア・リカバリを使用してファイルをリカバリすることはできません。このような操作の後に影響を受けるデータファイルの全体バックアップまたは増分バックアップのいずれかを実行して、リカバリ不能な操作の影響を受けるデータ・ブロックをRMANを使用してリカバリできるようにする必要があります。

リカバリ不能な操作の影響を受けるデータファイルを識別する手順

1. RMANを起動し、ターゲット・データベースおよびリカバリ・カタログ(使用している場合)に接続します。

2. REPORT UNRECOVERABLEコマンドを実行します。
出力例を次に示します。

RMAN> REPORT UNRECOVERABLE;

Report of files that need backup due to unrecoverable operations
File Type of Backup Required Name
---- ----------------------- -----------------------------------
1    full                    /oracle/oradata/trgt/system01.dbf

不要なバックアップに関するレポート

OBSOLETEキーワードを指定すると、不要な(指定した保存方針を満たす必要がない)バックアップ・セット、バックアップ・ピースおよびデータファイルのコピーをレポートできます。

不要なバックアップをレポートする手順

1. RMANを起動し、ターゲット・データベースおよびリカバリ・カタログ(使用している場合)に接続します。

2. CROSSCHECKコマンドを実行して、ディスク上のバックアップのステータスと比較してリポジトリのバックアップのステータスを更新します。
最も簡単な方法としては、次のいずれかのコマンドを使用して、ディスクまたはテープ(あるいはその両方)上のすべてのバックアップをクロスチェックすることができます。

CROSSCHECK BACKUP DEVICE TYPE DISK;
CROSSCHECK BACKUP DEVICE TYPE sbt;
CROSSCHECK BACKUP; # crosschecks all backups on all devices

実際に使用可能なバックアップ・セットが含まれるようにRMANリポジトリを更新する方法の詳細は、第12章「RMANバックアップおよびリポジトリ・レコードのメンテナンス」を参照してください。

3. REPORT OBSOLETEを実行して、リカバリの必要がなくなったために不要となったバックアップを識別します。
他のオプションを指定せずにREPORT OBSOLETEを実行すると、現行の保存方針で不要とみなされるバックアップが表示されます。次に例を示します。

RMAN> REPORT OBSOLETE;

Datafile Copy        44     08-FEB-06          /backup/ora_df549738566_s70_s1
Datafile Copy        45     08-FEB-06          /backup/ora_df549738567_s71_s1
Datafile Copy        46     08-FEB-06          /backup/ora_df549738568_s72_s1
Backup Set           26     08-FEB-06
Backup Piece       26     08-FEB-06          /backup/ora_df549738682_s76_s1
.
.
.

RECOVERY WINDOWおよびREDUNDANCYオプションを指定してREPORT OBSOLETEを使用することによって、様々なリカバリ期間ベースまたは冗長性ベースの保存方針に基づいて不要とみなされるバックアップを確認できます。次に例を示します。

REPORT OBSOLETE RECOVERY WINDOW OF 3 DAYS;
REPORT OBSOLETE REDUNDANCY 1;

関連項目:

- RMANのバックアップ保存方針の概要については、「バックアップの保存方針の構成」を参照してください。

- RMANバックアップを削除する方法およびRMANリポジトリからRMANバックアップのレコードを削除する方法については、「期限切れのRMANバックアップおよびコピーの削除」を参照してください。

データベース・スキーマに関するレポート

REPORT SCHEMAコマンドを実行すると、データベース・ファイル、表領域などに関する情報が表示されます。REPORT SCHEMAの出力については、『Oracle Databaseバックアップおよびリカバリ・リファレンス』を参照してください。

FOR DB_UNIQUE_NAMEをREPORT SCHEMAとともに指定しない場合、リカバリ・カタログ接続は任意ですが、ターゲット・データベース接続は必須です。Data Guard環境では、REPORT SCHEMA FOR DB_UNIQUE_NAMEを指定して環境内のデータベースのスキーマをレポートできます。この場合、RMANをターゲット・データベースに接続する必要はありません。かわりに、RMANをリカバリ・カタログに接続し、DBIDを設定できます。

データベース・スキーマに関してレポートする手順

1. RMANを起動し、対象となるデータベースに接続します。

2. 前の手順でRMANをターゲット・データベースに接続しておらず、REPORT SCHEMAにFOR DB_UNIQUE_NAME句を指定する場合は、データベースDBIDを設定します。たとえば、次のコマンドを入力します。

RMAN> SET DBID 28014364;

3. 次の例に示すように、REPORT SCHEMAコマンドを実行します。

RMAN> REPORT SCHEMA;

Report of database schema for database with db_unique_name DGRDBMS

List of Permanent Datafiles
===========================
File Size(MB) Tablespace           RB segs Datafile Name
---- -------- -------------------- ------- ------------------------
1    450      SYSTEM               YES     /disk1/oracle/dbs/t_db1.f
2    141      SYSAUX               NO      /disk1/oracle/dbs/t_ax1.f
3    50       UD1                  YES     /disk1/oracle/dbs/t_undo1.f
4    50       TBS_11               NO      /disk1/oracle/dbs/tbs_111.f
5    50       TBS_11               NO      /disk1/oracle/dbs/tbs_112.f

List of Temporary Files
=======================
File Size(MB) Tablespace           Maxsize(MB) Tempfile Name
---- -------- -------------------- ----------- --------------------
1    40       TEMP                 32767       /disk1/oracle/dbs/t_tmp1.f

リカバリ・カタログを使用すると、atClauseを使用して、過去の時刻、SCNまたはログ順序番号を指定できます。次に例を示します。

RMAN> REPORT SCHEMA AT TIME 'SYSDATE-14';     # schema 14 days ago
RMAN> REPORT SCHEMA AT SCN 1000;              # schema at scn 1000
RMAN> REPORT SCHEMA AT SEQUENCE 100 THREAD 1; # schema at sequence 100
RMAN> REPORT SCHEMA FOR DB_UNIQUE_NAME standby1; # schema for database standby1

V$ビューを使用したバックアップ・メタデータの問合せ

LISTおよびREPORTコマンドでは表示できない情報がV$ビューに表示される場合があります。この項では、V$ビューが特に役立つ場合について説明します。

過去および現行のRMANジョブの詳細の問合せ

RMANジョブは、RMANセッションで実行されるコマンドのセットです。したがって、1つのRMANジョブに複数のコマンドを含めることができます。たとえば、2つの別々のコマンドBACKUPおよびRECOVER COPYを、1つのセッションで実行できます。RMANバックアップ・ジョブは、1つのRMANジョブで実行されるBACKUPコマンドのセットです。たとえば、同じRMANジョブで実行されるBACKUP DATABASEおよびBACKUP ARCHIVELOG ALLコマンドで、1つのRMANバックアップ・ジョブが構成されます。

V$RMAN_BACKUP_JOB_DETAILSとV$RMAN_BACKUP_SUBJOB_DETAILSの各ビューおよびこれらに対応するリカバリ・カタログのバージョンによって、RMANバックアップ・ジョブの詳細が提供されます。たとえば、これらのビューには、バックアップにかかった時間、発行されたバックアップ・ジョブの数、各バックアップ・ジョブのステータス(失敗したか完了したかなど)、ジョブの開始日時と終了日時、および実行されたバックアップのタイプが表示されます。SESSION_KEY列は、バックアップ・ジョブが発生したRMANセッションの一意のキーです。

多くの場合、RMANによるバックアップでは、書込みを読取りほど行いません。RMANによる圧縮のため、OUTPUT_BYTES_PER_SEC列をバックアップ速度の測定には使用できません。バックアップ速度の測定に適した列はINPUT_BYTES_PER_SECです。読取りデータと書込みデータの比率はCOMPRESSION_RATIO列に示されます。

過去および現行のRMANジョブの詳細を問い合せる手順

1. 問い合せるバックアップ履歴を持つデータベースにSQL*Plusを接続します。

2. バックアップのタイプ、ステータスおよび開始日時と終了日時についての情報を表示するためにV$RMAN_BACKUP_JOB_DETAILSビューを問い合せます。
次の問合せによって、バックアップ・ジョブの履歴が、RMANセッションの主キーであるセッション・キーの順序で表示されます。

COL STATUS FORMAT a9
COL hrs    FORMAT 999.99
SELECT SESSION_KEY, INPUT_TYPE, STATUS,
TO_CHAR(START_TIME,'mm/dd/yy hh24:mi') start_time,
TO_CHAR(END_TIME,'mm/dd/yy hh24:mi')   end_time,
ELAPSED_SECONDS/3600                   hrs
FROM V$RMAN_BACKUP_JOB_DETAILS
ORDER BY SESSION_KEY;

次に、バックアップ・ジョブの履歴の出力例を示します。

SESSION_KEY INPUT_TYPE    STATUS    START_TIME     END_TIME           HRS
----------- ------------- --------- -------------- -------------- -------
9 DATAFILE FULL COMPLETED 04/18/07 18:14 04/18/07 18:15     .02
16 DB FULL       COMPLETED 04/18/07 18:20 04/18/07 18:22     .03
113 ARCHIVELOG    COMPLETED 04/23/07 16:04 04/23/07 16:05     .01

3. RMANセッションのバックアップ・ジョブの割合を表示するためにV$RMAN_BACKUP_JOB_DETAILSビューを問い合せます。
次の問合せによって、バックアップ・ジョブの速度が、RMANセッションの主キーであるセッション・キーの順序で表示されます。列IN_SECおよびOUT_SECに、1秒当たりのデータの入力と出力が表示されます。

COL in_sec FORMAT a10
COL out_sec FORMAT a10
COL TIME_TAKEN_DISPLAY FORMAT a10
SELECT SESSION_KEY,
OPTIMIZED,
COMPRESSION_RATIO,
INPUT_BYTES_PER_SEC_DISPLAY in_sec,
OUTPUT_BYTES_PER_SEC_DISPLAY out_sec,
TIME_TAKEN_DISPLAY
FROM   V$RMAN_BACKUP_JOB_DETAILS
ORDER BY SESSION_KEY;

次に、バックアップ・ジョブの速度の出力例を示します。

SESSION_KEY OPT COMPRESSION_RATIO IN_SEC     OUT_SEC    TIME_TAKEN
----------- --- ----------------- ---------- ---------- ----------
9 NO                  1     8.24M      8.24M  00:01:14
16 NO         1.32732239     6.77M      5.10M  00:01:45
113 NO                  1     2.99M      2.99M  00:00:44

4. RMANセッションのバックアップのサイズを表示するためにV$RMAN_BACKUP_JOB_DETAILSビューを問い合せます。
BACKUP DATABASEを実行すると、V$RMAN_BACKUP_JOB_DETAILS.OUTPUT_BYTESによって、バックアップ中のデータベースのバックアップ・ジョブによって書き込まれるバックアップ・セットの合計サイズが表示されます。登録されているすべてのデータベースのバックアップ・セットのサイズを表示するには、V$RMAN_BACKUP_JOB_DETAILSを問い合せます。

次の問合せでは、バックアップ・ジョブのサイズとスループットが、RMANセッションの主キーであるセッション・キーの順序で表示されます。列IN_SIZEおよびOUT_SIZEに、1秒当たりのデータの入力と出力が表示されます。

COL in_size  FORMAT a10
COL out_size FORMAT a10
SELECT SESSION_KEY,
INPUT_TYPE,
COMPRESSION_RATIO,
INPUT_BYTES_DISPLAY in_size,
OUTPUT_BYTES_DISPLAY out_size
FROM   V$RMAN_BACKUP_JOB_DETAILS
ORDER BY SESSION_KEY;

次に、バックアップ・ジョブのサイズの出力例を示します。

SESSION_KEY INPUT_TYPE    COMPRESSION_RATIO IN_SIZE    OUT_SIZE
----------- ------------- ----------------- ---------- ----------
10 DATAFILE FULL                 1   602.50M    602.58M
17 DB FULL              1.13736669   634.80M    558.13M

関連項目:
V$RMAN_BACKUP_JOB_DETAILSビューについては、『Oracle Databaseリファレンス』を参照してください。

バックアップ・ピースの暗号化ステータスの確認

V$BACKUP_PIECEビューおよびV$RMAN_BACKUP_PIECEビューのENCRYPTED列は、バックアップ・ピースが暗号化されているか(YES)、暗号化されていないか(NO)を示します。たとえば、SQL*Plusで次の問合せを実行すると、暗号化されているバックアップ・ピースを確認できます。

COL BS_REC    FORMAT 99999
COL BP_REC    FORMAT 99999
COL MB        FORMAT 9999999
COL ENCRYPTED FORMAT A7
COL TAG       FORMAT A25

SELECT S.RECID AS "BS_REC", P.RECID AS "BP_REC", P.ENCRYPTED,
P.TAG, P.HANDLE AS "MEDIA_HANDLE"
FROM   V$BACKUP_PIECE P, V$BACKUP_SET S
WHERE  P.SET_STAMP = S.SET_STAMP
AND    P.SET_COUNT = S.SET_COUNT;

次に、バックアップが暗号化されていることを示す出力例を示します。

BS_REC BP_REC ENCRYPT TAG
------ ------ ------- -------------------------
MEDIA_HANDLE
--------------------------------------------------------------------------------
1      1 YES     TAG20070711T140124
/disk1/c-39525561-20070711-00

2      2 YES     TAG20070711T140128
/disk1/c-39525561-20070711-01

3      3 YES     TAG20070711T140130
/disk1/c-39525561-20070711-02

関連項目:
V$BACKUP_PIECEビューについては、『Oracle Databaseリファレンス』を参照してください。

リカバリ・カタログ・ビューの問合せ

LIST、REPORTおよびSHOWコマンドを使用すると、制御ファイルおよびリカバリ・カタログ内のデータに簡単にアクセスできます。また、リカバリ・カタログ・ビューから有効な情報を取得できる場合もあります。リカバリ・カタログ・ビューとは、リカバリ・カタログ・スキーマ内に存在するRC_接頭辞が付いたビューのことです。

リカバリ・カタログ・ビュー

RMANは、ターゲット・データベースの制御ファイルからバックアップおよびリカバリのメタデータを取得し、リカバリ・カタログの表に格納します。リカバリ・カタログ・ビューは、これらの表から導出されます。リカバリ・カタログ・ビューは、ユーザーによる問合せに対して正規化または最適化されていません。

通常、リカバリ・カタログ・ビューは、RMANのレポート・コマンドほど簡単に使用できません。たとえば、RMANを起動してターゲット・データベースに接続した場合、LIST、REPORTおよびSHOWコマンドを発行するのみでこのターゲット・データベースの情報を取得できます。同じリカバリ・カタログに10個の異なるターゲット・データベースを登録している場合、カタログ・ビューの問合せによって、10個すべてのデータベースのすべてのインカネーションのメタデータが表示されます。多くの場合、ビュー間で複雑な選択および結合を実行して、データベース・インカネーションに関する使用可能な情報を抽出する必要があります。

ほとんどのカタログ・ビューには、対応するV$がデータベース内に存在します。たとえば、 RC_BACKUP_PIECEはV$BACKUP_PIECEに対応しています。リカバリ・カタログ・ビューと対応するV$ビューとの主な違いとしては、各リカバリ・カタログ・ビューにはリカバリ・カタログに登録されているすべてのターゲット・データベースに関するメタデータが含まれていることがあげられます。V$には、ビュー自体の情報のみが含まれています。

関連項目:
リカバリ・カタログ・ビューの詳細は、『Oracle Databaseバックアップおよびリカバリ・リファレンス』を参照してください。

登録されているデータベースの一意の識別子

ほとんどのリカバリ・カタログ・ビューには、列DB_KEYおよびDBINC_KEYが含まれています。リカバリ・カタログに登録されている各データベースは、主キー(DB_KEY列値)またはDBID(32ビットの一意のデータベース識別子)のいずれかによって一意に識別できます。データベースの各インカネーションは、DBINC_KEY列によって一意に識別されます。

DB_KEYおよびDBINC_KEYを使用すると、ターゲット・データベースの特定のインカネーションのレコードを取得できます。その後、他のほとんどのカタログ・ビューとの結合を実行して、このインカネーションに属するレコードを分離できます。

カタログ・ビューとV$ビューとの主な違いとしては、バックアップ・ファイルおよびリカバリ・ファイルに使用される一意の識別子の形式が異なることがあげられます。たとえば、V$ARCHIVED_LOGなどの多くのV$ビューでは、RECID列およびSTAMP列によって連結主キーが構成されます。対応するリカバリ・カタログ・ビューでは、導出された値が主キーとして使用され、この値は単一の列に格納されます。たとえば、RC_ARCHIVED_LOGの主キーはAL_KEY列です。AL_KEYの列値は、LISTコマンドの出力に表示される主キーです。

Data Guard環境の一意の識別子

Data Guard環境でリカバリ・カタログを問い合せる場合は、特別な考慮事項が適用されます。Data Guard環境では、複数のデータベースで同じDBIDが共有されます。複数のビューに、(レコードが含まれているデータベース・インカネーションのDB_UNIQUE_NAMEを示す)DB_UNIQUE_NAME列が含まれています。Data Guard環境のすべてのデータベースで同じDBIDが共有されますが、DB_UNIQUE_NAMEの値は異なります。

データベース名がカタログで認識されない場合は、リカバリ・カタログに登録されているOracle9iデータベースの場合と同様に、DB_UNIQUE_NAMEの値はnullになります。また、データベースをOracle Database 11gにアップグレードしたにもかかわらず、リカバリ・カタログのスキーマとすべてのファイルのデータベース名が一致していない場合も、列値はnullになります。

リカバリ・カタログ・ビューでは、プライマリ・データベースとスタンバイ・データベースは同じDB_KEYを共有します。ただし、Data Guard環境のすべてのデータベースに、一意のRC_SITE.SITE_KEY値があります。たとえば、プライマリ・データベースprodおよびスタンバイ・データベースstandby1の両方に値が1のDB_KEYがある場合がありますが、prodのSITE_KEYは3で、standby1のSITE_KEYは30です。

一部のリカバリ・カタログ・ビューには、DB_UNIQUE_NAME列はありませんが、SITE_KEY列はあります。SITE_KEY列を使用してRC_SITE.SITE_KEYと結合し、ファイルに関連付けられているデータベースのDB_UNIQUE_NAMEを決定できます。「Data Guard環境でのRMANによるファイル管理」で説明されているように、Data Guard環境では、すべてのファイルがそのファイルを作成したプライマリ・データベースまたはスタンバイ・データベースに関連付けられています。

関連項目:
Data Guard環境でのファイルのレポート方法および管理方法については、『Oracle Data Guard概要および管理』を参照してください。

カタログ・ビューへのターゲットDB_KEY値またはDBID値の問合せ

DB_KEY値は、登録されているデータベースの主キーであり、リカバリ・カタログでのみ使用されます。DB_KEYを取得する最も簡単な方法は、ターゲット・データベースのDBIDを使用する方法です。このDBIDは、RMANをTARGETとしてデータベースに接続するたびに表示されます。DBIDによって、RMANのリカバリ・カタログ内に登録されているデータベースが識別されます。

リカバリ・カタログに登録されているデータベースに関する情報を取得すると想定します。

データベースの現行のインカネーションに関する情報をカタログに問い合せる手順

1. レコードを表示するデータベースのDBIDを確認します。
DBIDは、RMANをデータベースに接続したときに表示される出力を参照するか、V$RMAN_OUTPUTを問い合せるか、またはV$DATABASEビューを問い合せることによって取得できます。次の例では、SQL*Plusを目的のデータベースに接続してDBIDを問い合せます。

SQL> CONNECT / AS SYSDBA
SQL> SELECT DBID
2  FROM   V$DATABASE;

DBID
---------
598368217

2. SQL*Plusを起動し、リカバリ・カタログの所有者としてリカバリ・カタログ・データベースに接続します。

3. 手順1で取得したDBIDを持つデータベースのデータベース・キーを取得します。
データベースのDB_KEYを取得するには、次の問合せを実行します。ここで、dbid_of_targetは、手順1で取得したDBIDです。

SELECT DB_KEY
FROM   RC_DATABASE
WHERE  DBID = dbid_of_target;

4. 手順1でDBIDを取得したデータベースの現行のインカネーションのレコードを問い合せます。
ターゲット・データベースの現行のインカネーションに関する情報を取得するには、ターゲット・データベースのDB_KEY値を指定し、RC_DATABASE_INCARNATIONビューとの結合を実行します。WHERE条件を使用して、CURRENT_INCARNATION列値がYESである条件を指定します。たとえば、DB_KEY値を1に指定して、ターゲット・データベースの現行のインカネーションに設定されたバックアップ・セットに関する情報を取得するには、次の問合せを実行します。

SELECT BS_KEY, BACKUP_TYPE, COMPLETION_TIME
FROM   RC_DATABASE_INCARNATION i, RC_BACKUP_SET b
WHERE  i.DB_KEY = 1
AND    i.DB_KEY = b.DB_KEY
AND    i.CURRENT_INCARNATION = 'YES';

関連項目:

- RC_DATABASE_INCARNATIONビューの詳細は、『Oracle Databaseバックアップおよびリカバリ・リファレンス』を参照してください。

- 「データベース・インカネーション」

RC_BACKUP_FILESの問合せ

ビューRC_BACKUP_FILESに対しては、リカバリ・カタログに登録されているデータベースのすべてのバックアップに関する情報を問い合せることができます。ただし、RC_BACKUP_FILESを問い合せる前に、DBMS_RCVMAN.SETDATABASEプロシージャをコールする必要があります。次の例に示すように、リカバリ・カタログに登録されたデータベースのDBIDを指定します。

SQL> CALL DBMS_RCVMAN.SETDATABASE(null,null,null,2283997583);

4番目のパラメータは、リカバリ・カタログに登録されているデータベースのDBIDにする必要があります。その他のパラメータは、すべてNULLにする必要があります。

関連項目:

- RC_BACKUP_FILESビューの詳細は、『Oracle Databaseバックアップおよびリカバリ・リファレンス』を参照してください。

- データベースのDBIDを確認する方法については、「データベースのDBIDの確認」を参照してください。

12 RMANバックアップおよびリポジトリ・レコードのメンテナンス

この章では、RMANのリポジトリ・レコードおよびRMANのバックアップとコピーの管理方法について説明します。また、高速リカバリ領域に関連するメンテナンス・タスクについても説明します。この章の内容は次のとおりです。

- RMANバックアップおよびリポジトリのメンテナンスの概要

- 制御ファイルのリポジトリのメンテナンス

- 高速リカバリ領域のメンテナンス

- RMANリポジトリの更新

- RMANバックアップおよびアーカイブREDOログの削除

- データベースの削除

参照:
リカバリ・カタログに固有のRMANのメンテナンスの問題は、第13章「リカバリ・カタログの管理」を参照してください。

RMANバックアップおよびリポジトリのメンテナンスの概要

この項では、RMANリポジトリのメンテナンスの目的および基本的な概念について説明します。

バックアップおよびリポジトリのメンテナンスの目的

メンテナンス計画では、高速リカバリ領域、バックアップの保存方針およびアーカイブREDOログの削除方針を構成することをお薦めします。この場合、バックアップおよびアーカイブREDOログは、必要に応じてデータベースによって自動的にメンテナンスおよび削除されます。ただし、データベース・バックアップおよびアーカイブREDOログを手動でメンテナンスする必要がある場合もあります。

RMANバックアップを管理する場合は、次の関連タスクを実行します。

- ディスクまたはテープに格納されているデータベース・バックアップの管理

- RMANリポジトリ内のバックアップのレコードの管理

RMANのメンテナンスでの重要なタスクに、不要となったバックアップの削除があります。高速リカバリ領域を構成すると、この領域内の不要なファイルはデータベースによって自動的に削除されます。その場合も、テープからバックアップおよびコピーを削除する場合があります。データベース全体を削除する必要がある場合もあります。RMANコマンドを使用すると、これらのタスクを実行できます。

高速リカバリ領域には、不定期のメンテナンスが必要な場合があります。たとえば、高速リカバリ領域が一杯になった場合、領域を追加できます。また、リカバリ領域の場所を変更する必要がある場合もあります。

ディスクおよびテープ上のファイルの実際の状態がRMANリポジトリに反映されない場合があります。たとえば、ユーザーがオペレーティング・システムのユーティリティを使用して、バックアップをディスクから削除する場合があります。この場合、RMANリポジトリには、実際には存在しないファイルが存在しているように表示されます。RMANバックアップが格納されているテープが破損した場合も、同様の状況が発生します。RMANメンテナンス・コマンドを使用すると、リポジトリを正しい情報で更新できます。

バックアップおよびリポジトリのメンテナンスの基本的な概念

RMANのメンテナンス・コマンドの概要を次に示します。

- CATALOGコマンドを使用すると、RMANリポジトリに現在記録されていないRMANバックアップおよびユーザー管理のバックアップに関するレコードを追加したり、記録されているバックアップのレコードを削除できます。

- CHANGEコマンドを使用すると、RMANリポジトリのレコードのステータスを更新できます。

- CROSSCHECKコマンドを使用すると、論理バックアップ・レコードをバックアップ・ストレージ内のファイルの物理的な状態と同期化できます。

- DELETEコマンドを使用すると、オペレーティング・システムからバックアップを削除できます。

メンテナンス・コマンドおよびRMANリポジトリ・メタデータ

RMANは、操作の実行対象となる各ターゲット・データベースの制御ファイルに、そのメタデータを常に格納します。ターゲット・データベースをリカバリ・カタログに登録すると、RMANは、このターゲット・データベースのメタデータをリカバリ・カタログに格納します。RMANのすべてのメンテナンス・コマンドは、リカバリ・カタログを使用しているかどうかに関係なく動作します。

関連項目:
「リカバリ・カタログのメンテナンス」

Data Guard環境でのメンテナンス・コマンド

Data Guard環境では、バックアップまたはコピーを作成するデータベースはファイルに関連付けられています。たとえば、RMANがターゲット・データベースstandby1に接続し、このデータベースをバックアップする場合、このバックアップはstandby1に関連付けられます。

「Data Guard環境でのRMANによるファイル管理」で指定されている基準に従ってRMANからバックアップにアクセスできる場合、プライマリ・データベースまたはスタンバイ・データベースへの接続時に、バックアップに対してCHANGE、DELETE、CROSSCHECKなどのRMANメンテナンス・コマンドを使用できます。

Data Guard環境でのクロスチェック

クロスチェックする場合、RMANは、ファイルに関連付けられているデータベースへの接続時にのみ、ファイルのステータスをAVAILABLEからEXPIREDに更新できます。このため、RMANでクロスチェックしてもファイルが検出されず、RMANがTARGETとして接続されていないデータベースにファイルが関連付けられている場合は、そのファイルに関連付けられているターゲット・データベースへの接続時に、RMANによってクロスチェックの実行が求められます。RMANは、CROSSCHECKまたはCHANGE ... AVAILABLEコマンドの実行時にクロスチェックを行います。

Data Guard環境での削除

RMANは、データベースへの接続時にファイルを削除できます。ファイルに関連付けられているデータベースにRMANがTARGETとして接続されておらず、RMANでファイルを正常に削除できない場合は、RMANによって、ファイルに関連付けられているデータベースにTARGETとして接続するように求められます。このため、ファイルのメタデータを削除するには、DELETE ... FORCEを使用する必要があります。

Data Guard環境でのRMANメタデータへの更新

メンテナンス・コマンドでRMANのメタデータのみを変更した場合は、RMANをTARGETとしてData Guard環境のデータベースに接続できます。メタデータのみを変更するコマンドは、次のとおりです。

- CHANGE ... UNAVAILABLEまたはCHANGE ... UNCATALOG

- CHANGE ... KEEPまたはCHANGE ... NOKEEP

- CHANGE ... RESET DB_UNIQUE_NAME

デフォルトでは、CHANGEコマンドを使用すると、「Data Guard環境でのバックアップのアクセシビリティについて」で指定されている規則に従ってアクセス可能なファイルに対してのみ操作が行われます。ただし、FOR DB_UNIQUE_NAMEオプションを使用すると、ターゲット・データベース以外のデータベースに関連付けられているファイルのステータスを変更できます。

データベースに関連付けられていないファイル

特定のファイルでDB_UNIQUE_NAMEが認識されない場合があります。たとえば、データベース名がカタログで認識されない場合は、リカバリ・カタログに登録されているOracle9iデータベースの場合と同様に、DB_UNIQUE_NAMEの値はnullになります。また、データベースを現行のバージョンにアップグレードしたにもかかわらず、リカバリ・カタログ・スキーマとすべてのファイルのDB_UNIQUE_NAME値が一致していないため、行のDB_UNIQUE_NAMEがnullになる場合もあります。デフォルトでは、RMANは、TARGETとして接続されているデータベースにSITE_KEYがnullのファイルを関連付けます。CHANGE ... RESET DB_UNIQUE_NAMEを明示的に使用して別のデータベースに関連付けないかぎり、バックアップはそのデータベースに関連付けられたままです。

関連項目:

- Data Guard環境でRMANを使用してファイルのバックアップおよびリストアを実行する方法については、『Oracle Data Guard概要および管理』を参照してください。

- RMANメンテナンス・コマンドについては、『Oracle Databaseバックアップおよびリカバリ・リファレンス』を参照してください。

制御ファイルのリポジトリのメンテナンス

RMANは、リカバリ・カタログを使用しなくても動作するように設計されています。ただし、リカバリ・カタログを使用しないことを選択すると、各ターゲット・データベースの制御ファイルは、RMANメタデータ用の排他的なリポジトリになります。制御ファイルへの情報の格納方法を理解し、バックアップおよびリカバリ計画によって制御ファイルが保護されるようにする必要があります。

関連項目:
制御ファイルの概要および管理方法の詳細は、『Oracle Database管理者ガイド』を参照してください。

制御ファイル・レコード

制御ファイルには、循環再利用レコードおよび非循環再利用レコードの2つのタイプのレコードが含まれています。

循環再利用レコードには、必要に応じて上書き可能な、重要度が低い情報が含まれます。これらのレコードには、データベースによって持続的に生成される情報が含まれます。使用可能なレコード・スロットがすべて使用されると、データベースは、制御ファイルを拡張して新規レコード用の領域を作成するか、または最も古いレコードを上書きします。CONTROL_FILE_RECORD_KEEP_TIME初期化パラメータには、レコードを再利用するまでの最短保管日数を指定します。

非循環再利用レコードには、頻繁には変更されず、上書きできない重要な情報が含まれます。非循環再利用レコードに含まれる情報は、データファイル、オンラインREDOログ・ファイル、REDOスレッドなどです。

ターゲット・データベースのバックアップを作成すると、データベースによってそれらのバックアップが制御ファイルに記録されます。新しいレコードを追加したことによって制御ファイルが過度に大きくならないように、指定したしきい値より古いレコードは再利用可能になります。CONTROL_FILE_RECORD_KEEP_TIME初期化パラメータは、レコードが上書き可能になるまでの最小日数を決定します。

CONTROL_FILE_RECORD_KEEP_TIME = integer

たとえば、パラメータ値が14の場合、14日以上経過したレコードは再利用の候補となります。上書きされたレコードの情報は失われます。再利用可能な最も古いレコードが最初に使用されます。

データベースでは、新しいRMANリポジトリ・レコードを制御ファイルに追加する必要があるにもかかわらず、しきい値より古いレコードが存在しない場合、制御ファイル・サイズの拡大が試行されます。基礎となるオペレーティング・システムで(ディスクが一杯などの状況によって)制御ファイルを拡大できない場合は、データベースによって制御ファイル内の最も古いレコードが上書きされます。

上書きは、自動診断リポジトリ(ADR)内のアラート・ログに記録されます。上書きされる各レコードに対するエントリが、アラート・ログに次のように記録されます。

kccwnc: following control file record written over:
RECID #72 Recno 72 Record timestamp
07/28/06 22:15:21
Thread=1 Seq#=3460
Backup set key: stamp=372031415, count=17
Low scn: 0x0000.3af33f36
07/27/06 21:00:08
Next scn: 0x0000.3af3871b
07/27/06 23:23:54
Resetlogs scn and time
scn: 0x0000.00000001

高速リカバリ領域および制御ファイル・レコード

高速リカバリ領域に作成されたファイルに関する情報を含む制御ファイルのレコードが再利用される際、そのファイルが削除対象である場合は、データベースによって高速リカバリ領域からのそのファイルの削除が試行されます。削除対象でない場合は、このファイルのレコードを含む制御ファイルのセクションのサイズが拡大されます。この拡大に関して、アラート・ログに次の例のようなメッセージが記録されます。ここで、nnnnは、制御ファイル・レコードのタイプの番号です。

kccwnc: trying to expand control file section nnnn for Oracle Managed Files

制御ファイルがホスト・オペレーティング・システムでサポートされている最大サイズに達している場合、制御ファイルを拡大することはできません。このような場合は、次の警告がアラート・ログに表示されます。

WARNING: Oracle Managed File filename is unknown to control file. This is the result of limitation in control file size that could not keep all recovery area files.

前述のメッセージは、構成されている保存方針を満たすために必要なすべての高速リカバリ領域ファイルのレコードを、制御ファイルで保持できないことを示しています。次の項では、この状況に対応する方法について説明します。

関連項目:
CONTROL_FILE_RECORD_KEEP_TIME初期化パラメータの詳細は、『Oracle Databaseリファレンス』を参照してください。

制御ファイル・レコードの消失の防止

制御ファイル・レコードの上書きによってRMANメタデータが消失することを防止するには、リカバリ・カタログを使用する方法が最適です。リカバリ・カタログを使用できない場合は、次の方法を使用できます。

- CONTROL_FILE_RECORD_KEEP_TIMEの値を、保持する必要がある最も古いファイルの期間より少し長く設定します。たとえば、データベース全体を1週間に1回バックアップする場合は、すべてのバックアップを7日間以上保持する必要があります。CONTROL_FILE_RECORD_KEEP_TIMEの値を10や14などに設定します。CONTROL_FILE_RECORD_KEEP_TIMEのデフォルト値は7日間です。

注意:
リカバリ・カタログの使用にかかわらず、CONTROL_FILE_RECORD_KEEP_TIMEが0に設定されている場合はRMANを使用しないでください。そうすると、バックアップ・レコードが失われる場合があります。

- 制御ファイルは、拡大できるようにRAWデバイスではなくファイル・システムに格納します。

- アラート・ログを監視して、Oracle Databaseによって制御ファイル・レコードが上書きされないようにします。アラート・ログは、自動診断リポジトリ(ADR)内にあります。

高速リカバリ領域を使用する場合は、次のガイドラインに従って、バックアップ保存方針を満たすために必要なすべての高速リカバリ領域ファイルのレコードを制御ファイルで保持できなくなるような状況を回避します。

- 制御ファイルのブロック・サイズが最大に達している場合は、より大きなブロック・サイズ(可能な場合32KB)を使用します。
これを実現するには、SYSTEM表領域のブロック・サイズを制御ファイルのブロック・サイズ以上に設定し、DB_BLOCK_SIZEの変更後に制御ファイルを再作成する必要があります。高速リカバリ領域内のファイルはカタログに再度追加されますが、テープに格納されているファイルのレコードは失われます。

- 高速リカバリ領域内のファイルをテープなどの3次ストレージ・デバイスにバックアップして、削除対象にします。
たとえば、BACKUP RECOVERY AREAを使用すると、高速リカバリ領域内のファイルを明示的にメディア・マネージャにバックアップできます。

- バックアップの保存方針によってバックアップおよびアーカイブ・ログがビジネス要件より長く保持されている場合は、その保存方針をより短いリカバリ期間またはより低い冗長性のレベルに変更して、高速リカバリ領域内のより多くのファイルを削除対象にすることができます。

制御ファイルの保護

リカバリ・カタログを使用してRMANメタデータを格納していない場合は、各ターゲット・データベースの制御ファイルを保護することがさらに重要となります。次の計画を使用すると、制御ファイルを保護することができます。

制御ファイルを保護する手順

1. 多重化またはオペレーティング・システムのミラー化によって、制御ファイルの冗長コピーを作成します。
これによって、制御ファイルのサブセットが消失した場合に、ユーザーが制御ファイルをバックアップからリストアする必要がなくなります。2つ以上の多重制御ファイルまたはミラー化制御ファイルを別々のディスクで使用することをお薦めします。

2. 制御ファイルの自動バックアップ機能を構成します。
この場合、特定のRMANコマンドを実行すると、制御ファイルが自動的にバックアップされます。制御ファイルの自動バックアップを使用できる場合、RMANは、サーバー・パラメータ・ファイルおよびバックアップ制御ファイルをリストアしてデータベースをマウントできます。制御ファイルをマウントした後、データベースの残りの部分をリストアできます。

3. データベースのDBIDのレコードを保持します。
制御ファイルが消失した場合は、DBIDを使用してデータベースをリカバリできます。

関連項目:

- 制御ファイルの手動バックアップおよび自動バックアップについては、「RMANを使用した制御ファイルのバックアップ」を参照してください。

- 「制御ファイルおよびサーバー・パラメータ・ファイルの自動バックアップ」

高速リカバリ領域のメンテナンス

高速リカバリ領域は多くの場合自動管理されますが、データベース管理の介入が必要になることもあります。

高速リカバリ領域の規則の削除

高速リカバリ領域の内容および永続的なファイルと一時的なファイルの違いについては、「高速リカバリ領域の概要」を参照してください。この章を読む前に、これらの項を参照してください。次の規則によって、ファイルがリカバリ領域からの削除対象となるタイミングが制御されます。

- 永続的なファイルは削除の対象となりません。

- 保存方針に従って不要になったファイルは削除対象となります。
保存方針の構成方法については、「バックアップの保存方針の構成」を参照してください。

- テープにコピーされた一時ファイルは削除対象となります。

- アーカイブREDOログは、ログのすべてのコンシューマが要件を満たすまで削除対象となりません。
ログが削除対象となるタイミングを決定するアーカイブREDOログの削除方針の構成方法については、「アーカイブREDOログの削除方針の構成」を参照してください。ログのコンシューマには、RMAN、スタンバイ・データベース、Oracle Streamsデータベースおよびフラッシュバック・データベース機能などがあります。Data Guard環境でのアーカイブREDOログ管理については、『Oracle Data Guard概要および管理』を参照してください。

- ロジカル・スタンバイ・データベースでLogMinerセッションによってマイニングされた外部のアーカイブ・ログは削除対象になります。外部のアーカイブREDOログは現在のデータベースとは異なるデータベースから生成されるため、そのDBIDは現在のアーカイブREDOログのDBIDとは異なっています。

高速リカバリ領域からの削除を制御する安全で確実な方法は、保存方針およびアーカイブ・ログの削除方針(「アーカイブREDOログの削除方針の構成」を参照)を構成する方法です。テープに移動したファイルがディスクに保存される可能性を高くするには、高速リカバリ領域の割当て制限を大きくします。

高速リカバリ領域の領域使用状況の監視

V$RECOVERY_FILE_DESTビューおよびV$RECOVERY_AREA_USAGEビューを使用すると、高速リカバリ領域に十分な領域が割り当てられているかどうかを確認できます。V$RECOVERY_FILE_DESTビューを問い合せて、高速リカバリ領域の現在の位置、ディスク割当て制限、使用領域、ファイル削除による再利用可能な領域、およびファイルの合計数を確認します。たとえば、例12-1に示す問合せを入力します(出力例も示します)。領域に関する列はバイト単位で示されます。

例12-1 高速リカバリ領域の領域消費量

SELECT * FROM V$RECOVERY_FILE_DEST;

NAME            SPACE_LIMIT SPACE_USED SPACE_RECLAIMABLE NUMBER_OF_FILES
--------------  ----------- ---------- ----------------- ---------------
/mydisk/rcva     5368709120 109240320             256000              28

異なるタイプのファイルで使用されている合計ディスク割当て制限の割合を確認するには、V$RECOVERY_AREA_USAGEビューを問い合せます。また、不要なファイル、冗長なファイルまたはテープにバックアップされているファイルを削除することによって、各タイプのファイル用に再利用できる領域の量を判断することもできます。たとえば、次の問合せを入力します(出力例も示します)。

SELECT * FROM   V$RECOVERY_AREA_USAGE;

FILE_TYPE    PERCENT_SPACE_USED PERCENT_SPACE_RECLAIMABLE NUMBER_OF_FILES
------------ ------------------ ------------------------- ---------------
CONTROLFILE                   0                         0               0
ONLINELOG                     2                         0              22
ARCHIVELOG                 4.05                      2.01              31
BACKUPPIECE                3.94                      3.86               8
IMAGECOPY                 15.64                     10.43              66
FLASHBACKLOG                .08                         0               1

保証付きリストア・ポイントがデータベースに定義されている場合は、保証を満たすために必要なファイル用に高速リカバリ領域で使用される領域の量を監視する必要があります。保証付きリストア・ポイントを表示する問合せ(「リストア・ポイントの表示」を参照)を使用し、STORAGE_SIZE列を参照して、各保証付きリストア・ポイントに関連するファイルに必要な領域を決定します。

関連項目:
V$RECOVERY_FILE_DESTビューおよびV$RECOVERY_AREA_USAGEビューの詳細は、『Oracle Databaseリファレンス』を参照してください。

高速リカバリ領域でのフラッシュバック・ログの領域の管理

フラッシュバック・ログの削除規則については、「保証付きリストア・ポイントを定義した状態でのフラッシュバック・データベースのロギング」を参照してください。高速リカバリ領域のフラッシュバック・ログは、フラッシュバック保存目標を設定するか、または保証付きリストア・ポイントを使用する以外に直接管理することはできません。ただし、フラッシュバック・ログの保存に使用できる領域を最大化するために、高速リカバリ領域を全体として管理することはできます。これによって、フラッシュバック目標を達成する可能性が高くなります。

フラッシュバック・ログ用の領域を確保するには、BACKUP RECOVERY AREA、BACKUP BACKUPSETなどのコマンドを使用して、高速リカバリ領域の他の内容をテープにバックアップします。Oracle Databaseでは、不要になったファイルが高速リカバリ領域から自動的に削除されます。バックアップをテープにオフロードしても、バックアップ保存方針およびフラッシュバック保存目標を満たす十分な領域が作成されない場合は、高速リカバリ領域により多くの領域を割り当てます。

注意:
フラッシュバック・ログはバックアップできません。このため、高速リカバリ領域の内容をテープにバックアップする場合、BACKUP RECOVERY AREA操作を使用してもフラッシュバック・ログは含まれません。

高速リカバリ領域が一杯になった場合の対応

RMANの保存方針によって高速リカバリ領域のディスク割当て制限より大きいバックアップのセットを保存する必要がある場合、またはこの保存方針がNONEに設定されている場合、高速リカバリ領域は再利用可能な領域がなくなるまで完全に一杯になることがあります。

再利用可能な領域が15%未満になると警告アラートが発行され、再利用可能な領域が3%未満になるとクリティカル・アラートが発行されます。この状況をDBAに警告するために、アラート・ログおよびDBA_OUTSTANDING_ALERTS表(Enterprise Managerで使用)にエントリが追加されます。ただし、高速リカバリ領域内の領域は、再利用可能な領域がなくなるまでデータベースによって継続して消費されます。

リカバリ領域が完全に一杯になると、次のエラーが表示されます。ここで、nnnnnは必要なバイト数、mmmmmはディスク割当て制限です。

ORA-19809: limit exceeded for recovery files
ORA-19804: cannot reclaim nnnnn bytes disk space from mmmmm limit

削除対象のファイルがない場合に高速リカバリ領域が一杯になった状態を解消する方法として、次のいくつかの方法があります。

- 使用可能なディスク領域を追加し、DB_RECOVERY_FILE_DEST_SIZEを増加して、追加した領域を反映させます。

- 高速リカバリ領域からテープなどの3次ストレージ・デバイスにバックアップを移動します。
リカバリ領域のすべてのファイルを一度にテープにバックアップする簡単な方法の1つに、BACKUP RECOVERY AREAコマンドがあります。バックアップをリカバリ領域からテープに転送した後、高速リカバリ領域からファイルを削除できます(「RMANバックアップおよびアーカイブREDOログの削除」を参照)。フラッシュバック・ログは、リカバリ領域外にはバックアップできないため、BACKUP RECOVERY AREAではバックアップされません。

- オペレーティング・システム・ユーティリティを使用して削除されたファイルに対しては、DELETEを実行します。
ホスト・オペレーティング・システムのコマンドを使用してファイルを削除した場合、その結果できる空き領域はデータベースでは認識されません。RMANのCROSSCHECKコマンドを実行して、高速リカバリ領域の内容を再確認し、期限切れのファイルを特定した後、DELETE EXPIREDコマンドを使用して、RMANリポジトリからすべての期限切れのバックアップを削除することができます。

- 保証付きリストア・ポイントが必要であることを確認します。必要ない場合は、「リストア・ポイントの削除」の説明に従って削除します。
保証付きリストア・ポイントで必要ないフラッシュバック・ログは、高速リカバリ領域内の他のファイルの領域を確保するために自動的に削除されます。保証付きリストア・ポイントを使用すると、リストア・ポイントSCNまでフラッシュバック・データベースを実行するために必要なフラッシュバック・ログを強制的に保存できます。

- バックアップ保存方針を確認します。Data Guardを使用している場合は、アーカイブREDOログの削除方針も確認します。

関連項目:
保存方針の決定方法については、第9章「データベースのバックアップ」を参照してください。Data Guard使用時のアーカイブ・ログの削除方針の詳細は、『Oracle Data Guard概要および管理』を参照してください。

新しい場所への高速リカバリ領域の変更

データベースの高速リカバリ領域を新しい場所に移動する必要がある場合は、次の手順を実行します。

1. ターゲット・データベースでSQL*Plusを起動し、DB_RECOVERY_FILE_DEST初期化パラメータを変更します。たとえば、次のコマンドを入力し、移動先をASMディスク・グループdisk1に設定します。

ALTER SYSTEM SET DB_RECOVERY_FILE_DEST='+disk1' SCOPE=BOTH SID='*';

このパラメータを変更すると、すべての新しい高速リカバリ領域ファイルが新しい場所に作成されます。

2. 古いフラッシュ・リカバリの場所にある永続的なファイル、フラッシュバック・ログおよび一時的なファイルをそのままにするか、または移動します。
既存のファイルをフラッシュ・リカバリに残した場合、古い高速リカバリ領域の一時的なファイルは、削除対象となったときに削除されます。

古いファイルを新しい高速リカバリ領域に移動する必要がある場合は、『Oracle Databaseストレージ管理者ガイド』を参照してください。ファイルを高速リカバリ領域に移動したり、高速リカバリ領域から移動する場合は、RMANを使用してデータベース・ファイルをASMディスク・グループに移動したり、ASMディスク・グループから移動するときと同じ手順を使用できます。

高速リカバリ領域の無効化

高速リカバリ領域を無効にする前に、すべての保証付きリストア・ポイントを削除してから、フラッシュバック・データベースを無効にする必要があります。これらの前提条件が満たされると、DB_RECOVERY_FILE_DEST初期化パラメータをNULL文字列に設定することによって、高速リカバリ領域を無効にできます。たとえば、次のSQL文を使用して、実行中のデータベースのパラメータを変更します。

ALTER SYSTEM SET DB_RECOVERY_FILE_DEST='' SCOPE=BOTH SID='*';

これで、データベースは以前のDB_RECOVERY_FILE_DESTの位置に格納されているファイルに高速リカバリ領域の領域管理機能を提供しなくなります。ただし、これらのファイルは、RMANリポジトリで認識され、バックアップおよびリストア・アクティビティで使用できます。

ファイル作成時のインスタンスのクラッシュへの対応

通常、高速リカバリ領域は自動管理されます。ただし、高速リカバリ領域内のファイルの作成中にインスタンスがクラッシュした場合、そのファイルが高速リカバリ領域内に残存することがあります。この状況が発生した場合は、アラート・ログに次のエラーが含まれます。ここで、locationは、高速リカバリ領域の場所です。

ORA-19816: WARNING: Files may exist in location that are not known to database.

このような場合は、RMANコマンドCATALOG RECOVERY AREAを使用して、このようなファイルをカタログに再度追加します。問題のファイルのヘッダーが破損している場合は、オペレーティング・システム・ユーティリティを使用してファイルを手動で削除します。

RMANリポジトリの更新

この項では、RMANリポジトリが、ディスクおよびテープに格納されているRMAN関連ファイルの実情を正確に反映していることを確認する方法について説明します。リポジトリとリポジトリによって記録されるファイル間の相違は、テープまたはディスクの障害、ユーザー管理のコピー、RMAN関連ファイルの削除などのいくつかの原因によって発生する可能性があります。

この項の内容は、次のとおりです。

- RMANリポジトリのクロスチェック

- バックアップおよびコピーのリポジトリ・ステータスの変更

- RMANリポジトリへのバックアップ・レコードの追加

- RMANリポジトリからのレコードの削除

RMANリポジトリのクロスチェック

リカバリ・カタログまたは制御ファイルのバックアップに関するデータがディスクまたはメディア管理カタログの該当するデータと同期されていることを確認するには、クロスチェックを実行します。CROSSCHECKコマンドでは、RMANリポジトリに現在記録されているファイルのみが処理されます。

高速リカバリ領域、バックアップの保存方針およびアーカイブREDOログの削除方針を使用する場合は、クロスチェックを頻繁に実行する必要はありません。RMAN以外の方法でファイルを削除する場合は、クロスチェックを定期的に実行して、リポジトリ・データが最新の状態で保持されるようにする必要があります。

RMANのクロスチェック

クロスチェックは、リポジトリ・レコードが物理的な状態と一致しないバックアップに関する、RMANリポジトリの期限切れの情報を更新します。たとえば、ユーザーがオペレーティング・システム・コマンドを使用してアーカイブ・ログをディスクから削除すると、ログが実際にはディスク上に存在していない場合でも、リポジトリではディスク上に存在しているように示されます。

図12-1に、メディア・マネージャのクロスチェックを示します。RMANは、RMANリポジトリに対して、チェックする4つのバックアップ・セットの名前と場所を問い合せます。RMANは、この情報をターゲット・データベース・サーバーに送信します。ターゲット・データベース・サーバーは、メディア管理ソフトウェアにバックアップについて問い合せます。メディア管理ソフトウェアは、メディア・カタログを確認して、バックアップ・セット3が欠落していることをサーバーにレポートします。RMANは、リポジトリでバックアップ・セット3のステータスをEXPIREDに更新します。DELETE EXPIREDを実行すると、バックアップ・セット3のレコードは削除されます。

図12-1 メディア・マネージャのクロスチェック

クロスチェックは、次の処理を行うため有効です。

- ディスクまたはテープから消失したバックアップや、破損したバックアップに関する以前の情報を更新できます。

- オペレーティング・システム・コマンドを使用してアーカイブREDOログまたはその他のファイルを削除した場合に、リポジトリを更新できます。

クロスチェック機能を使用すると、ディスクまたはテープ上のバックアップのステータスを確認できます。バックアップがディスク上に存在する場合、CROSSCHECKによって、そのファイルのヘッダーが有効かどうかが確認されます。バックアップがテープ上に存在する場合、このコマンドによって、バックアップがメディア管理ソフトウェアのカタログに存在するかどうかが確認されます。

バックアップ・ピースおよびイメージ・コピーのステータスは、AVAILABLE、EXPIREDまたはUNAVAILABLEとなります。RMANのLISTコマンドを実行するか、V$BACKUP_FILES、またはRC_DATAFILE_COPYやRC_ARCHIVED_LOGなどのリカバリ・カタログ・ビューを問い合せると、バックアップのステータスを表示できます。クロスチェックによってRMANリポジトリが更新されるため、これらのすべての方法で正確な情報が提供されます。RMANは、RMANリポジトリ内のバックアップが使用できなくなると、そのバックアップのステータスをEXPIREDに更新します。新しいクロスチェックによって期限切れのバックアップが再度使用可能であると判断された場合、RMANはそのステータスをAVAILABLEに更新します。

注意:
CROSSCHECKコマンドでは、オペレーティング・システム・ファイルまたはリポジトリ・レコードは削除されません。これらを削除するには、DELETEコマンドを使用する必要があります。

DELETE EXPIREDコマンドを発行すると、期限切れのすべてのバックアップを削除できます。RMANは、期限切れのファイルのレコードをリポジトリから削除します。なんらかの理由でファイルがまだメディア上に存在している場合、RMANは警告を発行して、削除できない不一致のオブジェクトのリストを表示します。

関連項目:

- CROSSCHECKの構文および使用される可能性があるステータス値については、『Oracle Databaseバックアップおよびリカバリ・リファレンス』を参照してください。

- DELETEの構文については、『Oracle Databaseバックアップおよびリカバリ・リファレンス』を参照してください。

すべてのバックアップおよびコピーのクロスチェック

ターゲット・データベースとリカバリ・カタログ(使用している場合)に接続してから、必要に応じてCROSSCHECKコマンドを実行し、RMANが認識するバックアップの状態と可用性を検証します。

CROSSCHECKまたはDELETEコマンドを発行する前に、複数のチャネルを構成するか、手動で割り当てます。RMANは、バックアップの作成に使用したチャネルと同じデバイスのタイプを持つすべてのチャネルの各バックアップを検索します。マルチチャネル機能は、1つのコマンドでディスクおよびテープの両方のクロスチェックまたはバックアップの削除を実行する場合に主に使用されます。たとえば、SBTチャネルが次のように構成されているとします。

CONFIGURE DEVICE TYPE sbt PARALLELISM 1;
CONFIGURE DEFAULT DEVICE TYPE sbt;

この場合は、次のコマンドを実行して、ディスクおよびSBTの両方をクロスチェックできます。

CROSSCHECK BACKUP;
CROSSCHECK COPY;

RMANは、SBTチャネルおよび事前構成済のディスク・チャネルの両方を使用してクロスチェックを実行します。出力例を次に示します。

allocated channel: ORA_SBT_TAPE_1
channel ORA_SBT_TAPE_1: sid=12 devtype=SBT_TAPE
channel ORA_SBT_TAPE_1: WARNING: Oracle Test Disk API
using channel ORA_DISK_1
crosschecked backup piece: found to be 'AVAILABLE'
backup piece handle=/oracle/dbs/16c5esv4_1_1 recid=36 stamp=408384484
crosschecked backup piece: found to be 'AVAILABLE'
backup piece handle=/oracle/dbs/c-674966176-20000915-01 recid=37 stamp=408384496
crosschecked backup piece: found to be 'AVAILABLE'
backup piece handle=12c5erb2_1_1 recid=32 stamp=408382820
.
.
.

自動SBTチャネルを構成していない場合は、ディスクおよびテープにメンテナンス・チャネルを手動で割り当てることができます。

ALLOCATE CHANNEL FOR MAINTENANCE DEVICE TYPE sbt;
CROSSCHECK BACKUP;
CROSSCHECK COPY;

RMANは事前構成済のディスク・チャネルを使用するため、ディスク・チャネルを手動で割り当てる必要はありません。

特定のバックアップ・セットおよびコピーのクロスチェック

LISTコマンドを使用してバックアップをレポートしてから、CROSSCHECKコマンドを使用してLIST出力に示された特定のバックアップが存在することを確認できます。DELETE EXPIREDコマンドは、クロスチェックの失敗の原因となるバックアップのリポジトリ・レコードを削除します。

指定したバックアップをクロスチェックする手順

1. RMANを起動し、ターゲット・データベースおよびリカバリ・カタログ(使用している場合)に接続します。

2. LISTコマンドを実行して、チェックするバックアップを識別します。
たとえば、次のコマンドを実行します。

LIST BACKUP;  # lists all backup sets, proxy copies, and image copies

3. 目的のバックアップまたはコピーをクロスチェックします。
次のコマンド例は、様々なタイプのクロスチェックを示しています。

CROSSCHECK BACKUP;  # checks backup sets, proxy copies, and image copies
CROSSCHECK COPY OF DATABASE;
CROSSCHECK BACKUPSET 1338, 1339, 1340;
CROSSCHECK BACKUPPIECE TAG 'nightly_backup';
CROSSCHECK BACKUP OF ARCHIVELOG ALL SPFILE;
CROSSCHECK BACKUP OF DATAFILE "?/oradata/trgt/system01.dbf"
COMPLETED AFTER 'SYSDATE-14';
CROSSCHECK CONTROLFILECOPY '/tmp/control01.ctl';
CROSSCHECK DATAFILECOPY 113, 114, 115;
CROSSCHECK PROXY 789;

関連項目:
特定のファイルのバックアップを確認するためのCROSSCHECKの使用方法の詳細は、『Oracle Databaseバックアップおよびリカバリ・リファレンス』を参照してください。

バックアップおよびコピーのリポジトリ・ステータスの変更

この項では、バックアップおよびコピーのリポジトリ・レコードの変更方法について説明します。バックアップが一時的に使用可能または使用不可になった場合、バックアップ・ステータスを変更できます。たとえば、マウントされているディスクのメンテナンスを行う場合は、ディスク上のバックアップのレコードのステータスをUNAVAILABLEに更新できます。

AVAILABLEまたはUNAVAILABLEへのバックアップのステータスの更新

バックアップが検出されない場合、またはサイト外に移された場合は、CHANGE ... UNAVAILABLEコマンドを実行します。RMANは、ステータスがUNAVAILABLEのファイルはRESTOREまたはRECOVERコマンドでは使用しません。ファイルが後で検出された場合またはメイン・サイトに戻された場合は、CHANGE ... AVAILABLEを発行してステータスを再度更新できます。高速リカバリ領域内のファイルをUNAVAILABLEにマークすることはできません。

リポジトリ内のファイルのステータスをUNAVAILABLEまたはAVAILABLEに更新する手順

1. LISTコマンドを発行して、RMANバックアップの可用性の状態を確認します。たとえば、次のコマンドを発行してすべてのバックアップを表示します。

LIST BACKUP;

2. UNAVAILABLEまたはAVAILABLEキーワードを指定してCHANGEを実行し、RMANリポジトリの状態を更新します。
次の例は、CHANGEコマンドの形式を示しています。

CHANGE DATAFILECOPY '/tmp/control01.ctl' UNAVAILABLE;
CHANGE COPY OF ARCHIVELOG SEQUENCE BETWEEN 1000 AND 1012 UNAVAILABLE;
CHANGE BACKUPSET 12 UNAVAILABLE;
CHANGE BACKUP OF SPFILE TAG "TAG20020208T154556" UNAVAILABLE;
CHANGE DATAFILECOPY '/tmp/system01.dbf' AVAILABLE;
CHANGE BACKUPSET 12 AVAILABLE;
CHANGE BACKUP OF SPFILE TAG "TAG20020208T154556" AVAILABLE;

関連項目:
CHANGEコマンドの構文については、『Oracle Databaseバックアップおよびリカバリ・リファレンス』を参照してください。

アーカイブ・バックアップのステータスの変更

「長期格納用のデータベース・バックアップの作成」で説明されているように、保存方針から除外するバックアップを指定できます。この方法は、ビジネス要件に準拠するためにバックアップをアーカイブする場合に有効です。ただし、アーカイブ・バックアップは完全に有効なバックアップであり、他のRMANバックアップと同様にリストアできます。

注意:
制御ファイルにはRMANリポジトリの大規模なデータ・セットを無限に含めることはできないため、KEEP FOREVER句を使用する場合は、リカバリ・カタログを使用する必要があります。

CHANGEコマンドを使用すると、既存のバックアップのKEEPステータスを変更できます。たとえば、長期バックアップを保持しないようにすることができます。BACKUP ... KEEPで使用できるオプションをCHANGE ... KEEPでも使用できます。

高速リカバリ領域に格納されているバックアップ・セットまたはファイルにはKEEP属性を設定できません。

アーカイブ・バックアップのKEEPステータスを変更する手順

1. LISTコマンドを発行してバックアップを表示します。たとえば、次のコマンドを発行してすべてのバックアップを表示します。

LIST BACKUP;

2. CHANGE ... KEEPコマンドを発行して異なる保存期間をこのバックアップに定義するか、またはCHANGE ... NOKEEPコマンドを発行して保存方針をこのファイルに適用します。
次の例では、バックアップ・セットがバックアップの保存方針に従うことができます。

CHANGE BACKUPSET 231 NOKEEP;

次の例では、データファイルのコピーを保存方針から180日間除外するようにマークします。

CHANGE DATAFILECOPY '/tmp/system01.dbf' KEEP UNTIL TIME 'SYSDATE+180';

RMANリポジトリへのバックアップ・レコードの追加

CATALOGコマンドを使用すると、リポジトリに記録されていないアーカイブ・ログ、またはRMAN以外の方法を使用して作成されたデータベース・ファイルのコピーの存在をRMANに認識させることができます。この項の内容は、次のとおりです。

- カタログ操作

- カタログへのユーザー管理データファイルのコピーの追加

- カタログへのバックアップ・ピースの追加

- カタログへのディスクの場所内のすべてのファイルの追加

カタログ操作

ターゲット・データベースの制御ファイルには、ターゲット・データベースによって生成されたすべてのアーカイブREDOログおよびすべてのRMANのバックアップのレコードが保持されます。CATALOGコマンドを実行すると、RMANのファイルのレコードが存在しない場合に、メタデータをリポジトリに追加できます。

次の場合に、RMANのCATALOGコマンドを実行します。

- オペレーティング・システム・ユーティリティを使用して、データファイル、アーカイブ・ログまたはバックアップ・ピースのコピーを作成した場合。この場合、これらのレコードはリポジトリに含まれません。

- バックアップ制御ファイルを使用してリカバリを実行し、リカバリ中にアーカイブ先または形式を変更した場合。この場合、リカバリに必要なアーカイブ・ログに関する情報はリポジトリに含まれません。そのため、これらのログをカタログに追加する必要があります。

- データファイルのコピーをレベル0のバックアップとしてカタログに追加した場合。これによって、増分バックアップ計画の基礎となるデータファイルのコピーを使用して後で増分バックアップを実行できるようになります。

- 新しいリリースに移行する前に作成したOracle7のデータベース・ファイルのユーザー管理コピー、またはRMANを使用する前に作成したOracle8以上のデータベース・ファイルのユーザー管理コピーをカタログに追加する場合。移行後にデータベースで障害が発生し、移行したデータベースのバックアップを作成していない場合は、これらのデータファイルのコピーを使用してデータベースをリカバリできます。

UNIXのcpコマンドを使用したデータファイルのコピーなど、ユーザー管理コピーを作成するときには必ずカタログに追加してください。ユーザー管理コピーを作成する場合、ALTER TABLESPACE ... BEGIN/END BACKUP文を使用してオンライン表領域のデータファイルのコピーを作成できます。RMANはこのようなデータファイルのコピーを作成しませんが、CATALOGコマンドを使用してデータファイルのコピーをリカバリ・カタログに追加し、RMANに認識させることができます。

ユーザー管理コピーをカタログに追加するには、次の条件を満たしている必要があります。

- ディスク上でアクセス可能であること

- 単一ファイルの完全なイメージ・コピーであること

- データファイル、制御ファイル、アーカイブREDOまたはバックアップ・ピースのいずれかのコピーであること

たとえば、ミラー化されたディスク・ドライブにデータファイルを格納する場合は、ミラー化を解除することによってユーザー管理コピーを作成できます。この場合、ミラー化を解除した後にCATALOGコマンドを使用してユーザー管理コピーが存在することをRMANに通知します。再度ミラー化する前に、 CHANGE ... UNCATALOGコマンドを実行してファイルのコピーが存在しないことをRMANに通知します。

カタログへのユーザー管理データファイルのコピーの追加

CATALOGコマンドを使用して、ユーザー管理コピーに関する情報をRMANリポジトリに伝播します。ファイルがカタログに追加されたら、LISTコマンドを実行するか、V$BACKUP_FILESビューを問い合せて、RMANリポジトリに情報が含まれていることを確認します。

データファイルのユーザー管理コピーを作成してカタログに追加する手順

1. オペレーティング・システム・ユーティリティを使用して、データファイルのコピーを作成します。バックアップ中にデータベースがオープンしており、データファイルがオンラインになっている場合は、ALTER TABLESPACE BEGIN/END BACKUPを実行する必要があります。次の例では、オペレーティング・システム・コマンドを発行するためのSQL*PlusコマンドHOSTを使用して、オンラインのデータファイルをバックアップします。

SQL> ALTER TABLESPACE users BEGIN BACKUP;
SQL> host cp $ORACLE_HOME/oradata/trgt/users01.dbf /tmp/users01.dbf;
SQL> ALTER TABLESPACE users END BACKUP;

2. RMANを起動し、ターゲット・データベースおよびリカバリ・カタログ(使用している場合)に接続します。

3. CATALOGコマンドを実行します。
たとえば、ユーザー管理のデータファイル・コピーをカタログに追加するには、次のコマンドを実行します。

CATALOG DATAFILECOPY '/tmp/users01.dbf';

接続したターゲット・データベース以外のデータベースからデータファイル・コピーをカタログに追加しようとすると、RMANは次のようなエラーを発行します。

RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03009: failure of catalog command on default channel at 08/29/2007 14:44:34
ORA-19563: datafile copy header validation failed for file /tmp/tools01.dbf

関連項目:
CATALOGコマンドの構文については、『Oracle Databaseバックアップおよびリカバリ・リファレンス』を参照してください。

カタログへのバックアップ・ピースの追加

ディスク上のバックアップ・ピースをカタログに追加できます。この方法は、オペレーティング・システム・ユーティリティを使用して、同じホスト上のある場所から別の場所に、またはあるホストから別のホストにバックアップ・ピースをコピーする場合に有効です。データベースの以前のインカネーションからバックアップ・ピースのカタログを追加することもできます。RMANは、後続のリストアおよびリカバリ操作中にバックアップ・ピースを使用できるかどうかを決定できます。

バックアップ・ピースをカタログに追加する手順

1. RMANを起動し、ターゲット・データベースおよびリカバリ・カタログ(使用している場合)に接続します。

2. バックアップ・ピースのファイル名をカタログに追加します。
たとえば、次のコマンドを入力します。

CATALOG BACKUPPIECE '/disk2/09dtq55d_1_2', '/disk2/0bdtqdou_1_1';

3. 必要に応じて、LISTコマンドを実行するか、またはV$ビューを問い合せて変更を確認します。
ビューには、V$BACKUP_PIECE、V$BACKUP_SET、V$BACKUP_DATAFILE、V$BACKUP_REDOLOGおよびV$BACKUP_SPFILEがあります。次の問合せは、バックアップ・ピース名を示しています。

SELECT HANDLE
FROM   V$BACKUP_PIECE;

関連項目:
CATALOG BACKUPPIECEの制限事項については、『Oracle Databaseバックアップおよびリカバリ・リファレンス』を参照してください。

カタログへのディスクの場所内のすべてのファイルの追加

自動ストレージ管理(ASM)、Oracle Managed Filesフレームワークまたは高速リカバリ領域を使用する場合は、ディスク管理システムによって認識されており、RMANのリポジトリには表示されていないファイルをカタログに再度追加する必要があることがあります。この状況は、メディア障害、ソフトウェアの不具合またはユーザー・エラーが原因でファイル名を追跡するメカニズムで障害が発生した場合に発生する可能性があります。

CATALOG START WITHコマンドを使用すると、ASMディスク・グループ、Oracle Managed Filesまたは従来のファイル・システム・ディレクトリにあるすべてのファイルを検索して、RMANリポジトリに記録されていないファイルを調べることができます。このコマンドによってファイルをカタログに追加できる場合は、ファイルがカタログに追加されます。ファイルをカタログに追加できない場合は、スキップされたファイルの内容が可能なかぎり推測されます。

CATALOG RECOVERY AREAコマンドを使用すると、リカバリ領域内のすべてのファイルをカタログに追加できます。通常、このコマンドを手動で実行する必要はありません。このコマンドは、制御ファイルをリストアまたは作成する場合などに必要に応じてRMANが自動的に実行するためです。このコマンドは、オペレーティング・システム・ユーティリティによってファイルを高速リカバリ領域にコピーする場合に実行できます。

ディスクの場所内のすべてのファイルをカタログに追加する手順

1. RMANを起動し、ターゲット・データベースおよびリカバリ・カタログ(使用している場合)に接続します。

2. カタログに追加するファイルのディスクの場所を指定して、CATALOGコマンドを実行します。
たとえば、次のコマンドを入力します。

CATALOG START WITH '+disk'; # catalog all files from an ASM disk group
CATALOG START WITH '/fs1/datafiles/'; # catalog all files in directory

注意:
START WITH句では、ワイルド・カードは正しく使用できません。

CATALOG RECOVERY AREAコマンドを使用すると、リカバリ領域内のすべてのファイルをカタログに追加できます。この操作で、RMANリポジトリに表示されていないリカバリ領域内のすべてのファイルが追加されます。次に例を示します。

CATALOG RECOVERY AREA;

3. LISTコマンドを実行し、ファイルがカタログに追加されていることを確認します。

RMANリポジトリからのレコードの削除

この項では、ファイルのレコードをRMANのリポジトリから削除する方法について説明します。

カタログからの削除操作

CHANGE ... UNCATALOGコマンドを実行すると、RMANリポジトリのレコードに次の処理を実行します。

- 制御ファイル・リポジトリのバックアップ・レコードをDELETED状態に更新します。

- 特定のバックアップ・レコードをリカバリ・カタログ(使用している場合)から削除します。

RMANは、指定した物理ファイルは変更しません。これらのファイルのリポジトリ・レコードのみを変更します。

このコマンドは、RMAN以外の方法を使用してバックアップを削除した場合に使用できます。たとえば、オペレーティング・システムのユーティリティを使用してアーカイブREDOログを削除した場合、CHANGE ARCHIVELOG ... UNCATALOGコマンドを発行することによってリポジトリからこのログのレコードを削除します。

オペレーティング・システム・ユーティリティを使用して削除したファイルのレコードの削除

ユーザーがオペレーティング・システム・ユーティリティを使用してバックアップまたはアーカイブREDOログを削除している場合もあります。CROSSCHECKを実行しないかぎり、この削除はRMANでは認識されません。CHANGE ... UNCATALOGコマンドを使用すると、存在しないファイルを反映してRMANリポジトリを更新できます。

バックアップまたはアーカイブREDOログのカタログ・レコードを削除する手順

1. オペレーティング・システムのコマンドを使用してオペレーティング・システムから削除したバックアップに対して、CHANGE ... UNCATALOGを実行します。次の例では、制御ファイルおよびデータファイル1のディスク・コピーへのリポジトリの参照を削除します。

CHANGE CONTROLFILECOPY '/tmp/control01.ctl' UNCATALOG;
CHANGE DATAFILECOPY '/tmp/system01.dbf' UNCATALOG;

2. 任意で、関連するリカバリ・カタログ・ビュー(RC_DATAFILE_COPY、RC_CONTROLFILE_COPYなど)を参照して、指定したレコードが削除されたことを確認します。次の問合せでは、コピー4833のレコードが削除されたことを確認しています。

SELECT CDF_KEY, STATUS
FROM RC_DATAFILE_COPY
WHERE CDF_KEY = 4833;

CDF_KEY    STATUS
---------- ------
0 rows selected.

RMANバックアップおよびアーカイブREDOログの削除

RMANのDELETEコマンドを使用すると、アーカイブREDOログおよびRMANバックアップを削除できます。ディスク上のバックアップの場合、バックアップを削除すると、バックアップ・ファイルがディスクから物理的に削除されます。SBTデバイス上のバックアップの場合、RMANのDELETEコマンドを使用すると、テープ上のバックアップ・ピースまたはプロキシ・コピーを削除するようにメディア・マネージャに指示が行われます。いずれの場合も、削除を反映してRMANのリポジトリが更新されます。

RMANの削除の概要

RMANの各バックアップによって、対応するレコードがRMANリポジトリに作成されます。このレコードは、制御ファイルに格納されます。リカバリ・カタログを使用する場合、リカバリ・カタログを制御ファイルと再同期化すると、レコードはリカバリ・カタログにも格納されます。たとえば、完全なデータベース・バックアップ・セットを生成する場合は、このバックアップ・セットのレコードをV$BACKUP_SETに表示できます。リカバリ・カタログを使用している場合は、RC_BACKUP_SETカタログ・ビューでレコードにアクセスすることもできます。

V$制御ファイル・ビューとリカバリ・カタログ・ビューでは、情報を格納する方法が異なります。この違いが、RMANによるリポジトリ・レコードの処理方法に影響します。リカバリ・カタログのRMANリポジトリは、実際のデータベース表に格納されますが、制御ファイルのRMANリポジトリは、制御ファイルの内部構造に格納されます。

RMANコマンドを使用してバックアップまたはアーカイブREDOログ・ファイルを削除する場合、RMANは次の処理を実行します。

- オペレーティング・システムから物理ファイルを削除します(ファイルが存在する場合)。

- 制御ファイル内のファイル・レコードのステータスをDELETEDに更新します。

- リカバリ・カタログ表からファイル・レコードを削除します(RMANがリカバリ・カタログに接続されている場合)。

制御ファイルのデータは内部構造に格納されているため、RMANは、制御ファイルからレコードを削除できず、レコードのステータスをDELETEDに更新するのみです。ただし、カタログ表は通常のデータベース表であるため、表から行が削除される場合と同様に、カタログ表から行が削除されます。

RMANの削除コマンド

表12-1に、バックアップを削除できるRMANコマンドを示します。

表12-1 RMANの削除コマンド

コマンド

用途

DELETE

バックアップを削除して、制御ファイル・レコードのステータスをDELETEDに更新します。リカバリ・カタログが使用されている場合は、それらのレコードをリカバリ・カタログから削除します。

DELETEによってEXPIREDまたはOBSOLETEのバックアップが削除されるように指定できます。存在しているバックアップにDELETE EXPIREDを実行すると、RMANは警告を発行し、バックアップの削除は行いません。オプションのFORCEキーワードを指定してDELETEコマンドを使用すると、RMANは指定されたバックアップを削除しますが、バックアップがディスクまたはテープから消失している場合に発生するエラーなど、すべてのI/Oエラーを無視します。その後、RMANは、ファイルが削除されたかどうかまたはファイルがすでに欠落していたかどうかに関係なく、バックアップが削除されたという事実を反映してRMANリポジトリを更新します。

RMANは、構成されているすべてのチャネルを使用して削除を実行します。自動チャネル用に構成されていないデバイス上のファイルに対してDELETEを使用する場合は、最初にALLOCATE CHANNEL FOR MAINTENANCEコマンドを使用する必要があります。たとえば、SBTチャネルを使用してバックアップを作成し、ディスク・チャネルのみが構成されている場合は、DELETEに対してSBTチャネルを手動で割り当てる必要があります。ディスクのみのファイルに対してDELETEコマンドを使用する場合は、自動的に割り当てられているメンテナンス・チャネルまたは手動で割り当てられているメンテナンス・チャネルが必要です。

BACKUP ... DELETE [ALL] INPUT

アーカイブ・ログ、データファイルのコピー、またはバックアップ・セットをバックアップして、バックアップが正常に完了した後にオペレーティング・システムから入力ファイルを削除します。RMANは、削除された入力ファイルのリポジトリ・レコードも削除して更新します。

ALLを付けずにDELETE INPUTを指定した場合、RMANは、バックアップする特定のファイルのみを削除します。ALL INPUTを指定した場合、RMANは、RMANリポジトリに記録されている、ファイルのすべてのコピーを削除します。

CHANGE ... UNCATALOG

指定されたバックアップのリカバリ・カタログ・レコードを削除して、制御ファイル・レコードのステータスをDELETEDに変更します。CHANGE ... UNCATALOGコマンドでは、バックアップのRMANリポジトリ・レコードのみが変更され、バックアップは実際には削除されません。

オブジェクトのRMANリポジトリ・レコードが、そのオブジェクトの物理ステータスを反映していない場合があります。たとえば、ディスクにアーカイブREDOログをバックアップした後で、オペレーティング・システム・ユーティリティを使用してそのオブジェクトを削除したとします。最初にCROSSCHECKを実行せずにDELETEを実行すると、リポジトリにログがAVAILABLEと誤って表示されます。RMANリポジトリと物理メディアの間で不一致が発生した場合のDELETEの動作の詳細は、『Oracle Databaseバックアップおよびリカバリ・リファレンス』を参照してください。

RMANを対話形式で実行すると、ファイルを削除する前に確認を求められます。BACKUPコマンドのいずれの形式でも、NOPROMPTキーワードを使用することによって、これらの確認が行われないようにすることができます。

DELETE NOPROMPT ARCHIVELOG ALL;

アーカイブREDOログの削除

「バックアップおよびリポジトリのメンテナンスの基本的な概念」で説明されているように、メンテナンス計画では、高速リカバリ領域、バックアップの保存方針およびアーカイブREDOログの削除方針を構成することをお薦めします。デフォルトでは、アーカイブREDOログの削除方針はNONEに構成されています。この場合、高速リカバリ領域は、ディスクまたはテープに1回以上バックアップされているとき、またはバックアップ保存方針に従ってログが不要になったときに、ログを削除対象であるとみなします。

アーカイブREDOログは、データベースによって自動的に削除されるか、またはユーザーが実行した表12-1に示されているRMANコマンドによって削除されます。リカバリ領域内のログは、データベースによってできるかぎり保存され、ディスク領域が必要になると対象となるログが削除されます。対象となるログは、BACKUP ... DELETE INPUTまたはDELETE ARCHIVELOGを使用して、リカバリ領域の内部または外部のすべての場所から削除できます。これらのコマンドは両方とも、アーカイブREDOログの削除方針の設定がNONE以外のときは、方針に従います。DELETEコマンドでFORCEオプションを使用すると、アーカイブREDOログの削除方針の設定を無効にできます。

関連項目:

- 「アーカイブREDOログの削除方針の構成」

- 方針のオプションの詳細は、『Oracle Databaseバックアップおよびリカバリ・リファレンス』のCONFIGURE ARCHIVELOG DELETION POLICYエントリを参照してください。

すべてのバックアップおよびコピーの削除

状況によっては、データベースに関連付けられているすべてのバックアップ・セット、プロキシ・コピーおよびイメージ・コピーを削除する必要がある場合があります。たとえば、データベースが不要になったため、関連するすべてのファイルをシステムから削除する場合などです。イメージ・コピーは、BACKUP AS COPYコマンドで生成されるファイル、データベースによってアーカイブされるログまたはCATALOGコマンドでカタログに追加されるファイルです。

すべてのバックアップおよびコピーを削除する手順

1. RMANを起動し、ターゲット・データベースおよびリカバリ・カタログ(使用している場合)に接続します。

2. 必要に応じて、削除するバックアップが含まれているデバイス用のメンテナンス・チャネルを割り当てます。
表12-1に示されているように、RMANは、構成されているすべてのチャネルを使用して削除を実行します。チャネルが構成されている場合、メンテナンス・チャネルを手動で割り当てる必要はありません。

3. バックアップおよびコピーをクロスチェックして、論理レコードが物理メディアと同期化されていることを確認します。

CROSSCHECK BACKUP;
CROSSCHECK COPY;

4. バックアップおよびコピーを削除します。
たとえば、次のコマンドを入力し、プロンプトが表示されたらYESと入力します。

DELETE BACKUP;
DELETE COPY;

ディスクおよびテープのチャネルが構成されている場合、RMANは、構成されているSBTチャネルおよび事前構成されているディスク・チャネルの両方を削除時に使用します。RMANは、ファイルを削除する前に確認を求めるプロンプトを表示します。

指定したバックアップおよびコピーの削除

DELETEおよびBACKUP ... DELETEコマンドのいずれを使用しても、特定のバックアップおよびコピーを削除できます。BACKUP ... DELETEコマンドを実行すると、ファイルはまず通常はテープにバックアップされ、その後入力ファイルが削除されます。

DELETEコマンドでは、削除するオブジェクトを識別するための様々なオプションがサポートされています。これらのオプションの詳細は、『Oracle Databaseバックアップおよびリカバリ・リファレンス』を参照してください。RMANは、アーカイブREDOログを削除する場合、構成済の設定を使用して、ログを削除できるかどうかを判断します(「アーカイブREDOログの削除方針の構成」を参照)。

指定したバックアップおよびコピーを削除する手順

1. RMANを起動し、ターゲット・データベースおよびリカバリ・カタログ(使用している場合)に接続します。

2. 必要に応じて、削除するバックアップが含まれているデバイス用のメンテナンス・チャネルを割り当てます。
表12-1に示されているように、RMANは、構成されているすべてのチャネルを使用して削除を実行します。チャネルが構成されている場合、メンテナンス・チャネルを手動で割り当てる必要はありません。

3. 指定したバックアップおよびコピーを削除します。
次の例は、DELETEコマンドを使用して削除するバックアップおよびアーカイブ・ログを指定する一般的な方法を示しています。

- LIST出力の主キーを使用してバックアップを削除します。

DELETE BACKUPPIECE 101;

- ディスク上のファイル名を指定してバックアップを削除します。

DELETE CONTROLFILECOPY '/tmp/control01.ctl';

- アーカイブREDOログを削除します。

DELETE NOPROMPT ARCHIVELOG UNTIL SEQUENCE 300;

- タグに基づいてバックアップを削除します。

DELETE BACKUP TAG 'before_upgrade';

- バックアップされているオブジェクトおよびバックアップが格納されているメディアまたはディスクの場所に基づいてバックアップを削除します。

DELETE BACKUP OF TABLESPACE users DEVICE TYPE sbt; # delete only from tape
DELETE COPY OF CONTROLFILE LIKE '/tmp/%';

- テープにバックアップされているかどうかに基づいて、ディスクからバックアップおよびアーカイブREDOログを削除します。

DELETE ARCHIVELOG ALL
BACKED UP 3 TIMES TO sbt;

BACKUP ... DELETEを使用した指定ファイルの削除

BACKUP ... DELETEを使用すると、アーカイブREDOログ、データファイルのコピー、またはバックアップ・セットをバックアップし、バックアップに成功した後で入力ファイルを削除できます。DELETE INPUTオプションを指定すると、入力ファイルに対してDELETEコマンドを発行した場合と同じ処理が実行されます。「アーカイブREDOログの削除方針の構成」で説明されているように、RMANは、アーカイブREDOログを削除する場合、構成済の設定を使用して、ログを削除できるかどうかを判断します。DELETE ALL INPUT句のALLオプションは、アーカイブREDOログにのみ適用されます。BACKUP ... DELETE ALL INPUTを実行すると、BACKUPコマンドの選択基準を満たすアーカイブREDOログまたはデータファイルのすべてのコピーが削除されます。

期限切れのRMANバックアップおよびコピーの削除

CROSSCHECKを実行し、RMANがファイルの場所を特定できない場合、RMANリポジトリのレコードはEXPIREDステータスに更新されます。その後、DELETE EXPIREDコマンドを使用して、RMANリポジトリから期限切れのバックアップおよびコピーのレコードを削除できます。

EXPIREDとマークされたファイルが実際に存在する場合は、DELETE EXPIREDコマンドによって警告が発行されます。まれに、ファイルが存在する場合でも、リポジトリによってファイルがEXPIREDとマークされる場合があります。たとえば、ファイルが含まれているディレクトリがクロスチェック中に破損し、その後、修復された場合や、メディア・マネージャが適切に構成されておらず、実際には存在するバックアップが存在しないとレポートされる場合などです。

期限切れのリポジトリ・レコードを削除する手順

1. 最近クロスチェックを実行していない場合は、CROSSCHECKコマンドを発行します。たとえば、次のように入力します。

CROSSCHECK BACKUP;

2. 期限切れのバックアップを削除します。たとえば、次のように入力します。

DELETE EXPIRED BACKUP;

保存方針に基づく不要なRMANバックアップの削除

RMANのDELETEコマンドでは、OBSOLETEオプションがサポートされています。このオプションによって、指定されているリカバリ可能性の要件を満たす必要がなくなったバックアップが削除されます。構成済のデフォルトの保存方針、またはDELETE OBSOLETEコマンドにオプションとして指定した他の保存方針に従って、不要とされるファイルを削除できます。DELETEコマンドの他の形式と同様に、削除されたファイルはバックアップ・メディアおよびリカバリ・カタログから削除され、制御ファイル内でDELETEDとしてマーク付けされます。

引数を使用せずにDELETE OBSOLETEコマンドを指定すると、RMANは、構成されている保存方針で定義されているすべての不要なバックアップを削除します。次に例を示します。

DELETE OBSOLETE;

KEEP UNTIL TIMEに指定した期限が切れた場合のDELETE OBSOLETEの動作

アーカイブ・バックアップに対してKEEP UNTIL TIMEに指定した期限が切れていない場合、バックアップは不要とはみなされません。ただし、KEEP UNTILに指定した期限が切れるとすぐに、構成されているバックアップの保存方針に関係なく、バックアップはすぐに不要とみなされます。このため、KEEPに指定した期限が切れた場合、DELETE OBSOLETEを使用すると、BACKUP ... KEEP UNTIL TIMEで作成されたすべてのバックアップが削除されます。

関連項目:
keepOptionの構文については、『Oracle Databaseバックアップおよびリカバリ・リファレンス』を参照してください。

データベースの削除

オペレーティング・システムからデータベースを削除するには、RMANのDROP DATABASEコマンドを使用できます。RMANは、ターゲット・データベースに属しているサーバー・パラメータ・ファイル(データベースに使用されている場合)、すべてのデータファイル、オンラインREDOログおよび制御ファイルを削除します。

DROP DATABASEでは、マウントされたターゲット・データベースにRMANが接続されている必要があります。リカバリ・カタログに接続している必要はありません。RMANをリカバリ・カタログに接続した状態でオプションINCLUDE COPIES AND BACKUPSを指定すると、RMANはデータベースも登録解除します。

データベースを削除する手順

1. RMANを起動し、ターゲット・データベースおよびリカバリ・カタログ(使用している場合)に接続します。

2. データベースに関連付けられているすべてのバックアップをカタログに追加します。たとえば、次のコマンドを実行すると、高速リカバリ領域内のファイルがカタログに追加され、次にセカンダリ・アーカイブ先内のファイルがカタログに追加されます。

CATALOG START WITH '+disk1';    # all files from recovery area on ASM disk
CATALOG START WITH '/arch_dest2';  # all files from second archiving location

3. データベースに関連付けられているすべてのバックアップおよびコピーを削除します。次に例を示します。

DELETE BACKUPSET; # deletes all backups
DELETE COPY; # deletes all image copies (including archived logs)

4. データベースをオペレーティング・システムから削除します。
次のコマンドを実行すると、データベースが削除され、リカバリ・カタログ(使用している場合)から自動的に登録解除されます。RMANによって構成を求められます。

DROP DATABASE;

関連項目:

- SQL文のDROP DATABASEの使用方法については、「SQL*Plusでのデータベースの削除」を参照してください。

- RMANのDROP DATABASEコマンドの構文については、『Oracle Databaseバックアップおよびリカバリ・リファレンス』を参照してください。

13 リカバリ・カタログの管理

この章では、RMANリカバリ・カタログを管理する方法について説明します。このカタログは、1つ以上のターゲット・データベースのRMANリポジトリ・データが含まれているデータベース・スキーマです。この章の内容は次のとおりです。

- リカバリ・カタログの概要

- リカバリ・カタログの作成

- リカバリ・カタログへのデータベースの登録

- リカバリ・カタログへのバックアップの追加

- 仮想プライベート・カタログの作成および管理

- リカバリ・カタログの保護

- ストアド・スクリプトの管理

- リカバリ・カタログのメンテナンス

- リカバリ・カタログの削除

関連項目:

- リカバリ・カタログを使用せずに、制御ファイルに格納されているRMANリポジトリを管理する方法については、第12章「RMANバックアップおよびリポジトリ・レコードのメンテナンス」を参照してください。

- サポートされている相互運用の例は、『Oracle Databaseバックアップおよびリカバリ・リファレンス』の互換性の表を参照してください。

リカバリ・カタログの概要

この項では、リカバリ・カタログの管理に関連する基本的な概念について説明します。

リカバリ・カタログの目的

リカバリ・カタログとは、1つ以上のOracle Databaseに関するメタデータを格納するためにRMANで使用されるデータベース・スキーマのことです。通常、このカタログは専用のデータベースに格納します。リカバリ・カタログには、次のメリットがあります。

- リカバリ・カタログによって、各ターゲット・データベースの制御ファイルに格納されているRMANリポジトリに対して冗長性が作成されます。リカバリ・カタログは、セカンダリ・メタデータ・リポジトリとして機能します。ターゲット制御ファイルおよびすべてのバックアップが消失した場合でも、RMANメタデータはリカバリ・カタログ内に存在します。

- リカバリ・カタログによって、すべてのターゲット・データベースのメタデータが集中化されます。メタデータを1つの場所に格納することによって、レポート・タスクおよび管理タスクの実行が簡単になります。

- リカバリ・カタログには、制御ファイルより長期のメタデータ履歴を格納できます。この機能は、制御ファイルの履歴より前の時点にリカバリする必要がある場合に有効です。リカバリ・カタログ・データベースを使用することによって管理はより複雑になりますが、より長期のバックアップ履歴を使用できるというメリットがあります。

一部のRMAN機能は、リカバリ・カタログを使用する場合にのみ機能します。たとえば、リカバリ・カタログにはRMANスクリプトを格納することができます。ストアド・スクリプトの主なメリットは、ターゲット・データベースおよびリカバリ・カタログに接続可能なRMANクライアントで使用できることです。コマンド・ファイルは、それらが格納されているファイル・システムにRMANクライアントがアクセスできる場合にのみ使用できます。

Data Guard環境でRMANを使用する場合は、リカバリ・カタログが必要です。すべてのプライマリ・データベースおよびスタンバイ・データベースのバックアップ・メタデータを格納すると、カタログによって、バックアップ・タスクを1つのスタンバイ・データベースにオフロードし、その環境内のその他のデータベースにバックアップをリストアできます。

リカバリ・カタログの基本的な概念

リカバリ・カタログには、登録されている各ターゲット・データベースのRMAN操作に関するメタデータが含まれています。RMANは、リカバリ・カタログに接続されると、カタログから排他的にそのメタデータを取得します。このカタログには、次のタイプのメタデータが含まれています。

- データファイルとアーカイブREDOログのバックアップ・セットおよびバックアップ・ピース

- データファイルのコピー

- アーカイブREDOログおよびそのコピー

- データベース構造(表領域およびデータファイル)

- ストアド・スクリプト(ユーザーが作成した一連の名前付きRMANコマンド)

- RMAN構成の永続設定

データベースの登録

RMANで使用するために、リカバリ・カタログにデータベースを記載するプロセスを登録と呼びます。すべてのターゲット・データベースを環境内の単一のリカバリ・カタログに登録することをお薦めします。たとえば、データベースprod1、prod2およびprod3を、データベースcatdbのcatownerが所有する1つのカタログに登録できます。

関連項目:
「リカバリ・カタログへのデータベースの登録」

ベース・リカバリ・カタログでのメタデータの集中化

集中化されたリカバリ・カタログ(ベース・リカバリ・カタログとも呼ばれる)の所有者は、他のデータベース・ユーザーに対してカタログへの制限付きアクセス権限を付与および取り消すことができます。制限付きユーザーは、それぞれ仮想プライベート・カタログと呼ばれる独自のメタデータへの完全な読取り/書込み権限を持っています。RMANメタデータは、仮想プライベート・カタログ所有者のスキーマに格納されます。ベース・リカバリ・カタログの所有者は、各仮想プライベート・カタログ・ユーザーがアクセスできるオブジェクトを決定します。

リカバリ・カタログは、様々なバージョンのOracle Databaseを使用している環境、または使用してきた環境で使用できます。その結果、様々なバージョンのRMANクライアント、リカバリ・カタログ・データベース、リカバリ・カタログ・スキーマおよびターゲット・データベースが環境内に存在する可能性があります。複数のリカバリ・カタログ・スキーマを1つにマージする方法については、「リカバリ・カタログのインポートおよび移動」を参照してください。

関連項目:
「仮想プライベート・カタログの作成および管理」

リカバリ・カタログの再同期化

バックアップ、リストア、クロスチェックなどのRMAN操作では、RMANによって常に最初に制御ファイルが更新され、次にメタデータがリカバリ・カタログに伝播されます。マウントされた制御ファイルからリカバリ・カタログへのメタデータのこのフローは、リカバリ・カタログの再同期化と呼ばれます。これによって、RMANが制御ファイルから取得するメタデータが現行のものになります。

関連項目:
「リカバリ・カタログの再同期化」

ストアド・スクリプト

ストアド・スクリプトは、制御ファイルの代替として、頻繁に使用する一連のRMANコマンドの管理に使用できます。 このスクリプトは、ファイル・システムではなくリカバリ・カタログに格納されます。

ローカル・ストアド・スクリプトは、作成時にRMANが接続していたターゲット・データベースに関連付けられます。スクリプトは、関連付けられたターゲット・データベースに接続している場合にのみ実行できます。グローバル・ストアド・スクリプトは、リカバリ・カタログに登録されているすべてのデータベースに対して実行できます。仮想プライベート・カタログ・ユーザーは、グローバル・スクリプトへの読取り専用アクセス権限を持っています。グローバル・スクリプトの作成または更新は、ベース・リカバリ・カタログへの接続中に実行する必要があります。

関連項目:
「ストアド・スクリプトの管理」

Data Guard環境でのリカバリ・カタログ

「Data Guard環境でのRMAN」で説明されているように、Data Guard環境内のすべての物理データベース(プライマリ・データベースとスタンバイ・データベースの両方)のRMANメタデータを管理するには、リカバリ・カタログを使用する必要があります。RMANは、Data Guard環境の実情の単一のソースとしてリカバリ・カタログを使用します。

RMANは、逆再同期化で、リカバリ・カタログを使用してプライマリまたはスタンバイ制御ファイルを更新できます。この場合、メタデータのフローの方向は、制御ファイルからカタログではなく、カタログから制御ファイルになります。RMANは、再同期化が必要なほぼすべての場合に、再同期化を自動的に実行します。そのため、RESYNCコマンドを使用して手動で再同期化する必要がある機会はあまり多くありません。

関連項目:
スタンバイ・データベースで使用するためにRMAN環境を構成する方法については、『Oracle Data Guard概要および管理』を参照してください。

リカバリ・カタログの管理の基本手順

リカバリ・カタログをRMANで使用できるように設定する基本手順は次のとおりです。

1. リカバリ・カタログを作成します。
このタスクの実行方法については、「リカバリ・カタログの作成」を参照してください。

2. リカバリ・カタログにターゲット・データベースを登録します。
この手順によって、RMANはターゲット・データベースに関するメタデータをリカバリ・カタログに格納できます。このタスクについては、「リカバリ・カタログへのデータベースの登録」を参照してください。

3. 必要に応じて、ターゲット制御ファイルに格納されていないレコードが含まれている古いバックアップをカタログに追加します。
このタスクの実行方法については、「リカバリ・カタログへのバックアップの追加」を参照してください。

4. 必要に応じて、特定のユーザー用の仮想プライベート・カタログを作成し、そのユーザーがアクセスできるメタデータを指定します。
このタスクの実行方法については、「仮想プライベート・カタログの作成および管理」を参照してください。

5. バックアップおよびリカバリ計画に含めることによって、リカバリ・カタログを保護します。
カタログをバックアップおよびリカバリする方法および可用性を向上させる方法については、「リカバリ・カタログの保護」を参照してください。

この章の残りでは、リカバリ・カタログの使用開始後、そのリカバリ・カタログを管理する方法について説明します。次のタスクを実行できます。

- RMANスクリプトをリカバリ・カタログに格納して管理する方法については、「ストアド・スクリプトの管理」を参照してください。

- RMAN操作に関してレポートする方法については、第11章「RMAN操作に関するレポート」を参照してください。LISTおよびREPORTコマンドは、リカバリ・カタログを使用しているかどうかに関係なく使用できます。リカバリ・カタログ内の固定ビューによってRMAN操作に関してレポートする方法については、「リカバリ・カタログ・ビューの問合せ」を参照してください。

- 実行中のリカバリ・カタログのメンテナンスでの様々なタスク(1つのリカバリ・カタログを別のリカバリ・カタログにインポートするタスクなど)については、「リカバリ・カタログのメンテナンス」を参照してください。

リカバリ・カタログをメンテナンスしない場合は、「リカバリ・カタログの削除」を参照してください。

リカバリ・カタログの作成

この項では、リカバリ・カタログ作成時の各フェーズについて説明します。この項の内容は、次のとおりです。

- リカバリ・カタログ・データベースの構成

- リカバリ・カタログのスキーマ所有者の作成

- CREATE CATALOGコマンドの実行

リカバリ・カタログ・データベースの構成

RMANでリカバリ・カタログを使用する場合、リカバリ・カタログ・スキーマを保持する必要があります。リカバリ・カタログは、スキーマのデフォルト表領域に格納されます。SYSユーザーはリカバリ・カタログ所有者に設定できません。

リカバリ・カタログ・スキーマをインストールするために使用するデータベースおよびそのデータベースのバックアップ方法を決定します。また、カタログ・データベースをARCHIVELOGモード(推奨)で動作させるかどうかを決定します。

注意:
ターゲット・データベースを使用して、リカバリ・カタログのデータベースとしてバックアップしないでください。リカバリ・カタログは、ターゲット・データベースが消失した場合に保護される必要があります。

リカバリ・カタログ・スキーマのサイズの計画

カタログ・スキーマによって使用される領域を割り当てる必要があります。リカバリ・カタログ・スキーマのサイズは、カタログによって監視されるデータベースの数によって異なります。スキーマは、アーカイブREDOログ・ファイルおよび各データベースのバックアップの増加とともに増大します。カタログに格納されているRMANストアド・スクリプトを使用する場合は、これらのスクリプトに対して領域を割り当てる必要があります。

たとえば、trgtデータベースにファイルが100個あり、このデータベースを1日に1回バックアップして、それぞれ1つのバックアップ・ピースを含む50個のバックアップ・セットを作成すると想定します。バックアップ・ピース表内の各行が領域を最大限に使用すると想定すると、1回の日次バックアップによってリカバリ・カタログ内で使用される領域は170KB未満です。この日次バックアップを1年間行うと、この期間中に使用される合計記憶域は約62MBです。これとほぼ同じ量の記憶域がアーカイブ・ログに使用されると想定されます。したがって、最悪の場合はメタデータの格納に1年間で約120MBが必要になります。バックアップ・ピースの行領域の一部のみを使用する通常の状況の場合、現実的な値は年間15MBです。

リカバリ・カタログに複数のデータベースの登録を予定している場合、前述の計算に従って各データベースに必要な領域を足し、リカバリ・カタログ・スキーマのデフォルト表領域の合計サイズを算出してください。

リカバリ・カタログ・データベースのディスク領域の割当て

リカバリ・カタログを既存のデータベース内に作成する場合、リカバリ・カタログ・スキーマ用のデフォルト表領域を保持できる十分な空き領域を追加します。リカバリ・カタログを格納するための新しいデータベースを作成する場合、リカバリ・カタログ・スキーマ自体の領域に加えて、次に示すリカバリ・カタログ・データベース内の他のファイル用の領域も考慮します。

- SYSTEM表領域およびSYSAUX表領域

- 一時表領域

- UNDO表領域

- オンラインREDOログ・ファイル

リカバリ・カタログ・データベース内の領域の大部分は、SYSTEM表領域、一時表領域、UNDO表領域などの表領域をサポートするために使用されます。表13-1に、一般的な領域要件を示します。

表13-1 1年間での一般的なリカバリ・カタログ領域要件

領域タイプ

領域要件

SYSTEM表領域

90MB

一時表領域

5MB

ロールバック表領域またはUNDO表領域

5MB

リカバリ・カタログ表領域

リカバリ・カタログに登録されたデータベースごとに15MB

オンラインREDOログ

ログごとに1MB(3グループ、各グループに2メンバー)

注意:
リカバリ・カタログとターゲット・データベースが同じディスク上に存在していないことを確認してください。リカバリ・カタログとターゲット・データベースの両方にハード・ディスク障害が発生した場合、リカバリ・プロセスがより困難になります。可能な場合、他の手段を利用し、リカバリ・カタログ・データベースとバックアップ対象のデータベースの共通の致命的な障害箇所を排除してください。

リカバリ・カタログのスキーマ所有者の作成

リカバリ・カタログ・データベースを選択して必要な領域を作成した後、リカバリ・カタログの所有者を作成し、そのユーザーに必要な権限を付与します。後続の項に示す手順では、次の状況を想定しています。

- ユーザーSYSは、catdbリカバリ・カタログ・データベースに対するSYSDBA権限を持っています。

- catdbリカバリ・カタログ・データベース内のtoolsという表領域にリカバリ・カタログが格納されています。RMANの予約語を表領域名として使用する場合、その語を引用符で囲み、大文字を使用する必要があります。(RMANの予約語のリストは、『Oracle Databaseバックアップおよびリカバリ・リファレンス』を参照してください。)

- tempという表領域が、リカバリ・カタログ・データベース内に存在します。

リカバリ・カタログ・データベース内にリカバリ・カタログ・スキーマを作成する手順

1. SQL*Plusを起動し、リカバリ・カタログを含むデータベースに管理者権限で接続します。この例では、データベースはcatdbです。

2. リカバリ・カタログのユーザーおよびスキーマを作成します。たとえば、次のSQL文を入力できます(passwordはユーザー定義のパスワードに置き換えます)。

CREATE USER rman IDENTIFIED BY password
TEMPORARY TABLESPACE temp
DEFAULT TABLESPACE tools
QUOTA UNLIMITED ON tools;

注意:
安全なパスワードを作成してください。詳細は、『Oracle Databaseセキュリティ・ガイド』を参照してください。

3. スキーマ所有者にRECOVERY_CATALOG_OWNERロールを付与します。このロールによって、リカバリ・カタログのメンテナンスおよび問合せに必要なすべての権限がユーザーに付与されます。

GRANT RECOVERY_CATALOG_OWNER TO rman;

CREATE CATALOGコマンドの実行

カタログ所有者の作成後、RMANのCREATE CATALOGコマンドを使用してカタログ表を作成します。このコマンドを実行すると、カタログ所有者のデフォルト表領域内にカタログが作成されます。

リカバリ・カタログを作成する手順

1. RMANを起動し、カタログを格納するデータベースに接続します。データベースには、リカバリ・カタログ所有者として接続します。

2. CREATE CATALOGコマンドを実行してカタログを作成します。カタログの作成には数分かかります。カタログ表領域がこのユーザーのデフォルト表領域の場合、次のコマンドを実行できます。

RMAN> CREATE CATALOG;

CREATE CATALOGコマンドでカタログの表領域名を指定できます。次に例を示します。

RMAN> CREATE CATALOG TABLESPACE cat_tbs;

注意:
リカバリ・カタログに使用する表領域名がRMANの予約語である場合は、その予約語を大文字にして引用符で囲む必要があります。次に例を示します。

CREATE CATALOG TABLESPACE 'CATALOG';

3. 結果を確認するには、SQL*Plusを使用し、リカバリ・カタログを問い合せて作成された表を表示します。

SQL> SELECT TABLE_NAME FROM USER_TABLES;

関連項目:
GRANTおよびCREATE USER文のSQL構文については、『Oracle Database SQL言語リファレンス』を参照してください。CREATE CATALOGコマンドの構文については、『Oracle Databaseバックアップおよびリカバリ・リファレンス』を参照してください。

リカバリ・カタログへのデータベースの登録

この項では、リカバリ・カタログでターゲット・データベース・レコードをメンテナンスする方法について説明します。この章の内容は、次のとおりです。

- リカバリ・カタログへのデータベースの登録

- REGISTER DATABASEコマンドを使用したデータベースの登録

リカバリ・カタログへのデータベースの登録

リカバリ・カタログにターゲット・データベースを記載するプロセスを登録と呼びます。ターゲット・データベースがリカバリ・カタログに登録されていない場合、RMANは、カタログを使用して操作に関するメタデータをそのデータベースに格納できません。登録されていないデータベースでも、RMAN操作を実行することはできます。RMANは、そのメタデータを常にターゲット・データベースの制御ファイルに格納するためです。

Data Guard環境でリカバリ・カタログを使用していない場合は、REGISTERコマンドを使用して各データベースを登録します。各データベースには、一意のDBIDが必要です。RMANのDUPLICATEコマンドまたはSQLのCREATE DATABASE文を使用すると、データベースに一意のDBIDが自動的に割り当てられます。その他の方法でデータベースを作成すると、コピーされたデータベースのDBIDとソース・データベースのDBIDが同じになる場合があります。ソース・データベースとコピー・データベースを同じカタログに登録できるように、DBNEWIDユーティリティを使用してDBIDを変更できます。

UNREGISTERコマンドを使用すると、リカバリ・カタログからデータベースの登録を解除できます。

スタンバイ・データベースの登録

Data Guard環境では、プライマリ・データベースとスタンバイ・データベースは同じDBIDおよびデータベース名を共有します。Data Guard環境のデータベースをリカバリ・カタログに登録できるようにするには、各データベースに異なるDB_UNIQUE_NAME値が必要です。データベースのDB_UNIQUE_NAMEパラメータは、その初期化パラメータ・ファイルに設定されています。

Data Guard環境でRMANを使用する場合は、プライマリ・データベースに対してのみREGISTER DATABASEコマンドを使用できます。次の方法を使用すると、スタンバイ・データベースをリカバリ・カタログに登録できます。

- TARGETとしてスタンバイ・データベースに接続すると、RMANによってデータベースがリカバリ・カタログに自動的に登録されます。

- リカバリ・カタログで認識されないスタンバイ・データベースに対してCONFIGURE DB_UNIQUE_NAMEコマンドを実行する場合、RMANは、対応するプライマリ・データベースが登録されていれば、このスタンバイ・データベースを自動的に登録します。

関連項目:

- 「リカバリ・カタログからのターゲット・データベースの登録の解除」

- DUPLICATEコマンドの構文については、『Oracle Databaseバックアップおよびリカバリ・リファレンス』を参照してください。

- DBNEWIDユーティリティを使用してDBIDを変更する方法については、『Oracle Databaseユーティリティ』を参照してください。

- Data Guard環境でのRMANの使用方法については、『Oracle Data Guard概要および管理』を参照してください。

REGISTER DATABASEコマンドを使用したデータベースの登録

ターゲット・データベースでリカバリ・カタログを使用するには、まずそのターゲット・データベースをリカバリ・カタログに登録します。Data Guard環境でカタログを使用する場合は、この方法でプライマリ・データベースのみを登録できます。

次の手順を実行します。

1. RMANを起動し、ターゲット・データベースおよびリカバリ・カタログに接続します。リカバリ・カタログ・データベースはオープンされている必要があります。
たとえば、ネット・サービス名catdbを使用してカタログ・データベースにユーザーrman(カタログ・スキーマ所有者)として接続するには、次のコマンドを発行します。

% rman TARGET / CATALOG rman@catdb

2. ターゲット・データベースをマウントしていない場合、マウントまたはオープンします。

STARTUP MOUNT;

3. 接続しているリカバリ・カタログに、ターゲット・データベースを登録します。

REGISTER DATABASE;

RMANは、カタログ表内に、ターゲット・データベースに関する情報を格納する行を作成し、ターゲット・データベースに関連するすべてのデータを制御ファイルからカタログにコピーし、カタログと制御ファイルを同期化します。

4. REPORT SCHEMAを実行し、正常に登録されたことを確認します。

REPORT SCHEMA;

Report of database schema
File Size(MB)   Tablespace       RB segs Datafile Name
---- ---------- ---------------- ------- -------------------
1        307200 SYSTEM             NO    /oracle/oradata/trgt/system01.dbf
2         20480 UNDOTBS            YES   /oracle/oradata/trgt/undotbs01.dbf
3         10240 CWMLITE            NO    /oracle/oradata/trgt/cwmlite01.dbf
4         10240 DRSYS              NO    /oracle/oradata/trgt/drsys01.dbf
5         10240 EXAMPLE            NO    /oracle/oradata/trgt/example01.dbf
6         10240 INDX               NO    /oracle/oradata/trgt/indx01.dbf
7         10240 TOOLS              NO    /oracle/oradata/trgt/tools01.dbf
8         10240 USERS              NO    /oracle/oradata/trgt/users01.dbf

リカバリ・カタログへのバックアップの追加

データファイルのコピー、バックアップ・ピースまたはアーカイブ・ログがディスクに存在する場合、CATALOGコマンドを使用して、それらをリカバリ・カタログに追加できます。リカバリ・カタログを使用する場合、制御ファイルからエージ・アウトされたバックアップをカタログに追加すると、リストア操作中に、その古いバックアップが使用されます。次のコマンドは、この方法を示しています。

CATALOG DATAFILECOPY '/disk1/old_datafiles/01_01_2003/users01.dbf';
CATALOG ARCHIVELOG '/disk1/arch_logs/archive1_731.dbf',
'/disk1/arch_logs/archive1_732.dbf';
CATALOG BACKUPPIECE '/disk1/backups/backup_820.bkp';

また、CATALOG START WITHコマンドを使用して、1つのディレクトリ内の複数のバックアップ・ファイルを一度にカタログに追加できます。次に例を示します。

CATALOG START WITH '/disk1/backups/';

RMANによって、RMANリポジトリに追加されるファイルが表示され、それらのバックアップが追加される前に確認するように求められます。CATALOG START WITHで接頭辞を指定する場合は注意が必要です。RMANは、ディスク上で、指定された接頭辞が付いたすべてのパスのすべてのファイルをスキャンします。接頭辞は、通常のディレクトリ名ではありません。不適切な接頭辞を使用すると、不適切なファイル・セットがカタログに追加される場合があります。

たとえば、/disk1/backups、/disk1/backups-year2003、/disk1/backupsets、/disk1/backupsets/testなどの一連のディレクトリにバックアップ・ファイルが含まれているとします。次のコマンドを実行すると、これらのすべてのディレクトリ内のすべてのファイルがカタログに追加されます。/disk1/backupsが、これらのすべてのディレクトリへのパスの接頭辞であるためです。

CATALOG START WITH '/disk1/backups';

/disk1/backupsディレクトリ内のバックアップのみをカタログに追加するには、次のコマンドが適切です。

CATALOG START WITH '/disk1/backups/';

関連項目:

- REGISTERの構文については、『Oracle Databaseバックアップおよびリカバリ・リファレンス』を参照してください。

- データベースの移行に関する問題については、『Oracle Databaseアップグレード・ガイド』を参照してください。

仮想プライベート・カタログの作成および管理

仮想プライベート・カタログ

デフォルトでは、RMANのリカバリ・カタログの全ユーザーは、カタログのすべてのメタデータを挿入、更新および削除する完全な権限を持ちます。たとえば、2つの関連のないデータベースの管理者が同じリカバリ・カタログを共有している場合、各管理者は、誤ってまたは意図的に、もう一方の管理者のデータベース用のカタログ・データを破壊することができます。多くの企業では、同じ担当者が多くの異なるデータベースを管理し、そのリカバリ・カタログも管理するため、この状況が許容されています。ただし、その他の企業では、様々なデータベースの管理者の間、およびDBAとリカバリ・カタログの管理者の間に、明確な責務の分離が存在しており、このような企業では、各データベース管理者が、担当のデータベースに属するバックアップ・メタデータのみを変更するように制限すると同時に、単一の中央管理されたRMANリカバリ・カタログによるメリットも保つ必要がある場合があります。 この目的は、仮想プライベート・カタログを実装することによって達成できます。

すべての11gのリカバリ・カタログは、仮想プライベート・カタログをサポートしていますが、仮想プライベート・カタログは、明示的に作成しないと使用されません。1つのリカバリ・カタログに対して作成できる仮想プライベート・カタログの数に、制限はありません。各仮想プライベート・カタログは、データベース・スキーマのユーザーによって所有されます。このユーザーは、リカバリ・カタログを所有するユーザーとは異なります。

1つ以上の仮想プライベート・カタログを作成した後、その後の指示に従って、リカバリ・カタログの管理者は、各仮想プライベート・カタログに対して、リカバリ・カタログに現在登録されている1つ以上のデータベースにそのカタログを使用する権限を付与します。リカバリ・カタログの管理者は、仮想プライベート・カタログの使用中に新しいデータベースを登録する権限を付与することもできます。

注意:
各仮想プライベート・カタログは、すべてのグローバル・ストアド・スクリプト、および仮想プライベート・カタログが権限を持つデータベースに属する非グローバル・ストアド・スクリプトにアクセスできます。 仮想プライベート・カタログは、権限を持たないデータベースに属する非グローバル・ストアド・スクリプトにはアクセスできません。また、グローバル・ストアド・スクリプトを作成することはできません。

仮想プライベート・カタログを作成する基本的な手順は次のとおりです。

1. 仮想プライベート・カタログを所有するデータベース・ユーザーを作成し(このユーザーが存在しない場合)、このユーザーにアクセス権限を付与します。
このタスクについては、「仮想プライベート・カタログ所有者の作成および権限の付与」を参照してください。

2. 仮想プライベート・カタログを作成します。
このタスクについては、「仮想プライベート・カタログの作成」を参照してください。

仮想プライベート・カタログの作成後に、必要に応じてカタログ・アクセス権限を取り消すことができます。このタスクについては、「仮想プライベート・カタログ所有者からの権限の取消し」を参照してください。仮想プライベート・カタログを削除する方法については、「仮想プライベート・カタログの削除」を参照してください。

リカバリ・カタログが仮想プライベート・カタログの場合、これに接続しているRMANクライアントは、パッチ・レベル10.1.0.6または10.2.0.3である必要があります。Oracle9iのRMANクライアントは、仮想プライベート・カタログに接続できません。ベース・カタログに仮想プライベート・カタログ・ユーザーが含まれている場合でも、Oracle Database 11gのベース・リカバリ・カタログへのRMANクライアントの接続は、このバージョン制限の影響を受けません。

関連項目:
RMANのバージョン互換性の詳細は、『Oracle Databaseバックアップおよびリカバリ・リファレンス』を参照してください。

仮想プライベート・カタログ所有者の作成および権限の付与

この項では、ベース・リカバリ・カタログは作成済であると想定しています。

データベースprod1、prod2およびprod3がベース・リカバリ・カタログに登録されていると想定します。ベース・リカバリ・カタログを所有するデータベース・ユーザーはcatownerです。データベース・ユーザーvpc1を作成し、このユーザーにprod1およびprod2のみへのアクセス権限を付与します。デフォルトでは、仮想プライベート・カタログ所有者にベース・リカバリ・カタログへのアクセス権限はありません。

仮想プライベート・カタログ所有者を作成し、権限を付与する手順

1. SQL*Plusを起動し、管理者権限でリカバリ・カタログ・データベースに接続します。

2. 仮想プライベート・カタログを所有するユーザーが存在しない場合は作成します。
たとえば、カタログを所有するデータベース・ユーザーvpc1を作成する場合は、次のコマンドを実行します(passwordはユーザー定義のパスワードに置き換えます)。

SQL> CREATE USER vpc1 IDENTIFIED BY password
2  DEFAULT TABLESPACE vpcusers
3  QUOTA UNLIMITED ON vpcusers;

注意:
安全なパスワードを作成してください。詳細は、『Oracle Databaseセキュリティ・ガイド』を参照してください。

3. 仮想カタログを所有するデータベース・ユーザーにRECOVERY_CATALOG_OWNERロールを付与し、SQL*Plusを終了します。
次の例では、ユーザーvpc1にロールを付与します。

SQL> GRANT recovery_catalog_owner TO vpc1;
SQL> EXIT;

4. RMANを起動し、(仮想プライベート・カタログ所有者ではなく)ベース・リカバリ・カタログ所有者としてリカバリ・カタログ・データベースに接続します。
次の例では、catownerとしてベース・リカバリ・カタログに接続します。

% rman
RMAN> CONNECT CATALOG catowner@catdb;

recovery catalog database Password: password
connected to recovery catalog database

5. 仮想プライベート・カタログ所有者に目的の権限を付与します。
次の例では、prod1およびprod2(prod3は対象外)に関するメタデータへのアクセス権限をユーザーvpc1に付与します。

RMAN> GRANT CATALOG FOR DATABASE prod1 TO vpc1;
RMAN> GRANT CATALOG FOR DATABASE prod2 TO vpc1;

データベース名ではなくDBIDを使用することもできます。仮想プライベート・カタログ・ユーザーには、リカバリ・カタログに登録されている他のデータベースに関するメタデータへのアクセス権限はありません。

新しいターゲット・データベースをリカバリ・カタログに登録する機能をユーザーに付与することもできます。次に例を示します。

RMAN> GRANT REGISTER DATABASE TO vpc1;

仮想プライベート・カタログの作成

この項では、仮想プライベート・カタログ所有者にRECOVERY_CATALOG_OWNERデータベース・ロールが付与されていると想定しています。また、ベース・リカバリ・カタログ所有者がGRANTコマンドを使用して、ベース・リカバリ・カタログ内のメタデータへのアクセス権限を仮想プライベート・カタログ所有者に付与しています。

仮想プライベート・カタログを作成する手順

1. RMANを起動し、(ベース・リカバリ・カタログ所有者ではなく)仮想プライベート・リカバリ・カタログ所有者としてリカバリ・カタログ・データベースに接続します。
次の例では、vpc1としてリカバリ・カタログに接続します。

% rman
RMAN> CONNECT CATALOG vpc1@catdb;

2. 仮想プライベート・カタログを作成します。
次のコマンドによって仮想プライベート・カタログが作成されます。

RMAN> CREATE VIRTUAL CATALOG;

3. この仮想プライベート・カタログで10.2以前のリリースのRMANを使用する場合は、次のPL/SQLプロシージャを実行します(base_catalog_ownerは、ベース・リカバリ・カタログを所有するデータベース・ユーザーです)。

SQL> EXECUTE base_catalog_owner.DBMS_RCVCAT.CREATE_VIRTUAL_CATALOG;

仮想プライベート・カタログ所有者からの権限の取消し

この項では、仮想プライベート・カタログを作成していると想定しています。

2つのデータベースprod1およびprod2がベース・リカバリ・カタログに登録されていると想定します。ベース・リカバリ・カタログの所有者として、vpc1ユーザーにprod1へのアクセス権限を付与しています。また、このユーザーには、仮想プライベート・カタログにデータベースを登録する権限も付与しています。ここで、vpc1から権限を取り消します。

仮想プライベート・カタログ所有者から権限を取り消す手順

1. RMANを起動し、(仮想プライベート・カタログ所有者ではなく)リカバリ・カタログ所有者としてリカバリ・カタログ・データベースに接続します。
次の例では、catownerとしてリカバリ・カタログに接続します。

% rman
RMAN> CONNECT CATALOG catowner@catdb;

2. 指定した権限を仮想プライベート・カタログ所有者から取り消します。
次のコマンドによって、prod1に関するメタデータへのアクセス権限が仮想プライベート・カタログ所有者vpc1から取り消されます。

REVOKE CATALOG FOR DATABASE prod1 FROM vpc1;

データベース名ではなくDBIDを指定することもできます。カタログvpc1は、付与されているその他のすべてのカタログ権限を保持します。

新しいターゲット・データベースをリカバリ・カタログに登録する権限を取り消すこともできます。次に例を示します。

REVOKE REGISTER DATABASE FROM vpc1;

仮想プライベート・カタログの削除

この項では、仮想プライベート・カタログを作成しており、この時点でこれを削除すると想定しています。仮想プライベート・カタログを削除する場合、ベース・リカバリ・カタログ自体は削除しません。ベース・リカバリ・カタログを参照するシノニムおよびビューのみを削除します。

仮想プライベート・カタログを削除する手順

1. RMANを起動し、(ベース・リカバリ・カタログ所有者ではなく)仮想プライベート・リカバリ・カタログ所有者としてリカバリ・カタログ・データベースに接続します。
次の例では、ユーザーvpc1としてリカバリ・カタログに接続します。

% rman
RMAN> CONNECT CATALOG vpc1@catdb;

2. カタログを削除します。
Oracle Database 11g以上のRMAN実行可能ファイルを使用している場合は、DROP CATALOGコマンドを使用して仮想プライベート・カタログを削除します。

RMAN> DROP CATALOG;

Oracle Database 10g以前のRMAN実行可能ファイルを使用している場合は、DROP CATALOGコマンドは使用できません。かわりに、仮想プライベート・カタログ・ユーザーとしてSQL*Plusをカタログ・データベースに接続してから、次のPL/SQLプロシージャを実行します(base_catalog_ownerは、ベース・リカバリ・カタログを所有するデータベース・ユーザーです)。

SQL> EXECUTE base_catalog_owner.DBMS_RCVCAT.DELETE_VIRTUAL_CATALOG;

リカバリ・カタログの保護

バックアップおよびリカバリ計画には、リカバリ・カタログ・データベースも含める必要があります。リカバリ・カタログをバックアップしないと、ディスク障害が発生してリカバリ・カタログ・データベースが破損した場合、カタログ内のメタデータが消失する場合があります。リカバリ・カタログの内容がない場合は、その他のデータベースのリカバリがより困難になる可能性があります。

リカバリ・カタログのバックアップ

1つのリカバリ・カタログには、複数のターゲット・データベースに関するメタデータを格納できます。したがって、リカバリ・カタログが消失すると、重大な問題が発生する可能性があります。リカバリ・カタログは、頻繁にバックアップしてください。この項では、リカバリ・カタログを保護する計画を作成するための一般的なガイドラインについて説明します。

リカバリ・カタログの頻繁なバックアップ

リカバリ・カタログ・データベースは他のデータベースと同様のデータベースであり、バックアップおよびリカバリ計画に含める必要があります。リカバリ・カタログは、データベースの他の部分と同様にバックアップして保護してください。リカバリ・カタログ・データベースのバックアップは、全体的なバックアップおよびリカバリの一環として計画する必要があります。

リカバリ・カタログのバックアップは、ターゲット・データベースのバックアップと同じ頻度で行います。たとえば、ターゲット・データベース全体のバックアップを週1回行う場合、ターゲット・データベースのバックアップ後にリカバリ・カタログをバックアップします。リカバリ・カタログのこのバックアップは、障害リカバリに役立ちます。制御ファイルの自動バックアップを使用してリカバリ・カタログ・データベースをリストアする必要がある場合も、リストアしたリカバリ・カタログ・データベース内の完全なバックアップ・レコードを使用すると、ターゲット・データベースをリストアできます。

適切な物理バックアップ方法の選択

リカバリ・カタログ・データベースのバックアップは、RMANを使用して実行できます。図13-1に示すように、RMANのリポジトリがカタログ・データベースの制御ファイルになるように、NOCATALOGオプションを指定してRMANを起動します。

図13-1 リカバリ・カタログのバックアップのリポジトリとしての制御ファイルの使用

RMANを使用したリカバリ・カタログ・データベースのバックアップを計画する場合、次のガイドラインに従います。

- 必要に応じてPoint-in-Timeリカバリを実行できるように、リカバリ・カタログ・データベースをARCHIVELOGモードで実行します。

- 保存方針として、REDUNDANCY値を1より大きい値に設定します。

- データベースを2つの異なるメディア(ディスクとテープなど)にバックアップします。

- BACKUP DATABASE PLUS ARCHIVELOGを、使用可能な場合はメディア・マネージャに、メディア・マネージャが使用不可の場合はディスクのみに定期的に実行します。

- 別のリカバリ・カタログをバックアップのリポジトリに使用しないでください。

- 制御ファイルの自動バックアップ機能をONに設定します。

この方法では、制御ファイルの自動バックアップ機能によって、この機能が使用可能なかぎり確実にリカバリ・カタログ・データベースがリカバリされます。

関連項目:
制御ファイルの自動バックアップを使用したリカバリの詳細は、「障害リカバリの実行」を参照してください。

ターゲット・データベースからのリカバリ・カタログの分離

リカバリ・カタログは、そのカタログが保護するデータとは別の場所に格納されている場合にのみ有効です。そのため、データベースのRMANリポジトリを含むリカバリ・カタログは、ターゲット・データベースと同じデータベースには格納しないでください。また、カタログ・データベースはターゲット・データベースと同じディスクに格納しないでください。

データの分離をお薦めする理由を説明するために、データベースprod1のカタログをprod1に格納したとします。prod1にメディア全体の障害が発生したときに、prod1のリカバリ・カタログもprod1に格納されていた場合、データベースが消失すると、リカバリ・カタログも同様に消失します。この場合の対応策は1つのみです。リカバリ・カタログに格納されている情報を使用せずに、prod1の制御ファイルの自動バックアップをリストアして使用して、データベースのリストアおよびリカバリを実行する必要があります。

論理バックアップ用のリカバリ・カタログ・データのエクスポート

データ・ポンプ・エクスポート・ユーティリティを使用してRMANリカバリ・カタログの論理バックアップを作成しておくと、物理バックアップの有効な補助バックアップとなります。リカバリ・カタログ・データベースが破損した場合、データ・ポンプ・インポートを使用して、エクスポートされたリカバリ・カタログ・データを別のデータベースに再インポートすることで、カタログを迅速に再構築できます。

リカバリ・カタログのリカバリ

リカバリ・カタログ・データベースのリストアおよびリカバリは、RMANを使用して他のデータベースをリストアおよびリカバリする場合とほぼ同様です。リカバリ・カタログ・データベースの制御ファイルおよびサーバー・パラメータ・ファイルを自動バックアップからリストアし、その後、データベースの残りの部分のリストアおよび完全リカバリを実行できます。複数のリカバリ・カタログを使用している場合、別のリカバリ・カタログを使用して、このリカバリ・カタログ・データベースのバックアップに関するメタデータを記録することもできます。

通常のOracleのリカバリ手順によるリカバリ・カタログ・データベースのリカバリが実行不可能である場合は、カタログを再作成する必要があります。最悪の場合の例を次に示します。

- リカバリ・カタログ・データベースを一度もバックアップしていない。

- リカバリ・カタログ・データベースをバックアップしているが、データファイルのバックアップまたはアーカイブ・ログが使用不可であるためリカバリできない。

欠落しているリカバリ・カタログの内容を部分的に再作成するには、次の方法があります。

- RESYNC CATALOGコマンドを使用して、ターゲット・データベースの制御ファイルまたは制御ファイルのコピーからのRMANリポジトリ情報でリカバリ・カタログを更新します。制御ファイルからエージ・アウトされた制御ファイル・レコードに含まれているメタデータは消失します。

- CATALOG START WITH ... コマンドを発行して、使用可能なバックアップをカタログに再度追加します。

この最悪の状況が発生する可能性を最小限に抑えるには、バックアップ計画に少なくともリカバリ・カタログのバックアップを含める必要があります。この方法については、「リカバリ・カタログのバックアップ」を参照してください。

関連項目:

- CATALOGコマンドの詳細は、『Oracle Databaseバックアップおよびリカバリ・リファレンス』を参照してください。

- CROSSCHECKコマンドの詳細は、『Oracle Databaseバックアップおよびリカバリ・リファレンス』を参照してください。

ストアド・スクリプトの管理

「ストアド・スクリプト」で説明するように、リカバリ・カタログにスクリプトを格納できます。この項では、ストアド・スクリプトを作成および管理する方法について説明します。

ストアド・スクリプト

ストアド・スクリプトは、制御ファイルの代替として、頻繁に使用する一連のRMANコマンドの管理に使用できます。 このスクリプトは、ファイル・システムではなくリカバリ・カタログに格納されます。

ストアド・スクリプトには、ローカルとグローバルの2種類があります。ローカル・スクリプトは、作成時にRMANが接続していたターゲット・データベースに関連付けられます。このスクリプトは、関連付けられたターゲット・データベースに接続している場合にのみ実行できます。グローバル・ストアド・スクリプトは、RMANクライアントがリカバリ・カタログおよびターゲット・データベースに接続している場合、リカバリ・カタログに登録されたすべてのデータベースに対して実行できます。

CREATE SCRIPTコマンドの大カッコ内で使用できるコマンドは、RUNブロック内でサポートされているコマンドと同じです。RUNコマンド内で有効なコマンドは、ストアド・スクリプトで使用できます。RUN、@および@@コマンドは、ストアド・スクリプト内で有効ではありません。

スクリプト名を指定する場合、ストアド・スクリプト名を引用符で囲むことはできますが、必須ではありません。ただし、名前が数値で始まる場合やRMANの予約語である場合、その名前をストアド・スクリプト名として使用するには、引用符で囲む必要があります。ストアド・スクリプトには、英字以外の文字で始まる名前、またはRMANの予約語と同じ名前を付けないことをお薦めします。

グローバル・ストアド・スクリプトとローカル・ストアド・スクリプトが混同されないように、ネーミング規則を使用することをお薦めします。EXECUTE SCRIPT、DELETE SCRIPTおよびPRINT SCRIPTコマンドで引数として渡されたスクリプト名が、接続しているターゲット・インスタンス用に定義されたスクリプトの名前ではない場合、RMANは、指定した名前が付いたグローバル・スクリプトを検索します。たとえば、リカバリ・カタログにglobal_backupという名前のグローバル・スクリプトが存在し、ターゲット・データベース用に定義されたglobal_backupというローカル・ストアド・スクリプトが存在しない場合に次のコマンドを実行すると、このグローバル・スクリプトは削除されます。

DELETE SCRIPT global_backup;

ストアド・スクリプト(グローバル・スクリプトの場合も)に関連するコマンドを使用するには、リカバリ・カタログとターゲット・データベース・インスタンスの両方に接続する必要があります。

ストアド・スクリプトの作成

CREATE SCRIPTコマンドを使用すると、ストアド・スクリプトを作成できます。GLOBALを指定する場合は、この名前のグローバル・スクリプトがリカバリ・カタログ内に存在していない必要があります。GLOBALを指定しない場合は、同じターゲット・データベースに対して同じ名前のローカル・スクリプトが存在していない必要があります。また、 REPLACE SCRIPTを使用すると、スクリプトの作成または既存のスクリプトの更新を行うこともできます。

ストアド・スクリプトを作成する手順

1. RMANを起動し、ターゲット・データベースおよびリカバリ・カタログ(使用している場合)に接続します。

2. CREATE SCRIPTコマンドを実行します。
次に、ローカル・スクリプトを作成する例を示します。

CREATE SCRIPT full_backup
{
BACKUP DATABASE PLUS ARCHIVELOG;
DELETE OBSOLETE;
}

グローバル・スクリプトの場合、次のとおり、同様の構文を実行します。

CREATE GLOBAL SCRIPT global_full_backup
{
BACKUP DATABASE PLUS ARCHIVELOG;
DELETE OBSOLETE;
}

必要に応じて、COMMENTを使用して説明を追加できます。

CREATE GLOBAL SCRIPT global_full_backup
COMMENT 'use only with ARCHIVELOG mode databases'
{
BACKUP DATABASE PLUS ARCHIVELOG;
DELETE OBSOLETE;
}

テキスト・ファイルから内容を読み取ってスクリプトを作成することもできます。このファイルは、左中カッコ({)で始まり、次に有効な一連のコマンドが含まれているRUNブロックを含み、最後に右中カッコ(})で終わる必要があります。そうでない場合、キーボードからコマンドを入力した場合と同様の構文エラーが発生します。

CREATE SCRIPT full_backup
FROM FILE '/tmp/my_script_file.txt';

3. 出力を確認します。
エラーが表示されていない場合、RMANは、スクリプトを正常に作成し、リカバリ・カタログに格納しています。

関連項目:
RMANの予約語のリストは、『Oracle Databaseバックアップおよびリカバリ・リファレンス』を参照してください。

ストアド・スクリプトの置換え

ストアド・スクリプトを更新するには、REPLACE SCRIPTコマンドを使用します。ローカル・スクリプトを置き換える場合は、スクリプトの作成時に接続していたターゲット・データベースに接続する必要があります。スクリプトが存在しない場合、RMANによってスクリプトが作成されます。

ストアド・スクリプトを置き換える手順

1. RMANを起動し、ターゲット・データベースおよびリカバリ・カタログ(使用している場合)に接続します。

2. REPLACE SCRIPTを実行します。
次の例では、スクリプトfull_backupを新しい内容で更新します。

REPLACE SCRIPT full_backup
{
BACKUP DATABASE PLUS ARCHIVELOG;
}

GLOBALキーワードを次のように指定することによって、グローバル・スクリプトを更新できます。

REPLACE GLOBAL SCRIPT global_full_backup
COMMENT 'A script for full backup to be used with any database'
{
BACKUP AS BACKUPSET DATABASE PLUS ARCHIVELOG;
}

CREATE SCRIPTと同様に、ローカルまたはグローバル・ストアド・スクリプトをテキスト・ファイルから更新できます。その場合、次の形式のコマンドを使用します。

REPLACE GLOBAL SCRIPT global_full_backup
FROM FILE '/tmp/my_script_file.txt';

関連項目:
REPLACE SCRIPTコマンドの構文については、『Oracle Databaseバックアップおよびリカバリ・リファレンス』を参照してください。

ストアド・スクリプトの実行

ストアド・スクリプトを実行するには、EXECUTE SCRIPTコマンドを使用します。GLOBALを指定する場合は、この名前のグローバル・スクリプトがリカバリ・カタログ内に存在している必要があります。存在していない場合、RMANはエラーRMAN-06004を戻します。GLOBALを指定しなかった場合は、RMANによって、現行のターゲット・データベースに対して定義されているローカル・ストアド・スクリプトが検索されます。その名前のローカル・スクリプトが見つからなかった場合は、同じ名前のグローバル・スクリプトが検索され、見つかった場合はそのスクリプトが実行されます。

ストアド・スクリプトを実行する手順

1. RMANを起動し、ターゲット・データベースおよびリカバリ・カタログ(使用している場合)に接続します。

2. 必要に応じて、SHOWを使用して構成済のチャネルを確認します。
スクリプトは、実行時に構成されていた自動チャネルを使用します。構成済のチャネルを変更する必要がある場合、スクリプトにALLOCATE CHANNELを指定します。RUNブロックが使用されているため、スクリプト内のあるRMANコマンドが正常に実行されなかった場合、スクリプト内の後続のRMANコマンドは実行されません。

3. EXECUTE SCRIPTを実行します。このコマンドにはRUNブロックが必要です。次に例を示します。

RUN
{
EXECUTE SCRIPT full_backup;
}

このコマンドによって、指定した名前が付いたローカル・スクリプトがある場合は、ローカル・スクリプトが起動されます。該当するローカル・スクリプトが存在しないが、指定した名前が付いたグローバル・スクリプトが存在する場合、RMANはそのグローバル・スクリプトを実行します。

EXECUTE GLOBAL SCRIPTを使用して、ローカル・スクリプトとグローバル・スクリプトの名前が同じである場合に起動するスクリプトを制御することもできます。global_full_backupというローカル・スクリプトが存在しない場合、次の2つのコマンドによって実行される操作は同じになります。

RUN
{
EXECUTE GLOBAL SCRIPT global_full_backup;
}

RUN
{
EXECUTE SCRIPT global_full_backup;
}

関連項目:
EXECUTE SCRIPTコマンドの構文については、『Oracle Databaseバックアップおよびリカバリ・リファレンス』を参照してください。

動的ストアド・スクリプトの作成および実行

CREATE SCRIPTコマンドでは置換変数を指定できます。コマンドラインでRMANを起動する場合、USING句によって、コマンド・ファイル内の置換変数で使用される1つ以上の値が指定されます。SQL*Plusの場合と同様に、&1は最初の値を配置する場所を示し、&2は2番目の値を配置する場所を示します。それ以降も同様です。

動的ストアド・スクリプトを作成および使用する手順

1. 動的に更新する必要がある値用の置換変数が指定されているCREATE SCRIPT文を含むコマンド・ファイルを作成します。
次の例では、テープ・セットの名前、FORMAT指定内の文字列およびリストア・ポイントの名前の置換変数が使用されています。

CREATE SCRIPT quarterly {
ALLOCATE CHANNEL c1
DEVICE TYPE sbt
PARMS 'ENV=(OB_MEDIA_FAMILY=&1)';
BACKUP
TAG &2
FORMAT '/disk2/bck/&1%U.bck'
KEEP FOREVER
RESTORE POINT &3
DATABASE;
}

2. RMANをターゲット・データベース(マウントまたはオープンされている必要があります)およびリカバリ・カタログに接続して、リカバリ・カタログ・スクリプトの初期値を指定します。
たとえば、次のコマンドを入力します。

% rman TARGET / CATALOG rman@catdb USING arc_backup bck0906 FY06Q3

リカバリ・カタログは、KEEP FOREVERには必要ですが、その他のKEEPオプションには必要ありません。

3. 最初の手順で作成したコマンド・ファイルを実行して、ストアド・スクリプトを作成します。
たとえば、/tmp/catscript.rmanコマンド・ファイルを次のように実行します。

RMAN> @/tmp/catscript.rman

この手順では、ストアド・スクリプトは作成はされますが、実行はされません。

4. 四半期ごとに、ストアド・スクリプトを実行して、置換変数の値を渡します。
次の例では、quarterlyというリカバリ・カタログ・スクリプトを実行します。この例では、メディア・ファミリ(テープのセット)の名前としてarc_backup、FORMAT文字列の一部としてbck1206、リストア・ポイントの名前としてFY06Q4を指定します。

RUN
{
EXECUTE SCRIPT quarterly
USING arc_backup
bck1206
FY06Q4;
}

関連項目:
「長期格納用のデータベース・バックアップの作成」

ストアド・スクリプトの出力

ストアド・スクリプトを表示またはファイルに出力するには、PRINT SCRIPTコマンドを使用します。

ストアド・スクリプトを出力する手順

1. RMANを起動し、ターゲット・データベースおよびリカバリ・カタログに接続します。

2. PRINT SCRIPTコマンドを次のように実行します。

PRINT SCRIPT full_backup;

スクリプトの内容をファイルに送信するには、次の形式のコマンドを使用します。

PRINT SCRIPT full_backup
TO FILE '/tmp/my_script_file.txt';

グローバル・スクリプトの場合、次の構文では同じ操作が実行されます。

PRINT GLOBAL SCRIPT global_full_backup;
PRINT GLOBAL SCRIPT global_full_backup
TO FILE '/tmp/my_script_file.txt';

参照:
PRINT SCRIPTコマンドの構文については、『Oracle Databaseバックアップおよびリカバリ・リファレンス』を参照してください。

ストアド・スクリプト名の表示

リカバリ・カタログに定義されたスクリプトの名前を表示するには、LIST ... SCRIPT NAMESコマンドを使用します。RMANがターゲット・インスタンスに接続せずにリカバリ・カタログに接続している場合に使用できるコマンドは、LIST GLOBAL SCRIPT NAMESおよびLIST ALL SCRIPT NAMESのみです。その他の形式のLIST ... SCRIPT NAMESコマンドでは、リカバリ・カタログ接続が必要です。

ストアド・スクリプト名を表示する手順

1. RMANを起動し、ターゲット・データベースおよびリカバリ・カタログに接続します。

2. LIST ... SCRIPT NAMESコマンドを実行します。
たとえば、現在接続しているターゲット・データベースに対して実行可能なすべてのグローバル・スクリプトおよびローカル・スクリプトの名前を表示するには、次のコマンドを実行します。

LIST SCRIPT NAMES;

次の例では、グローバル・スクリプトの名前のみを表示します。

LIST GLOBAL SCRIPT NAMES;

現行のリカバリ・カタログに格納されたすべてのスクリプト(リカバリ・カタログに登録されたすべてのターゲット・データベースのグローバル・スクリプトとローカル・スクリプトを含む)の名前を表示するには、次の形式のコマンドを使用します。

LIST ALL SCRIPT NAMES;

表示された各スクリプトに関して、出力では、定義されたターゲット・データベース(または各スクリプトがグローバルであるかどうか)が示されます。

関連項目:
LIST SCRIPT NAMESコマンドの構文および出力形式については、『Oracle Databaseバックアップおよびリカバリ・リファレンス』を参照してください。

ストアド・スクリプトの削除

リカバリ・カタログからストアド・スクリプトを削除するには、DELETE GLOBAL SCRIPTコマンドを使用します。

ストアド・スクリプトを削除する手順

1. RMANを起動し、ターゲット・データベースおよびリカバリ・カタログに接続します。

2. DELETE SCRIPTコマンドを入力します。
GLOBALを指定せずにDELETE SCRIPTを使用し、指定した名前のストアド・スクリプトがそのターゲット・データベースに存在しない場合、指定した名前が付いたグローバル・ストアド・スクリプトが検索され、該当するスクリプトが削除されます。たとえば、次のコマンドを入力するとします。

DELETE SCRIPT 'global_full_backup';

この場合、RMANは、接続したターゲット・データベース用に定義されたglobal_full_backupスクリプトを検索します。該当するスクリプトが検出されない場合、グローバル・スクリプト内でglobal_full_backupという名前のスクリプトを検索し、該当するスクリプトを削除します。

グローバル・ストアド・スクリプトを削除するには、DELETE GLOBAL SCRIPTを使用します。

DELETE GLOBAL SCRIPT 'global_full_backup';

関連項目:
DELETE SCRIPTコマンドの構文については、『Oracle Databaseバックアップおよびリカバリ・リファレンス』を参照してください。

RMANの起動時のストアド・スクリプトの実行

RMANクライアントの起動時にリカバリ・カタログ内のストアド・スクリプトを実行するには、RMANクライアントの起動時にSCRIPT引数を指定します。たとえば、次のコマンドを入力してスクリプト/tmp/fbkp.cmdを実行できます。

% rman TARGET / CATALOG rman@catdb SCRIPT '/tmp/fbkp.cmd';

RMANクライアントの起動時には、(ストアド・スクリプトを含む)リカバリ・カタログおよび(スクリプトの実行先の)ターゲット・データベースに接続する必要があります。

ローカル・スクリプトとグローバル・ストアド・スクリプトが同じ名前で定義されている場合、RMANは常にローカル・スクリプトを実行します。

関連項目:
RMANクライアントのコマンドライン構文の詳細は、『Oracle Databaseバックアップおよびリカバリ・リファレンス』を参照してください。

リカバリ・カタログのメンテナンス

この項では、様々な管理タスクおよびメンテナンス・タスクについて説明します。この項の内容は、次のとおりです。

- リカバリ・カタログのメンテナンス

- リカバリ・カタログの再同期化

- DB_UNIQUE_NAMEを変更した後のリカバリ・カタログの更新

- リカバリ・カタログからのターゲット・データベースの登録の解除

- リカバリ・カタログのデータベース・インカネーションの再設定

- リカバリ・カタログのアップグレード

- リカバリ・カタログのインポートおよび移動

リカバリ・カタログのメンテナンス

リカバリ・カタログを作成してターゲット・データベースを登録した後、このカタログをメンテナンスする必要があります。たとえば、RMANメンテナンス・コマンド(第12章「RMANバックアップおよびリポジトリ・レコードのメンテナンス」を参照)を実行して、バックアップ・レコードの更新および不要なバックアップの削除を行う必要があります。このタイプのメンテナンスは、リカバリ・カタログでRMANを使用するかどうかに関係なく実行する必要があります。リカバリ・カタログ・スキーマのアップグレードなどのその他のタイプのメンテナンスは、リカバリ・カタログでのRMANの使用に固有です。

Data Guard環境でリカバリ・カタログを使用する場合は、カタログに記録されるバックアップおよびデータベース・ファイルに、特別な考慮事項が適用されます。RMANでバックアップにアクセスできるタイミング、およびアクセス可能なバックアップに対するRMANメンテナンス・コマンドの動作については、「Data Guard環境でのRMANによるファイル管理」を参照してください。

リカバリ・カタログの再同期化

RMANは、再同期化を実行する際に、リカバリ・カタログと、ターゲット・データベースの現行の制御ファイルまたはバックアップ制御ファイルを比較し、欠落したメタデータまたは変更されたメタデータを追加してカタログを更新します。ほとんどのRMANコマンドは、ターゲット制御ファイルがマウントされ、カタログが使用可能になると、再同期化を自動的に実行します。Data Guard環境では、RMANは逆再同期化を実行して、カタログのメタデータでデータベース制御ファイルを更新できます。

リカバリ・カタログの再同期化

リカバリ・カタログを再同期化すると、RMANが制御ファイルから取得するメタデータが常に最新に保たれます。再同期化には、完全再同期化と部分再同期化があります。

部分再同期化では、RMANはターゲット・データベースの現行の制御ファイルを読み取って、新しいバックアップ、新しいアーカイブREDOログなどに関する変更されたメタデータを更新します。RMANは、データベースの物理スキーマに関するメタデータは再同期化しません。

完全再同期化では、RMANは、データベース・スキーマのレコードを含め、変更されたすべてのレコードを更新します。RMANは、データベースに構造変更(データベース・ファイルの追加または削除、新しいインカネーションの作成など)を行った後またはRMANの永続的な構成を変更した後に完全再同期化を実行します。

RMANは、完全再同期化の実行時に、一時的なバックアップ制御ファイルであるスナップショット制御ファイルを作成します。データベースでは、あるスナップショット制御ファイルにアクセスするRMANセッションが一度に1つのみに制限されます。RMANは、ターゲット・データベース・ホスト上のオペレーティング・システム固有の場所にスナップショット制御ファイルを作成します。スナップショット制御ファイルの名前および場所は、「スナップショット制御ファイルの場所の構成」の説明に従って指定できます。

このスナップショット制御ファイルによって、RMANは制御ファイルの一貫性ビューを持つことができます。制御ファイルは短期の使用を目的としているため、カタログには登録されません。RMANは、制御ファイルのチェックポイントをリカバリ・カタログに記録して、そのカタログが記録された時点を示します。

関連項目:
RESYNCコマンドの詳細は、『Oracle Databaseバックアップおよびリカバリ・リファレンス』を参照してください。

Data Guard環境でのリカバリ・カタログの再同期化

RMANは、データベースにTARGETとして接続すると、リカバリ・カタログをそのデータベースとのみ自動的に再同期化します。つまり、RMANは、Data Guard環境内の1つのデータベースにTARGETとして接続しても、Data Guard環境内のすべてのデータベースは自動的に再同期化しません。RESYNC CATALOG FROM DB_UNIQUE_NAMEコマンドを使用すると、リカバリ・カタログをData Guard環境内のデータベースと手動で再同期化できます。

手動での再同期化の例では、RMANが本番データベースprodにTARGETとして接続していること、およびCONFIGUREを使用してdgprod3用の構成を作成していることを想定しています。RESYNC CATALOG FROM DB_UNIQUE_NAME dgprod3を実行すると、RMANは、リカバリ・カタログをdgprod3制御ファイルと再同期化します。この場合、RMANは、通常の再同期化(メタデータのフローがdgprod3制御ファイルからカタログの方向)と逆再同期化の両方が実行されます。逆再同期化では、RMANは、リカバリ・カタログの永続的な構成を使用して、dgprod3制御ファイルを更新します。

関連項目:
『Oracle Data Guard概要および管理』

リカバリ・カタログを再同期化するタイミングの決定

RMANがターゲット・データベースおよびリカバリ・カタログに接続しているときにRMANコマンドを実行すると、RMANは自動的にリカバリ・カタログを再同期化します。そのため、RESYNC CATALOGコマンドを手動で実行する必要がある機会はあまり多くありません。次の項では、カタログの再同期化を手動で実行する必要がある場合について説明します。

リカバリ・カタログが使用不可の場合の再同期化

部分再同期化を実行するRMANコマンドの発行時にリカバリ・カタログが使用不可であった場合、後でカタログ・データベースをオープンして、RESYNC CATALOGコマンドを使用して手動で再同期化します。

たとえば、ターゲット・データベースがニューヨークに存在し、リカバリ・カタログが日本に存在するとします。地理的に離れたデータベースの可用性に依存しないようにするため、CATALOGモードのターゲット・データベースの日次バックアップは行わないことにします。このような場合、実行可能な頻度でカタログに接続し、RESYNC CATALOGコマンドを実行します。

バックアップ頻度が低い場合のARCHIVELOGモードでの再同期化

ターゲット・データベースがARCHIVELOGモードで実行されていると想定します。また、次の操作を実行すると想定します。

- データベースを低い頻度でバックアップします(たとえば、REDOログが100個アーカイブされるごとにデータベースをアーカイブします)。

- 毎日多数のログ・スイッチが発生します(たとえば、スイッチが1000回発生するごとにカタログを再同期化します)。

この場合、REDOログ・スイッチの発生時またはREDOログのアーカイブ時にリカバリ・カタログが自動的に更新されないため、リカバリ・カタログを定期的に手動で再同期化する必要があります。データベースでは、REDOログ・スイッチおよびアーカイブREDOログに関するメタデータは制御ファイルにのみ格納されます。定期的に再同期化を実行して、この情報をリカバリ・カタログに伝播する必要があります。

リカバリ・カタログの再同期化の頻度は、データベースがREDOログをアーカイブする頻度によって異なります。 この操作のコストは、制御ファイル内の、最後の再同期化以降に挿入または変更されたレコードの数に比例します。挿入または変更されたレコードがない場合、再同期化のコストは非常に低くなります。多くのレコードが挿入または変更された場合、再同期化にかかる時間が長くなります。

スタンバイ・データベースの構成後の再同期化

スタンバイ・データベースにTARGETとして接続されていない場合でも、このデータベースに対してRMAN構成の作成または変更を行うことができます。このタスクは、CONFIGURE DB_UNIQUE_NAMEまたはCONFIGURE ... FOR DB_UNIQUE_NAMEコマンドを使用して実行します。「リカバリ・カタログの手動での再同期化」で説明されているように、スタンバイ・データベースを手動で再同期化して、スタンバイ・データベースの制御ファイルを更新できます。

制御ファイル・レコードがエージ・アウトされる前のリカバリ・カタログの再同期化

リカバリ・カタログ内のメタデータは、常に最新の状態にしておく必要があります。リカバリ・カタログはターゲット制御ファイルからメタデータを取得するため、カタログ内のデータが最新の状態かどうかは、制御ファイル内のデータが最新の状態かどうかによって決まります。制御ファイル内のバックアップ・メタデータが、新しいレコードで上書きされる前にカタログに記録されていることを確認する必要があります。

CONTROL_FILE_RECORD_KEEP_TIME初期化パラメータは、レコードが制御ファイルに保持される最小日数を指定します。この日数後は、レコードは上書き対象になります。このため、これらのレコードが消去される前に、リカバリ・カタログを制御ファイルのレコードと再同期化する必要があります。CONTROL_FILE_RECORD_KEEP_TIME設定より短い間隔で、次の処理のいずれかを実行する必要があります。

- バックアップを実行することによって、リカバリ・カタログの再同期化を暗黙的に実行します。

- RESYNC CATALOGコマンドを使用して、リカバリ・カタログを手動で再同期化します。

CONTROL_FILE_RECORD_KEEP_TIMEがバックアップまたは再同期化の間隔より長くなるようにします。そうしないと、制御ファイルがリカバリ・カタログに伝播される前に再利用される場合があります。通常、予定の間隔に1週間を追加することをお薦めします。

注意:
CONTROL_FILE_RECORD_KEEP_TIMEは0に設定しないでください。そうすると、制御ファイル内のバックアップ・レコードが、RMANによってカタログに追加される前に上書きされる場合があります。

制御ファイルのサイズが大きくなりすぎることは問題です。ターゲット・データベースの制御ファイルのサイズは、次のものの数に応じて大きくなります。

- 実行するバックアップ操作

- データベースが生成するアーカイブREDOログ

- 前述の情報が制御ファイルに保持される日数

制御ファイルのサイズが大きくなり、ブロック数またはレコード数が上限に達して制御ファイルのサイズがそれ以上大きくならない場合、最も古いレコードは、CONTROL_FILE_RECORD_KEEP_TIMEの設定値に達していなくても上書きされる場合があります。この場合、データベースはアラート・ログにメッセージを書き込みます。この状況が頻繁に発生する場合、CONTROL_FILE_RECORD_KEEP_TIMEの値を減らし、再同期化の頻度を高くします。

関連項目:

- CONTROL_FILE_RECORD_KEEP_TIMEパラメータの詳細は、『Oracle Databaseリファレンス』を参照してください。

- 制御ファイル管理の詳細は、『Oracle Database管理者ガイド』を参照してください。

- 制御ファイル・レコードの上書きを監視する方法については、「制御ファイル・レコードの消失の防止」を参照してください。

リカバリ・カタログの手動での再同期化

ターゲット・データベースの制御ファイルを使用してリカバリ・カタログの完全再同期化を強制実行するには、RESYNC CATALOGを使用します。Data Guard環境で特定のデータベースを再同期化するか、またはすべてのデータベースを再同期化するかに応じて、RESYNC FROM DB_UNIQUE_NAMEまたはALLを使用してデータベースの一意の名前を指定できます。通常、この操作は、スタンバイ・データベースに対するCONFIGUREコマンドを実行した後、そのスタンバイ・データベースに接続していない場合に実行します。

1. RMANを起動し、ターゲット・データベースおよびリカバリ・カタログに接続します。

2. ターゲット・データベースをマウントまたはオープンします。

STARTUP MOUNT;

3. リカバリ・カタログを再同期化します。
RMANプロンプトで、RESYNC CATALOGコマンドを次のように実行します。

RESYNC CATALOG;

次の例では、standby1の制御ファイルを再同期化します。

RESYNC CATALOG FROM DB_UNIQUE_NAME standby1;

次の例では、Data Guard環境内ですべてのデータベースの制御ファイルを再同期化します。

RESYNC CATALOG FROM DB_UNIQUE_NAME ALL;

関連項目:

- RESYNC CATALOGコマンドの構文については、『Oracle Databaseバックアップおよびリカバリ・リファレンス』を参照してください。

- スタンバイ・データベースで使用するためにRMAN環境を構成する方法については、『Oracle Data Guard概要および管理』を参照してください。

DB_UNIQUE_NAMEを変更した後のリカバリ・カタログの更新

Data Guard環境でデータベースのDB_UNIQUE_NAMEを変更する必要がある場合があります。この場合は、CHANGE DB_UNIQUE_NAMEコマンドを実行して、リカバリ・カタログに格納されている古いDB_UNIQUE_NAMEに関するメタデータを新しいDB_UNIQUE_NAMEに関連付けることができます。CHANGE DB_UNIQUE_NAMEコマンドによって、データベース自体のDB_UNIQUE_NAMEが実際に変更されることはありません。かわりに、一意の名前が変更された(または変更される)データベースに関するカタログ・メタデータが更新されます。

次の手順では、プライマリ・データベースのDB_UNIQUE_NAMEがprodnyであること、およびスタンバイ・データベースのDB_UNIQUE_NAMEをprodsf1からprodsf2に変更したことを想定しています。プライマリ・データベースのDB_UNIQUE_NAMEを変更した後に、同じ手順を使用できます。ただし、手順1で、プライマリ・データベースではなく、スタンバイ・データベースにRMANをTARGETとして接続する点は異なります。

DB_UNIQUE_NAMEを変更した後にリカバリ・カタログを更新する手順

1. RMANをTARGETとしてプライマリ・データベースに接続し、リカバリ・カタログにも接続します。たとえば、次のコマンドを入力します。

% rman
RMAN> CONNECT CATALOG catowner@catdb

recovery catalog database Password: password
connected to recovery catalog database

RMAN> CONNECT TARGET SYS@prodny

target database Password: password
connected to target database: PRODNY (DBID=39525561)

2. リカバリ・カタログで認識されるDB_UNQUE_NAME値を表示します。
次のLISTコマンドを実行します。

RMAN> LIST DB_UNIQUE_NAME OF DATABASE;

3. RMANメタデータ内のDB_UNIQUE_NAMEを変更します。

次の例では、データベースの一意の名前をスタンバイ・データベースprodsf1からprodsf2に変更します。

RMAN> CHANGE DB_UNIQUE_NAME FROM prodsf1 TO prodsf2;

リカバリ・カタログからのターゲット・データベースの登録の解除

UNREGISTER DATABASEコマンドを使用すると、リカバリ・カタログからデータベースの登録を解除できます。データベースがリカバリ・カタログから登録解除されると、RMANのすべてのリポジトリ・レコードが消失します。データベースは再度登録できますが、このデータベースのリカバリ・カタログ・レコードは、再登録時の制御ファイルの内容に基づきます。ターゲット・データベースの制御ファイル内のCONTROLFILE_RECORD_KEEP_TIME設定より古いレコードは消失します。また、制御ファイルに格納されていないストアド・スクリプトも消失します。

Data Guard環境外のターゲット・データベースの登録の解除

この例では、リカバリ・カタログを使用せずにプライマリ・データベースとスタンバイ・データベースのメタデータを格納すると想定しています。

データベースの登録を解除する手順

1. RMANを起動し、登録を解除するデータベースにTARGETとして接続します。リカバリ・カタログにも接続します。
ターゲット・データベースに接続する必要はありませんが、接続しない場合は、UNREGISTERコマンドでターゲット・データベースの名前を指定する必要があります。リカバリ・カタログで複数のデータベースに同じ名前がある場合は、コマンドを囲むようにRUNブロックを作成し、SET DBIDを使用してデータベースのDBIDを設定する必要があります。

2. 起動時に、RMANによって表示されたDBIDを書き留めます。
たとえば、RMANは、オープンしているターゲット・データベースに接続した場合、次の形式の行を出力します。

connected to target database: PROD (DBID=39525561)

3. 念のため、LIST BACKUP SUMMARYおよびLIST COPY SUMMARYを使用して、リカバリ・カタログに記録されているすべてのバックアップを表示すると役に立つ場合があります。この場合、後でデータベースを再登録するときに、制御ファイルで認識されないバックアップをカタログに再度追加できます。

4. データベースのすべてのバックアップを実際に削除する場合は、DELETE文を実行して、既存のすべてのバックアップを削除します。データベースをリカバリ・カタログから削除し、制御ファイルを使用してこのデータベースのRMANメタデータを格納する場合は、すべてのバックアップは削除しないでください。
次のコマンドは、バックアップの削除方法を示しています。

DELETE BACKUP DEVICE TYPE sbt;
DELETE BACKUP DEVICE TYPE DISK;
DELETE COPY;

RMANによって、削除されるバックアップが表示され、それらの削除前に確認するように求められます。

5. UNREGISTER DATABASEコマンドを実行します。次に例を示します。

UNREGISTER DATABASE;

RMANにデータベース名およびDBIDが表示され、確認するように求められます。

database name is "RDBMS" and DBID is 931696259

Do you really want to unregister the database (enter YES or NO)? yes

プロセスが完了すると、RMANは次のメッセージを出力します。

database unregistered from the recovery catalog

スタンバイ・データベースの登録の解除

UNREGISTERコマンドでは、Data Guard環境での使用のためにDB_UNIQUE_NAME句がサポートされています。この句を使用すると、特定のデータベースのメタデータを削除できます。

リカバリ・カタログによって、バックアップは特定のデータベースに関連付けられます。データベースの登録を解除すると、RMANは、これらのバックアップ・ファイルのデータベース名をNULLに更新します。そのため、バックアップは記録されていますが、バックアップの所有者は存在しなくなります。CHANGE ... RESET DB_UNIQUE_NAMEコマンドを実行すると、現在所有者が存在しないバックアップの所有権を別のデータベースに関連付けることができます。UNREGISTERコマンドにINCLUDING BACKUPSを指定した場合、RMANは、登録を解除されたデータベースのバックアップ・メタデータも削除します。

この例では、プライマリ・データベースlnx3に、関連付けられたスタンバイ・データベースstandbyがあると想定しています。このスタンバイ・データベースの登録を解除します。

スタンバイ・データベースの登録を解除する手順

1. RMANを起動し、TARGETとしてプライマリ・データベースに接続します。また、リカバリ・カタログにもRMANを接続します。
たとえば、次のコマンドを入力します。

% rman
RMAN> CONNECT TARGET SYS@lnx3

target database Password: password
connected to target database: LNX3 (DBID=781317675)

RMAN> CONNECT CATALOG rman@catdb

2. データベースの一意の名前を表示します。
たとえば、LIST DB_UNIQUE_NAMEコマンドを次のように実行します。

RMAN> LIST DB_UNIQUE_NAME OF DATABASE;

List of Databases
DB Key  DB Name DB ID             Database Role   Db_unique_name
------- ------- ----------------- --------------- ------------------
1       LNX3    781317675         STANDBY         STANDBY
1       LNX3    781317675         PRIMARY         LNX3

3. UNREGISTER DB_UNIQUE_NAMEコマンドを実行します。
たとえば、データベースstandbyの登録を解除するには、UNREGISTERコマンドを次のように実行します。

RMAN> UNREGISTER DB_UNIQUE_NAME standby;

RMANにデータベース名およびDBIDが表示され、確認するように求められます。

database db_unique_name is "standby", db_name is "LNX3" and DBID is 781317675

Do you really want to unregister the database (enter YES or NO)? yes

プロセスが完了すると、RMANは次のメッセージを出力します。

database with db_unique_name standby unregistered from the recovery catalog

リカバリ・カタログのデータベース・インカネーションの再設定

「データベース・インカネーション」で説明されているように、RESETLOGSオプションでデータベースをオープンする際にデータベースのインカネーションを作成します。新しいインカネーションのレコードには、V$DATABASE_INCARNATIONビューでアクセスできます。

RESETLOGSオプションでデータベースをオープンすると、新しいデータベース・インカネーション・レコードがリカバリ・カタログ内に自動的に作成されます。また、データベースによって暗黙的かつ自動的にRESET DATABASEコマンドが発行され、このデータベースの新しいインカネーションが現行のインカネーションであることが指定されます。ターゲット・データベースによって実行される後続のすべてのバックアップおよびログのアーカイブは、新しいデータベース・インカネーションに関連付けられます。

RMANで、RESTOREとRECOVER、またはFLASHBACK DATABASEのいずれかを使用してデータベースを現行のRESETLOGS SCNより前のSCNに戻す場合は、常にRESET DATABASE TO INCARNATIONコマンドを実行する必要があります。ただし、RMANではフラッシュバックでRESET DATABASE TO INCARNATIONが暗黙的に実行されるため、次の場合はこのコマンドを明示的に実行する必要はありません。

- FLASHBACK DATABASEを使用して、データベースを直系祖先パス内のSCNに戻す場合(直系祖先パスについては、「データベース・インカネーション」を参照)

- FLASHBACK DATABASEを使用して、データベースをリストア・ポイントに戻す場合

次の手順では、RESETLOGSを使用してリカバリする場合にデータベース・インカネーションをリセットする方法について説明します。

リカバリ・カタログをメディア・リカバリの古いインカネーションにリセットする手順

1. 必要なデータベース・インカネーションのインカネーション・キーを確認します。インカネーション・キー値を取得するには、LISTコマンドを発行します。

LIST INCARNATION OF DATABASE trgt;

List of Database Incarnations
DB Key  Inc Key   DB Name   DB ID       STATUS     Reset SCN    Reset Time
------- -------   -------   ------      -------    ----------   ----------
1       2         TRGT      1224038686  PARENT     1            02-JUL-02
1       582       TRGT      1224038686  CURRENT    59727        10-JUL-02

インカネーション・キーは、Inc Key列に表示されます。

2. データベースを以前のインカネーションに再設定します。たとえば、次のように入力します。

RESET DATABASE TO INCARNATION 2;

3. 以前のインカネーションの制御ファイルが使用可能でマウントされている場合、手順6にスキップします。そうでない場合、データベースを停止して、NOMOUNTモードで起動します。次に例を示します。

SHUTDOWN IMMEDIATE
STARTUP NOMOUNT

4. 以前のインカネーションから制御ファイルをリストアします。タグ付きの制御ファイルの場合、タグを指定します。そうでない場合、次のとおり、SET UNTILコマンドを実行できます。

RUN
{
SET UNTIL 'SYSDATE-45';
RESTORE CONTROLFILE; # only if current control file is not available
}

5. リストアされた制御ファイルをマウントします。

ALTER DATABASE MOUNT;

6. RESTOREコマンドおよびRECOVERコマンドを実行して以前のインカネーションからデータベース・ファイルをリストアおよびリカバリし、RESETLOGSオプションを指定してデータベースをオープンします。たとえば、次のように入力します。

RESTORE DATABASE;
RECOVER DATABASE;
ALTER DATABASE OPEN RESETLOGS;

関連項目:
RESET DATABASEの構文については、『Oracle Databaseバックアップおよびリカバリ・リファレンス』を参照してください。LISTの構文については、『Oracle Databaseバックアップおよびリカバリ・リファレンス』を参照してください。

リカバリ・カタログのアップグレード

この項では、リカバリ・カタログのアップグレードおよびアップグレードの実行が必要となるタイミングについて説明します。

リカバリ・カタログのアップグレード

RMANクライアントで要求されるバージョンより古いリカバリ・カタログ・スキーマを使用している場合、そのカタログをアップグレードする必要があります。RMANのバージョンと互換性があるスキーマ・バージョンについては、『Oracle Databaseバックアップおよびリカバリ・リファレンス』の互換性の表を参照してください。たとえば、Oracle Database 11gのRMANクライアントでリリース10.2のリカバリ・カタログ・スキーマを使用する場合、そのカタログをアップグレードする必要があります。

Oracle Database 10gR1バージョンのリカバリ・カタログ・スキーマには、CREATE TYPE権限が必要です。10gR1より前のリリースでリカバリ・カタログの所有者を作成し、CREATE TYPE権限が含まれていないRECOVERY_CATALOG_OWNERロールを付与した場合は、カタログのアップグレードの前に、明示的にこの所有者にCREATE TYPEを付与する必要があります。

RMANクライアントで要求されるバージョンより新しいバージョンのリカバリ・カタログを使用している場合、UPGRADE CATALOGを発行するとエラーが表示されます。RMANでは、リカバリ・カタログが現行のバージョンでアップグレードが必要ない場合でもUPGRADE CATALOGコマンドを実行できます。このコマンドを実行すると、必要に応じていつでもパッケージを再作成できます。アップグレード中に生成されたエラー・メッセージを、メッセージ・ログで確認してください。

Data Guard環境での特別な考慮事項

Data Guard環境で、リカバリ・カタログ・スキーマをOracle Database 11gにアップグレードすると想定します。RMANは、スタンバイ・データベースに接続する際に、新しいデータベース情報を自動的に登録し、再同期化してファイル名を制御ファイルから取得します。

再同期化中に、RMANは名前をターゲット・データベース名に関連付けます。リカバリ・カタログには、履歴メタデータが含まれているため、制御ファイルで認識されないレコードもあります。たとえば、standby1制御ファイルでは、primary1に作成されたすべてのバックアップについては認識されません。これらの古いレコードのデータベースの一意の名前はNULLです。「リカバリ・カタログのメンテナンス」で説明されているように、CROSSCHECKを使用してこれらのレコードを修正できます。

リカバリ・カタログのスキーマ・バージョンの確認

リカバリ・カタログのスキーマ・バージョンは、リカバリ・カタログ自体に格納されます。この情報は、本番システムにバージョンの異なる複数のデータベースが存在し、カタログのスキーマ・バージョンが特定のターゲット・データベース・バージョンで使用可能かどうかを確認する必要がある場合に重要です。

リカバリ・カタログのスキーマ・バージョンを確認する手順

1. SQL*Plusを起動し、カタログ所有者としてリカバリ・カタログ・データベースに接続します。

2. RCVER表を問い合せてスキーマ・バージョンを取得します。次に、コマンドと出力の例を示します。

SELECT *
FROM   rcver;

VERSION
------------
10.02.00

RCVER表に複数の行が表示される場合、この表内で最上位のバージョンが、現行のカタログ・スキーマ・バージョンです。この表に格納されるのはメジャー・バージョン番号のみであり、パッチ番号は格納されません。たとえば、rcver表に次の行が表示されたと想定します。

VERSION
------------
08.01.07
09.00.01
10.02.00

これらの行は、カタログがリリース8.1.7の実行可能ファイルによって作成され、リリース9.0.1にアップグレードされ、最後にリリース10.2.0にアップグレードされたことを示しています。カタログ・スキーマの現行バージョンは10.2.0です。

関連項目:
RMAN環境で適用される互換性規則の詳細は、『Oracle Databaseバックアップおよびリカバリ・リファレンス』を参照してください。

UPGRADE CATALOGコマンドの使用

この例では、リカバリ・カタログ・スキーマを現行のバージョンにアップグレードすると想定しています。

リカバリ・カタログをアップグレードする手順

1. 10gR1より前のリリースでリカバリ・カタログの所有者を作成し、RECOVERY_CATALOG_OWNERロールにCREATE TYPE権限が含まれていなかった場合は、これを付与します。
たとえば、SQL*Plusを起動し、管理者権限でリカバリ・カタログ・データベースに接続します。これによって、次のGRANT文を実行できます。

SQL> GRANT CREATE TYPE TO rman;
SQL> EXIT;

2. RMANを起動し、リカバリ・カタログ・データベースにRMANを接続します。

3. UPGRADE CATALOGコマンドを実行します。

RMAN> UPGRADE CATALOG;

recovery catalog owner is rman
enter UPGRADE CATALOG command again to confirm catalog upgrade

4. 確認のためにUPDATE CATALOGコマンドを再度実行します。

RMAN> UPGRADE CATALOG;

recovery catalog upgraded to version 11.01.00
DBMS_RCVMAN package upgraded to version 11.01.00
DBMS_RCVCAT package upgraded to version 11.01.00

関連項目:

- UPGRADE CATALOGコマンドの構文については、『Oracle Databaseバックアップおよびリカバリ・リファレンス』を参照してください。

- リカバリ・カタログの互換性については、『Oracle Databaseバックアップおよびリカバリ・リファレンス』を参照してください。

- 互換性および移行の詳細は、『Oracle Databaseアップグレード・ガイド』を参照してください。

リカバリ・カタログのインポートおよび移動

RMANでIMPORT CATALOGコマンドを使用して、1つのリカバリ・カタログ・スキーマを別のリカバリ・カタログ・スキーマにマージできます。このコマンドは、次の場合に有効です。

- 様々なバージョンのデータベースに対して複数のリカバリ・カタログ・スキーマが存在する場合。バックアップ・メタデータを失わずに、既存のすべてのスキーマを1つにマージする必要があります。

- リカバリ・カタログをデータベース間で移動する場合。

リカバリ・カタログのインポート

IMPORT CATALOGを使用する場合、ソース・カタログ・スキーマが、別のスキーマにインポートするカタログ・スキーマになります。宛先カタログ・スキーマは、ソース・カタログ・スキーマのインポート先のカタログ・スキーマです。

デフォルトでは、RMANは、ソース・リカバリ・カタログに登録されているすべてのターゲット・データベースのメタデータをインポートします。必要に応じて、ソース・カタログ・スキーマからインポートするデータベースのIDのリストを指定できます。

デフォルトでは、RMANは、正常なインポートの後で、インポートしたデータベースをソース・カタログ・スキーマから登録解除します。登録解除が正常に実行されたかどうかを示すために、RMANは、マージされたデータベースの登録解除の前後にメッセージを出力します。NO UNREGISTERオプションを指定して、データベースが宛先カタログから登録解除されないように指定することもできます。

ストアド・スクリプトは、グローバルまたはローカルのいずれかです。スクリプトのインポート時に、インポート先のスキーマにスクリプト名が含まれていることが原因で、グローバル・スクリプトの名前が競合することがあります(ローカル・スクリプトの場合は競合しません)。この場合、RMANは、グローバル・スクリプト名をCOPY OF script_nameに変更します。たとえば、RMANは、bp_cmdをCOPY OF bp_cmdに変更します。

名前が変更されたグローバル・スクリプトも一意でない場合、RMANは、その名前をCOPY(2) OF script_nameに変更します。このスクリプト名も存在する場合、RMANは、スクリプトの名前をCOPY(3) OF script_nameに変更します。RMANは、スクリプト名が一意になるまでCOPY(n) OFのパターンを繰り返します。

リカバリ・カタログのインポートの前提条件

『Oracle Databaseバックアップおよびリカバリ・リファレンス』の互換性の表に示されているように、ターゲット・データベース、リカバリ・カタログ・データベースおよびリカバリ・カタログ・スキーマのデータベース・バージョンが異なっている場合があります。最新のバージョンのリカバリ・カタログ・スキーマで、既存のすべてのリカバリ・カタログを1つのリカバリ・カタログにインポートすることをお薦めします。カタログのバージョンを確認する方法については、「リカバリ・カタログのスキーマ・バージョンの確認」を参照してください。互換性の表を確認し、使用している環境内で互換性があるスキーマ・バージョンを判別します。

IMPORT CATALOGを使用する場合、ソース・リカバリ・カタログ・スキーマのバージョンは、このコマンドの実行に使用するRMAN実行可能ファイルの現行のバージョンと一致している必要があります。ソース・カタログ・スキーマのバージョンのほうが低い場合は、スキーマをインポートする前に現行のバージョンにアップグレードします。アップグレード方法については、「リカバリ・カタログのアップグレード」を参照してください。ソース・リカバリ・カタログ・スキーマのバージョンのほうが高い場合は、より高いバージョンのRMAN実行可能ファイルを使用してインポートを再試行します。

ソース・カタログ・スキーマと宛先カタログ・スキーマの両方にデータベースを登録することはできません。現在、データベースが両方のカタログ・スキーマに登録されている場合は、インポートを実行する前にソース・カタログ・スキーマからデータベースを登録解除します。

リカバリ・カタログのインポート

リカバリ・カタログを別のリカバリ・カタログにインポートする場合、ターゲット・データベースへの接続は必要ありません。RMANは、ソース・カタログおよび宛先カタログにのみ接続する必要があります。

次の例では、データベースsrcdbにユーザー102catが所有する10.2リカバリ・カタログ・スキーマが含まれており、データベースdestdbにユーザー111catが所有する11.1リカバリ・カタログ・スキーマが含まれています。

リカバリ・カタログをインポートする手順

1. RMANを起動し、CATALOGとして宛先リカバリ・カタログ・スキーマに接続します。次に例を示します。

% rman
RMAN> CONNECT CATALOG 111cat@destdb;

2. ソース・カタログの接続文字列を指定して、ソース・リカバリ・カタログ・スキーマをインポートします。
たとえば、次のコマンドを入力して、データベースsrcdbの102catが所有するカタログをインポートします。

IMPORT CATALOG 102cat@srcdb;

前述の例を少し変更して、ソース・カタログに登録されたターゲット・データベースのサブセットに関するメタデータをインポートすることもできます。DBIDまたはデータベース名によってデータベースを指定できます。次に例を示します。

IMPORT CATALOG 102cat@srcdb DBID=1423241, 1423242;
IMPORT CATALOG 102cat@srcdb DB_NAME=prod3, prod4;

3. 必要に応じて、ターゲット・データベースに接続して、メタデータが正常にインポートされたことを確認します。たとえば、次のコマンドは、データベースprod1にTARGETとして接続し、このデータベースのすべてのバックアップを表示します。

LIST BACKUP;

リカバリ・カタログの移動

データベース間でリカバリ・カタログを移動する手順は、カタログをインポートする手順に類似しています。次の例では、ソース・データベースは既存のリカバリ・カタログを含むデータベースで、移動先データベースには移動されたリカバリ・カタログが含まれます。

ソース・データベースから移動先データベースにリカバリ・カタログを移動する手順

1. 移動先データベースでリカバリ・カタログを作成しますが、新しいカタログにデータベースは登録しません。
このタスクの実行方法については、「リカバリ・カタログの作成」を参照してください。

2. 前の手順で作成したカタログにソース・カタログをインポートします。
このタスクの実行方法については、「リカバリ・カタログのインポート」を参照してください。

リカバリ・カタログの削除

DROP CATALOGコマンドを使用すると、CREATE CATALOGコマンドによって作成されたオブジェクトが削除されます。リカバリ・カタログを所有するユーザーが、CREATE CATALOGで作成されなかったオブジェクトも所有している場合、これらのオブジェクトはDROP CATALOGコマンドでは削除されません。

リカバリ・カタログ・スキーマのバックアップが存在しない場合にリカバリ・カタログを削除すると、このカタログに登録されているすべてのターゲット・データベースのバックアップが使用できなくなる可能性があります。ただし、すべてのターゲット・データベースの制御ファイルには、そのデータベースの最近のバックアップのレコードが保持されます。

DROP CATALOGコマンドは、複数のターゲット・データベースが登録されたリカバリ・カタログから1つのデータベースを登録解除する場合には使用しないことをお薦めします。リカバリ・カタログを削除すると、そのカタログに登録されたすべてのターゲット・データベースのバックアップのリカバリ・カタログ・レコードが削除されます。

リカバリ・カタログ・スキーマを削除する手順

1. RMANを起動し、ターゲット・データベースおよびリカバリ・カタログに接続します。削除するカタログ・スキーマの所有者として、リカバリ・カタログに接続します。
次の例では、ユーザーcatownerとしてリカバリ・カタログに接続します。

% rman TARGET / CATALOG catowner@catdb

2. DROP CATALOGコマンドを実行します。

DROP CATALOG;

recovery catalog owner is catowner
enter DROP CATALOG command again to confirm catalog removal

3. 確認のためにDROP CATALOGコマンドを再度実行します。

DROP CATALOG;

注意:
リカバリ・カタログを削除しても、制御ファイルにはバックアップに関するレコードが含まれたままです。RMANリポジトリ・レコードを制御ファイルから消去するには、制御ファイルを再作成します。

関連項目:
DROP CATALOGコマンドの構文については、『Oracle Databaseバックアップおよびリカバリ・リファレンス』、カタログからデータベースを登録解除する方法については「リカバリ・カタログからのターゲット・データベースの登録の解除」を参照してください。

第V部

障害の診断および対応

次の章では、メディア障害およびデータ破損に対する診断および対応方法について説明します。この部に含まれる章は次のとおりです。

- 第14章「RMANのデータ修復の概要」

- 第15章「データ・リカバリ・アドバイザを使用した障害の診断および修復」

- 第16章「データベース・ファイルおよびバックアップの検証」

- 第17章「データベースの完全リカバリの実行」

- 第18章「フラッシュバックおよびデータベースのPoint-in-Timeリカバリの実行」

- 第19章「ブロック・メディア・リカバリの実行」

- 第20章「RMANのリカバリの実行: 高度な例」

- 第21章「RMANの表領域のPoint-in-Timeリカバリ(TSPITR)の実行」

14 RMANのデータ修復の概要

この章では、データ修復を実行するために理解しておく必要がある一般的な概念について説明します。この章の内容は次のとおりです。

- RMANのデータ修復の概要

- RMANのリストア操作

- RMANのメディア・リカバリ

RMANのデータ修復の概要

「データ保護」で説明されているように、バックアップおよびリカバリ計画の主な目的はデータの保護です。効果的で効率的な計画を立案するために重要な点は、データ修復の基本的な方法を理解することです。

データ修復が必要な問題

Oracle Databaseの正常な稼働を停止させたり、データベースのI/O処理に影響を与える問題はいくつかありますが、通常、ユーザー・エラー、アプリケーション・エラーおよびメディア障害が発生した場合にのみDBAが介入する必要があります。

ユーザー・エラー

ユーザー・エラーは、アプリケーション・ロジックのエラーまたは誤操作のため、データベースのデータが誤って変更または削除された場合に発生します。たとえば、ユーザーが間違ったデータベースにログインしてデータベースの表を削除した場合などです。ユーザー・エラーは、データベースの停止時間を発生させる最も大きな原因であるとみなされています。

アプリケーション・エラー

ソフトウェアの障害によってデータ・ブロックが破損する場合もあります。物理的な破損(メディア破損とも呼ばれる)の場合、ブロックがデータベースで認識されません。

メディア障害

メディア障害は、通常の操作中に、データベースの外部の問題によってファイルに対する読取りまたは書込みができなくなった場合に発生します。典型的なメディア障害としては、ディスク障害、データベース・ファイルの削除などがあります。メディア障害は、ユーザー・エラーまたはアプリケーション・エラーほど一般的ではありませんが、バックアップおよびリカバリ計画では、メディア障害に対する準備をしておく必要があります。

RMANのデータ修復方法

予測する状況に基づいて、データの消失に対処するために次の各オプションを組み込むことを検討した後、これらのオプションを使用できるようにデータベースを設定します。

- データ・リカバリ・アドバイザ
このOracle Databaseインフラストラクチャを使用すると、障害を診断して対応する方法を提示し、自動的にその障害を修復できます。

データ・リカバリ・アドバイザの基本的な概念については、「データ・リカバリ・アドバイザの概要」を参照してください。

- 論理フラッシュバック機能
このOracleフラッシュバック技術機能のサブセットを使用すると、過去の時点の個々のデータベース・オブジェクトまたはトランザクションを表示したり、個々のデータベース・オブジェクトまたはトランザクションを過去の時点まで巻き戻すことができます。この機能では、RMANを使用する必要はありません。

論理フラッシュバック機能の基本的な概念および(必要に応じた)参照先については、「Oracleフラッシュバック技術およびデータベースのPoint-in-Timeリカバリの概要」を参照してください。

- Oracle Flashback Database
フラッシュバック・データベースとは、メディア・リカバリに類似したブロックレベルのリカバリ・メカニズムのことですが、通常、高速で、リストアするバックアップは必要としません。事前にフラッシュバック・ロギングを有効にしているかぎり、データファイルの古いコピーをバックアップからリストアせずに、データベース全体を前の状態に戻すことができます。データベースのフラッシュバック・ロギング用または保証付きリストア・ポイント用に高速リカバリ領域を構成しておく必要があります。

フラッシュバック・データベースの基本的な概念については、「Point-in-Timeリカバリおよびフラッシュバック機能の基本的な概念」を参照してください。

- データファイル・メディア・リカバリ
この形式のメディア・リカバリでは、データファイルのバックアップをリストアし、アーカイブREDOログまたは増分バックアップを適用して、消失した変更をリカバリできます。データベース全体またはデータベースのサブセットのいずれかをリカバリすることができます。データファイルのメディア・リカバリは、最も汎用的な形式のリカバリで、物理的な破損および論理的な破損の両方から保護できます。

データファイルのメディア・リカバリの基本的な概念については、この章で説明します。方法については、第17章「データベースの完全リカバリの実行」および「データベースのPoint-in-Timeリカバリの実行」を参照してください。

- ブロック・メディア・リカバリ
この形式のメディア・リカバリでは、データファイル全体ではなく、データファイル内の個々のブロックをリストアできます。

ブロック・メディア・リカバリの基本的な概念については、「ブロック・メディア・リカバリの概要」を参照してください。

- 表領域のPoint-in-Timeリカバリ(TSPITR)
これは特別な形式のPoint-in-Timeリカバリで、1つ以上の表領域をデータベースの残りの部分より前の時点までリカバリします。

TSPITRの基本的な概念については、「RMANのTSPITRの概要」を参照してください。

通常、前述の修復方法を使用するために必要な概念は、その方法とともに説明されています。この章では、RMANのいくつかのデータ修復方法に共通の概念について説明します。

RMANのリストア操作

RMANのリストア操作では、リストアされるファイルを選択してからRESTOREコマンドを実行します。通常は、メディア・リカバリの準備としてファイルをリストアします。次のタイプのファイルをリストアできます。

- データベース(すべてのデータファイル)

- 表領域

- 制御ファイル

- アーカイブREDOログ

- サーバー・パラメータ・ファイル

リストアされるデータファイルおよび制御ファイルには、デフォルトの場所または新しい場所を指定できます。デフォルトの場所にリストアする場合、RMANは、現在その場所に存在する同じ名前のすべてのファイルを上書きします。また、SET NEWNAMEコマンドを使用して、リストアされるデータファイルに対して新しい場所を指定することもできます。その後、SWITCHコマンドを実行して、新しい場所にあるリストアされたファイルが現行のデータファイルであることを示すように制御ファイルを更新できます。

参照:
RESTOREの構文および前提条件については、『Oracle Databaseバックアップおよびリカバリ・リファレンス』を参照してください。SET NEWNAMEの構文については、『Oracle Databaseバックアップおよびリカバリ・リファレンス』を参照してください。SWITCHの構文については、『Oracle Databaseバックアップおよびリカバリ・リファレンス』を参照してください。

バックアップの選択

RMANは、RMANリポジトリに存在する使用可能なバックアップ・セットまたはイメージ・コピーのレコードを使用して、リストア操作に使用する最適なバックアップを選択します。使用可能な最新のバックアップ、またはRESTOREコマンドで指定したUNTIL句を満たす最新のバックアップが選択されます。同じ時点の2つのバックアップが存在する場合、RMANはバックアップ・セットよりイメージ・コピーを選択します。これは、バックアップ・セットよりイメージ・コピーからのリストアの方が高速に実行できるためです(特に、テープ上に格納されている場合)。

RMANでバックアップをリストアする前に、RESTOREコマンドのすべての仕様を満たす必要があります。DEVICE TYPE句で制限していないかぎり、RESTOREコマンドでは、構成されたチャネルのすべてのデバイス・タイプでバックアップが検索されます。指定したすべての基準を満たす使用可能なバックアップがリポジトリに存在しない場合は、ファイルがリストアできないことを示すエラーが戻されます。

手動で割り当てたチャネルのみを使用する場合、チャネルを割り当てたメディアに使用可能なバックアップが存在しないと、バックアップ・ジョブが失敗する場合があります。自動チャネルを構成すると、指定した基準を満たすバックアップがRMANによって検索およびリストアされる可能性が高くなります。

バックアップ・セットがバックアップの暗号化で保護されている場合、RMANは、バックアップ・セットの内容をリストアする際にバックアップ・セットを自動的に復号化します。透過的に暗号化されたバックアップは、Oracleウォレットがオープンしていて使用可能な場合にかぎり、ユーザーが介入せずにリストアできます。パスワード暗号化バックアップをリストアするには、正しいパスワードを入力する必要があります。

関連項目:
「高度なチャネル・オプションの構成」

リストア・フェイルオーバー

RMANは、自動的にリストア・フェイルオーバーを使用し、破損したバックアップまたはアクセスできないバックアップをスキップして使用可能なバックアップを検索します。バックアップが検出されなかった場合、または破損したデータがバックアップに含まれている場合、RMANは、目的のファイルをリストアするための別のバックアップを自動的に検索します。

RMANは、実行しているフェイルオーバーのタイプを示すメッセージを生成します。たとえば、RMANは、同じファイルの別のバックアップにフェイルオーバーする場合、次のようなメッセージを表示します。

failover to piece handle=/u01/backup/db_1 tag=BACKUP_031009

RMANは、使用可能なコピーが存在しない場合、以前のバックアップを検索します。次に、表示されるメッセージの例を示します。

ORA-19624: operation failed, retry possible
ORA-19505: failed to identify file "/u01/backup/db_1"
ORA-27037: unable to obtain file status
SVR4 Error: 2: No such file or directory
Additional information: 3
failover to previous backup

RMANは、すべての使用可能なバックアップを使い切るまでリストア・フェイルオーバーを繰り返し実行します。すべてのバックアップを使用できない場合またはバックアップが存在しない場合、RMANはデータファイルの再作成を試行します。リストア・フェイルオーバーは、RECOVER、RECOVER ... BLOCKおよびFLASHBACK DATABASEコマンドの実行中、アーカイブREDOログのリストアでエラーが発生した場合にも使用されます。

RMANのリストア操作およびASMの概要

自動ストレージ管理(ASM)ディスク・グループが使用されている場合、インカーネーションを含むデータ・ファイルの完全名が既存のデータ・ファイル名と一致しない場合のみ、RMANリストア操作によってデータ・ファイルの新規コピーが作成されます。完全修飾ASMファイル名の形式は+diskgroup/dbname/filetype/filetypetag.file.incarnationです。最初に制御ファイルをリストアしてから他のデータベース・ファイルをリストアする際、制御ファイル内のデータ・ファイルの名前が既存のデータ・ファイル名と一致しないために、データ・ファイルが再作成されることがあります。

次のいずれかの方法を使用して、リストアまたは複製操作中に、既存のデータ・ファイルが再作成されないようにします。

- 制御ファイルでは、各データ・ファイルに別名を使用します。別名にASMインカーネーション番号を含めることはできません。

- 制御ファイルのリストア後、他のデータベース・ファイルをリストアする前に、CATALOGコマンドを使用して、既存のデータ・ファイルがリストアされた制御ファイル内にカタログ化されていることを確認します。次に、SWITCHコマンドを使用して、リストアされた制御ファイルが既存のデータ・ファイルを指すようにします。

- SET NEWNAMEを使用して、データ・ファイルをリストアする前および制御ファイルをリストアした後に、データ・ファイルの名前を変更します。

リストアの最適化

RMANは、可能な場合、バックアップからデータファイルがリストアされないようにリストアの最適化を使用します。データファイルが適切な場所に存在し、そのヘッダーに予測された情報が含まれている場合、RMANはそのデータファイルをバックアップからリストアしません。

注意:
リストアの最適化では、データファイルのヘッダーのみがチェックされます。データファイルのボディに破損ブロックがあるかどうかはスキャンされません。

RESTOREコマンドのFORCEオプションを使用すると、この動作を無効にして、目的のファイルを無条件でリストアできます。

リストアの最適化は、複数のデータファイルをリストアする操作が中断された場合に特に有効です。たとえば、データベース全体のリストアで、1つ以外のすべてのデータファイルがリストアされた後に停電が発生したと想定します。同じRESTOREコマンドを再度実行した場合、RMANは、前回のリストア中にリストアされなかった1つのデータファイルのみをリストアします。

リストアの最適化は、データベースの複製時にも使用されます。複製にあるデータファイルが適切な場所に存在し、ヘッダーの内容が適切である場合、そのデータファイルは複製されません。ただし、RESTOREとは異なり、DUPLICATEではFORCEオプションがサポートされていません。リストアの最適化によってスキップされたデータファイルをRMANで強制的に複製するには、複製からこのデータファイルを削除した後、DUPLICATEコマンドを実行します。

関連項目:
Oracle RAC構成のRESTOREの動作の詳細は、『Oracle Real Application Clusters管理およびデプロイメント・ガイド』を参照してください。

RMANのメディア・リカバリ

メディア・リカバリでは、RMANは、リストアされたデータに変更を適用してそのデータを任意の時点にロールフォワードします。RMANでは、データファイルのメディア・リカバリまたはブロック・メディア・リカバリのいずれかを実行できます。

データファイルのメディア・リカバリは、現在または指定した他の時間に更新するための、リストアされたデータファイルに対するREDOログまたは増分バックアップのアプリケーションです。『Oracle Database概要』で説明されているように、RMANを使用して完全リカバリ、データベースのPoint-in-Timeリカバリ(DBPITR)または表領域のPoint-in-Timeリカバリ(TSPITR)を実行できます。RESTOREコマンドを使用して、消失または破損したデータファイルまたは制御ファイルのバックアップをリストアし、RECOVERコマンドを使用して、メディア・リカバリを実行することができます。

ブロック・メディア・リカバリとは、データファイル全体ではなく、個々のデータ・ブロックのリカバリのことです。ここでは、データファイルのメディア・リカバリについてのみ説明します。メディア・リカバリの特殊な形式であるブロック・メディア・リカバリについては、「ブロック・メディア・リカバリの概要」を参照してください。

増分バックアップおよびアーカイブREDOログの選択

メディア・リカバリは、RMANによって自動化されています。RMANは、増分バックアップおよびアーカイブREDOログを最適な組合せで自動的にリストアし、適用します。

必要なログ順序番号のコピーがディスク上に存在しないことがRMANリポジトリに示されている場合、RMANは、必要なログをバックアップから自動的にリストアします。デフォルトでは、アーカイブ先がUSE_DB_RECOVERY_FILE_DESTに設定されている場合、RMANは、アーカイブ・ログを高速リカバリ領域にリストアします。その他の場合は、初期化パラメータ・ファイルで指定された最初のローカルのアーカイブ先に、アーカイブREDOログをリストアします。

関連項目:
CROSSCHECKの構文については、『Oracle Databaseバックアップおよびリカバリ・リファレンス』を参照してください。

データベース・インカネーション

RESETLOGSオプションを使用してデータベースをオープンするたびに、データベース・インカネーションが作成されます。リカバリが完了すると、OPEN RESETLOGSを使用せずに通常の操作を再開できます。ただし、バックアップ制御ファイルを使用したDBPITRまたはリカバリの後は、RESETLOGSオプションを使用してデータベースをオープンする必要があります。これによって、データベースの新しいインカネーションが作成されます。異なる時刻に発生した2つの異なるREDOストリームのSCNが同じになっている場合は、混同を回避するために、データベースに新しいインカネーションが必要となります。間違ったREDOをデータベースに適用すると、データベースは破損します。

1つのデータベースに複数のインカネーションが存在するかどうかによって、RMANによる現行のインカネーション・パスに存在しないバックアップの処理方法が決まります。通常、使用に適したインカネーションは現行のデータベース・インカネーションです。ただし、データベースを以前のインカネーションにリセットする方法が最適な場合もあります。たとえば、実行したPoint-in-Timeリカバリの結果が適切でなく、データベースをRESETLOGSより前の時点に戻す必要がある場合があります。データベース・インカネーションを理解することによって、そのような状況に備えることができます。

OPEN RESETLOGS操作

RESETLOGSオプションを指定してデータベースをオープンすると、データベースによって次の処理が実行されます。

- 現行のオンラインREDOログがアーカイブされ(アクセス可能な場合)、オンラインREDOログの内容が消去されて、ログ順序番号が1にリセットされます。
たとえば、現行のオンラインREDOログの順序が1000および1001である場合、RESETLOGSでデータベースをオープンすると、ログ1000および1001がアーカイブされ、オンライン・ログは順序1および2にリセットされます。

- 現在存在していない場合は、オンラインREDOログ・ファイルが作成されます。

- 制御ファイル内のREDOスレッド・レコードおよびオンラインREDOログ・レコードが、新しいデータベース・インカネーションの開始時点の状態に初期化されます。
具体的には、REDOスレッドのステータスがCLOSEDに、REDOスレッド・レコード内の現行のスレッド順序が1に、各REDOスレッドのスレッド・チェックポイントがログ順序の最初である1に設定され、各スレッドからREDOログが1つ選択され、その順序が1に初期化されます。

- すべての現行のデータファイル、オンラインREDOログおよび後続のアーカイブREDOログが、新しいRESETLOGS SCNおよびタイムスタンプによって更新されます。

RESETLOGS SCNとタイムスタンプが一致しないかぎり、データファイルにアーカイブREDOログは適用されません。そのため、RESETLOGS要件を指定すると、現行のインカネーションの直接の親インカネーションのものではないアーカイブ・ログによってデータファイルが破損されることを回避できます。インカネーション間の関係については、後続の項で説明します。

以前のリリースでは、OPEN RESETLOGSの直後にデータベースをバックアップすることが推奨されていました。今回のリリースでは、他のバックアップと同様にRESETLOGSの実行前のバックアップを簡単にリカバリできるため、新しいデータベースのバックアップを作成するかどうかは任意です。RESETLOGSを介したリカバリを実行するには、最後のバックアップ以降に生成されたすべてのアーカイブ・ログおよび1つ以上の制御ファイル(現行のファイル、バックアップまたは作成したファイル)が必要です。

データベース・インカネーション間の関係

データベース・インカネーションは、相互に次の関係を持つことができます。

- 現行のインカネーションは、データベースで現在操作されているインカネーションです。

- OPEN RESETLOGS操作によって、あるインカネーションから現行のインカネーションが分岐している場合、そのインカネーションを、現行のインカネーションの親インカネーションといいます。

- 親インカネーションの親は、祖先インカネーションです。また、祖先インカネーションのすべての親も現行インカネーションの祖先です。

- 現行インカネーションの直系祖先パスは、最も古いインカネーションで始まり、現行インカネーションの祖先、親インカネーションまたは現行インカネーションへのブランチのみを含みます。

REDOのストリームを一意にタグ付けして識別するために、インカネーション番号が使用されます。図14-1に、複数のインカネーションを持つデータベースを示します。各インカネーションに、異なるインカネーション番号が付けられています。

図14-1 データベース・インカネーションの履歴

データベースのインカネーション1はSCN 1で始まり、SCN 1000からSCN 2000まで続いています。インカネーション1のSCN 2000で、Point-in-Timeリカバリを実行してSCN 1000まで戻り、RESETLOGSオプションを指定してデータベースをオープンするとします。これによって、インカネーション2はSCN 1000で始まり、SCN 3000まで続きます。この例では、インカネーション1はインカネーション2の親となります。

インカネーション2のSCN 3000で、Point-in-Timeリカバリを実行してSCN 2000まで戻り、RESETLOGSオプションを指定してデータベースをオープンするとします。この例では、インカネーション2はインカネーション3の親となります。インカネーション1はインカネーション3の祖先です。

データベースでDBPITRまたはフラッシュバック・データベースが実行されると、いずれのインカネーションが現行インカネーションであるかによって、SCNが複数の時点を示す場合があります。たとえば、図14-1のSCN 1500は、インカネーション1または2でのSCNを示す場合があります。

RESET DATABASE TO INCARNATIONコマンドを使用すると、SCNが特定のデータベース・インカネーションの参照の範囲にあると解釈されます。FLASHBACK、RESTOREまたはRECOVERを使用して現行以外のデータベース・インカネーションのSCNに戻る場合は、RESET DATABASE TO INCARNATIONコマンドが必要です。ただし、「リカバリ・カタログのデータベース・インカネーションの再設定」で説明するように、RMANはフラッシュバックでRESET DATABASE TO INCARNATIONコマンドを暗黙的に実行します。

関連項目:

- 「祖先インカネーションへのデータベースのリカバリ」

- RESET DATABASEコマンドの詳細は、『Oracle Databaseバックアップおよびリカバリ・リファレンス』を参照してください。

孤立したバックアップ

データベースが複数のインカネーションを持つ場合、一部のバックアップは孤立したバックアップの可能性があります。孤立したバックアップとは、直系祖先パス内にないデータベースのインカネーションで作成されたバックアップのことです。

図14-1の例を想定します。インカネーション3が現行インカネーションの場合、次のバックアップが孤立します。

- SCN 1000より後のインカネーション1のすべてのバックアップ

- SCN 2000より後のインカネーション2のすべてのバックアップ

これに対して、次のバックアップは、直系祖先パス内にあるため孤立しません。

- SCN 1000より前のインカネーション1のすべてのバックアップ

- SCN 2000より前のインカネーション2のすべてのバックアップ

- インカネーション3のすべてのバックアップ

直系祖先パス内にないSCNまでデータベースをリストアする場合は、孤立したバックアップを使用できます。RMANは、OPEN RESETLOGS操作が実行された場合でも、最も古いバックアップからリカバリする時点までのアーカイブ・ログが連続して存在しているかぎり、親および祖先のインカネーションからバックアップをリストアして、現在の時点までリカバリすることができます。また、RMANは、バックアップに示されている変更が取り消されたことがないインカネーションから制御ファイルをリストアする場合、孤立したバックアップを使用してリストアおよびリカバリを実行できます。

15 データ・リカバリ・アドバイザを使用した障害の診断および修復

この章では、RMANのデータ・リカバリ・アドバイザ・ツールを使用して、データベースの障害を診断および修復する方法について説明します。この章の内容は次のとおりです。

- データ・リカバリ・アドバイザの概要

- 障害の表示

- データベースの検証によるブロック破損の確認

- 修復オプションの決定

- 障害の修復

- 障害のステータスおよび優先順位の変更

データ・リカバリ・アドバイザの概要

この項では、データ・リカバリ・アドバイザの目的および基本的な概念について説明します。

データ・リカバリ・アドバイザの目的

データ・リカバリ・アドバイザは、データ障害を自動的に診断し、適切な修復オプションを判断して提示し、ユーザーの要求に応じて修復を実行するOracle Databaseツールです。このコンテキストでは、データ障害とはディスク上の永続的なデータの破損または損失のことです。データの自動修復用の集中化されたツールであるデータ・リカバリ・アドバイザを使用すると、Oracle Databaseの管理性および信頼性が向上し、MTTRを短縮できます。

データ障害を診断し、修復に最適な計画を立案するには、高度なトレーニングおよび経験が必要です。データ・リカバリ・アドバイザには、従来の修復手法と比較して、次のようなメリットがあります。

- データ・リカバリ・アドバイザは、データベース・プロセスで破損が検出されてエラーが通知される前に、データ障害の検出、分析および修復を行うことができます。早い時期に警告することによって、破損による損害を最小限に抑えることができます。

- データ障害の症状を手動で評価し、症状を関連付けて問題陳述文にまとめる作業は、複雑で時間のかかる、エラーが発生しやすい作業です。データ・リカバリ・アドバイザは、自動的に障害を診断してその影響を評価し、発見した内容をユーザーにレポートします。

- 通常、ユーザーは修復の影響とともに修復オプションを手動で判断する必要があります。複数の障害が発生している場合、ユーザーは修復を実行する正しい順序を判断し、修復を統合する必要があります。一方、データ・リカバリ・アドバイザは、最適な修復オプションを自動的に判断し、それらのオプションが環境に適していることを確認するためのチェックを実行します。

- データの修復は、複雑でエラーが発生しやすい作業です。自動修復オプションを選択すると、データ・リカバリ・アドバイザによって修復が実行され、修復に成功したことが確認されます。

データ・リカバリ・アドバイザの基本的な概念

この項では、データ・リカバリ・アドバイザを使用する前に理解しておく必要がある概念について説明します。

データ・リカバリ・アドバイザのユーザー・インタフェース

データ・リカバリ・アドバイザには、コマンドラインおよびGUIの両方のインタフェースがあります。GUIインタフェースは、Oracle Enterprise Manager Database ControlおよびGrid Controlで使用できます。データベースのホームページの「可用性」タブにある「リカバリの実行」をクリックすると、図15-1に示すページにナビゲートできます。

図15-1 データ・リカバリ・アドバイザ

RMANのコマンドライン・インタフェースでのデータ・リカバリ・アドバイザ・コマンドは、LIST FAILURE、ADVISE FAILURE、REPAIR FAILUREおよびCHANGE FAILUREです。

障害は、データベースによって自動的に検出されるか、またはVALIDATEコマンドなどの手動チェックによって検出されます。LIST FAILUREコマンドを使用すると、障害に関する問題陳述文およびデータベースの操作に対するそれらの障害の影響を表示できます。各障害は、障害番号によって一意に識別されます。同じRMANセッションでADVISE FAILUREコマンドを使用すると、修復オプションを表示できます。通常、これらのオプションには、自動オプションと手動オプションの両方があります。

ADVISE FAILUREを実行した後、障害を手動で修復するか、またはREPAIR FAILUREコマンドを実行して障害を自動的に修復することができます。修復とは、1つ以上の障害を修復する操作のことです。修復の例としては、ブロック・メディア・リカバリ、データファイル・メディア・リカバリ、Oracle Flashback Databaseなどがあげられます。自動修復オプションを選択すると、データ・リカバリ・アドバイザは修復に成功したかどうかを検証し、該当する修復済の障害をクローズします。

関連項目:
Enterprise Managerによるバックアップおよびリカバリの実行方法は、『Oracle Database 2日でデータベース管理者』を参照してください。

データ整合性チェック

チェッカーとは、データベースまたはデータベース・コンポーネントの状態を評価するために状態モニターに登録された診断操作またはプロシージャのことです。状態の評価はデータ整合性チェックと呼ばれ、事後対応的または事前対応的に実行できます。

通常、障害は事後対応的に検出されます。破損したデータに対するデータベース操作でエラーが発生すると、データ整合性チェックが自動的に開始され、データベースでエラーに関連する障害が調査されます。障害が診断されると、その障害は自動診断リポジトリ(ADR)に記録されます。ADRは、データベースの外部に格納されているディレクトリ構造です。データベースによって障害が検出され、ADRに格納された後にのみ、データ・リカバリ・アドバイザを使用して、修復アドバイスを生成し、障害を修復できます。

データ整合性チェックを事前対応的に実行することもできます。チェックは状態モニターを介して実行します。状態モニターによって、事後対応的にチェックが実行された場合と同じ方法で障害が検出され、格納されます。また、「データベースの検証によるブロック破損の確認」で説明するように、VALIDATEおよびBACKUP VALIDATEコマンドを使用してブロック破損をチェックすることもできます。

関連項目:
状態モニターの使用方法については、『Oracle Database管理者ガイド』を参照してください。

障害

障害とは、データ整合性チェックによって検出される永続的なデータの破損のことです。障害は、エラー・メッセージやアラートなどの目に見える症状として示される場合がありますが、診断された問題を表すため、症状とは異なります。データベースによって問題が障害として診断された後、データ・リカバリ・アドバイザを使用して、障害に関する情報を取得し、障害の修復を行うことができます。

障害情報はデータベース自体には格納されていないため、この障害情報にアクセスするためにデータベースをオープンまたはマウントする必要はありません。障害は、データベースがNOMOUNTモードで起動されている場合に表示できます。したがって、制御ファイルおよびリカバリ・カタログの可用性が、検出された障害の表示に影響することはありません。ただし、修復の可能性に影響を与えることはあります。

データ・リカバリ・アドバイザでは、次のような障害を診断できます。

- 存在しない、適切なアクセス権限がない、オフラインになっているなどの理由でアクセスできないデータファイルや制御ファイルなどのコンポーネント

- ブロック・チェックサム障害、無効なブロック・ヘッダー・フィールド値などの物理的な破損

- 他のデータベース・ファイルより古いデータファイルなどの矛盾

- ハードウェア・エラー、オペレーティング・システムのドライバの障害、オペレーティング・システムのリソース制限(たとえば、オープンしているファイルの数)の超過などのI/O障害

データ・リカバリ・アドバイザが、論理的な破損の一部を検出または処理することがあります。一般的に、このタイプの破損の場合は、Oracleサポート・サービスに連絡する必要があります。

障害ステータス

すべての障害には、OPENまたはCLOSEDの障害ステータスがあります。障害ステータスは、適切な修復操作が行われるまでOPENのままです。障害が修復されると、ステータスはCLOSEDに変更されます。

LIST FAILUREを実行するたびに、データ・リカバリ・アドバイザは、ステータスがOPENのすべての障害を再検証し、存在しなくなった障害をクローズします。したがって、別の手順の一部として障害を修復した場合、または障害が自然に消滅した一時的な問題であった場合、LIST FAILUREを実行すると、障害は自動的にクローズされます。

CHANGE FAILUREを使用すると、ステータスがOPENの障害を手動で修復した場合にそのステータスをCLOSEDに変更できます。ただし、CHANGE FAILURE ... CLOSEDは、なんらかの理由で障害が自動的にクローズされなかった場合にのみ使用することをお薦めします。CHANGEを使用して手動でクローズした障害が存在したままになっている場合、データ・リカバリ・アドバイザは、適切なデータ整合性チェックを実行する際に別の障害IDでこの障害を再作成します。

障害優先順位

すべての障害には、CRITICAL、HIGHまたはLOWの障害優先順位があります。データ・リカバリ・アドバイザは、診断された障害に対してCRITICALまたはHIGHの優先順位のみを割り当てます。

優先順位がCRITICALの障害は、データベース全体を使用できなくするため、すぐに対応する必要があります。たとえば、現行の制御ファイルを格納するディスクに障害が発生した場合などがあります。優先順位がHIGHの障害は、データベースの一部を使用できなくしたり、リカバリできなくするため、通常は迅速に修復する必要があります。これらの障害の例としては、ブロック破損やアーカイブREDOログの欠落などがあります。

障害に優先順位HIGHが割り当てられていても、データベースの可用性およびリカバリ可能性にはほとんど影響がない場合は、優先順位をLOWに下げることができます。優先順位LOWは、より重要な障害が修復されるまで、この障害を無視できることを示します。

デフォルトでは、LIST FAILUREを実行すると、優先順位がCRITICALおよびHIGHの障害のみが表示されます。CHANGEコマンドを使用して、LOWおよびHIGHの障害のステータスは変更できますが、CRITICALの障害のステータスは変更できません。優先順位をLOWに変更する主な理由としては、LIST FAILUREの出力を削減することがあげられます。別の障害などのためにこの時点で障害を再検証できない場合、LIST FAILUREには障害がOPENとして表示されます。

障害のグループ化

わかりやすくするために、データ・リカバリ・アドバイザによって、関連する障害がグループ化されます。たとえば、1つのファイル内の20の異なるブロックが破損している場合、これらの障害は1つの親障害にまとめられます。 デフォルトでは、データ・リカバリ・アドバイザは、障害のグループに関する情報を表示します。ただし、DETAILオプションを使用して、個々の下位の障害に関する情報を表示することもできます。

下位の障害の形式は通常の障害と同じです。下位の障害に関するアドバイスの取得およびその修復は、個別に行うことも、他の障害と組み合せて行うこともできます。

手動処理および自動修復オプション

ADVISE FAILUREコマンドでは、手動および自動の両方の修復オプションを表示できます。データ・リカバリ・アドバイザは、手動処理を必須またはオプションのいずれかとしてカテゴリ化します。

場合によっては、手動処理のみが可能であることがあります。消失した制御ファイルのバックアップが存在しないとします。この場合、手動処理では、CREATE CONTROLFILE文を実行します。自動修復が利用可能ではないため、データ・リカバリ・アドバイザでは、この手動処理を必須として表示します。これに対して、欠落したデータファイルに対してRMANバックアップが存在するとします。この場合、REPAIR FAILUREコマンドを実行すると、データファイルをリストアおよびリカバリすることによって、修復を自動的に実行できます。データファイルが誤って名前変更されたり移動された場合は、オプションの手動処理として、データファイルをリストアします。データ・リカバリ・アドバイザは、データファイルのリストアやリカバリなどの大規模な修復を回避できる場合に、オプションの手動処理を推奨します。

手動処理とは異なり、自動修復はデータ・リカバリ・アドバイザによって実行されます。ADVISE FAILUREコマンドによって、各自動修復オプションのオプションIDが表示され、処理の要約が示されます。

データ・リカバリ・アドバイザでは、自動修復を推奨する前に、実行可能性チェックを実行します。たとえば、データ・リカバリ・アドバイザは、メディア・リカバリに必要なすべてのバックアップおよびアーカイブREDOログが存在しており、一貫性があるかどうかをチェックします。データ・リカバリ・アドバイザでは、特定のバックアップおよびアーカイブREDOログを必要とすることがあります。リカバリに必要なファイルが利用できない場合、リカバリを行うことはできません。

注意:
パフォーマンス上の理由から、データ・リカバリ・アドバイザは、全ファイルの全バイトを完全にチェックするわけではありません。このため、バックアップまたはアーカイブREDOログ・ファイルの破損が原因で、実行可能な修復が失敗する場合があります。

統合された修復

データ・リカバリ・アドバイザは、可能なかぎり複数の障害が1回で修復されるように修復を統合します。統合された修復では、手順が複数にわたる場合があります。

修復は統合できないこともあります。1つの障害によって、他の障害の修復を作成できない場合があるためです。たとえば、制御ファイルが欠落している場合、データファイルの修復の可能性を判断することはできません。 このような場合、データ・リカバリ・アドバイザは、修復可能な障害に対して1つの修復オプションを生成し、この時点では修復できない障害が存在することを示すメッセージをユーザーに出力します。提示された修復を実行した後、LIST、ADVISEおよびREPAIRを繰り返し実行すると、残りの障害を修復できます。

スクリプトの修復

データ・リカバリ・アドバイザは、自動修復オプションの生成時に常に、RMANで障害の修復に使用されるコマンドに関するスクリプトを作成します。データ・リカバリ・アドバイザは、このスクリプトの場所を出力します。このスクリプトは、オペレーティング・システムに存在するテキスト・ファイルです。例15-1に、修復スクリプトの例を示します。この例は、データ・リカバリ・アドバイザによる消失したデータファイル27の修復計画を示しています。

例15-1 修復スクリプトのサンプル

# restore and recover data file
sql 'alter database datafile 27 offline';
restore datafile 27;
recover datafile 27;
sql 'alter database datafile 27 online';

データ・リカバリ・アドバイザで障害を自動的に修復しない場合は、スクリプトをコピーして編集し、手動で実行できます。

サポートされているデータベースの構成

現行のリリースでは、データ・リカバリ・アドバイザはシングル・インスタンス・データベースのみをサポートしています。Oracle Real Application Clusters(Oracle RAC)データベースはサポートしていません。

すべてのOracle RACインスタンスを停止するデータ障害が発生した場合は、データベースをシングル・インスタンス・モードでマウントして、データ・リカバリ・アドバイザを使用し、制御ファイル、SYSTEMデータファイルおよびデータ・ディクショナリの障害を検出および修復できます。また、データ・リカバリ・チェックを事前対応的に実行して、他のデータベース・コンポーネントのデータ障害をテストすることもできます。この方法では、他のクラスタ・インスタンスに対してローカルなデータ障害(アクセス不能なデータファイルなど)は検出されません。

Data Guard環境では、データ・リカバリ・アドバイザで次のことを行うことはできません。

- フィジカル・スタンバイ・データベースから転送されたファイルを使用して、プライマリ・データベース上の障害を修復する。

- スタンバイ・データベースの障害を診断し、修復する。

ただし、プライマリ・データベースを使用できない場合は、データ・リカバリ・アドバイザによって、スタンバイ・データベースへのフェイルオーバーを薦められることがあります。フェイルオーバー後に、古いプライマリ・データベースを修復できます。Enterprise Manager Grid ControlをData Guard構成で使用している場合は、データ・リカバリ・アドバイザの推奨事項ページからフェイルオーバーを開始できます。

関連項目:
Data Guard構成でのRMANの使用方法については、『Oracle Data Guard概要および管理』を参照してください。

障害の診断および修復の基本手順

データ・リカバリ・アドバイザのワークフローは、障害の疑いが発生したときまたは障害が検出されたときに始まります。障害は、エラー・メッセージ、アラート、トレース・ファイル、データ整合性チェックの失敗などの多くの方法で検出できます。「データ整合性チェック」で説明されているように、データベースでは、エラーが発生した場合に障害を自動的に診断できます。

障害に対応する場合の基本的なプロセスでは、RMANセッションを開始し、その同じセッションで次の手順をすべて実行します。

1. LIST FAILUREコマンドを実行して、障害を表示します。
このタスクの詳細は、「障害の表示」を参照してください。

2. データベースによって自動的に診断されていない障害の存在が疑われる場合は、VALIDATE DATABASEを実行して、破損ブロックおよび欠落しているファイルを確認します。
VALIDATEによって問題が検出されると、RMANが障害の評価の実行をトリガーします。障害が検出されると、データ・リカバリ・アドバイザからアクセスできる自動診断リポジトリにログが記録されます。

このタスクの詳細は、「データベースの検証によるブロック破損の確認」を参照してください。

3. ADVISE FAILUREコマンドを実行して、修復オプションを決定します。
このタスクの詳細は、「修復オプションの決定」を参照してください。

4. 修復オプションを選択します。障害は、手動で修復するか、またはREPAIR FAILUREコマンドを実行して自動的に修復することができます。
このタスクの詳細は、「障害の修復」を参照してください。

5. 最初の手順に戻り、すべての障害が修復されていることを確認するか、または残っている障害を特定します。

この項に示すものと異なる順序で障害を診断および修復する手順を実行すると、エラーが発生する場合があります。

必要に応じて、データ・リカバリ・アドバイザのワークフロー内の任意の時点でCHANGE FAILUREコマンドを使用して、障害優先順位をLOWからHIGHに、またはHIGHからLOWに変更するか、あるいは手動で修復された障害をクローズすることができます。このタスクの詳細は、「障害のステータスおよび優先順位の変更」を参照してください。

障害の表示

1つ以上のデータベースの障害が発生した疑いがあるか、または発生したことがわかっている場合は、LIST FAILUREを使用して、これらの障害に関する情報を取得します。障害のすべてまたはサブセットを表示し、様々な方法で出力を制限できます。障害は、障害番号によって一意に識別されます。これらの番号は連続していないため、障害番号が離れていても問題はありません。

LIST FAILUREコマンドは、新しい障害を診断するためのデータ整合性チェックは実行しません。かわりに、以前に実行された評価の結果を表示します。したがって、LIST FAILUREを繰り返し実行すると、コマンドを実行してから次にコマンドを実行するまでの間に発生したエラーに対応してデータベースで新しい障害が自動的に診断された場合にのみ、その障害が検出されます。ただし、LIST FAILUREを実行すると、データ・リカバリ・アドバイザは既存のすべての障害を再検証します。ユーザーが障害を手動で修復した場合または一時的な障害が消滅した場合、データ・リカバリ・アドバイザは、これらの障害をLIST FAILUREの出力から削除します。別の障害などのためにこの時点で障害を再検証できない場合、LIST FAILUREによって障害がOPENとして表示されます。

すべての障害の表示

データベースで発生する問題を確認する最も簡単な方法は、LIST FAILUREコマンドを使用する方法です。

すべての障害を表示する手順

1. RMANを起動し、ターゲット・データベースに接続します。ターゲット・データベース・インスタンスが起動されている必要があります。

2. LIST FAILUREコマンドを実行します。
次の例では、データ・リカバリ・アドバイザで認識されるすべての障害をレポートします(ページに収まるように出力の形式が再設定されています)。

RMAN> LIST FAILURE;

List of Database Failures
=========================

Failure ID Priority Status    Time Detected Summary
---------- -------- --------- ------------- -------
142        HIGH     OPEN      23-APR-07     One or more non-system datafiles are missing
101        HIGH     OPEN      23-APR-07     Datafile 1: '/disk1/oradata/prod/system01.dbf' contains one or more corrupt blocks

この例では、RMANは、欠落しているデータファイルのグループおよび破損ブロックが含まれているデータファイルの2つの異なる障害をレポートしています。出力には、各障害の一意の識別子(142および101)、優先順位、ステータスおよび検出時刻が示されています。

3. 必要に応じて、LIST FAILURE ... DETAILコマンドを実行して、障害を個々に表示します。
「障害のグループ化」で説明されているように、データ・リカバリ・アドバイザは可能なかぎり障害を統合します。障害を個々に表示するには、DETAILオプションを指定します。たとえば、ファイル内で複数のブロックが破損している場合、DETAILオプションを指定すると、各ブロックの破損が表示されます。次の例では、障害101に関する詳細情報を表示します。

RMAN> LIST FAILURE 101 DETAIL;

List of Database Failures
=========================

Failure ID Priority Status    Time Detected Summary
---------- -------- --------- ------------- -------
101        HIGH     OPEN      23-APR-07     Datafile 1: '/disk1/oradata/prod/system01.dbf' contains one or more corrupt blocks
List of child failures for parent failure ID 101
Failure ID Priority Status    Time Detected Summary
---------- -------- --------- ------------- -------
104        HIGH     OPEN      23-APR-07     Block 56416 in datafile 1: '/disk1/oradata/prod/system01.dbf' is media corrupt
Impact: Object BLKTEST owned by SYS might be unavailable

4. 「修復オプションの決定」に進み、LIST FAILUREコマンドによって表示された障害の修復方法を決定します。

障害のサブセットの表示

LIST FAILUREでは、さらに詳しい出力を表示できるのみでなく、出力を制限することもできます。たとえば、CRITICAL、HIGH、LOWまたはCLOSEDオプションを使用してLIST FAILUREを実行すると、特定のステータスまたは優先順位を持つ障害のみを表示できます。また、EXCLUDE FAILUREを指定して、指定した障害を出力から除外することもできます。

障害のサブセットを表示する手順

1. RMANを起動し、ターゲット・データベースに接続します。ターゲット・データベース・インスタンスが起動されている必要があります。

2. 必要なオプションを指定してLIST FAILUREを実行します。
次の例は、いくつかのLIST FAILUREコマンドを示しています。

LIST FAILURE LOW;
LIST FAILURE CLOSED;
LIST FAILURE EXCLUDE FAILURE 234234;

関連項目:
LIST FAILUREコマンドの詳細は、『Oracle Databaseバックアップおよびリカバリ・リファレンス』を参照してください。

データベースの検証によるブロック破損の確認

「データ整合性チェック」で説明されているように、破損したデータへのアクセスをユーザーのトランザクションで試行すると、データベースはそれに対応してデータ整合性チェックを実行します。遅延障害は検出されない場合もあります。たとえば、データ・ブロック破損エラーが発生すると、データベースは、エラーが発生したブロックおよびそのブロックに隣接している他のブロックを検証する事後対応型データ整合性チェックを実行します。ただし、エラーが発生したブロックに隣接していないブロックが破損している場合もあります。また、データベースによって読み取られない破損したブロックは、事後対応型データ整合性チェックでは検出されません。

事前対応型データ整合性チェックを効果的に実行する方法の1つとして、RMANでVALIDATEまたはBACKUP VALIDATEコマンドを実行する方法があります。これらのコマンドによって、データファイルおよび制御ファイルに物理的な破損および論理的な破損がないかどうかを確認できます。RMANによってブロック破損が検出された場合、自動診断リポジトリにログが記録され、1つ以上の障害が作成されます。その後、データ・リカバリ・アドバイザを使用すると、これらの障害に関する情報を表示して、これらの障害を修復することができます。

データベースを検証する手順

1. RMANを起動し、ターゲット・データベースに接続します。ターゲット・データベースはマウントされている必要があります。

2. 目的のデータベース・ファイルを検証します。
次の例では、VALIDATE DATABASEを使用して、データベース全体の物理的および論理的な破損を確認します(出力例も示します)。「障害の表示」には一部のデータファイルが消失していることが示されているため、SKIP INACCESSIBLE句が指定されています。出力には、system01.dbfデータベース・ファイルに1つの新しい破損ブロック(Blocks Failing)があり、以前にデータベースによって破損とマークされたブロック(Marked Corrupt)がないことが示されています。

RMAN> VALIDATE CHECK LOGICAL SKIP INACCESSIBLE DATABASE;

Starting validate at 23-APR-07
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=103 device type=DISK
could not access datafile 28
skipping inaccessible file 28
RMAN-06060: WARNING: skipping datafile compromises tablespace USERS recoverability
RMAN-06060: WARNING: skipping datafile compromises tablespace USERS recoverability
channel ORA_DISK_1: starting validation of datafile
channel ORA_DISK_1: specifying datafile(s) for validation
input datafile file number=00001 name=/disk1/oradata/prod/system01.dbf
input datafile file number=00002 name=/disk1/oradata/prod/sysaux01.dbf
input datafile file number=00022 name=/disk1/oradata/prod/undotbs01.dbf
input datafile file number=00023 name=/disk1/oradata/prod/cwmlite01.dbf
input datafile file number=00024 name=/disk1/oradata/prod/drsys01.dbf
input datafile file number=00025 name=/disk1/oradata/prod/example01.dbf
input datafile file number=00026 name=/disk1/oradata/prod/indx01.dbf
input datafile file number=00027 name=/disk1/oradata/prod/tools01.dbf
channel ORA_DISK_1: validation complete, elapsed time: 00:00:25
List of Datafiles
=================
File Status Marked Corrupt Empty Blocks Blocks Examined High SCN
---- ------ -------------- ------------ --------------- ----------
1    FAILED 0              3536         57600           637711
File Name: /disk1/oradata/prod/system01.dbf
Block Type Blocks Failing Blocks Processed
---------- -------------- ----------------
Data       1              41876
Index      0              7721
Other      0              4467
.
.
.
File Status Marked Corrupt Empty Blocks Blocks Examined High SCN
---- ------ -------------- ------------ --------------- ----------
27   OK     0              1272         1280            400914
File Name: /disk1/oradata/prod/tools01.dbf
Block Type Blocks Failing Blocks Processed
---------- -------------- ----------------
Data       0              0
Index      0              0
Other      0              8

validate found one or more corrupt blocks
See trace file /disk1/oracle/log/diag/rdbms/prod/prod/trace/prod_ora_2596.trc
for details
channel ORA_DISK_1: starting validation of datafile
channel ORA_DISK_1: specifying datafile(s) for validation
including current control file for validation
including current SPFILE in backup set
channel ORA_DISK_1: validation complete, elapsed time: 00:00:01
List of Control File and SPFILE
===============================
File Type    Status Blocks Failing Blocks Examined
------------ ------ -------------- ---------------
SPFILE       OK     0              2
Control File OK     0              512
Finished validate at 23-APR-07

関連項目:

- 第16章「データベース・ファイルおよびバックアップの検証」

- VALIDATEコマンドの詳細は、『Oracle Databaseバックアップおよびリカバリ・リファレンス』を参照してください。

- Oracle Databaseが診断データを管理する方法については、『Oracle Database管理者ガイド』を参照してください。

修復オプションの決定

RMANセッションでLIST FAILUREを実行した後、ADVISE FAILUREコマンドを使用して修復オプションを表示します。このコマンドによって、障害のサマリーが出力され、修復されているステータスがOPENのすべての障害がクローズされます。

必要に応じて、ADVISE FAILUREコマンドによって手動および自動の修復オプションのリストが表示されます。最初に、必須またはオプションのいずれかとしてカテゴリ化された手動オプションが表示されます。オプションの手動の修復によって、データファイルのリストアやリカバリなどの大規模な処理を回避できる場合もあります。通常は、データベースに及ぶ影響が最も少なく、エラーが発生する可能性が最も少ない修復手法を使用します。

すべての障害に対する修復オプションの決定

1つ以上の障害が存在する場合は、通常、LIST FAILUREを使用して障害の情報を表示してから、同じRMANセッションでADVISE FAILUREを使用して修復オプションのレポートを取得します。

すべての障害に対する修復オプションを決定する手順

1. 「すべての障害の表示」の説明に従って障害を表示します。

2. 同じRMANセッションで、ADVISE FAILUREを実行します。
次の例では、データ・リカバリ・アドバイザで認識されるすべての障害に対する修復オプションを要求し、出力例(ページに収まるように形式が再設定されています)を示します。

RMAN> ADVISE FAILURE;

List of Database Failures
=========================

Failure ID Priority Status    Time Detected Summary
---------- -------- --------- ------------- -------
142        HIGH     OPEN      23-APR-07     One or more non-system datafiles
are missing
101        HIGH     OPEN      23-APR-07     Datafile 1: '/disk1/oradata/prod/system01.dbf' contains one or more corrupt blocks

analyzing automatic repair options; this may take some time
using channel ORA_DISK_1
analyzing automatic repair options complete

Mandatory Manual Actions
========================
no manual actions available

Optional Manual Actions
=======================
1. If file /disk1/oradata/prod/users01.dbf was unintentionally renamed or moved, restore it

Automated Repair Options
========================
Option Repair Description
------ ------------------
1      Restore and recover datafile 28; Perform block media recovery of
block 56416 in file 1
Strategy: The repair includes complete media recovery with no data loss
Repair script: /disk1/oracle/log/diag/rdbms/prod/prod/hm/reco_660500184.hm

前述の例では、ADVISE FAILUREによって、欠落しているデータファイルおよび破損ブロックが含まれているデータファイルの2つの障害がレポートされています。このコマンドでは必須の手動処理は表示されませんが、欠落しているデータファイルの名前が誤って変更されていないこと、または欠落しているデータファイルが誤って削除されていないことを確認するように指示されています。この自動修復オプションは、ブロック・メディア・リカバリおよび欠落したデータファイルのリストアとリカバリに関連しています。ADVISE FAILUREでは、修復スクリプトの場所が表示されます。

次の類似した例では、自動修復に必要なRMANバックアップまたはアーカイブREDOログが利用できない場合の出力を示します。ADVISE FAILUREコマンドで、必須の手動処理が表示されます。

RMAN> ADVISE FAILURE;

List of Database Failures
=========================

Failure ID Priority Status    Time Detected Summary
---------- -------- --------- ------------- -------
142        HIGH     OPEN      23-APR-07     One or more non-system datafiles
are missing
101        HIGH     OPEN      23-APR-07     Datafile 1: '/disk1/oradata/prod/system01.dbf' contains one or more corrupt blocks

analyzing automatic repair options; this may take some time
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=103 device type=DISK
analyzing automatic repair options complete

Mandatory Manual Actions
========================
1. If file /disk1/oradata/prod/users01.dbf was unintentionally renamed or moved, restore it
2. Contact Oracle Support Services if the preceding recommendations cannot be used, or if they do not fix the failures selected for repair

Optional Manual Actions
=======================
no manual actions available

Automated Repair Options
========================
Option Repair Description
------ ------------------
1      Perform block media recovery of block 56416 in file 1
Strategy: The repair includes complete media recovery with no data loss
Repair script: /disk1/oracle/log/diag/rdbms/prod/prod/hm/reco_1863891774.hm

3. 「障害の修復」に進み、LIST FAILURE出力によって表示された障害の修復方法を決定します。

障害のサブセットに対する修復オプションの決定

特定の障害に対する修復オプションを要求することもできます。障害は、ステータス(CRITICAL、HIGH、LOW)または障害番号で指定できます。EXCLUDE FAILUREを使用して、1つ以上の障害をレポートから除外することもできます。

障害のサブセットに対する修復オプションを決定する手順

1. 「すべての障害の表示」の説明に従って障害を表示します。

2. 同じRMANセッションで、必要なオプションを指定してADVISE FAILUREを実行します。
次の例では、障害101のみに対する修復オプションを要求します。

RMAN> ADVISE FAILURE 101;

List of Database Failures
=========================

Failure ID Priority Status    Time Detected Summary
---------- -------- --------- ------------- -------
101        HIGH     OPEN      23-APR-07     Datafile 1: '/disk1/oradata/prod/system01.dbf' contains one or more corrupt blocks

analyzing automatic repair options; this may take some time
using channel ORA_DISK_1
analyzing automatic repair options complete

Mandatory Manual Actions
========================
no manual actions available

Optional Manual Actions
=======================
no manual actions available

Automated Repair Options
========================
Option Repair Description
------ ------------------
1      Perform block media recovery of block 56416 in file 1
Strategy: The repair includes complete media recovery with no data loss
Repair script: /disk1/oracle/log/diag/rdbms/prod/prod/hm/reco_708819503.hm

3. 「障害の修復」に進み、LIST FAILUREコマンドによって表示された障害の修復方法を決定します。

関連項目:
ADVISE FAILUREコマンドの詳細は、『Oracle Databaseバックアップおよびリカバリ・リファレンス』を参照してください。

障害の修復

この項では、データ・リカバリ・アドバイザを使用して、障害を自動的に修復する方法について説明します。

障害の修復の概要

ADVISE FAILUREで手動の修復が提示された場合は、これらの修復を最初に試行します。手動の修復が可能でない場合、または手動の修復ではすべての障害が修復されない場合は、REPAIR FAILUREを使用して、現行のRMANセッションでの最新のADVISE FAILUREコマンドで提示された障害の修復を自動的に実行することができます。

デフォルトでは、REPAIR FAILUREの実行を開始する前に確認を求められます。NOPROMPTオプションを指定して、確認のプロンプトが表示されないようにすることができます。コマンドの実行が開始されると、現行の修復フェーズが示されます。状況に応じて、RMANは、ユーザーに操作を求める場合があります。修復を実行した後、RMANは、この修復中に修復された可能性がある既存のすべての障害を再評価します。

通常は、修復を実行する前に、PREVIEWオプションを指定して修復をプレビューすることをお薦めします。RMANは、修復を行わず、すべての修復操作およびコメントが含まれているスクリプトを生成します。特定の修復オプションを指定しなかった場合、RMANは、現行セッションの最新のADVISE FAILUREコマンドの最初の修復オプションを使用します。デフォルトでは、修復スクリプトは標準出力に表示されます。SPOOLコマンドを使用すると、編集可能なファイルにスクリプトを書き込むことができます。

関連項目:

- REPAIR FAILUREコマンドの詳細は、『Oracle Databaseバックアップおよびリカバリ・リファレンス』を参照してください。

- SPOOLコマンドの詳細は、『Oracle Databaseバックアップおよびリカバリ・リファレンス』を参照してください。

障害の修復

デフォルトでは、スクリプトは標準出力に表示されます。SPOOLコマンドを使用すると、編集可能なファイルにスクリプトを書き込むことができます。

障害を修復する手順

1. 「すべての障害の表示」の説明に従って障害を表示します。

2. 「修復オプションの決定」の説明に従って修復オプションを表示します。

3. 必要に応じて、REPAIR FAILURE PREVIEWを実行します。
次の例では、RMANセッションの以前のADVISE FAILUREコマンドによって表示された最初の修復オプションをプレビューします。

RMAN> REPAIR FAILURE PREVIEW;

Strategy: The repair includes complete media recovery with no data loss
Repair script: /disk1/oracle/log/diag/rdbms/prod/prod/hm/reco_475549922.hm
contents of repair script:
# restore and recover data file
sql 'alter database datafile 28 offline';
restore datafile 28;
recover datafile 28;
sql 'alter database datafile 28 online';
# block media recovery
recover datafile 1 block 56416;

4. REPAIR FAILUREを実行します。
次の修復では、1つのデータファイルをリストアおよびリカバリし、1つの破損ブロックでブロック・メディア・リカバリを実行します。RMANによって、修復を行うかどうかの確認が求められます。ユーザーが入力したテキストは太字で示されています。

RMAN> REPAIR FAILURE;

Strategy: The repair includes complete media recovery with no data loss
Repair script: /disk1/oracle/log/diag/rdbms/prod/prod/hm/reco_475549922.hm
contents of repair script:
# restore and recover data file
sql 'alter database datafile 28 offline';
restore datafile 28;
recover datafile 28;
sql 'alter database datafile 28 online';
# block media recovery
recover datafile 1 block 56416;

Do you really want to execute the above repair (enter YES or NO)? YES
executing repair script

sql statement: alter database datafile 28 offline

Starting restore at 23-APR-07
using channel ORA_DISK_1

channel ORA_DISK_1: starting datafile backup set restore
channel ORA_DISK_1: specifying datafile(s) to restore from backup set
channel ORA_DISK_1: restoring datafile 00028 to /disk1/oradata/prod/users01.dbf
channel ORA_DISK_1: reading from backup piece /disk2/PROD/backupset/2007_04_18/o1_mf_nnndf_TAG20070418T182042_32fjzd3z_.bkp
channel ORA_DISK_1: piece handle=/disk2/PROD/backupset/2007_04_18/o1_mf_nnndf_TAG20070418T182042_32fjzd3z_.bkp tag=TAG20070418T182042
channel ORA_DISK_1: restored backup piece 1
channel ORA_DISK_1: restore complete, elapsed time: 00:00:03
Finished restore at 23-APR-07

Starting recover at 23-APR-07
using channel ORA_DISK_1

starting media recovery
media recovery complete, elapsed time: 00:00:01

Finished recover at 23-APR-07

sql statement: alter database datafile 28 online

Starting recover at 23-APR-07
using channel ORA_DISK_1
searching flashback logs for block images until SCN 429690
finished flashback log search, restored 1 blocks

starting media recovery
media recovery complete, elapsed time: 00:00:03

Finished recover at 23-APR-07
repair failure complete

5. 必要に応じて、LIST FAILUREを実行して確認します。

障害のステータスおよび優先順位の変更

CHANGE FAILUREコマンドを使用して、障害のステータスまたは優先順位を変更する必要がある場合もあります。たとえば、ブロックの破損の優先順位がHIGHで、そのブロックがほとんど使用されない表領域に存在する場合は、そのブロックの破損の優先順位を一時的にLOWに変更できます。

REPAIR FAILUREコマンド以外の方法で障害を修復すると、次回LIST FAILUREを実行した場合、データ・リカバリ・アドバイザはこの障害を暗黙的にクローズします。このため、通常はCHANGE FAILURE ... CLOSEDコマンドを実行する必要はありません。このコマンドは、自動障害再検証が正常に実行されなかったにもかかわらず、障害は存在していないと確信できる場合にのみ使用する必要があります。CHANGE FAILUREを使用して、存在したままになっている障害をクローズすると、データ・リカバリ・アドバイザは、適切なデータ整合性チェックを実行する際に別の障害IDでこの障害を再作成します。

通常、障害は障害番号で指定します。ALL、CRITICAL、HIGHまたはLOWを指定して、障害を一括で変更することもできます。障害は、CLOSED、PRIORITY HIGHまたはPRIORITY LOWに変更できます。

障害のステータスまたは優先順位を変更する手順

1. 「すべての障害の表示」の説明に従って障害を表示します。
次の例は、破損データ・ブロックが含まれている1つの障害を示しています。

RMAN> LIST FAILURE;

List of Database Failures
=========================

Failure ID Priority Status    Time Detected Summary
---------- -------- --------- ------------- -------
142        HIGH     OPEN      23-APR-07     One or more non-system datafiles
are missing
101        HIGH     OPEN      23-APR-07     Datafile 25: '/disk1/oradata/prod/example01.dbf' contains one or more corrupt blocks

2. 必要なオプションを使用してCHANGE FAILUREを実行します。
次の例では、ブロックの破損障害の優先順位をHIGHからLOWに変更します。

RMAN> CHANGE FAILURE 101 PRIORITY LOW;

List of Database Failures
=========================

Failure ID Priority Status    Time Detected Summary
---------- -------- --------- ------------- -------
101        HIGH     OPEN      23-APR-07     Datafile 25: '/disk1/oradata/prod/example01.dbf' contains one or more corrupt blocks

Do you really want to change the above failures (enter YES or NO)? YES
changed 1 failures to LOW priority

3. 必要に応じて、LIST FAILURE ALLを実行して変更内容を表示します。
ALLを指定せずにLIST FAILUREを実行すると、CRITICALまたはHIGHの優先順位の障害が存在しない場合にのみ、LOWの優先順位の障害が表示されます。

RMAN> LIST FAILURE ALL;

List of Database Failures
=========================

Failure ID Priority Status    Time Detected Summary
---------- -------- --------- ------------- -------
142        HIGH     OPEN      23-APR-07     One or more non-system datafiles
are missing
101        LOW      OPEN      23-APR-07     Datafile 25: '/disk1/oradata/prod/example01.dbf' contains one or more corrupt blocks

関連項目:
CHANGEコマンドの詳細は、『Oracle Databaseバックアップおよびリカバリ・リファレンス』を参照してください。

16 データベース・ファイルおよびバックアップの検証

この章では、データベース・ファイルおよびバックアップの整合性をチェックする方法について説明します。この章の内容は次のとおりです。

- RMANの検証の概要

- VALIDATEコマンドによるブロック破損の確認

- BACKUP VALIDATEを使用したデータベース・ファイルの検証

- リストアする前のバックアップの検証

RMANの検証の概要

この項では、RMANで検証を行う場合の基本的な概念およびタスクについて説明します。

RMANの検証の目的

RMANの検証は、ブロックが破損していないか、およびファイルが欠落していないかどうかを確認することを主な目的としています。また、RMANを使用して、バックアップがリストア可能かどうかを確認することもできます。RMANの次のコマンドを使用すると、検証を実行できます。

- VALIDATE

- BACKUP ... VALIDATE

- RESTORE ... VALIDATE

関連項目:

- VALIDATEの構文については、『Oracle Databaseバックアップおよびリカバリ・リファレンス』を参照してください。

- RESTORE ... VALIDATEの構文については、『Oracle Databaseバックアップおよびリカバリ・リファレンス』を参照してください。

RMANの検証の基本的な概念

バックアップ・ファイルが使用できなくなったり、リストアされたデータファイルが破損する可能性がある操作は防止されます。データベースは、自動的に次の処理を実行します。

- データファイルのリストアまたはリカバリ中、そのファイルへのアクセスをブロックします。

- 各データファイルのリストア操作を、一度に1つのみ許可します。

- 増分バックアップが適切な順序で適用されることを確認します。

- バックアップ・ファイルに情報を格納して、破損の検出を可能にします。

- 破損を検出するとすぐに通知できるように、ブロックが読取りまたは書込みされるたびにブロックを確認します。

チェックサムおよび破損ブロック

破損ブロックとは、変更が行われたため、Oracle Databaseでの検出時に予測される内容とは異なる内容になっているブロックのことです。ブロックの破損は、次に示す様々な障害によって発生する可能性があります。ただし、原因はこれらに限定されるわけではありません。

- ディスクおよびディスク・コントローラの障害

- メモリー障害

- Oracle Databaseソフトウェアの不具合

DB_BLOCK_CHECKSUMは、(バックアップ内ではなく)データベース内のデータファイルおよびオンラインREDOログ・ファイルのブロックに対するチェックサムの書込みを制御するデータベース初期化パラメータです。DB_BLOCK_CHECKSUMがtypicalに設定されている場合、データベースは、通常の操作中に各ブロックのチェックサムを計算し、ヘッダーにその値を格納してからブロックをディスクに書き込みます。データベースは、後でディスクからブロックを読み取る場合、チェックサムを再計算し、格納されている値と比較します。値が一致しなかった場合、そのブロックは破損しています。

デフォルトでは、BACKUPコマンドは、各ブロックのチェックサムを計算し、その値をバックアップに格納します。DB_BLOCK_CHECKSUMは、バックアップ内ではなくデータベース内のデータファイルに適用される初期化パラメータであるため、BACKUPコマンドではこの値は無視されます。

物理および論理ブロック破損

物理的な破損(メディア破損とも呼ばれます)の場合、ブロックがデータベースで認識されません。チェックサムが無効か、ブロック内容がすべて0(ゼロ)か、またはブロックのヘッダーとフッターが一致していません。

注意:
デフォルトでは、BACKUPコマンドは、各ブロックのチェックサムを計算し、その値をバックアップに格納します。NOCHECKSUMオプションを指定すると、バックアップの作成時にRMANはブロックのチェックサムを実行しません。

論理的な破損の場合、ブロックの内容は論理的に一貫性のない状態になっています。論理的破損の例として、行の一部や索引エントリの破損があげられます。RMANは、論理的な破損を検出すると、アラート・ログおよびサーバー・セッションのトレース・ファイルにそのブロックを記録します。

デフォルトでは、RMANは、論理的な破損を確認しません。ただし、BACKUPコマンドでCHECK LOGICALを指定すると、RMANは、データおよび索引ブロックをテストして、行ピースまたは索引エントリの破損などの論理的な破損がないかどうかを調べ、その結果を自動診断リポジトリ(ADR)内のアラート・ログに記録します。ファイルのバックアップ時またはリストア時に、RMANを次の構成で使用すると、RMANは、検出可能なすべてのタイプのブロック破損を検出します。

- データベースがデータファイルのチェックサムを(バックアップに対してではなく、データベースで使用中のデータファイルに対して)自動的に計算するように、データベースの初期化パラメータ・ファイルでDB_BLOCK_CHECKSUM=typicalを設定する。

- RMANがマーク解除されたブロック破損を許容しないように、BACKUPコマンドの前にSET MAXCORRUPTを使用しない。

- バックアップの書込み時にRMANがチェックサムを計算するように、BACKUPコマンドにNOCHECKSUMオプションを指定しない。

- RMANが物理的な破損と論理的な破損を確認するように、BACKUPコマンドおよびRESTOREコマンドにCHECK LOGICALオプションを指定する。

RMANバックアップの破損ブロックの制限

SET MAXCORRUPTコマンドを使用すると、RMANバックアップで1つのファイルに許容されるマーク解除された破損の合計数を設定できます。デフォルトは0(ゼロ)です。つまり、RMANはいずれの種類のマーク解除された破損ブロックも許容しません。

マーク解除された破損ブロックがバックアップ中に検出された際にMAXCORRUPTの制限を超えていると、RMANはバックアップを終了します。これ以外の場合、RMANは、ブロックが破損とマークされていることを示す特別なヘッダーを付けて、新しく検出された破損ブロックをバックアップに書き込みます。VALIDATEコマンドを使用すると、すでに破損とマークされているブロックを特定でき、また、以前にマーク解除された破損ブロックを検出できます。

RMANはバックアップで、以前にマークされた破損ブロックを許容します。また、以前にマーク解除された破損ブロックを、そのバックアップで破損とマークすることを許容するようにRMANに指示することができます(MAXCORRUPTを使用する場合)。そのため、破損とマークされた複数のブロックが含まれるデータファイルをリストアすることができます。(新たな破損が発生していないと想定して)リストアされたこのデータファイルをバックアップする場合、MAXCORRUPT設定がなくても、バックアップは正常に実行されます。これは、以前にマークされた破損は、RMANによるバックアップの完了を妨害しないためです。

関連項目:
SET MAXCORRUPTの構文については、『Oracle Databaseバックアップおよびリカバリ・リファレンス』を参照してください。

ブロック破損の検出

Oracle Databaseでは、ブロックの破損を検出、修復および監視する様々な方法がサポートされています。方法は、破損がブロック間の破損かブロック内の破損かによって異なります。ブロック内の破損は、ブロック自体内で発生します。この破損は、物理的な破損または論理的な破損のいずれかです。ブロック間の破損の場合、論理的な破損のみがブロック間で発生します。

たとえば、V$DATABASE_BLOCK_CORRUPTIONビューではブロック内の破損が記録され、自動診断リポジトリ(ADR)ではすべてのタイプの破損が追跡されます。表16-1に、データベースで様々なタイプのブロック破損を処理する方法を示します。

表16-1 ブロックの破損の検出、修復および監視

対策

ブロック内の破損

ブロック間の破損

検出

RMAN(BACKUPコマンドなど)、DBVERIFYユーティリティなどのすべてのデータベース・ユーティリティによって、ブロック内の破損が検出されます。データベース・プロセスでORA-1578エラーが発生すると、破損が検出され、監視されます。

DBVERIFYおよびANALYZE文でのみ、ブロック間の破損が検出されます。

追跡

V$DATABASE_BLOCK_CORRUPTIONビューに、RMANコマンド、ANALYZE、dbv、SQL問合せなどのOracle Databaseコンポーネントによって破損とマークされたブロックが表示されます。ブロック内の破損を検出したプロセスでは、このビューおよびADRにブロック破損が記録されます。

データベースは、ADRでこのタイプのブロック破損を監視します。

修復

修復方法には、ブロック・メディア・リカバリ、データファイルのリストア、増分バックアップによるリカバリおよびブロックの新規作成などがあります。ブロック・メディア・リカバリでは、物理的な破損は修復できますが、論理的な破損は修復できません。

修復を行うかブロックが修復されたことを検出するすべてのRMANコマンドによって、V$DATABASE_BLOCK_CORRUPTIONが更新されます。たとえば、RMANは、ブロック・メディア・リカバリが正常に実行された後にリポジトリを更新します。BACKUP、RESTOREまたはVALIDATEコマンドによって、ブロックの破損がなくなったことが検出された場合、修正済のブロックがビューから削除されます。

ブロック間の破損は、オブジェクトの削除、索引の再構築などの手動による方法で修正する必要があります。

関連項目:

- 第17章「データベースの完全リカバリの実行」

- 第19章「ブロック・メディア・リカバリの実行」

- ADRについては、『Oracle Database管理者ガイド』を参照してください。

VALIDATEコマンドによるブロック破損の確認

VALIDATEコマンドを使用すると、データベース・ファイル内の物理的および論理的な破損を手動で確認できます。このコマンドでは、BACKUP VALIDATEと同じタイプのチェックが実行されますが、VALIDATEでは、より広範囲のオブジェクトをチェックできます。たとえば、VALIDATE DATAFILE ... BLOCKコマンドを使用すると、個々のブロックを検証できます。

すべてのファイルを検証する場合、RMANによって、入力ファイルのすべてのブロックが確認されます。バックアップの検証によって、以前にマーク解除された破損ブロックが検出された後、RMANは破損を示している行を反映してV$DATABASE_BLOCK_CORRUPTIONビューを更新します。

バックアップ・セット内の1つ以上のバックアップ・ピースが欠落または破損している可能性がある場合は、VALIDATE BACKUPSETを使用します。このコマンドでは、バックアップ・セット内のすべてのブロックがチェックされ、バックアップがリストア可能かどうかが確認されます。ブロックの破損が検出されると、エラーが発行されて検証が停止されます。VALIDATE BACKUPSETコマンドでは、ユーザーがチェック対象のバックアップを選択できます。これに対して、RESTOREコマンドのVALIDATEオプションでは、RMANによって選択が行われます。

VALIDATEを使用してデータベース・ファイルおよびバックアップを確認する手順

1. RMANを起動し、ターゲット・データベースに接続します。

2. 必要なオプションを指定してVALIDATEコマンドを実行します。
たとえば、データファイル、制御ファイルおよび(使用されている場合は)サーバー・パラメータ・ファイルをすべて検証するには、次のコマンドをRMANのプロンプトで実行します。

RMAN> VALIDATE DATABASE;

また、次の例に示すコマンド形式を使用すると、特定のバックアップ・セットを検証することもできます(出力例も示します)。

RMAN> VALIDATE BACKUPSET 22;

Starting validate at 17-AUG-06
using channel ORA_DISK_1
allocated channel: ORA_SBT_TAPE_1
channel ORA_SBT_TAPE_1: SID=89 device type=SBT_TAPE
channel ORA_SBT_TAPE_1: Oracle Secure Backup
channel ORA_DISK_1: starting validation of datafile backup set
channel ORA_DISK_1: reading from backup piece /disk1/oracle/work/orcva/RDBMS/backupset/2007_08_16/o1_mf_nnndf_TAG20070816T153034_2g774bt2_.bkp
channel ORA_DISK_1: piece handle=/disk1/oracle/work/orcva/RDBMS/backupset/2007_08_16/o1_mf_nnndf_TAG20070816T153034_2g774bt2_.bkp tag=TAG20070816T153034
channel ORA_DISK_1: restored backup piece 1
channel ORA_DISK_1: validation complete, elapsed time: 00:00:01
Finished validate at 17-AUG-06

次の例に、データファイル内の個々のデータ・ブロックを調べて破損を確認する方法を示します。

RMAN> VALIDATE DATAFILE 1 BLOCK 10;

Starting validate at 17-AUG-06
using channel ORA_DISK_1
channel ORA_DISK_1: starting validation of datafile
channel ORA_DISK_1: specifying datafile(s) for validation
input datafile file number=00001 name=/disk1/oracle/dbs/tbs_01.f
channel ORA_DISK_1: validation complete, elapsed time: 00:00:01
List of Datafiles
=================
File Status Marked Corrupt Empty Blocks Blocks Examined High SCN
---- ------ -------------- ------------ --------------- ----------
1    OK     0              2            127             481907
File Name: /disk1/oracle/dbs/tbs_01.f
Block Type Blocks Failing Blocks Processed
---------- -------------- ----------------
Data       0              36
Index      0              31
Other      0              58

Finished validate at 17-AUG-06

データファイルの検証のパラレル化

大規模なデータファイルを検証する必要がある場合、RMANは、そのファイルを複数のセクションに分割し、各ファイル・セクションをパラレルに処理することによって、作業をパラレル化できます。複数のチャネルが構成されているか、または割り当てられている場合にチャネルで検証をパラレル化するには、VALIDATEコマンドのSECTION SIZEパラメータを指定します。

ファイルのサイズより大きいセクション・サイズを指定した場合、RMANはファイル・セクションを作成しません。小さなセクション・サイズを指定した結果、セクションの数が256を超えると、RMANは、正確に256になる値までセクション・サイズを増やします。

データファイルの検証をパラレル化する手順

1. RMANを起動し、ターゲット・データベースに接続します。ターゲット・データベースは、マウントまたはオープンされている必要があります。

2. SECTION SIZEパラメータを指定してVALIDATEを実行します。
次の例では、2つのチャネルを割り当て、大規模なデータファイルを検証します。セクション・サイズは1200MBです。

RUN
{
ALLOCATE CHANNEL c1 DEVICE TYPE DISK;
ALLOCATE CHANNEL c2 DEVICE TYPE DISK;
VALIDATE DATAFILE 1 SECTION SIZE 1200M;
}

関連項目:

- 「セクションへの大規模なデータファイルのバックアップの分割」

- VALIDATEコマンドの詳細は、『Oracle Databaseバックアップおよびリカバリ・リファレンス』を参照してください。

BACKUP VALIDATEを使用したデータベース・ファイルの検証

BACKUP VALIDATEコマンドを使用すると、次の操作を実行できます。

- データファイルのブロックの物理的および論理的な破損の確認

- すべてのデータベース・ファイルが存在するかどうか、および格納場所が正しいかどうかの確認

BACKUP VALIDATEを実行すると、RMANは、実際のバックアップ時と同様に、バックアップするファイル全体を読み取ります。ただし、実際には、バックアップ・セットもイメージ・コピーも作成しません。

BACKUPSETパラメータ、MAXCORRUPTパラメータまたはPROXYパラメータは、BACKUP VALIDATEを指定して使用することはできません。特定のバックアップ・セットを検証するには、VALIDATEコマンドを実行します。

BACKUP VALIDATEコマンドを使用してファイルを検証する手順

1. RMANを起動し、ターゲット・データベースおよびリカバリ・カタログ(使用している場合)に接続します。

2. BACKUP VALIDATEコマンドを実行します。
たとえば、次の例のようにコマンドを実行すると、すべてのデータベース・ファイルおよびアーカイブ・ログがバックアップ可能かどうかを検証できます。このコマンドは物理的な破損のみ確認します。

BACKUP VALIDATE
DATABASE
ARCHIVELOG ALL;

物理的な破損に加えて論理的な破損も確認するには、前述のコマンドを次のように少し変更して実行します。

BACKUP VALIDATE
CHECK LOGICAL
DATABASE
ARCHIVELOG ALL;

前述の例では、RMANクライアントは、実際にファイルをバックアップしたときと同じ出力を表示します。RMANは、ファイルを1つもバックアップできない場合、エラー・メッセージを発行します。たとえば、次のように表示されます。

RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of backup command at 08/29/2007 14:33:47
ORA-19625: error identifying file /oracle/oradata/trgt/arch/archive1_6.dbf
ORA-27037: unable to obtain file status
SVR4 Error: 2: No such file or directory
Additional information: 3

関連項目:

- BACKUPの構文については、『Oracle Databaseバックアップおよびリカバリ・リファレンス』を参照してください。

- BACKUP VALIDATEで検出される破損ブロックを修復する方法については、第19章「ブロック・メディア・リカバリの実行」を参照してください。

リストアする前のバックアップの検証

RESTORE ... VALIDATEを実行すると、RMANで特定のファイルまたはファイル・セットをバックアップからリストアできるかどうかがテストされます。RMANによって、使用するバックアップが選択されます。

このコマンドでは、データベースがマウントまたはオープンされている必要があります。データファイルのリストアの検証時にデータファイルをオフラインにする必要はありません。データファイルのバックアップの検証は、バックアップを読み取るのみで、本番データファイルには影響しないためです。

ディスクまたはテープのファイルを検証する場合、RMANは、バックアップ・ピースまたはイメージ・コピー内のすべてのブロックを読み取ります。また、RMANは、オフサイトのバックアップの検証も行います。この検証は、RMANによって出力ファイルが書き込まれないことを除き、実際のリストア操作と同じです。

注意:
RECOVER ... TESTコマンドを使用して、試行リカバリを実行するテスト方法もあります。試行リカバリでは、通常のリカバリと同じ方法でREDOが適用されますが、これはメモリー内のみで行われ、変更は試行後にロールバックされます。

RESTOREコマンドを使用してバックアップを検証する手順

1. VALIDATEオプションを指定してRESTOREコマンドを実行します。
次に、データベースおよびすべてのアーカイブREDOログのリストアの検証例を示します。

RESTORE DATABASE VALIDATE;
RESTORE ARCHIVELOG ALL VALIDATE;

RMANのエラー・スタックが表示されない場合は、後続の手順をスキップします。エラー・メッセージが表示されないということは、実際のリストアおよびリカバリ中にこれらのバックアップを正常に使用できることがRMANで確認されたということを意味しています。

2. 出力内にエラー・メッセージおよびRMAN-06026メッセージが表示された場合は、問題の原因を調査します。可能な場合は、RMANによるバックアップの検証を妨げている問題を解決し、検証を再試行します。
次のエラーは、RMANが、指定した1つ以上のファイルを使用可能なバックアップからリストアできないことを意味します。

RMAN-06026: some targets not found - aborting restore

次の出力例は、指定したバックアップの読取りでRMANが問題を検出したことを示しています。

RMAN-03009: failure of restore command on c1 channel at 12-DEC-06 23:22:30
ORA-19505: failed to identify file "oracle/dbs/1fafv9gl_1_1"
ORA-27037: unable to obtain file status
SVR4 Error: 2: No such file or directory
Additional information: 3

関連項目:
RESTORE ... VALIDATEコマンドの詳細は、『Oracle Databaseバックアップおよびリカバリ・リファレンス』を参照してください。

17 データベースの完全リカバリの実行

この章では、1つ以上のデータファイルが消失した後、RMANを使用してデータベースを通常の稼働状態に戻す方法について説明します。この章の内容は次のとおりです。

- データベースの完全リカバリの概要

- データベースの完全リカバリの準備

- データベースの完全リカバリの実行

データベースの完全リカバリの概要

この項では、データベースの完全リストアおよびリカバリの目的およびこの章の概要について説明します。

データベースの完全リカバリの目的

この章では、データファイルの一部またはすべてが消失または破損したと想定しています。通常、この状況は、メディア障害または誤った削除によって発生します。破損したファイルをRMANバックアップからリストアし、すべてのデータベース変更をリカバリすることによって、データベースを通常の稼働状態に戻す必要があります。

この章の概要

この章では、完全リカバリを使用して最も一般的なデータベースの問題を解決する方法について説明します。この章では、次のことを想定しています。

- 一部またはすべてが消失したデータファイルがあり、すべての変更をリカバリすることが目標です。ただし、現行のすべての制御ファイルまたはオンラインREDOログ・グループ全体は消失していません。
すべてのデータベースの変更ではなく、一部の変更をリカバリする方法については、第18章「フラッシュバックおよびデータベースのPoint-in-Timeリカバリの実行」を参照してください。第30章「ユーザー管理のリカバリの実行: 高度な例」では、現行のすべての制御ファイルではなく一部の制御ファイルを消失したとき、またはオンラインREDOログ・グループのメンバーを消失したときに対応する方法について説明します。「バックアップ制御ファイルを使用したリカバリの実行」では、すべての制御ファイルを消失したときにデータベースをリカバリする方法について説明します。

- データベースでは、現行のサーバー・パラメータ・ファイルが使用されています。
バックアップ・サーバー・パラメータ・ファイルをリストアするには、「サーバー・パラメータ・ファイルのリストア」を参照してください。

- データファイルのバックアップのリカバリに必要なすべてのアーカイブREDOログおよび増分バックアップが存在します。すべてのデータファイルには、バックアップ、またはバックアップなしでデータファイルを作成した時点からのすべてのオンラインおよびアーカイブREDOログが存在します。
RMANは、リストアおよびリカバリ時に、消失したデータファイルを処理できます。ユーザーが手動で操作を行う必要はありません。データファイルが消失している場合、次のような状況が考えられます。

- 制御ファイルにデータファイルのレコードが含まれている(データファイルの作成後に制御ファイルをバックアップしているが、データファイル自体はバックアップしていない)。データファイルのレコードが制御ファイルに含まれている場合、RESTOREを実行すると、元の場所またはユーザーが指定する場所にデータファイルが作成されます。その後、RECOVERコマンドを実行すると、必要なログをデータファイルに適用できます。

- 制御ファイルにデータファイルのレコードが含まれていない(データファイルの作成後に制御ファイルをバックアップしていない)。 リカバリ時に、データベースは、欠落しているデータファイルを検出してRMANに報告し、RMANは、新しいデータファイルを作成し、残りのログを適用してリカバリを続行します。データファイルが親インカネーション内に作成されている場合は、必要に応じて、リストアまたはリカバリ・フェーズ中にデータファイルが作成されます。

- 暗号化された表領域は、リストアおよびリカバリしません。
暗号化された表領域でメディア・リカバリを実行する場合は、この表領域のメディア・リカバリの実行時に、Oracleウォレットをオープンする必要があります。暗号化された表領域については、『Oracle Database管理者ガイド』を参照してください。

- データベースは、シングル・インスタンス構成で実行されています。
RMANは、Oracle RACおよびData Guard構成でデータベースをリストアおよびリカバリできますが、このマニュアルではこれらの例については説明しません。

- Oracle Enterprise ManagerではなくRMANクライアントを使用しています。
Enterprise Managerでは、一連のウィザードによってRMANにアクセスできます。これらのウィザードは、データベース、使用可能なバックアップおよびデータ・リカバリの目的の分析に基づいて、様々なリカバリ手順を提供します。

Enterprise Managerを使用することによって、この章で説明する簡単なリストアおよびリカバリの例を実行できます。また、Point-in-Timeリカバリやデータベースのフラッシュバックなどのより高度なリストアおよびリカバリ方法を使用して、メディア障害およびユーザー・エラーを効率的に修復することもできます。通常、Enterprise ManagerのほうがRMANコマンドライン・クライアントを直接使用するより簡単です。

関連項目:

- Oracle RACでのRMANの使用の詳細は、『Oracle Real Application Clusters管理およびデプロイメント・ガイド』を参照してください。

- Data GuardでのRMANの使用の詳細は、『Oracle Data Guard概要および管理』を参照してください。

- Enterprise Managerのリストアおよびリカバリ機能の詳細は、『Oracle Database 2日でデータベース管理者』を参照してください。

データベースの完全リカバリの準備

RMANによってデータベースのほとんどのリストアおよびリカバリ・タスクは簡単になりますが、データベースのリストアおよびリカバリ計画は、消失したデータベース・ファイルおよびリカバリの目標に基づいて作成する必要があります。この項の内容は、次のとおりです。

- リストアまたはリカバリするデータファイルの識別

- データベースのDBIDの確認

- リストア操作で使用されるバックアップのプレビュー

- リストアする前のバックアップの検証

- リカバリに必要なアーカイブREDOログのリストア

リストアまたはリカバリするデータファイルの識別

リストアまたはリカバリが必要なファイルを判別する方法は、消失したファイルのタイプによって異なります。

消失した制御ファイルの識別

通常、データベースの制御ファイルが消失した日時は明らかです。多重制御ファイルのいずれかがアクセス不可能になると、データベースは即時に停止します。また、CONTROL_FILES初期化パラメータに指定された有効な制御ファイルがそれぞれの場所に存在しない状態でデータベースを起動しようとした場合も、データベースによってエラーがレポートされます。

制御ファイルのコピーのすべてではなく一部が消失した場合は、バックアップから制御ファイルをリストアする必要はありません。影響を受けていない制御ファイルが1つ以上存在する場合は、影響を受けていない制御ファイルを破損または消失した制御ファイルにコピーするか、または破損または消失した制御ファイルを参照しないように初期化パラメータ・ファイルを更新することができます。存在し、影響を受けていない制御ファイルのコピーのみをCONTROL_FILESパラメータが参照するようにした後で、データベースを再起動できます。

制御ファイルをバックアップからリストアする場合は、データファイルをリストアする必要がない場合でも、データベース全体のメディア・リカバリを実行してから、OPEN RESETLOGSオプションを使用してデータベースをオープンする必要があります。この方法については、「バックアップ制御ファイルを使用したリカバリの実行」を参照してください。

メディア・リカバリが必要なデータファイルの識別

リカバリを実行するタイミングと方法は、データベースの状態とデータファイルの場所によって異なります。

RMANを使用したデータファイルの識別

欠落しているデータファイルを判別する簡単な方法は、指定したすべてのデータファイルの読取りを試行するVALIDATE DATABASEコマンドを実行することです。たとえば、RMANクライアントを起動し、次のコマンドを実行してデータベースを検証します(出力例も示します)。

例17-1 BACKUP VALIDATE DATABASE

RMAN> VALIDATE DATABASE;

Starting validate at 20-OCT-06
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=90 device type=DISK
could not read file header for datafile 7 error reason 4
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of backup command at 10/20/2007 13:05:43
RMAN-06056: could not access datafile 7

例17-1の出力は、データファイル7がアクセス不可能であることを示しています。この場合は、REPORT SCHEMAコマンドを次のように実行して、データファイル7の表領域名およびファイル名を取得できます(出力例も示します)。

RMAN> REPORT SCHEMA;

Report of database schema for database with db_unique_name RDBMS

List of Permanent Datafiles
===========================
File Size(MB) Tablespace           RB segs Datafile Name
---- -------- -------------------- ------- ------------------------
1    450      SYSTEM               ***     +DATAFILE/tbs_01.f
2    86       SYSAUX               ***     +DATAFILE/tbs_ax1.f
3    15       UD1                  ***     +DATAFILE/tbs_undo1.f
4    2        SYSTEM               ***     +DATAFILE/tbs_02.f
5    2        TBS_1                ***     +DATAFILE/tbs_11.f
6    2        TBS_1                ***     +DATAFILE/tbs_12.f
7    2        TBS_2                ***     +DATAFILE/tbs_21.f

List of Temporary Files
=======================
File Size(MB) Tablespace           Maxsize(MB) Tempfile Name
---- -------- -------------------- ----------- --------------------
1    40       TEMP                 32767       +DATAFILE/tbs_tmp1.f

SQLを使用したデータファイルの識別

VALIDATE DATABASEはファイルがアクセス不可能かどうかを確認する場合の最適な方法ですが、SQL問合せを使用してより詳細な情報を取得する必要がある場合があります。

データファイルにメディア・リカバリが必要かどうかを確認する手順

1. SQL*Plusを起動し、管理者権限でターゲット・データベース・インスタンスに接続します。

2. 次のSQL問合せを実行して、データベースのステータスを確認します。

SELECT STATUS FROM V$INSTANCE;

状態がOPENの場合、データベースはオープン状態です。ただし、一部のデータファイルにメディア・リカバリが必要な場合があります。

3. V$DATAFILE_HEADERを問い合せて、データファイルのステータスを確認します。次のSQL文を実行して、データファイルのヘッダーを確認します。

SELECT FILE#, STATUS, ERROR, RECOVER, TABLESPACE_NAME, NAME
FROM   V$DATAFILE_HEADER
WHERE  RECOVER = 'YES'
OR     (RECOVER IS NULL AND ERROR IS NOT NULL);

戻される各行は、メディア・リカバリが必要なデータファイルまたはリストアが必要なエラー発生しているデータファイルを表します。RECOVERおよびERROR列を確認します。RECOVERには、ファイルにメディア・リカバリが必要かどうかが示され、ERRORには、データファイルのヘッダーの読取り時および検証時にエラーが発生したかどうかが示されます。

ERRORがNULLでない場合は、データファイルのヘッダーの読取りおよび検証は実行できません。エラーの原因となるハードウェアまたはオペレーティング・システムの一時的な問題がないかどうかを確認します。問題がない場合は、ファイルをリストアしてコピーに切り替える必要があります。

ERROR列がNULLで、RECOVER列がYESの場合、ファイルにはメディア・リカバリが必要です(バックアップからリストアする必要がある場合もあります)。

注意:
V$DATAFILE_HEADERは各データファイルのヘッダー・ブロックのみを読み取るため、データファイルのリストアが必要となるすべての問題を検出するわけではありません。たとえば、このビューではデータファイルに破損したデータ・ブロックが含まれているかどうかは確認できません。

4. 必要に応じて、V$RECOVER_FILEを問い合せて、リカバリが必要なデータファイルをそのステータス情報およびエラー情報とともにデータファイル番号で表示します。たとえば、次の問合せを実行します。

SELECT FILE#, ERROR, ONLINE_STATUS, CHANGE#, TIME
FROM   V$RECOVER_FILE;

注意:
V$RECOVER_FILEは、バックアップからリストアされた制御ファイル、またはデータファイルに影響を及ぼすメディア障害の発生後に再作成された制御ファイルには使用できません。リストアされた制御ファイルまたは再作成された制御ファイルには、V$RECOVER_FILEを正確に更新するために必要な情報が含まれていません。

データファイルおよび表領域の名前を取得するために、データファイル番号、V$DATAFILEおよびV$TABLESPACEビューを使用して、有効な結合を実行することもできます。次に例を示します。

SELECT r.FILE# AS df#, d.NAME AS df_name, t.NAME AS tbsp_name,
d.STATUS, r.ERROR, r.CHANGE#, r.TIME
FROM V$RECOVER_FILE r, V$DATAFILE d, V$TABLESPACE t
WHERE t.TS# = d.TS#
AND d.FILE# = r.FILE#;

ERROR列で、リカバリが必要な各ファイルに関する問題を識別します。

関連項目:
V$ビューの詳細は、『Oracle Databaseリファレンス』を参照してください。

データベースのDBIDの確認

自動バックアップからのサーバー・パラメータ・ファイルまたは制御ファイルのリカバリが必要な状況では、DBIDがわかっている必要があります。DBIDは、データベースに関する他の基本情報とともに記録する必要があります。

データベースのDBIDの記録がない場合は、データベースをオープンせずに次の場所で参照することができます。

- DBIDは、制御ファイルの自動バックアップのファイル名の一部に使用されています。制御ファイルを検索した後、「制御ファイルの自動バックアップ書式の構成」を参照して、ファイル名のどこにDBIDが表示されるかを確認します。

- RMANセッションからの出力を保持するテキスト・ファイルがある場合、DBIDは、RMANクライアントが起動してデータベースに接続する際に表示されます。通常の出力を次に示します。

% rman TARGET /

Recovery Manager: Release 11.1.0.6.0 - Production on Wed Jul 11 17:51:30 2007

Copyright (c) 1982, 2007, Oracle.  All rights reserved.

connected to target database: PROD (DBID=36508508)

リストア操作で使用されるバックアップのプレビュー

RESTORE ... PREVIEWを任意のRESTORE操作に適用すると、要求されたRESTORE操作で使用されるすべてのバックアップ、およびRESTORE操作完了後のリカバリに必要な目的のSCNの詳細なリストを作成できます。このコマンドは、RMANリポジトリにアクセスしてバックアップ・メタデータを問い合せますが、実際にバックアップ・ファイルを読み取ってリストア可能であることは確認しません。

RESTORE ... PREVIEWの代替として、RESTORE ... VALIDATE HEADERコマンドを使用できます。RESTORE ... VALIDATE HEADERコマンドは、リストアおよびリカバリに必要なファイルを一覧表示する以外に、バックアップ・ファイル・ヘッダーを検証して、ディスク上またはメディア管理カタログ内のファイルが、RMANリポジトリのメタデータに対応しているかどうかを確認します。

リストアおよびリカバリ操作を計画する場合は、RESTORE ... PREVIEWまたはRESTORE ... VALIDATE HEADERを使用して、必要なすべてのバックアップが使用可能であることを確認するか、または特定のバックアップの使用または回避をRMANに指示する必要がある状況を識別します。

リストア操作で使用されるバックアップをプレビューする手順

1. PREVIEWオプションを指定してRESTOREコマンドを実行します。
たとえば、次のいずれかのコマンドを実行します。

RESTORE DATABASE PREVIEW;
RESTORE ARCHIVELOG FROM TIME 'SYSDATE-7' PREVIEW;

RESTORE ... PREVIEWによって生成されるレポートの情報が多すぎる場合は、次の例に示すようにSUMMARYオプションを指定します。

RESTORE DATABASE PREVIEW SUMMARY;

出力が適切である場合は、ここで停止します。一時的に使用できないことがわかっているテープからのバックアップをRMANが要求することが出力に示された場合は、この手順を続行します。バックアップがオフサイトに格納されていることが出力に示された場合は、「オフサイト・バックアップのリコール」に進みます。

2. 必要に応じて、CHANGEコマンドを使用して、一時的に使用できないバックアップのバックアップ・ステータスをUNAVAILABLEに設定します。
このタスクの実行方法については、「AVAILABLEまたはUNAVAILABLEへのバックアップのステータスの更新」を参照してください。

3. 必要に応じて、RESTORE ... PREVIEWを再度実行して、使用できないバックアップがリストアで使用されないことを確認します。

関連項目:
RESTORE ... PREVIEWの出力(LISTコマンドの出力と同じ書式)の解釈の詳細は、『Oracle Databaseバックアップおよびリカバリ・リファレンス』を参照してください。

オフサイト・バックアップのリコール

一部のメディア・マネージャは、オフサイトにあるバックアップに関するステータス情報をRMANに提供します。オフサイト・バックアップは、安全なストレージ設備などのリモートの場所に格納され、メディア・マネージャがメディアを取り込まないかぎりリストアできません。

バックアップをリストアする前にストレージからメディアを取り込む必要がある場合でも、オフサイト・バックアップは、RMANリポジトリでAVAILABLEとマークが付けられます。RMANがオフサイト・バックアップのリストアを試みると、リストア・ジョブに失敗します。

RESTORE ... PREVIEWを使用すると、オフサイト・バックアップを確認できます。例17-2のサンプル出力の最後にあるテキストに示すように、コマンドの出力には、バックアップがオフサイトに格納されたかどうかが示されます。

例17-2 RESTORE ... PREVIEWの出力

List of Backup Sets
===================

BS Key  Size       Device Type Elapsed Time Completion Time
------- ---------- ----------- ------------ ---------------
9       2.25M      SBT_TAPE    00:00:00     21-MAY-07
BP Key: 9   Status: AVAILABLE  Compressed: NO  Tag: TAG20070521T144258
Handle: 0aii9k7i_1_1   Media: 0aii9k7i_1_1

List of Archived Logs in backup set 9
Thrd Seq     Low SCN    Low Time  Next SCN   Next Time
---- ------- ---------- --------- ---------- ---------
1    1       392314     21-MAY-07 392541     21-MAY-07
1    2       392541     21-MAY-07 392545     21-MAY-07
1    3       392545     21-MAY-07 392548     21-MAY-07
1    4       392548     21-MAY-07 395066     21-MAY-07
1    5       395066     21-MAY-07 395095     21-MAY-07
1    6       395095     21-MAY-07 395355     21-MAY-07

List of remote backup files
============================
Handle: aii9k7i_1_1   Media: 0aii9k7i_1_1
validation succeeded for backup piece
Finished restore at 21-MAY-07
released channel: dev1

RESTORE ... PREVIEW RECALLを使用すると、オフサイト・バックアップを使用可能にするようにメディア・マネージャに指示できます。

オフサイト・バックアップをリコールする手順

1. バックアップがオフサイトに格納されている場合、RECALLオプションを指定してRESTORE ... PREVIEWコマンドを実行します。
次の例では、例17-2に示されているオフサイト・アーカイブ・ログのバックアップのリコールを開始します(出力例も示します)。

RESTORE ARCHIVELOG ALL PREVIEW RECALL;

次のサンプル出力は、RMANがリコールを開始したことを示しています。

List of Backup Sets
===================

BS Key  Size       Device Type Elapsed Time Completion Time
------- ---------- ----------- ------------ ---------------
9       2.25M      SBT_TAPE    00:00:00     21-MAY-07
BP Key: 9   Status: AVAILABLE  Compressed: NO  Tag: TAG20070521T144258
Handle: VAULT0aii9k7i_1_1   Media: /tmp,VAULT0aii9k7i_1_1

List of Archived Logs in backup set 9
Thrd Seq     Low SCN    Low Time  Next SCN   Next Time
---- ------- ---------- --------- ---------- ---------
1    1       392314     21-MAY-07 392541     21-MAY-07
1    2       392541     21-MAY-07 392545     21-MAY-07
1    3       392545     21-MAY-07 392548     21-MAY-07
1    4       392548     21-MAY-07 395066     21-MAY-07
1    5       395066     21-MAY-07 395095     21-MAY-07
1    6       395095     21-MAY-07 395355     21-MAY-07

Initiated recall for the following list of remote backup files
==========================================================
Handle: VAULT0aii9k7i_1_1   Media: /tmp,VAULT0aii9k7i_1_1
validation succeeded for backup piece
Finished restore at 21-MAY-07
released channel: dev1

2. RESTORE ... PREVIEWコマンドを実行します。必要に応じて、リストアに必要なバックアップがオフサイトとしてレポートされなくなるまで、前の手順に戻ります。

リストアする前のバックアップの検証

「リストア操作で使用されるバックアップのプレビュー」の手順では、リストアされるバックアップは示されますが、それらのバックアップが実際に使用可能であることは検証されません。RMANコマンドを実行して、RESTORE操作で使用可能なバックアップの可用性またはRESTORE操作で使用される特定のバックアップの内容をテストできます。バックアップの内容が実際に読み取られ、破損が確認されます。次の検証オプションがあります。

- RESTORE ... VALIDATEを実行すると、RMANで特定のオブジェクトをバックアップからリストアできるかどうかがテストされます。RMANによって、使用するバックアップが選択されます。

- VALIDATE BACKUPSETは、指定するバックアップ・セットの妥当性をテストします。

関連項目:
第16章「データベース・ファイルおよびバックアップの検証」

リカバリに必要なアーカイブREDOログのリストア

RMANは、リカバリを実行するために、必要に応じてアーカイブREDOログ・ファイルをバックアップから自動的にリストアします。また、後でRECOVERコマンド中にこれらのファイルのリストアに必要となる時間を節約するために、またはリストアされたアーカイブREDOログ・ファイルを新しい場所に格納する場合に、アーカイブREDOログを手動でリストアすることもできます。RMANでは、すべてのアーカイブREDOログ・ファイル、現行のREDOログ・ファイルまたは指定されたデータベースの以前のインカネーションからのアーカイブREDOログ・ファイルをリストアすることができます。

デフォルトでは、RMANは、ターゲット・データベースのLOG_ARCHIVE_FORMATおよび最大のLOG_ARCHIVE_DEST_nパラメータを使用して構成された名前でアーカイブREDOログをリストアします。これらのパラメータがプラットフォーム固有の形式で組み合され、リストアされたアーカイブ・ログの名前が構成されます。

新しい場所へのアーカイブREDOログのリストア

SET ARCHIVELOG DESTINATIONコマンドを使用すると、リストアしたアーカイブREDOログのデフォルトの名前を上書きできます。このコマンドによって、アーカイブ・ログは、データベースのリストア中に別の場所に手動でステージングされます。リカバリ中、RMANは新しくリストアされたアーカイブ・ログを検索する場所を認識するため、初期化パラメータ・ファイルで指定された場所にアーカイブ・ログが存在している必要はありません。

アーカイブREDOログを新しい場所へリストアする手順

1. RMANを起動し、ターゲット・データベースに接続します。

2. データベースがマウントまたはオープンされていることを確認します。

3. RUNコマンド内で、次の操作を実行します。

1. SET ARCHIVELOG DESTINATIONを使用して、リストアするアーカイブREDOログの新しい場所を指定します。

2. アーカイブREDOログを明示的にリストアするか、またはログを自動的にリストアするコマンドを実行します。

次の例のRUNコマンドは、すべてのバックアップ・アーカイブ・ログを新しい場所に明示的にリストアします。

RUN
{
SET ARCHIVELOG DESTINATION TO '/oracle/temp_restore';
RESTORE ARCHIVELOG ALL;
# restore and recover datafiles as needed
.
.
.
}

次の例では、アーカイブ・ログの宛先を設定し、RECOVER DATABASEを使用してアーカイブ・ログをこの宛先から自動的にリストアします。

RUN
{
SET ARCHIVELOG DESTINATION TO '/oracle/temp_restore';
RESTORE DATABASE;
RECOVER DATABASE; # restores and recovers logs automatically
}

複数の場所へのアーカイブREDOログのリストア

アーカイブ・ログのリストア先を1つのRUNブロックに複数回指定して、リストアしたログを複数のリストア先に分散できます。(ただし、同時に複数のリストア先を指定して、リストア操作時に同じログの複数のコピーを生成することはできません。)この機能を使用して、リストアしたログを格納するために使用するディスク領域を管理できます。

次の例では、バックアップから300のアーカイブREDOログをリストアし、ディレクトリ/fs1/tmp、/fs2/tmpおよび/fs3/tmpに分散します。

RUN
{
# Set a new location for logs 1 through 100.
SET ARCHIVELOG DESTINATION TO '/fs1/tmp';
RESTORE ARCHIVELOG FROM SEQUENCE 1 UNTIL SEQUENCE 100;
# Set a new location for logs 101 through 200.
SET ARCHIVELOG DESTINATION TO '/fs2/tmp';
RESTORE ARCHIVELOG FROM SEQUENCE 101 UNTIL SEQUENCE 200;
# Set a new location for logs 201 through 300.
SET ARCHIVELOG DESTINATION TO '/fs3/tmp';
RESTORE ARCHIVELOG FROM SEQUENCE 201 UNTIL SEQUENCE 300;
# restore and recover datafiles as needed
.
.
.
}

RECOVERコマンドを発行すると、リストアした必要なアーカイブ・ログがリストア先で自動的に検出され、データファイルに適用されます。

データベースの完全リカバリの実行

この項では、「データベースの完全リカバリの準備」のタスクをすでに実行していると想定しています。この項では、広範囲の様々な例に対応することを目的としているデータベースの完全リカバリの概要について説明します。

データベースの完全リカバリ

データベースをリストアおよびリカバリするには、RESTOREおよびRECOVERコマンドを使用します。リカバリ中、RMANは、必要なアーカイブREDOログのバックアップを自動的にリストアします。バックアップがメディア・マネージャに格納されている場合は、チャネルを事前に構成しておくか、またはALLOCATE CHANNELコマンドを含むRUNブロックを使用して、そこに格納されているバックアップへのアクセスを有効にする必要があります。

RMANは、リカバリ中にアーカイブREDOログを高速リカバリ領域にリストアする場合、リストアしたログを、データファイルに適用した後で自動的に削除します。そうでない場合は、リストアしたアーカイブREDOログがリカバリに必要でなくなった後、DELETE ARCHIVELOGコマンドを使用して、それらのアーカイブREDOログをディスクから削除できます。たとえば、次のコマンドを入力できます。

RECOVER DATABASE DELETE ARCHIVELOG;

デフォルト以外の場所へのデータファイルのリストア

データファイルをデフォルトの場所にリストアできない場合は、データファイルの新しい場所が反映されるように、制御ファイルを更新する必要があります。RMANのSET NEWNAMEコマンドをRUNコマンド内で使用して、新しいファイル名を指定します。その後、SQL文ALTER DATABASE RENAME FILEと同じ動作をするSWITCHコマンドを使用し、制御ファイル内のデータファイルの名前を更新します。SWITCH DATAFILE ALLを実行すると、制御ファイルに、RUNコマンドでSET NEWNAMEが発行されているすべてのデータファイルの新しい名前が反映されます。

関連項目:
SWITCHの構文については、『Oracle Databaseバックアップおよびリカバリ・リファレンス』を参照してください。

バックアップの復号化

RMANは、暗号化バックアップをリストアする場合、バックアップ・セットの内容をリストアする際にバックアップ・セットを自動的に復号化します。透過的に暗号化されたバックアップは、Oracleウォレットがオープンしていて使用可能な場合にかぎり、ユーザーが介入せずにリストアできます。

パスワード暗号化バックアップをリストアするには、正しいパスワードを入力する必要があります。SET DECRYPTIONコマンドを使用して、暗号化パスワードを入力する必要があります。異なるパスワードを使用して作成されたバックアップのグループからリストアを行う場合は、SET DECRYPTIONコマンドで、必要なすべてのパスワードを指定する必要があります。各バックアップ・セットで正しいパスワードが自動的に使用されます。

関連項目:

- バックアップの透過的暗号化を構成する方法の詳細は、「バックアップの暗号化の構成」を参照してください。

- 暗号化バックアップを作成する方法については、「RMANバックアップの暗号化」を参照してください。

データベース全体の完全リカバリの実行

この例では、データベースtrgtのほとんどまたはすべてのデータファイルが消失したと想定しています。また、データベースで高速リカバリ領域が使用されているとも想定しています。

データベース全体のリストアおよびリカバリの後で、データベースがオープンされると、制御ファイルに記録された欠落している一時表領域は、以前の作成サイズ、AUTOEXTENDおよびMAXSIZE属性で再作成されます。欠落している一時表領域のみが再作成されます。RMANリポジトリに記録された場所に存在する一時ファイルのヘッダーが無効な場合、RMANは一時ファイルを再作成しません。

一時ファイルがOracle Managed Filesとして作成されていた場合は、現在のDB_CREATE_FILE_DESTの場所に再作成されます。そうでない場合は、以前の場所で再作成されます。RMANがI/Oエラーまたは他の原因でファイルを再作成できない場合、エラーがアラート・ログにレポートされ、データベースのオープン操作が続行されます。

データベース全体をリストアおよびリカバリする手順

1. RMANを起動し、ターゲット・データベースに接続します。
たとえば、次のコマンドを入力します。

% rman
RMAN> CONNECT TARGET /

RMANは、接続時にnot started、not mounted、not open(データベースはマウントされているがオープンされていない場合)またはnone(データベースがオープンされている場合)のいずれかのデータベース・ステータスを表示します。

2. データベースがマウントされていない場合は、データベースをマウントします。ただし、オープンはしません。
たとえば、次のコマンドを入力します。

STARTUP MOUNT;

3. SHOWコマンドを使用して、事前構成済のチャネルを確認します。
たとえば、次のコマンドを入力します(出力例も示します)。

SHOW ALL;

RMAN configuration parameters for database with db_unique_name PROD1 are:
.
.
.
CONFIGURE DEFAULT DEVICE TYPE TO DISK; # default
CONFIGURE DEVICE TYPE DISK PARALLELISM 1 BACKUP TYPE TO BACKUPSET; # default
CONFIGURE DEVICE TYPE SBT_TAPE PARALLELISM 1 BACKUP TYPE TO BACKUPSET; # default
CONFIGURE CHANNEL DEVICE TYPE 'SBT_TAPE' PARMS "SBT_LIBRARY=/usr/local/oracle/backup/lib/libobk.so";

必要なデバイスおよびチャネルがすでに構成されている場合、操作は必要ありません。そうでない場合は、CONFIGUREコマンドを使用して自動チャネルを構成するか、またはRUNブロック内にALLOCATE CHANNELコマンドを含めます。

4. パスワード保護された暗号化バックアップをリストアする場合は、パスワードを指定します。
次の例に示すように、SET DECRYPTION IDENTIFIED BYコマンドを使用して、パスワード保護されたバックアップのパスワードを指定します(passwordは実際に入力するパスワードを表します)。

SET DECRYPTION IDENTIFIED BY password;

異なるパスワードでバックアップを作成した場合は、バックアップのリストアに必要となる可能性のあるすべてのパスワードを指定してSET DECRYPTION IDENTIFIED BY passwordコマンドを複数回実行できます。

5. データベースをリストアおよびリカバリします。次のいずれかを実行します。

- すべてのデータファイルを元の場所にリストアする場合は、RMANプロンプトでRESTORE DATABASEとRECOVER DATABASEを順に実行します。
たとえば、自動チャネルが構成されている場合は、次のコマンドを入力します(出力例も示します)。

RMAN> RESTORE DATABASE;

Starting restore at 20-JUN-06
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=35 device type=DISK
allocated channel: ORA_SBT_TAPE_1
channel ORA_SBT_TAPE_1: SID=34 device type=SBT_TAPE
channel ORA_SBT_TAPE_1: Oracle Secure Backup

channel ORA_DISK_1: starting datafile backup set restore
channel ORA_DISK_1: specifying datafile(s) to restore from backup set
channel ORA_DISK_1: restoring datafile 00001 to /disk1/oracle/dbs/tbs_01.f
channel ORA_DISK_1: restoring datafile 00002 to /disk1/oracle/dbs/tbs_ax1.f
.
.
.
Finished restore at 20-JUN-06

RMAN> RECOVER DATABASE;

Starting recover at 20-JUN-06
using channel ORA_DISK_1
allocated channel: ORA_SBT_TAPE_1
channel ORA_SBT_TAPE_1: SID=34 device type=SBT_TAPE
channel ORA_SBT_TAPE_1: Oracle Secure Backup

starting media recovery

channel ORA_DISK_1: starting archived log restore to default destination
channel ORA_DISK_1: restoring archived log
archived log thread=1 sequence=5
channel ORA_DISK_1: restoring archived log
archived log thread=1 sequence=6
.
.
.
channel ORA_DISK_1: reading from backup piece /disk1/oracle/work/orcva/TKRM/backupset/2007_06_20/o1_mf_annnn_TAG20070620T113128_29jhr197_.bkp
channel ORA_DISK_1: piece handle=/disk1/oracle/work/orcva/TKRM/backupset/2007_06_20/o1_mf_annnn_TAG20070620T113128_29jhr197_.bkp tag=TAG20070620T113128
channel ORA_DISK_1: restored backup piece 1
channel ORA_DISK_1: restore complete, elapsed time: 00:00:02
archived log file name=/disk1/oracle/work/orcva/TKRM/archivelog/2007_06_20/o1_mf_1_5_29jhv47k_.arc thread=1 sequence=5
channel default: deleting archived log(s)
.
.
.
media recovery complete, elapsed time: 00:00:15
Finished recover at 20-JUN-06

チャネルを手動で割り当てる場合は、RESTOREおよびRECOVERコマンドをRUNブロック内で同時に発行する必要があります。次に例を示します。

RUN
{
ALLOCATE CHANNEL c1 DEVICE TYPE sbt;
RESTORE DATABASE;
RECOVER DATABASE;
}

- 一部のデータファイルを新しい場所にリストアする場合は、RUNコマンドでRESTORE DATABASEとRECOVER DATABASEを順に実行します。「デフォルト以外の場所へのデータファイルのリストア」で説明するように、SET NEWNAMEを使用して、データファイルの名前を変更します。
次の例では、データベースをリストアし、3つのデータファイルに新しい名前を指定してから、データベースをリカバリします。

RUN
{
SET NEWNAME FOR DATAFILE 2 TO '/disk2/df2.dbf';
SET NEWNAME FOR DATAFILE 3 TO '/disk2/df3.dbf';
SET NEWNAME FOR DATAFILE 4 TO '/disk2/df4.dbf';
RESTORE DATABASE;
SWITCH DATAFILE ALL;
RECOVER DATABASE;
}

6. 出力を調べて、メディア・リカバリが正常に実行されたかどうかを確認します。正常に実行された場合は、データベースをオープンします。
たとえば、次のコマンドを入力します。

ALTER DATABASE OPEN;

表領域の完全リカバリの実行

基本的な例では、データベースはオープンされており、データファイルのすべてではなく一部が破損しています。データベースの残りの部分を使用可能にしておくために、データベースはオープンしたままで、破損した表領域をリストアおよびリカバリします。この例では、データベースtrgtの表領域usersが消失したと想定しています。

表領域をリストアおよびリカバリする手順

1. RMANを起動し、ターゲット・データベースに接続します。

2. データベースがオープンされている場合は、リカバリが必要なデータファイルをオフラインにします。
たとえば、次のコマンドを入力してusersをオフラインにします。

SQL "ALTER TABLESPACE users OFFLINE IMMEDIATE";

3. SHOWコマンドを使用して、事前構成済のチャネルを確認します。
たとえば、次のコマンドを入力します(出力例も示します)。

SHOW ALL;

RMAN configuration parameters for database with db_unique_name PROD1 are:
.
.
.
CONFIGURE DEFAULT DEVICE TYPE TO DISK; # default
CONFIGURE DEVICE TYPE DISK PARALLELISM 1 BACKUP TYPE TO BACKUPSET; # default
CONFIGURE DEVICE TYPE SBT_TAPE PARALLELISM 1 BACKUP TYPE TO BACKUPSET; # default
CONFIGURE CHANNEL DEVICE TYPE 'SBT_TAPE' PARMS  "SBT_LIBRARY=/usr/local/oracle/backup/lib/libobk.so";

必要なデバイスおよびチャネルがすでに構成されている場合、操作は必要ありません。そうでない場合は、CONFIGUREコマンドを使用して自動チャネルを構成するか、またはRUNブロック内にALLOCATE CHANNELコマンドを含めます。

4. パスワード保護された暗号化バックアップをリストアする場合は、パスワードを指定します。
次の例に示すように、SET DECRYPTION IDENTIFIED BYコマンドを使用して、パスワード保護されたバックアップのパスワードを指定します(passwordは実際に入力するパスワードを表します)。

SET DECRYPTION IDENTIFIED BY password;

5. 表領域をリストアおよびリカバリします。次のいずれかを実行します。

- データファイルを元の場所にリストアする場合は、RMANプロンプトでRESTORE TABLESPACEとRECOVER TABLESPACEコマンドを実行します。
たとえば、自動チャネルが構成されている場合は、次のコマンドを入力します(出力例も示します)。

RMAN> RESTORE TABLESPACE users;

Starting restore at 20-JUN-06
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=37 device type=DISK
allocated channel: ORA_SBT_TAPE_1
channel ORA_SBT_TAPE_1: SID=38 device type=SBT_TAPE
channel ORA_SBT_TAPE_1: Oracle Secure Backup

channel ORA_DISK_1: starting datafile backup set restore
channel ORA_DISK_1: specifying datafile(s) to restore from backup set
channel ORA_DISK_1: restoring datafile 00012 to /disk1/oracle/dbs/users01.f
channel ORA_DISK_1: restoring datafile 00013 to /disk1/oracle/dbs/users02.f
channel ORA_DISK_1: restoring datafile 00021 to /disk1/oracle/dbs/users03.f
channel ORA_DISK_1: reading from backup piece /disk1/oracle/work/orcva/TKRM/backupset/2007_06_20/o1_mf_nnndf_TAG20070620T105435_29jflwor_.bkp
channel ORA_DISK_1: piece handle=/disk1/oracle/work/orcva/TKRM/backupset/2007_06_20/o1_mf_nnndf_TAG20070620T105435_29jflwor_.bkp tag=TAG20070620T105435
channel ORA_DISK_1: restored backup piece 1
channel ORA_DISK_1: restore complete, elapsed time: 00:00:01
Finished restore at 20-JUN-06

RMAN> RECOVER TABLESPACE users;

Starting recover at 20-JUN-06
using channel ORA_DISK_1
using channel ORA_SBT_TAPE_1

starting media recovery

archived log for thread 1 with sequence 27 is already on disk as file /disk1/oracle/work/orcva/TKRM/archivelog/2007_06_20/o1_mf_1_27_29jjmtc9_.arc
archived log for thread 1 with sequence 28 is already on disk as file /disk1/oracle/work/orcva/TKRM/archivelog/2007_06_20/o1_mf_1_28_29jjnc5x_.arc
.
.
.
channel ORA_DISK_1: starting archived log restore to default destination
channel ORA_DISK_1: restoring archived log
archived log thread=1 sequence=5
channel ORA_DISK_1: restoring archived log
archived log thread=1 sequence=6
channel ORA_DISK_1: restoring archived log
archived log thread=1 sequence=7
.
.
.
channel ORA_DISK_1: reading from backup piece /disk1/oracle/work/orcva/TKRM/backupset/2007_06_20/o1_mf_annnn_TAG20070620T113128_29jhr197_.bkp
channel ORA_DISK_1: piece handle=/disk1/oracle/work/orcva/TKRM/backupset/2007_06_20/o1_mf_annnn_TAG20070620T113128_29jhr197_.bkp tag=TAG20070620T113128
channel ORA_DISK_1: restored backup piece 1
channel ORA_DISK_1: restore complete, elapsed time: 00:00:02
archived log file name=/disk1/oracle/work/orcva/TKRM/archivelog/2007_06_20/o1_mf_1_5_29jkdvjq_.arc thread=1 sequence=5
channel default: deleting archived log(s)
archived log file name=/disk1/oracle/work/orcva/TKRM/archivelog/2007_06_20/o1_mf_1_5_29jkdvjq_.arc RECID=91 STAMP=593611179
archived log file name=/disk1/oracle/work/orcva/TKRM/archivelog/2007_06_20/o1_mf_1_6_29jkdvbz_.arc thread=1 sequence=6
channel default: deleting archived log(s)
.
.
.
media recovery complete, elapsed time: 00:00:01
Finished recover at 20-JUN-06

- 一部のデータファイルを新しい場所にリストアする場合は、RUNコマンドでRESTORE TABLESPACEとRECOVER TABLESPACEを実行します。「デフォルト以外の場所へのデータファイルのリストア」で説明するように、SET NEWNAMEを使用して、データファイルの名前を変更します。
次の例では、表領域users内のデータファイルを新しい場所にリストアした後、リカバリを実行します。古いデータファイルは/disk1パスに格納されており、新しいデータファイルは/disk2パスに格納されると想定しています。

RUN
{
# specify the new location for each datafile
SET NEWNAME FOR DATAFILE '/disk1/oracle/dbs/users01.f' TO
'/disk2/users01.f';
SET NEWNAME FOR DATAFILE '/disk1/oracle/dbs/users02.f' TO
'/disk2/users02.f';
SET NEWNAME FOR DATAFILE '/disk1/oracle/dbs/users03.f' TO
'/disk2/users03.f';
RESTORE TABLESPACE users;
SWITCH DATAFILE ALL;   # update control file with new file names
RECOVER TABLESPACE users;
}

6. 出力を調べて、リカバリが正常に実行されたことを確認します。正常に実行された場合は、リカバリした表領域をオンラインに戻します。
たとえば、次のコマンドを入力します。

SQL "ALTER TABLESPACE users ONLINE";

コピーへの切替え後の完全リカバリの実行

アクセスできないデータファイルのイメージ・コピーが高速リカバリ領域に存在する場合、SWITCH DATAFILE ... TO COPYコマンドを使用して制御ファイルをデータファイルのコピーにポイントしてからRECOVERを使用すると、消失した変更をリカバリできます。SWITCH DATABASE TO COPYコマンドを使用して、制御ファイルをデータベース全体のコピーにポイントすることもできます。バックアップをリストアする必要がないため、このリカバリ方法は従来のリストアおよびリカバリより時間がかかりません。

注意:
SWITCH TABLESPACE ... TO COPYコマンドは、表領域のすべてのデータファイルが消失し、すべてのデータファイルのコピーが存在する場合でもサポートされます。SWITCH DATABASE TO COPYについても同じ制限があります。

データファイルのコピーへの切替え

基本的な例では、データベースはオープンされており、データファイルのすべてではなく一部が破損しています。1日の中で、あるデータファイルがストレージ障害によって欠落します。このファイルを修復する必要がありますが、バックアップからリストアおよびリカバリする時間はありません。最新のイメージ・コピー・バックアップを新しいファイルとして使用して、リストア時間をなくします。この例では、データベースtrgtのデータファイル4が消失したと想定しています。

データファイルのコピーに切り替えてリカバリを実行する手順

1. RMANを起動し、ターゲット・データベースに接続します。

2. データベースがオープンされている場合は、リカバリが必要な表領域をオフラインにします。
次のコマンドを入力してデータファイル4をオフラインにします。

SQL "ALTER DATABASE DATAFILE 4 OFFLINE";

3. オフラインのデータファイルを最新のコピーに切り替えます。
次のコマンドを入力して、制御ファイルをデータファイル4の最新のイメージ・コピーにポイントします。

SWITCH DATAFILE 4 TO COPY;

4. RECOVER DATAFILEコマンドで、データファイルをリカバリします。
次のコマンドを入力します。

RECOVER DATAFILE 4;

RMANは、アーカイブREDOログおよび増分バックアップを自動的にリストアします。データベースでは高速リカバリ領域が使用されるため、RMANは、これらを、適用した後に自動的に削除します。

5. 出力を調べて、リカバリが正常に実行されたことを確認します。正常に実行された場合は、リカバリしたデータファイルをオンラインに戻します。
次のコマンドを入力してデータファイル4をオンラインにします。

SQL "ALTER DATABASE DATAFILE 4 ONLINE";

データベースのコピーへの切替え

この例では、データベースは停止しており、すべてのデータファイルが破損しています。破損したすべてのデータファイルには、イメージ・コピーがあります。既存のイメージ・コピーを新しいデータファイルとして使用して、リストア時間をなくします。

データベースのコピーに切り替えてリカバリを実行する手順

1. RMANを起動し、ターゲット・データベースに接続します。

2. データベースをマウントします。

3. データベースを最新のコピーに切り替えます。
次のコマンドを入力して、制御ファイルをデータベースの最新のイメージ・コピーにポイントします。

SWITCH DATABASE TO COPY;

4. RECOVER DATABASEコマンドで、データベースをリカバリします。
次のコマンドを入力します。

RECOVER DATABASE;

RMANは、アーカイブREDOログおよび増分バックアップを自動的にリストアします。データベースでは高速リカバリ領域が使用されるため、RMANは、これらを、適用した後に自動的に削除します。

5. 出力を調べて、リカバリが正常に実行されたことを確認します。正常に実行された場合は、データベースをオープンします。
データベースをオープンするには、次のコマンドを入力します。

ALTER DATABASE OPEN;

18 フラッシュバックおよびデータベースのPoint-in-Timeリカバリの実行

この章では、不要なデータベース変更について調べ、Oracleのフラッシュバック技術およびデータベース・バックアップに基づいた適切なリカバリ計画を選択して実行する方法について説明します。含まれる内容は、次のとおりです。

- Oracleフラッシュバック技術およびデータベースのPoint-in-Timeリカバリの概要

- フラッシュバック表を使用した表の巻戻し

- フラッシュバック・ドロップを使用したDROP TABLE操作の巻戻し

- フラッシュバック・データベースを使用したデータベースの巻戻し

- データベースのPoint-in-Timeリカバリの実行

- フラッシュバックおよびデータベースのPoint-in-Timeリカバリの例

Oracleフラッシュバック技術およびデータベースのPoint-in-Timeリカバリの概要

この項では、フラッシュバック技術およびデータベースのPoint-in-Timeリカバリの目的および基本的な概念について説明します。

フラッシュバックおよびデータベースのPoint-in-Timeリカバリの目的

通常、フラッシュバック機能またはPoint-in-Timeリカバリは、次のような場合に実行します。

- ユーザー・エラーまたは破損によって、必要なデータが削除されるか、またはデータが破損された場合。たとえば、ユーザーまたはDBAが誤って1つ以上の表の内容を削除または更新したり、アプリケーションの更新中にまだ必要なデータベース・オブジェクトを削除したり、大規模なバッチ更新を実行して途中で障害が発生した場合などです。

- データベースのアップグレードに失敗するか、アップグレード・スクリプトが消失した場合。

- すべての必要なREDOログまたは増分バックアップがないため、メディア障害後の完全なデータベース・リカバリを正常に実行できない場合。

いずれの場合も、Point-in-Timeリカバリまたはフラッシュバック機能を使用して、データベースまたはデータベース・オブジェクトを前の時点の状態に戻すことができます。

Point-in-Timeリカバリおよびフラッシュバック機能の基本的な概念

不要なデータベース変更に対する最も基本的な解決方法は、RMANのデータベースのPoint-in-Timeリカバリ(DBPITR)です。DBPITRは、使用可能なすべてのREDOを使用することも、データベースに対するすべての変更をリカバリすることもないため、不完全リカバリとも呼ばれます。この場合は、データベース全体のバックアップをリストアしてから、REDOログまたは増分バックアップを適用して、不要な変更の前の時点までのすべての変更を再作成します。

不要なデータベース変更が大規模ではあるが、特定の表領域に制限されている場合は、 表領域のPoint-in-Timeリカバリ(TSPITR)を使用して、影響を受けない表領域を使用可能の状態にしたまま、影響を受けている表領域を以前のSCNに戻すことができます。RMANのTSPITRは高度な手法です。詳細は、第21章「RMANの表領域のPoint-in-Timeリカバリ(TSPITR)の実行」を参照してください。

また、Oracle Databaseには、フラッシュバック技術と呼ばれる一連の機能も備えられています。この技術によって、バックアップからデータベースをリストアせずに、データの過去の状態を表示したり、データを任意の時点に戻したり、進めることができます。データベースに対する変更によっては、フラッシュバック技術で、データベースの可用性に与える影響を抑えてより迅速に不要な変更を無効にすることができます。

データベースのPoint-in-Timeリカバリの基本的な概念

DBPITRは、物理レベルで動作し、データファイルを過去の目標時点の状態に戻します。RMANのDBPITR操作では、目的のSCN、ログ順序、リストア・ポイントまたは時刻を指定します。RMANは、目標時点以前に作成されたバックアップからデータベースをリストアしてから、増分バックアップおよびログを適用して、データファイルをバックアップした時点とリカバリの終了時点の間のすべての変更を再作成します。終了時点がSCNとして指定されている場合、データベースは、REDOログを適用し、各REDOスレッドの終了時または指定したSCNのうちの早い方の時点で停止します。終了時点が時刻として指定されている場合、データベースは、指定した時刻に適したSCNを内部的に判別した後、このSCNまでリカバリします。

バックアップ計画が適切に設計され、データベースがARCHIVELOGモードで実行されている場合は、ほぼすべての状況でDBPITRを実行できます。「データベースの不完全リカバリの実行」で説明されているように、RMANのDBPITRは、ユーザー管理のDBPITRと比較すると簡略化されています。目的のSCNを指定すると、データファイルがバックアップからリストアされ、ユーザーの介入なしで効率的にリカバリが行われます。ただし、RMANのDBPITRには、次のデメリットがあります。

- 以前の状態に戻すことができるのはデータベース全体のみであり、選択したオブジェクトを以前の状態に戻すことはできません。

- DBPITRの実行中、データベース全体が使用不可になります。

- RMANはすべてのデータファイルをリストアする必要があるため、DBPITRに時間がかかる可能性があります。また、RMANは、データファイルをリカバリするためにREDOログおよび増分バックアップをリストアする必要がある場合もあります。バックアップがテープ上にある場合は、このプロセスにさらに時間がかかる可能性があります。

フラッシュバック技術の基本的な概念

Oracleのフラッシュバック機能が使用可能なほとんどの状況では、フラッシュバック機能の方がメディア・リカバリより効率的です。フラッシュバック機能を使用すると、データベースの過去の状態を調べることができます。

バックアップおよびリカバリで役立つ物理フラッシュバック機能

「フラッシュバック・データベースを使用したデータベースの巻戻し」で説明されているように、DBPITRの最も効率的な代替機能として、Oracle Flashback Databaseがあります。他のフラッシュバック機能とは異なり、この機能は物理レベルで動作して、現行のデータファイルが過去の内容に戻されます。結果は、DBPITR(OPEN RESETLOGSを含む)の結果に類似していますが、フラッシュバック・データベースではデータファイルをリストアする必要はなく、メディア・リカバリと比較してREDOの適用が限られているため、通常、はるかに短時間でリカバリが行われます。

「高速リカバリ領域の構成」で説明されているように、フラッシュバック・データベースには高速リカバリ領域が必要です。フラッシュバック・データベースのロギングを有効にするには、DB_FLASHBACK_RETENTION_TARGET初期化パラメータを設定し、ALTER DATABASE FLASHBACK ON文を発行する必要があります。

通常の操作中、データベースによって、フラッシュバック・ログにデータファイル・ブロックの古いイメージが定期的に書き込まれます。フラッシュバック・ログは順次書き込まれ、バルク書込みが行われることも多くあります。フラッシュバック・ロギングは、継続バックアップに類似しています。データベースでは、リカバリ領域に対するフラッシュバック・ログの書込み、削除およびサイズ変更が自動的に行われます。フラッシュバック・ログはアーカイブされません。フラッシュバック・ログは、パフォーマンスを監視したり、フラッシュ・リカバリ領域に対するディスク領域の割当てを決定する場合にのみ確認する必要があります。

フラッシュバック・データベース操作を行う際に、データベースは、過去のバージョンのデータ・ブロックへのアクセスにフラッシュバック・ログを使用し、アーカイブREDOログの一部のデータも使用します。したがって、障害が検出された後はフラッシュバック・データベースを有効にできなくなるため、フラッシュバック・データベースを使用してこの障害発生の前まで巻き戻します。保証付きリストア・ポイントの関連機能を使用すると、危険を伴うデータベースの変更の直前などの特定の時点のデータベースの内容を保護できます。

バックアップおよびリカバリで役立つ論理フラッシュバック機能

残りのフラッシュバック機能は、論理レベルで動作します。この章で説明する論理機能は、次のとおりです。

- フラッシュバック表
データベースのいずれの部分もオフラインにすることなく、表または表のセットを過去の指定した時点にリカバリできます。ほとんどの場合、フラッシュバック表を使用すると、より複雑なPoint-in-Timeリカバリ操作を行う必要がなくなります。フラッシュバック表では、表がリストアされ、同時に現在の索引、トリガーおよび制約などの関連する属性が自動的にメンテナンスされるため、ユーザーはアプリケーション固有のプロパティを検索してリストアする必要がありません。

この機能の使用方法については、「フラッシュバック表を使用した表の巻戻し」を参照してください。

- フラッシュバック・ドロップ
DROP TABLE文の結果を無効にできます。

この機能の使用方法については、「フラッシュバック・ドロップを使用したDROP TABLE操作の巻戻し」を参照してください。

注意:
論理フラッシュバック機能の用途はバックアップおよびリカバリに特化したものではないため、これらの機能に関する一部のドキュメントはドキュメント・セット内の他の場所に存在しています。

フラッシュバック・ドロップ以外のすべての論理フラッシュバック機能では、UNDOデータが使用されます。UNDOレコードは、主に、SQL問合せでの読取り一貫性の提供およびトランザクションのロールバックのために使用されます。このため、UNDOレコードには、過去の時点のデータの再構築、およびその過去の時点以降の変更のレコードの調査に必要な情報が含まれています。

フラッシュバック・ドロップでは、ごみ箱と呼ばれるメカニズムが使用されます。Oracleは、削除されたデータベース・オブジェクトの占める領域が新しいデータのために必要となるまで、ごみ箱を使用してそれらのオブジェクトを管理します。ごみ箱に割り当てられる領域の量は固定されていません。また、削除されたオブジェクトがごみ箱に残される期間については保証されていません。システム・アクティビティに応じて、削除されたオブジェクトがごみ箱に残される期間は、数秒または数か月になる場合があります。

参照:

- UNDOデータおよび自動UNDO管理の詳細は、『Oracle Database概要』および『Oracle Database管理者ガイド』を参照してください。

- 論理フラッシュバック機能を使用する方法については、『Oracle Databaseアドバンスト・アプリケーション開発者ガイド』を参照してください。

- フラッシュバック・データベースを使用するためのデータベースの設定および関連するリストア・ポイント機能の詳細は、「フラッシュバック・データベース、リストア・ポイントおよび保証付きリストア・ポイントについて」を参照してください。

フラッシュバック表を使用した表の巻戻し

フラッシュバック表では、リストアされたバックアップではなくUNDO表領域の情報を使用して、表を取得します。フラッシュバック表操作を行うと、新しい行が削除され、古い行が再度挿入されます。表のフラッシュバックの実行中、データベースの残りの部分は使用可能のままになります。

関連項目:
自動UNDO管理の詳細は、『Oracle Database管理者ガイド』を参照してください。

フラッシュバック表の前提条件

1つ以上の表でOracle Flashback Table機能を使用するには、目標時点またはSCNでFLASHBACK TABLE SQL文を使用します。

フラッシュバック表機能を使用するには、次の権限を所有している必要があります。

- FLASHBACK ANY TABLEシステム権限を付与されているか、または表に対するFLASHBACKオブジェクト権限を所有している必要があります。

- 表に対するSELECT、INSERT、DELETEおよびALTER権限を持っている必要があります。

- 表をリストア・ポイントまでフラッシュバックするには、SELECT ANY DICTIONARYまたはFLASHBACK ANY TABLEシステム権限またはSELECT_CATALOG_ROLEロールを所有している必要があります。

オブジェクトをフラッシュバックするには、そのオブジェクトが次の前提条件を満たしている必要があります。

- オブジェクトが、クラスタの一部である表、マテリアライズド・ビュー、アドバンスト・キューイング(AQ)表、静的データ・ディクショナリ表、システム表、リモート表、オブジェクト表、ネストした表、個々の表パーティションまたは個々の表サブパーティションなどのカテゴリに含まれていないこと。

- 現在の時刻とフラッシュバックの目標時点の間に、表の構造が変更されていないこと。
表の構造は、表の更新、移動または切捨て、表への制約の追加、クラスタへの表の追加、列の変更または削除、パーティションまたはサブパーティションの追加、削除、マージ、分割、結合または切捨て(レンジ・パーティションの追加を除く)などのDDL操作によって変更されます。

- 行の移動が、表で有効化されていること(フラッシュバックの発生後に行IDが変更されることを意味します)。
フラッシュバック前の行IDがアプリケーションによって保存された場合、その行IDがフラッシュバック後の同じ行に対応することは保証されないため、この制限が存在します。アプリケーションが行IDに依存している場合は、フラッシュバック表を使用することができません。

- UNDO表領域のUNDOデータの範囲が、フラッシュバック目標時点またはSCNを含む十分な範囲になっていること。
フラッシュバック表を実行することができる時点は、UNDO保存期間(UNDOデータが再利用されるまで保存される最小時間)および表領域の特性によって決定されます。UNDOデータには、変更前のデータ・ブロックに関する情報が含まれています。フラッシュバック操作では、UNDOを使用して元のデータが再作成されます。

フラッシュバック表操作でUNDO情報が確実に保持されるように、UNDO表領域のUNDO_RETENTIONパラメータを86400秒(24時間)以上に設定することをお薦めします。

注意:
FLASHBACK TABLE ... TO BEFORE DROPでは、フラッシュバック表ではなくフラッシュバック・ドロップ機能が使用されるため、これらの前提条件は適用されません。詳細は、「フラッシュバック・ドロップを使用したDROP TABLE操作の巻戻し」を参照してください。

フラッシュバック表操作の実行

次の例では、ユーザーが更新を誤って複数回実行した後、hr.temp_employees表のフラッシュバックを実行すると想定しています。

temp_employeesのフラッシュバックを実行する手順

1. SQL*Plusをターゲット・データベースに接続し、現行のSCNを識別します。
FLASHBACK TABLE文はロールバックできませんが、別のFLASHBACK TABLE文を発行し、現在の時刻の直前の時刻を指定することができます。このため、現行のSCNを記録することお薦めします。現行のSCNは、V$DATABASEを次のように問い合せることによって取得できます。

SELECT CURRENT_SCN
FROM   V$DATABASE;

2. 表を戻す時刻、SCNまたはリストア・ポイントを識別します。
リストア・ポイントを作成した場合は、次の問合せを実行して、使用可能なリストア・ポイントを表示できます。

SELECT NAME, SCN, TIME
FROM   V$RESTORE_POINT;

3. 指定した目標時点に表を巻戻すための十分なUNDOデータが存在していることを確認します。
UNDO_RETENTION初期化パラメータが設定されており、UNDO保存保証が有効になっている場合は、次の問合せを使用して、UNDOデータが保持される期間を確認できます。

SELECT NAME, VALUE/60 MINUTES_RETAINED
FROM   V$PARAMETER
WHERE  NAME = 'undo_retention';

4. 行の移動が、フラッシュバック表を使用して巻き戻しているすべてのオブジェクトに対して有効になっていることを確認します。
次のSQL文を使用して、表の行の移動を有効にすることができます。ここで、tableは、巻き戻す表の名前です。

ALTER TABLE table ENABLE ROW MOVEMENT;

5. フラッシュバック対象の表に、他の表への依存性があるかどうかを確認します。依存性が存在する場合は、それらの表をフラッシュバックするかどうかも決定します。
次のSQL文を発行し、依存性を確認します。ここで、schema_nameはフラッシュバック対象の表のスキーマ、table_nameは表の名前です。

SELECT other.owner, other.table_name
FROM   sys.all_constraints this, sys.all_constraints other
WHERE  this.owner = schema_name
AND    this.table_name = table_name
AND    this.r_owner = other.owner
AND    this.r_constraint_name = other.constraint_name
AND    this.constraint_type='R';

6. フラッシュバック対象のオブジェクトに対して、FLASHBACK TABLE文を実行します。

次のSQL文を実行すると、hr.temp_employees表が、temp_employees_updateというリストア・ポイントまでリストアされます。

FLASHBACK TABLE hr.temp_employees
TO RESTORE POINT temp_employees_update;

次のSQL文を実行すると、hr.temp_employees表の状態が、SCNで指定された時点のデータベースの状態まで巻き戻されます。

FLASHBACK TABLE hr.temp_employees
TO SCN 123456;

次の例に示すように、TO_TIMESTAMPを使用して目標時点を指定することもできます。

FLASHBACK TABLE hr.temp_employees
TO TIMESTAMP TO_TIMESTAMP('2007-10-17 09:30:00', 'YYYY-MM-DD HH:MI:SS');

注意:
タイムスタンプとSCNのマッピングは、常に正確であるとはかぎりません。FLASHBACK TABLE文でタイムスタンプを使用した場合、表がフラッシュバックされる時刻とTO_TIMESTAMPで指定される時刻の間で最大3秒異なることがあります。過去の正確な時点が必要な場合は、時刻ではなくSCNを使用します。

7. 必要に応じて、表を問い合せてデータを確認します。

フラッシュバック表中のトリガーの有効状態の保持

デフォルトでは、データベースによって、FLASHBACK TABLE操作の実行前に、影響を受ける表のトリガーが無効にされます。このトリガーの状態は、操作の終了後、操作前の状態(有効または無効)に戻されます。表のフラッシュバック中にトリガーを有効な状態のままにするには、手順6でFLASHBACK TABLE文にENABLE TRIGGERS句を追加します。

たとえば、HR管理者が17時に、hr.temp_employees表からある従業員が欠落していることに気付いたとします。この従業員は、レポートが最後に実行された14時には表に含まれていました。したがって、この従業員のレコードが誤って削除されたのは、14時から17時の間です。HR管理者は、フラッシュバック表を使用して、hr.temp_employees表に設定されているすべてのトリガーを有効にして、表を午後2時の状態に戻します。この場合、次の例のSQL文を使用します。

FLASHBACK TABLE temp_employees
TO TIMESTAMP TO_TIMESTAMP('2005-03-03 14:00:00' , 'YYYY-MM-DD HH:MI:SS')
ENABLE TRIGGERS;

関連項目:

- フラッシュバック表機能を使用して表をリカバリする方法については、『Oracle Database管理者ガイド』を参照してください。

- Oracle Flashback Tableの簡単な使用例は、『Oracle Database SQL言語リファレンス』を参照してください。

フラッシュバック・ドロップを使用したDROP TABLE操作の巻戻し

この項では、FLASHBACK TABLE ... TO BEFORE DROP文を使用して、ごみ箱からオブジェクトを取得する方法について説明します。

フラッシュバック・ドロップ

フラッシュバック・ドロップによって、DROP TABLE操作の結果を無効にできます。フラッシュバック・ドロップは、この状況で使用できる他のリカバリ・メカニズム(Point-in-Timeリカバリなど)より高速です。また、フラッシュバック・ドロップによって、停止時間または最新のトランザクションの消失は発生しません。

表を削除した場合、その表に関連付けられている領域はデータベースによってすぐには削除されません。かわりに、表は、名前を変更され、関連付けられているすべてのオブジェクトとともにごみ箱に配置されます。システム生成のごみ箱のオブジェクト名は一意です。他のオブジェクトを問い合せる場合と同様に、ごみ箱内のオブジェクトを問い合せることができます。

フラッシュバック操作では、ごみ箱から表が取り出されます。削除された表を取得する場合は、ユーザーが指定した表の元の名前またはシステム生成の名前を使用できます。

表を削除すると、表およびそれに依存するすべてのオブジェクトが同時にごみ箱に移動されます。同様に、フラッシュバック・ドロップを実行すると、通常、すべてのオブジェクトが同時に取得されます。表をごみ箱からリストアすると、索引などの依存オブジェクトの名前は、元の名前に戻されず、ごみ箱内のシステム生成の名前のままになります。Oracle Databaseでは、表に定義されたすべての索引(ビットマップ結合索引を除く)、および表に定義されたすべてのトリガーと制約(他の表を参照する参照整合性制約を除く)が取得されます。

索引などの依存オブジェクトの一部は、領域圧迫のため再利用される場合があります。この場合、再利用された依存オブジェクトは、ごみ箱から取得できません。

フラッシュバック・ドロップの前提条件

次に、フラッシュバック・ドロップおよびごみ箱に関連する操作に必要なユーザー権限の概要を示します。

- DROP
オブジェクトに対してDROP権限を持つすべてのユーザーは、オブジェクトを削除し、ごみ箱に配置することができます。

- FLASHBACK TABLE ... TO BEFORE DROP
この文に対する権限は、DROP権限に関連付けられています。つまり、オブジェクトを削除できるすべてのユーザーは、フラッシュバック・ドロップを実行して、削除済オブジェクトをごみ箱から取得できます。

- PURGE
ごみ箱の消去に対する権限は、DROP権限に関連付けられています。DROP TABLEまたはDROP ANY TABLE権限を持つユーザーは、オブジェクトをごみ箱から消去できます。

- ごみ箱内のオブジェクトに対するSELECT
ごみ箱のオブジェクトの問合せを行う場合、ユーザーは、ごみ箱のオブジェクトに対してSELECTおよびFLASHBACK権限を所有している必要があります。削除前にオブジェクトに対してSELECT権限を所有していたすべてのユーザーは、ごみ箱内のそのオブジェクトに対してSELECT権限を継続して所有しています。ごみ箱内のオブジェクトは過去の状態のデータベースのオブジェクトであるため、これらのオブジェクトを問い合せるには、ユーザーはFLASHBACK権限が必要です。

ごみ箱からオブジェクトを取得するには、オブジェクトが次の要件を満たしている必要があります。

- システム表領域ではないローカル管理表領域に対してのみごみ箱が使用可能であること。表がシステム表領域ではないローカル管理表領域に含まれていて、その依存セグメント(オブジェクト)がディクショナリ管理表領域に含まれている場合、これらのオブジェクトはごみ箱によって保護されます。

- ファイングレイン監査ポリシー(FGA)およびVirtual Private Database(VPD)ポリシーが定義されている表が、ごみ箱によって保護されていないこと。

- パーティション化された索引構成表が、ごみ箱によって保護されていないこと。

- 領域再利用操作のため、ユーザーまたはOracle Databaseのいずれかによって表が削除されていないこと。

フラッシュバック・ドロップ操作の実行

FLASHBACK TABLE ... TO BEFORE DROP文を使用すると、ごみ箱からオブジェクトをリカバリできます。ごみ箱内の表の名前または元の表の名前のいずれかを指定できます。

この項では、誤った表を削除した例を想定しています。テスト・データベースで表の削除を複数回要求されましたが、この場合、かわりに本番データベースに誤って接続し、hr.employee_demoを削除したとします。FLASHBACK TABLEを使用し、削除されたオブジェクトを取得します。

削除された表を取得する手順

1. SQL*Plusをターゲット・データベースに接続し、ごみ箱内の削除された表の名前を取得します。
SQL*PlusコマンドSHOW RECYCLEBINは、次のように使用できます。

SHOW RECYCLEBIN;

ORIGINAL NAME    RECYCLEBIN NAME                   TYPE         DROP TIME
---------------- --------------------------------- ------------ -------------
EMPLOYEE_DEMO    BIN$gk3lsj/3akk5hg3j2lkl5j3d==$0  TABLE    2005-04-11:17:08:54

ORIGINAL NAME列には、オブジェクトの元の名前が表示され、RECYCLEBIN NAME列には、ごみ箱内でのオブジェクトの名前が表示されます。

また、USER_RECYCLEBINまたはDBA_RECYCLEBINを問い合せて表の名前を取得することもできます。次の例では、ビューを問い合せて、削除されたオブジェクトの元の名前を確認します。

SELECT object_name AS recycle_name, original_name, type
FROM   recyclebin;

RECYCLE_NAME                      ORIGINAL_NAME          TYPE
--------------------------------  ---------------------  ----------
BIN$gk3lsj/3akk5hg3j2lkl5j3d==$0  EMPLOYEE_DEMO          TABLE
BIN$JKS983293M1dsab4gsz/I249==$0  I_EMP_DEMO             INDEX

依存オブジェクトの元の名前を手動でリストアする場合は、表をリストアする前に、各依存オブジェクトのごみ箱内のシステム生成の名前を書き留めておいてください。

注意:
DBA_TABLESなどのオブジェクト・ビューには、ごみ箱オブジェクトは表示されません。

2. 必要に応じて、ごみ箱内の表を問い合せます。
問合せでは、オブジェクトの元の名前ではなく、オブジェクトのごみ箱内の名前を使用する必要があります。次の例では、BIN$KSD8DB9L345KLA==$0というごみ箱内の名前を持つ表を問い合せます。

SELECT *
FROM   "BIN$gk3lsj/3akk5hg3j2lkl5j3d==$0";

ごみ箱内の名前に特殊文字が含まれているため、引用符が必要です。

注意:
必要な権限を所有している場合は、ごみ箱内の表に対してフラッシュバック問合せを使用できますが、表の元の名前ではなく、ごみ箱内の名前を使用する必要があります。ごみ箱内のオブジェクトに対して、DMLまたはDDL文を使用することはできません。

3. 削除された表を取得します。
FLASHBACK TABLE ... TO BEFORE DROP文を使用します。次の例では、BIN$gk3lsj/3akk5hg3j2lkl5j3d==$0表をリストアし、その名前をhr.employee_demoに戻して、そのエントリをごみ箱から消去します。

FLASHBACK TABLE "BIN$gk3lsj/3akk5hg3j2lkl5j3d==$0" TO BEFORE DROP;

ごみ箱内のオブジェクト名に特殊文字が含まれる可能性があるため、表の名前が引用符で囲まれています。

また、次のようにして、表の元の名前を使用することもできます。

FLASHBACK TABLE HR.EMPLOYEE_DEMO TO BEFORE DROP;

RENAME TO句を指定することによって、リストアされた表に新しい名前を割り当てることもできます。次に例を示します。

FLASHBACK TABLE "BIN$KSD8DB9L345KLA==$0" TO BEFORE DROP
RENAME TO hr.emp_demo;

4. 必要に応じて、すべての依存オブジェクトがごみ箱内のシステム生成の名前を保持していることを確認します。
次の問合せによって、取得されたhr.employee_demo表の索引の名前を確認します。

SELECT INDEX_NAME
FROM   USER_INDEXES
WHERE  TABLE_NAME = 'EMPLOYEE_DEMO';

INDEX_NAME
------------------------------
BIN$JKS983293M1dsab4gsz/I249==$0

5. 必要に応じて、取得された索引を元の名前に変更します。
次の文を実行すると、索引がその元の名前であるi_emp_demoに変更されます。

ALTER INDEX "BIN$JKS983293M1dsab4gsz/I249==$0" RENAME TO I_EMP_DEMO;

6. 取得された表に、ごみ箱に配置される前に参照制約が含まれていた場合は、その参照制約を再作成します。
ごみ箱では表に対する参照制約が保存されないため、この手順は手動で実行する必要があります。

元の名前が同じオブジェクトが複数存在する場合のオブジェクトの取出し

複数のオブジェクトを同じ元の名前で作成し、その後削除できます。削除されたすべてのオブジェクトは、ごみ箱に保存されます。たとえば、次の例のSQL文について考えてみます。

例18-1 同じ名前の複数オブジェクトの削除

CREATE TABLE temp_employees ( ...columns ); # temp_employees version 1
DROP TABLE temp_employees;

CREATE TABLE temp_employees ( ...columns ); # temp_employees version 2
DROP TABLE temp_employees;

CREATE TABLE temp_employees ( ...columns ); # temp_employees version 3
DROP TABLE temp_employees;

例18-1では、temp_employees表が削除されるたびに、ごみ箱の中でそれぞれに一意の名前が割り当てられています。次の例に示すように、FLASHBACK TABLE ... TO BEFORE DROP文は、表の元の名前を指定して使用できます。

FLASHBACK TABLE temp_employees TO BEFORE DROP;

この元の名前で最後に削除された表は、その元の名前でごみ箱から取得されます。例18-2では、前の例で削除された3つすべてのtemp_employees表が、それぞれ新しい名前を割り当てられてごみ箱から取得されています。

例18-2 削除された表の名前の変更

FLASHBACK TABLE temp_employees TO BEFORE DROP
RENAME TO temp_employees_VERSION_3;
FLASHBACK TABLE temp_employees TO BEFORE DROP
RENAME TO temp_employees_VERSION_2;
FLASHBACK TABLE temp_employees TO BEFORE DROP
RENAME TO temp_employees_VERSION_1;

FLASHBACK TABLEでの元の名前はこの名前で最後に削除された表を参照するため、最後に削除された表が最初に取得されます。

また、元の名前が競合している場合でも、ごみ箱内の一意の名前を使用して、すべての表をごみ箱から取得することができます。たとえば、ごみ箱を次のように問い合せます(出力例も示します)。

SELECT object_name, original_name, createtime
FROM   recyclebin;

OBJECT_NAME                    ORIGINAL_NAME   CREATETIME
------------------------------ --------------- -------------------
BIN$yrMKlZaLMhfgNAgAIMenRA==$0 TEMP_EMPLOYEES  2007-02-05:21:05:52
BIN$yrMKlZaVMhfgNAgAIMenRA==$0 TEMP_EMPLOYEES  2007-02-05:21:25:13
BIN$yrMKlZaQMhfgNAgAIMenRA==$0 TEMP_EMPLOYEES  2007-02-05:22:05:53

次のコマンドを使用すると、中間の表を取得できます。

FLASHBACK TABLE BIN$yrMKlZaVMhfgNAgAIMenRA==$0 TO BEFORE DROP;

関連項目:

- フラッシュバック・ドロップを使用する方法およびごみ箱を管理する方法については、『Oracle Database管理者ガイド』を参照してください。

- FLASHBACK TABLE文の詳細は、『Oracle Database SQL言語リファレンス』を参照してください。

フラッシュバック・データベースを使用したデータベースの巻戻し

この項では、フラッシュバック・データベースを使用して、データベースに対する不要な変更を巻き戻す最も一般的な例について説明します。

フラッシュバック・データベースの前提条件

FLASHBACK DATABASEコマンドを使用してデータベースの内容をフラッシュバック・ウィンドウ内の時点まで戻すには、「フラッシュバック・データベース、リストア・ポイントおよび保証付きリストア・ポイントについて」の説明に従って、フラッシュバック・ロギングを行うようにデータベースを構成する必要があります。保証付きリストア・ポイントまでデータベースを戻すには、「通常のリストア・ポイントと保証付きリストア・ポイントの使用」の説明に従って、保証付きリストア・ポイントを定義しておく必要があります。

フラッシュバック・データベースでは、コマンド実行時に存在した、データファイルに対する変更が取り消されます。重要な前提条件は、次のとおりです。

- 現行のデータファイルが消失または破損していないこと。FLASHBACK DATABASEは、Oracle Databaseで行われたデータファイルに対する変更の巻戻しにのみ使用できます。メディア障害の修復には使用できません。

- データファイルの誤った削除からのリカバリ、データファイルの縮小操作の取消しまたはデータベース名の変更の取消しをしようとしていないこと。

- 制御ファイルのリストアまたは再作成前の時点に戻すためにFLASHBACK DATABASEを使用しようとしていないこと。データベース制御ファイルがバックアップからリストアされるか、または再作成されると、すべての累積フラッシュバック・ログ情報が破棄されます。

- 互換性の変更を取り消すためにFLASHBACK DATABASEを使用しようとしていないこと。

関連項目:
FLASHBACK DATABASEのコマンドの前提条件および使用方法の詳細は、『Oracle Databaseバックアップおよびリカバリ・リファレンス』を参照してください。

フラッシュバック・データベース操作の実行

この項では、時刻書式、通常のリストア・ポイントまたは保証付きリストア・ポイントの名前、あるいはSCNを使用して目的の目標時点を指定し、データベースのフラッシュバックを実行する基本的な方法について説明します。

次の例では、現行のデータベースのインカネーション内の時点までデータベースを巻戻すと想定しています。最後のOPEN RESETLOGSの直前の時点までデータベースを戻す場合は、「フラッシュバック・データベースを使用したOPEN RESETLOGS操作の巻戻し」を参照してください。

デフォルトでは、FLASHBACK DATABASEコマンドで使用されるSCNは、データベース・インカネーションの直系祖先パス内のSCNを参照します。「データベース・インカネーション」で説明されているように、データベースを以前にRESETLOGSオプションでオープンした後で取り消さなかった場合、インカネーションはこのパス内にあります。取り消されたインカネーション内の変更を取得する場合は、「取り消されたインカネーション・ブランチ内のSCNへのデータベースの巻戻し」を参照してください。

フラッシュバック・データベース操作を行う手順

1. SQL*Plusをターゲット・データベースに接続し、FLASHBACK DATABASEコマンドに必要なSCN、リストア・ポイントまたは時点を確認します。
次のように入力して、フラッシュバック・データベース・ウィンドウ内の最も古いSCNを取得します。

SELECT OLDEST_FLASHBACK_SCN, OLDEST_FLASHBACK_TIME
FROM   V$FLASHBACK_DATABASE_LOG;

フラッシュバック・データベースで到達できる最新のSCNは、データベースの現行のSCNです。次の問合せを実行すると、現行のSCNが戻されます。

SELECT CURRENT_SCN
FROM   V$DATABASE;

使用可能な保証付きリストア・ポイントは、次のように問い合せることができます(出力例も示します)。

SELECT NAME, SCN, TIME, DATABASE_INCARNATION#,
GUARANTEE_FLASHBACK_DATABASE
FROM   V$RESTORE_POINT
WHERE  GUARANTEE_FLASHBACK_DATABASE='YES';

NAME                   SCN TIME                  DATABASE_INCARNATION# GUA
--------------- ---------- --------------------- --------------------- ---
BEFORE_CHANGES     5753126 04-MAR-05 12.39.45 AM                     2 YES

注意:
フラッシュバック・ウィンドウが目的の目標時点に達する過去の時点まで提供されておらず、その目的の時点での保証付きリストア・ポイントが存在しない場合は、同じ結果を得るために、データベースのPoint-in-Timeリカバリを使用できます。詳細は、「データベースのPoint-in-Timeリカバリの実行」を参照してください。

2. データベースを、一貫性のある状態で停止し、インスタンスによってオープンされていないことを確認してからマウントします。

SHUTDOWN IMMEDIATE;
STARTUP MOUNT;

3. 手順1で実行した問合せを繰り返します。
データベースが停止されている場合は、一部のフラッシュバック・ロギング・データが生成されます。高速リカバリ領域での領域圧迫が原因でフラッシュバック・ログが削除された場合は、目的のSCNが取得不可になっている可能性があります。

注意:
目的のSCNがフラッシュバック・ウィンドウの範囲外にある場合にFLASHBACK DATABASEを実行すると、FLASHBACK DATABASEは失敗し、ORA-38729エラーが戻されます。この場合、データベースは変更されません。

4. RMANを起動し、ターゲット・データベースに接続します。

5. SHOWコマンドを実行して、事前構成済のチャネルを確認します。
フラッシュバック操作中、RMANは、バックアップからアーカイブREDOログをリストアする必要がある場合があります。次のコマンドを入力し、自動チャネルが構成されているかどうかを確認します(出力例も示します)。

SHOW ALL;

RMAN configuration parameters for database with db_unique_name PROD1 are:
.
.
.
CONFIGURE DEFAULT DEVICE TYPE TO DISK; # default
CONFIGURE DEVICE TYPE DISK PARALLELISM 1 BACKUP TYPE TO BACKUPSET; # default
CONFIGURE DEVICE TYPE SBT_TAPE PARALLELISM 1 BACKUP TYPE TO BACKUPSET; # default
CONFIGURE CHANNEL DEVICE TYPE 'SBT_TAPE' PARMS  "SBT_LIBRARY=/usr/local/oracle/backup/lib/libobk.so";

必要なデバイスおよびチャネルがすでに構成されている場合、操作は必要ありません。そうでない場合は、CONFIGUREコマンドを使用して自動チャネルを構成するか、またはRUNブロック内にALLOCATE CHANNELコマンドを含めます。

6. RMANのFLASHBACK DATABASEコマンドを実行します。
次の例に示すいずれかの形式のコマンドを使用して、目標時点を指定できます。

FLASHBACK DATABASE TO SCN 46963;

FLASHBACK DATABASE
TO RESTORE POINT BEFORE_CHANGES;

FLASHBACK DATABASE TO TIME
"TO_DATE('09/20/05','MM/DD/YY')";

FLASHBACK DATABASEコマンドが完了すると、データベースはマウントされたまま、指定した目標時点にリカバリされています。

7. SQL*Plusを使用してデータベースを読取り専用でオープンし、いくつかの問合せを実行して、データベースの内容を検証します。
次のように入力して、データベースを読取り専用でオープンします。

ALTER DATABASE OPEN READ ONLY;

データベースの状態が適切である場合は、手順8で手順を終了します。データベースの状態が適切でない場合は、手順9に進みます。

8. 結果が適切である場合は、相互に排他的な次の処理のいずれかを実行します。

- RESETLOGSオプションを指定してデータベースをオープンし、データベースを更新可能な状態にします。データベースが現在読取り専用でオープンされている場合は、SQL*Plusで次のコマンドを実行します。

SHUTDOWN IMMEDIATE
STARTUP MOUNT
ALTER DATABASE OPEN RESETLOGS;

注意:
このOPEN RESETLOGS操作を実行した後、FLASHBACK DATABASEの目的のSCN以降に行われたデータベースへの変更はすべて破棄されます。ただし、「取り消されたインカネーション・ブランチ内のSCNへのデータベースの巻戻し」に示す方法を使用すると、複数のSCNがフラッシュバック・ウィンドウ内にあるかぎり、データベースをそれぞれのSCNの範囲まで戻すことができます。

- Oracle Data Pump Exportを使用し、破損状態のオブジェクトの論理バックアップを行います。その後、RMANを使用して、データベースを現在の時刻までリカバリします。

RECOVER DATABASE;

この手順では、REDOログ内のすべての変更をデータベースに適用してフラッシュバック・データベースの影響を取り消し、データベースを最新のSCNまで戻します。

データベースを読取り/書込みでオープンした後、データ・ポンプ・インポート・ユーティリティを使用してエクスポートされたオブジェクトをインポートできます。データ・ポンプを使用する方法の詳細は、『Oracle Databaseユーティリティ』を参照してください。

9. フラッシュバックで誤ったリストア・ポイント、時刻またはSCNを使用した場合は、データベースをマウントし、次の相互に排他的ないずれかのオプションを実行します。

- 選択した目標時点が十分に前の時点でなかった場合は、別のFLASHBACK DATABASEコマンドを使用し、データベースをさらに巻き戻します。

FLASHBACK DATABASE TO SCN 42963;  #earlier than current SCN

- 選択した目的のSCNが前過ぎる場合は、RECOVER DATABASE UNTILを使用してデータベースを必要なSCNまで進めます。

RECOVER DATABASE UNTIL SCN 56963; #later than current SCN

- FLASHBACK DATABASEコマンドの影響を完全に取り消す必要がある場合は、UNTIL句またはSET UNTILコマンドを指定しないでRECOVER DATABASEコマンドを使用することによって、データベースの完全リカバリを実行できます。

RECOVER DATABASE;

RECOVER DATABASEコマンドを実行すると、すべての変更がデータベースに再適用され、データベースが最新のSCNまで戻されます。

フラッシュバック・データベースの監視

フラッシュバック・データベースを使用してデータベースを過去の目標時点に巻き戻す場合、目標時点以降に変更されたブロックが判別され、フラッシュバック・ログからリストアされます。これをリストア・フェーズと呼びます。このフェーズの完了後、フラッシュバック・データベースでは、REDOログを使用して、これらのブロックがフラッシュバック・ログに書き込まれた後に行われた変更が再適用されます。これをリカバリ・フェーズと呼びます。

リストア・フェーズ中のフラッシュバック・データベースの進捗状況は、V$SESSION_LONGOPSビューを問い合せることによって監視できます。opnameはFlashback Databaseです。TOTALWORK列の下には、読み取る必要があるフラッシュバック・ログのMB数が表示されます。例18-3に示すSOFAR列には、現在までに読み取られたMB数が表示されます。

例18-3 フラッシュバック・データベースの進捗状況の追跡(リストア・フェーズ)

SQL> select sofar, totalwork, units from v$session_longops where opname = 'Flashback Database';

SOFAR  TOTALWORK  UNITS
-----  ---------- --------------------------------
17          60 Megabytes

リカバリ・フェーズ中のフラッシュバック・データベースの進捗状況は、V$RECOVERY_PROGRESSビューを問い合せることによって監視できます。

関連項目:
ビューV$RECOVERY_PROGRESSの詳細は、『Oracle Databaseリファレンス』を参照してください。

データベースのPoint-in-Timeリカバリの実行

RMANのDBPITRを実行すると、リカバリの目標時点より前のバックアップからデータベースがリストアされ、増分バックアップおよびREDOを使用してデータベースが目標時点までロールフォワードされます。SCN、時刻、ログ順序番号またはリストア・ポイントまでのリカバリを行うことができます。必要になった場合にPoint-in-Timeリカバリをより管理しやすい状態にしておくために、重要な時刻にリストア・ポイントを作成しておくことをお薦めします。

可能な場合は、データベースのPoint-in-Timeリカバリではなく、フラッシュバック・データベースを実行することをお薦めします。バックアップを使用したメディア・リカバリは、最後に行った変更を取り消すためにフラッシュバックを使用できない場合の最後の手段として使用してください。

データベースのPoint-in-Timeリカバリの前提条件

データベースのPoint-in-Timeリカバリの前提条件は、次のとおりです。

- データベースはARCHIVELOGモードで実行されている必要があります。

- DBPITRの目的のSCNより前のすべてのデータファイルのバックアップ、およびバックアップのSCNと目的のSCNの間の期間のアーカイブ・ログが存在している必要があります。

コマンドの前提条件および使用上の注意の詳細は、『Oracle Databaseバックアップおよびリカバリ・リファレンス』のRECOVERエントリに関する項を参照してください。

データベースのPoint-in-Timeリカバリの実行

この項では、DBPITRの基本手順について説明します。この手順では、次のことを想定しています。

- 現行のデータベースのインカネーション内で、DBPITRを実行します。目標時点が現行のインカネーション内に存在しない場合は、祖先インカネーションへのDBPITRについて、「祖先インカネーションへのデータベースのリカバリ」を参照してください。

- 制御ファイルは現行のものです。バックアップ制御ファイルをリストアする必要がある場合は、「バックアップ制御ファイルを使用したリカバリの実行」を参照してください。

- データベースでは、現行のサーバー・パラメータ・ファイルが使用されています。バックアップ・サーバー・パラメータ・ファイルをリストアする必要がある場合は、「サーバー・パラメータ・ファイルのリストア」を参照してください。

DBPITRを実行する場合は、RESTOREおよびRECOVERコマンドで個々にUNTIL句を指定するのではなく、SET UNTILコマンドを使用して目標時点を手順の最初に設定することによって、エラーを回避できます。これによって、バックアップからリストアされたデータファイルに十分に古いタイムスタンプが設定され、後続のRECOVER操作に使用できます。

DBPITRを実行する手順

1. リカバリを終了するSCN、リストア・ポイントまたはログ順序番号を決定します。
フラッシュバック問合せ機能を使用すると、論理的な破損が発生した時点を特定できます。表に対してフラッシュバック・データ・アーカイブが有効になっている場合は、非常に古いデータを問い合せることができます。

また、アラート・ログを使用して、リカバリする必要があるイベントの時刻を特定することもできます。

さらに、SQL問合せを使用して、目的のSCNが含まれているログ順序番号を特定し、このログを使用してリカバリすることもできます。たとえば、次の問合せを実行して、現行のデータベース・インカネーションのログを表示します(出力例も示します)。

SELECT RECID, STAMP, THREAD#, SEQUENCE#, FIRST_CHANGE#
FIRST_TIME, NEXT_CHANGE#
FROM   V$ARCHIVED_LOG
WHERE  RESETLOGS_CHANGE# =
( SELECT RESETLOGS_CHANGE#
FROM   V$DATABASE_INCARNATION
WHERE  STATUS = 'CURRENT');

RECID      STAMP      THREAD#    SEQUENCE#  FIRST_CHAN FIRST_TIM NEXT_CHANG
---------- ---------- ---------- ---------- ---------- --------- ----------
1  344890611          1          1      20037 24-SEP-05      20043
2  344890615          1          2      20043 24-SEP-05      20045
3  344890618          1          3      20045 24-SEP-05      20046

たとえば、ユーザーが誤って表領域を午前9時2分に削除したことがわかった場合は、削除が発生する直前の午前9時までリカバリを行うことができます。この時刻より後にデータベースに対して行われたすべての変更は消失します。

2. 目的のSCNではなく、目標の時刻書式を使用する場合は、RMANの起動前に時刻書式の環境変数が適切であることを確認します。
グローバリゼーション・サポート設定の例を次に示します。

NLS_LANG = american_america.us7ascii
NLS_DATE_FORMAT="Mon DD YYYY HH24:MI:SS"

3. RMANをターゲット・データベースに接続し、必要に応じてリカバリ・カタログにも接続します。データベースをマウント状態にします。

SHUTDOWN IMMEDIATE;
STARTUP MOUNT;

4. RUNブロック内で、次の操作を実行します。

1. SET UNTILを使用して、DBPITRの目標時点、リストア・ポイント、SCNまたはログ順序番号を指定します。時刻を指定する場合は、環境変数NLS_LANGおよびNLS_DATE_FORMATで指定した日付書式を使用します。

2. 自動チャネルを構成していない場合は、必要に応じて、ディスク・チャネルおよびテープ・チャネルを手動で割り当てます。

3. データベースをリストアおよびリカバリします。

次の例では、ターゲット・データベースでSCN 1000までDBPITRを実行します。

RUN
{
SET UNTIL SCN 1000;
RESTORE DATABASE;
RECOVER DATABASE;
}

また、次の例に示すように、時刻書式、リストア・ポイントまたはログ順序番号を使用して、SET UNTIL時刻を指定することもできます。

SET UNTIL TIME 'Nov 15 2004 09:00:00';
SET UNTIL SEQUENCE 9923;
SET UNTIL RESTORE POINT before_update;

操作がエラーを戻さずに完了した場合、DBPITRは正常に終了しています。

5. 次の相互に排他的ないずれかのアクションを実行します。

- データベースを読取り/書込みでオープンし、目的のSCN以降のすべての変更を取り消します。この場合は、データベースを停止し、マウントしてから、次のコマンドを実行する必要があります。

ALTER DATABASE OPEN RESETLOGS;

データファイルがオフラインになっていると、データファイルが正常にオフラインにされているか、または読取り専用である場合を除き、OPEN RESETLOGS操作が失敗します。RESETLOGSの実行後はREDOが不要になるため、読取り専用またはNORMALモードでオフラインにされた表領域のファイルをオンラインにすることができます。

- データ・ポンプ・エクスポートを使用してデータベースから1つ以上のオブジェクトをエクスポートします。次に、データベースを現在の時点までリカバリして、エクスポートされたオブジェクトを再インポートします。これによって、他のすべての変更を取り消さずにこれらのオブジェクトを不要な変更前の状態に戻すことができます。

フラッシュバックおよびデータベースのPoint-in-Timeリカバリの例

この項では、「フラッシュバック・データベースを使用したデータベースの巻戻し」および「データベースのPoint-in-Timeリカバリの実行」で説明されている基本例を少し変更した例について説明します。

フラッシュバック・データベースを使用したOPEN RESETLOGS操作の巻戻し

フラッシュバック・データベースを使用して不要なALTER DATABASE OPEN RESETLOGS文の結果を前の状態に戻すための手順は、「フラッシュバック・データベース操作の実行」で説明する通常の場合と類似しています。ただし、FLASHBACK DATABASEコマンドで特定のSCNまたは時点を指定するかわりに、FLASHBACK DATABASE TO BEFORE RESETLOGSを使用します。

OPEN RESETLOGS操作を取り消す手順

1. SQL*Plusをターゲット・データベースに接続し、フラッシュバック・ウィンドウの開始時点が最新のOPEN RESETLOGSより前であることを確認します。
次の問合せを実行します。

SELECT RESETLOGS_CHANGE#
FROM   V$DATABASE;

SELECT OLDEST_FLASHBACK_SCN
FROM   V$FLASHBACK_DATABASE_LOG;

V$DATABASE.RESETLOGS_CHANGE#がV$FLASHBACK_DATABASE_LOG.OLDEST_FLASHBACK_SCNより大きい場合は、Oracle Flashback Databaseを使用してOPEN RESETLOGSを前の状態に戻すことができます。

2. データベースを停止してマウントし、フラッシュバック・ウィンドウを再確認します。RESETLOGS SCNがまだフラッシュバック・ウィンドウ内にある場合は、次の手順に進みます。

3. RMANをターゲット・データベースに接続し、RESETLOGSの直前のSCNまでフラッシュバックを実行します。
次の形式のFLASHBACK DATABASEコマンドを使用します。

FLASHBACK DATABASE TO BEFORE RESETLOGS;

FLASHBACK DATABASEの他の使用例と同様に、ターゲットSCNがフラッシュバック・データベース・ウィンドウの開始時点より前である場合は、エラーが戻され、データベースは変更されません。コマンドが正常終了した場合、データベースはマウントされたまま、以前のインカネーションでOPEN RESETLOGSが実行される前の最新のSCNまでリカバリされます。

4. SQL*Plusを使用してデータベースを読取り専用でオープンし、必要に応じて問合せを実行して、論理的な破損の影響が無効にされたことを確認します。
次のように入力して、データベースを読取り専用でオープンします。

ALTER DATABASE OPEN READ ONLY;

5. データベースを再度更新できるようにするには、データベースを停止してマウントしてから、次のコマンドを実行します。

ALTER DATABASE OPEN RESETLOGS;

フラッシュバック・データベースを使用したスタンバイ・データベースでのOPEN RESETLOGSの取消し

OPEN RESETLOGSをまたぐフラッシュバック・データベースは、Data Guard環境で次の機能を実現するために使用できます。

- ロジカル・スタンバイ・スイッチオーバーを取り消すためのフラッシュバック
この場合、データベースは、フラッシュバック・データベース操作の目標時点での役割(プライマリまたはスタンバイ)に戻されます。

- フィジカル・スタンバイのアクティブ化の取消し
一時的にフィジカル・スタンバイ・データベースをアクティブ化し、テストまたはレポートの目的で使用してから、フラッシュバック・データベースを使用してフィジカル・スタンバイとしての役割に戻すことができます。

- テスト目的でのスタンバイ・データベースの継続的な使用
フラッシュバック・データベースを使用すると、ストレージ・スナップショットを使用する必要がなくなります。

関連項目:
Data Guardでのフラッシュバック・データベースのこれらの高度な適用の詳細は、『Oracle Data Guard概要および管理』を参照してください。

取り消されたインカネーション・ブランチ内のSCNへのデータベースの巻戻し

フラッシュバック・データベースまたはDBPITRの後にOPEN RESETLOGSを使用すると、データベースが以前のSCNに戻され、その時点以降の変更が取り消されます。したがって、その時点以降の一部のSCNは、取り消された変更またはデータベースの現行の履歴にある変更のいずれかを参照できます。この方法では、FLASHBACK DATABASEで指定された目的のSCNが不明確になる可能性があります。

SCNとは異なり、時刻書式およびリストア・ポイントは不明確にはなりません。時刻書式は、常に、その時点の現行インカネーションに関連付けられています。リストア・ポイントは、常に、作成時の現行インカネーションに関連付けられています。これは、取り消されたデータベース・インカネーションに対応する時刻およびリストア・ポイントにも該当します。データベース・インカネーションは、指定した時刻またはリストア・ポイントの作成時の現行インカネーションに自動的に再設定されます。

フラッシュバック・データベースを使用して、現行のインカネーション・パスが古いインカネーションからブランチした時点のOPEN RESETLOGSのSCNより後の親インカネーション内の時点までデータベースを巻き戻す必要がある場合があります。OPEN RESETLOGSで新しいインカネーションを作成した後でも、インカネーション・ブランチでSCNを生成できる方法については、図14-1「データベース・インカネーションの履歴」を参照してください。この図に示されているように、インカネーション1内の取り消されたSCN 1500まで戻る必要がある場合、データベースはインカネーション3内のSCN 3000にある可能性があります。

巻き戻しているSCNが直系祖先パスにある場合、またはデータベースをリストア・ポイントまで巻き戻している場合は、明示的なRESET DATABASEはフラッシュバック・データベースに必要ありません。ただし、明示的なRESET DATABASE TO INCARNATIONコマンドは、FLASHBACK DATABASEを使用してデータベースを取り消されたデータベース・インカネーションのSCNに巻き戻す場合は必須です。

取り消されたインカネーション・ブランチ内のSCNまでデータベースを巻き戻す手順

1. SQL*Plusを使用してターゲット・データベースに接続し、SCNまでフラッシュバックするための十分な情報がフラッシュバック・ログに含まれていることを確認します。
たとえば、次の問合せを実行します。

SELECT OLDEST_FLASHBACK_SCN
FROM   V$FLASHBACK_DATABASE_LOG;

2. フラッシュバック・データベース操作のターゲット・インカネーション番号(親インカネーションのインカネーション・キー)を特定します。
たとえば、次の問合せを実行します。

SELECT PRIOR_INCARNATION#
FROM   V$DATABASE_INCARNATION
WHERE  STATUS = 'CURRENT';

3. RMANを起動し、ターゲット・データベースに接続します。

4. 次のように入力して、データベースを停止してからマウントします。

SHUTDOWN IMMEDIATE;
STARTUP MOUNT;

5. データベース・インカネーションを親インカネーションに設定します。
たとえば、次のコマンドを使用してインカネーション1に戻ります。

RESET DATABASE TO INCARNATION 1;

6. FLASHBACK DATABASEコマンドを実行し、目的のSCNを指定します。
たとえば、次のコマンドを使用して、データベースをSCN 1500まで巻き戻します。

FLASHBACK DATABASE TO SCN 1500;

7. SQL*Plusを使用してデータベースを読取り専用でオープンし、必要に応じて問合せを実行して、論理的な破損の影響が無効にされたことを確認します。
次のように入力して、データベースを読取り専用でオープンします。

ALTER DATABASE OPEN READ ONLY;

8. データベースを再度更新できるようにするには、データベースを停止してマウントしてから、次のコマンドを実行します。

ALTER DATABASE OPEN RESETLOGS;

関連項目:

- データベースのインカネーション、取り消された変更、およびALTER DATABASE OPEN RESETLOGSの影響に関する有効な基礎知識については、「データベース・インカネーション」を参照してください。

- RESET DATABASEコマンドの詳細は、『Oracle Databaseバックアップおよびリカバリ・リファレンス』を参照してください。

祖先インカネーションへのデータベースのリカバリ

現行のインカネーション内でのDBPITRの手順は、現行以外のインカネーション内のSCNへのDBPITRとは異なります。後者の場合は、明示的にRESET DATABASEを実行して、目的のSCNでの現行インカネーションにデータベースを再設定する必要があります。また、目的のSCNが含まれているデータベース・インカネーションから制御ファイルをリストアする必要があります。

RMANがリカバリ・カタログに接続されている場合にRESTORE CONTROLFILEコマンドを実行すると、UNTIL句で指定された時刻に最も近い時刻の現行のデータベース・インカネーションのみが検索されます。現行以外のインカネーションから制御ファイルをリストアするには、LIST INCARNATIONを実行し、ターゲット・データベースのインカネーションを特定して、RESET DATABASE TO INCARNATIONコマンドにこのインカネーションを指定する必要があります。

RMANがリカバリ・カタログに接続されている場合は、データベースをマウントする前にRESET DATABASE TO INCARNATIONコマンドを実行することはできません。したがって、SET UNTILを実行し、制御ファイルを自動バックアップからリストアしてマウントする必要があります。

次の状況を想定しています。

- RMANがリカバリ・カタログに接続されています。

- 2007年10月2日にターゲット・データベースtrgtのバックアップを実行しています。

- 2007年10月10日にこのデータベースに対してDBPITRを実行し、以前のエラーを修正しています。DBPITRの最後にOPEN RESETLOGS操作を実行して、新しいインカネーションを開始しています。

10月25日、2007年10月8日午前8時にデータベースから削除された重要なデータが必要であることが判明したとします。これは、現行のインカネーションの開始点より前の時刻です。

DBPITRを現行以外のインカネーションに実行する手順

1. RMANを起動し、ターゲット・データベースおよびリカバリ・カタログに接続します。

2. バックアップの時点での現行のデータベース・インカネーションを特定します。
LIST INCARNATIONを使用して、目標時点での現行のインカネーションの主キーを取得します。

LIST INCARNATION OF DATABASE trgt;

List of Database Incarnations
DB Key  Inc Key   DB Name   DB ID       STATUS     Reset SCN    Reset Time
------- -------   -------   ------      -------    ----------   ----------
1       2         TRGT      1224038686  PARENT     1            02-OCT-06
1       582       TRGT      1224038686  CURRENT    59727        10-OCT-06

Reset SCNおよびReset Time列を参照し、正しいインカネーションを特定して、Inc Key列内のインカネーション・キーを書き留めます。この例では、バックアップは2007年10月2日に実行されました。この場合、インカネーション・キーの値は2です。

3. データベースは起動されているが、マウントされていないことを確認します。

STARTUP FORCE NOMOUNT

4. ターゲット・データベースを、手順2で取得したインカネーションに再設定します。
この例では、10月2日のバックアップ時点での現行インカネーションを指定します。Inc Key列の値を使用して、インカネーションを識別します。

RESET DATABASE TO INCARNATION 2;

5. RUNコマンドで次の操作を実行して、データベースをリストアおよびリカバリします。

- リカバリの終了時刻を、データが消失する直前の時刻に設定します。

- 構成されていない必要なチャネルを割り当てます。

- 10月2日のバックアップから制御ファイルをリストアし、マウントします。

- データファイルをリストアし、データベースをリカバリします。RECOVER DATABASE ... UNTILコマンドを使用してDBPITRを実行し、データが消失する直前の10月8日午前7時55分の目標時点にデータベースを戻します。

次の例では、この場合に必要なすべての手順を示しています。

RUN
{
SET UNTIL TIME 'Oct 8 2007 07:55:00';
RESTORE CONTROLFILE;
# without recovery catalog, use RESTORE CONTROLFILE FROM AUTOBACKUP
ALTER DATABASE MOUNT;
RESTORE DATABASE;
RECOVER DATABASE;
}
ALTER DATABASE OPEN RESETLOGS;

関連項目:
RESET DATABASEコマンドの詳細は、『Oracle Databaseバックアップおよびリカバリ・リファレンス』を参照してください。

19 ブロック・メディア・リカバリの実行

この章では、データファイル内の個々のデータ・ブロックをリストアおよびリカバリする方法について説明します。この章の内容は次のとおりです。

- ブロック・メディア・リカバリの概要

- ブロック・メディア・リカバリの前提条件

- 個々のブロックのリカバリ

- V$DATABASE_BLOCK_CORRUPTION内のすべてのブロックのリカバリ

関連項目:

- RECOVERの構文については、『Oracle Databaseバックアップおよびリカバリ・リファレンス』を参照してください。

- V$DATABASE_BLOCK_CORRUPTIONビューの詳細は、『Oracle Databaseリファレンス』を参照してください。

ブロック・メディア・リカバリの概要

この項では、ブロック・メディア・リカバリの目的および基本的な概念について説明します。

ブロック・メディア・リカバリの目的

ブロック・メディア・リカバリを使用すると、データファイル内の1つ以上の破損したデータ・ブロックをリカバリできます。ブロック・メディア・リカバリには、データファイルのメディア・リカバリにはない次のようなメリットがあります。

- リカバリが必要なブロックのみがリストアおよびリカバリされるため、平均リカバリ時間(MTTR)が短くなります。

- リカバリ中、影響を受けるデータファイルをオンラインのままにしておくことができます。
ブロック・メディア・リカバリを使用しないと、1つのブロックが破損した場合でも、データファイルをオフラインにしてデータファイルのバックアップをリストアする必要があります。バックアップの作成後にデータファイルに対して生成されたすべてのREDOを適用する必要があります。メディア・リカバリが完了するまで、ファイル全体が使用不可となります。ブロック・メディア・リカバリを使用すると、実際にリカバリされているブロックのみがリカバリ中に使用不可となります。

ブロック・メディア・リカバリは、ブロックが少数でその数がわかっている場合に発生する物理的な破損の問題に特に有効です。ブロックレベルのデータ消失は、通常、広範囲なデータ消失は引き起こさない断続的でランダムなI/Oエラーや、破損したメモリーがディスクに書き込まれることが原因で発生します。ブロック・メディア・リカバリは、データの消失または破損の程度が不明で、データファイル全体のリカバリが必要な場合には適していません。このような場合は、データファイルのメディア・リカバリが最適です。

ブロック・メディア・リカバリの基本的な概念

通常、データベースは、破損が最初に発生したときに、ブロックをメディア破損とマークし、ディスクに書き込みます。それ以降のブロックの読取りは、ブロックがリカバリされるまで正常に実行できません。ブロック・リカバリは、破損とマークされたブロックまたは破損チェックが失敗したブロックに対してのみ実行できます。

破損が発生したデータベースがリアルタイム問合せのフィジカル・スタンバイ・データベースに関連付けられている場合、データベースは、自動的にブロック・メディア・リカバリを実行します。プライマリ・データベースは、スタンバイ・データベースで完全な状態に近いブロックのコピーを検索し、見つかった場合は、破損ブロックが発生した問合せに影響を与えることなくブロックを修復します。データベースが破損を修復できない場合のみ、Oracle Databaseの物理ブロック破損のメッセージ(ORA-1578)が表示されます。

ブロックの破損が自動的に検出されると、RECOVER ... BLOCKコマンドを使用してブロック・メディア・リカバリを手動で実行できます。デフォルトでは、RMANは、リアルタイム問合せのフィジカル・スタンバイ・データベース内の完全な状態に近いブロックを検索し、次にフラッシュバック・ログを検索してから、全体またはレベル0の増分バックアップ内のブロックを検索します。

注意:
ブロック・メディア・リカバリを自動的に機能させるには、フィジカル・スタンバイ・データベースをリアルタイム問合せモードにする必要があります。Oracle Active Data Guardライセンスが必要です。

リアルタイム問合せのフィジカル・スタンバイ・データベースで破損データ・ブロックが検出された場合、サーバーは、プライマリ・データベースからブロックのコピーを取得することによって破損の修復を試行します。修復はバックグラウンドで行われ、正常に実行されると、それ以降の問合せが正常に実行されます。スタンバイ・データベースに、次のデータベース初期化パラメータが説明のように構成されている場合、自動ブロック修復が試行されます。

- LOG_ARCHIVE_CONFIGパラメータがDG_CONFIGリスト付きで構成され、LOG_ARCHIVE_DEST_nパラメータがDB_UNIQUE_NAME属性付きでプライマリ・データベース用に構成されている
または

- FAL_SERVERパラメータが構成され、その値にプライマリ・データベース用のOracle Netサービス名が含まれている

注意:
RMANのVALIDATEコマンドなどによって、検証中に破損ブロックが検出された場合、リカバリは自動的に開始されません。

関連項目:

- RECOVER ... BLOCKの構文については、『Oracle Databaseバックアップおよびリカバリ・リファレンス』を参照してください。

- スタンバイ・データベースのリアルタイム問合せオプションについては、『Oracle Data Guard概要および管理』を参照してください。

破損ブロックの識別

V$DATABASE_BLOCK_CORRUPTIONビューに、RMAN、ANALYZE、dbv、SQL問合せなどのデータベース・コンポーネントによって破損とマークされたブロックが表示されます。次のタイプの破損が、このビューに行として追加されます。

- 物理的な破損(メディア破損とも呼ばれる)
ブロックがデータベースで認識されません。チェックサムが無効か、ブロックの内容がすべて0(ゼロ)か、またはブロック・ヘッダーが破損しています。

物理的な破損のチェックは、デフォルトで有効になっています。BACKUPコマンドのNOCHECKSUMオプションを指定することによってチェックサムのチェックを無効にすることはできますが、ブロック・ヘッダーやフッターのチェックなどの他の物理的な一貫性チェックを無効にすることはできません。

- 論理的な破損
ブロックのチェックサムが有効で、ヘッダーとフッターが一致している点などは正常ですが、内容が論理的に一貫性のない状態になっています。ブロック・メディア・リカバリでは、すべての論理ブロック破損を修復できない場合があります。これらの場合、表領域のPoint-in-Timeリカバリなどの代替リカバリ方法、または影響を受けたオブジェクトの削除と再作成によって破損を修復する場合があります。

論理的な破損のチェックは、デフォルトでは無効になっています。BACKUP、RESTORE、RECOVERおよびVALIDATEコマンドのCHECK LOGICALオプションを指定することによって、有効にすることができます。

データベースは、ブロックとセグメント間の関係を検証することによって一部の破損を検出することはできますが、個々のブロックのチェックによって検出することはできません。V$DATABASE_BLOCK_CORRUPTIONビューには、この粒度レベルでは記録されません。

ブロック・リカバリ時に欠落しているREDO

データファイルのメディア・リカバリと同様に、ブロック・メディア・リカバリでも通常は、アーカイブ・ログが欠落しているか、またはアクセスできない場合はリカバリを実行できません。ただし、アーカイブREDOログ・ファイルの使用可能なコピーが検出された場合は、リストア・フェイルオーバーが試行されます(「リストア・フェイルオーバー」を参照)。 また、ブロック・メディア・リカバリでは、チェックサム障害となる物理的なREDOの破損がある場合はリカバリを実行できません。ただし、ブロック・メディア・リカバリでは、REDOストリームが連続していない場合に、欠落または破損しているREDOレコードがリカバリするブロックに影響しなければ、リカバリを実行できます。データファイルのリカバリには、リカバリの開始から終了まで連続した一連のREDO変更が必要ですが、ブロック・メディア・リカバリでは、リカバリするブロックに対してのみ、連続した一連のREDO変更が必要です。

注意:
ブロック・メディア・リカバリ中、各ブロックは別々にリカバリされるため、一部のブロックでのみリカバリが正常に行われる場合があります。

RMANは、ブロック・メディア・リカバリ中に欠落または破損しているREDOレコードを初めて検出した際、すぐにはエラーを通知しません。これは、リカバリ中のブロックによってこの後のREDOストリームでブロックが作成される場合があるためです。ブロックが再作成されると、それ以前のREDOはブロックの古いインカネーションに適用されていたことになるため、それまでのすべてのREDOは無関係になります。たとえば、ユーザーが表を削除するか、または切り捨ててから、ブロックを他のデータに対して使用した場合、データベースは新しいブロックを作成します。

図19-1に示すように、メディア・リカバリがブロック13で実行されるとします。

図19-1 RMANのメディア・リカバリの実行

ブロック・リカバリの開始後、RMANは、変更120がREDOストリームから欠落していることを検出します。ログ・ブロックが破損しているか、またはログを検出できないためです。ブロック13はこの後のREDOストリームで再作成されると想定されるため、RMANはリカバリを続行します。変更140で、ユーザーが、ブロック13に格納されているemployees表を削除し、このブロックで新しい表を割り当て、新しい表にデータを挿入したとします。この時点で、データベースはブロック13を新しいブロックとしてフォーマットします。これで、再作成操作の前の一部のREDOが欠落していた場合でも、このブロックでリカバリを続行できるようになります。

ブロック・メディア・リカバリの前提条件

次の前提条件がRECOVER ... BLOCKコマンドに適用されます。

- ターゲット・データベースがARCHIVELOGモードで実行されており、現行の制御ファイルを使用してオープンまたはマウントされている必要があります。

- ターゲット・データベースがスタンバイ・データベースの場合は、データベースが一貫性のある状態で、リカバリが開始されておらず、バックアップは破損したファイルよりも古いものである必要があります。

- 破損ブロックが含まれているデータファイルのバックアップは、プロキシ・コピーではなく全体またはレベル0のバックアップである必要があります。
プロキシ・コピー・バックアップのみが存在する場合は、それらをディスク上のデフォルト以外の場所にリストアできます。この場合、RMANは、プロキシ・バックアップをデータファイルのコピーとみなして、ブロック・メディア・リカバリ中にプロキシ・バックアップ内のブロックを検索します。

- RMANは、リカバリでアーカイブREDOログのみを使用できます。
RMANは、レベル1の増分バックアップを使用できません。ブロック・メディア・リカバリでは、アーカイブREDOログが欠落しているか、またはアクセスできない場合はリカバリを実行できません。ただし、REDOレコードが欠落している場合はリカバリを実行できる場合もあります。

- RMANがフラッシュバック・ログで破損ブロックの完全な状態に近いコピーを検索するには、フラッシュバック・データベースがターゲット・データベースで有効になっている必要があります。
破損していない古いバージョンの破損ブロックが含まれている場合にフラッシュバック・ロギングが有効になっていると、RMANは、それらのブロックを使用し、リカバリに必要な時間を短縮できます。

- RMANがデータベースで破損ブロックの完全な状態に近いコピーを検索するには、ターゲット・データベースがリアルタイム問合せのフィジカル・スタンバイ・データベースに関連付けられている必要があります。

個々のブロックのリカバリ

通常、ブロック破損は次の場所に表示されます。

- LIST FAILURE、VALIDATEまたはBACKUP ... VALIDATEコマンドの結果

- V$DATABASE_BLOCK_CORRUPTIONビュー

- 標準出力のエラー・メッセージ

- アラート・ログ

- ユーザー・トレース・ファイル

- SQLコマンドANALYZE TABLEおよびANALYZE INDEXの結果

- DBVERIFYユーティリティの結果

- サード・パーティのメディア管理の出力

たとえば、ユーザー・トレース・ファイルに次のメッセージが表示される場合があります。

ORA-01578: ORACLE data block corrupted (file # 7, block # 3)
ORA-01110: data file 7: '/oracle/oradata/trgt/tools01.dbf'
ORA-01578: ORACLE data block corrupted (file # 2, block # 235)
ORA-01110: data file 2: '/oracle/oradata/trgt/undotbs01.dbf'

次の手順では、リカバリが必要なブロックを識別し、使用可能なすべてのバックアップを使用してこれらのブロックをリストアおよびリカバリします。

特定のデータ・ブロックをリカバリする手順

1. 破損ブロックのデータファイル番号およびブロック番号を取得します。
トレース・ファイルおよびアラート・ログを検索する最も簡単な方法は、SQL*Plusをターゲット・データベースに接続し、次の問合せを実行する方法です。

SELECT NAME, VALUE
FROM   V$DIAG_INFO;

2. RMANを起動し、ターゲット・データベースに接続します。ターゲット・データベースは、マウントまたはオープンされている必要があります。

3. SHOW ALLコマンドを実行して、適切なチャネルが事前構成されていることを確認します。

4. RMANプロンプトで、ファイルおよび破損ブロックのブロック番号を指定してRECOVER ... BLOCKコマンドを実行します。
次の例では、2つのブロックをリカバリします。

RECOVER
DATAFILE 8 BLOCK 13
DATAFILE 2 BLOCK 19;

RMANの動作を制御する様々なオプションを指定することもできます。次の例は、ブロックの検索時にタグmondayamが含まれているバックアップのみが使用されることを示しています。FROM BACKUPSETオプションを使用して、RMANによって検索されるバックアップのタイプを制限できます。または、EXCLUDE FLASHBACK LOGオプションを使用して、RMANによるフラッシュバック・ログの検索を制限できます。

RECOVER
DATAFILE 8 BLOCK 13
DATAFILE 2 BLOCK 199
FROM TAG mondayam;

V$DATABASE_BLOCK_CORRUPTION内のすべてのブロックのリカバリ

この例では、RMANがV$DATABASE_BLOCK_CORRUPTIONビューに表示されているすべてのブロックを自動的にリカバリします。

V$DATABASE_BLOCK_CORRUPTIONに記録されているすべてのブロックをリカバリする手順

1. SQL*Plusを起動し、ターゲット・データベースに接続します。

2. V$DATABASE_BLOCK_CORRUPTIONを問い合せて、破損ブロックが存在するかどうかを確認します。たとえば、次の文を実行します。

SQL> SELECT * FROM V$DATABASE_BLOCK_CORRUPTION;

3. RMANを起動し、ターゲット・データベースに接続します。

4. V$DATABASE_BLOCK_CORRUPTION内の破損とマークされたすべてのブロックをリカバリします。
次のコマンドを実行すると、ビューに記録された物理的に破損しているすべてのブロックが修復されます。

RMAN> RECOVER CORRUPTION LIST;

ブロックは、修復された後、データベースによってV$DATABASE_BLOCK_CORRUPTIONから削除されます。

関連項目:
RECOVER ... BLOCKコマンドの詳細は、『Oracle Databaseバックアップおよびリカバリ・リファレンス』を参照してください。

20 RMANのリカバリの実行: 高度な例

先行の第V部「障害の診断および対応」の章は、最も基本的なリカバリの例についての一般的な説明となっています。この章では、基本的な例ほど一般的ではないか、またはより複雑な例について説明します。

この章の内容は次のとおりです。

- 増分バックアップを使用したNOARCHIVELOGモードのデータベースのリカバリ

- サーバー・パラメータ・ファイルのリストア

- バックアップ制御ファイルを使用したリカバリの実行

- 障害リカバリの実行

- 新しいホストへのデータベースのリストア

増分バックアップを使用したNOARCHIVELOGモードのデータベースのリカバリ

NOARCHIVELOGモードで実行されているデータベースのリストアは、ARCHIVELOGモードのデータベースのリストアと類似しています。主な違いを次に示します。

- NOARCHIVELOGモードでのデータベースのリストアでは、一貫性バックアップのみを使用できます。

- アーカイブREDOログが存在しないため、メディア・リカバリは実行できません。

増分バックアップを適用することによって、制限された変更のリカバリをNOARCHIVELOGモードで実行されているデータベースに実行できます。NOARCHIVELOGモードで実行されるデータベースのすべてのバックアップと同様に、増分バックアップは一貫性バックアップである必要があります。そのため、データベースのオープン時にデータベースのバックアップは作成できません。

NOARCHIVELOGデータベースをリカバリする場合は、RECOVERコマンドでNOREDOオプションを指定し、RMANがアーカイブREDOログの適用を試行しないように指定します。そうしない場合、RMANによってエラーが戻されます。

増分バックアップを使用して NOARCHIVELOG データベースをリカバリする手順

1. ターゲット・データベースおよびリカバリ・カタログに接続した後、データベースをマウント状態にします。

STARTUP FORCE MOUNT

2. データベースをリストアおよびリカバリします。
たとえば、次のコマンドで不完全リカバリを実行できます。

RESTORE DATABASE
FROM TAG "consistent_whole_backup";
RECOVER DATABASE NOREDO;

3. RESETLOGSオプションを指定してデータベースをオープンします。
たとえば、次のコマンドを入力します。

ALTER DATABASE OPEN RESETLOGS;

サーバー・パラメータ・ファイルのリストア

サーバー・パラメータ・ファイルが消失した場合は、RMANを使用して、デフォルトの場所または選択した場所にそのファイルをリストアできます。制御ファイルが消失した場合とは異なり、サーバー・パラメータ・ファイルが消失した場合、インスタンスはすぐに停止しません。インスタンスは継続して実行できます。ただし、サーバー・パラメータ・ファイルをリストアした後、インスタンスを停止して再起動する必要があります。

サーバー・パラメータ・ファイルをリストアする場合は、次の考慮事項に注意してください。

- インスタンスがサーバー・パラメータ・ファイルを使用してすでに起動されている場合、既存のサーバー・パラメータ・ファイルを上書きすることはできません。

- リストア・コマンドでTO句を使用せずにクライアント側の初期化パラメータ・ファイルを使用してインスタンスを起動すると、RMANによってサーバー・パラメータ・ファイルがデフォルトの場所にリストアされます。デフォルトの場所はプラットフォーム固有です。たとえば、Linuxでは?/dbs/spfile.oraです。

- リカバリ・カタログを使用すると、DBIDの記録および記憶を省略できるため、リカバリ手順が簡単になります。次の手順では、リカバリ・カタログを使用していないと想定しています。

自動バックアップからサーバー・パラメータ・ファイルをリストアする手順

1. RMANを起動し、次のいずれかを実行します。

- サーバー・パラメータ・ファイルが消失したときにデータベース・インスタンスが起動されていた場合は、ターゲット・データベースに接続します。

- サーバー・パラメータ・ファイルが消失したときにデータベース・インスタンスが起動されておらず、リカバリ・カタログを使用していない場合は、SET DBIDコマンドを実行してターゲット・データベースのDBIDを設定します。DBIDを決定する方法については、「データベースのDBIDの確認」を参照してください。

2. データベース・インスタンスを停止し、データベースをマウントせずに再起動します。
サーバー・パラメータ・ファイルを使用できない場合、RMANでは仮のパラメータ・ファイルを使用してインスタンスが起動されます。たとえば、次のコマンドを入力します。

STARTUP FORCE NOMOUNT;

3. RUNコマンドを実行してサーバー・パラメータ・ファイルをリストアします。
状況によっては、RUNコマンドで複数のコマンドを実行する必要がある場合もあります。次のことに注意してください。

- テープからリストアする場合は、ALLOCATE CHANNELを使用してSBTチャネルを手動で割り当てます。ディスクからリストアする場合は、RMANによってデフォルトのディスク・チャネルが使用されます。

- 自動バックアップがデフォルトの書式(%F)で生成されなかった場合は、SET CONTROLFILE AUTOBACKUP FOR DEVICE TYPEコマンドを使用して、自動バックアップの実行時に有効であった書式を指定します。

- 最新の自動バックアップが今日作成されなかった場合は、SET UNTILを使用して検索を開始する日付を指定します。

- RMANがリカバリ・カタログに接続されていない場合は、SET DBIDを使用してターゲット・データベースのDBIDを設定します。

- サーバー・パラメータ・ファイルをデフォルト以外の場所にリストアするには、RESTORE SPFILEコマンドでTO句またはTO PFILE句を指定します。

- RMANによって1日にn個を超える自動バックアップが生成されないことがわかっている場合は、RESTORE SPFILE FROM AUTOBACKUP ... MAXSEQパラメータにnを設定して、検索時間を短縮することができます。MAXSEQはデフォルトで255に設定されており、RESTOREはMAXSEQから逆算して、その日最後のバックアップを検索します。現在の日付(または指定した日付)の自動バックアップが検出されない場合にリストア操作を終了するには、RESTOREコマンドでMAXDAYS 1を設定します。

次の例では、テープ上の自動バックアップからサーバー・パラメータ・ファイルをリストアするRUNコマンドを示します。

RUN
{
ALLOCATE CHANNEL c1 DEVICE TYPE sbt PARMS ...;
SET UNTIL TIME 'SYSDATE-7';
SET CONTROLFILE AUTOBACKUP FORMAT
FOR DEVICE TYPE sbt TO '/disk1/control_files/autobackup_%F';
SET DBID 123456789;
RESTORE SPFILE
TO '/tmp/spfileTEMP.ora'
FROM AUTOBACKUP MAXDAYS 10;
}

4. リストアしたファイルを使用してデータベース・インスタンスを再起動します。
デフォルト以外の場所にあるサーバー・パラメータ・ファイルを使用してRMANを再起動する場合は、行SPFILE=new_locationを含む初期化パラメータ・ファイルを作成します。ここで、new_locationは、リストアされたサーバー・パラメータ・ファイルのパス名です。 次に、クライアント側の初期化パラメータ・ファイルを使用してインスタンスを再起動します。

たとえば、次の1行を含む/tmp/init.oraファイルを作成します。

SPFILE=/tmp/spfileTEMP.ora

次のRMANコマンドを使用すると、リストアされたサーバー・パラメータ・ファイルを使用してインスタンスを再起動できます。

STARTUP FORCE PFILE=/tmp/init.ora;

制御ファイルの自動バックアップからのサーバー・パラメータ・ファイルのリストア

制御ファイルの自動バックアップが構成されている場合は、自動バックアップが実行されるたびに、制御ファイルとともにサーバー・パラメータ・ファイルが常にバックアップされます。

制御ファイルの自動バックアップからサーバー・パラメータ・ファイルをリストアするには、まずデータベースのDBIDを設定し、次にRESTORE SPFILE FROM AUTOBACKUPコマンドを使用する必要があります。自動バックアップがデフォルト以外の書式である場合は、最初にSET CONTROLFILE AUTOBACKUP FORMATコマンドを使用して書式を指定します。

例20-1では、DBIDを設定し、デフォルト以外の場所にある制御ファイルの自動バックアップから、サーバー・パラメータをリストアします。

例20-1 制御ファイルの自動バックアップからのサーバー・パラメータ・ファイルのリストア

SET DBID 320066378;
RUN
{
SET CONTROLFILE AUTOBACKUP FORMAT
FOR DEVICE TYPE DISK TO 'autobackup_format';
RESTORE SPFILE FROM AUTOBACKUP;
}

RMANでは、自動バックアップの書式およびDBIDを使用して、制御ファイルの自動バックアップが検索されます。制御ファイルの自動バックアップが検出されると、RMANによってサーバー・パラメータ・ファイルがバックアップからデフォルトの場所にリストアされます。

autobackup_formatの適切な値を判断する方法については、『Oracle Databaseバックアップおよびリカバリ・リファレンス』のCONFIGUREコマンド用のエントリ内のCONFIGURE CONTROLFILE AUTOBACKUP FORMATについての説明を参照してください。

関連項目:
DBIDを決定する方法の詳細は、「データベースのDBIDの確認」を参照してください。

RMANを使用した初期化パラメータ・ファイルの作成

サーバー・パラメータ・ファイルは、TO PFILE 'filename'句を使用してクライアント側の初期化パラメータ・ファイルとしてリストアすることもできます。指定するファイル名は、RMANクライアントが実行されているホストからアクセス可能なファイル・システム上にあることを示している必要があります。このファイルは、インスタンスが実行されているホストから直接アクセス可能である必要はありません。

次のRMANコマンドを実行すると、RMANクライアントが実行されているシステム上に/tmp/initTEMP.oraという名前の初期化パラメータ・ファイルが作成されます。

RESTORE SPFILE TO PFILE '/tmp/initTEMP.ora';

初期化パラメータ・ファイルを使用してインスタンスを再起動するには、次のコマンドを使用して、同じクライアント・ホスト上でRMANを再度実行します。

STARTUP FORCE PFILE='/tmp/initTEMP.ora';

バックアップ制御ファイルを使用したリカバリの実行

この項では、現行のすべての制御ファイルが消失したため、バックアップ制御ファイルをリストアする必要がある場合に行う操作について説明します。

バックアップ制御ファイルを使用したリカバリの実行

現行のすべての制御ファイルのコピーが消失したか、または破損した場合は、バックアップ制御ファイルをリストアおよびマウントする必要があります。リストアされたデータファイルがない場合でも、RECOVERコマンドを実行し、RESETLOGSオプションを指定してデータベースをオープンする必要があります。ただし、現行の制御ファイルのいくつかのコピーを使用できる場合は、「現行の制御ファイルのサブセットが消失した場合の対応」の手順を実行し、リカバリおよびRESETLOGS操作の実行を回避できます。

RMANは、リカバリ時にRMANリポジトリに記録されていないオンライン・ログおよびアーカイブ・ログを自動的に検索し、検出したログをカタログに追加します。RMANは、現行のアーカイブ先で、現行のログ・フォーマットを持つすべての有効なアーカイブREDOログの検索を試行します。現行のフォーマットは、このインスタンス(またはOracle RAC構成のすべてのインスタンス)の起動に使用される初期化パラメータで指定されます。同様に、RMANは、制御ファイルに示されたファイル名を使用して、オンラインREDOログの検索を試行します。

リカバリ時にアーカイブ先またはフォーマットを変更したり、制御ファイルのバックアップの後に新しいオンライン・ログ・メンバーを追加すると、RMANで、必要なオンライン・ログまたはアーカイブ・ログを自動的にカタログに追加できなくなる場合があります。RMANでは、UNTIL時間を指定しなかった場合にオンラインREDOログを検出できないと、次のようなエラーが通知されます。

RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of recover command at 08/29/2007 14:23:09
RMAN-06054: media recovery requesting unknown log: thread 1 scn 86945

この場合、リカバリを続行するには、CATALOGコマンドを使用して必要なREDOログをリポジトリに手動で追加する必要があります。

関連項目:
様々な例(リカバリ・カタログの使用または特定のバックアップからのリストアなど)でRESTORE CONTROLFILEを使用する場合の制限の詳細は、『Oracle Databaseバックアップおよびリカバリ・リファレンス』のRESTORE CONTROLFILEについての説明を参照してください。

制御ファイルの場所

制御ファイルをリストアする場合、デフォルトのリストア先は、CONTROL_FILES初期化パラメータに定義されているすべての場所です。CONTROL_FILES初期化パラメータを設定しない場合、データベースは、CONTROL_FILESパラメータが設定されていないときに制御ファイルを作成する場合と同じ規則を使用して、リストアされた制御ファイルの格納先を決定します。これらの規則については、『Oracle Database SQL言語リファレンス』のCREATE CONTROLFILE文についての説明を参照してください。

1つ以上の新しい場所に制御ファイルをリストアするには、CONTROL_FILES初期化パラメータを変更した後、引数を指定せずにRESTORE CONTROLFILEを実行して制御ファイルをデフォルトの場所にリストアする方法があります。たとえば、CONTROL_FILESに定義されている場所の一部がディスク障害によって使用できなくなった後に制御ファイルをリストアする場合は、CONTROL_FILESで障害ディスクへの参照を別のディスクへのパス名に置き換えた後、引数を指定せずにRESTORE CONTROLFILEを実行します。

RESTORE CONTROLFILE TO 'filename'という形式を使用して、CONTROL_FILESに定義されている以外の任意の場所に制御ファイルをリストアすることもできます。

RESTORE CONTROLFILE TO '/tmp/my_controlfile';

現在使用中の制御ファイルは上書きされないため、この操作は、NOMOUNT、MOUNTまたはOPENの状態のデータベースで実行できます。'filename'という名前のすべての既存ファイルが上書きされます。制御ファイルを新しい場所にリストアした後、CONTROL_FILES初期化パラメータを更新して新しい場所を追加定義できます。

関連項目:
RESTORE CONTROLFILEの構文については、『Oracle Databaseバックアップおよびリカバリ・リファレンス』を参照してください。

リカバリ・カタログを使用したリカバリおよび使用しないリカバリ

RMANがリカバリ・カタログに接続している場合、バックアップ制御ファイルを使用したリカバリ手順は、現行の制御ファイルを使用したリカバリと同様になります。バックアップ制御ファイルで欠落しているRMANメタデータは、リカバリ・カタログで入手可能です。唯一の例外は、データベース名がカタログ内で一意でない場合です。この場合は、SET DBIDコマンドを使用してから制御ファイルをリストアする必要があります。

リカバリ・カタログを使用していない場合は、自動バックアップから制御ファイルをリストアする必要があります。自動バックアップから制御ファイルをリストアするには、データベースがNOMOUNT状態である必要があります。例20-2に示すように、まずデータベースのDBIDを設定し、次にRESTORE CONTROLFILE FROM AUTOBACKUPコマンドを使用する必要があります。

例20-2 DBIDの設定および自動バックアップからの制御ファイルのリストア

SET DBID 320066378;
RUN
{
SET CONTROLFILE AUTOBACKUP FORMAT
FOR DEVICE TYPE DISK TO 'autobackup_format';
RESTORE CONTROLFILE FROM AUTOBACKUP;
}

RMANでは、自動バックアップの書式およびDBIDを使用して、制御ファイルの自動バックアップを検索する場所が決定されます。制御ファイルの自動バックアップが検出されると、RMANによって、CONTROL_FILES初期化パラメータに示されているすべての制御ファイルの場所に制御ファイルがリストアされます。

関連項目:

- 自動バックアップの書式の適切な値を判断する方法については、『Oracle Databaseバックアップおよびリカバリ・リファレンス』のCONFIGURE用のエントリ内のCONFIGURE CONTROLFILE AUTOBACKUP FORMATについての説明を参照してください。

- DBIDを決定する方法については、「データベースのDBIDの確認」を参照してください。

高速リカバリ領域を使用している場合のリカバリ

制御ファイルをリストアするコマンドは、データベースで高速リカバリ領域が使用されているかどうかに関係なく同じです。データベースでリカバリ領域が使用されている場合、RMANは、すべてのディスクベースのバックアップおよび制御ファイルに記録されているイメージ・コピーをクロスチェックして、バックアップからリストアされた制御ファイルを更新します。RMANは、リカバリ領域内の記録されていないすべてのバックアップをカタログに追加します。この結果、リストアされた制御ファイルには、リカバリ領域内のすべてのバックアップ、およびバックアップの時点で制御ファイルに認識されたその他のバックアップの完全で正確なレコードが含まれます。

RMANは、制御ファイルをリストアした後、テープ・バックアップのクロスチェックを自動的には実行しません。テープ・バックアップを使用している場合は、制御ファイルをリストアおよびマウントできます。また、必要に応じてテープ上のバックアップをクロスチェックできます。次に例を示します。

CROSSCHECK BACKUP DEVICE TYPE sbt;

バックアップ制御ファイルを使用してリカバリ・カタログを使用しないリカバリの実行

この項では、制御ファイルのRMANバックアップを使用し、リカバリ・カタログは使用しないと想定しています。また、ターゲット・データベースの制御ファイルの自動バックアップ機能を有効にして、制御ファイルの自動バックアップをリストアできると想定しています。

自動バックアップでは標準的な書式が使用されるため、使用可能なバックアップを表示するリポジトリが存在しなくても、RMANは自動バックアップをリストアできます。自動バックアップはデフォルトの場所または新しい場所にリストアできます。RMANは、CONTROL_FILESで指定されたすべての場所に制御ファイルを自動的にレプリケートします。

注意:
(たとえば、メディア・マネージャによって、またはバックアップ・ピースがディスク上に存在するため)制御ファイルを含むバックアップ・ピースの名前がわかっている場合は、RESTORE CONTROLFILE FROM 'filename'コマンドを使用してバックアップ・ピースの名前を指定できます。データベースは、すべての自動バックアップの場所をアラート・ログに記録します。

リカバリ・カタログに接続していないため、RMANリポジトリには制御ファイルのバックアップの時点で使用可能なバックアップに関する情報のみが含まれます。他の使用可能なバックアップ・セットまたはイメージ・コピーの場所がわかっている場合は、CATALOGコマンドを使用して制御ファイルのRMANリポジトリに追加します。

NOCATALOGモードで制御ファイルの自動バックアップを使用してデータベースをリカバリする手順

1. RMANを起動し、ターゲット・データベースに接続します。

2. データベースをマウントせずにターゲット・データベース・インスタンスを起動します。次に例を示します。

STARTUP NOMOUNT;

3. SET DBIDコマンドを使用して、ターゲット・データベースのデータベース識別子を設定します。
ターゲット・データベースに接続するたびに、DBIDがRMANにより表示されます。保存されたRMANのログ・ファイルを調べるか、カタログを問い合せるか、または制御ファイルの自動バックアップのファイル名を検索することによって取得することもできます。たとえば、次のコマンドを実行します。

SET DBID 676549873;

4. 自動バックアップの制御ファイルをリストアしてリカバリを実行するためのRMANコマンド・ファイルを記述します。
このコマンド・ファイルには、次の手順が含まれている必要があります。

1. 必要に応じて、最新のバックアップのタイムスタンプを指定します。RMANは、リストアする制御ファイルの自動バックアップの検索時に、このタイムスタンプを使用できます。

2. 制御ファイルの自動バックアップの作成時に制御ファイルの自動バックアップの異なる書式が有効になっていたことがわかっている場合は、制御ファイルのリストアにデフォルト以外の書式を指定します。

3. SBTチャネルによって制御ファイルの自動バックアップが作成された場合は、1つ以上のSBTチャネルを割り当てます。使用可能なリカバリ・カタログがないため、事前構成されたチャネルは使用できません。

4. 必要に応じて、RMANが検索できる過去の最大日数および最初の日付の検索に使用する必要がある最初の順序番号を設定して、制御ファイルの自動バックアップをリストアします。

5. 残りのリストア・プロセスに有効な構成済のチャネルに関する情報が制御ファイルに含まれていることがわかっている場合は、RMANを終了し、手順cで行ったチャネルの手動割当てを解除できます。
RMANクライアントを再起動してデータベースをマウントする場合は、これらの構成済のチャネルを使用できます。制御ファイルに含まれている構成済のチャネルを使用しない場合は、データベースをマウントできます。

6. この手順は、オンラインREDOログが使用可能かどうかによって異なります。ログが使用可能かどうかに関係なく、バックアップ制御ファイルを使用してリカバリを行った後は、常にOPEN RESETLOGSオプションが必要となります。
オンラインREDOログが使用可能な場合、RMANはこれらのログを検出および適用できます。完全なリストアおよびリカバリを実行します(「データベースの完全リカバリの実行」を参照)。

オンラインREDOログを使用できない場合は、DBPITRを実行します(「データベースのPoint-in-Timeリカバリの実行」を参照)。オンラインREDOログの最初のSCNより前の時点までリカバリする場合の目標時点、SCNまたはログ順序番号を指定するには、UNTIL句を使用する必要があります(この句を使用しない場合、RMANはRMAN-6054エラーを発行します)。

バックアップ制御ファイルを使用してDBPITRを実行する場合、RESETLOGSを使用してデータベースをオープンする前に、SQL*Plusを使用してデータベースを読取り専用でオープンし、必要に応じて問合せを実行して、論理的な破損の影響が無効にされたことを確認できます。結果が期待どおりだった場合、RESETLOGSを使用して、データベースをオープンできます。

注意:
ログ順序の指定時に、最後に作成されたアーカイブREDOログの順序がnの場合は、RMANがnを適用してから停止するように、UNTIL SEQUENCE n+1を指定します。

次の例では、オンラインREDOログ・ファイルが消失しており、最新のアーカイブREDOログの順序番号は13243です。この例は、制御ファイルの自動バックアップをリストアし、最新のログを使用してリカバリする方法を示しています。

RUN
{
# Optionally, set upper limit for eligible time stamps of control file
# backups
# SET UNTIL TIME '09/10/2007 13:45:00';
# Specify a nondefault autobackup format only if required
# SET CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK
#   TO '?/oradata/%F.bck';
ALLOCATE CHANNEL c1 DEVICE TYPE sbt PARMS '...'; # allocate manually
RESTORE CONTROLFILE FROM AUTOBACKUP
MAXSEQ 100           # start at sequence 100 and count down
MAXDAYS 180;         # start at UNTIL TIME and search back 6 months
ALTER DATABASE MOUNT DATABASE;
}
# Now use automatic channels configured in restored control file
RESTORE DATABASE UNTIL SEQUENCE 13244;
RECOVER DATABASE UNTIL SEQUENCE 13244;

5. リカバリに成功した場合は、データベースをオープンし、オンライン・ログをリセットします。

ALTER DATABASE OPEN RESETLOGS;

障害リカバリの実行

障害リカバリには、ターゲット・データベース全体、リカバリ・カタログ・データベース、すべての現行の制御ファイル、すべてのオンラインREDOログ・ファイルおよびすべてのパラメータ・ファイルが消失した後のターゲット・データベースのリストアおよびリカバリが含まれます。

障害リカバリの前提条件

障害リカバリを実行するには、次のものが必要です。

- すべてのデータファイルのバックアップ

- リストアする最も古いバックアップの作成時刻の後に生成されたすべてのアーカイブREDOログ

- 1つ以上の制御ファイルの自動バックアップ

- データベースのDBIDのレコード

障害発生後のデータベースのリカバリ

障害リカバリの手順は、NOCATALOGモードでバックアップ制御ファイルを使用してデータベースをリカバリする手順と類似しています。新しいホストにデータベースをリストアする場合は、「新しいホストへのデータベースのリストア」で説明されている考慮事項を参照してください。

この例では、データベースが実行されていたLinuxサーバーに修復不可能な破損が発生していると想定しています。データベースをOracle Secure Backupにバックアップしてあるため、そのテープを使用できます。この例では、次のことを想定しています。

- Oracle Databaseが新しいホストにすでにインストールされています。

- 古いホストと同じディレクトリ構造を持つ新しいLinuxホストにデータベースをリストアします。

- 1つのテープ・ドライブを使用します(このテープ・ドライブには、すべてのデータファイルのバックアップ、ログ1124までのアーカイブREDOログおよび制御ファイルとサーバー・パラメータ・ファイルの自動バックアップが含まれています)。

- データベースでリカバリ・カタログは使用しません。

新しいホストにデータベースをリカバリする手順

1. 可能な場合は、tnsnames.ora、listener.ora、パスワード・ファイルなどの関連するすべてのネットワーク・ファイルをリストアまたは再生成します。

2. RMANを起動し、ターゲット・データベース・インスタンスに接続します。
この時点では、初期化パラメータ・ファイルは存在しません。ORACLE_SIDおよびORACLE_HOMEを設定すると、オペレーティング・システム認証を使用してSYSDBAとして接続できます。たとえば、RMANを次のように起動します。

% rman
RMAN> CONNECT TARGET /

3. SET DBIDコマンドを使用してターゲット・データベースのDBIDを指定します(「サーバー・パラメータ・ファイルのリストア」を参照)。
たとえば、次のコマンドを入力します。

SET DBID 676549873;

4. STARTUP NOMOUNTコマンドを実行します。
サーバー・パラメータ・ファイルを使用できない場合、RMANは仮のサーバー・パラメータ・ファイルを使用してインスタンスの起動を試行します。

5. チャネルをメディア・マネージャに割り当て、自動バックアップからサーバー・パラメータ・ファイルをリストアします。
たとえば、Oracle Secure Backupからサーバー・パラメータ・ファイルをリストアする場合は、次のコマンドを入力します。

RUN
{
ALLOCATE CHANNEL c1 DEVICE TYPE sbt;
RESTORE SPFILE FROM AUTOBACKUP;
}

6. リストアしたサーバー・パラメータ・ファイルを使用してインスタンスを再起動します。

STARTUP FORCE NOMOUNT;

7. リストアおよびリカバリ操作を実行するためのコマンド・ファイルを記述し、そのコマンド・ファイルを実行します。このコマンド・ファイルには、次の手順が含まれている必要があります。

1. チャネルをメディア・マネージャに割り当てます。

2. 制御ファイルの自動バックアップをリストアします(「バックアップ制御ファイルを使用してリカバリ・カタログを使用しないリカバリの実行」を参照)。

3. リストアした制御ファイルをマウントします。

4. CATALOGコマンドを使用して、リポジトリに記録されていないバックアップをカタログに追加します。

5. データファイルを元の場所にリストアします。 ボリューム名が変更されている場合は、リストア操作の前にSET NEWNAMEコマンドを実行し、リストア操作の後にSWITCHを実行して、制御ファイルをデータファイルの新しい場所に更新します。次に例を示します。

6. データファイルをリカバリします。指定したログ順序番号に達すると、RMANによってリカバリが停止されます。

RMAN> RUN
{
# Manually allocate a channel to the media manager
ALLOCATE CHANNEL t1 DEVICE TYPE sbt;
# Restore autobackup of the control file. This example assumes that you have
# accepted the default format for the autobackup name.
RESTORE CONTROLFILE FROM AUTOBACKUP;
#  The set until command is used in case the database
#  structure has changed in the most recent backups, and you want to
#  recover to that point in time. In this way RMAN restores the database
#  to the same structure that the database had at the specified time.
ALTER DATABASE MOUNT;
SET UNTIL SEQUENCE 1124 THREAD 1;
RESTORE DATABASE;
RECOVER DATABASE;
}

次のRUNコマンドの例は、リストアしたデータファイルに新しいファイル名を使用することを除き、前述の例と同様です。

RMAN> RUN
{
#  If you must restore the files to new locations,
#  use SET NEWNAME commands:
SET NEWNAME FOR DATAFILE 1 TO '/dev/vgd_1_0/rlvt5_500M_1';
SET NEWNAME FOR DATAFILE 2 TO '/dev/vgd_1_0/rlvt5_500M_2';
SET NEWNAME FOR DATAFILE 3 TO '/dev/vgd_1_0/rlvt5_500M_3';
ALLOCATE CHANNEL t1 DEVICE TYPE sbt;
RESTORE CONTROLFILE FROM AUTOBACKUP;
ALTER DATABASE MOUNT;
SET UNTIL SEQUENCE 124 THREAD 1;
RESTORE DATABASE;
SWITCH DATAFILE ALL; # Update control file with new location of data files.
RECOVER DATABASE;
}

8. リカバリに成功した場合は、データベースをオープンし、オンライン・ログをリセットします。

ALTER DATABASE OPEN RESETLOGS;

新しいホストへのデータベースのリストア

障害リカバリ手順のテスト実行を行うか、またはデータベースを新しいホストに永続的に移動する場合は、この項で説明する手順を実行します。この手順では、RESTOREコマンドおよびRECOVERコマンドを使用します。

この項の手順を実行する場合、リストアされるデータベースのDBIDは、元のデータベースのDBIDと同じです。この方法で作成したテスト・データベースは、ソース・データベースと同じリカバリ・カタログに登録しないでください。2つのデータベースのDBIDが同じであるため、テスト・データベースのメタデータが、ソース・データベースをリストアおよびリカバリするRMANの機能に影響を与える可能性があります。

新しいホストで継続して使用するためにターゲット・データベースの新しいコピーを作成する場合は、この手順ではなく、RMANのDUPLICATEコマンドを実行します。DUPLICATEコマンドを実行すると、作成されるデータベースに対して新しいDBIDが割り当てられるため、このデータベースを元のデータベースと同じリカバリ・カタログに追加できます。

関連項目:
データベースの複製方法については、「RMANデータベースの複製の概要」を参照してください。

新しいホストへのデータベースのリストアの準備

新しいホストへのデータベースのリストアを準備するには、次の手順を実行します。

- ソース・データベースのDBIDを記録します。データベースのDBIDが不明な場合は、DBIDの確認方法について「データベースのDBIDの確認」を参照してください。

- 新しいホスト上でソース・データベースの初期化パラメータ・ファイルをアクセス可能にします。オペレーティング・システム・ユーティリティを使用して、古いホストから新しいホストにこのファイルをコピーします。

- テスト・リストア操作のみを実行する場合は、RMANがリカバリ・カタログに接続されていないことを確認してください。接続されている場合は、RMANによって、リストアされたデータファイルに関するメタデータがリカバリ・カタログに記録されます。このメタデータは、プライマリ・データベースを将来リストアおよびリカバリする場合の障害となります。
リストアする必要があるすべてのバックアップのRMANリポジトリ・データを格納するには制御ファイルのサイズが十分ではないため、リカバリ・カタログを使用する必要がある場合は、Oracle Data Pumpを使用してカタログをエクスポートし、別のスキーマまたはデータベースにインポートします。その後、コピーしたリカバリ・カタログをテスト・リストアに使用します。これを行わない場合、リカバリ・カタログでは、リストアされたデータベースが現行のターゲット・データベースとみなされます。

- リストア操作に使用されるバックアップがリストア・ホスト上でアクセス可能であることを確認します。たとえば、メディア・マネージャを使用してバックアップを作成した場合は、テープ・デバイスが新しいホストに接続されていることを確認します。ディスクのコピーを使用している場合は、次の項の手順を実行します。

- 本番データベースの試行リストアを実行する場合は、テスト環境でデータベースをリストアする前に、次の操作のいずれかを実行します。

- 本番データベースが使用しているリカバリ領域とは物理的に異なる高速リカバリ領域をテスト・データベースで使用する場合は、テスト・データベース・インスタンスのDB_RECOVERY_FILE_DESTを新しい場所に設定します。

- 本番データベースで使用されるリカバリ領域と物理的に同じ高速リカバリ領域をテスト・データベースで使用する場合は、テスト・データベース・インスタンスのDB_UNIQUE_NAMEを、本番データベースとは異なる名前に設定します。

前述の操作をどちらも実行しないと、RMANでは、本番データベースをリストアしていると判断し、高速リカバリ領域の フラッシュバック・ログを使用不可能とみなして削除します。

新しいホストへのディスク・バックアップのリストア

ディスク上のデータファイルのコピーまたはバックアップ・セットを使用して新しいホストにデータベースを移動するには、新しいホストにそのファイルを手動で転送する必要があります。次の例では、RMANでリカバリ・カタログが使用されていると想定しています。

バックアップ・ファイルを新しいホストにリストアする方法

1. RMANを起動し、ターゲット・データベースおよびリカバリ・カタログに接続します。

2. LISTコマンドを実行して、データファイルのバックアップおよび制御ファイルの自動バックアップのリストを表示します。
たとえば、次のコマンドを入力してデータファイルのコピーを表示します。

LIST COPY;

たとえば、次のコマンドを入力して制御ファイルのバックアップを表示します。

LIST BACKUP OF CONTROLFILE;

自動バックアップ・ピースの名前には、%F置換変数を使用する必要があります。したがって、自動バックアップ・ピースの名前には、文字列c-IIIIIIIIII-YYYYMMDD-QQが含まれます。ここで、IIIIIIIIIIはDBIDを表し、YYYYMMDDはバックアップが生成された日のグレゴリオ暦でのタイムスタンプ、QQは16進数の順序です。

3. オペレーティング・システム・ユーティリティを使用して、バックアップを新しいホストにコピーします。
次のコマンドを入力して、すべてのデータファイルのコピーを新しいホストの?/oradata/trgtディレクトリにコピーします。

% cp -r /disk1/*dbf /net/new_host/oracle/oradata/trgt

次のコマンドを入力して、自動バックアップのバックアップ・ピースを新しいホストの/tmpディレクトリにコピーします。

% cp -r /disk1/auto_bkp_loc/c-1618370911-20070208-00 /net/new_host/tmp

「制御ファイルの自動バックアップからのサーバー・パラメータ・ファイルのリストア」で説明されているように、デフォルト以外の場所から自動バックアップをリストアする場合は、SET CONTROLFILE AUTOBACKUP FORMATコマンドを使用する必要があります。

新しいホストへのデータベースのリストアのテスト

次の例では、データベースを新しいホストにリストアすることができるかどうかをテストすると想定しています。この例では、ネットワークで接続された2台のLinuxホストhostaとhostbを使用します。trgtaという名前のターゲット・データベースがhosta上に存在し、リカバリ・カタログcatdbに登録されています。データベースtrgtaが起動され、hosta上で実行されている間に、hostb上でtrgtaのリストアおよびリカバリをテストします。

ここで、hostbのディレクトリ構造はhostaのディレクトリ構造と異なっていると想定します。ターゲット・データベースは/net/hosta/dev3/oracle/dbsに存在していますが、このデータベースを/net/hostb/oracle/oradata/testにリストアします。データファイル、制御ファイル、アーカイブREDOログおよびサーバー・パラメータ・ファイルのテープ・バックアップが、両方のホストからアクセス可能なメディア・マネージャ上にあります。trgtaデータベースのORACLE_SIDはtrgtaで、リストアされたデータベースでも変更されません。

注意:
テストの目的でデータベースをリストアする場合は、RMANをテスト・データベースおよびリカバリ・カタログに接続しないでください。

新しいホストにデータベースをリストアする手順

1. ターゲット・データベースのバックアップが新しいホスト上でアクセス可能であることを確認します。
障害リカバリをテストするには、ターゲット・データベースのリカバリ可能なバックアップが必要です。障害リカバリ計画を作成する場合は、データファイル、制御ファイルおよびサーバー・パラメータ・ファイルのバックアップがhostb上にリストア可能であることを確認します。そのため、hostbをメディア・マネージャのクライアントにして、hosta上に作成されたバックアップ・セットを読み取ることができるように、メディア管理ソフトウェアを構成する必要があります。この問題に対するサポートについては、メディア管理ベンダーに問い合せてください。

2. hostb上でORACLE_SIDを構成します。
この例では、RMANクライアントをhostb上で起動し、オペレーティング・システムを介して自分を認証すると想定しています。ただし、ローカルで、またはネット・サービス名を介して、hostbに接続する必要があります。

管理者権限を使用してhostbにログインした後、自分がDBAグループに含まれるように/etc/groupファイルを編集します。

dba:*:614:<your_user_name>

hostb上で、環境変数ORACLE_SIDをhosta上で使用した値と同じ値に設定します。

% setenv ORACLE_SID trgta

3. hostb上でRMANを起動し、リカバリ・カタログに接続せずにターゲット・データベースに接続します。
たとえば、次のコマンドを入力します。

% rman NOCATALOG
RMAN> CONNECT TARGET /

4. DBIDを設定し、データベースをマウントせずにデータベース・インスタンスを起動します。
たとえば、SET DBIDを実行してDBIDを設定し、次にSTARTUP NOMOUNTを実行します。

SET DBID 1340752057;
STARTUP NOMOUNT

サーバー・パラメータ・ファイルがリストアされていないため、RMANがサーバー・パラメータ・ファイルの検出に失敗しますが、仮のファイルを使用してインスタンスが起動されます。出力例を次に示します。

startup failed: ORA-01078: failure in processing system parameters
LRM-00109: could not open parameter file '/net/hostb/oracle/dbs/inittrgta.ora'

trying to start the Oracle instance without parameter files ...
Oracle instance started

5. サーバー・パラメータ・ファイルをリストアおよび編集します。
バックアップの実行時に制御ファイルの自動バックアップ機能を有効にしたため、バックアップにサーバー・パラメータ・ファイルが含まれます。デフォルト以外の書式の自動バックアップをリストアする場合は、SET CONTROLFILE AUTOBACKUP FORMATコマンドを使用して書式を指定します。

メディア・マネージャにチャネルを割り当て、サーバー・パラメータ・ファイルをクライアント側のパラメータ・ファイルとしてリストアし、SETコマンドを使用して自動バックアップの場所を指定します(この例では、自動バックアップは/tmpにあります)。

RUN
{
ALLOCATE CHANNEL c1 DEVICE TYPE sbt PARMS '...';
SET CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO '/tmp/%F';
RESTORE SPFILE
TO PFILE '?/oradata/test/inittrgta.ora'
FROM AUTOBACKUP;
SHUTDOWN ABORT;
}

6. リストアされた初期化パラメータ・ファイルを編集します。
末尾が_DESTなどの場所固有のすべてのパラメータを変更し、新しいディレクトリ構造を反映します。たとえば、次のパラメータを編集します。

- IFILE
- LOG_ARCHIVE_DEST_1
- CONTROL_FILES

7. 編集した初期化パラメータ・ファイルを使用してインスタンスを再起動します。
たとえば、次のコマンドを入力します。

STARTUP FORCE NOMOUNT PFILE='?/oradata/test/inittrgta.ora';

8. 自動バックアップから制御ファイルをリストアし、データベースをマウントします。
たとえば、次のコマンドを入力します。

RUN
{
ALLOCATE CHANNEL c1 DEVICE TYPE sbt PARMS '...';
RESTORE CONTROLFILE FROM AUTOBACKUP;
ALTER DATABASE MOUNT;
}

CONTROL_FILES初期化パラメータで指定した場所に制御ファイルがRMANによりリストアされます。

9. 新しいファイル名またはCATALOG START WITH(すべてのファイルが共通の接頭辞を持つディレクトリに含まれ、CATALOG START WITHコマンドで簡単に指定できることがわかっている場合)を使用して、「新しいホストへのディスク・バックアップのリストア」でコピーしたデータファイルのコピーをカタログに追加します。たとえば、次のコマンドを実行します。

CATALOG START WITH '/oracle/oradata/trgt/';

ファイルを個別に指定する場合は、CATALOGコマンドを次のように実行します。

CATALOG DATAFILECOPY
'/oracle/oradata/trgt/system01.dbf', '/oracle/oradata/trgt/undotbs01.dbf',
'/oracle/oradata/trgt/cwmlite01.dbf', '/oracle/oradata/trgt/drsys01.dbf',
'/oracle/oradata/trgt/example01.dbf', '/oracle/oradata/trgt/indx01.dbf',
'/oracle/oradata/trgt/tools01.dbf', '/oracle/oradata/trgt/users01.dbf';

10. 新しいデータベース上でSQL*Plusセッションを開始し、制御ファイルに記録されたデータベースのファイル名を問い合せます。
制御ファイルはtrgtaデータベースからリストアされているため、記録されたファイル名では元のhostaのファイル名が使用されます。V$ビューを問い合せると、この情報を取得できます。SQL*Plusで次の問合せを実行します。

COLUMN NAME FORMAT a60
SPOOL  LOG '/tmp/db_filenames.out'
SELECT FILE# AS "File/Grp#", NAME
FROM   V$DATAFILE
UNION
SELECT GROUP#,MEMBER
FROM   V$LOGFILE;
SPOOL OFF
EXIT

11. RMANのリストア・スクリプトおよびリカバリ・スクリプトを記述します。このスクリプトには、次の手順が含まれている必要があります。

1. ソース・ホスト上のパスとは異なるパスにリストアされた宛先ホスト上の各データファイルに対して、SET NEWNAMEコマンドを使用して宛先ホスト上に新しいパスを指定します。宛先システム上のファイル・システムがソース・ホスト上のパスと同じパスを持つように設定されている場合は、ソース・ホスト上のパスと同じパスにリストアされるファイルに対してSET NEWNAMEを使用しないでください。

2. ソース・ホスト上の場所とは異なる場所に作成される各オンラインREDOログに対して、SQLのALTER DATABASE RENAME FILEコマンドを使用して宛先ホスト上にパス名を指定します。宛先システム上のファイル・システムがソース・ホスト上のパスと同じパスを持つように設定されている場合は、ソース・ホスト上のパスと同じパスにリストアされるファイルに対してALTER DATABASE RENAME FILEを使用しないでください。

3. SET UNTIL操作を実行して、リカバリをアーカイブREDOログの最後までに制限します。SET UNTILコマンドが指定されていない場合、エラーが発生してリカバリが停止します。

4. データベースをリストアおよびリカバリします。

5. SWITCH DATAFILE ALLコマンドを実行して、新しいパス名をデータファイルの正式な新しい名前として制御ファイルに認識させます。

例20-3に、リストアおよびリカバリ操作を実行できるRMANスクリプトreco_test.rmanを示します。

例20-3 新しいホストへのデータベースのリストア

RUN
{
# allocate a channel to the tape device
ALLOCATE CHANNEL c1 DEVICE TYPE sbt PARMS '...';

# rename the data files and online redo logs
SET NEWNAME FOR DATAFILE 1 TO '?/oradata/test/system01.dbf';
SET NEWNAME FOR DATAFILE 2 TO '?/oradata/test/undotbs01.dbf';
SET NEWNAME FOR DATAFILE 3 TO '?/oradata/test/cwmlite01.dbf';
SET NEWNAME FOR DATAFILE 4 TO '?/oradata/test/drsys01.dbf';
SET NEWNAME FOR DATAFILE 5 TO '?/oradata/test/example01.dbf';
SET NEWNAME FOR DATAFILE 6 TO '?/oradata/test/indx01.dbf';
SET NEWNAME FOR DATAFILE 7 TO '?/oradata/test/tools01.dbf';
SET NEWNAME FOR DATAFILE 8 TO '?/oradata/test/users01.dbf';
SQL "ALTER DATABASE RENAME FILE ''/dev3/oracle/dbs/redo01.log''
TO ''?/oradata/test/redo01.log'' ";
SQL "ALTER DATABASE RENAME FILE ''/dev3/oracle/dbs/redo02.log''
TO ''?/oradata/test/redo02.log'' ";

# Do a SET UNTIL to prevent recovery of the online logs
SET UNTIL SCN 123456;
# restore the database and switch the data file names
RESTORE DATABASE;
SWITCH DATAFILE ALL;

# recover the database
RECOVER DATABASE;
}
EXIT

12. 前述の手順で作成したスクリプトを実行します。
たとえば、RMANを起動してターゲット・データベースに接続し、@コマンドを実行します。

% rman TARGET / NOCATALOG
RMAN> @reco_test.rman

13. RESETLOGSオプションを指定して、リストアしたデータベースをオープンします。
RMANプロンプトで、RESETLOGSオプションを指定してデータベースをオープンします。

ALTER DATABASE OPEN RESETLOGS;

注意:
次の手順でデータベースを再オープンする場合は、リカバリ・カタログに接続しないでください。そうしなかった場合は、作成される新しいデータベース・インカネーションがリカバリ・カタログに自動的に登録され、本番データベースのファイル名が、スクリプトに指定されている新しいファイル名に置換されます。

14. 必要に応じて、含まれているすべてのファイルとともにテスト・データベースを削除します。

注意:
ASMディスク・グループを使用した場合、テスト・データベースのファイルを安全に削除する方法はDROP DATABASEコマンドのみです。非ASMストレージにリストアした場合は、オペレーティング・システムのコマンドを使用してデータベースを削除することもできます。

DROP DATABASEコマンドを使用して、データベースに関連付けられているすべてのファイルを自動的に削除します。次の例では、データベース・ファイルを削除します。

STARTUP FORCE NOMOUNT PFILE='?/oradata/test/inittrgta.ora';
DROP DATABASE;

リカバリ・カタログへの接続時にリストアおよびリカバリ操作を実行しなかったため、リカバリ・カタログには、リストアしたファイルまたはテスト中に実行した手順のレコードは含まれません。同様に、trgtaデータベースの制御ファイルは、テストによる影響を受けません。

21 RMANの表領域のPoint-in-Timeリカバリ(TSPITR)の実行

この章では、RMANの表領域のPoint-in-Timeリカバリを実行する方法について説明します。この章の内容は、次のとおりです。

- RMANのTSPITRの概要

- TSPITRの制限、特殊事例および制約

- TSPITRの計画および準備

- RMANのTSPITRの実行

- 完全に自動化されたRMANのTSPITRの実行

- RMAN管理の補助インスタンスを使用したRMANのTSPITRに対するデフォルトの変更

- 独自の補助インスタンスを使用したRMANのTSPITRの実行

- RMANのTSPITRのトラブルシューティング

RMANのTSPITRの概要

RMANの表領域のPoint-in-Timeリカバリ(TSPITR)を効果的に使用するには、解決可能な問題の種類、コンポーネント、TSPITRを実行中のRMANの機能、および実行時や実行方法に関する様々な制約および制限について理解することが有用です。この項では、RMANのTSPITRの実行に関する基本的な概念、準備およびモードについて説明します。

RMANのTSPITRの目的

Recovery Manager (RMAN)のTSPITRを使用すると、データベースの1つ以上の表領域をデータベースの残りの表領域およびオブジェクトには影響を及ぼさずに、過去の時点まで迅速にリカバリできます。

RMANのTSPITRは、次の場合に最も有効です。

- 1つの物理データベースの個別の表領域に複数の論理データベースが存在するときに、ある論理データベースを物理データベースの残りの部分とは異なる時点までリカバリする場合。たとえば、ordersおよびpersonnel表領域に論理データベースを保持している場合などです。不正なバッチ・ジョブまたはデータ操作言語(DML)文を実行すると、1つの表領域にのみ存在するデータが破損します。

- 表の構造を変更するデータ定義言語(DDL)操作を実行した後に消失したデータをリカバリする場合。フラッシュバック表を使用して、表の切捨て操作などで構造を変更した時点より前に表を巻き戻すことはできません。

- PURGEオプションを使用して表を削除した後、その表をリカバリする場合。

- 表の論理的な破損からリカバリする場合。

- 削除された表領域をリカバリする場合。実際に、リカバリ・カタログを使用しない場合でも、RMANでは削除された表領域に対してTSPITRを実行できます。

フラッシュバック・データベースを使用してデータを巻き戻すこともできますが、サブセットのみでなくデータベース全体を巻き戻す必要があります。また、TSPITRとは異なり、フラッシュバック・データベース機能ではフラッシュバック・ログを保持するオーバーヘッドが伴います。データベースのフラッシュバックが可能な期間は、TSPITRの期間より限られています。TSPITRの期間は、最も古いリカバリ可能なバックアップまでの期間となります。

RMANのTSPITRの基本的な概念

次の各項では、RMANのTSPITRの基本事項について説明します。

- 共通の用語

- RMANのTSPITRのモード

- RMAN管理の補助インスタンスを使用したRMANのTSPITRの仕組み

共通の用語

表21-1に、RMANのTSPITRで使用される共通のエンティティの一部を定義します。

表21-1 RMANのTSPITRのエンティティ

名前

説明

ターゲット・インスタンス

目標時点までリカバリする表領域が含まれます。

目標時点

TSPITRが完了した後の表領域のPoint-in-TimeまたはSCN

補助インスタンス

リカバリ・プロセスで使用され、リカバリ作業を実行するデータベース・インスタンス。補助インスタンスには、データベース・インスタンスに関連付けられる他のファイルが含まれます。完全なリストについては、補助セットを参照してください。

補助の宛先

RMANが補助セット・ファイルを一時的に格納するために使用する、オプションのディスクの場所。補助の宛先は、RMAN管理の補助インスタンスを使用する場合にのみ使用されます。ユーザー管理の補助インスタンスとともに補助の宛先を指定すると、エラーが発生します。

この章で補助の宛先について言及したすべての箇所で、RMAN管理の補助インスタンスを使用することを想定しています。

リカバリ・セット

リカバリする表領域のデータファイル。

補助セット

リカバリ・セットには含まれていないTSPITRに必要なデータファイル。通常、補助セットには次のものが含まれます。

- SYSTEM表領域およびSYSAUX表領域。

- ターゲット・データベース・インスタンスのロールバック・セグメントまたはUNDOセグメントを含むデータファイル。

- 一時表領域。

- ソース・データベースの制御ファイル。

- 指定した時点まで補助インスタンスをリカバリするためにリストアが必要なアーカイブREDOログ。

- 補助インスタンスのオンラインREDOログ。ソース・データベースのオンラインREDOログとは異なります。RESETLOGSオプションを使用して補助インスタンスをオープンした場合に作成されます。

補助セットには、パラメータ・ファイル、パスワード・ファイルまたは関連するネットワーク・ファイルは含まれません。

RMANのTSPITRのモード

RMANのRECOVER TABLESPACEコマンドを使用して、RMANのTSPITRを起動します。RMANのTSPITRを実行するには、いくつかのオプションがあります。様々な操作モード間の違いは、実行環境に応じて必要とされる自動化とカスタマイズの割合に対応しています。ユーティリティは、次の3つの方法で実行できます。

- 完全自動化(デフォルト)
このモードでは、補助インスタンスを含むTSPITRプロセス全体がRMANによって管理されます。リカバリ・セットの表領域、補助の宛先および目標時点を指定し、RMANでその他すべてのTSPITRに関する手順を管理します。

TSPITRの実行後のリカバリ・セット・ファイルの場所、TSPITRを実行中の補助セット・ファイル、チャネル設定およびチャネル・パラメータまたは補助インスタンスのその他の詳細を特に制御する必要がないかぎり、このデフォルトのモードをお薦めします。詳細は、「完全に自動化されたRMANのTSPITRの実行」を参照してください。

- ユーザー設定を使用する自動化されたRMAN管理の補助インスタンス
RMAN管理の補助インスタンスおよび補助の宛先を使用している場合でも、RMANのTSPITRのデフォルト値の一部を変更できます。デフォルトのモードを少し変更したこのモードを使用すると、RMANのTSITRに備えられた組込みの管理機能の一部を利用し、次の項目を指定できます。

- 補助セットまたはリカバリ・セット・ファイルの場所

- 初期化パラメータ

詳細は、「RMAN管理の補助インスタンスを使用したRMANのTSPITRに対するデフォルトの変更」を参照してください。

- 非自動化TSPITRおよびユーザー管理の補助インスタンス
RMANのTSPITRのこのモードでは、補助インスタンスのすべての手順、およびTSPITRプロセスの一部の手順をユーザーが設定して管理する必要があります。たとえば、ユーザー管理の補助インスタンスに対して異なる数のチャネルを割り当てたり、チャネル・パラメータを変更する必要があるときなどは、このモードが適切である場合があります。

詳細は、「独自の補助インスタンスを使用したRMANのTSPITRの実行」を参照してください。

RMAN管理の補助インスタンスを使用したRMANのTSPITRの仕組み

リカバリ・セットの表領域、補助の宛先および目標時点を選択すると、完全に自動化されたRMANのTSPITR(デフォルト)を実行できます。これらの高水準の処理ステップの多くは、RMANのTSPITRの自動化モードの場合にも共通します。

RMANのTSPITRによって、次の処理が自動的に実行されます。

1. リカバリ・セットの表領域が削除されていない場合は、リカバリ・セットの表領域に対してDBMS_TTS.TRANSPORT_SET_CHECKを実行し、次にビューTRANSPORT_SET_VIOLATIONSが空であることを確認して、リカバリ・セットの表領域が自己完結型であるかどうかを確認します。問合せが行を戻す場合、RMANはTSPITRの処理を停止します。TSPITRを続行するには、表領域の格納違反をすべて解決する必要があります。例21-1に、RMANのTSPITRを起動する前に行う問合せの設定方法および実行方法を示します。

2. ユーザー管理の補助インスタンスへの接続が指定されているかどうかを確認します。接続が指定されている場合、RMANのTSPITRはその接続を使用します。そうでない場合、RMANのTSPITRは補助インスタンスを作成して起動し、その補助インスタンスに接続します。

3. リカバリ・セットの表領域が削除されていない場合は、ターゲット・データベース内のリカバリする表領域をオフラインにします。

4. 目標時点より前の時点のバックアップの制御ファイルを、補助インスタンスにリストアします。

5. リカバリ・セットおよび補助セットのデータファイルを、補助インスタンスにリストアします。
次のいずれかの場所で、ファイルがリストアされます。

- ファイルごとに指定した場所

- ファイルの元の場所(リカバリ・セット・データファイルの場合)

- 補助の宛先(RECOVER TABLESPACEのAUXILIARY DESTINATION引数およびRMAN管理の補助インスタンスを使用する場合)

6. 補助インスタンスにリストアしたデータファイルを、指定した時点までリカバリします。

7. RESETLOGSオプションを使用して補助データベースをオープンします。

8. 補助インスタンスのリカバリ・セットの表領域を読取り専用に設定します。

9. トランスポータブル表領域のダンプ・ファイルを作成するためのデータ・ポンプ・ユーティリティを使用して、補助インスタンスからリカバリ・セットの表領域をエクスポートします。

10. 補助インスタンスを停止します。

11. リカバリ・セットの表領域をターゲットから削除します。

12. データ・ポンプ・ユーティリティは、トランスポータブル表領域のダンプ・ファイルを読み取り、リカバリ・セットの表領域をターゲットに組み込みます。

13. ターゲット・データベースに組み込まれた表領域を読取り/書込みに設定し、それらの表領域をすぐにオフラインにします。

14. すべての補助セット・ファイルを削除します。

この時点でRMANのTSPITRは完了です。リカバリ・セットのデータファイルは、指定した時点の内容に戻り、ターゲット・データベースに属します。

バックアップを行うことができるよう、リカバリ・セットの表領域はオフラインの状態であるため、オンラインに戻します。この最後の手順は、TSPITRの完了直後にリカバリした表領域をバックアップするという、オラクル社の推奨事項およびベスト・プラクティスに基づいています。

TSPITRの制限、特殊事例および制約

TSPITRでは解決できないデータベースの問題もあります。次に、TSPITRを実行できない場合を示します。

- アーカイブREDOログ・ファイルがないか、またはデータベースをNOARCHIVELOGモードで実行している場合。

- TSPITRを使用して、名前が変更された表領域を変更前の時点にリカバリするには、表領域の変更前の名前を使用してリカバリ操作を実行する必要があります。
この場合、TSPITRが完了すると、ターゲット・データベースには同じ表領域のコピーが2つ含まれます。新しい名前を持つ元の表領域と変更前の名前を持つTSPITRの表領域です。この状態が目的のものでない場合は、変更後の名前を持つ新しい表領域を削除できます。

- 表領域tbs1の表の制約が表領域tbs2に含まれている場合、tbs2をリカバリせずにtbs1をリカバリすることはできません。

- 表およびその索引が別の表領域に格納されている場合、TSPITRを実行する前に索引を削除する必要があります。

- TSPITRを使用して、現行のデフォルト表領域をリカバリすることはできません。

- TSPITRでは、次のオブジェクトを含む表領域はリカバリできません。

- 基礎となるオブジェクト(マテリアライズド・ビューなど)またはコンテナ・オブジェクト(パーティション表など)を持つオブジェクト。ただし、基礎となるすべてのオブジェクトまたはコンテナ・オブジェクトがリカバリ・セットに含まれる場合を除きます。さらに、パーティション表のパーティションが別に表領域に保存されている場合は、TSPITRを実行する前に表を削除するか、TSPITRを実行する前にパーティションをすべて同じ表領域に移動する必要があります。

- UNDOセグメントまたはロールバック・セグメント

- 複数の受信者を持つOracle8互換アドバンスト・キュー

- ユーザーSYSが所有するオブジェクト。このタイプのオブジェクトの例としては、PL/SQL、Javaクラス、コールアウト・プログラム、ビュー、シノニム、ユーザー、権限、ディメンション、ディレクトリおよび順序があります。

TSPITRの制約

TSPITRが完了した後、RMANは、リカバリ・セットのデータファイルを目標時点までリカバリします。次の特殊事例に注意してください。

- TSPITRでは、リカバリしたオブジェクトに関する問合せオプティマイザの統計情報はリカバリされません。TSPITRが完了した後で新しい統計情報を収集する必要があります。

- 表領域に対してTSPITRを実行し、時刻tに表領域をオンラインにすると、時刻tより前に作成された表領域のバックアップは、現行の制御ファイルでのリカバリには使用できません。現行の制御ファイルを使用して、データベースを時刻t以前の時点までリカバリすることはできません。

- リカバリ・セットの1つ以上のデータファイルがOracle Managed File(OMF)名を持ち、ターゲット・データベースの互換性がバージョン10.1以下に設定されている場合、RMANはデータファイルを再利用できません。この制限は、データファイルにSET NEWNAMEコマンドが指定されていない場合も当てはまります。リカバリ・セットのデータファイルに対して新しいOMF名が作成されます。このアクションによって、データファイルの領域要件が一時的に倍になります。これは、ターゲットの表領域および元のデータファイルが削除されるまで、DB_CREATE_FILE_DESTにデータファイルのコピーが2つ(元のデータファイルおよびTSPITRによって使用されるデータファイル)存在するためです。

RMANは、トランスポータブル表領域機能を使用して、TSPITRを実行します。したがって、トランスポータブル表領域についてのすべての制限事項は、TSPITRにも当てはまります。

関連項目:
トランスポータブル表領域の制限事項の詳細は、『Oracle Database管理者ガイド』を参照してください。

リカバリ・カタログを使用しない場合の特別な考慮事項

次に注意してください。

- RMANでのUNDOの履歴レコードは制御ファイルに含まれないため、ロールバック・セグメントまたはUNDOセグメントを含む現行の表領域セットは、リカバリの実行時に存在したセットと同じであるとみなされます。その時点以降に表領域セットが変更された場合、現行のロールバック・セグメントまたはUNDOセグメントは、リカバリの目標時点に存在したセグメントと同じになります。その時点以降にUNDOセグメントが変更された場合は、UNDO TABLESPACEを使用して、表領域がリカバリされた時点のUNDOセグメントを含む正しい表領域セットを表示できます。

- 必要なバックアップの制御ファイル・レコードがOracle Databaseで再利用されている場合は、TSPITRで時間を過度に戻すと失敗することがあります。(データベースの計画時に、CONTROL_FILE_RECORD_KEEP_TIME初期化パラメータを十分に大きい値に設定して、TSPITRに必要な制御ファイル・レコードが確実に保持されるようにします。)

- リカバリ・カタログを使用しないときにTSPITRを再実行するには、最初に、TSPITRで使用される表領域をターゲット・データベースから削除する必要があります。

TSPITRの計画および準備

この項では、「TSPITRの制限、特殊事例および制約」を参照済であると想定しています。TSPITRの準備では、次の手順を実行する必要があります。

- 手順1: TSPITRでの正しい目標時点の選択

- 手順2: リカバリ・セットの決定

- 手順3: TSPITRの実行後に消失するオブジェクトの確認および保存

手順1: TSPITRでの正しい目標時点の選択

TSPITRでの正しい目標時点またはSCNを選択することは、非常に重要です。「TSPITRの制限、特殊事例および制約」で説明されているように、TSPITRの実行後に表領域をオンラインにすると、それより前の時点のバックアップは使用できなくなります。

リカバリ・カタログを使用している場合は、表領域の履歴情報がカタログに格納されているため、TSPITR操作を異なる目標時点まで繰り返し実行できます。ただし、RMANで制御ファイルのみが使用される場合は、制御ファイルに表領域の履歴が存在しないため、表領域を削除した後でのみ繰返しTSPITRを実行できます。この場合、RMANは現行の表領域のセットのみを認識します。TSPITRが実行された表領域の作成時刻は、オンラインになった時点になります。

TSPITRの目標時点を指定するためにデータの過去の状態を調べるには、フラッシュバック問合せ、トランザクション問合せおよびフラッシュバック・バージョン問合せを使用して、データベースに不要な変更が発生した時点を検索します。

関連項目:
フラッシュバック問合せ、フラッシュバック・トランザクション問合せおよびフラッシュバック・バージョン問合せの詳細は、『Oracle Databaseアドバンスト・アプリケーション開発者ガイド』を参照してください。

手順2: リカバリ・セットの決定

最初、リカバリ・セットには、リカバリする表領域のデータファイルが含まれています。ただし、必要な表領域内のオブジェクトが他の表領域内のオブジェクトと関係(制約など)を持つ場合、TSPITRを実行する前にこれらの関係を処理する必要があります。このような関係に対応するには、次のいずれかの方法を選択します。

- 関連するオブジェクトを含む表領域をリカバリ・セットに追加する。

- 関係を削除する。

- TSPITRの実行中、関係を一時解消する。

プライマリ・データベースの依存性の確認および解決

RMANのTSPITRでは、表領域が自己完結型であり、SYSが所有するオブジェクトが表領域内に存在しないことが必要です。DBMS_TTS.TRANSPORT_SET_CHECKプロシージャを使用して、表領域の外部のオブジェクトの場所を特定し、リカバリ・セットの境界にまたがるオブジェクト間の関係を確認できます。TRANSPORT_SET_VIOLATIONSビューが行を戻した場合は、この手順で前述した選択肢に従って、問題を調査して解決する必要があります。

注意:
リカバリ・セットの1つ以上の表領域が削除されていた場合は、RMANのTSPITRで、プロシージャDBMS_TTS.TRANSPORT_SET_CHECKを実行できません。この場合、補助インスタンスのデータ・ポンプ・エクスポートが発生するときにDBMS_TTS.TRANSPORT_SET_CHECKが実行されます。RMANのTSPITRと同様に、エクスポート実行時に自己完結型でない表領域が検出されると、エクスポートは失敗します。

TSPITRの完了後に一時解消または削除した関係を再作成できるように、この手順で実行するすべての処理を記録します。TRANSPORT_SET_VIOLATIONSビューがリカバリ・セットの表領域に対して空の場合にのみ、TSPITRを続行します。

例21-1の問合せでは、表領域toolsおよびusersで構成された最初のリカバリ・セットでのDBMS_TTS.TRANSPORT_SET_CHECKプロシージャの使用方法を示します。依存性を管理するために、トランスポータブル表領域の違反表を問い合せます。すべての依存性が管理されている場合、この問合せは行を戻しません。

例21-1 表領域のサブセットに対するDBMS_TTS.TRANSPORT_SET_CHECKの問合せ

BEGIN
DBMS_TTS.TRANSPORT_SET_CHECK('USERS,TOOLS', TRUE,TRUE);
END;
/
SELECT * FROM  TRANSPORT_SET_VIOLATIONS;

関連項目:
DBMS_TTS.TRANSPORT_SET_CHECKプロシージャおよび対応するビューの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。

手順3: TSPITRの実行後に消失するオブジェクトの確認および保存

表領域に対してRMANのTSPITRを実行すると、リカバリの目標時点より後に作成されたオブジェクトは消失します。このようなオブジェクトを確認した場合は、TSPITRの実行前にデータ・ポンプ・エクスポート・ユーティリティを使用してそれらをエクスポートし、後でデータ・ポンプ・インポートを使用して再インポートすることで、それらのオブジェクトを保存できます。

TSPITRを実行すると消失するオブジェクトを確認するには、プライマリ・データベースでTS_PITR_OBJECTS_TO_BE_DROPPEDビューを問い合せます。表21-2に、このビューの内容を示します。

表21-2 TS_PITR_OBJECTS_TO_BE_DROPPEDビュー

列名

意味

OWNER

削除されるオブジェクトの所有者

NAME

TSPITRの実行によって消失するオブジェクトの名前

CREATION_TIME

オブジェクトの作成タイムスタンプ

TABLESPACE_NAME

オブジェクトを含む表領域の名前

CREATION_TIMEがTSPITRの目標時点より後であるオブジェクトのビューをフィルタ処理します。たとえば、usersおよびtoolsで構成されるリカバリ・セットを使用し、リカバリの目標時点が2007年11月2日午前7:03:11の場合は、例21-2に示す文を発行します。

例21-2 TS_PITR_OBJECTS_TO_BE_DROPPEDの問合せ

SELECT OWNER, NAME, TABLESPACE_NAME,
TO_CHAR(CREATION_TIME, 'YYYY-MM-DD:HH24:MI:SS')
FROM TS_PITR_OBJECTS_TO_BE_DROPPED
WHERE TABLESPACE_NAME IN ('USERS','TOOLS')
AND CREATION_TIME > TO_DATE('02-NOV-07:07:03:11','YY-MON-DD:HH24:MI:SS')
ORDER BY TABLESPACE_NAME, CREATION_TIME;

TO_CHARおよびTO_DATEファンクションを使用すると、国によって異なる日付書式を使用した場合の問題を回避できます。ユーザーは、ユーザー自身の作業では現地の日付書式を使用できます。

また、表領域のSCNがある場合には、変換ファンクションを使用して、そのSCNに関連付けられているタイムスタンプおよび削除されるオブジェクトを決定できます。たとえば、表領域usersおよびtoolsをリカバリするSCNが1645870である場合、削除されるオブジェクトを確認するには、例21-3に示す文を使用します。

例21-3 SCNおよびTS_PITR_OBJECTS_TO_BE_DROPPEDの使用

SELECT OWNER, NAME, TABLESPACE_NAME,
TO_CHAR(CREATION_TIME,'YYYY-MM-DD:HH24:MI:SS')
FROM TS_PITR_OBJECTS_TO_BE_DROPPED
WHERE TABLESPACE_NAME IN ('USERS','TOOLS')
AND CREATION_TIME > TO_DATE(TO_CHAR(SCN_TO_TIMESTAMP(1645870),
'MM/DD/YYYY HH24:MI:SS'),
'MM/DD/YYYY HH24:MI:SS')
ORDER BY TABLESPACE_NAME, CREATION_TIME;

関連項目:
TS_PITR_OBJECTS_TO_BE_DROPPEDビューの詳細は、『Oracle Databaseリファレンス』を参照してください。

完全に自動化されたRMANのTSPITRの実行

デフォルトのモードで、RMANのTSPITRは、ターゲット・データベースでの構成にできるかぎり基づきます。TSPITRの実行中、リカバリ・セットのデータファイルはターゲット・データベースの現行の場所に書き込まれます(OMFファイルの詳細は、「TSPITRの制約」を参照)。バックアップからファイルをリストアする場合は、ターゲット・データベースのチャネル構成と同じ構成が補助インスタンスで使用されます。ただし、補助セットのデータファイルおよび補助インスタンスの他のファイルは、補助の宛先に格納されます。

RMANで補助セットのデータファイルに対して使用する場所を指定するには、AUXILIARY DESTINATIONパラメータを使用します。補助の宛先は、補助セットのデータファイルを格納するための領域が十分にあるディスク上の場所にする必要があります。他の方法を使用して一部またはすべての補助セットのデータファイル名を変更した場合でも、AUXILIARY DESTINATIONパラメータを指定すると、名前が指定されていない補助セットのデータファイルにデフォルトの場所が提供されます。補助セットの一部のデータファイルの名前を省略した場合でも、TSPITRは正常に実行されます。

完全に自動化されたRMANのTSPITRを実行するには、TSPITRを実行するユーザーが、オペレーティング・システム認証を使用してSYSDBAとして接続できる必要があります。

完全に自動化されたRMANのTSPITRを実行する手順

1. 「TSPITRの制限、特殊事例および制約」の情報を確認します。

2. 「TSPITRの計画および準備」のタスクを実行します。

3. ターゲット・データベースでRMANセッションを開始し、必要に応じてリカバリ・カタログに接続します。

注意:
自動化されたTSPITRでRMANクライアントを起動する場合は、補助インスタンスに接続しないでください。RMANは、RECOVER TABLESPACEを実行するときに補助インスタンスに接続していると、「独自の補助インスタンスを使用したRMANのTSPITRの実行」で説明されているように、ユーザー独自の補助インスタンスを管理しようとしていると判断し、接続している補助インスタンスをTSPITRに使用します。

4. TSPITRに必要なすべてのチャネルをターゲット・インスタンスで構成します。
補助インスタンスでは、TSPITRの実行時に、ターゲット・インスタンスと同じチャネル構成が使用されます。

5. UNTIL句およびAUXILIARY DESTINATIONパラメータを指定して、RECOVER TABLESPACEコマンドを実行します。
例21-4では、usersおよびtools表領域をログ順序番号1299まで戻し、補助セット・ファイルを/disk1/auxdestディレクトリに格納します。

例21-4 2つの表領域に対するTSPITRの実行

RECOVER TABLESPACE users, tools
UNTIL LOGSEQ 1300 THREAD 1
AUXILIARY DESTINATION '/disk1/auxdest';

この次の手順は、RECOVERコマンドの結果によって異なります。

- TSPITRの実行中にエラーが発生しなかった場合は、手順6に進みます。
表領域は、RMANによってオフラインにされ、バックアップからリストアされて補助インスタンスで目標時点までリカバリされた後、ターゲット・データベースに再インポートされます。表領域はオフラインのままです。補助セットのすべてのデータファイルおよび補助インスタンスの他のファイルは、補助の宛先から削除されます。

- TSPITRの実行中にエラーが発生した場合は、「RMANのTSPITRのトラブルシューティング」に進みます。

6. TSPITRが正常に完了した場合は、リカバリした表領域をオンラインにする前に、その表領域をバックアップします。

たとえば、次のコマンドを入力します。

BACKUP TABLESPACE users, tools;

表領域に対してTSPITRを実行し、TSPITRが正常に完了した場合、表領域の以前のバックアップは使用できなくなります。バックアップを作成せずにリカバリした表領域を使用すると、これらの表領域の使用可能なバックアップが存在しない状態でデータベースを実行することになります。

7. 表領域をオンラインに戻します。
たとえば、次のコマンドを入力します。

RMAN> SQL "ALTER TABLESPACE users, tools ONLINE";

これで、リカバリした表領域を使用できます。

RMAN管理の補助インスタンスを使用したRMANのTSPITRに対するデフォルトの変更

RMANのTSPITRでは、多くの操作で「完全に自動化されたRMANのTSPITRの実行」の手順に従う必要がありますが、次のタスクはカスタマイズできます。

- TSPITRの実行後に、リカバリした表領域を構成するデータファイルが元の場所に格納されないように、リカバリ・セットのデータファイルを名前変更または再配置するタスク。これは、表領域が格納されていたディスクを使用できない場合などに行う必要があります。
このタスクについては、「SET NEWNAMEを使用したTSPITRのリカバリ・セットのデータファイル名の変更」を参照してください。

- 補助セットの一部またはすべてのデータファイルの格納場所を、補助の宛先以外の場所に指定するタスク。このオプションは、すべての補助セット・ファイルを格納するための十分な領域がある場所がディスク上に存在しない場合に選択します。
このタスクについては、「TSPITRの補助セットのデータファイル名の指定」を参照してください。

- ファイル名をOracle Managed Files形式に変更するタスク。
このタスクについては、「TSPITRのOMF補助セット・ファイルの名前変更時の考慮事項」を参照してください。

- TSPITRの実行中にデータファイルをリストアする必要がないように、補助セットのデータファイルのイメージ・コピー・バックアップを事前に設定するタスク。
このタスクについては、「イメージ・コピーを使用したRMANのTSPITRの高速化」を参照してください。

- RMAN管理の補助インスタンスの初期化パラメータをカスタマイズするタスク。
このタスクについては、「TSPITRにおける自動補助インスタンスの初期化パラメータのカスタマイズ」を参照してください。

SET NEWNAMEを使用したTSPITRのリカバリ・セットのデータファイル名の変更

リカバリ・セットのデータファイルは、元の場所にリストアおよびリカバリしない方がよい場合があります。SET NEWNAMEコマンドを使用すると、新しい格納場所を指定できます。リカバリ・セットに新しい格納場所を指定する場合は、RMANによって表領域の元のデータファイルが削除されません。

リカバリ・セットの新しいファイル名を指定するには、RUNブロックを作成し、そのブロック内でSET NEWNAMEコマンドを使用します。複数のファイル名が相互に競合しない名前、または現行のデータファイル名と競合しない名前を割り当ててください。例21-5に、基本的な方法を示します。

例21-5 リカバリ・セットのファイル名の変更

RUN
{
.
.
.
SET NEWNAME FOR DATAFILE 'ORACLE_HOME/oradata/trgt/users01.dbf'
TO '/newfs/users01.dbf';
...other SET NEWNAME commands...
RECOVER TABLESPACE users, tools UNTIL SEQUENCE 1300 THREAD 1;
}

この例では、RMANは次のように動作します。

- TSPITRの実行中に、指定した各データファイルを新しい場所にリストアします。

- 指定した場所にイメージ・コピーが存在し、そのチェックポイントが指定した時点よりも過去の場合には、イメージ・コピーを使用します。この条件が満たされない場合、イメージ・コピーはRMANによって上書きされます。

- 新しくリカバリしたデータファイルをターゲット制御ファイルに組み込みます。

RMANは、リカバリを実際に実行するまで、SET NEWNAMEで設定された名前とターゲット・データベースの現行のデータファイル名の間の競合を検出しません。RMANが競合を検出すると、TSPITRは失敗し、RMANはエラーをレポートします。有効なデータファイルは上書きされません。

TSPITRの補助セットのデータファイル名の指定

通常は元の場所に格納されるリカバリ・セットのデータファイルとは異なり、補助セットのデータファイルは、ターゲット・データベース内の対応する元のファイルを上書きできません。元の場所とは異なる補助セット・ファイルの格納場所を指定しない場合、TSPITRは失敗します。RMANが元のデータベース内の対応するファイルの上書きを試行し、そのファイルが使用中であることを検出した場合、障害が発生します。

補助セットのデータファイルの格納場所には、TSPITRの補助の宛先を指定する方法が最も簡単です。 ただし、RMANでは、補助セットのデータファイルの場所を制御するための代替方法がサポートされています。表21-3に、それらの方法を優先順位に従って示します。

表21-3 ファイル名を指定する場合の優先順位

順位

方法

参照先

1

SET NEWNAME

「SET NEWNAMEを使用した補助セットのデータファイル名の指定」

2

CONFIGURE AUXNAME

「補助セットのイメージ・コピーでのSET NEWNAMEおよびCONFIGURE AUXNAMEの使用」

3

DB_FILE_NAME_CONVERT

「DB_FILE_NAME_CONVERTを使用した補助セットのデータファイル名の指定」。ターゲット・データベースで補助セットに対してOMF名を使用する場合、DB_FILE_NAME_CONVERTは使用できません。「TSPITRのOMF補助セット・ファイルの名前変更時の考慮事項」を参照してください。

4

RECOVER TABLESPACEにAUXILIARY DESTINATION引数を指定(RMAN管理の補助インスタンスを使用する場合)

2つの設定が同時に適用された場合、優先順位の高い設定が優先順位の低い設定より優先されます。たとえば、補助セットの一部のデータファイルの補助名がCONFIGURE AUXNAMEで構成されているときにターゲット・データベースでRECOVER TABLESPACE... AUXILIARY DESTINATIONを実行した場合などです。

前述のいずれかの方法を使用して特定のファイルの格納場所を指定する場合でも、RMAN管理の補助インスタンスを使用する場合には、RECOVER TABLESPACEにAUXILIARY DESTINATION引数を指定することをお薦めします。これによって、補助セットのデータファイル名を変更し忘れた場合でも、TSPITRが正常に実行されます。名前を変更していないファイルは、補助の宛先に格納されます。

注意:
『Oracle Databaseバックアップおよびリカバリ・リファレンス』で説明するように、SHOW AUXNAMEコマンドを実行することによって、現行のCONFIGURE AUXNAME設定を表示できます。

TSPITRのOMF補助セット・ファイルの名前変更時の考慮事項

補助セットのデータファイルではターゲットでOracle Managed Files(OMF)を使用でき、自動ストレージ管理(ASM)または非ASMストレージを使用できます。DB_FILE_NAME_CONVERT初期化パラメータが設定されており、OMFファイルがASMストレージまたは非ASMストレージに存在する場合、TSPITRでは異なる方法で名前の変換を実行します。

ASMストレージの使用

ASMストレージを使用するOracle Managed Files(OMF)の場合は、ディスク・グループ名のみが変換されます(+DISK1から+DISK2など)。

補助インスタンスにDB_FILE_NAME_CONVERTおよびLOG_FILE_NAME_CONVERT初期化パラメータを使用して、ディスク・グループの変換を指定できます。RMANは、ASMディスク・グループ名を変換するパターンを使用し、変換されたディスク・グループの有効なOMFファイル名を生成します。次に、コマンドの例を示します。

LOG_FILE_NAME_CONVERT='+onlinelogs','+tmpasm'

DB_FILE_NAME_CONVERTおよびLOG_FILE_NAME_CONVERTパラメータがディスク・グループ名以外の部分文字列を変更する場合は、変換は無視されて、その結果のディスク・グループ名が使用されます。次に、例を示します。

DB_FILE_NAME_CONVERT='+DATAFILE/prod','+DATAFILE/tspitr'

前述のコマンドの結果は無効なASM OMFファイル名となり、変更は無視されます。かわりに、ディスク・グループ名が+DATAFILEである場所にファイルが作成され、次のメッセージが表示されます。

WARNING: DB_FILE_NAME_CONVERT resulted in invalid ASM names; names changed to disk group only

補助セットのデータファイルがASMディスク・グループに格納される場合には、SET NEWNAMEコマンドを使用して、個々のファイルを補助インスタンスからアクセスできる固有のディスク・グループにリダイレクトできます(また、データベースではディスク・グループ内でファイル名を生成できます)。例21-6に、その方法を示します。

例21-6 ASMファイルのリダイレクト

RUN
{
SET NEWNAME FOR DATAFILE 1 TO "+DISK2";
SET NEWNAME FOR DATAFILE 2 TO "+DISK3";
RECOVER TABLESPACE users, tools
UNTIL LOGSEQ 1300 THREAD 1
AUXILIARY DESTINATION '/disk1/auxdest';
}

非ASMストレージの使用

初期化パラメータDB_FILE_NAME_CONVERTおよびLOG_FILE_NAME_CONVERTは無効なOMFファイル名を生成するため、補助インスタンスのOMF(非ASM)ファイル名の変更には使用できません。ASMストレージを使用しない新しいOMFファイル名の生成を制御する必要がある場合は、次に示すいずれかの代替方法を使用して名前を変更する必要があります。名前を指定するための様々な方法を、推奨される順に示します。

1. 補助の宛先を使用します(「完全に自動化されたRMANのTSPITRの実行」を参照)。

2. 補助インスタンスにOMF初期化パラメータを1つ以上使用して、新規OMFファイルの格納場所を指定します。これにより、必要なOMFファイルをすべて管理できるようになります。

- 補助セットのデータファイルに対しては、DB_CREATE_FILE_DESTを使用します。

- オンライン・ログがDB_CREATE_FILE_DESTに作成されない場合には、補助インスタンスのオンラインREDOログに対して、DB_CREATE_ONLINE_LOG_DEST_nとDB_CREATE_FILE_DESTを使用します。

SET NEWNAMEを使用した補助セットのデータファイル名の指定

補助セットのデータファイルに新しい名前を指定するには、RECOVER TABLESPACEコマンドをRUNブロックに含め、SET NEWNAMEコマンドをRUNブロック内で使用してファイル名を変更します。例21-7に、基本的な方法を示します。

例21-7 TSPITRでの補助セットのOracle Managed Files(OMF)の名前の変更

RUN
{
SET NEWNAME FOR DATAFILE '?/oradata/prod/system01.dbf'
TO '/disk1/auxdest/system01.dbf';
SET NEWNAME FOR DATAFILE '?/oradata/prod/sysaux01.dbf'
TO '/disk1/auxdest/sysaux01.dbf';
SET NEWNAME FOR DATAFILE '?/oradata/prod/undotbs01.dbf'
TO '/disk1/auxdest/undotbs01.dbf';
RECOVER TABLESPACE users, tools
UNTIL LOGSEQ 1300 THREAD 1
AUXILIARY DESTINATION '/disk1/auxdest';
}

この結果は、RECOVER TABLESPACEの実行時に/disk1/auxdest/system01.dbfが存在するかどうかによって異なります。?/oradata/system01.dbfが指定した場所に存在し、TSPITRのUNTILの時点より前のSCNで作成されている場合、DATAFILECOPYが使用されるためリストア操作は必要ありません。詳細は、「補助セットのイメージ・コピーでのSET NEWNAMEおよびCONFIGURE AUXNAMEの使用」を参照してください。それ以外の場合、RMANは、デフォルトの場所ではなくNEWNAMEで指定した場所に補助セットのデータファイルをリストアします。補助セットのデータファイルが格納される場所を制御する場合は、TSPITRの実行前にSET NEWNAMEで指定した場所にファイルが格納されていないことを確認します。

DB_FILE_NAME_CONVERTを使用した補助セットのデータファイル名の指定

補助セットのすべてのデータファイルには補助の宛先を使用せず、すべてのデータファイルには個々に名前も指定しない場合を想定します。この場合、補助インスタンスで使用される初期化パラメータ・ファイルに、DB_FILE_NAME_CONVERT初期化パラメータを含めることができます。この方法は、次の場合にのみ使用できます。

次のいずれかの状況が該当します。

- 「TSPITRにおける自動補助インスタンスの初期化パラメータのカスタマイズ」で説明するように、自動管理補助インスタンスに対して独自の初期化パラメータ・ファイルを作成する場合

- 「独自の補助インスタンスを使用したRMANのTSPITRの実行」で説明するように、独自の補助インスタンスを作成する場合

補助インスタンス内のDB_FILE_NAME_CONVERT初期化パラメータによって、ターゲット・データベース・インスタンス内の対応するファイルの元の名前から補助インスタンスのファイルの名前を導出する方法が指定されます。このパラメータは、文字列のペアのリストで構成されます。ペアの1つ目の文字列を含むファイル名の場合、補助インスタンスの一致するファイル名は、ペアの2つ目の文字列を元のファイル名に置き換えることによって生成されます。

たとえば、ターゲット・インスタンスに次のファイルが含まれているとします。

- SYSTEM表領域の?/oradata/trgt/system01.dbf

- SYSAUX表領域の?/oradata/trgt/sysaux01.dbf

- undotbs表領域の?/oradata/trgt/undotbs01.dbf

補助インスタンス内の対応するファイルを/bigtmp内に配置する場合は、次の行を補助インスタンスのパラメータ・ファイルに追加します。

DB_FILE_NAME_CONVERT=('?/oradata/trgt', '/bigtmp')

対応する補助インスタンス・ファイルの新しいファイル名は、/bigtmp/trgt/system01.dbf、/bigtmp/trgt/sysaux01.dbfおよび/bigtmp/trgt/undotbs01.dbfです。

最も重要な点は、補助インスタンスのパラメータ・ファイルにDB_FILE_NAME_CONVERTを含める必要があることです。補助インスタンスを手動で作成した場合は、その補助インスタンスのパラメータ・ファイルにDB_FILE_NAME_CONVERTを追加します。

SET NEWNAMEまたはCONFIGURE AUXNAMEコマンドを使用して、補助セットの個々のデータファイル名を変更することもできます。また、DB_FILE_NAME_CONVERTで指定したパターンと一致しないファイルの名前は変更されません。RMAN管理の補助インスタンスを使用する場合、RECOVER TABLESPACEコマンドのAUXILIARY DESTINATIONパラメータを使用して、補助セットのすべてのデータファイルが格納場所に転送されていることを確認できます。使用した名前の変更方法によって補助インスタンスの新しいファイル名が提供されない場合、TSPITRは失敗します。

TSPITRの実行中の一時ファイルの名前の変更

一時ファイルは、データベースの補助セットの一部とみなされます。補助インスタンスのインスタンス化時に、RMANは、ターゲット・データベースの一時表領域を再作成し、補助データファイル名の通常の規則を使用して名前を生成します。

一時ファイルの名前を変更するには、次のいずれかを使用できます。

- SET NEWNAME FOR TEMPFILEコマンド

- 補助インスタンスのDB_FILE_NAME_CONVERT初期化パラメータ。前述の例を参照してください。一時ファイルがASM Oracle Managed Filesの名前でない場合、このパラメータを使用する方法は使用できません。「TSPITRのOMF補助セット・ファイルの名前変更時の考慮事項」を参照してください。

- RECOVERコマンドのAUXILIARY DESTINATION句(RMAN管理の補助インスタンスを使用する場合)

イメージ・コピーを使用したRMANのTSPITRの高速化

リカバリ・セットおよび補助セットのデータファイルの既存のイメージ・コピーをRMANが使用するようにリダイレクトすることによって、TSPITRのパフォーマンスを向上させることができます。この場合、RMANはバックアップからデータファイルをリストアする必要がありません。次の方法を使用して、データファイルのイメージ・コピーの存在をRMANに認識させることができます。

- 補助セットのデータファイルのイメージ・コピーを指定してCONFIGURE AUXNAMEコマンドを使用します

- リカバリ・セットのデータファイルまたは補助セットのデータファイルのイメージ・コピーを指定してSET NEWNAMEコマンドを使用します

通常、指定した場所で適切なイメージ・コピーが使用可能な場合、RMANはそのイメージ・コピーを使用してTSPITRを実行し、データファイル・コピーは、ターゲット制御ファイルのカタログから削除されます。

リカバリ・セットのイメージ・コピーでのSET NEWNAMEの使用

TSPITRの実行中、RMANは、NEWNAMEで指定した場所でデータファイルを検索します。RMANは、目標時点までリカバリ可能な古いデータファイル・チェックポイントSCNを持つデータファイルのイメージ・コピー・バックアップが存在するかどうかを確認します。使用可能なイメージ・コピーが検出されると、RMANは、そのイメージ・コピーをTSPITRで使用します。それ以外の場合、RMANは、NEWNAMEで指定した場所にデータファイルをリストアします。NEWNAMEで指定した場所のすべてのファイルが上書きされます。TSPITRが完了すると、指定したNEWNAMEがターゲット・データベースのデータファイルの名前になります。例21-8に、この方法を示します。

例21-8 SET NEWNAMEの使用

RUN
{
SET NEWNAME FOR DATAFILE 'ORACLE_HOME/oradata/trgt/users01.dbf'
TO '/newfs/users1.dbf';
...other RMAN commands, if any...
RECOVER TABLESPACE users, tools UNTIL SEQUENCE 1300 THREAD 1;
}

補助セットのイメージ・コピーでのSET NEWNAMEおよびCONFIGURE AUXNAMEの使用

CONFIGURE AUXNAMEコマンドを使用すると、補助セットのデータファイルのイメージ・コピーの永続的な代替格納場所を設定できます。一方、SET NEWNAMEコマンドを使用すると、RUNコマンド実行中の代替格納場所を設定できます。

SET NEWNAMEまたはCONFIGURE AUXNAMEを使用して、補助セットのデータファイルの新しい格納場所を指定するとします。また、TSPITRで使用可能なSCNを持つイメージ・コピーがその場所に存在するとします。この場合、RMANはイメージ・コピーを使用します。ただし、使用可能なイメージ・コピーがその場所に存在しない場合、RMANは、使用可能なコピーをバックアップからリストアします。(イメージ・コピーは存在するが、SCNがTSPITRの目標時点より後の場合は、リストアしたファイルによってデータファイルが上書きされます。)

すべての補助セット・ファイルと同様に、TSPITRが実行されるとファイルは削除されます。そのファイルが、TSPITRの実行前に作成されたイメージ・コピーであるか、TSPITRの実行中にRMANによってバックアップからリストアされたかに関係なく、このように動作します。

CONFIGURE AUXNAMEは、主にリストア時間を削減してTSPITRを高速化するために使用されます。TSPITRを実行する可能性がある場合は、補助セットのデータファイルのイメージ・コピー・セットをバックアップ・ルーチンで保持し、そのデータファイルのイメージ・コピーをTSPITRを実行する可能性がある最も早い目標時点まで定期的に更新できます。推奨される実行手順のモデルは、次のとおりです。

1. この計画の作成時に、ファイルに対してAUXNAMEを1回構成します。

2. BACKUP AS COPY DATAFILE n FORMAT auxnameを定期的に実行して、更新されたイメージ・コピーを保持します。パフォーマンスを向上させるために、増分更新バックアップ方法を使用して、データファイルの全体バックアップを実行せずにイメージ・コピーを最新に保ちます。

3. TSPITRを実行する必要がある場合は、イメージ・コピーの最新の更新より後の目標時点を指定します。

CONFIGURE AUXNAMEおよびイメージ・コピーを使用したTSPITRの実行の例

TSPITRで使用するデータベース全体のイメージ・コピーを保存するための十分なディスク領域があるとします。TSPITRを実行する必要がある場合の準備として、次の手順を実行します。

- 次の形式のコマンドを使用して、補助セット内の各データファイルのAUXNAMEを構成します。

CONFIGURE AUXNAME FOR DATAFILE n TO auxname_n;

- 次の形式のコマンドを使用して、毎週日曜日に補助セットのイメージ・コピーを作成します。

BACKUP AS COPY DATAFILE n FORMAT auxname_n

すべてのイメージ・コピーがディスクの同じ場所に格納され、元のデータファイルに類似した名前が付けられている場合は、すべてのデータファイルのバックアップが個々に実行されないようにできます。かわりに、BACKUPコマンドのFORMATまたはDB_FILE_NAME_CONVERTオプションを指定して、BACKUP AS COPY DATABASEを使用できます。たとえば、構成した補助名が場所maindiskをauxdiskに変換したものである場合は、次のコマンドを使用します。

BACKUP AS COPY
DATABASE
DB_FILE_NAME_CONVERT (maindisk, auxdisk);

注意:
通常、Oracle Managed Filesの名前は簡単な置換を使用して変換できないため、DB_FILE_NAME_CONVERTを使用して、OMFに格納されたイメージ・コピーの名前を生成することはできません。

これらの手順の後、バックアップから補助セットをリストアせずにTSPITRの準備が完了します。たとえば、2007年11月15日19:00:00に誤ったバッチ・ジョブが開始され、これによって表領域partsの表が不正に更新された場合、次のコマンドを使用して、表領域partsでTSPITRを実行します。

RECOVER TABLESPACE parts UNTIL TIME 'November 15 2007, 19:00:00';

AUXNAMEの場所を構成すると、TSPITRの目標時点より前のSCN以降のデータファイルのコピーを参照するため、補助セットはバックアップからリストアされません。かわりに、データファイルのコピーはリカバリに使用され、リストアのオーバーヘッドが減少します。

また、リカバリ・セットがリストアされないようにすることもできます。表領域のイメージ・コピーを頻繁に作成し、SET NEWNAMEを使用してこれらのコピーの場所を指定する必要があります。この方法を使用すると、TSPITRが正常に完了した後にリカバリ・セットはリストアされず、表領域の場所が変更されます。

TSPITRにおける自動補助インスタンスの初期化パラメータのカスタマイズ

自動補助インスタンスでは、表21-4に示すデフォルトの初期化パラメータのセットが使用されます。また、デフォルトのパラメータを補完する追加の初期化パラメータがオペレーティング・システム依存の場所で検索されます。たとえば、UNIXの場合、この場所は?/rdbms/admin/params_auxinst.oraです。TSPITRの実行時、RMANでは、常に、RMAN自動補助インスタンスの追加のパラメータが検索されます。ファイルが検出されない場合でも、RMANでエラーは発生しません。かわりに、RMANでは、RMAN管理の自動補助インスタンスに対して表21-4のデフォルト・パラメータを使用します。

表21-4 RMAN管理の補助インスタンスに対するデフォルトの初期化パラメータ

初期化パラメータ

値

DB_NAME

ソース・データベースのDB_NAMEと同じです

COMPATIBLE

ターゲット・データベースのCOMPATIBLE設定と同じです

DB_UNIQUE_NAME

DB_NAMEの値に基づいてRMANで自動生成された一意の値。

DB_BLOCK_SIZE

ターゲット・データベースのDB_BLOCK_SIZEと同じです

DB_CREATE_FILE_DEST

補助の宛先(RMAN管理の補助インスタンスの使用時に、AUXILIARY DESTINATION引数が設定されている場合のみ)。RMANは、この場所の補助セット・ファイルに対してOracle Managed Filesを作成します。

LOG_ARCHIVE_DEST_1

補助の宛先(RMAN管理の補助インスタンスの使用時に、AUXILIARY DESTINATION句が設定されている場合のみ)。リカバリに必要なアーカイブ・ログがこの場所にリストアされます。

SGA_TARGET

280M

DB_FILES

ターゲット・データベースのDB_FILESと同じです。

PROCESSES

50

通常、特に、RMAN管理の補助インスタンスの使用時にRECOVER TABLESPACEコマンドに対してAUXILIARY DESTINATION句を指定する場合には、これらの初期化パラメータの値を変更または追加する必要はありません。表21-4の初期化パラメータの1つを不適切な値で上書きすると、補助インスタンスで問題が発生し、TSPITRが失敗する場合があります。ただし、これらの基本パラメータ以外に、その他のパラメータも必要に応じて追加できます。たとえば、DB_FILE_NAME_CONVERTを使用して補助セットおよびリカバリ・セットのデータファイルの名前を指定できます。

自動補助インスタンスのパラメータを変更または指定するには、次のいずれかの手順に従います。

- オペレーティング・システム固有のデフォルトの補助パラメータのファイル名に、初期化パラメータを設定します。たとえば、UNIXの場合、ファイル名は?/rdbms/admin/params_auxinst.oraです。

- 次の手順を実行します。

1. ファイルに初期化パラメータを設定します。

2. TSPITRを実行する前に、SET AUXILIARY INSTANCE PARAMETER FILEコマンドを使用して、そのファイルの場所を指定します。

いずれの方法を選択した場合も、指定したパラメータはデフォルトよりも優先され、AUXILIARY DESTINATION句の値が変更されます。

TSPITRにおける補助インスタンスの制御ファイルの格納場所の指定

初期化パラメータ・ファイルを使用すると、補助インスタンスの制御ファイルに対して独自の格納場所を指定できます。CONTROL_FILES初期化パラメータを設定して、制御ファイルの格納場所を指定します。

制御ファイルの格納場所を明示的に指定しない場合、AUXILIARY DESTINATION句を使用すると、RMANは、そのファイルを補助の宛先に格納します。AUXILIARY DESTINATION句を使用しない場合、補助インスタンスの制御ファイルは、オペレーティング・システム固有の場所に格納されます。

格納場所にかかわらず、補助インスタンスの制御ファイルは、TSPITR操作が実行された後に削除されます。制御ファイルはサイズが比較的小さいため、RMANで補助制御ファイルの作成時に問題が発生することはほとんどありません。ただし、制御ファイルを作成するための十分な領域がない場合、TSPITRは失敗します。

TSPITRにおける補助インスタンスのアーカイブ・ログの指定

補助インスタンスで補助セットおよびリカバリ・セットをリストアした後、それらのセットに対してリカバリを実行するには、RMANでアーカイブ・ログをリストアする必要がある場合があります。補助の宛先が使用されている場合、アーカイブ・ログはその場所にリストアされます。補助の宛先および他の初期化パラメータがない場合、アーカイブ・ログはオペレーティング・システム固有の場所にリストアされます。詳細は、ご使用のオペレーティング・システム固有のドキュメントを参照してください。アーカイブ・ログがリストアされる代替の場所を指定するには、LOG_ARCHIVE_DEST_1初期化パラメータを使用できます。

TSPITRにおける補助インスタンスのオンライン・ログの格納場所の指定

補助インスタンスのパラメータ・ファイルでLOG_FILE_NAME_CONVERT初期化パラメータを指定して、ターゲットのオンラインREDOログの名前が正常に変換できる場合は、このパラメータによってオンラインREDOログの格納場所が決定されます。OMFデータファイルに適用される制限と同じ制限が、OMFオンラインREDOログに適用されます。詳細は、「TSPITRのOMF補助セット・ファイルの名前変更時の考慮事項」を参照してください。RMANによって補助インスタンスが管理され、補助の宛先が指定される場合は、補助の宛先にオンラインREDOログが作成されます。

また、DB_CREATE_FILE_DESTを使用するか、DB_CREATE_FILE_DESTおよびDB_CREATE_ONLINE_LOG_1を使用して、補助インスタンスREDOログを作成する場所を指定できます。後者の方法を選択する場合は、DB_CREATE_ONLINE_LOG_1をDB_CREATE_FILE_DESTとともに使用する必要があります。

次のいずれかを使用してオンラインREDOログの格納場所を指定しないと、TSPITRでオンラインREDOログは作成されません。

- LOG_FILE_NAME_CONVERT

- DB_CREATE_FILE_DEST

- DB_CREATE_FILE_DESTおよびDB_CREATE_ONLINE_LOG_1

- AUXILIARY DESTINATION

独自の補助インスタンスを使用したRMANのTSPITRの実行

RMANで補助インスタンスのすべての手順を管理することをお薦めしますが、ユーザー独自の補助インスタンスを作成および管理することもできます。このモードを選択した場合、TSPITRで使用する補助インスタンスの設定、起動、停止およびクリーンアップは、ユーザーが行う必要があります。

ユーザー独自のインスタンスを作成する理由の1つとして、TSPITRで使用されるチャネルを制御できることがあげられます。自動補助インスタンスでは、ターゲット・データベースの構成済チャネルが、補助インスタンスで構成されてリストア操作中に使用されるチャネルの基本チャネルとして使用されます。ターゲット・データベースの設定を変更するために、CONFIGUREコマンドを使用せずに異なるチャネルを設定する必要がある場合があります。この場合、独自の補助インスタンスを使用できます。RECOVERを起動する前に補助インスタンスに接続すると、RUNブロックではALLOCATE AUXILIARY CHANNELコマンドを使用して、特定のチャネルの割当てを行うことができます。

RMANのTSPITRに使用する独自の補助インスタンスの準備

補助インスタンスとしての使用に適したOracleインスタンスを作成するには、次のすべての手順を実行する必要があります。

- 手順1: 補助インスタンス用のOracleパスワード・ファイルの作成

- 手順2: 補助インスタンス用の初期化パラメータ・ファイルの作成

- 手順3: Oracle Netから補助インスタンスへの接続性の確認

手順1: 補助インスタンス用のOracleパスワード・ファイルの作成

Oracleパスワード・ファイルを作成およびメンテナンスする方法については、『Oracle Database管理者ガイド』を参照してください。

手順2: 補助インスタンス用の初期化パラメータ・ファイルの作成

テキスト・エディタを使用して、ターゲット・データベース・ホストで補助インスタンスの初期化パラメータ・ファイルを作成します。この例では、パラメータ・ファイルが/tmp/initAux.oraに格納されていると想定します。表21-5に示すパラメータを設定します。

注意:
TSPITRの場合、ターゲット・データベースおよび補助データベースは同一ホスト上にある必要があります。

表21-5 ユーザー管理の補助インスタンスの初期化パラメータ

パラメータ

必須かどうか

値

DB_NAME

必須

ターゲット・データベースと同じ名前

DB_UNIQUE_NAME

必須

同じOracleホーム内のいずれのデータベースとも異なる値。簡略化するために、_dbnameを指定します。たとえば、ターゲット・データベース名がtrgtの場合は、_trgtを指定します。

REMOTE_LOGIN_PASSWORDFILE

必須

EXCLUSIVE(パスワード・ファイルを使用して補助インスタンスに接続する場合)。それ以外の場合は、NONEに設定します。

COMPATIBLE

必須

ターゲット・データベースのパラメータと同じ値

DB_BLOCK_SIZE

必須

補助インスタンスと同じ値(この初期化パラメータがターゲット・データベースで設定されている場合)。

LOG_FILE_NAME_CONVERT

任意

補助データベースのオンラインREDOログのファイル名を生成するパターン。ターゲット・データベースのオンラインREDOログ名に基づきます。V$LOGFILE.MEMBERを問い合せてターゲット・インスタンスのオンラインREDOログのファイル名を取得し、変換パターンがビューに表示されたファイル名の書式と一致することを確認します。

注意: 末尾にスラッシュ(\または/)を指定するパターンがサポートされていないプラットフォームもあります。

参照: OMFファイル名を使用したLOG_FILE_NAME_CONVERTに対して設定可能な値の制限については、「TSPITRにおける補助インスタンスのオンライン・ログの格納場所の指定」を参照してください。また、「TSPITRのOMF補助セット・ファイルの名前変更時の考慮事項」を参照してください。

DB_FILE_NAME_CONVERT

任意

補助データベースのデータファイルのファイル名を変換するパターン。このパラメータを使用すると、SET NEWNAMEまたはCONFIGURE AUXNAMEで名前を付けなかったファイルのファイル名を生成できます。 V$DATAFILE.NAMEを問い合せてデータファイルのファイル名を取得し、変換パターンがビューに表示されたファイル名の書式と一致することを確認します。

注意: 末尾にスラッシュ(\または/)を指定するパターンがサポートされていないプラットフォームもあります。

参照: 「DB_FILE_NAME_CONVERTを使用した補助セットのデータファイル名の指定」および「TSPITRのOMF補助セット・ファイルの名前変更時の考慮事項」を参照してください。

DB_CREATE_FILE_DEST

任意

すべての補助セット・ファイルの場所を指定するために使用します。

LOG_ARCHIVE_DEST_n

任意

リカバリに必要なアーカイブ・ログの作成場所を指定するために使用します。

DB_CREATE_ONLINE_LOG_n

任意

オンラインREDOログの作成場所を別に指定するためにDB_CREATE_FILE_DESTとともに使用します。

CONTROL_FILES

任意

ターゲット・インスタンス(または他の既存のファイル)の制御ファイル名と競合しないファイル名。

SGA_TARGET

任意(推奨)

280M

STREAMS_POOL_SIZE

任意

必須

SGA_TARGETが設定されている場合

SGA_TARGETが設定されていない場合

必要に応じて、補助インスタンスが使用するメモリー量を指定するパラメータなど、その他のパラメータを設定します。

次に、TSPITRの補助インスタンスで設定可能な初期化パラメータの例を示します。

DB_NAME=trgt
DB_UNIQUE_NAME=_trgt
CONTROL_FILES=/tmp/control01.ctl
DB_FILE_NAME_CONVERT=('/oracle/oradata/trgt/','/tmp/')
LOG_FILE_NAME_CONVERT=('/oracle/oradata/trgt/redo','/tmp/redo')
REMOTE_LOGIN_PASSWORDFILE=exclusive
COMPATIBLE =11.0.0
DB_BLOCK_SIZE=8192

注意:
これらの初期化パラメータを設定した後、ターゲット・データベースの本番ファイルの初期化設定を上書きしていないことを確認してください。

手順3: Oracle Netから補助インスタンスへの接続性の確認

補助インスタンスには、有効なネット・サービス名が必要です。先に進む前に、SQL*Plusを使用して補助インスタンスにSYSDBAで接続できることを確認します。

関連項目:
Oracle Netの詳細は、『Oracle Database Net Services管理者ガイド』を参照してください。

独自の補助インスタンスを使用したTSPITRに使用するRMANコマンドの準備

独自の補助インスタンスを実行すると、TSPITRに必要な一連のコマンドが長くなる場合があります。この状況は、バックアップからのリストアに複雑なチャネル構成を割り当てたり、DB_CREATE_FILE_DESTを使用せずに補助セット・ファイルのファイル名を指定した場合に発生する可能性があります。

TSPITRに使用する一連のコマンドは、RMANのコマンド・ファイルに格納できます。コマンド・ファイルにエラーがないかを慎重に確認します。このコマンド・ファイルをRMANに読み込むには、@コマンド(またはRMANの起動時にCMDFILEコマンドライン引数)を使用します。

次の例では、/tmp/tspitr.rmanというコマンド・ファイルを実行します。

@/tmp/tspitr.rman;

関連項目:
「RMANでのコマンド・ファイルの使用」

独自の補助インスタンスを使用したTSPITRに使用するチャネルの計画

独自の補助インスタンスを実行すると、デフォルトでターゲット・インスタンスの自動チャネル構成が使用されます。独自のチャネルに異なる構成を割り当てる場合(チャネル数やチャネル・パラメータを変更する場合)は、RUNブロックにALLOCATE AUXILIARY CHANNELコマンドおよびTSPITR用のRECOVER TABLESPACEコマンドを含めることができます。必要に応じてこれらのコマンドの使用を計画し、TSPITRに使用する一連のコマンドに追加します。

関連項目:
TSPITRスクリプトにチャネル割当てを含める方法については、「独自の補助インスタンスを使用したTSPITRの実行例」を参照してください。

独自の補助インスタンスのデータファイル名の計画: SET NEWNAME

SET NEWNAMEコマンドを使用して、補助セット・ファイルの既存のイメージ・コピーを参照してTSPITRのパフォーマンスを向上させるか、またはTSPITRの実行後にリカバリ・セット・ファイルに新しい名前を割り当てることができます。必要に応じてこれらのコマンドの使用を計画し、TSPITRで実行する一連のコマンドに追加します。詳細は、「SET NEWNAMEを使用したTSPITRのリカバリ・セットのデータファイル名の変更」を参照してください。

独自の補助インスタンスを使用したTSPITRの実行

準備およびTSPITRコマンドの計画が完了すると、TSPITRを実行できます。次の手順を実行する必要があります。

- 手順1: NOMOUNTモードでの補助インスタンスの起動

- 手順2: ターゲット・インスタンスおよび補助インスタンスへのRMANクライアントの接続

- 手順3: RECOVER TABLESPACEコマンドの実行

手順1: NOMOUNTモードでの補助インスタンスの起動

RMANのTSPITRを開始する前に、SQL*Plusを起動してSYSOPER権限で補助インスタンスに接続します。

補助インスタンスをNOMOUNTモードで起動し、必要に応じてパラメータ・ファイルを指定します。たとえば、次のSQL*Plusコマンドを入力します。

SQL> STARTUP NOMOUNT PFILE='/tmp/initAux.ora'

PFILEを指定する場合は、PFILEのパスに、SQL*Plusを実行するホスト上のクライアント側のパスを指定することに注意してください。

補助インスタンスに制御ファイルがないため、このインスタンスはNOMOUNTモードでのみ起動できます。制御ファイルを作成したり、TSPITR用の補助インスタンスをマウントまたはオープンしないでください。

手順2: ターゲット・インスタンスおよび補助インスタンスへのRMANクライアントの接続

RMANを起動し、ターゲット・データベースおよび手動で作成した補助インスタンスに接続します。

$rman target dba/dbapwd AUXILIARY aux/auxpwd@aux

手順3: RECOVER TABLESPACEコマンドの実行

最も簡単な方法は、RMANプロンプトでRECOVER TABLESPACE ... UNTILコマンドを実行する方法です。

RECOVER TABLESPACE ts1, ts2... UNTIL TIME 'time';

ALLOCATE AUXILIARY CHANNELコマンドまたはSET NEWNAMEコマンドを使用する場合は、RUNコマンドでRECOVER TABLESPACEコマンドの前にこれらのコマンドを指定します。次に、この方法の例を示します。

RUN
{
ALLOCATE AUXILIARY CHANNEL c1 DEVICE TYPE DISK;
ALLOCATE AUXILIARY CHANNEL c2 DEVICE TYPE sbt;
# and so on...
RECOVER TABLESPACE ts1, ts2 UNTIL TIME 'time';
}

独自の補助インスタンスを使用したTSPITRの実行例

この項では、RECOVER TABLESPACE... UNTIL操作の実行例を示します。この実行例では、RMANのTSPITRの次の機能について説明します。

- 独自の補助インスタンスの管理

- ディスクおよびSBTデバイスからのバックアップのリストアに対するチャネルの構成

- SET NEWNAMEを使用した補助セットのデータファイルのリカバリ可能なイメージ・コピーの使用

- SET NEWNAMEを使用したリカバリ・セットのデータファイルの新しい名前の指定

TSPITRを独自の補助インスタンスとともに使用する手順

1. 「RMANのTSPITRに使用する独自の補助インスタンスの準備」で説明するように、補助インスタンスを準備します。補助インスタンスのパスワードをパスワード・ファイルに指定し、補助インスタンス・パラメータ・ファイル/bigtmp/init_tspitr_prod.oraを次のように設定します。

DB_NAME=PROD
DB_UNIQUE_NAME=tspitr_PROD
CONTROL_FILES=/bigtmp/tspitr_cntrl.dbf
DB_CREATE_FILE_DEST=/bigtmp
COMPATIBLE=11.0.0
BLOCK_SIZE=8192
REMOTE_LOGIN_PASSWORD=exclusive

2. 補助インスタンスのサービス名pitprodを作成し、接続性を確認します。

3. SQL*Plusを使用して、SYSOPER権限で補助インスタンスに接続します。インスタンスをNOMOUNTモードで起動します。

SQL> STARTUP NOMOUNT PFILE=/bigtmp/init_tspitr_prod.ora

4. RMANを起動し、ターゲット・データベース・インスタンスおよび補助データベース・インスタンスに接続します。

rman target / auxiliary sys/syspwd@pitprod

5. 次のコマンドをRUNブロック内で入力し、TSPITRを設定および実行します。

RUN
{
# Specify NEWNAME for recovery set data files
SET NEWNAME FOR TABLESPACE clients
TO '?/oradata/prod/rec/%b';

# Specify NEWNAMES for some auxiliary set
# data files that have a valid image copy to avoid restores:
SET NEWNAME FOR DATAFILE '?/oradata/prod/system01.dbf'
TO '/backups/prod/system01_monday_noon.dbf';
SET NEWNAME FOR DATAFILE '?/oradata/prod/system02.dbf'
TO '/backups/prod/system02_monday_noon.dbf';
SET NEWNAME FOR DATAFILE '?/oradata/prod/sysaux01.dbf'
TO '/backups/prod/sysaux01_monday_noon.dbf';
SET NEWNAME FOR DATAFILE '?/oradata/prod/undo01.dbf'
TO '/backups/prod/undo01_monday_noon.dbf';

# Specify the types of channels to use
ALLOCATE AUXILIARY CHANNEL c1 DEVICE TYPE DISK;
ALLOCATE AUXILIARY CHANNEL t1 DEVICE TYPE sbt;

# Recover the clients tablespace to 24 hours ago:
RECOVER TABLESPACE clients UNTIL TIME 'sysdate-1';
}

コマンド・ファイルにこの一連のコマンドを格納し、コマンド・ファイルを実行することを検討してください。

TSPITR操作が正常に実行されると、結果は次のようになります。

- リカバリ・セットのデータファイルが、SET NEWNAMEで指定した名前およびTSPITRの目標時点の内容で、ターゲット・データベースの制御ファイルに登録されます。

- RMANによって、補助インスタンスの制御ファイル、オンライン・ログ、補助セットのデータファイルなどの補助ファイルが削除されます。

- 補助インスタンスが停止します。

TSPITR操作に失敗すると、補助セット・ファイルが削除され、補助インスタンスが停止します。リカバリ・セット・ファイルは指定された場所に残り、TSPITRの実行の失敗から未解決の状態となります。

RMANのTSPITRのトラブルシューティング

様々な問題によって、RMANのTSPITRが失敗する可能性があります。この項では、確認および修正が可能な場合について説明します。

- ファイル名の競合

- 表領域のセットおよびUNDOセグメントに対するTSPITRの目標時点の不一致または不正

- RMANを使用せずに作成した補助インスタンスの管理に関する問題

ファイル名の競合のトラブルシューティング

ターゲット・データベース内の既存のファイル、SET NEWNAMEまたはCONFIGURE AUXNAMEコマンドで割り当てられたファイル名と、DB_FILE_NAME_CONVERTパラメータの影響で生成されたファイル名の間で、名前の競合が発生する場合があります。

SET NEWNAME、CONFIGURE AUXNAMEおよびDB_FILE_NAME_CONVERTを使用したため、補助セットまたはリカバリ・セット内の複数のファイルに同じ名前が指定されたとします。この場合、RMANは、TSPITRの実行中にエラーをレポートします。この問題を解決するには、これらのパラメータに異なる値を使用します。

UNDOセグメントを含む表領域の識別のトラブルシューティング

TSPITR中は、RMANではTSPITRターゲット時刻にUNDOセグメントがあったのはどの表領域かという情報が必要です。通常、この情報は、リカバリ・カタログを使用している場合はそのリカバリ・カタログにあります。

リカバリ・カタログが存在していない場合、またはリカバリ・カタログで情報が検出されない場合、RMANは、目標時点でUNDOセグメントが含まれていた表領域のセットが、現在UNDOセグメントが含まれている表領域のセットと同じであるとみなします。この仮定が正しくない場合、TSPITRは失敗してエラーが表示されます。この場合は、UNDO TABLESPACE句を使用して、目標時点でのUNDOセグメントを表領域のリストに含めます。

TSPITRの失敗後の手動による補助インスタンスの再起動のトラブルシューティング

独自の補助インスタンスを管理しているときにTSPITRが失敗した場合は、エラーを解決してから、次の方法に従ってTSPITRを再実行してください。

1. TSPITRが正常に実行されなかった原因を特定して修正します。

2. 補助インスタンスをNOMOUNTで起動します。

3. TSPITRを再実行します。

第VI部

チューニングおよびトラブルシューティング

次の章では、RMAN操作のチューニングおよびトラブルシューティングの方法について説明します。この部に含まれる章は、次のとおりです。

- 第22章「RMANのパフォーマンスのチューニング」

- 第23章「RMAN操作のトラブルシューティング」

22 RMANのパフォーマンスのチューニング

この章の内容は次のとおりです。

- RMANのパフォーマンスのチューニングの目的

- RMANのパフォーマンスのチューニングの基本的な概念

- RMANのパフォーマンスの問題を診断するためのV$ビューの使用方法

- RMANのバックアップのパフォーマンスのチューニング

RMANのパフォーマンスのチューニングの目的

RMANのバックアップ・ジョブまたはリストア・ジョブは、別々のフェーズまたはコンポーネントに分けることができます。RMANジョブでのこれらのフェーズのうち、最も低速なものをボトルネックといいます。RMANのチューニングの目的は、ジョブのボトルネックを特定し、RMANコマンド、初期化パラメータまたは物理メディアの調整を利用して、パフォーマンスを向上することです。

RMANのパフォーマンスのチューニングの基本的な概念

RMANのパフォーマンスをチューニングするには、RMANがバックアップをどのように作成するかについて、詳細に理解しておく必要があります。「RMANチャネル」で説明されているように、バックアップの作業は、1つ以上のチャネルで実行されます。チャネルは、ストレージ・デバイスへのバイト・ストリームを表しています。

バイト・ストリームは、メモリー内の入力バッファからCPU経由で出力バッファに渡され、さらにそこからストレージ・デバイスに渡されます。2つのテープ・デバイスにバックアップするように指定するには、2つのテープ・チャネルを割り当て、各バイト・ストリームが別々のデバイスに渡されるようにします。

各チャネルの作業は、チャネルのタイプがディスクまたはシステム・バックアップ・テープ(SBT)のいずれであるかにかかわらず、次のフェーズに細分化されます。

1. 読取りフェーズ
ディスクのブロックが入力バッファに読み取られます。

2. コピー・フェーズ
入力バッファから出力バッファにブロックがコピーされ、ブロックに対する追加処理が実行されます。

3. 書込みフェーズ
出力バッファのブロックがストレージ・メディアに書き込まれます。書込みフェーズは、バックアップ・メディアのタイプに応じて、次の相互排他的な形式のいずれかになります。

- システム・バックアップ・テープ(SBT)への書込みフェーズ

- ディスクへの書込みフェーズ

図22-1に、3つのディスクに格納されているデータをバックアップする2つのチャネルを示します。各チャネルはデータを入力バッファに読み取り、入力バッファから出力バッファへのコピー時にデータを処理し、出力バッファからのデータをディスクに書き込みます。

図22-1 ディスクへのマルチチャネル・バックアップのフェーズ

図22-2は、同様に、3つのディスクに格納されているデータをバックアップする2つのチャネルを示していますが、1つのディスクがネットワーク上にリモートでマウントされています。各チャネルはデータを入力バッファに読み取り、入力バッファから出力バッファへのコピー時にデータを処理し、出力バッファからのデータをテープに書き込みます。チャネル1はローカル接続されたテープ・ドライブにデータを書き込み、チャネル2はネットワークを介してリモート・メディア・サーバーにデータを送信します。

図22-2 テープへのマルチチャネル・バックアップのフェーズ

データをリストアする場合、これらの手順が逆順で実行され、読取りと書込みの操作が逆になります。次の項では、RMANのチューニングの概念について、バックアップを例に説明します。

読取りフェーズ

この項では、RMANチャネルがディスクのデータを読み取る場合に、パフォーマンスに影響する次の要因について説明します。

- 入力ディスク・バッファの割当て

- 同期ディスクI/Oと非同期ディスクI/O

- ディスクI/Oスレーブ

- チャネルのRATEパラメータ

入力ディスク・バッファの割当て

バックアップ中、RMANチャネルは、入力ファイルのブロックをI/Oディスク・バッファに読み取ります。ディスク・サブシステムのデータベース・ファイルは、自動ストレージ管理(ASM)、他のボリューム・マネージャまたはファイル・システムで管理できます。バックアップのチューニングに関する考慮事項は、データベース・ファイルをASMで管理するかどうかによって異なります。

入力バッファの割当ては、ファイルをどのように多重化するかによって異なります。バックアップの多重化は、バックアップ内のいくつかのファイルを複数のソースから同時に読み取り、1つのバックアップ・ピースに書き込むRMANの機能です。同時に読み取られ、同じバックアップ・ピースに書き込まれる入力ファイルの数を表す多重化レベルを決定するアルゴリズムの詳細は、「多重バックアップ・セット」を参照してください。この章を読む前に、これらの項を参照してください。

RMANチャネルは、ディスクのファイルをバックアップするときに、表22-1に示す規則を使用して、作成する入力ディスクのバッファのサイズを決定します。

表22-1 データファイルの読取りバッファのサイズを決定するアルゴリズム

多重化レベル

入力ディスクのバッファのサイズ

4以下

すべての入力ファイル用の合計バッファ・サイズが16メガバイト(MB)になるように、1MBのバッファが16個割り当てられます。

4より大きく8以下

すべての入力ファイル用の合計バッファ・サイズが16MB未満になるように、512キロバイト(KB)のディスク・バッファがいくつか割り当てられます。

8より大きい

各入力ファイル用の合計バッファ・サイズが512KBになるように、各ファイルに128KBのディスク・バッファが4つずつ割り当てられます。

図22-3に、1つのチャネルで4つのデータファイルをバックアップする例を示します。MAXOPENFILESは4に設定され、FILESPERSETは4に設定されています。したがって、多重化のレベルは4です。このため、各データファイル用の合計バッファ・サイズは4MBになります。すべてのバッファを組み合せたサイズは16MBになります。

図22-3 ディスク・バッファの割当て

ASMに格納されているファイルをチャネルがバックアップする場合、入力ディスクのバッファの数は、ASMディスク・グループの物理ディスクの数と等しくなります。たとえば、16個の物理ディスクを含むASMディスク・グループにデータファイルが保存されていると、チャネルはそのデータファイルのバックアップ用に16個の入力バッファを割り当てます。

チャネルがディスクからバックアップをリストアする場合は、4つのバッファが割り当てられます。バッファのサイズは、オペレーティング・システムによって異なります。

同期ディスクI/Oと非同期ディスクI/O

チャネルによるディスクに対する読取りまたは書込みでは、I/Oは同期I/Oと非同期I/Oのいずれかです。ディスクI/Oが同期の場合、サーバー・プロセスは一度に1つのタスクのみを実行できます。ディスクI/Oが非同期の場合、サーバー・プロセスは1つのI/O操作を開始し、そのI/Oが完了するまで待機している間に他の作業を実行できます。また、1つ目のI/Oの完了の待機に入る前に、複数のI/O操作を開始することもできます。

ASMディスク・グループから読み取るときには、可能な場合は非同期ディスクI/Oを使用してください。また、ボリューム・マネージャで管理されているRAWデバイスからチャネルが読み取る場合も、非同期ディスクI/Oが適切に動作します。一部のオペレーティング・システムでは、固有の非同期ディスクI/Oをサポートしています。データベースは、使用可能な場合はその機能を利用します。

ディスクI/Oスレーブ

固有の非同期I/Oをサポートしていないオペレーティング・システムの場合、データベースは、特別なI/Oスレーブ・プロセスを使用してその機能をシミュレートできます。このようなプロセスは、別のプロセスのかわりにI/Oを実行する専用のプロセスです。

ディスクI/Oスレーブを制御するには、動的でないDBWR_IO_SLAVES初期化パラメータを設定します。このパラメータでは、データベース・ライター・プロセス(DBWR)で使用されるI/Oサーバー・プロセスの数を指定します。デフォルトでは、この値は0(ゼロ)であり、I/Oサーバー・プロセスは使用されません。DBWR_IO_SLAVESが0(ゼロ)以外の値である場合に、非同期I/Oが無効であると、4つのバックアップ・ディスクI/Oスレーブが割り当てられます。

データベースがI/Oスレーブ用の共有バッファを取得する際、次のことが行われます。

- LARGE_POOL_SIZE初期化パラメータが設定されていて、かつDBWR_IO_SLAVESパラメータの値が0(ゼロ)以外に設定されている場合、データベースでは、ラージ・プールからのメモリーの取得が試行されます。この値が十分大きくない場合、アラート・ログにエラーが記録されます。また、共有プールからのバッファの取得は試行されず、非同期I/Oは使用されません。

- LARGE_POOL_SIZE初期化パラメータが設定されていない場合、または0(ゼロ)に設定されている場合、データベースは、共有プールからのメモリーの取得を試行します。

- データベースが十分なメモリーを取得できない場合、プログラム・グローバル領域(PGA)からI/Oバッファ・メモリーを取得し、このバックアップに同期I/Oを使用するというメッセージをalert.logファイルに書き込みます。

ラージ・プールのメモリーは、共有サーバー、パラレル問合せ、RMANのI/Oスレーブ・バッファなどの多くの機能に使用されます。ラージ・プールを構成すると、RMANがメモリー取得のために他のサブシステムと競合することを防止できます。

共有プールからの連続メモリーの割当ての要求は、通常は小さいサイズ(5KB未満)の要求です。ただし、大きいサイズの連続メモリーの割当てが要求されると、割当てが失敗するか、または要求された量の連続メモリーを解放するための大量のクリーンアップが必要となる場合があります。このメモリー要求は、共有プールでは満たせない場合がありますが、ラージ・プールでは満たすことができます。ラージ・プールには最低使用頻度(LRU)リストが存在しないため、ラージ・プールからの古いメモリーの削除は試行されません。

チャネルのRATEパラメータ

ALLOCATEコマンドおよびCONFIGURE CHANNELコマンドでは、RATEパラメータで、チャネルで読み取られる速度(バイト/秒)を指定します。このパラメータを使用すると、RMANが過度のディスク帯域幅を使用してオンライン・パフォーマンスが低下することを防止するために、読取りバイト数の上限を設定できます。基本的に、RATEは、バックアップの制限として機能します。たとえば、RATE=1500Kと設定し、各ディスク・ドライブの速度が3MB/秒である場合、チャネルは、ディスク帯域幅の一部をオンライン・システム用に確保します。

コピー・フェーズ

このフェーズでは、入力バッファから出力バッファにブロックがコピーされ、追加処理が実行されます。たとえば、データがディスクから読み取られてテープにバックアップされる場合、データはディスク・バッファから出力テープ・バッファにコピーされます。

コピー・フェーズには、次の処理が含まれています。

- 検証

- 圧縮

- 暗号化

ブロックの検証を実行すると、ブロックが破損していないかどうかが確認されます。検証については、第16章「データベース・ファイルおよびバックアップの検証」を参照してください。通常、この処理ではCPUに負荷はかかりません。

バイナリ圧縮を実行すると、RMANで、バックアップ・セット内のデータに圧縮アルゴリズムが適用されます。バイナリ圧縮は、CPUに負荷がかかる場合があります。RMANでバックアップに使用する圧縮アルゴリズムを選択できます。RMANの基本の圧縮レベルは、ほとんどのシナリオで圧縮率に優れています。Advanced Compressionオプションを有効にすると、圧縮率と必要なCPUリソースの間の妥協点として選択できる様々なレベルが示されます。バイナリ圧縮については、「バックアップ・セットのバイナリ圧縮」および「圧縮バックアップの作成」を参照してください。

バックアップ暗号化を実行すると、V$RMAN_ENCRYPTION_ALGORITHMSに表示されているアルゴリズムのいずれかを使用して、バックアップ・セットが暗号化されます。RMANには、透過モード、パスワード保護モードおよびデュアル・モードの3つの暗号化モードがあります。バックアップの暗号化については、「RMANバックアップの暗号化」を参照してください。バックアップの暗号化は、CPUに負荷がかかる場合があります。

システム・バックアップ・テープ(SBT)への書込みフェーズ

SBTへのバックアップ時、RMANは、メディア・マネージャにバイト・ストリームを渡し、そのストリームに一意の名前を関連付けます。ストリームの格納方法および格納場所の詳細は、メディア・マネージャによって管理されます。したがって、テープへのバックアップでは、RMANとメディア・マネージャの両方が相互に作用します。

SBTへの書込みフェーズにおけるRMANの構成要素

SBTへの書込みフェーズに影響するRMAN固有の要因は、ディスクの読取りに影響する要因と類似しています。いずれの場合も、バッファの割当て、スレーブ・プロセスおよび同期I/Oまたは非同期I/Oによってパフォーマンスが左右されます。

テープ・バッファの割当て

SBTデバイスにバックアップする場合、またはそこからリストアする場合、デフォルトでは、テープ書込み用(表22-1に示すようにデータをリストアする場合は読取り用)の各チャネルに4つのバッファが割り当てられます。テープI/Oバッファのサイズは、プラットフォームによって異なります。この値は、ALLOCATE CHANNELコマンドまたはCONFIGURE CHANNELコマンドのPARMSパラメータおよびBLKSIZEパラメータで変更できます。

図22-4 テープ・バッファの割当て

テープI/Oスレーブ

RMANは、I/Oスレーブが使用されているかどうかに応じて、システム・グローバル領域(SGA)またはプログラム・グローバル領域(PGA)にテープ・バッファを割り当てます。初期化パラメータBACKUP_TAPE_IO_SLAVES=trueを設定した場合、テープ・バッファはSGAから割り当てられます。テープ・デバイスにアクセスできるのは、一度に1つのプロセスだけです。そのため、テープ・デバイス数に対応する必要な数のスレーブが起動されます。LARGE_POOL_SIZE初期化パラメータも設定されている場合は、ラージ・プールからバッファが割り当てられます。BACKUP_TAPE_IO_SLAVES=falseを設定した場合、バッファはPGAから割り当てられます。

I/Oスレーブを使用する場合、LARGE_POOL_SIZE初期化パラメータを設定し、SGAメモリーをサイズの大きいメモリー割当ての保持専用に確保しておきます。このパラメータによって、SGAメモリーのためにRMANのI/Oバッファとライブラリ・キャッシュが競合することを防止できます。テープI/OのI/Oスレーブが要求されたものの、そのために十分な領域がSGAに存在しない場合、スレーブは使用されず、アラート・ログにメッセージが書き込まれます。

BACKUP_TAPE_IO_SLAVESパラメータには、スレーブ・プロセスの数ではなく、RMANがスレーブ・プロセスを使用するかどうかを指定します。テープ・デバイスにアクセスできるのは、一度に1つのプロセスだけであり、RMANでは、テープ・デバイス数に対応する必要な数のスレーブが使用されます。

同期I/Oと非同期I/O

SBTチャネルによるデータの読取りまたはテープへの書込みでは、I/Oは常に同期です。テープI/Oでは、(手動または自動で)割当て済の各チャネルは1つのサーバー・プロセスに対応しています。ここでは、このプロセスをチャネル・プロセスと呼びます。

表22-1に、テープへのバックアップでの同期I/Oを示します。

図22-5 同期テープI/O

次の手順が実行されます。

1. チャネル・プロセスが、テープ・バッファにブロックを書き込みます。

2. チャネル・プロセスが、テープ・バッファを処理するメディア・マネージャ・コードを実行して、メディア・マネージャが追加の処理および格納を行えるように内部処理を行います。

3. メディア・マネージャ・コードが、書込みが完了したことを示すメッセージをサーバー・プロセスに戻します。

4. チャネル・プロセスが新しいタスクを開始できる状態になります。

表22-1に、テープへのバックアップでの非同期I/Oを示します。テープへの非同期I/Oは、テープ・スレーブを使用してシミュレートされます。この場合、各割当て済チャネルは1つのサーバー・プロセスに対応しています。この項の説明では、サーバー・プロセスをチャネル・プロセスと呼びます。各チャネル・プロセスに対して1つ(複数のコピーが存在する場合は複数)のテープ・スレーブが起動されます。

図22-6 非同期テープI/O

次の手順が実行されます。

1. チャネル・プロセスが、テープ・バッファにブロックを書き込みます。

2. チャネル・プロセスが、テープ・バッファを処理するためのメッセージをテープ・スレーブ・プロセスに送信します。テープ・スレーブ・プロセスが、テープ・バッファを処理するメディア・マネージャ・コードを実行して、メディア・マネージャが処理を行えるように内部処理を行います。

3. テープ・スレーブ・プロセスが書込みを行っている間、チャネル・プロセスはデータファイルからデータを読み取り、追加の出力バッファを準備できます。

4. テープ・スレーブ・チャネルは、メディア・マネージャ・コードから戻されると、新しいテープ・バッファを要求します。通常、その時点で新しいバッファが使用可能になっています。このため、チャネル・プロセスの待機時間が減少し、バックアップ時間が短縮されます。

SBTへの書込みフェーズにおけるメディア・マネージャの構成要素

テープへのバックアップの速度に影響する要因を次に示します。

- ネットワークのスループット

- 固有の転送レート

- テープの圧縮

- テープ・ストリーム

- 物理テープ・ブロック・サイズ

ネットワークのスループット

リモートのテープ・デバイスの場合、メディア・マネージャは、ネットワーク経由でデータを転送する必要があります。たとえば、Oracle Secure Backupの管理ドメインには、ネットワークで接続された複数のクライアント・ホスト、メディア・サーバーおよびテープ・デバイスが含まれていることがあります。あるホストにデータベースがあり、別のホストに出力用のテープ・ドライブが接続されている場合、Oracle Secure Backupがネットワーク経由のデータ転送を管理します。ネットワークのスループットが、バックアップのパフォーマンスの上限になります。

固有の転送レート

テープ固有の転送レートは、圧縮なしでテープに書き込む場合の速度です。この速度は、バックアップ・レートの上限を表します。バックアップのパフォーマンスの上限は、すべてのテープ・デバイスの転送レートの集計となります。バックアップ操作がすでにそのレートで実行されており、必要以上にCPUを使用していない場合、チューニングしてもRMANのパフォーマンスは変わりません。

テープの圧縮

テープの圧縮レベルは、バックアップのパフォーマンスに重大な影響を及ぼします。テープの圧縮レベルが高い場合、持続的なバックアップの転送レートは高くなります。たとえば、圧縮比が2:1で、テープ・ドライブ固有の転送レートが6MB/秒である場合、バックアップ速度は12MB/秒になります。この場合、RMANは、12MB/秒より高速なスループットでディスクを読み取ることができる必要があり、そうでない場合はこのディスクはバックアップのボトルネックになります。

注意:
メディア・マネージャによるテープの圧縮機能とRMANによるバイナリ圧縮機能の両方を使用しないでください。メディア・マネージャによる圧縮が十分である場合は、こちらを使用することをお薦めします。RMANでのデータ圧縮によるCPUオーバーヘッドを許容できる場合は、RMANの圧縮バックアップ・セットを使用すると、圧縮していないバックアップ・セットをネットワークを介してメディア・マネージャに移動するときに使用される帯域幅を削減することができます。

テープ・ストリーム

書込み操作中のテープ・ストリームは、テープへのバックアップ・パフォーマンスに重大な影響を及ぼします。多くのテープ・ドライブは、固定速度のストリーム・テープ・ドライブです。そのようなドライブはデータの書込み速度を変更できないため、テープへ書き込むデータがなくなると、テープを減速して停止する必要があります。通常、ドライブのバッファが空になっても、テープの移動が速すぎて書込み終了位置を越えてしまいます。そのためドライブで書込みを継続するには、書込みが終了した位置までテープを巻き戻す必要があります。複数の速度で動作するテープ・ドライブを利用すると、この問題を軽減できます。

物理テープ・ブロック・サイズ

物理テープ・ブロック・サイズは、バックアップのパフォーマンスに影響する場合があります。ブロック・サイズは、メディア管理ソフトウェアが、1回の書込み操作でテープに書き込むデータの量です。通常、テープ・ブロック・サイズが大きいほど、バックアップが高速になります。物理テープ・ブロック・サイズは、RMANまたはOracle Databaseではなく、メディア管理ソフトウェアが制御します。詳細は、ご使用のメディア管理ソフトウェアのドキュメントを参照してください。

ディスクへの書込みフェーズ

ディスクへの書込みフェーズに影響する主な要因は、バッファ・サイズです。バックアップの出力がディスクに存在する場合、各チャネルは、1MBずつの出力バッファを4つ割り当てます。ディスク・チャネルが、ディスク・サブシステムにブロックを書き込みます。ファイルをリストアするときの読取りフェーズは、ファイルをバックアップするときの書込みフェーズと似ています。ただし、ブロックの動く向きは逆です。

ディスクから非同期の読取りが行われる場合は、ディスクへの書込みも非同期になります。ディスクへの書込み時には、ディスクからの読取り時と同様にディスクI/Oスレーブを利用できます。

RMANが、複数のディスクにストライプ化されたディスクベースの出力先にファイルをバックアップする場合は、複数のチャネルを割り当てることができます。チャネルの数は、出力先のストライプ化されたディスクの数に制限されます。ASMは、複数のディスクにストライプ化された出力先の一例です。

RMANのパフォーマンスの問題を診断するためのV$ビューの使用方法

通常、チューニング・プロセスを開始する場合は、V$ビューを使用して、RMANのバックアップ操作およびリストア操作のどこで問題が発生しているかを特定します。

V$SESSION_LONGOPSによるRMANジョブの進捗状況の監視

V$SESSION_LONGOPSビューを問い合せると、バックアップ・ジョブおよびリストア・ジョブの進捗状況を監視できます。RMANは、V$SESSION_LONGOPSで詳細行と集計行の2つのタイプの行を使用します。

詳細行には、1つのジョブ手順によって処理されているファイルの説明が表示され、集計行には、RMANコマンドのすべてのジョブ手順によって処理されたファイルの説明が表示されます。ジョブ手順とは、1つのバックアップ・セットまたはデータファイルのコピーの作成またはリストアです。詳細行は、バックアップ手順中、バッファに対する読取りまたは書込みが行われるたびに更新されるため、更新の粒度は小さくなります。集計行は、各ジョブ手順の完了時に更新されるため、更新の粒度は大きくなります。

表22-2に、RMANに最も関連するV$SESSION_LONGOPSの列を示します。通常、各バックアップ・セットの進捗状況を確認するには、集計行ではなく詳細行を表示します。

表22-2 RMANに関連するV$SESSION_LONGOPSの列

列

詳細行の説明

SID

RMANチャネルに対応するサーバー・セッションID

SERIAL#

サーバー・セッションのシリアル番号。この値はサーバー・セッションが再利用されるたびに変更されます。

OPNAME

行の説明テキスト。詳細行の例は、RMAN: datafile copy、RMAN: full datafile backup、RMAN: full datafile restoreなどです。

注意: 集計行は、RMAN: aggregate inputおよびRMAN: aggregate outputのみです。

CONTEXT

バックアップ出力行では、この値は2です。それ以外のすべての行では、値は1です(ただし、この列を更新しないプロキシ・コピーは除く)。

SOFAR

この列の内容は、行に表示される操作のタイプによって次のように異なります。

- イメージ・コピーの場合、読み取られたブロック数

- バックアップ入力行の場合、バックアップされるファイルから読み取られたブロック数

- バックアップ出力行の場合、バックアップ・ピースに書き込まれたブロック数

- リストアの場合、この1つのジョブ手順でリストアされているファイルに処理されたブロック数

- プロキシ・コピーの場合、コピーされたファイル数

TOTALWORK

この列の内容は、行に表示される操作のタイプによって次のように異なります。

- イメージ・コピーの場合、ファイルのブロックの合計数。

- バックアップ入力行の場合、このジョブ手順で処理されるすべてのファイルから読み取られるブロックの合計数。

- バックアップ出力行の場合、RMANはバックアップ・ピースに書き込むブロック数を認識しないため、値は0になります。

- リストアの場合、このジョブ手順でリストアされるすべてのファイルのブロックの合計数。

- プロキシ・コピーの場合、このジョブ手順でコピーされるファイルの合計数。

バックアップ・ジョブまたはリストア・ジョブを実行する各サーバー・セッションは、1つのジョブ手順で必要な処理の合計と比較して、進捗状況をレポートします。たとえば、2つのチャネルを使用してデータベースをリストアし、各チャネルが2つのバックアップ・セットをリストアする場合(合計4セットをリストアする場合)、各サーバー・セッションは、1つのバックアップ・セットにおける進捗状況をレポートします。あるセットのリストアが完了すると、RMANは、リストアする次のセットでの進捗状況のレポートを開始します。

RMANジョブの進捗状況の監視手順

1. RMANジョブを開始する前に、次のSQL文を含むスクリプト・ファイル(この例ではlongops)を作成します。

SELECT SID, SERIAL#, CONTEXT, SOFAR, TOTALWORK,
ROUND(SOFAR/TOTALWORK*100,2) "%_COMPLETE"
FROM   V$SESSION_LONGOPS
WHERE  OPNAME LIKE 'RMAN%'
AND    OPNAME NOT LIKE '%aggregate%'
AND    TOTALWORK != 0
AND    SOFAR <> TOTALWORK;

2. RMANを起動し、ターゲット・データベースおよびリカバリ・カタログ(使用している場合)に接続します。

3. RMANジョブを起動します。たとえば、次のように入力します。

RMAN> RESTORE DATABASE;

4. RMANジョブの実行中に、SQL*Plusを起動し、ターゲット・データベースに接続してlongopsスクリプトを実行し、RMANジョブの進捗状況を確認します。RMANジョブの実行中に問合せを繰り返すと、次のような出力が表示されます。

SQL> @longops
SID    SERIAL#    CONTEXT      SOFAR  TOTALWORK %_COMPLETE
---------- ---------- ---------- ---------- ---------- ----------
8         19          1      10377      36617      28.34

SQL> @longops
SID    SERIAL#    CONTEXT      SOFAR  TOTALWORK % COMPLETE
---------- ---------- ---------- ---------- ---------- ----------
8         19          1      21513      36617      58.75

SQL> @longops
SID    SERIAL#    CONTEXT      SOFAR  TOTALWORK % COMPLETE
---------- ---------- ---------- ---------- ---------- ----------
8         19          1      29641      36617      80.95

SQL> @longops
SID    SERIAL#    CONTEXT      SOFAR  TOTALWORK % COMPLETE
---------- ---------- ---------- ---------- ---------- ----------
8         19          1      35849      36617       97.9

SQL> @longops
no rows selected

5. 2分以上の間隔でlongopsスクリプトを実行しているときに、%_COMPLETE列の値が増加しない場合は、RMANで問題が発生しています。詳細は、「RMANとメディア・マネージャの相互作用の監視」を参照してください。

長時間の作業の実行を頻繁に監視する場合、SQL*Plusを実行するホスト・オペレーティング・システムでシェル・スクリプトまたはバッチ・ファイルを作成して、この問合せを繰り返し実行できます。

V$BACKUP_SYNC_IOおよびV$BACKUP_ASYNC_IOによるボトルネックの特定

バックアップまたはリストアのボトルネックの原因を特定し、バックアップ・ジョブの詳細な進捗を確認するには、V$BACKUP_SYNC_IO ビューおよびV$BACKUP_ASYNC_IOビューを使用できます。

バックアップを実行中のプロセス(一部のプラットフォームではスレッド)にI/Oが同期している場合は、V$BACKUP_SYNC_IOに行が表示されます。I/Oが非同期の場合は、V$BACKUP_ASYNC_IOに行が表示されます。非同期I/Oは、I/Oプロセスによって、または基礎となるオペレーティング・システムがサポートしている場合に実行されます。

データベース・インスタンスが停止するまで、バックアップ・ジョブまたはリストア・ジョブの結果はメモリーに残ります。このため、ジョブの完了後にビューを問い合せることができます。

I/Oが同期している場合に、テープがストリーム化されているかどうかを確認する手順

1. SQL*Plusを起動し、ターゲット・データベースに接続します。

2. V$BACKUP_SYNC_IOビューまたはV$BACKUP_ASYNC_IOビューのEFFECTIVE_BYTES_PER_SECOND列を問い合せます。
EFFECTIVE_BYTES_PER_SECONDがハードウェアのロー・キャパシティ未満の場合、そのテープはストリーム化されていません。EFFECTIVE_BYTES_PER_SECONDがハードウェアのロー・キャパシティより大きい場合、そのテープはストリーム化されている場合とされていない場合があります。これは、圧縮によって、EFFECTIVE_BYTES_PER_SECONDが実際のI/O速度より高速になる場合があるためです。

参照:
これらのビューの詳細は、『Oracle Databaseリファレンス』を参照してください。

同期I/Oのボトルネックの特定

同期I/Oでは、すべての同期I/Oがプロセスのボトルネックになるため、特定のボトルネックを識別することは困難です。同期I/Oをチューニングする唯一の方法は、I/Oレート(バイト/秒)をデバイスの最大スループット・レートと比較することです。I/Oレートが、デバイスで指定されているレートより低い場合、バックアップ・プロセスおよびリストア・プロセスのこの側面をチューニングすることを考慮します。

同期I/Oのレートを確認する手順

1. SQL*Plusを起動し、ターゲット・データベースに接続します。

2. V$BACKUP_SYNC_IOビューのDISCRETE_BYTES_PER_SECOND列を問い合せて、I/Oレートを表示します。
V$BACKUP_SYNC_IOにデータが表示されている場合は、非同期I/Oを有効にしていないか、またはディスクI/Oスレーブを使用していないことが問題となっています。

非同期I/Oのボトルネックの特定

ロング・ウェイトは、バックアップ・プロセスまたはリストア・プロセスが、I/Oが完了するまで待機するようにオペレーティング・システムに通知した回数です。ショート・ウェイトは、バックアップ・プロセスまたはリストア・プロセスがオペレーティング・システム・コールを実行して、非ブロック化モードでI/Oの完了をポーリングした回数です。レディは、I/Oが使用可能な状態になっており、I/Oの完了をポーリングするためにオペレーティング・システム・コールを実行する必要がなかった回数です。

非同期I/Oのレートを確認する手順

1. SQL*Plusを起動し、ターゲット・データベースに接続します。

2. V$BACKUP_SYNC_IOビューのLONG_WAITS列およびIO_COUNT列を問い合せて、I/Oレートを表示します。
ボトルネックを特定する最も簡単な方法は、LONG_WAITSをIO_COUNTで割った比率が最も大きいデータファイルを見つける方法です。たとえば、次の問合せを使用できます。

SELECT   LONG_WAITS/IO_COUNT, FILENAME
FROM     V$BACKUP_ASYNC_IO
WHERE    LONG_WAITS/IO_COUNT > 0
ORDER BY LONG_WAITS/IO_COUNT DESC;

注意:
同期I/Oの使用時にBACKUP_DISK_IO_SLAVESを設定した場合、I/OはV$BACKUP_ASYNC_IOに表示されます。

関連項目:
V$BACKUP_SYNC_IOビューおよびV$BACKUP_ASYNC_IOビューの詳細は、『Oracle Databaseリファレンス』を参照してください。

RMANのバックアップのパフォーマンスのチューニング

バックアップのパフォーマンスは、多くの要因に影響を受けます。多くの場合、低速なバックアップを改善するには、試行錯誤が伴います。この項では、バックアップで最高のパフォーマンスを得るための手順を順に示します。

この項の内容は、次のとおりです。

- 手順1: チャネル設定からのRATEパラメータの削除

- 手順2: 同期ディスクI/Oを使用する場合のDBWR_IO_SLAVESの設定

- 手順3: 共有メモリーの割当てに失敗する場合のLARGE_POOL_SIZEの設定

- 手順4: 読取り、書込みおよびコピーのフェーズのチューニング

手順1: チャネル設定からのRATEパラメータの削除

「チャネルのRATEパラメータ」で説明されているように、チャネルのRATEパラメータは、他のデータベース操作でより多くのディスク帯域幅を使用できるように、バックアップ・スループットを(増加ではなく)削減するためのパラメータです。バックアップがテープにストリーム配信されていない場合、RATEパラメータを設定していないことを確認してください。

RATEパラメータを削除する手順

1. バックアップ・スクリプトを確認します。

2. 次のいずれかを実行します。

- バックアップがRUNコマンド内に指定されていて、ALLOCATEコマンドにRATEパラメータが指定されている場合は、このパラメータを削除します。残りの手順はスキップします。

- バックアップがRUNコマンド内に指定されていない場合は、RMANを起動し、ターゲット・データベースに接続して次の手順に進みます。

3. SHOW ALLコマンドを実行して、現在構成されている設定を表示します。

4. CONFIGURE CHANNELコマンドにRATEパラメータが設定されている場合は削除します。

手順2: 同期ディスクI/Oを使用する場合のDBWR_IO_SLAVESの設定

「同期ディスクI/Oと非同期ディスクI/O」に示されているように、一部のオペレーティング・システムでは、固有の非同期I/Oをサポートしています。ご使用のディスクが非同期I/Oをサポートしない場合にのみ、DBWR_IO_SLAVESを設定します。DBWR_IO_SLAVESに0(ゼロ)以外の値を設定すると、バックアップおよびリストアに固定数のディスクI/Oスレーブが使用され、非同期I/Oがシミュレートされます。

ディスクI/Oスレーブを有効にする手順

1. SQL*Plusを起動し、ターゲット・データベースに接続します。

2. データベースを停止します。

3. DBWR_IO_SLAVES初期化パラメータを0(ゼロ)以外の値に設定します。
DBWR_IO_SLAVESを設定すると、データベース・ライター・プロセスでスレーブを使用できるようになります。したがって、PROCESSES初期化パラメータの値を増やす必要がある場合があります。

4. データベースを再起動します。

5. RMANバックアップを再開します。

手順3: 共有メモリーの割当てに失敗する場合のLARGE_POOL_SIZEの設定

LARGE_POOL_SIZE初期化パラメータは、メモリー不足のためにI/Oスレーブを起動できないというエラーがアラート・ログに書き込まれた場合に設定します。メッセージの例を次に示します。

ksfqxcre: failure to allocate shared memory means sync I/O will be used whenever
async I/O to file not supported natively

ラージ・プールは、RMANおよびその他の用途に使用されるため、すべてのユーザーに対応できる合計サイズにする必要があります。このことは特に、DBWR_IO_SLAVESが設定されており、DBWRプロセスにバッファが必要な場合に該当します。

ラージ・プールのサイズを設定する手順

1. SQL*Plusを起動し、ターゲット・データベースに接続します。

2. 必要に応じて、V$SGASTAT.POOLを問い合せて、特定のオブジェクト用のメモリーが存在するプール(共有プールまたはラージ・プール)を確認します。

3. ターゲット・データベースにLARGE_POOL_SIZE初期化パラメータを設定します。
ALTER SYSTEM SET文を実行して、パラメータを動的に設定します。LARGE_POOL_SIZEを設定するための計算式を次に示します。

LARGE_POOL_SIZE =  number_of_allocated_channels *
(16 MB + ( 4 *  size_of_tape_buffer ) )

4. RMANバックアップを再開します。

参照:
ラージ・プールの詳細は、『Oracle Database概要』を参照してください。初期化パラメータの詳細は、『Oracle Databaseリファレンス』を参照してください。

手順4: 読取り、書込みおよびコピーのフェーズのチューニング

次のいくつかのタスクを実行して、バックアップのパフォーマンスに影響を及ぼすボトルネックを特定および解消できます。

バックアップの検証を使用した読取りと書込みのボトルネックの識別

任意のバックアップ・ジョブで出力デバイスまたは入力ディスクI/Oのどちらがボトルネックになっているかを確実に確認する方法の1つは、あるバックアップ・タスクの実行時間と、同じタスクのBACKUP VALIDATEの実行時間を比較することです。バックアップのBACKUP VALIDATEは、実際のバックアップと同じディスク読取りを実行しますが、出力デバイスに対するI/Oは実行しません。

バックアップ時間と検証時間を比較する手順

1. NLS環境の日付書式変数が、時刻を表示するように設定されていることを確認します。たとえば、NLS変数を次のように設定します。

setenv NLS_LANG  AMERICAN_AMERICA.WE8DEC;
setenv NLS_DATE_FORMAT "MM/DD/YYYY HH24:MI:SS"

2. BACKUPコマンドでなくBACKUP VALIDATEコマンドを使用するようにバックアップ・スクリプトを編集します。

3. バックアップ・スクリプトを実行します。

4. RMAN出力を調べ、Starting backup atとFinished backup atに示された時間の差を計算します。

5. BACKUP VALIDATEコマンドでなくBACKUPコマンドを使用するようにバックアップ・スクリプトを編集します。

6. バックアップ・スクリプトを実行します。

7. RMAN出力を調べ、Starting backup atとFinished backup atに示された時間の差を計算します。

8. 検証と実際のバックアップでバックアップ時間を比較します。
テープに対するBACKUP VALIDATEの時間が、テープへの実際のバックアップの時間とほとんど変わらない場合は、ディスクからの読取りがボトルネックになっている可能性があります。「読取りフェーズのチューニング」を参照してください。

テープに対するBACKUP VALIDATEの時間が、テープへの実際のバックアップの時間より大幅に短い場合は、出力デバイスへの書込みがボトルネックになっている可能性があります。「コピーおよび書込みのフェーズのチューニング」を参照してください。

読取りフェーズのチューニング

RMANでは、出力デバイスの占有を継続するのに十分な速度で出力デバイスにデータ・ブロックを送信できないことがあります。たとえば、RMANは、増分バックアップ中、同じ計画の一環として以前にデータファイルをバックアップした後に変更されたブロックのみをバックアップします。ブロック・チェンジ・トラッキングを有効にしない場合、RMANは、変更されたブロックを検出するためにデータファイル全体をスキャンし、変更されたブロックを検出しながら出力バッファを一杯にする必要があります。変更されたブロックがほとんどなく、SBTバックアップを行っている場合、RMANは、テープ・ドライブへのストリームを継続するのに十分な速度で出力バッファを一杯にできないことがあります。

同時に読み取られ、RMANの同じバックアップ・ピースに書き込まれる入力ファイルの数を表す多重化レベルを調整すると、バックアップのパフォーマンスを向上させることができます。多重化のレベルは、チャネル上のMAXOPENFILES設定および各バックアップ・セット内の入力ファイル数の最小値です。次の表に、多重化のレベルを調整するときの推奨事項を示します。

表22-3 多重化のレベルの調整

ASM

ストライプ化されたディスク

推奨事項

なし

あり

多重化のレベルを上げます。MAXOPENFILESまたは各バックアップ・セット内のファイル数のいずれが最小値かを確認してから、この値を増やします。

このようにして、RMANがテープ・バッファを一杯にする速度を上げ、ストリームを継続するのに十分な速度でバッファがメディア・マネージャに送信される確率を高くします。

なし

なし

チャネル上のMAXOPENFILES設定値を増やします。

あり

該当なし

チャネルのMAXOPENFILESパラメータを1または2に設定します。

関連項目:

- MAXOPENFILESおよびFILESPERSETの設定が多重化のレベルにどのような影響を与えるかについては、「多重バックアップ・セット」を参照してください。

- 概要については、「増分バックアップ」を参照してください。

コピーおよび書込みのフェーズのチューニング

読取りフェーズのパフォーマンスが良好な場合、ボトルネックとなっている可能性が高いのは、コピー・フェーズまたは書込みフェーズです。特に、RMANが、ストリームをサポートするのに十分な速度でテープ・ドライブにデータ・ブロックを送信しているときにテープがストリーム化されていない場合は、SBTへの書込みフェーズがボトルネックです。次のように、パフォーマンスを向上させます。

- バックアップが全体バックアップの場合、増分バックアップの使用を検討します。
増分レベル1のバックアップでは、変更されたブロックのみがデータファイルからテープに書き込まれるため、テープへの書込みに関するボトルネックは、バックアップ計画全体にはあまり影響を及ぼしません。特に、バックアップするデータベースのノードにテープ・ドライブがローカルに接続されていない場合、増分バックアップはより高速になる場合があります。「増分バックアップの作成および更新」を参照してください。

- バックアップで基本の圧縮アルゴリズムが使用されている場合は、Advanced Compressionオプションの使用を検討します。
「圧縮オプションの構成」または「バックアップ・セットのバイナリ圧縮」を参照してください。

- データベースのホストが複数のCPUを使用し、バックアップではバイナリ圧縮が使用されている場合は、チャネルの数を増やします。

- バックアップが暗号化されている場合は、暗号化アルゴリズムをAES128に変更します。
AES128アルゴリズムは、最もCPUに負荷がかからないアルゴリズムです。「バックアップ暗号化アルゴリズムの構成」を参照してください。

- RMANがテープにバックアップしている場合は、次のような調整を試してください。

- テープI/Oバッファのサイズを調整します。
サイズを設定するには、ALLOCATE CHANNELコマンドまたはCONFIGURE CHANNELコマンドのPARMSパラメータおよびBLKSIZEパラメータを使用します。テープI/Oバッファのサイズは、プラットフォームによって異なります。BLKSIZE設定は、デフォルトより優先されます。

- メディア管理ソフトウェアの設定を調整します。
テープ・ブロック・サイズなどの一部のメディア・マネージャ設定は、バックアップのパフォーマンスに影響する場合があります。

- RMANがASMにファイルをバックアップしている場合は、チャネルの数を増やします。
たとえば、RMANが、16個の物理ディスクを含む1つのディスク・グループにデータベースをバックアップしている場合は、ディスク・チャネルの数を4から16の範囲で割り当てるか構成します。

23 RMAN操作のトラブルシューティング

この章では、Recovery Managerをトラブルシューティングする方法について説明します。この章の内容は次のとおりです。

- RMANのメッセージ出力の解釈

- RMANのトラブルシューティングでのV$ビューの使用

- Media Management APIのテスト

- RMANコマンドの終了

RMANのメッセージ出力の解釈

Recovery Managerは、問題のトラブルシューティングに役立つ詳細なエラー・メッセージを提供します。また、Oracle Databaseおよびサード・パーティのメディア・ベンダーは、独自の有効なデバッグ出力を生成します。この項では、発生する可能性がある様々なエラーの識別方法および解釈について説明します。

メッセージ出力タイプの識別

障害が発生したか、応答しなくなったRMANジョブのトラブルシューティングに役立つ出力は、表23-1に示すとおり、様々な場所に表示または格納されます。

表23-1 メッセージ出力タイプ

出力タイプ

作成元

場所

説明

RMANメッセージ

RMAN

ジョブの詳細情報は、V$RMAN_STATUSおよびRC_RMAN_STATUSに表示されます。現行のジョブの情報は、V$RMAN_OUTPUTに表示されます。

RMANをコマンドラインから実行すると、出力を次の場所に送ることができます。

- 標準出力

- コマンドラインのLOGまたはSPOOL LOGコマンドで指定したログ・ファイル

- RMAN出力をリダイレクトすることで作成したファイル(たとえば、UNIXの場合、'>'演算子を使用)

RMANジョブに関連するアクションと、RMAN、データベース・サーバーおよびメディア・ベンダーによって生成されたエラー・メッセージが含まれています。RMANのエラー・メッセージには、RMAN-という接頭辞が付いています。通常のアクションの説明には接頭辞は付きません。

次のPL/SQLを実行すると、V$RMAN_STATUSからすべてのエントリを削除できます。

SYS.DBMS_BACKUP_RESTORE.resetCfileSection(28);

このファンクションでは、すべてのジョブ関連エントリが削除されます。新しいバックアップ・ジョブがV$RMAN_BACKUP_JOB_DETAILSに表示されるまで、行は表示されません。

alert_SID.log

Oracle Database

自動診断リポジトリ(ADR)ホームのalertサブディレクトリ

エラー、初期化パラメータ設定および管理操作の時系列のログが含まれています。上書きされた制御ファイル・レコードの値が記録されます。

Oracleトレース・ファイル

Oracle Database

ADRホームのtraceサブディレクトリ

Oracle Databaseプロセスによって生成された詳細な出力が含まれています。このファイルは、ORA-600またはORA-3113エラー・メッセージが発生したとき、RMANがチャネルを割り当てられないとき、およびデータベースがメディア管理ライブラリのロードに失敗したときに作成されます。

sbtio.log

サード・パーティのメディア管理ソフトウェア

ADRホームのtraceサブディレクトリ

メディア管理ソフトウェアによって生成されたベンダー固有の情報が含まれています。このログには、Oracle DatabaseまたはRMANのエラーは含まれていません。

メディア・マネージャのログ・ファイル

サード・パーティのメディア管理ソフトウェア

sbtio.log以外のすべてのメディア・マネージャのログのファイル名は、メディア管理ソフトウェアによって決定されます。

メディア管理デバイスの機能に関する情報が含まれています

RMANのエラー・メッセージ・スタックの識別

RMANは、エラーの発生時にそれらのエラーを通知します。回復不可能なエラーの場合、つまりRMANが別のチャネルへのフェイルオーバーを実行して特定のジョブ手順を完了することができない場合、すべてのジョブ・セットの完了後にエラーの概要レポートも出力されます。この機能は、遅延エラー・レポートともいいます。

「RMANのリターン・コードの識別」で説明するように、RMANにエラーが発生したかどうかを確認する方法の1つは、リターン・コードを調べることです。2つ目の方法は、Recovery Managerの出力内でRMAN-00569文字列を検索することです。RMAN-00569は、エラー・スタック・バナーのメッセージ番号です。すべてのRMANエラーの前に、このエラー・メッセージが表示されます。出力内にRMAN-00569メッセージが表示されない場合、エラーはありません。例23-1に、構文エラーの例を示します。

例23-1 RMAN構文エラー

RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-00558: error encountered while parsing input commands
RMAN-01005: syntax error: found ")": expecting one of: "archivelog, backup, backupset, controlfilecopy, current, database, datafile, datafilecopy, (, plus, ;, tablespace"
RMAN-01007: at line 1 column 18 file: standard input

エラー・コードの識別

通常、RMANメッセージ・スタックには次のタイプのエラー・コードが含まれています。

- 接頭辞がRMAN-のエラー

- 接頭辞がORA-のエラー

- Additional information:の後に表示されるエラー

関連項目:
RMANおよびORAのエラー・コードの詳細は、『Oracle Databaseエラー・メッセージ』を参照してください。

RMANのエラー・メッセージ番号

表23-2に、一般的なRMANエラー・メッセージのエラー範囲を示します。すべてのメッセージの詳細は、『Oracle Databaseエラー・メッセージ』を参照してください。

表23-2 RMANのエラー・メッセージの範囲

エラー範囲

原因

0550-0999

コマンドライン・インタプリタ

1000-1999

キーワード・アナライザ

2000-2999

構文アナライザ

3000-3999

主レイヤー

4000-4999

サービス・レイヤー

5000-5499

RESTOREコマンドまたはRECOVERコマンドのコンパイル

5500-5999

DUPLICATEコマンドのコンパイル

6000-6999

通常のコンパイル

7000-7999

通常の実行

8000-8999

PL/SQLプログラム

9000-9999

低レベルのキーワードのアナライザ

10000-10999

サーバー側の実行

11000-11999

PL/SQLとRMAN間のフェーズ間エラー

12000-12999

リカバリ・カタログ・パッケージ

ORA-19511: メディア・マネージャ・エラー

メディア・マネージャ・エラーが発生した場合、ORA-19511が通知され、説明を含むエラー・メッセージがメディア・マネージャからRMANに戻されます。RMANは、メディア・マネージャから戻されたエラーを表示します。たとえば、次のようなエラーが表示されます。

ORA-19511: Error received from media manager layer, error text:
sbtpvt_open_input: file .* does not exist or cannot be accessed, errno = 2

メディア・マネージャからのメッセージには、根本的な問題を修正するために十分な情報が含まれています。十分でない場合、ご使用のメディア・マネージャのドキュメントを参照するか、またはメディア管理ベンダーのサポート担当者に詳細を問い合せてください。ORA-19511エラーは、Oracle Databaseではなくメディア・マネージャによって生成されます。データベースは、メディア・マネージャからのメッセージを渡すのみです。原因を解決できるのは、メディア管理ベンダーのみです。

SBT 1.1対応のメディア管理レイヤーを使用している場合、その他のエラー・メッセージ・テキストが表示される場合があります。SBT 1.1対応のメディア管理レイヤーからの出力は、次のものと類似しています。

ORA-19507: failed to retrieve sequential file, handle="c-140148591-20031014-06", parms=""
ORA-27007: failed to open file
Additional information: 7000
Additional information: 2
ORA-19511: Error received from media manager layer, error text:
SBT error = 7000, errno = 0, sbtopen: backup file not found

「Additional information」には、SBT 1.1に固有なエラー・コードが表示されます。表示される値は、表23-3に示すメディア・マネージャ・メッセージ番号およびエラー・テキストに対応しています。RMANは、「ORA-19511: メディア・マネージャ・レイヤーからのエラーを受け取りました。」を再度表示し、メディア・マネージャから戻されたエラー・コードに関連する一般的なエラー・メッセージおよびSBT 1.1エラー番号を表示します。

参考として、SBT 1.1エラー・メッセージを示します。表23-3に、メディア・マネージャ・メッセージ番号および各番号に対応するエラー・テキストを示します。エラー・コード内のO/Sは、オペレーティング・システムを意味します。アスタリスク(*)が付いているエラーは内部エラーであり、通常の操作中に一般的に表示されるものではありません。

表23-3 メディア・マネージャのエラー・メッセージの範囲

原因

番号

メッセージ

sbtopen

7000

7001

7002*

7003

7004

7005

7006

7007

7008

7009

7010

7011

7012*

バックアップ・ファイルが見つかりません。(読取りの場合のみ戻されます。)

バックアップ・ファイルは存在します。(書込みの場合のみ戻されます。)

不正なモードが指定されました。

指定されたブロック・サイズが無効です。

デバイスがありません。

デバイスは見つかりましたがビジーです。後で再試行してください。

ボリュームが見つかりません。

ボリュームは使用中です。

I/Oエラーです。

Media Managerと接続できません。

許可されません。

システム・エラー - 例: malloc、forkのエラー

引数が無効です。

sbtclose

7020*

7021*

7022

7023

7024*

7025

ファイル・ハンドルが無効か、ファイルをオープンできません。

フラグが無効です。

I/Oエラーです。

O/Sエラー。

引数が無効です。

Media Managerと接続できません。

sbtwrite

7040*

7041

7042

7043

7044*

ファイル・ハンドルが無効か、ファイルをオープンできません。

ボリュームの終わりに達しました。

I/Oエラーです。

O/Sエラー。

引数が無効です。

sbtread

7060*

7061

7062

7063

7064

7065*

ファイル・ハンドルが無効か、ファイルをオープンできません。

EOFに達しました。

ボリュームの終わりに達しました。

I/Oエラーです。

O/Sエラー。

引数が無効です。

sbtremove

7080

7081

7082

7083

7084

7085

7086*

バックアップ・ファイルが見つかりません。

バックアップ・ファイルは使用中です。

I/Oエラーです。

Media Managerと接続できません。

許可されません。

O/Sエラー。

引数が無効です。

sbtinfo

7090

7091

7092

7093

7094

7095*

バックアップ・ファイルが見つかりません。

I/Oエラーです。

Media Managerと接続できません。

許可されません。

O/Sエラー。

引数が無効です。

sbtinit

7110*

7111

引数が無効です。

O/Sエラー。

RMANエラー・スタックの解釈

RMANエラー・スタック内の役立つメッセージを特定することが困難な場合があります。次のヒントおよび推奨事項を参考にしてください。

- メッセージは下から上に読みます。これは、RMANは下から順にメッセージを発行するためです。スタックの最後から1つか2つのエラーが、通常は最も重要です。

- SBT 1.1メディア管理レイヤーを使用しており、「追加情報」およびエラー・コード(番号)を含むSBT 1.1形式のエラー・メッセージが表示された場合、その後に続くORA-19511メッセージの、メディア・マネージャによってRMANに戻されたエラー・メッセージのテキストを確認します。これらのメッセージには、メディア管理レイヤーでの実際の障害が示されます。

- エラー・バナーの直後にあるRMAN-03002メッセージまたはRMAN-03009メッセージを確認します(RMAN-03009はRMAN-03002と同じですが、RMAN-03009にはチャネルIDが含まれます)。これらのメッセージには、正常に実行されなかったコマンドが示されます。構文エラーの場合、RMAN-00558が生成されます。

- 表23-2に示すエラー範囲を参照して基本的なエラー・タイプを判断し、最も重要なメッセージについて、『Oracle Databaseエラー・メッセージ』を参照して確認します。

RMANエラーの解釈の例

users表領域のバックアップを試行し、次のメッセージが戻されたと想定します。

Starting backup at 29-AUG-02
using channel ORA_DISK_1
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of backup command at 08/29/2002 15:14:03
RMAN-20202: tablespace not found in the recovery catalog
RMAN-06019: could not translate tablespace name "USESR"

RMAN-03002エラーは、BACKUPコマンドが正常に実行されなかったことを示しています。スタックの最後の2つのメッセージを参照すると、表領域名を正しく入力しなかったため、リカバリ・カタログ内にusesrという名前の表領域が見つからないことがわかります。

サーバー・エラーの解釈の例

表領域のリカバリを試行し、次のエラーが戻されたと想定します。

RMAN> RECOVER TABLESPACE users;

Starting recover at 29-AUG-07
using channel ORA_DISK_1

starting media recovery
media recovery failed
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of recover command at 08/29/2007 15:18:43
RMAN-11003: failure during parse/execution of SQL statement: alter database recover if needed tablespace USERS
ORA-00283: recovery session canceled due to errors
ORA-01124: cannot recover data file 8 - file is in use or recovery
ORA-01110: data file 8: '/oracle/oradata/trgt/users01.dbf'

前述の推奨事項に従って、スタックの下から読み始めます。ORA-01110メッセージは、users01.dbfデータファイルのリカバリで問題が発生したことを示しています。下から2つ目のメッセージは、そのデータファイルが使用中かリカバリ中であるため、リカバリ不可能であることを示しています。その他のRMANエラーは、サーバー・エラーのためにリカバリ・セッションが取り消されたことを示しています。こうして、このデータファイルはリカバリ中ではないため、問題はデータファイルがオンラインであることで、このファイルをオフラインにしてバックアップをリストアする必要があると判断できます。

SBT 2.0のメディア管理エラーの解釈の例

テープ・ドライブを使用したバックアップ・ジョブ中に、次の出力が戻されたと想定します。

RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
ORA-19624: operation failed, retry possible
ORA-19507: failed to retrieve sequential file, handle="/tmp/mydir", parms=""
ORA-27029: skgfrtrv: sbtrestore returned error
ORA-19511: Error received from media manager layer, error text:
sbtpvt_open_input:file /tmp/mydir does not exist or cannot be accessed, errno=2

ORA-19511エラーの後に表示されるエラー・テキストはメディア・マネージャによって生成されたものであり、障害の根源を示しています。このエラーを解釈する方法は、メディア・マネージャのドキュメントを参照してください。

SBT 1.1のメディア管理エラーの解釈の例

テープ・ドライブを使用したバックアップ・ジョブ中に、次の出力が戻されたと想定します。

RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03009: failure of backup command on c1 channel at 09/04/2007 13:18:19
ORA-19506: failed to create sequential file, name="07d36ecp_1_1", parms=""
ORA-27007: failed to open file
SVR4 Error: 2: No such file or directory
Additional information: 7005
Additional information: 1
ORA-19511: Error received from media manager layer, error text:
SBT error = 7005, errno = 2, sbtopen: system error

SBT 1.1メディア・マネージャによって戻される最も重要な情報は、「Additional information」行にあるエラー・コードです。

Additional information: 7005

表23-3を参照すると、7005エラーが、メディア管理デバイスがビジー状態であることを示していることがわかります。メディア管理ソフトウェアが使用中か、またはそのソフトウェアに問題が発生しているため、そのソフトウェアを使用してデバイスに書き込むことができません。

注意:
sbtio.logには、Oracle Databaseではなくメディア管理ソフトウェアによって生成された情報が含まれています。そのため、それらのエラー・コードおよびメッセージを解釈するには、ご使用のメディア・ベンダーのドキュメントを参照する必要があります。sbtio.logに情報が記述されない場合、別の場所にエラー・メッセージが記述されているかどうか、またはメディア・マネージャ・エラーをsbtio.logに表示するために必要な手順があるかどうかを、ご使用のメディア・マネージャのサポートに問い合せてください。

RMANのリターン・コードの識別

RMANにエラーが発生したかどうかを確認する方法の1つは、リターン・コードまたは終了ステータスを調べることです。RMANクライアントは、そのクライアントが起動されたシェルに、エラーが発生しなかった場合は0(ゼロ)を戻し、エラーが発生した場合は0(ゼロ)以外のエラー値を戻します。

このリターン・コードへのアクセス方法は、RMANクライアントを起動した環境によって異なります。たとえば、UNIXおよびCシェルを実行している場合、RMANが完了すると、$statusというシェル変数にリターン・コードが配置されます。終了ステータスを戻す方法は、RMANクライアントではなくホスト・オペレーティング・システムの詳細によって異なります。

RMANのトラブルシューティングでのV$ビューの使用

LIST、REPORTおよびSHOWを使用しても、RMANアクティビティで必要なすべての情報が表示されない場合は、いくつかの有効なV$ビューで詳細を参照できます。

バックアップおよびリカバリ・ジョブを実行するサーバー・セッションで現在実行されている動作を確認すると有効な場合があります。表23-4に示すビューは、RMANジョブに関する情報を取得する場合に有効です。

表23-4 トラブルシューティングで有効なV$ビュー

ビュー

説明

V$PROCESS

現在アクティブなプロセスを識別します

V$SESSION

現在アクティブなセッションを識別します。このビューを使用して、RMANが割り当てたチャネルに対応するデータベース・サーバー・セッションを判断します。

V$SESSION_WAIT

セッションが待機中のイベントまたはリソースのリストを表示します

前述のビューを使用して、次のタスクを実行できます。

- RMANとメディア・マネージャの相互作用の監視

- サーバー・セッションとRMANチャネルの関連付け

RMANとメディア・マネージャの相互作用の監視

動的パフォーマンス・イベント・ビューのイベント名を使用して、Media Management APIに対するRMANコールを監視できます。イベント名は、SBTファンクションと1対1で対応します。次に例を示します。

Backup: MML v1 open backup piece
Backup: MML v1 read backup piece
Backup: MML v1 write backup piece
Backup: MML v1 query backup piece
Backup: MML v1 delete backup piece
Backup: MML v1 close backup piece
.
.
.

SBTイベントの完全なリストを取得するには、次の問合せを使用します。

SELECT NAME
FROM   V$EVENT_NAME
WHERE  NAME LIKE '%MML%';

サーバーは、Media Management APIでいずれかのファンクションをコールする前に、V$SESSION_WAITに行を追加して、STATE列に文字列WAITINGを含めます。V$SESSION_WAIT.SECONDS_IN_WAIT列には、サーバーが、このコールが戻されるのを待機している秒数が表示されます。SBTファンクションがメディア・マネージャから戻されると、この行は削除されます。

SBTイベント名に対応するV$SESSION_WAITの行には、問題は表示されません。これは、サーバーがこれらの行を実行時に更新するためです。これらの行は、コールが実行されると表示され、戻されると削除されます。ただし、SECONDS_IN_WAIT列の値が高い場合、メディア・マネージャが一時停止している可能性があります。

SBTイベントを監視するには、次のSQL問合せを実行します。

COLUMN EVENT FORMAT a17
COLUMN SECONDS_IN_WAIT FORMAT 999
COLUMN STATE FORMAT a15
COLUMN CLIENT_INFO FORMAT a30

SELECT p.SPID, s.EVENT, s.SECONDS_IN_WAIT AS SEC_WAIT,
sw.STATE, s.CLIENT_INFO
FROM   V$SESSION_WAIT sw, V$SESSION s, V$PROCESS p
WHERE  sw.EVENT LIKE '%MML%'
AND    s.SID=sw.SID
AND    s.PADDR=p.ADDR;

SQL出力を調べて、待機中のSBT機能を確認します。たとえば、次の出力には、RMANがsbtbackupファンクションが戻されるのを10分間待機していることが示されています。

SPID EVENT             SEC_WAIT   STATE           CLIENT_INFO
---- ----------------- ---------- --------------- ------------------------------
8642 Backup: MML creat 600        WAITING         rman channel=ORA_SBT_TAPE_1

注意:
V$SESSION_WAITビューにはデータベース・イベントのみが表示され、メディア・マネージャ・イベントは表示されません。

関連項目:
V$SESSION_WAITビューの詳細は、『Oracle Databaseリファレンス』を参照してください。

サーバー・セッションとRMANチャネルの関連付け

どのサーバー・セッションがどのRMANチャネルに対応しているかを確認するには、V$SESSIONおよびV$PROCESSを問い合せます。V$PROCESSのSPID列に、オペレーティング・システムのプロセスまたはスレッドのID番号が示されます。たとえば、UNIXではSPID列にプロセスIDが表示され、WindowsではSPID列にスレッドIDが表示されます。この情報を取得するには、複数のRMANセッションが同時にアクティブになっているかどうかに応じて、2つの基本的な方法があります。

アクティブなRMANセッションが1つの場合のサーバー・セッションとチャネルの一致

アクティブなRMANセッションが1つのみの場合、RMANチャネルに対応するサーバー・セッションIDを確認する最も簡単な方法は、RMANジョブの実行中、ターゲット・データベースで次の問合せを実行することです。

COLUMN CLIENT_INFO FORMAT a30
COLUMN SID FORMAT 999
COLUMN SPID FORMAT 9999

SELECT s.SID, p.SPID, s.CLIENT_INFO
FROM   V$PROCESS p, V$SESSION s
WHERE  p.ADDR = s.PADDR
AND    CLIENT_INFO LIKE 'rman%';

出力例を次に示します。

SID SPID         CLIENT_INFO
---- ------------ ------------------------------
14 8374         rman channel=ORA_SBT_TAPE_1

システム生成のデフォルトIDではなく、RMANのSET COMMAND IDコマンドを使用してIDを設定する場合、'rman%'ではなく、CLIENT_INFO列の値を検索します。

RMANセッションが複数の場合のサーバー・セッションとチャネルの一致

アクティブなRMANセッションが複数の場合、V$SESSION.CLIENT_INFO列に、各セッションのチャネルに対して同じ情報が表示される場合があります。次に例を示します。

SID SPID         CLIENT_INFO
---- ------------ ------------------------------
14 8374         rman channel=ORA_SBT_TAPE_1
9 8642         rman channel=ORA_SBT_TAPE_1

この場合、次の方法でSID値に対応するチャネルを確認します。

RMAN出力からのチャネルIDの取得

この方法では、まずRMAN出力からsid値を取得して、その値をSQL問合せで使用する必要があります。

バックアップ中にプロセスをチャネルに関連付ける手順

1. アクティブなセッションで、RMANジョブを通常どおりに実行し、出力を確認してチャネルのsidを取得します。たとえば、次の出力が表示される場合があります。

Starting backup at 21-AUG-01
allocated channel: ORA_SBT_TAPE_1
channel ORA_SBT_TAPE_1: sid=14 devtype=SBT_TAPE

2. RMANジョブの実行中に、SQL*Plusセッションを開始して、V$SESSIONおよびV$PROCESSビューを結合して問い合せます。たとえば、次のように入力します。

COLUMN CLIENT_INFO FORMAT a30
COLUMN SID FORMAT 999
COLUMN SPID FORMAT 9999

SELECT s.SID, p.SPID, s.CLIENT_INFO
FROM   V$PROCESS p, V$SESSION s
WHERE  p.ADDR = s.PADDR
AND    CLIENT_INFO LIKE 'rman%'
/

最初の手順で取得したsid値を使用して、どのチャネルがどのサーバー・セッションに対応しているかを確認します。

SID SPID         CLIENT_INFO
---------- ------------ ------------------------------
14 2036         rman channel=ORA_SBT_TAPE_1
12 2066         rman channel=ORA_SBT_TAPE_1

SET COMMAND IDを使用したサーバー・セッションとチャネルの関連付け

この方法では、RMANバックアップ・スクリプトでコマンドID文字列を指定します。これによって、この文字列のV$SESSION.CLIENT_INFOを問い合せることができます。

バックアップ中にプロセスをチャネルに関連付ける手順

1. 各セッションで、チャネルの割当て後、COMMAND IDを別々の値に設定して、目的のオブジェクトをバックアップします。たとえば、セッション1で次のように入力します。

RUN
{
ALLOCATE CHANNEL c1 TYPE disk;
SET COMMAND ID TO 'sess1';
BACKUP DATABASE;
}

セッション2で実行中のジョブで、コマンドIDをsess2などの文字列に設定します。

RUN
{
ALLOCATE CHANNEL c1 TYPE sbt;
SET COMMAND ID TO 'sess2';
BACKUP DATABASE;
}

2. RMANジョブの実行中に、SQL*Plusセッションを開始して、V$SESSIONおよびV$PROCESSビューを結合して問い合せます。たとえば、次のように入力します。

SELECT SID, SPID, CLIENT_INFO
FROM   V$PROCESS p, V$SESSION s
WHERE  p.ADDR = s.PADDR
AND    CLIENT_INFO LIKE '%id=sess%';

RMANジョブでSET COMMAND IDコマンドを実行した場合、CLIENT_INFO列は次の形式で表示されます。

id=command_id,rman channel=channel_id

出力例を次に示します。

SID SPID         CLIENT_INFO
---- ------------ ------------------------------
11 8358         id=sess1
15 8638         id=sess2
14 8374         id=sess1,rman channel=c1
9 8642         id=sess2,rman channel=c1

文字列rman channelを含む行に、バックアップを実行中のチャネルが表示されます。残りの行には、ターゲット・データベースへの接続が表示されます。

関連項目:
SET COMMAND IDの構文については、『Oracle Databaseバックアップおよびリカバリ・リファレンス』を参照してください。V$SESSIONおよびV$PROCESSの詳細は、『Oracle Databaseリファレンス』を参照してください。

Media Management APIのテスト

一部のプラットフォームでは、Oracleによってsbttestという診断ツールが提供されます。このユーティリティは、Oracle Databaseサーバーとして機能し、メディア・マネージャとの通信を試行することによって、メディア管理ソフトウェアの簡単なテストを実行します。

sbttestユーティリティの入手

UNIX上では、sbttestユーティリティは、通常$ORACLE_HOME/binに存在します。なんらかの理由でプラットフォームにこのユーティリティが存在しない場合、Oracleサポート・サービスからこのプログラムのCバージョンを入手してください。このバージョンのプログラムは、すべてのUNIXプラットフォームでコンパイルできます。

Solarisなどのプラットフォームでは、sbttestを使用する際に再リンクを行う必要はありません。その他のプラットフォームでは、再リンクが必要な場合があります。

sbttestユーティリティのオンライン・ドキュメントの取得

sbttestのオンライン・ドキュメントを入手するには、コマンドラインで次のコマンドを発行します。

% sbttest

このプログラムで使用可能な引数のリストが表示されます。

Error: backup file name must be specified
Usage: sbttest backup_file_name # this is the only required parameter
<-dbname database_name>
<-trace trace_file_name>
<-remove_before>
<-no_remove_after>
<-read_only>
<-no_regular_backup_restore>
<-no_proxy_backup>
<-no_proxy_restore>
<-file_type n>
<-copy_number n>
<-media_pool n>
<-os_res_size n>
<-pl_res_size n>
<-block_size block_size>
<-block_count block_count>
<-proxy_file os_file_name bk_file_name
[os_res_size pl_res_size block_size block_count]>
<-libname sbt_library_name>

各引数の意味も表示されます。例として、2つのオプション・パラメータの説明を次に示します。

Optional parameters:
-dbname  specifies the database name which will be used by SBT
to identify the backup file. The default is "sbtdb"
-trace   specifies the name of a file where the Media Management
software will write diagnostic messages.

sbttestユーティリティの使用

sbttestを使用すると、メディア・マネージャの簡単なテストを実行できます。

sbttestによって0(ゼロ)が戻される場合、テストがエラーなしで実行されています。これは、メディア・マネージャが正しくインストールされ、データ・ストリームを受け入れ、要求に応じて同じデータを戻すことができることを意味します。sbttestによって0以外の値が戻される場合、メディア・マネージャがインストールされていないか、正しく構成されていません。

sbttestの使用手順

1. コマンドラインでsbttestと入力し、プログラムがインストール済でシステム・パスに含まれていることを確認します。

% sbttest

プログラムが操作可能の場合、オンライン・ドキュメントが表示されます。

2. オンライン・ドキュメントに表示された任意の引数を指定して、プログラムを実行します。たとえば、some_file.fテスト・ファイルを作成してsbtio.logに出力を生成するには、次のコマンドを入力します。

% sbttest some_file.f -trace sbtio.log

既存のデータファイルのバックアップをテストすることもできます。たとえば、prodデータベースのtbs_33.fデータファイルをテストするには、次のコマンドを入力します。

% sbttest tbs_33.f -dbname prod

3. 出力を確認します。プログラムの実行中にエラーが発生した場合、障害を説明するメッセージが出力されます。たとえば、データベースがライブラリを検出できない場合、次の出力が戻されます。

libobk.so could not be loaded. Check that it is installed properly, and that
LD_LIBRARY_PATH environment variable (or its equivalent on your platform)
includes the directory where this file can be found. Here is some additional
information on the cause of this error:
ld.so.1: sbttest: fatal: libobk.so: open failed: No such file or directory

sbttestを実行可能でも、RMANバックアップを実行できない場合があります。次のような理由が考えられます。

- sbttestを実行したユーザーがOracle Databaseプロセスの所有者ではない。

- データベース・サーバーがメディア管理ライブラリにリンクされていないか、または必要に応じてメディア管理ライブラリを動的にロードできない。この場合、sbttestは機能しますが、メディア・マネージャに対するRMANによるバックアップは失敗します。

- sbttestプログラムはシェルからすべての環境変数を渡しているが、RMANは渡していない。

RMANコマンドの終了

実行中のRMANコマンドは、次の複数の方法で終了できます。

- 推奨する方法は、RMANインタフェースで[Control]キーを押しながら[C]キー(または、ご使用のシステムのアテンション・キーの組合せ)を押すことです。この操作では、テープのマウントを待機している場合など、割当て済チャネルがメディア管理コードで一時停止していないかぎり、そのチャネルも終了します。

- SQLのALTER SYSTEM KILL SESSION文を実行すると、RMANチャネルに対応するサーバー・セッションを終了できます。

- オペレーティング・システム上のRMANチャネルに対応するサーバー・セッションを終了します。

ALTER SYSTEM KILL SESSIONによるセッションの終了

RMANチャネル用のOracleセッションIDは、RMANログ内の、次のような書式のメッセージに示されています。

channel ch1: sid=15 devtype=SBT_TAPE

割当て済チャネルごとに、sidおよびdevtypeが表示されます。Oracle Databaseのsidはオペレーティング・システム・プロセスIDとは異なります。セッションを終了するには、SQLのALTER SYSTEM KILL SESSION文を使用します。

ALTER SYSTEM KILL SESSIONには、シリアル番号およびRMANメッセージに出力されたsidの2つの引数を指定できます。いずれの引数も、V$SESSIONを問い合せて取得できます。たとえば、次の文を実行します。ここで、sid_in_rman_outputはRMANメッセージから得られた番号です。

SELECT SERIAL#
FROM   V$SESSION
WHERE  SID=sid_in_rman_output;

問合せによって取得したsid_in_rman_outputおよびシリアル番号を代入して次の文を実行します。

ALTER SYSTEM KILL SESSION 'sid_in_rman_output,serial#';

メディア・マネージャ・コードでセッションが停止した場合、この文はセッションに影響を与えません。

オペレーティング・システム・レベルでのセッションの終了

サーバー・セッションに関連付けられたプロセスの検出および終了の方法は、オペレーティング・システムによって異なります。サーバー・セッションがどのプロセスにも関連付けられていないプラットフォームもあります。詳細は、ご使用のオペレーティング・システム固有のドキュメントを参照してください。

メディア・マネージャで応答しなくなったRMANセッションの終了

メディア・マネージャで応答しなくなったRMANジョブを終了する必要がある場合があります。チャネル接続がメディア・マネージャで応答しなくなった場合にRMANを終了する最も適切な方法は、メディア・マネージャ内のセッションを終了することです。この操作で問題が解決しない場合、Linuxなどの一部のプラットフォームでは、接続を行っているOracle Databaseプロセスを終了できる場合があります。(Oracleプロセスを終了すると、メディア・マネージャに問題が発生する場合があります。詳細は、ご使用のメディア・マネージャのドキュメントを参照してください。)

RMANセッションの構成要素

RMANセッションの特性は、オペレーティング・システムに応じて異なります。UNIXでは、RMANセッションには次のプロセスが関連付けられています。

- RMANクライアント・プロセス自体。

- ターゲット・データベースへの初期接続であるデフォルト・チャネル。

- 各割当て済チャネルに1つ対応付けられた、ターゲット・データベースへのターゲット接続。

- リカバリ・カタログを使用する場合、リカバリ・カタログ・データベースへのカタログ接続。

- DUPLICATE操作またはTSPITR操作中は、補助インスタンスへの補助接続。

- 様々な割当て済チャネルに対するRMANコマンドの実行の監視に使用される、ターゲット・データベースへのポーリング接続。デフォルトでは、RMANは1つのポーリング接続を確立します。ALLOCATE CHANNELコマンドまたはCONFIGURE CHANNELコマンドに異なる接続文字列を使用すると、RMANは追加のポーリング接続を確立します。ポーリング接続は、ALLOCATE CHANNELコマンドまたはCONFIGURE CHANNELコマンドに使用した各接続文字列に1つ存在します。

ジョブの一時停止中のプロセス動作

RMANが応答しなくなる理由は、通常、メディア・マネージャ・コードでテープ・リソースが使用可能になるまでチャネル接続が待機するためです。カタログ接続およびデフォルト・チャネルが一時停止しているように見えるのは、RMANからの指示を待機しているためです。ポーリング接続は、RMANプロセスの制御下でRPCをポーリングする間は無限にループしているように見えます。

RMANプロセス自体を終了すると、カタログ接続、補助接続、デフォルト・チャネルおよびポーリング接続が切断されます。メディア・マネージャ・コードの実行中以外に一時停止しているターゲット接続および補助接続も切断されます。メディア管理レイヤーで、ターゲット接続または補助接続が実行されている場合、これらのプロセスを終了するには、オペレーティング・システム・レベルで手動で終了する必要があります。

すべてのメディア・マネージャがOracle Databaseプロセスの終了を検出できるわけではありません。終了を検出しないメディア・マネージャは、リソースをビジー状態のままにしたり、処理を継続する場合があります。詳細は、ご使用のメディア・マネージャのドキュメントを参照してください。

カタログ接続を切断しても、RMANプロセスは終了されません。これは、RMANは、バックアップまたはリストアの実行中にはカタログ操作を実行しないためです。デフォルト・チャネルおよびポーリング接続を削除すると、RMANプロセスはチャネルの1つが存在しなくなったことを検出し、終了処理を実行します。この場合、前述のとおり、応答しなくなったチャネルへの接続はアクティブのままです。

RMANセッションの終了の基本手順

メディア・マネージャ・コードで応答しなくなったチャネルが終了されると、RMANプロセスはその終了を検出し、終了処理を実行します。その際、メディア管理レイヤーで実行可能なターゲット接続を除く、すべての接続を削除します。この場合にも、メディア・マネージャ・リソースに関する警告が当てはまります。

メディア・マネージャで応答しなくなったOracle Databaseプロセスを終了する手順

1. 「RMANのトラブルシューティングでのV$ビューの使用」で説明するように、V$SESSIONおよびV$SESSION_WAITを問い合せます。たとえば、次の問合せを実行します。

COLUMN EVENT FORMAT a17
COLUMN SECONDS_IN_WAIT FORMAT 999
COLUMN STATE FORMAT a10
COLUMN CLIENT_INFO FORMAT a30

SELECT p.SPID, s.EVENT, s.SECONDS_IN_WAIT AS SEC_WAIT,
sw.STATE, s.CLIENT_INFO
FROM   V$SESSION_WAIT sw, V$SESSION s, V$PROCESS p
WHERE  sw.EVENT LIKE '%MML%'
AND    s.SID=sw.SID
AND    s.PADDR=p.ADDR;

SQL出力を調べて、待機中のSBT機能を確認します。たとえば、次のような出力が表示されます。

SPID EVENT             SEC_WAIT   STATE      CLIENT_INFO
---- -----------------  ---------- ---------- -----------------------------
8642 Backup:MML write   600        WAITING    rman channel=ORA_SBT_TAPE_1
8374 Backup:MML write   600        WAITING    rman channel=ORA_SBT_TAPE_2

2. ご使用のプラットフォームに適切なオペレーティング・システム・レベルのツールを使用して、応答しなくなったセッションを終了します。たとえば、Linuxではkill -9コマンドを実行します。

% kill -9 8642 8374

一部のプラットフォームには、orakillというコマンドライン・ユーティリティが含まれています。このユーティリティを使用すると、特定のスレッドを終了できます。コマンド・プロンプトから、次のコマンドを実行します。ここで、sidはターゲットに対するデータベース・インスタンスで、thread_idは手順1の問合せで取得したSPID値です。

orakill sid thread_id

3. メディア・マネージャがプロセスも消去したことを確認します。消去されていないプロセスが存在する場合、次のバックアップまたはリストア操作が、以前のバックアップおよびリストア操作の問題が原因で再度フリーズする可能性があります。一部のメディア・マネージャでは、この唯一の解決策は、メディア・マネージャを停止して再起動することです。メディア・マネージャのドキュメントに必要な情報が記載されていない場合、メディア・マネージャのテクニカル・サポートに問い合せてください。

関連項目:
関連するコマンドについては、ご使用のオペレーティング・システム固有のドキュメントを参照してください。

第VII部

RMANを使用したデータの送信

次の章では、データベースおよび表領域のトランスポートおよび移行にRMANを使用する方法について説明します。この部に含まれる章は、次のとおりです。

- 第24章「データベースの複製」

- 第25章「データベースの複製: 高度なトピック」

- 第26章「トランスポータブル表領域セットの作成」

- 第27章「プラットフォーム間でのデータ転送」

24 データベースの複製

この章では、DUPLICATEコマンドを使用して、独立して機能するデータベース・コピーを作成する方法について説明します。

この章の内容は次のとおりです。

- RMANデータベースの複製の概要

- データベースの複製の準備

- ソース・データベースの適切な設定

- RMANの起動およびデータベースへの接続

- 複製で使用するためのRMANチャネルの構成

- データベースの複製

- 失敗後のDUPLICATEの再実行

RMANデータベースの複製の概要

データベースを複製するには、DUPLICATEコマンドを使用して、ソース・データベースにあるすべてのデータまたはそのサブセットをコピーします。複製データベース(コピー先のデータベース)は、ソース・データベース(コピー元のデータベース)から完全に独立して機能します。

データベースの複製の目的

複製データベースは様々な目的で有効であり、ほとんどの場合、テストに使用されます。複製データベースでは、次のタスクを実行できます。

- バックアップ手順およびリカバリ手順のテスト

- Oracle Databaseの新しいリリースへのアップグレードのテスト

- データベースのパフォーマンスにアプリケーションが与える影響のテスト

- スタンバイ・データベースの作成

- レポートの生成

たとえば、host1上の本番データベースをhost2上に複製し、host1上の本番データベースを通常どおりに実行したまま、host2上の複製データベースを使用してこのデータベースのリストアおよびリカバリを練習できます。

DUPLICATEコマンドの代わりにオペレーティング・システムのユーティリティを使用してデータベースをコピーした場合、コピーしたデータベースのDBIDは元のデータベースと同じになります。このコピーしたデータベースを元のデータベースと同じリカバリ・カタログに登録するには、DBNEWIDユーティリティを使用してDBIDを変更する必要があります(『Oracle Databaseユーティリティ』を参照)。これに対して、DUPLICATEコマンドを実行すると、複製データベースに対して異なるDBIDが自動的に割り当てられるため、複製データベースをソース・データベースと同じリカバリ・カタログに登録できます。

DUPLICATEコマンドを使用すると、まったく同じ機能を持つデータベースのコピーを作成したり、大きく異なる目的で使用されるフィジカル・スタンバイ・データベースを作成することができます。スタンバイ・データベースはプライマリ・データベースのコピーで、プライマリ・データベースのアーカイブ・ログ・ファイルを使用して継続的に更新できます。プライマリ・データベースにアクセスできない場合は、スタンバイ・データベースへのフェイルオーバーを実行し、それを新しいプライマリ・データベースにすることができます。ただし、データベース・コピーはこの用途には使用できません。データベース・コピーは、フェイルオーバーでの使用を目的としていないため、スタンバイの様々なリカバリ・オプションおよびフェイルオーバー・オプションをサポートしていません。

関連項目:
DUPLICATEコマンドを使用したスタンバイ・データベースの作成方法は、『Oracle Data Guard概要および管理』を参照してください。

データベースの複製の基本的な概念

ソース・ホストは、ソース・データベースをホストするコンピュータを表します。ソース・データベース・インスタンスは、ソース・データベースに関連付けられたインスタンスを表します。

転送先ホストは、複製データベースをホストするコンピュータを表します。ソース・ホストと転送先ホストは、同じコンピュータである場合も異なるコンピュータである場合もあります。複製データベースに関連付けられたデータベース・インスタンスは、補助インスタンスと呼ばれます。

注意:
同じソース・データベースを使用して同時データベース複製操作を実行することは、サポートされていません。

データベースの複製方法

RMANでは、2種類の基本的な複製がサポートされます。アクティブなデータベースの複製およびバックアップベースの複製です。RMANは、次の接続を使用しているかどうかにかかわらず、バックアップベースの複製を実行できます。

- ターゲット

- リカバリ・カタログ

アクティブなデータベースを複製する場合、両方への接続が必要です。

図24-1に、2つの複製方法のディシジョン・ツリーを示します。

図24-1 複製方法

アクティブなデータベースの複製

アクティブなデータベースの複製の場合、RMANは、ソース・データベース・インスタンスにTARGETとして、補助インスタンスにAUXILIARYとして接続します。RMANは使用中のソース・データベースをネットワーク経由で補助インスタンスにコピーします。これにより、複製データベースが作成されます。ソース・データベースのバックアップは必要ありません。図24-2に、アクティブなデータベースの複製を示します。

図24-2 アクティブなデータベースの複製

バックアップベースの複製

バックアップベースの複製の場合、RMANでは、既存のRMANバックアップおよびコピーを使用して複製データベースを作成します。この複製方法では、相互に排他的な次の方法のいずれかを使用します。

- ターゲット・データベース接続を行わない複製。RMANはリカバリ・カタログからバックアップのメタデータを取得します。

- ターゲット・データベース接続を行わず、リカバリ・カタログを使用しない複製。RMANはBACKUP LOCATIONからバックアップおよびコピーが存在する場所のメタデータを取得します。

- ターゲット・データベース接続を行う複製。RMANはターゲット・データベースの制御ファイルまたはリカバリ・カタログからバックアップのメタデータを取得します。

図24-3に、ターゲット接続を行わない場合のバックアップベースの複製を示します。RMANは、リカバリ・カタログ・データベース・インスタンスおよび補助インスタンスに接続します。転送先ホストは、複製データベースの作成に必要なRMANバックアップにアクセスできる必要があります。

図24-3 ターゲット接続を行わない場合のバックアップベースの複製

図24-4に、ターゲットまたはリカバリ・カタログ・データベース・インスタンスへの接続を行わない場合のバックアップベースの複製を示します。RMANは、転送先ホスト上の複製データベースの補助インスタンスに接続します。複製のためのすべてのバックアップまたはコピーが含まれているディスクのバックアップ場所が、転送先ホストによって使用可能である必要があります。

図24-4 ターゲット接続またはリカバリ・カタログ接続を行わない場合のバックアップベースの複製

図24-5に、ターゲット接続を行う場合のバックアップベースの複製を示します。RMANは、ソース・データベース・インスタンスおよび補助インスタンスに接続します。必要に応じて、RMANはリカバリ・カタログ・データベース(図では非表示)に接続できます。転送先ホストは、複製データベースの作成に必要なRMANバックアップにアクセスできる必要があります。

図24-5 ターゲット接続を行う場合のバックアップベースの複製

複製データベースの内容

複製データベースには、ソース・データベースと同じ内容か、またはソース・データベース内の表領域のサブセットのみを含めることができます。たとえば、TABLESPACEオプションを使用すると、指定した表領域のみを複製できます。また、SKIP READONLYオプションを使用すると、複製データベースから読取り専用表領域を除外できます。

RMANによるデータベースの複製方法

バックアップベースの複製では、複製の主な作業は補助チャネルによって実行されます。これらのチャネルは、宛先ホスト上の補助インスタンスのサーバー・セッションに対応しています。アクティブなデータベースの複製では、主な作業はターゲット・チャネルによって実行されます。

複製のための明示的な時点が提供されていない場合でも、RMANでデータベースのPoint-in-Timeリカバリを実行する必要があります。Point-in-Timeリカバリが必要なのは、ソース・データベースのオンラインREDOログ・ファイルがバックアップされておらず、複製データベースに適用できないためです。複製データベースをリカバリできるのは、ソース・データベースによってアーカイブされた最新のREDOログ・ファイルの時点までです。

RMANは、複製操作のうち、次の処理を自動化します。

1. 次の条件を満たしている場合に、補助インスタンスのデフォルトのサーバー・パラメータ・ファイルを作成します。

- 複製にはスタンバイ・データベースを使用しない。

- サーバー・パラメータ・ファイルは複製されない。

- 補助インスタンスは、サーバー・パラメータ・ファイルを使用して起動されていない。

2. UNTIL句の要件を満たす最新の制御ファイルを、アクティブなデータベースのバックアップまたはコピーからリストアします。

3. リストアまたはコピーされたバックアップ制御ファイルを、アクティブなデータベースからマウントします。

注意:
ソース・データベースの制御ファイルに無効なスレッドが含まれる場合、それらのスレッドも複製データベースで無効になります。

4. RMANリポジトリを使用して、データファイルを補助インスタンスにリストアするためのバックアップを選択します。この手順は、バックアップベースの複製に適用されます。

5. 複製データファイルをリストアおよびコピーし、増分バックアップとアーカイブREDOログ・ファイルを使用して、現在以外の時点にリカバリします。

6. データベース・インスタンスを停止し、NOMOUNTモードで再起動します。

7. 新しい制御ファイルを作成します(この制御ファイルによって、新しいDBIDが作成されてデータファイルに格納されます)。

8. RESETLOGSオプションを使用して複製データベースをオープンし、新しいデータベース用のオンラインREDOログを作成します。

関連項目:
複製データベースにコピーされるファイルの詳細は、『Oracle Databaseバックアップおよびリカバリ・リファレンス』のDUPLICATEに関する項を参照してください。

データベースの複製の基本手順

この項では、データベースの複製の基本手順について説明します。詳細は、各手順のリンク先を参照してください。

データベースを複製する手順

1. データベースを複製する準備をします。
「データベースの複製の準備」を参照してください。

2. RMANを起動し、必要なデータベース・インスタンスに接続します。
「RMANの起動およびデータベースへの接続」を参照してください。

3. ソース・データベースを適切な状態に設定します(必要な場合)。
「ソース・データベースの適切な設定」を参照してください。

4. RMANチャネルを構成します(必要な場合)。
「複製で使用するためのRMANチャネルの構成」を参照してください。

5. 複製を実行します。
「データベースの複製」を参照してください。

データベースの複製の準備

データベースを複製する前に、複製方法を決定し、補助データベース・インスタンスを含めてデータベース環境を準備する必要があります。

複製の準備の手順

1. 複製方法を選択します。
「手順1: 複製方法の選択」を参照してください。

Oracle Real Application Clusters (Oracle RAC)データベースの複製では、補助データベースのCLUSTER_DATABASE初期化パラメータをFALSEに設定します。複製完了後に、このパラメータはTRUEに再設定できます。

2. 複製データベース・ファイルの名前の指定方法を選択します。
「手順2: 複製ファイルの名前の指定方法の選択」を参照してください。

3. バックアップベースの方法の場合は、バックアップに補助インスタンスからアクセスできるようにします。バックアップベースの方法でない場合、この手順をスキップします。
「手順3: 複製インスタンスからバックアップへのアクセス可能化」を参照してください。

4. データベースへのリモート・アクセスを準備します。
「手順4: データベースへのリモート・アクセスの準備」を参照してください。

5. 補助インスタンスを準備します。
「手順5: 初期化パラメータ・ファイルの作成と補助インスタンスの起動」を参照してください。

手順1: 複製方法の選択

ビジネス要件およびデータベース環境に応じて、状況に合った最適な複製方法を決定します。次の質問事項を検討してください。

- それぞれの複製方法の前提条件を十分に理解しているかどうか。
詳細は、『Oracle Databaseバックアップおよびリカバリ・リファレンス』のDUPLICATEコマンド・エントリの前提条件に関する項を参照してください。すべての複製方法に共通する前提条件もあります。そのような条件の例を次に示します。

- ソース・データベースおよび複製データベースは、同じプラットフォーム上にある必要があります。DUPLICATEコマンドは、同じオペレーティング・システムの32ビット版および64ビット版を、同じプラットフォームに属しているとみなします。

- DUPLICATEコマンドを使用する場合は、補助インスタンスで複製作業を実行するために1つ以上の補助チャネルが必要です。

その他の前提条件は特定のものであり、複製方法に応じて異なります。たとえば、アクティブな複製では、ソース・インスタンスと補助インスタンスにソース・データベースと同じパスワードを使用する必要があります。一方で、ターゲット・データベースおよびリカバリ・カタログに接続しないバックアップベースの複製では、すべてのバックアップおよびデータベース・コピーが単一の場所に存在することのみが必要とされます。

- ソース・データベースのバックアップがすでに存在しているかどうか。
アクティブなデータベースの複製の主なメリットとしては、ソース・データベースをバックアップする必要のないことがあげられます。アクティブな複製では、マウントされたデータベース・ファイルまたはオンラインのデータベース・ファイルがネットワークを介して補助インスタンスにコピーされます。この方法のデメリットの1つとしては、作業がネットワークのパフォーマンスに悪影響を及ぼすことがあげられます。また、別のデメリットとして、ファイルを補助ホストに転送するために必要なプロセスがソース・データベースによって実行されているため、ソース・データベースおよび本番ワークロードに影響を与えることもあげられます。

ソース・データベースのバックアップがすでに存在し、ネットワークへの影響を許容できない場合は、バックアップベースの複製をお薦めします。バックアップを一時記憶域にコピーし、手動で転送先ホストに転送できます。ターゲットまたはリカバリ・カタログとの接続を使用して複製が作成される場合、転送先ホストのバックアップ・ファイルは、ソース・ホスト上のバックアップ・ファイルと同じファイル仕様である必要があります。それ以外の場合、これは要件ではありません。

- リカバリ・カタログが使用できるかどうか。
リカバリ・カタログが存在する場合は、RMANがTARGETとしてソース・データベースに接続されていなくても、バックアップベースの複製を実行できます。この方法は、補助ホストからソース・データベースへのネットワーク接続が制限されたり、断続的に中断されるような場合に役立ちます。TARGET接続を行わない複製では、ソース・データベースは複製の影響を受けません。

- 宛先ホストでどの程度のディスク領域が使用できるか。
ディスク・バックアップを使用して複製を実行する場合、宛先ホストのディスク領域が問題となることがあります。たとえば、ソース・データベースが1テラバイト(TB)で、共有ディスクまたはネットワーク・ファイル・システム(NFS)を使用せずにディスク・バックアップからデータベースを複製する場合は、宛先ホストで2テラバイト(TB)以上の領域を使用できる必要があります。NFSのパフォーマンスがボトルネックとなるため、環境によっては、手動でバックアップを転送する必要があります。

- ソース・ホストと宛先ホストの接続がLANまたはWANであるかどうか。
アクティブなデータベースの複製のパフォーマンスは、Local Area Network(LAN)よりもWide Area Network(WAN)の方が低下する可能性があります。WANにおけるパフォーマンスの低下を許容できないときは、バックアップベースの複製のみが実行可能な選択肢となる場合があります。

- データベースをいつ複製する予定か。
ユーザー・アクティビティが高い時間帯にデータベースを複製する必要がある場合には、アクティブな複製によって生じるネットワーク・スループットの損失が問題となる可能性があるため、バックアップベースの複製をお薦めします。また、アクティブなデータベースの複製の場合は、補助ホストへファイルをコピーするときに必要となるRMANチャネルが、パフォーマンスに影響を与えることがあります。

手順2: 複製ファイルの名前の指定方法の選択

データベースの複製時に、RMANによって、複製制御ファイル、データファイル、一時ファイルおよびオンラインREDOログ・ファイルの名前が生成されます。このため、これらのファイルの名前の指定方法を決定する必要があります。

最も簡単な複製の方法として、ソース・データベースと同じ名前を使用するよう複製データベースを構成する方法をお薦めします。同じ名前を使用する場合は、環境が次の要件を満たしている必要があります。

- ソース・データベースがASMディスク・グループを使用している場合、複製データベースは同じ名前のASMディスク・グループを使用する必要があります。

- ソース・データベース・ファイルがOracle Managed Filesの場合、補助インスタンスはソース・データベースと同じディレクトリの場所に、DB_FILE_CREATE_DESTを設定する必要があります。ソース・ホスト上と宛先ホスト上でディレクトリが同じであっても、Oracle Databaseは複製ファイルに対して相対ファイル名を選択します。

- Oracle RAC環境を使用している場合、ソース・ホストと転送先ホストの両方に同じORACLE_SIDを使用する必要があります。

- ソース・データベースのデータベース・ファイルの名前にパスが含まれている場合、そのパス名は複製データベースにあるパス名と同じである必要があります。

前述の推奨事項に従って環境を構成する場合、複製ファイルの名前の指定で必要となる追加の構成はありません。

関連項目:
複製ファイルに対して異なる名前を使用する、より複雑な名前の指定方法については、「複製データベース・ファイルの代替名の指定」を参照してください。

手順3: 複製インスタンスからバックアップへのアクセス可能化

注意:
アクティブなデータベースの複製を実行している場合は、この項をスキップし、「手順4: データベースへのリモート・アクセスの準備」に進みます。

ターゲットおよびリカバリ・カタログへの接続を使用して、またはターゲット接続のみを使用して複製を実行している場合、RMANでは、RMANリポジトリのメタデータを使用して、複製に必要なバックアップおよびアーカイブREDOログ・ファイルを検索します。RMANがリカバリ・カタログに接続される場合、RMANはカタログからバックアップ・メタデータを取得します。RMANがカタログに接続されない場合は、(ターゲット接続を行うバックアップベースの複製のときなど)、制御ファイルからメタデータを取得します。

ターゲットにもリカバリ・カタログにも接続せずに複製を実行している場合を除いて、バックアップの名前はRMANリポジトリに記録されている名前と同じ名前で使用できる必要があります。宛先ホスト上の補助チャネルがすべてのデータファイル・バックアップおよびアーカイブREDOログ・ファイルにアクセスできることを確認してください(複製データベースを目的の時点までリストアおよびリカバリするために必要です)。アクセスできない場合、複製は失敗します。アーカイブREDOログ・ファイルは、イメージ・コピーまたはバックアップ・セットとして使用可能です。

注意:
データベース・バックアップは、BACKUP DATABASEで生成する必要はありません。個々のデータファイルの全体バックアップおよび増分バックアップを組み合せることができますが、すべてのデータファイルの全体バックアップが必要です。

補助インスタンスからSBTバックアップへのアクセス可能化

この作業手順はメディア・マネージャの構成によって異なります。

補助インスタンスからSBTバックアップへのアクセスを可能にするための手順

1. 必要に応じて、宛先ホストにメディア管理ソフトウェアをインストールします。

2. 宛先ホストからバックアップが含まれているテープにアクセスできるようにします。通常、次のいずれかを実行します。

- リモート・ホストに接続されているドライブに、テープを物理的に移動します。

- ネットワーク・アクセスが可能なテープ・サーバーを使用します。

3. 必要に応じて、リモート・メディア管理ソフトウェアにテープの存在について通知します。

補助インスタンスからディスク・バックアップへのアクセス可能化

補助インスタンスからディスク・バックアップへのアクセスを可能にする場合は、ターゲットまたはリカバリ・カタログに接続された状態でデータベースを複製するかどうかによって、方法が異なります。ターゲットまたはリカバリ・カタログに接続しない場合、複製のためのBACKUP LOCATIONを指定する必要があります。

BACKUP LOCATIONを使用する場合、バックアップおよびコピーは共有の場所に存在するか、または宛先ホスト上のBACKUP LOCATIONに移動することができます。後者の場合は、バックアップまたはコピーの名前や元のパスを保持する必要はありません。BACKUP LOCATIONオプションで指定された場所には、複製されるすべてのファイルをリストアし目的の時点までリカバリするために十分なバックアップ・セット、イメージ・コピーおよびアーカイブ・ログが含まれる必要があります。

バックアップは、すべて同じ時点のものである必要はありません。また、すべてバックアップ・セットである必要も、すべてイメージ・コピーである必要もありません。データファイル・バックアップは、イメージ・コピーまたはバックアップ・セットとして提供されることができます。 アーカイブ・ログは、通常の形式またはアーカイブ・ログのバックアップ・セットとして提供されることができます。

異なる時点のバックアップを使用する場合、バックアップ場所には、最も古いバックアップの開始から目的のリカバリ・ポイントまでの期間をカバーするアーカイブ・ログが含まれる必要があります。

バックアップ場所に複数のデータベースのバックアップ・ファイルが含まれる場合、DATABASE句で、複製するデータベースの名前を指定する必要があります。バックアップ場所に同じ名前を持つ複数のデータベースのバックアップ・ファイルが含まれる場合、DATABASE句で、複製するデータベースの名前とDBIDの両方を指定する必要があります。

ソース・データベースの高速リカバリ領域は、バックアップ場所としての使用に特に適しています。これは、複製に必要なすべてのファイルがほぼ常に含まれているためです。高速リカバリ領域をバックアップ場所として使用するには、宛先システムからリモートでアクセスするか、または高速リカバリ領域の内容を宛先システムにコピーすることができます。

BACKUP LOCATIONを使用しない場合は、次の相互に排他的な例ごとに、方法が異なります。

- ソース・ホストと宛先ホストが同一のファイル・システムである場合
これは最も簡単で推奨される例です。たとえば、ソース・データベースのバックアップが/dsk1/bkpに格納されているとします。この場合、次のいずれかの方法で、宛先ホストからディスク・バックアップにアクセスできるようになります。

- バックアップをソース・ホストから宛先ホストの同一のパスに手動で転送します。たとえば、バックアップがソース・ホストの/dsk1/bkpにある場合は、FTPを使用してそれらのバックアップを宛先ホストの/dsk1/bkpに転送します。

- NFSまたは共有ディスクを使用して、宛先ホストで同じパスにアクセスできるようにします。たとえば、ソース・ホストから/dsk1/bkpにアクセスできると想定して、NFSを使用して宛先ホストに/dsk1/bkpをマウントし、/dsk1/bkpをマウント・ポイント名として使用します。

- ソース・ホストと宛先ホストのファイル・システムが異なる場合
この場合、ソース・ホストで使用するディレクトリ名と同じディレクトリ名は、宛先ホストで使用できません。次の選択肢があります。

- バックアップを使用可能にするために共有ディスクを使用できる場合。この項では、共有ディスクを使用する方法について説明します。

- バックアップを使用可能にするために共有ディスクを使用できない場合。この方法については、「共有ディスクを使用しないディスク・バックアップのアクセス可能化」を参照してください。

srchostおよびdsthostという2つのホストがあり、NFSまたは共有ディスクにアクセスできるとします。srchost上のデータベースは、srcdbです。srcdbのバックアップは、ホストsrchost上の/dsk1/bkp内に存在します。ディレクトリ/dsk1/bkpは転送先ホストで使用されていますが、ディレクトリ/dsk2/dupは、いずれのホストでも使用されていません。

バックアップをソース・ホストから宛先ホストに転送する手順

1. ソース・ホストまたは宛先ホストのいずれかに、バックアップを格納するディレクトリを作成します。
たとえば、宛先ホスト上にバックアップ・ディレクトリ/dsk2/dupを作成します。

2. 前の手順で作成したディレクトリをもう一方のホストにマウントします。ディレクトリとマウント・ポイントの名前が同一であることを確認します。
たとえば、宛先ホストに/dsk2/dupを作成した場合は、NFSを使用してこのディレクトリを/dsk2/dupとしてソース・ホストにマウントします。

3. バックアップを宛先ホスト上の新しい場所で使用できるようにします。次のいずれかの方法を使用できます。

- RMANをTARGETとしてソース・データベースに接続し、「RMANバックアップのバックアップ」で説明されているBACKUPコマンドを使用して、バックアップのバックアップを作成します。たとえば、BACKUP COPY OF DATABASEコマンドを使用して、ソース・ホストの/dsk1/bkpにあるバックアップをソース・ホストの/dsk2/dupにコピーします。この場合、RMANは、新しい場所のバックアップを自動的にカタログに追加します。

- オペレーティング・システム・ユーティリティを使用して、バックアップを新しい場所に転送します。たとえば、FTPを使用して、ソース・ホストの/dsk1/bkpから宛先ホストの/dsk2/dupにバックアップを転送するか、cpコマンドを使用して、ソース・ホストの/dsk1/bkpからソース・ホストの/dsk2/dupにバックアップをコピーします。後で、RMANをTARGETとしてソース・データベースに接続し、CATALOGコマンドを使用して、手動で転送したバックアップの場所で、RMANのリポジトリを更新します。

手順4: データベースへのリモート・アクセスの準備

別のホストからデータベースにアクセスする必要がある場合、パスワード・ファイルおよびOracle Netからの接続を設定する必要があります。このタイプの設定は、セキュリティに影響を与える可能性があることに注意してください。

必要な場合の接続の確立

手動でパスワード・ファイルを作成する手順

パスワード・ファイルを作成するには、『Oracle Database管理者ガイド』の手順を実行します。

パスワード・ファイルに許可されているファイル名のタイプおよびパスワード・ファイルの場所は、プラットフォームとオペレーティング・システムの両方に固有です。

関連項目:

- 手動でパスワード・ファイルを作成する方法については、『Oracle Data Guard概要および管理』を参照してください。

- Oracle Database Advanced Security管理者ガイド

Oracle Netの接続を確立し静的リスナーを設定する手順

データベースに接続するようにクライアントを構成し、リスナーの静的サービス情報を追加するには、『Oracle Database Net Services管理者ガイド』の手順を実行します。

補助インスタンス用のパスワード・ファイルの作成

宛先ホスト上の補助インスタンスのパスワード・ファイルを作成するには、次の方法があります。

- パスワード・ファイルを手動で作成します。
DUPLICATE ... FROM ACTIVE DATABASEを使用する場合は、追加の要件があります。SYSユーザーIDを使用する必要があり、パスワードがソース・データベースのパスワードと一致する必要があります。補助インスタンスを起動し、ソース・データベースをその補助インスタンスに接続できるように、1つのパスワードが含まれているパスワード・ファイルを作成することができます。

- DUPLICATE... FROM ACTIVE DATABASEコマンドにPASSWORD FILEオプションを指定します。
この場合、RMANは、ソース・データベース・パスワード・ファイルを転送先ホストにコピーし、既存のすべての補助インスタンスのパスワード・ファイルを上書きします。この方法は、複製データベースで使用できるようにするパスワードがソース・データベースのパスワード・ファイルに複数含まれている場合に有効です。

関連項目:
Oracle Database管理者ガイド

注意:
FROM ACTIVE DATABASEオプションを使用してスタンバイ・データベースを作成する場合、RMANは、パスワード・ファイルを常にスタンバイ・ホストにコピーします。

手順5: 初期化パラメータ・ファイルの作成と補助インスタンスの起動

初期化パラメータ・ファイルの場所と内容は、「手順2: 複製ファイルの名前の指定方法の選択」での決定によって異なります。この項では、次のことを想定しています。

- ソース・ホストと転送先ホストで同じ名前を使用するという推奨される方法を選択します。つまり、Oracle RAC環境では、ソース・ホストと転送先ホストに同じORACLE_SIDを使用します。

- 補助インスタンス用にテキストベースの初期化パラメータ・ファイルを作成します。表25-5「補助インスタンスの初期化パラメータ」を参照してください。

- 初期化パラメータ・ファイルは、SQL*Plusを実行するホストのオペレーティング・システム固有のデフォルトの場所に配置されます。
たとえば、LinuxおよびUNIXではデフォルトの初期化パラメータ・ファイル名はORACLE_HOME/dbs/initORACLE_SID.oraですが、WindowsではORACLE_HOME\database\initORACLE_SID.oraです。

- DUPLICATEコマンドのSPFILE句を指定する予定です。
このDUPLICATE ... SPFILEという方法が最も簡単です。これは、複製中にRMANによって、自動的にサーバー・パラメータ・ファイルがソース・データベースから補助インスタンスへコピーされるか、またはそのファイルがバックアップからリストアされるためです。サーバー・パラメータ・ファイルが補助インスタンスに存在する場合は、RMANによって上書きされます。

前述の要件を満たすことができない場合は、「サーバー・パラメータ・ファイルが存在しない場合のデータベースの複製」を参照してください。

初期化パラメータ・ファイルの作成および補助インスタンスの起動の手順

1. テキスト・エディタを使用して、テキストベースの初期化パラメータ・ファイルとして使用するための空のファイルを作成します。

2. SQL*Plusを実行するホストのオペレーティング・システム固有のデフォルトの場所に、初期化パラメータ・ファイルをコピーします。

3. パラメータ・ファイルのDB_NAMEを任意の値に設定します。
必須の初期化パラメータは、DB_NAMEのみです。次に、DB_NAMEの設定例を示します。

DB_NAME=somevalue

4. 必要に応じて、Oracle RACに必要なパラメータおよびOracle Netを介してSYSDBA権限を持つユーザーIDを使用して接続するためのパラメータなど、その他の初期化パラメータを設定します。

5. SQL*Plusを起動し、SYSDBA権限で補助インスタンスに接続します。補助インスタンスをNOMOUNTモードで起動します(ファイルがデフォルトの場所にある場合には、STARTUPコマンドのPFILEパラメータは不要です)。

SQL> STARTUP NOMOUNT

注意:
サーバー・パラメータ・ファイルではなく、テキストベースの初期化パラメータ・ファイルで補助インスタンスが起動されることを確認してください。制御ファイルの作成、補助インスタンスのマウントまたはオープンは実行しないでください。

ソース・データベースの適切な設定

注意:
ターゲット接続を行わないバックアップベースの複製を実行する場合には、「複製で使用するためのRMANチャネルの構成」に進みます。

RMANがTARGETとしてソース・データベースに接続されている場合、複製を行うには、ソース・データベースが適切な状態に設定されている必要があります。

ソース・データベースが適切な状態にあることを確認する手順

1. ソース・データベース・インスタンスをマウントまたはオープンしていない場合は、マウントまたはオープンします。

2. アクティブなデータベースの複製を実行している場合は、次の追加要件を満たしていることを確認します。

- ソース・データベースがオープンしている場合は、アーカイブを有効にする必要があります。

- ソース・データベースがオープンしていない場合は、データベースにインスタンス・リカバリは必要ありません。

RMANの起動およびデータベースへの接続

この項では、RMANクライアントを起動し、「手順1: 複製方法の選択」で選択した複製方法で必要となるデータベース・インスタンスに接続します。RMANクライアントは、ネットワーク経由で必要なデータベースに接続可能であるかぎり、任意のホスト上に配置できます。

RMANを起動し、ターゲット・インスタンスおよび補助インスタンスに接続する手順

1. 必要なデータベース・インスタンスに接続可能なホスト上で、RMANを起動します。

2. RMANプロンプトで、選択した複製方法に必要となるデータベース・インスタンスに対して、CONNECTコマンドを実行します。

- アクティブなデータベースの複製の場合、ソース・データベースにTARGETとして、補助インスタンスにAUXILIARYとして接続する必要があります。両方のインスタンスに同じSYSDBAパスワードを使用し、ネット・サービス名を提供してAUXILIARYインスタンスに接続する必要があります。リカバリ・カタログ接続は任意です。

- ターゲット接続を行わないバックアップベースの複製の場合、AUXILIARYとして補助インスタンスに接続し、CATALOGとしてリカバリ・カタログに接続する必要があります。

- ターゲット接続を行うバックアップベースの複製の場合、TARGETとしてソース・データベースに接続し、AUXILIARYとして補助インスタンスに接続する必要があります。リカバリ・カタログは任意です。

- ターゲットおよびリカバリ・カタログへの接続を行わないバックアップベースの複製の場合、AUXILIARYとして補助インスタンスに接続する必要があります。

次のアクティブなデータベースの複製の例では、3つのすべてのデータベース・インスタンスにネット・サービス名を使用して接続します。

RMAN> CONNECT TARGET SYS/sysdba@prod;    # source database
connected to target database: PROD (DBID=39525561)

RMAN> CONNECT AUXILIARY SYS/sysdba@dupdb; # duplicate database instance
connected to auxiliary database: DUPDB (not mounted)

RMAN> CONNECT CATALOG rman/rman@catdb;    # recovery catalog database
connected to recovery catalog database

複製で使用するためのRMANチャネルの構成

バックアップベースの複製では、ソース・データベース・インスタンスではなく、補助インスタンスのチャネルによって、RMANのバックアップがリストアされます。チャネル構成は複製方法に応じて異なります。

アクティブなデータベースの複製のためのチャネル構成

アクティブなデータベースの複製では、ソース・データベースのチャネル構成を変更したり、AUXILIARYチャネルを構成する必要はありません。ただし、RMANがネットワークを介してパラレルにファイルをコピーできるよう、ソース・データベースのディスク・チャネルのパラレル化設定を増加させる必要がある場合があります。

関連項目:
CONFIGUREコマンドの詳細は、『Oracle Databaseバックアップおよびリカバリ・リファレンス』を参照してください。

バックアップベースの複製のためのチャネル構成

RMANでは、ソース・データベースのチャネル構成と同じ構成を宛先ホスト上の複製に使用できます。ソース・データベースのチャネルでAUXILIARYオプションを指定しなくても、RMANでこれらの構成を利用できます。

次の追加事項に注意してください。

- 補助チャネルのチャネル・タイプ(DISKまたはsbt)は、バックアップ・メディアと一致している必要があります。通常、ディスク・バックアップ用に割り当てるチャネルの数を増やすと、複製が高速になります。ディスクが最大の読取り/書込み速度に達した後、複製の速度を速くすることはできません。テープ・バックアップの場合は、チャネルの数を使用可能なデバイスの数に制限します。

- ただし、補助チャネルに特別なパラメータが必要な場合(別のメディア・マネージャを指す場合など)は、CONFIGUREコマンドのAUXILIARYオプションを指定して自動チャネルを構成します。

- ターゲット接続もリカバリ・カタログも使用せずに複製を実行する場合、ディスク・チャネルのみが使用できます。ユーザーによって割り当てられたチャネルが使用されていない場合、最初に制御ファイルをリストアするチャネルは1つのみです。制御ファイルがマウントされた後は、割り当てられるチャネルの数はリストアされた制御ファイルの構成によって異なります。

データベースの複製

この項では、データベースを複製する最も基本的な手順について説明します。この項では、次のことを想定しています。

- リモート・ホストにデータベースを複製します。複製データベース・ファイルには、ソース・データベース・ファイルと同じ名前を使用します。

注意:
この構成でDUPLICATEコマンドを実行する場合は、DUPLICATEコマンドにNOFILENAMECHECKオプションを指定する必要があります。ソース・データベースと同じホスト上にデータベースを複製する場合は、NOFILENAMECHECKが指定されていないことを確認してください。

- データベース全体を複製します。他の例については、「ソース・データベース表領域のサブセットの複製」を参照してください。

同じディレクトリ構造を持つリモート・ホストにデータベースを複製する手順

1. 「データベースの複製の基本手順」の手順1から4が完了していることを確認します。

2. DUPLICATEコマンドを実行します。

例24-1に、SPFILE句が指定された場合のアクティブな複製の実行方法を示します。DUPLICATEでは、ソース・データベース・ファイルの名前が複製データベース・ファイルの名前と同じであるため、NOFILENAMECHECKオプションが必要です。

PASSWORD FILEオプションを指定すると、RMANはパスワード・ファイルを転送先ホストにコピーします。RMANは、サーバー・パラメータ・ファイルを転送先ホストに自動的にコピーし、サーバー・パラメータ・ファイルを使用して補助インスタンスを起動し、必要なすべてのデータベース・ファイルおよびアーカイブREDOログをネットワークを介して転送先ホストにコピーし、データベースをリカバリします。最後に、RMANは、RESETLOGSオプションを指定してデータベースをオープンし、オンラインREDOログを作成します。

例24-1 同じディレクトリ構造を持つホストへの複製(アクティブ)

DUPLICATE TARGET DATABASE TO dupdb
FROM ACTIVE DATABASE
PASSWORD FILE
SPFILE
NOFILENAMECHECK;

ターゲット接続を行わないバックアップベースの複製の例

これは例24-1を少し変更した例です。この例では、RMANは、ソース・データベースに対してTARGET接続を行いません。例24-2では、ソース・データベースprodの複製が、以前のデータベース・インカネーションの2007年の状態で作成されます。BACKUP LOCATIONが提供されていないため、RMANはソース・データベースに接続していませんが、リカバリ・カタログに接続する必要があります。

例24-2 過去の特定の時点までのデータベースの複製(バックアップベース)

DUPLICATE DATABASE prod DBID 8675309 TO dupdb
UNTIL TIME "TO_DATE('11/01/2007', 'MM/DD/YYYY')"
SPFILE
NOFILENAMECHECK;

例24-2の特徴は、次のとおりです。

- FROM ACTIVE DATABASE句が指定されていません。句を指定しないと、RMANでは、バックアップベースの複製が行われます。

- DBIDが指定されています。これは、ソース・データベース名prodがリカバリ・カタログ内で一意ではないためです。

- NOFILENAMECHECKチェックが指定されています。これは、複製データベース・ファイルでソース・データベース・ファイルと同じ名前を使用する場合にはこのオプションが必要となるためです。

類似の例として、アーカイブ・バックアップをリストアする必要があるとします。このバックアップは、データベースのリストアおよびリカバリに必要なすべてのファイルが含まれているという点で包括的なバックアップです。テストのためにアーカイブ・バックアップをリストアする場合は、一時インスタンスを作成し、DUPLICATEコマンドを使用する方法をお薦めします。この方法を使用すると、ソース・データベースに影響が及ぼされません。

DUPLICATEコマンドで、アーカイブ・バックアップを使用して作成されたリストア・ポイントを指定する必要があります。リストア・ポイントが制御ファイル内に存在しているときに、RMANがカタログまたはソース・データベースに接続されている場合は、TO RESTORE POINTのみを指定できます。例24-3では、リストア・ポイントとしてTESTDB103107を指定しています。

例24-3 バックアップベースの複製におけるアーカイブ・バックアップの使用

DUPLICATE DATABASE prod DBID 8675309 TO dupdb
TO RESTORE POINT TESTDB103107
SPFILE
NOFILENAMECHECK;

ターゲット接続を行うバックアップベースの複製の例

例24-1をバックアップベースに変更したとします。この場合、RMANは、TARGETとしてソース・データベースに接続します。例24-4では、ソース・データベースの1週間前のデータを表示するために、複製データベースをその時点までリカバリします。

例24-4 過去の特定の時点までのデータベースの複製(バックアップベース)

DUPLICATE TARGET DATABASE TO dupdb
SPFILE
NOFILENAMECHECK
UNTIL TIME 'SYSDATE-7';

例24-4の特徴は、次のとおりです。

- FROM ACTIVE DATABASE句が指定されていません。句を指定しないと、RMANでは、バックアップベースの複製が行われます。

- NOFILENAMECHECKオプションが指定されています。これは、複製データベース・ファイルでソース・データベース・ファイルと同じ名前を使用する場合にはこのオプションが必要となるためです。

ターゲット接続およびリカバリ・カタログ接続を行わないバックアップベースの複製の例

例24-5は例24-1を少し変更した例です。この例では、RMANは、ソース・データベースに対してTARGET接続を行わず、リカバリ・カタログに対してCATALOG接続を行いません。制御ファイルのバックアップまたはコピーを含む、2007年11月11日午後2:00までの複製に必要なすべてのバックアップおよびコピーは、/prod_backupsに格納されています。

例24-5 ターゲット接続およびリカバリ・カタログ接続を行わない場合のデータベースの複製(バックアップベース)

DUPLICATE DATABASE TO dupdb
UNTIL TIME "TO_DATE('11/01/2007 14:00:00', 'MM/DD/YYYY HH24:MI:SS')"
SPFILE
BACKUP LOCATION '/prod_backups'
NOFILENAMECHECK;

例24-5の特徴は、次のとおりです。

- データベース名が指定されていません。DATABASEキーワードを使用してデータベース名を指定しないことによって、DUPLICATEはデータベース名とDBIDをバックアップから取得します。BACKUP LOCATIONで複数のデータベースのバックアップが検出された場合、エラーが表示されます。

- BACKUP LOCATION句を使用して、複製のタイプがターゲット接続もリカバリ・カタログも使用しないバックアップベースであることを識別します。

- UNTIL TIMEオプションが指定されています。これは、BACKUP LOCATION句で許容される唯一のUNTIL副次句です。

- NOFILENAMECHECKオプションによるチェックが指定されています。これは、複製データベース・ファイルでソース・データベース・ファイルと同じ名前を使用する場合にはこのオプションが必要となるためです。

例24-6 過去の特定の時点までのデータベースの複製(バックアップベース)

DUPLICATE TARGET DATABASE TO dupdb
SPFILE
NOFILENAMECHECK
UNTIL TIME 'SYSDATE-7';

例24-6の特徴は、次のとおりです。

- FROM ACTIVE DATABASE句が指定されていません。この句を省略すると、RMANでは、バックアップベースの複製が行われます。

- NOFILENAMECHECKオプションによるチェックが指定されています。これは、複製データベース・ファイルでソース・データベース・ファイルと同じ名前を使用する場合にはこのオプションが必要となるためです。

失敗後のDUPLICATEの再実行

RMANは、以前に失敗したDUPLICATEコマンドの繰返しであるDUPLICATEコマンドを自動的に最適化します。繰返しのDUPLICATEコマンドは、過去に正常にコピーされたデータファイルを検知し、それらのデータファイルを再度コピーしません。これは、バックアップベース(ターゲット接続の有無を問わない)の複製かアクティブなデータベースの複製かにかかわらず、すべての複製の形式に適用されます。DUPLICATEコマンドの自動最適化は、非常に大きなデータベースの複製中に障害が発生した場合に特に有効です。

DUPLICATEの処理を再起動する手順

1. RMANを終了します。

2. SQL*Plusを起動し、SYSDBA権限またはSYSBACKUP権限で補助インスタンスに接続します。最初に使用したものと同じSPFILE指定またはPFILE指定を使用して、補助インスタンスをNOMOUNTモードで起動します。この指定を最初に省略した場合は、再度省略します。
この例は、/home/my_pfile.oraのパラメータを使用して補助インスタンスを開始します。

STARTUP FORCE PFILE=/home/my_pfile.ora

3. SQL*Plusを終了し、RMANを開始します。

4. 最初と同じデータベースに接続します。

5. DUPLICATEコマンドを繰り返します。

2番目のDUPLICATE操作は、次の処理を実行します。

- 最初のDUPLICATEコマンドによって正常に複製されたデータファイルを検索します。

- 再度複製される必要のない各データファイルに対して、次のようなメッセージを表示します。

RMAN-05560: Using previous duplicated file /oradata/new/data01.f for datafile 1 with checkpoint SCN of 1654665

- 欠落しているか、または不完全なデータファイルのみをリストアするため、コピーおよびリストアをすべてのデータファイルに対して再実行することを回避します。

失敗したDUPLICATE操作からRMANが自動的にリカバリしないようにする場合、NORESUMEキーワードを指定してこの機能を無効にします。DUPLICATEの最初の起動時にNORESUMEキーワードを使用すると、後続の新しいデータベース用のDUPLICATEコマンドがこの自動最適化を使用することを防止できます。

25 データベースの複製: 高度なトピック

この章では、第24章「データベースの複製」で説明していない高度なデータベースの複製について説明します。

この章の内容は次のとおりです。

- 複製データベース・ファイルの代替名の指定

- 共有ディスクを使用しないディスク・バックアップのアクセス可能化

- サーバー・パラメータ・ファイルが存在しない場合のデータベースの複製

- サーバー・パラメータ・ファイルが存在しない場合の補助インスタンスの起動

- ソース・データベース表領域のサブセットの複製

複製データベース・ファイルの代替名の指定

複製データベース・ファイルとソース・データベース・ファイルに同じ名前を使用する方法(推奨)については、「手順2: 複製ファイルの名前の指定方法の選択」を参照してください。それ以外の場合は、複製ファイルに対して、代替名を使用する方法を選択する必要があります。ソース・データベースと複製データベースでOracle Managed Files(OMF)またはOracle Automatic Storage Management (ASM)のいずれを使用するかによって、使用する方法は異なります。

ソース・データファイルにOMFを使用している場合、DB_FILE_NAME_CONVERTを使用して名前を変更することはできません。OMF管理データファイルの詳細およびオプションについては、「非ASMストレージの使用」を参照してください。

複製データベース・ファイルの非OMFまたは非ASM代替名の指定

この項では、次の条件に該当する場合に複製ファイルの名前を指定する方法について説明します。

ソース・ホストと補助ホストのいずれかが異なるディレクトリ構造を使用しているか、または同じ構造を使用しているが複製ファイルに異なる名前を使用する必要がある場合

表25-1に、各タイプのファイルに名前を指定するために使用可能な形式の概要を示します。

SET NEWNAMEを使用したファイル・システム・データファイルおよび一時ファイルの名前の指定

表25-1に示すように、複製データファイルに名前を指定する方法の1つとして、DUPLICATEコマンドを実行する前にSET NEWNAMEコマンドを使用する方法があります。次に、RMANでサポートされているコマンドを優先順位の高い順に示します。

1. SET NEWNAME FOR DATAFILEおよびSET NEWNAME FOR TEMPFILE

2. SET NEWNAME FOR TABLESPACE

3. SET NEWNAME FOR DATABASE

この優先順位に従って、SET NEWNAME FOR DATAFILEおよびSET NEWNAME FOR TEMPFILEを使用して名前が指定されていないファイルにはSET NEWNAME FOR TABLESPACEを使用して名前が指定され、SET NEWNAME FOR TABLESPACE、SET NEWNAME FOR DATAFILEまたはSET NEWNAME FOR TEMPFILEを使用して名前が指定されていないファイルにはSET NEWNAME FOR DATABASEを使用して名前が指定されます。

SET NEWNAME FOR DATAFILEを使用する場合は、/oradata1/system01.dbfのようなリテラルのフルパスを指定できます。ただし、SETをFOR DATABASEまたはFOR TABLESPACEとともに使用する場合は、表25-1に示す最初の3つの置換変数のうち、1つ以上を使用する必要があります(%Iと%Nはオプションです)。

表25-1 SET NEWNAMEの置換変数

変数

要約

%b

ディレクトリ・パス以外のファイル名を指定します。たとえば、データファイルの名前が/oradata/prod/financial.dbfである場合、%bはfinancial.dbfとなります。

%f

新しい名前を生成するデータファイルの絶対ファイル番号を指定します。たとえば、データファイル2を複製する場合は、%fによって値2が生成されます。

%I

DBIDを指定します

%N

表領域名を指定します

%U

data-D-%d_id-%I_TS-%N_FNO-%fという形式を指定します。

SET NEWNAMEを使用して新しいファイル名を指定する手順

1. 「データベースの複製の基本手順」の手順1から4を実行します。

2. RUNコマンド内で、DUPLICATEコマンドを発行する前にSET NEWNAMEコマンドを発行します。
例25-1に、データファイル1から5および一時ファイル1に新しい名前を指定するスクリプトを示します。データファイル6は、複製データベースから除外されるtools表領域内にあるため、このスクリプトでは新しい名前は設定されません。

例25-1 SET NEWNAME FOR DATAFILEを使用した複製

RUN
{
SET NEWNAME FOR DATAFILE 1 TO '/oradata1/system01.dbf';
SET NEWNAME FOR DATAFILE 2 TO '/oradata2/sysaux01.dbf';
SET NEWNAME FOR DATAFILE 3 TO '/oradata3/undotbs01.dbf';
SET NEWNAME FOR DATAFILE 4 TO '/oradata4/users01.dbf';
SET NEWNAME FOR DATAFILE 5 TO '/oradata5/users02.dbf';
SET NEWNAME FOR TEMPFILE 1 TO '/oradatat/temp01.dbf';
DUPLICATE TARGET DATABASE TO dupdb
SKIP TABLESPACE tools
LOGFILE
GROUP 1 ('/duplogs/redo01a.log',
'/duplogs/redo01b.log') SIZE 4M REUSE,
GROUP 2 ('/duplogs/redo02a.log',
'/duplogs/redo02b.log') SIZE 4M REUSE;
}

例25-2は、例25-1を少し変更した例です。この例では、単一のSET NEWNAMEコマンドを使用して、users表領域内にあるすべてのデータファイルの名前を指定します。この例が完了すると、users表領域のファイル名は/oradata4/users01.dbfおよび/oradata5/users02.dbfに設定されます。

例25-2 SET NEWNAME FOR DATAFILEおよびSET NEWNAME FOR TABLESPACEを使用した複製

RUN
{
SET NEWNAME FOR TABLESPACE users TO '/oradata%f/%b';
SET NEWNAME FOR DATAFILE 1 TO '/oradata1/system01.dbf';
SET NEWNAME FOR DATAFILE 2 TO '/oradata2/sysaux01.dbf';
SET NEWNAME FOR DATAFILE 3 TO '/oradata3/undotbs01.dbf';
SET NEWNAME FOR TEMPFILE 1 TO '/oradatat/temp01.dbf';
DUPLICATE TARGET DATABASE TO dupdb
SKIP TABLESPACE tools
LOGFILE
GROUP 1 ('/duplogs/redo01a.log',
'/duplogs/redo01b.log') SIZE 4M REUSE,
GROUP 2 ('/duplogs/redo02a.log',
'/duplogs/redo02b.log') SIZE 4M REUSE;
}

例25-3は、例25-1を少し変更した例です。この例では、単一のSETコマンドを使用して、データベース内のすべてのデータファイルの名前を指定します。

例25-3 SET NEWNAME FOR DATABASEを使用した複製

RUN
{
SET NEWNAME FOR DATABASE TO '/oradata/%U';
DUPLICATE TARGET DATABASE TO dupdb
SKIP TABLESPACE tools
LOGFILE
GROUP 1 ('/duplogs/redo01a.log',
'/duplogs/redo01b.log') SIZE 4M REUSE,
GROUP 2 ('/duplogs/redo02a.log',
'/duplogs/redo02b.log') SIZE 4M REUSE;
}

次の状況を想定しています。

- DBIDは87650928

- データベース名はPROD

表25-2に、例25-3の結果を示します。

表25-2 例25-3 SET NEWNAME DATABASEコマンドの結果

SET NEWNAME DATABASEの実行前

表領域名

データファイルのファイル番号

SET NEWNAME DATABASE TO '/oradata/%U';の実行後

.../system01.dbf

SYSTEM

1

/oradata/data-D-PROD_id-87650928_TS-SYSTEM_FNO-1

.../sysaux01.dbf

SYSAUX

2

/oradata/data-D-PROD_id-87650928_TS-SYSAUX_FNO-2

.../undotbs01.dbf

UNDOTS

3

/oradata/data-D-PROD_id-87650928_TS-UNDOTS_FNO-3

.../users01.dbf

USERS

4

/oradata/data-D-PROD_id-87650928_TS-USERS_FNO-4

.../users02.dbf

USERS

5

/oradata/data-D-PROD_id-87650928_TS-USERS_FNO-5

.../temp01.dbf

TEMP

1

/oradata/data-D-PROD_id-87650928_TS-TEMP_FNO-1

関連項目:
SET NEWNAMEで使用可能な置換変数の詳細は、『Oracle Databaseバックアップおよびリカバリ・リファレンス』を参照してください。

CONFIGURE AUXNAMEを使用したファイル・システム・データファイルおよびOMF/ASMターゲット・データファイルの名前の指定

CONFIGURE AUXNAMEコマンドは、SET NEWNAMEコマンドの代替となるコマンドです。一度このコマンドを使用して補助ファイル名を構成すると、構成した設定がその後のDUPLICATEコマンドで再利用される点が異なります。一方、SET NEWNAMEコマンドは、DUPLICATEコマンドを実行するたびに再発行する必要があります。

CONFIGURE AUXNAMEを使用して複製データファイル名を指定する手順

1. 複製データベースで名前を指定するファイルごとに、CONFIGURE AUXNAMEコマンドを発行します。
たとえば、データファイル1から5の名前を指定するには、RMANプロンプトで次のコマンドを入力します。

CONFIGURE AUXNAME FOR DATAFILE 1 TO '/oradata1/system01.dbf';
CONFIGURE AUXNAME FOR DATAFILE 2 TO '/oradata2/sysaux01.dbf';
CONFIGURE AUXNAME FOR DATAFILE 3 TO '/oradata3/undotbs01.dbf';
CONFIGURE AUXNAME FOR DATAFILE 4 TO '/oradata4/users01.dbf';
CONFIGURE AUXNAME FOR DATAFILE 5 TO '/oradata5/users02.dbf';

2. DUPLICATEコマンドを発行します。
たとえば、RMANプロンプトで次のコマンドを入力します。

SET NEWNAME FOR TEMPFILE 1 TO '/oradatat/temp01.dbf';
DUPLICATE TARGET DATABASE
TO dupdb
SKIP TABLESPACE tools
LOGFILE
GROUP 1 ('/duplogs/redo01a.log',
'/duplogs/redo01b.log') SIZE 4M REUSE,
GROUP 2 ('/duplogs/redo02a.log',
'/duplogs/redo02b.log') SIZE 4M REUSE;

RMANでは、CONFIGURE AUXNAME設定を使用してデータファイル1から5の名前を指定します。

関連項目:
CONFIGURE AUXNAMEの使用方法の詳細は、『Oracle Databaseバックアップおよびリカバリ・リファレンス』を参照してください。

複製データベース・ファイルに対するOMFまたはASM代替名の指定

この項では、複製データベースの一部またはすべてのファイルでOMFまたはASMが使用されている場合に複製データベースを作成するための要件について説明します。

関連項目:
ASMおよびOMFの概要は、『Oracle Databaseストレージ管理者ガイド』を参照してください。

OMF初期化パラメータの設定および制限事項

Oracle Managed Filesを使用する複製データベースを作成する場合は、補助インスタンスで初期化パラメータを設定する必要があります。DUPLICATEのSPFILE句を使用してファイルの名前を指定する場合は、SPFILE句で初期化パラメータを設定できます。表25-3に、関連するパラメータおよび推奨設定を示します。表25-4に、制限事項および設定するべきでない初期化パラメータを示します。

関連項目:
これらのパラメータの詳細は、『Oracle Databaseリファレンス』を参照してください。

表25-3 Oracle Managed Filesの初期化パラメータ

初期化パラメータ

用途

推奨事項

DB_CREATE_FILE_DEST

Oracle管理データファイルのデフォルトの場所を指定します。この場所は、どのDB_CREATE_ONLINE_LOG_DEST初期化パラメータも指定されていない場合、Oracle管理の制御ファイルおよびオンライン・ログのデフォルトの場所でもあります。

このパラメータをOracle Managed Filesの場所に設定します。他の場所が指定されてないデータベース・ファイルがDUPLICATEによってDB_CREATE_FILE_DESTで作成されます。「SET NEWNAMEを使用したOMFまたはASMファイルの作成」で説明するように、SET NEWNAMEを使用して特定のファイルのデフォルト値を上書きできます。

DB_CREATE_ONLINE_LOG_DEST_n

Oracle管理の制御ファイルおよびオンラインREDOログのデフォルトの場所を指定します。複数のパラメータが設定されている場合は、それぞれの場所に制御ファイルおよびオンラインREDOログが1つずつ作成されます。

複数の場所の制御ファイルおよびオンラインREDOログ・ファイルを多重化する場合にのみ、これらのパラメータを設定します(_1、_2など)。

DB_RECOVERY_FILE_DEST

高速リカバリ領域のデフォルトの場所を指定します。高速リカバリ領域には、現行の制御ファイルおよびオンラインREDOログ・ファイルの多重コピーが含まれています。

リカバリ領域に制御ファイルおよびオンラインREDOログ・ファイルの多重コピーが必要な場合は、このパラメータを設定します。

表25-4 Oracle Managed Filesの初期化パラメータの制限事項

初期化パラメータ

用途

制限事項

CONTROL_FILES

1つ以上の制御ファイル名をカンマで区切って指定します。

OMF形式でデータベース制御ファイルを複製する場合は、このパラメータを設定しないでください。制御ファイルにOMF形式を使用する場合は、複製データベースでサーバー・パラメータ・ファイルを使用することをお薦めします。

DB_FILE_NAME_CONVERT

プライマリ・データベース上の新しいデータファイルのファイル名を複製データベース上のファイル名に変換します。

このパラメータを設定しないでください。このパラメータを省略することによって、データベースは複製データファイルにOracle Managed Filesの有効な名前を生成できます。

LOG_FILE_NAME_CONVERT

プライマリ・データベース上の新しいログ・ファイルのファイル名をスタンバイ・データベース上のログ・ファイルのファイル名に変換します。

このパラメータを設定しないでください。このパラメータを省略することによって、データベースはOracle管理オンラインREDOログ・ファイルの有効な名前を生成できます。

複製データベースのオンラインREDOログ・ファイルをOracle管理ストレージに格納するには、DB_CREATE_FILE_DEST、DB_RECOVERY_FILE_DESTまたはDB_CREATE_ONLINE_LOG_DEST_n初期化パラメータを使用して、オンライン・ログのOracle管理の場所を指定します。

ASMの初期化パラメータの設定

ASMの場所に複製データベースを作成する手順は、「OMF初期化パラメータの設定および制限事項」に示す手順と同様です。ファイルが作成される場所を制御する初期化パラメータを特定し、これらのパラメータをASMディスク・グループに対して設定する必要がある点が異なります。たとえば、DB_CREATE_FILE_DEST、DB_CREATE_ONLINE_DEST_nおよびCONTROL_FILESを+DISK1に対して設定します。

ファイル・システムからASMへのデータベースの複製の例

この例では、アクティブなデータベースの複製を使用します。ソース・データベースでサーバー・パラメータ・ファイルが使用されている(またはバックアップが使用可能である)場合は、宛先ホストに一時初期化パラメータ・ファイルを作成し、DB_NAMEパラメータのみを設定できます。

ソース・データベースprodはhost1上にあり、データファイルは非ASMファイル・システムに保存されていると想定しています。prodの制御ファイルは、/oracle/oradata/prod/に存在します。ソース・データベースを複製し、リモート・ホストhost2上にdupdbデータベースを作成します。ASMディスク・グループ+DISK1に複製データベース・ファイルを保存します。

RMANをターゲット・データベース、複製データベースおよびリカバリ・カタログ・データベースに接続してから、例25-4に示すRMANスクリプトを実行してデータベースを複製します。

例25-4 ファイル・システムからASMへの複製(アクティブ)

DUPLICATE TARGET DATABASE TO dupdb
FROM ACTIVE DATABASE
SPFILE
PARAMETER_VALUE_CONVERT '/oracle/oradata/prod/', '+DISK1'
SET DB_CREATE_FILE_DEST +DISK1;

DUPLICATEコマンドが完了すると、複製データベースはデータファイル、オンラインREDOログ・ファイルおよび制御ファイルとともに、ASMディスク・グループ+DISK1に作成されます。

ASMからASMへのデータベースの複製の例

この例では、アクティブなデータベースの複製を使用します。ソース・データベースでサーバー・パラメータ・ファイルが使用されている(またはバックアップが使用可能である)場合は、宛先ホストに一時初期化パラメータ・ファイルを作成し、DB_NAMEパラメータのみを設定できます。

ソース・データベースprodはhost1上にあり、データファイルはASMディスク・グループ+DISK1に保存されていると想定しています。ターゲット・データベースを複製し、リモート・ホストhost2上にdupdbデータベースを作成します。ASMにdupdbのデータファイルを格納します。具体的には、ディスク・グループ+DISK2にデータファイルおよび制御ファイルを保存します。

DUPLICATEコマンドにPARAMETER_VALUE_CONVERTを設定し、すべてのディレクトリの場所を+DISK1から+DISK2に変換します。+DISK2の新しいファイル名は、ASMによって生成され、ディスク・グループ+DISK1の元のファイル名とは一致しません。

ターゲット・データベース、複製データベースおよびカタログ・データベースに接続してから、例25-5に示すRMANスクリプトを実行してデータベースを複製します。

例25-5 ASMからASMへの複製(アクティブ)

DUPLICATE TARGET DATABASE
TO dupdb
FROM ACTIVE DATABASE
SPFILE PARAMETER_VALUE_CONVERT '+DISK1','+DISK2'
SET DB_RECOVERY_FILE_DEST_SIZE='750G';

DUPLICATEコマンドが完了すると、データファイル、オンラインREDOログおよび制御ファイルとともに複製データベースがより大きなASMディスク・グループ+DISK2に作成されます。

SET NEWNAMEを使用したOMFまたはASMファイルの作成

Oracle管理データファイルの名前を指定するには、「SET NEWNAMEを使用したファイル・システム・データファイルおよび一時ファイルの名前の指定」で説明したSET NEWNAMEコマンドを使用できますが、TO "filename"のかわりにTO NEWを指定します。RMANによって、指定したデータファイルまたは一時ファイルが、DB_CREATE_FILE_DESTを使用して指定した場所にOracle Managed Filesの名前で作成されます。

SET NEWNAMEを使用してOracle Managed Filesの名前を指定する手順

1. 補助インスタンスのDB_CREATE_FILE_DEST初期化パラメータを任意の場所に設定します。

2. RUNブロックにDUPLICATEコマンドを含め、Oracle Managed Filesに対してSET NEWNAMEをTO NEWオプションとともに使用します。
例25-6に、データファイル1から5のリテラル名を指定するスクリプトを示します。ソース・データベース内のOracle Managed Filesは、users表領域内のデータファイルのみです。このため、これらのファイルのSET NEWNAMEコマンドにはTO NEWを指定します。

例25-6 SET NEWNAME FOR DATAFILEおよびSET NEWNAME FOR TABLESPACEを使用した複製

RUN
{
SET NEWNAME FOR TABLESPACE users TO NEW;
SET NEWNAME FOR DATAFILE 3 TO NEW;
SET NEWNAME FOR DATAFILE 1 TO '/oradata1/system01.dbf';
SET NEWNAME FOR DATAFILE 2 TO '/oradata2/sysaux01.dbf';
SET NEWNAME FOR TEMPFILE 1 TO '/oradatat/temp01';
DUPLICATE TARGET DATABASE TO dupdb
SKIP TABLESPACE tools
LOGFILE
GROUP 1 ('/duplogs/redo01a.log',
'/duplogs/redo01b.log') SIZE 4M REUSE,
GROUP 2 ('/duplogs/redo02a.log',
'/duplogs/redo02b.log') SIZE 4M REUSE;
}

例25-7に示すように、SET NEWNAMEを使用して、指定したASMディスク・グループに個々のデータファイル、一時ファイルまたは表領域を格納することもできます。

例25-7 SET NEWNAMEを使用したASMディスク・グループでのファイルの作成

RUN
{
SET NEWNAME FOR DATAFILE 1 TO "+DGROUP1";
SET NEWNAME FOR DATAFILE 2 TO "+DGROUP2";
.
.
.
DUPLICATE TARGET DATABASE
TO dupdb
FROM ACTIVE DATABASE
SPFILE SET DB_CREATE_FILE_DEST +DGROUP3;
}

関連項目:
SET NEWNAMEの使用方法の詳細は、『Oracle Databaseバックアップおよびリカバリ・リファレンス』を参照してください。

DB_FILE_NAME_CONVERTを使用した非OMFまたはASMデータファイルの名前の生成

名前を生成するには、SET NEWNAMEまたはCONFIGURE AUXNAMEコマンドを使用する以外にもう1つ、DB_FILE_NAME_CONVERTを使用してターゲット・ファイル名を変更する方法があります。たとえば、ターゲット・ファイル名を/oracle/から/dup/oracle/に変更できます。DB_FILE_NAME_CONVERTを使用すると、複数の変換ファイル名のペアを指定できます。データファイルや一時ファイルの名前を作成することもできます。

DB_FILE_NAME_CONVERTは、DUPLICATEコマンドで指定するか、または補助インスタンスの初期化パラメータで設定できます。

DB_FILE_NAME_CONVERTの制限事項

DUPLICATEコマンドのDB_FILE_NAME_CONVERT句を使用して、ソース・データベース・インスタンスではOracle Managed Files(OMF)形式である、複製インスタンスにあるファイル用の新しい名前の生成を制御することはできません。この制限事項の詳細は、『Oracle Databaseバックアップおよびリカバリ・リファレンス』を参照してください。

LOG_FILE_NAME_CONVERTを使用した非OMFまたはASMログ・ファイルの名前の生成

LOG_FILE句が省略されており、Oracle Managed Filesの初期化パラメータDB_CREATE_FILE_DEST、DB_CREATE_ONLINE_DEST_nまたはDB_RECOVERY_FILE_DESTのいずれも指定されていない場合、LOG_FILE_NAME_CONVERTはターゲット・ファイル名を変更できます。これは、DB_FILE_NAME_CONVERTとほぼ同様に機能し、ターゲット・ファイル名をlog_*からduplog_*に変更できます。このパラメータを使用すると、複数の変換ファイル名のペアを指定できます。

LOG_FILE_NAME_CONVERTを指定すると、RMANは、オンラインREDOログの作成時にREUSEパラメータを使用します。オンラインREDOログ・ファイルが名前の付けられた場所にすでに存在し、適切なサイズである場合、そのファイルは複製に再利用されます。

LOG_FILE_NAME_CONVERTの制限事項

- Oracle Managed Filesの初期化パラメータを設定する場合、LOG_FILE_NAME_CONVERTを指定しないでください。

- LOG_FILE_NAME_CONVERTは、DUPLICATE句としては指定できません。補助インスタンスの初期化パラメータでのみ指定できます。

- LOG_FILE_NAME_CONVERT初期化パラメータを使用して、ソース・データベース・インスタンスではOracle Managed Files(OMF)形式である、複製インスタンスにあるファイル用の新しい名前の生成を制御することはできません。

共有ディスクを使用しないディスク・バックアップのアクセス可能化

「手順3: 複製インスタンスからバックアップへのアクセス可能化」では、バックアップを補助インスタンスで使用できるようにするため、共有ディスクを使用する方法を推奨しています。ターゲットまたはリカバリ・カタログ接続なしにBACKUP LOCATIONオプションがDUPLICATEコマンドに使用されていないかぎり、NFSまたは共有ディスクを使用できない場合、バックアップを格納するパスはソース・ホストおよび転送先ホストの両方に存在する必要があります。

srchostおよびdsthostという2つのホストがあるとします。srchost上のデータベースは、srcdbです。srcdbのRMANバックアップは、ホストsrchost上の/dsk1/bkp内に存在します。ディレクトリ/dsk1/bkpはすでに転送先ホストで使用されているため、バックアップは転送先ホスト上の/dsk2/dupに格納します。

バックアップをソース・ホストから宛先ホストに転送する手順

1. バックアップを格納する転送先ホスト上にあるディレクトリと同じ名前のディレクトリをソース・ホスト上に新しく作成します。
たとえば、RMANバックアップを宛先ホストの/dsk2/dupに格納する場合、ソース・ホスト上に/dsk2/dupを作成します。

2. ソース・ホスト上で、前の手順で作成したディレクトリにバックアップをコピーして、バックアップをカタログに追加します。次のいずれかの方法を使用できます。

- RMANをTARGETとしてソース・データベースに接続し、「RMANバックアップのバックアップ」で説明されているBACKUPコマンドを使用して、バックアップのバックアップを作成します。たとえば、BACKUP COPY OF DATABASEコマンドを使用して、ソース・ホストの/dsk1/bkpにあるバックアップをソース・ホストの/dsk2/dupにコピーします。この場合、RMANは、新しい場所のバックアップを自動的にカタログに追加します。

- オペレーティング・システム・ユーティリティを使用して、ソース・ホストの/dsk1/bkpにあるバックアップを、ソース・ホストの/dsk2/dupにコピーします。後で、RMANをTARGETとしてソース・データベースに接続し、CATALOGコマンドを使用して、手動で転送したバックアップの場所で、ソースの制御ファイルを更新します。

3. ソース・ホスト上の新しいディレクトリから宛先ホスト上の同じ名前のディレクトリに、バックアップを手動で転送します。
たとえば、FTPを使用して、ソース・ホストの/dsk2/dupにあるバックアップを、宛先ホストの/dsk2/dupに転送します。

補助チャネルでは、宛先ホストの/dsk2/dupでバックアップを検索してリストアできます。

サーバー・パラメータ・ファイルが存在しない場合のデータベースの複製

「手順5: 初期化パラメータ・ファイルの作成と補助インスタンスの起動」の手順では、DUPLICATEコマンドのSPFILE句を使用する場合を想定しています。ソース・データベースがサーバー・パラメータ・ファイルを使用していない場合は、補助インスタンスに必要なすべてのパラメータをテキストベースの初期化パラメータ・ファイルで設定する必要があります。

表25-5に、指定可能な初期化パラメータのサブセットを示します。これらのパラメータの詳細は、『Oracle Databaseリファレンス』を参照してください。複製ファイルに名前を指定するためのオプションについては、表25-1を参照してください。

表25-5 補助インスタンスの初期化パラメータ

初期化パラメータ

値

ステータス

DB_NAME

DUPLICATEコマンドで使用する名前と同じ名前。DUPLICATEを使用してスタンバイ・データベースを作成する場合、プライマリ・データベースと同じ名前にする必要があります。

複製データベースのDB_NAME設定は、そのOracleホームのデータベース間で一意である必要があります。

必須

CONTROL_FILES

制御ファイルの場所

必須

DB_BLOCK_SIZE

複製データベースのブロック・サイズ。このブロック・サイズは、ソース・データベースのブロック・サイズと一致している必要があります。ソース・データベースのパラメータ・ファイルにDB_BLOCK_SIZE初期化パラメータの値が含まれている場合、補助インスタンスに同じ値を指定する必要があります。ただし、ソース・データベースの初期化パラメータ・ファイルにDB_BLOCK_SIZEが指定されていない場合は、補助インスタンスにDB_BLOCK_SIZEは指定しないでください。

必須(ソース・データベースでこの初期化パラメータが設定されている場合)

DB_FILE_NAME_CONVERT

データファイルおよび一時ファイルの名前を変換する文字列のペア。DUPLICATEコマンド自体にDB_FILE_NAME_CONVERTを指定することもできます。「DB_FILE_NAME_CONVERTを使用した非OMFまたはASMデータファイルの名前の生成」を参照してください。

オプション

LOG_FILE_NAME_CONVERT

オンラインREDOログ・ファイルの名前を指定する文字列のペア。「LOG_FILE_NAME_CONVERTを使用した非OMFまたはASMログ・ファイルの名前の生成」を参照してください。

オプション

DB_CREATE_FILE_DEST

Oracle管理データファイルの場所

オプション

DB_CREATE_ONLINE_LOG_DEST_n

Oracle管理オンラインREDOログ・ファイルの場所

オプション

DB_RECOVERY_FILE_DEST

高速リカバリ領域の場所

オプション

Oracle Real Application Cluster(Oracle RAC)パラメータ:

- <INSTANCESIDn>.INSTANCE_NAME

- <INSTANCESIDn>.INSTANCE_NUMBER

- <INSTANCESIDn>.THREAD

- <INSTANCESIDn>.UNDO_TABLESPACE

- <INSTANCESIDn>.LOCAL_LISTENER

Oracle RACデータベースのインスタンスごとにこれらのパラメータを設定します。

必須(Oracle RAC構成の場合)

SPFILE句を使用しない場合に初期化パラメータ・ファイルを作成する手順

1. オペレーティング・システム・ユーティリティを使用して、ソース・データベースの初期化パラメータ・ファイルのコピーをオペレーティング・システム固有のデフォルトの場所に作成します。

2. コピーした初期化パラメータ・ファイルで、DB_NAMEを複製データベースの名前に手動で変更します。DUPLICATEを使用してスタンバイ・データベースを作成する場合、プライマリ・データベースと同じ名前にする必要があります。

3. 必要に応じて、Oracle Netを介してSYSDBAとして接続するためのパラメータも含めて、その他の初期化パラメータを変更します。データベースの複製先ホスト上ですべてのパスがアクセス可能であることを確認する必要があります。
例25-8に、サンプルの初期化パラメータ・ファイルを示します。

例25-8 補助インスタンス用のサンプル初期化パラメータ・ファイル

DB_NAME=dupdb
CONTROL_FILES=(/dup/oracle/oradata/prod/control01.ctl,
/dup/oracle/oradata/prod/control02.ctl)
DB_FILE_NAME_CONVERT=(/oracle/oradata/prod/,/dup/oracle/oradata/prod/)
LOG_FILE_NAME_CONVERT=(/oracle/oradata/prod/redo,/dup/oracle/oradata/prod/redo)

サーバー・パラメータ・ファイルが存在しない場合の補助インスタンスの起動

「手順5: 初期化パラメータ・ファイルの作成と補助インスタンスの起動」では、ソース・データベース・インスタンスがサーバー・パラメータ・ファイルを使用する場合を想定しています。この例では、ソース・データベースが現時点でサーバー・パラメータ・ファイルを使用していないか、またはRMANによってバックアップ・サーバー・パラメータ・ファイルをリストアできないと想定しています。この場合は、テキストベースの初期化パラメータ・ファイルを使用して、補助インスタンスを起動する必要があります。

データベース複製の準備として補助インスタンスを起動する手順

1. テキストベースの初期化パラメータ・ファイルを、SQL*Plusクライアントを含むホストのデフォルトの場所にコピーします。

2. SQL*Plusを起動し、SYSOPER権限を使用して補助インスタンスに接続します。

3. テキストベースの初期化パラメータ・ファイルを使用して、補助インスタンスをNOMOUNTモードで起動します。

SQL> STARTUP NOMOUNT

4. 補助インスタンス用のテキストベースの初期化パラメータ・ファイルを、複製の実行に使用されるRMANクライアントと同じホストにコピーします。DUPLICATEコマンドのPFILE句で、このテキストベースの初期化パラメータ・ファイルの場所を指定する必要があります。

ソース・データベース表領域のサブセットの複製

常に、データベースのすべての表領域を複製する必要があるわけではありません。たとえば、ソース・データベースから表領域のサブセットのみを必要とするレポートを生成する場合があります。

注意:
ターゲット接続なしに、またはターゲットおよびリカバリ・カタログ接続なしにバックアップベースの複製で表領域を除外する場合、RMANには特別な前提条件があります。詳細は、『Oracle Databaseバックアップおよびリカバリ・リファレンス』のDUPLICATEエントリの前提条件に関する項を参照してください。

表25-6に、複製データベースの表領域のサブセットを指定するためのDUPLICATEコマンドのオプションを示します。

表25-6 複製データベースの表領域のサブセットを指定するためのオプション

DUPLICATEのオプション

説明

SKIP READONLY

複製データベースから読取り専用表領域のデータファイルを除外します。

SKIP TABLESPACE 'tablespace_name ', ...

指定した表領域を複製データベースから除外します。SYSTEM表領域、SYSAUX表領域、SYSオブジェクトを含む表領域、UNDO表領域、UNDOセグメントを含む表領域、マテリアライズド・ビューを使用する表領域、または複製された表領域が自己完結型になっていない表領域は除外できません。

TABLESPACE 'tablespace_name ', ...

SYSTEM表領域、SYSAUX表領域およびUNDO表領域を自動的に含みます。含まれる表領域は自己完結型である必要があります。また、結果としてスキップされる表領域には、SYSオブジェクトまたはマテリアライズド・ビューが含まれない必要があります。

複製データベースの表領域のサブセットを指定するには、次の手順を実行します。

1. 「データベースの複製の基本手順」の手順1から4が完了していることを確認します。

2. 表25-6に示すオプションを1つ以上指定して、DUPLICATEコマンドを実行します。

コピーされる表領域に影響を与えるその他の要因には、OFFLINE NORMALオプションが含まれます。複製の前にOFFLINE NORMALオプションによって表領域がオフラインにされた場合、RMANは関連するデータファイルを複製せず、その複製データベースの表領域に対してDROP TABLESPACE文を発行します。したがって、これらの表領域を除外するオプションを指定する必要はありません。

注意:
RMANは、NORMAL以外のいずれのオプションを使用してオフラインにされた表領域も複製します(SKIP TABLESPACEオプションで名前が指定されている場合を除く)。自動的にスキップされるのは、OFFLINE NORMAL表領域のみです。バックアップベースの複製を使用する場合は、オンライン表領域のときと同様に、RMANにこれらの表領域の有効なバックアップが必要です。

指定した表領域の除外

例25-9に、読取り専用表領域をスキップする方法を示します。

例25-9 読取り専用表領域の除外

DUPLICATE TARGET DATABASE TO dupdb
FROM ACTIVE DATABASE
SKIP READONLY
NOFILENAMECHECK;

例25-10に、toolsという名前の表領域をスキップする方法を示します。

例25-10 指定した表領域の除外

DUPLICATE TARGET DATABASE
TO dupdb
FROM ACTIVE DATABASE
SKIP TABLESPACE tools
NOFILENAMECHECK;

指定した表領域の追加

TABLESPACEオプションを使用すると、指定したデータベースに含める表領域を指定できます。複製データベースから除外する表領域を指定するSKIP TABLESPACEオプションとは異なり、このオプションを使用すると、含める表領域が指定された後、残りの表領域はスキップされます。複製された表領域のサブセットは、自己完結型である必要があります。結果として、スキップされた表領域のセットには、UNDOセグメントやマテリアライズド・ビューは含まれていない必要があります。

例25-11は例24-1を少し変更した例です。自己完結型であると想定されるusers表領域が含まれ、SYSTEM表領域、SYSAUX表領域およびUNDOセグメントを含む表領域以外の、すべての表領域が除外される点が異なります。

例25-11 指定した表領域の追加

DUPLICATE TARGET DATABASE
TO dupdb
FROM ACTIVE DATABASE
TABLESPACE users
NOFILENAMECHECK;

リカバリ・カタログ接続ではなく、ターゲット接続を使用してバックアップベースの複製を実行するとします。また、複製の対象として表領域のサブセットを指定します。この場合、ターゲット・データベースが開いていないと、RMANではUNDOセグメントを含む表領域の名前を取得できません。したがって、例25-12に示すように、対象の表領域に対してUNDO TABLESPACEオプションを指定する必要があります。

例25-12 指定した表領域の追加

DUPLICATE TARGET DATABASE TO dupdb
TABLESPACE users
UNDO TABLESPACE undotbs
NOFILENAMECHECK;

26 トランスポータブル表領域セットの作成

この章では、RMANを使用し、バックアップをリストアしてトランスポータブル表領域セットを作成する方法について説明します。ここでは、『Oracle Database管理者ガイド』で説明するトランスポータブル表領域の手順に習熟していることを前提としています。この章で説明する手順は、トランスポータブル表領域セットの生成に使用する代替方法です。この章の内容は、次のとおりです。

- トランスポータブル表領域セットの作成の概要

- 補助インスタンスの初期化パラメータのカスタマイズ

- トランスポータブル表領域セットの作成

- トランスポータブル表領域セットの作成のトラブルシューティング

- トランスポータブル表領域セットの使用例

トランスポータブル表領域セットの作成の概要

この項では、RMANのバックアップからトランスポータブル表領域セットを作成する場合の基本的な概念およびタスクについて説明します。

トランスポータブル表領域セットの作成の目的

トランスポータブル表領域セットには、表領域セットのデータファイル、および表領域セットの構造メタデータを含むエクスポート・ファイルが含まれています。エクスポート・ファイルは、データ・ポンプ・エクスポートによって生成されます。

トランスポータブル表領域セットを使用する例としては、表領域リポジトリの作成があげられます。たとえば、四半期レポートに使用する複数の表領域を含むデータベースがある場合、これらの表領域のトランスポータブル・セットを表領域リポジトリのストレージに作成できます。その後、表領域のバージョンをリポジトリから要求して別のデータベースに組み込み、レポートの生成に使用することができます。

トランスポータブル表領域を使用するもう1つの例としては、Oracle Streams環境での使用があげられます。Oracle Streamsを使用して、宛先データベースとソース・データベースを継続して同期化するための準備をする場合には、Oracle Streamsのインスタンス化を実行する必要があります。Oracle Streamsを使用して後続の更新をソース・データベースから宛先データベースに移動する前に、2つのデータベースが同期化されたことがわかっている時点のSCNまで宛先データベースを戻す必要があります。バックアップからのトランスポータブル表領域セットは、Oracle Streamsのインスタンス化の一部として作成できます。

RMANのTRANSPORT TABLESPACEコマンドの主なメリットは、トランスポートする表領域のアクティブなデータファイルにアクセスする必要がないことです。これに対して、『Oracle Database管理者ガイド』で説明されているトランスポータブル表領域の方法では、トランスポート時に、トランスポートする表領域を読取り専用でオープンする必要があります。したがって、バックアップからトランスポートすると、トランスポート中、トランスポートする表領域を書込み用にオープンしたままにできるため、特に大規模な表領域の場合にデータベースの可用性が向上します。また、現行のデータベース・アクティビティによっては、表領域を読取り専用モードにする操作に時間が長くかかる場合もあります。

RMANのTRANSPORT TABLESPACEコマンドを使用すると、リカバリ期間内に目標時点、SCNまたはリストア・ポイントを指定し、表領域データを指定した時点の状態でトランスポートすることもできます(「指定した時点またはSCNでのトランスポータブル表領域セットの作成」を参照)。たとえば、バックアップの保存方針で1週間のリカバリ期間を保証しており、月の最終日のデータベースの内容に基づいてトランスポータブル表領域を作成する場合、RMANは、翌月の第1週目の任意の時点にそのタスクを実行できます。

関連項目:

- TRANSPORT TABLESPACEコマンドの詳細は、『Oracle Databaseバックアップおよびリカバリ・リファレンス』を参照してください。

- RMANおよび表領域リポジトリの詳細は、『Oracle Streamsレプリケーション管理者ガイド』を参照してください。

- RMANおよびOracle Streamsのインスタンス化の詳細は、『Oracle Streamsレプリケーション管理者ガイド』を参照してください。

トランスポータブル表領域セットの基本的な概念

RMANをソース・データベースにTARGETとして接続してから、TRANSPORT TABLESPACEコマンドを実行して、トランスポータブル表領域セットを作成します。ソース・データベースには、トランスポートされる表領域が含まれています。

TRANSPORT TABLESPACE操作の目標時点までリカバリできる必要なすべての表領域のバックアップおよびアーカイブREDOログ・ファイルがRMANで使用可能になっている必要があります。図26-1に、トランスポータブル表領域の基本プロセスを示します。

図26-1 バックアップからのRMANトランスポータブル表領域: アーキテクチャ

図26-1に示されているプロセスは、次のフェーズで実行されます。

1. RMANによって、補助インスタンスが起動されます。
RMANによって、表領域のリストアおよびリカバリを実行するために、ソース・データベースと同じホスト上に補助インスタンスが作成されます。また、補助インスタンスの初期化パラメータ・ファイルが自動的に作成され、インスタンスがNOMOUNTモードで起動されます。

2. RMANによって、補助インスタンスの制御ファイルとして機能するソース・データベースの制御ファイルのバックアップがリストアされ、その制御ファイルがマウントされます。

3. RMANによって、ソース・データベースのバックアップから、補助セットおよびトランスポータブル・セットのデータファイルがリストアされます。
補助セットには、表領域のトランスポートに必要なデータファイルおよびその他のファイルが含まれていますが、それらのファイル自体はトランスポータブル表領域セットの一部ではありません。通常、補助セットには、SYSTEM表領域、SYSAUX表領域、一時ファイル、およびロールバック・セグメントまたはUNDOセグメントを含むデータファイルが含まれています。補助インスタンスには、それ自体の制御ファイル、パラメータ・ファイル、オンライン・ログなどの他のファイルが関連付けられますが、これらのファイルは補助セットの一部ではありません。

RMANによって、選択した補助の宛先に補助データファイルが格納されます。補助の宛先は、トランスポート実行中に、補助インスタンスのパラメータ・ファイル、データファイル(トランスポータブル・セットのデータファイル以外)、制御ファイル、オンライン・ログなどの補助セット・ファイルをRMANによって格納できるディスク上の場所です。トランスポートが正常に実行されると、これらのファイルはRMANによって削除されます。

RMANによって、表領域の格納場所にトランスポータブル・セット・ファイルが格納されます。表領域の格納場所は、表領域のトランスポートコマンドの完了時に、デフォルトでデータファイルのコピーおよび他の出力が格納されるディスク上の場所です。

4. RMANは、補助インスタンスでデータベースのPoint-in-Timeリカバリ(DBPITR)を実行します。
このリカバリによって、補助セットおよびトランスポータブル・セットのデータファイルの内容が、TRANSPORT TABLESPACEコマンドに対して指定された目標時点の状態に更新されます。目標時点が指定されていない場合、RMANでは、すべての使用可能なREDOログを使用してリカバリが行われます。必要に応じて、バックアップからアーカイブREDOログが補助の宛先(またはその他の場所)にリストアされ、適用後に削除されます。

5. RMANによって、補助データベースがRESETLOGSオプションを使用してオープンされます。
これにより、データファイルに、表領域のトランスポート操作の目的のSCN時点の表領域内容が反映されます。

6. RMANによって、補助インスタンスのトランスポータブル・セットの表領域が読取り専用モードに設定されます。また、データ・ポンプ・エクスポートがトランスポータブル表領域モードで起動され、トランスポータブル・セットのエクスポート・ダンプ・ファイルが作成されます。
デフォルトでは、ダンプ・ファイルは表領域の格納場所に格納されます。ダンプ・ファイルの場所を指定するには、「データ・ポンプ・ファイルの場所の指定」を参照してください。

また、RMANによって、トランスポートした表領域をターゲット・データベースに組み込む場合に使用するサンプル・データ・ポンプ・インポート・スクリプトも生成されます。このスクリプトの内容は、表領域の格納場所のimpscript.sqlという名前のファイルに書き込まれます。このスクリプト用のコマンドも、RMANのコマンド出力に含まれます。

7. 前述の手順が正常に実行されると、RMANによって、補助インスタンスが停止され、TRANSPORT TABLESPACE操作の実行中に作成されたすべてのファイル(トランスポータブル・セット・ファイル、データ・ポンプ・エクスポート・ファイルおよびサンプル・インポート・スクリプトを除く)が削除されます。

トランスポータブル表領域セットの作成の基本手順

トランスポータブル表領域セットを作成する前に、いくつかの前提条件を満たす必要があります。これらの前提条件については、『Oracle Databaseバックアップおよびリカバリ・リファレンス』のTRANSPORT TABLESPACEエントリを参照してください。

トランスポータブル表領域セットの作成の基本手順は次のとおりです。

1. RMANクライアントを起動し、ソース・データベースおよびリカバリ・カタログ(使用する場合)に接続します。

2. 必要に応じて、補助インスタンスのパラメータ・ファイルで追加のパラメータを設定します。
このタスクについては、「補助インスタンスの初期化パラメータのカスタマイズ」を参照してください。

3. TRANSPORT TABLESPACEコマンドを実行します。
この基本的な方法については、「トランスポータブル表領域セットの作成」を参照してください。この方法を少し変更した例については、「トランスポータブル表領域セットの使用例」を参照してください。

4. TRANSPORT TABLESPACEコマンドが失敗した場合は、問題のトラブルシューティングを行い、コマンドが正常に実行されるまで再試行します。
この方法については、「トランスポータブル表領域セットの作成のトラブルシューティング」を参照してください。

5. 表領域のトランスポート手順(『Oracle Database管理者ガイド』を参照)に戻ります。

補助インスタンスの初期化パラメータのカスタマイズ

RMANは、補助インスタンスの作成時に、初期化パラメータ・ファイルを作成します。デフォルト値は、ほぼすべてのTRANSPORT TABLESPACEの例(特にTRANSPORT TABLESPACEコマンドにAUXILIARY DESTINATIONオプションを指定する場合)で正常に動作します。

また、RMANは、追加の初期化パラメータの値を含む補助インスタンスのパラメータ・ファイルも使用できます。これらの値によって、デフォルトの初期化パラメータ・ファイルで定義されているパラメータの値が上書きされます。次の理由から、補助インスタンスのパラメータ・ファイルを使用する場合があります。

- STREAMS_POOL_SIZEおよびSHARED_POOL_SIZEを増加するため(データ・ポンプ・エクスポートで必要な場合)。

- 補助インスタンスのデータファイルの場所を管理するため(「初期化パラメータを使用した補助ファイル名の指定」を参照)。たとえば、すべてのファイルの場所を個別に指定せずに、補助インスタンスのすべてのデータファイルが同一の場所に格納されないようにする場合などです。

- LOG_FILE_NAME_CONVERTを使用してオンラインREDOログの名前を指定するため(「初期化パラメータを使用した補助ファイル名の指定」を参照)。

補助インスタンスのパラメータ・ファイルは、補助インスタンスの完全な初期化パラメータ・ファイルとはみなされません。指定したパラメータは、補助インスタンスのデフォルト・パラメータに追加されるか、これらのパラメータを上書きします。上書きしない初期化ファイルに、パラメータを指定する必要はありません。

補助インスタンスの初期化パラメータの設定

RMANは、自動補助インスタンスに対して表26-1の基本初期化パラメータを定義します。

表26-1 補助インスタンスに対するデフォルトの初期化パラメータ

初期化パラメータ

値

DB_NAME

ソース・データベースのDB_NAMEと同じです。

COMPATIBLE

ソース・データベースの互換性設定と同じです。

DB_UNIQUE_NAME

DB_NAMEの値に基づいて生成された一意の値。

DB_BLOCK_SIZE

ソース・データベースのDB_BLOCK_SIZEと同じです。

DB_FILES

ソース・データベースのDB_FILESと同じです。

SGA_TARGET

推奨値280Mです。

DB_CREATE_FILE_DEST

補助の宛先(TRANSPORT TABLESPACEにAUXILIARY DESTINATION引数が設定されている場合のみ)。RMANは、Oracle管理の制御ファイルおよびオンライン・ログをこの場所に作成します。

表26-1に示されている、補助インスタンスのパラメータ・ファイル内の基本初期化パラメータを不適切な値で上書きすると、TRANSPORT TABLESPACEが失敗する場合があります。問題が発生する場合は、初期化パラメータをデフォルト値に戻してください。

関連項目:
ファイルの名前を指定するためにDB_FILE_NAME_CONVERTおよびLOG_FILE_NAME_CONVERTを使用する方法については、「初期化パラメータを使用した補助ファイル名の指定」を参照してください。

補助インスタンスのパラメータ・ファイルの場所の設定

デフォルトでは、RMANは、RMANクライアントが実行されているホスト上のオペレーティング・システム依存の場所で、補助の初期化パラメータ・ファイルを検索します。この場所は、補助インスタンスが実行されているホスト上ではない場合があります。UNIXシステムの場合、この場所は?/rdbms/admin/params_auxint.oraです。ここで、クエスチョン・マーク(?)は、RMANが実行されるホスト上のORACLE_HOMEを表します。デフォルトの場所でファイルが検出されない場合でも、RMANはエラーを生成しません。

補助インスタンスのデフォルトの初期化パラメータを使用する場合は、TRANSPORT TABLESPACEを実行する前に、補助インスタンスのパラメータ・ファイルが存在するかどうかを確認してください。

補助インスタンスのパラメータ・ファイルに別の場所を指定するには、RMANでTRANSPORT TABLESPACEコマンドの前にRUNブロック内でSET AUXILIARY INSTANCE PARAMETER FILEコマンドを使用します。補助インスタンスのパラメータ・ファイルのデフォルトの場所と同様に、SET AUXILIARY INSTANCE PARAMETER FILEコマンドを使用して指定したパスは、クライアント側のパスです。

RMANクライアントが実行されているホスト上に、/tmp/auxinstparams.oraというファイルを作成するとします。このファイルには、次の初期化パラメータが含まれています。

SHARED_POOL_SIZE=150M;

例26-1に示すように、TRANSPORT TABLESPACEを指定して初期化パラメータ・ファイルを使用できます。RMANが補助インスタンスを作成する際に、/tmp/auxinstparams.oraのSHARED_POOL_SIZEパラメータによって、SHARED_POOL_SIZEで使用されるデフォルト値が上書きされます。

例26-1 補助インスタンスのパラメータ・ファイルの指定

RUN
{
SET AUXILIARY INSTANCE PARAMETER FILE TO '/tmp/auxinstparams.ora';
TRANSPORT TABLESPACE tbs_2
TABLESPACE DESTINATION '/disk1/transportdest'
AUXILIARY DESTINATION '/disk1/auxdest';
}

トランスポータブル表領域セットの作成

この項では、最大限に自動化された最も基本的な場合のTRANSPORT TABLESPACEの使用について説明します。基本例を少し変更した例については、「トランスポータブル表領域セットの使用例」を参照してください。

『Oracle Databaseバックアップおよびリカバリ・リファレンス』のTRANSPORT TABLESPACEエントリに関する項で説明されている前提条件を満たしていると想定しています。また、『Oracle Database管理者ガイド』で説明されている前提条件も満たしていると想定しています。

- ソース・プラットフォームと宛先プラットフォーム間で、表領域のトランスポートがサポートされていることを確認します。

- トランスポータブル・セットに含める自己完結型の表領域セットを識別します。

トランスポータブル表領域セットを作成する手順

1. RMANクライアントを起動し、ソース・データベースおよびリカバリ・カタログ・データベース(使用している場合)に接続します。

2. RMANで、TRANSPORT TABLESPACEコマンドを実行します。
最も基本的な場合では、AUXILIARY DESTINATION句を指定します。これはオプションですが、指定することをお薦めします。RMANは、ほとんどの場合で機能するデフォルト値を使用します。補助の宛先を指定しない場合は、補助インスタンスのすべてのファイルに対して場所が指定されていることを確認します。補助ファイルに名前を指定する方法については、「補助ファイルの場所の指定」で説明されている規則を参照してください。

例26-2では、表領域tbs_2およびtbs_3を含むトランスポータブル表領域セットを作成します。

例26-2 トランスポータブル表領域セットの作成

TRANSPORT TABLESPACE tbs_2, tbs_3
TABLESPACE DESTINATION '/disk1/transportdest'
AUXILIARY DESTINATION '/disk1/auxdest';

コマンドが正常に実行されると、結果は次のようになります。

- トランスポータブル・セットのデータファイルが、元の名前で/disk1/transportdestという場所に格納されます。TRANSPORT TABLESPACEでは、トランスポータブル表領域セットのデータファイルは、宛先データベースのエンディアン形式に自動的には変換されません。必要に応じて、トランスポータブル・セットを作成した後にRMANのCONVERTコマンドを使用して、データファイルを宛先データベースのエンディアン形式に変換します。

- トランスポータブル・セットのデータ・ポンプ・エクスポート・ダンプ・ファイルの名前はdmpfile.dmp、エクスポート・ログの名前はexplog.log、サンプル・インポート・スクリプトの名前はimpscrpt.sqlになります。
すべてのファイルは、/disk1/transportdest内に作成されます。表領域の格納場所にエクスポート・ダンプ・ファイルの名前と同じ名前のファイルがすでに存在する場合は、TRANSPORT TABLESPACEでデータ・ポンプ・エクスポートをコールすると失敗します。前のTRANSPORT TABLESPACE操作を繰り返す場合には、以前の出力ファイル(エクスポート・ダンプ・ファイルを含む)を削除してください。

- 補助セット・ファイルが/disk1/auxdestから削除されます。

3. 必要に応じて、サンプル・インポート・スクリプトを編集します。
サンプル・インポート・スクリプトでは、表領域を宛先データベースにインポートするために使用するファイルは、TRANSPORT TABLESPACEで作成された場所と同じ場所に格納されていると想定されます。組込み前にファイルがディスク内の新しい場所に移動している場合、スクリプトを使用してトランスポートした表領域を組み込む前に、ファイルの新しい場所を使用してサンプル・スクリプトを更新する必要があります。

4. 表領域のトランスポート手順(『Oracle Database管理者ガイド』を参照)に戻ります。

トランスポータブル表領域セットの作成のトラブルシューティング

RMANのTRANSPORT TABLESPACEコマンドが失敗すると、トラブルシューティングのために、失敗した補助インスタンスのファイルがその補助インスタンスの宛先にそのまま残ります。

SET NEWNAME、CONFIGURE AUXNAMEおよびDB_FILE_NAME_CONVERT設定を使用したため、補助セット内またはトランスポータブル表領域セット内の複数のファイルに同じ名前が付けられた場合は、TRANSPORT TABLESPACEコマンドの実行中にエラーがレポートされます。この問題を解決するには、これらのパラメータに異なる値を使用して、重複するファイル名が作成されないようにします。ネーミング方法については、「補助ファイルの場所の指定」を参照してください。

トランスポータブル表領域セットの使用例

この項の内容は、次のとおりです。

- 指定した時点またはSCNでのトランスポータブル表領域セットの作成

- データ・ポンプ・ファイルの場所の指定

- 補助ファイルの場所の指定

指定した時点またはSCNでのトランスポータブル表領域セットの作成

TRANSPORT TABLESPACEコマンドを使用すると、目標時点またはSCNを指定できます。表領域のトランスポート操作中、RMANは、目標時点より前のバックアップを使用して補助インスタンスで表領域をリストアし、補助データベースでPoint-in-Timeリカバリを実行して指定の目標時点にリカバリします。このPoint-in-Timeリカバリに必要なバックアップおよびアーカイブREDOログが使用可能である必要があります。

例26-3に示すように、(現行のインカネーションまたはその祖先内の)SCNを使用して目標時点を指定できます。

例26-3 終了SCNの指定

TRANSPORT TABLESPACE tbs_2
TABLESPACE DESTINATION '/disk1/transportdest'
AUXILIARY DESTINATION '/disk1/auxdest'
UNTIL SCN 11379;

例26-4に示すように、リストア・ポイントを指定することもできます。

例26-4 終了リストア・ポイントの指定

TRANSPORT TABLESPACE tbs_2
TABLESPACE DESTINATION '/disk1/transportdest'
AUXILIARY DESTINATION '/disk1/auxdest'
TO RESTORE POINT 'before_upgrade';

例26-5に示すように、終了時刻を指定することもできます。

例26-5 終了時刻の指定

TRANSPORT TABLESPACE tbs_2
TABLESPACE DESTINATION '/disk1/transportdest'
AUXILIARY DESTINATION '/disk1/auxdest'
UNTIL TIME 'SYSDATE-1';

データ・ポンプ・ファイルの場所の指定

トランスポータブル・セットのデータ・ポンプ・エクスポート・ダンプ・ファイル、ターゲット・データベースで使用するサンプル・インポート・スクリプト、データ・ポンプ・エクスポートで生成されるログ・ファイル、およびこれらのファイルの書込み先となるディレクトリの名前は変更できます。

デフォルトでは、これらのファイルは、表領域の格納場所に格納され、次のような名前になります。

- データ・ポンプ・エクスポート・ダンプ・ファイルは、dmpfile.dmpという名前になります。

- エクスポート・ログ・ファイルは、explog.logという名前になります。

- サンプル・インポート・スクリプトは、impscrpt.sqlという名前になります。

TRANSPORT TABLESPACEコマンドのDATAPUMP DIRECTORY句を使用してデータベース・ディレクトリ・オブジェクトの名前で渡すことによって、ダンプ・ファイルとエクスポート・ログを異なるディレクトリに格納できます。DATAPUMP DIRECTORY句で使用するデータベース・ディレクトリ・オブジェクトは、実際のファイル・システム・ディレクトリのディレクトリ・パスではありません。渡される値は、データ・ポンプ・エクスポートのDIRECTORYコマンドライン引数に対応しています。データ・ポンプ・エクスポートでのディレクトリ・オブジェクトの使用方法の詳細は、『Oracle Databaseユーティリティ』を参照してください。

これらのファイルの名前は、TRANSPORT TABLESPACEのDUMP FILE、EXPORT LOG、およびIMPORT SCRIPT句を使用して変更できます。ファイル名には、ディレクトリ名を使用した完全なファイル・パスを含めることができません。DUMP FILEまたはEXPORT LOGというファイル名によってファイル・パスを指定した場合、TRANSPORT TABLESPACEでエクスポート・ダンプ・ファイルを生成しようとすると失敗します。DATAPUMP DIRECTORY句を使用して、データ・ポンプ・エクスポートの出力場所を識別するデータベース・ディレクトリ・オブジェクトを指定します。

次の例では、DATAPUMP DIRECTORY、DUMP FILE、EXPORT LOGおよびIMPORT SCRIPTというファイル名を指定したTRANSPORT TABLESPACEを使用します。次のように入力して、データ・ポンプ・エクスポートで使用するためにデータベース・ディレクトリ・オブジェクトを作成するとします。

CREATE OR REPLACE DIRECTORY mypumpdir as '/datapumpdest';

例26-6に、ファイルの出力場所を指定するオプションの引数を使用したTRANSPORT TABLESPACEコマンドを示します。

例26-6 ファイルの出力場所の指定

TRANSPORT TABLESPACE tbs_2
TABLESPACE DESTINATION '/transportdest'
AUXILIARY DESTINATION '/auxdest'
DATAPUMP DIRECTORY  mypumpdir
DUMP FILE 'mydumpfile.dmp'
IMPORT SCRIPT 'myimportscript.sql'
EXPORT LOG 'myexportlog.log';

正常に実行されると、RMANは、補助の宛先をクリーンアップし、DATAPUMP DIRECTORY(/datapumpdest/mydumpfile.dmpおよび/datapumpdest/myexportlog.log)によって参照されるディレクトリにデータ・ポンプ・エクスポート・ダンプ・ファイルおよびエクスポート・ログを作成し、トランスポータブル・セットのデータファイルを/transportdestに格納します。

補助ファイルの場所の指定

いくつかの規則が、トランスポート実行中に作成される補助インスタンス・ファイルの場所に影響します。

補助ファイルの場所を指定する方法にかかわらず、目標時点でこの転送操作に使用するのに適したデータファイル・コピーがいずれかの補助ファイルにすでに含まれるとRMANが判断した場合、データファイルをリストアするかわりに、そのデータファイル・コピーが使用されます。

存在するデータファイル・コピーのうち、要求された時点よりも新しいため、またはターゲット・データベースの一部として認識されていないためにこのトランスポート操作に適さないものは、データファイルのリストア時に上書きされます。

最も簡単な方法としては、TRANSPORT TABLESPACEコマンドのAUXILIARY DESTINATION句を使用して、RMANで自動的にすべてのファイルの場所を管理する方法があげられます。補助インスタンスの一部またはすべてのファイルを再配置するために、ファイルの場所を指定する次のオプションを優先順位の高い順に示します。

1. SET NEWNAME FOR DATAFILES
SET NEWNAME FOR TABLESPACE

SET NEWNAME FOR DATABASE

「補助データファイルに対するSET NEWNAMEの使用」を参照してください。

2. CONFIGURE AUXNAME
「補助データファイルに対するCONFIGURE AUXNAMEの使用」の説明に従ってこのコマンドを使用して、データファイルの名前を指定することができます。

3. TRANSPORT TABLESPACEコマンドのAUXILIARY DESTINATION句
「AUXILIARY DESTINATIONを使用した補助ファイルの場所の指定」の説明に従ってこのオプションを使用して、補助ファイルの場所を指定できます。

4. LOG_FILE_NAME_CONVERTおよびDB_FILE_NAME_CONVERT(初期化パラメータ・ファイル内)
「初期化パラメータを使用した補助ファイル名の指定」の説明に従ってこれらの初期化パラメータを使用して、補助ファイルの場所を指定できます。

これらのうち複数のオプションを使用する場合は、ファイルに適用されるリスト内の最初のオプションによってファイル名が決定されます。

補助データファイルに対するSET NEWNAMEの使用

RUNブロック内で次のSET NEWNAMEコマンドを使用すると、TRANSPORT TABLESPACEコマンドで使用するファイル名を指定できます。

- SET NEWNAME FOR DATAFILE

- SET NEWNAME FOR DATABASE

- SET NEWNAME FOR TABLESPACE

例26-7に示すSET NEWNAME FOR DATAFILEコマンドを使用すると、補助インスタンスのデータファイルは/disk1/auxdestではなく、指定した場所にリストアされます。

例26-7 SET NEWNAME FOR DATAFILEを使用した補助データファイル名の指定

RUN
{
SET NEWNAME FOR DATAFILE '/oracle/dbs/tbs_12.f'
TO '/bigdrive/auxdest/tbs_12.f';
SET NEWNAME FOR DATAFILE '/oracle/dbs/tbs_11.f'
TO '/bigdrive/auxdest/tbs_11.f';
TRANSPORT TABLESPACE tbs_2
TABLESPACE DESTINATION '/disk1/transportdest'
AUXILIARY DESTINATION '/disk1/auxdest';
}

SET NEWNAMEは、1回のみの操作に最適です。特定の表領域セット用に、定期的にバックアップからトランスポータブル表領域を作成する予定がある場合、補助インスタンスのデータファイルの場所に永続的な設定を行うために、SET NEWNAMEのかわりにCONFIGURE AUXNAMEを使用することを検討してください。

補助データファイルに対するCONFIGURE AUXNAMEの使用

CONFIGURE AUXNAMEコマンドを使用して、トランスポータブル表領域セットまたは補助セットのデータファイル用の永続的な場所を指定できます。RMANは、リカバリの前に、CONFIGURE AUXNAMEコマンドが使用されている各データファイルを指定された場所にリストアします。RMANは、操作が失敗しないかぎり、操作の完了時に補助セットのデータファイルを削除します。

CONFIGURE AUXNAMEコマンドとTRANSPORT ... AUXILIARY DESTINATIONコマンドの間の関係を表す例を示します。表領域tbs_11をトランスポートするとします。表領域tbs_12は、補助セットの一部であり、データファイルtbs_12.fを含んでいます。次の手順を実行します。

1. CONFIGURE AUXNAME文を使用して、補助セットのデータファイル/oracle/dbs/tbs_12.fに対してデフォルト以外の永続的な場所を設定します。
たとえば、次のコマンドを入力します。

CONFIGURE AUXNAME FOR '/oracle/dbs/tbs_12.f'
TO '/disk1/auxdest/tbs_12.f';

2. AUXILIARY DESTINATIONパラメータを指定してTRANSPORT TABLESPACEコマンドを実行します。
たとえば、次のコマンドを入力します。

TRANSPORT TABLESPACE tbs_11
AUXILIARY DESTINATION '/myauxdest';

前述の例で、RMANは、データファイル/oracle/dbs/tbs_12.fの補助セットのコピーを、AUXILIARY DESTINATIONで指定された場所ではなく/disk1/auxdest/tbs_12.fに格納します。CONFIGURE AUXNAME設定の優先順位が、AUXILIARY DESTINATIONの優先順位より高いためです。

注意:
『Oracle Databaseバックアップおよびリカバリ・リファレンス』で説明するように、SHOW AUXNAMEコマンドを実行することによって、現行のCONFIGURE AUXNAME設定を表示できます。

AUXILIARY DESTINATIONを使用した補助ファイルの場所の指定

AUXILIARY DESTINATION引数をTRANSPORT TABLESPACEとともに使用する場合、SET NEWNAMEまたはCONFIGURE AUXNAMEコマンドを使用して別の場所に移動されていない補助セット・ファイルは、TRANSPORT TABLESPACE操作の間に補助の宛先に格納されます。

AUXILIARY DESTINATIONを使用しない場合は、LOG_FILE_NAME_CONVERTを使用して、補助インスタンスのオンラインREDOログ・ファイルの場所を指定する必要があります。SET NEWNAMEまたはCONFIGURE AUXNAMEのいずれを使用しても、補助インスタンスのオンラインREDOログの場所に影響を与えることはできません。このため、AUXILIARY DESTINATIONまたはLOG_FILE_NAME_CONVERTを使用しない場合、RMANにはオンラインREDOログを作成する場所に関する情報がありません。

初期化パラメータを使用した補助ファイル名の指定

補助インスタンスのパラメータ・ファイルでLOG_FILE_NAME_CONVERTおよびDB_FILE_NAME_CONVERT初期化パラメータを使用すると、補助インスタンスのオンラインREDOログおよびその他のデータベース・ファイルの名前を指定できます。TRANSPORT TABLESPACEコマンドにAUXILIARY DESTINATION句を指定しない場合は、これらのパラメータによって、CONFIGURE AUXNAMEまたはSET NEWNAMEコマンドが実行されなかったすべてのファイルの場所が決定されます。

元のファイルがOracle Managed Files(OMF)ファイルである場合、LOG_FILE_NAME_CONVERTまたはDB_FILE_NAME_CONVERTを使用して、補助インスタンスのファイルに新しいOMFファイル名を生成することはできません。データベースによって、各OMF転送先で一意のファイル名が生成されるように管理されます。AUXILIARY DESTINATION句を使用して、オンラインREDOログ・ファイルの場所を制御する必要があります。AUXILIARY DESTINATION句、SET NEWNAMEコマンド、CONFIGURE AUXNAMEコマンドまたはDB_CREATE_FILE_DEST初期化パラメータを使用して、OMFデータファイルの場所を指定する必要があります。

関連項目:
LOG_FILE_NAME_CONVERTおよびDB_FILE_NAME_CONVERT初期化パラメータの詳細は、『Oracle Databaseリファレンス』を参照してください。

27 プラットフォーム間でのデータ転送

RMANを使用すると、異なるエンディアン形式のプラットフォーム間で表領域を転送できます。また、2つのプラットフォームのエンディアン形式が同じであるかぎり、RMANを使用してデータベース全体を別のプラットフォームにトランスポートすることもできます。

この章の内容は次のとおりです。

- クロス・プラットフォーム・データ・トランスポートの概要

- ソース・ホストでのクロス・プラットフォーム表領域変換の実行

- 転送先ホストでのクロス・プラットフォーム・データファイル変換の実行

- クロス・プラットフォーム・データベース変換の前のデータベースの確認

- データベースをトランスポートする場合のソース・ホストでのデータファイルの変換

- データベースをトランスポートする場合の宛先ホストでのデータファイルの変換

クロス・プラットフォーム・データ・トランスポートの概要

この項では、プラットフォーム間で表領域およびデータベースをトランスポートする場合の基本的な概念およびタスクについて説明します。

クロス・プラットフォーム・データ・トランスポートの目的

あるプラットフォームで実行されているデータベースの表領域を別のプラットフォームで実行されているデータベースにトランスポートできます。クロス・プラットフォーム・トランスポータブル表領域の通常の使用方法を次に示します。

- 表領域を変換することでプラットフォームに関係なく既存のデータベースに表領域を統合できるカスタマへ、構造化データをトランスポータブル表領域として公開する。

- 大規模なデータ・ウェアハウス・サーバーから小規模なコンピュータ(Linuxベースのワークステーションやサーバーなど)上のデータ・マートへデータを移動する。

- すべてのホストのエンディアン形式が同一である異機種間クラスタ間で、読取り専用表領域を共有する。

トランスポータブル表領域、その使用方法、およびトランスポータブル表領域を作成および使用する場合の様々な方法の詳細は、『Oracle Database管理者ガイド』を参照してください。

また、RMANを使用して、プラットフォーム間でデータベース全体をトランスポートすることもできます。たとえば、ビジネス要件によって、別のプラットフォームを使用する、より低コストなサーバー上でデータベースを実行する必要があるとします。この場合、データベースを再作成し、インポート・ユーティリティまたはトランスポータブル表領域を使用してデータを再移入するのではなく、RMANを使用してデータベース全体をトランスポートできます。

宛先ホストまたはソース・ホスト上のデータベースを変換できます。宛先ホストで変換を行う理由は次のとおりです。

- 変換プロセスによるソース・ホストのパフォーマンスのオーバーヘッドを回避する場合。

- 1つのソース・システムから複数の異なるプラットフォーム上の複数の受信者にデータベースを分散する場合。

- 新しいプラットフォームへの移行パスを評価する場合

クロス・プラットフォーム・データ転送の基本的な概念

ソース・プラットフォームと宛先プラットフォームが異なり、そのエンディアン形式も異なる場合は、トランスポータブル表領域の操作でRMANのCONVERTコマンドを使用する必要があります。同じエンディアン形式のプラットフォーム間でデータベースの一部を変換する場合、オペレーティング・システムの方法を使用してソースから宛先にファイルをコピーできます。同じエンディアン形式のデータベース全体を変換する場合、UNDO情報のあるすべてのデータファイルを変換する必要があります。ソースから宛先プラットフォームに直接データファイルをコピーすることはできません。

表領域およびデータファイルの変換

ソース・ホストではRMANのCONVERT TABLESPACEコマンドを使用して表領域の変換を実行できますが、宛先ホストでは実行できません。CONVERT TABLESPACEコマンドでは、データファイルのインプレース変換は実行されません。かわりに、このコマンドでは、宛先プラットフォームで使用するために適切な形式の出力ファイルが生成されます。ソース・データベース内のデータファイルの内容は変更されません。

宛先ホストではCONVERT DATAFILEコマンドを使用してファイルを変換できますが、ソース・ホストでは変換できません。データ・ポンプ・エクスポート・ユーティリティでは、エクスポート・ダンプ・ファイルが生成されます。このファイルは、宛先ホストに手動でコピーされたデータファイルとともに、宛先データベースにインポートできます。データファイルが宛先データベースにトランスポートされるまで、それらのデータファイルはデータベース内の表領域名に関連付けられません。この場合、RMANは、表領域名を一連のデータファイルに変換できません。このため、CONVERT DATAFILEを使用して、ファイル名でデータファイルを指定する必要があります。

注意:
CONVERT TABLESPACEまたはCONVERT DATAFILEの使用は、クロス・プラットフォーム・トランスポータブル表領域を使用する場合の1つの手順にすぎません。この章の手順を実行する前に、『Oracle Database管理者ガイド』のトランスポータブル表領域に関する項を参照してください。

データベースの変換

データベース全体を異なるプラットフォームに変換するには、両方のプラットフォームで同じエンディアン形式が使用されている必要があります。RMANのCONVERT DATABASEコマンドを使用すると、ソース・プラットフォームから宛先プラットフォームへのデータベース全体の移動を自動化できます。トランスポートされたデータベースには、ソース・データベースと同じデータおよび(いくつかの例外を除いて)ソース・データベースと同じ設定が含まれています。

宛先プラットフォームに自動的にトランスポートされるファイルを次に示します。

- 永続表領域に属するデータファイル
プラットフォーム間での表領域のトランスポートとは異なり、データベース全体をトランスポートする場合は、宛先プラットフォームとの互換性が維持されるように、特定の形式のブロック(UNDOセグメント内のブロックなど)を再フォーマットする必要があります。ソース・プラットフォームと宛先プラットフォームのエンディアン形式が同じである場合でも、トランスポータブル・データベースのデータファイルは変換する必要があります。表領域をトランスポートする場合のように、あるプラットフォームから別のプラットフォームにデータファイルを単純にコピーすることはできません。

- 初期化パラメータ・ファイルまたはサーバー・パラメータ・ファイル
データベースでテキストベースの初期化パラメータ・ファイルが使用されている場合、RMANはそのファイルをトランスポートします。データベースでサーバー・パラメータ・ファイルが使用されている場合、RMANは、そのサーバー・パラメータ・ファイルに基づいて初期化パラメータ・ファイルを生成し、トランスポートします。次に、初期化パラメータ・ファイルの設定に基づいて、宛先で新しいサーバー・パラメータ・ファイルを作成します。

通常、初期化パラメータ・ファイルの一部のパラメータを新しいデータベース用に手動で更新する必要があります。たとえば、DB_NAME、および宛先ホスト上のファイルの場所を示すCONTROL_FILESなどのパラメータを変更する場合があります。

ソース・プラットフォームまたは宛先プラットフォームのいずれかのデータファイルの形式を変換できます。CONVERT DATABASE ON DESTINATION PLATFORMコマンドでは、データファイルの形式は変換されません。かわりに、変換を実行するために手動で実行できるスクリプトが生成されます。CONVERT SCRIPTパラメータを指定すると、変換スクリプトが作成されます。このスクリプトを宛先ホストで手動で実行すると、データファイルのコピーをバッチ・モードで変換できます。TRANSPORT SCRIPTパラメータを指定すると、トランスポート・スクリプトが生成されます。このスクリプトには、宛先プラットフォーム上に新しいデータベースを作成するSQL文が含まれています。

ソース・ホストでのクロス・プラットフォーム表領域変換の実行

CONVERTコマンドの前提条件のリストについては、『Oracle Databaseバックアップおよびリカバリ・リファレンス』を参照してください。この項の手順を実行する前に、この前提条件をすべて満たしている必要があります。

わかりやすくするため、Sun Solarisホスト上で実行されているソース・データベースprod_sourceから、表領域financeおよびhrをトランスポートする必要があると想定します。Linux PC上で実行されている宛先データベースprod_destに、これらの表領域をトランスポートすることを計画します。ソース・ホスト上の一時ディレクトリ/tmp/transport_linux/に、変換済データファイルを格納することを計画しています。

ソース・ホストでクロス・プラットフォーム表領域変換を実行する手順

1. SQL*Plusを起動し、管理者権限でソース・データベースprod_sourceに接続します。

2. V$TRANSPORTABLE_PLATFORMビューで宛先プラットフォームの名前を問い合せます。
データベースには、クロス・プラットフォーム・データ・トランスポートをサポートする各プラットフォームの固有な内部名のリストが存在します。CONVERTコマンドのパラメータとして、ソース・プラットフォームまたは宛先プラットフォームの正確な名前が必要な場合があります。V$TRANSPORTABLE_PLATFORMを問い合せて、プラットフォームの名前を取得します。次の例では、Linuxプラットフォームの名前を問い合せます。

SELECT PLATFORM_ID, PLATFORM_NAME, ENDIAN_FORMAT
FROM   V$TRANSPORTABLE_PLATFORM
WHERE  UPPER(PLATFORM_NAME) LIKE '%LINUX%';

PC上のLinuxのPLATFORM_NAMEは、Linux IA (32-bit)です。

3. トランスポートする表領域を読取り専用モードに設定します。たとえば、次のように入力します。

ALTER TABLESPACE finance READ ONLY;
ALTER TABLESPACE hr READ ONLY;

4. 出力ファイルの名前を指定する方法を選択します。
CONVERTコマンドにFORMATまたはDB_FILE_NAME_CONVERT引数を指定して、出力ファイルの名前を制御する必要があります。次に、優先順位の高い順に規則を示します。

1. CONVERT ... DB_FILE_NAME_CONVERT句のパターンに一致するファイルは、そのパターンに基づいて名前が指定されます。

2. FORMAT句を指定すると、CONVERT ... DB_FILE_NAME_CONVERT句のパターンに基づいて名前が指定されていないすべてのファイルに対して、FORMAT句に基づいて名前が指定されます。

注意:
ソース・ファイルおよび宛先ファイルがOracle Managed Files名を持つ場合、CONVERT ... DB_FILE_NAME_CONVERTを使用して、CONVERTコマンドの出力ファイル名を生成することはできません。

5. RMANを起動し、TARGETとして(宛先データベースではなく)ソース・データベースに接続します。たとえば、次のように入力します。

% rman
RMAN> CONNECT TARGET SYS@prod_source

6. CONVERT TABLESPACEコマンドを実行して、データファイルを宛先ホストのエンディアン形式に変換します。
次の例でFORMAT引数は、変換されたデータファイルの名前および場所を制御しています。

RMAN> CONVERT TABLESPACE finance,hr
2>   TO PLATFORM 'Linux IA (32-bit)'
3>   FORMAT '/tmp/transport_linux/%U';

結果として、/tmp/transport_linux/ディレクトリに、Linux IA(32ビット)プラットフォームに適切なエンディアン形式のデータを含む一連の変換済データファイルが格納されます。

関連項目:
CONVERTコマンドの完全なセマンティクスについては、『Oracle Databaseバックアップおよびリカバリ・リファレンス』を参照してください。

7. 表領域をトランスポートする場合の一般的な手順の残りの手順を実行します。

1. Oracle Data Pump Exportユーティリティを使用して、ソース・ホスト上にエクスポート・ダンプ・ファイルを作成します。

2. 変換済データファイルおよびエクスポート・ダンプ・ファイルをソース・ホストから宛先ホストの目的のディレクトリに移動します。

3. インポート・ユーティリティを使用して、表領域を新しいデータベースに組み込みます。

4. 必要に応じて、トランスポートされた表領域を読取り/書込みモードに設定します。

転送先ホストでのクロス・プラットフォーム・データファイル変換の実行

CONVERTコマンドの前提条件のリストについては、『Oracle Databaseバックアップおよびリカバリ・リファレンス』を参照してください。この項の手順を実行する前に、この前提条件を満たしている必要があります。

転送先ホストでのクロス・プラットフォーム・データファイル変換

データファイルの変換では、出力ファイルの名前を指定する方法を選択する必要があります。CONVERTコマンドにFORMAT引数またはDB_FILE_NAME_CONVERT引数を指定して、出力ファイルの名前を指定する方法を制御する必要があります。次に、優先順位の高い順に規則を示します。

1. CONVERT ... DB_FILE_NAME_CONVERT句のパターンに一致するファイルは、そのパターンに基づいて名前が指定されます。

2. FORMAT句を指定すると、CONVERT ... DB_FILE_NAME_CONVERT句のパターンに基づいて名前が指定されていないすべてのファイルに対して、FORMAT句に基づいて名前が指定されます。

注意:
ソース・ファイルおよび宛先ファイルの両方がOracle Managed Filesである場合、CONVERT ... DB_FILE_NAME_CONVERTを使用して、CONVERTコマンドの出力ファイル名を生成することはできません。

ソース・プラットフォームおよび宛先プラットフォームが異なる場合は、FROM PLATFORMパラメータを指定する必要があります。V$TRANSPORTABLE_PLATFORMを問い合せて、プラットフォームの名前を確認します。エラーを回避するには、FROM PLATFORMの値が、変換するデータファイルの形式と一致している必要があります。FROM PLATFORMを指定しない場合、このパラメータはデフォルトで宛先プラットフォームの値になります。

CONVERT DATAFILEを使用したデータファイル形式の変換

この項では、CONVERT DATAFILEコマンドの使用方法について説明します。この項では、表領域finance(データファイルfin/fin01.dbfおよびfin/fin02.dbf)およびhr(データファイルhr/hr01.dbfおよびhr/hr02.dbf)を、prod_sourceというソース・データベースからトランスポートすると想定しています。このデータベースは、Sun Solarisホスト上で実行されています。Linux PC上で実行されているprod_destという宛先データベースに、これらの表領域をトランスポートすることを計画します。宛先ホスト上で変換を実行することを計画しています。

データファイルが宛先データベースに組み込まれる場合は、これらのデータファイルが/orahome/dbsに格納され、現行のディレクトリ構造が保持されるように計画します。つまり、hr表領域のデータファイルは/orahome/dbs/hrサブディレクトリに、finance表領域のデータファイルは/orahome/dbs/finディレクトリに格納されます。

転送先ホストでクロス・プラットフォーム・データファイル変換を実行する手順

1. SQL*Plusを起動し、管理者権限でソース・データベースprod_sourceに接続します。

2. V$TRANSPORTABLE_PLATFORMでソース・プラットフォームの名前を問い合せます。
データベースには、クロス・プラットフォーム・データ・トランスポートをサポートする各プラットフォームの固有な内部名のリストが存在します。CONVERTコマンドのパラメータとして、ソース・プラットフォームまたは宛先プラットフォームの正確な名前が必要な場合があります。たとえば、次のように入力すると、接続したデータベースのプラットフォーム名を取得できます。

SELECT PLATFORM_NAME
FROM   V$TRANSPORTABLE_PLATFORM
WHERE  PLATFORM_ID =
( SELECT PLATFORM_ID
FROM   V$DATABASE );

この例では、ソース・ホストのPLATFORM_NAMEはSolaris[tm] OE (64-bit)であると想定しています。

3. ソース・データベースからトランスポートする表領域を識別し、それらの表領域を読取り専用モードに設定します。
たとえば、financeおよびhrを読取り専用モードに設定するには、次のSQL文を入力します。

ALTER TABLESPACE finance READ ONLY;
ALTER TABLESPACE hr READ ONLY;

4. ソース・ホスト上で、データ・ポンプ・エクスポートを使用してエクスポート・ダンプ・ファイルを作成します。
この例では、ダンプ・ファイルはexpdat.dmpという名前になります。

5. エクスポート・ダンプ・ファイルおよびトランスポートするデータファイルを宛先ホストで使用可能にします。
NFSを使用して、ダンプ・ファイルおよび現行のデータベース・ファイル(コピーは対象外)をアクセス可能にします。また、オペレーティング・システム・ユーティリティを使用して、これらのファイルを宛先ホストにコピーすることもできます。

この例では、宛先ホストの/tmp/transport_solaris/ディレクトリにファイルを格納します。ファイルの元の場所からのサブディレクトリ構造を保持します。つまり、データファイルは次の場所に格納されます。

- /tmp/transport_solaris/fin/fin01.dbf

- /tmp/transport_solaris/fin/fin02.dbf

- /tmp/transport_solaris/hr/hr01.dbf

- /tmp/transport_solaris/hr/hr02.dbf

6. RMANを起動し、TARGETとして(ソース・データベースではなく)転送先データベースに接続します。たとえば、次のコマンドを入力します。

% rman
RMAN> CONNECT TARGET SYS@prod_dest

7. CONVERT DATAFILEコマンドを実行して、データファイルを宛先ホストのエンディアン形式に変換します。
次の例では、DB_FILE_NAME_CONVERTを使用して、変換済データファイルの名前および場所を制御します。また、FROM PLATFORM句も指定します。

RMAN> CONVERT DATAFILE
2>   '/tmp/transport_solaris/fin/fin01.dbf',
3>   '/tmp/transport_solaris/fin/fin02.dbf',
4>   '/tmp/transport_solaris/hr/hr01.dbf',
5>   '/tmp/transport_solaris/hr/hr02.dbf'
6>   DB_FILE_NAME_CONVERT
7>     '/tmp/transport_solaris/fin','/orahome/dbs/fin',
8>     '/tmp/transport_solaris/hr','/orahome/dbs/hr'
9>   FROM PLATFORM 'Solaris[tm] OE (64-bit)

結果として、/orahome/dbs/ディレクトリに一連の変換済データファイルが格納されます。これらのファイルの名前は次のとおりです。

- /orahome/dbs/fin/fin01.dbf

- /orahome/dbs/fin/fin02.dbf

- /orahome/dbs/hr/hr01.dbf

- /orahome/dbs/hr/hr02.dbf

8. 表領域をトランスポートする場合の一般的な手順の残りの手順を実行します。

1. インポート・ユーティリティを使用して、表領域を新しいデータベースに組み込みます。

2. 必要に応じて、トランスポートされた表領域を読取り専用モードに設定します。

関連項目:
CONVERTコマンドの構文およびセマンティクスについては、『Oracle Databaseバックアップおよびリカバリ・リファレンス』を参照してください。

クロス・プラットフォーム・データベース変換の前のデータベースの確認

「クロス・プラットフォーム・データ転送の基本的な概念」で説明されているように、RMANのCONVERT DATABASEコマンドを使用すると、あるプラットフォームから別のプラットフォームへのデータベース全体のコピーを自動化できます。

データベースを変換する前に、CONVERT DATABASEコマンドの前提条件のリストについて『Oracle Databaseバックアップおよびリカバリ・リファレンス』を参照してください。この項の手順を試す前に、この前提条件をすべて満たしていることを確認します。

前提条件の1つは、ソース・プラットフォームと宛先プラットフォームのエンディアン形式が同じである必要があるということです。たとえば、Microsoft WindowsからLinux for x86(両方ともリトル・エンディアン)またはHP-UXからAIX(両方ともビッグ・エンディアン)にデータベースをトランスポートすることはできますが、HP-UXからLinux for x86にデータベース全体をトランスポートすることはできません。

注意:
プラットフォームのエンディアン形式が異なるため、CONVERT DATABASEコマンドを使用できない場合は、宛先プラットフォーム上にデータベースを手動で作成し、クロス・プラットフォーム・トランスポータブル表領域を使用して、ソース・データベースから必要な表領域をトランスポートできます。

データベース全体をトランスポートする場合は、宛先プラットフォームとの互換性が維持されるように、特定のファイルをRMANによって変換する必要があることに注意してください。ソース・プラットフォームと宛先プラットフォームのエンディアン形式が同じである場合でも、ソース・システムから宛先システムにこれらのファイルを単純にコピーすることはできません。次のようなファイルは、RMANによって変換する必要があります。

- UNDOセグメントを含むファイル

- HP Tru64プラットフォーム内外へトランスポートされる自動セグメント領域管理(ASSM)セグメント・ヘッダーを含むファイル

CONVERT DATABASEコマンドは、デフォルトで、データベース内のすべてのデータファイルをRMANによる変換を使用して処理します。RMANによる変換では、ファイルに対して変更を行わない場合でも、ファイルをある場所から別の場所にコピーします。RMANによる変換を必要としないその他の方法でファイルをコピーする場合は、CONVERT DATABASEコマンドのSKIP UNNECESSARY DATAFILESオプションを使用します。このオプションを選択した場合、CONVERT DATABASEコマンドでは、前述のようなファイルのみが処理されます。その他のすべてのファイルは、ユーザーがソース・データベースから宛先データベースにコピーする必要があります。

ファイルは、ソース・データベースが読取り専用モードでオープンされた状態でコピーする必要があります。同様に、転送先データベースで変換が実行される場合、すべてのデータファイルは、ソース・データベースが読取り専用モードでオープンされた状態で、転送先データベースにコピーする必要があります。

データベースの変換を準備する手順

1. ソース・データベースで、SYSDBAとしてSQL*Plusセッションを開始します。

2. データベースを読取り専用モードでオープンします。

ALTER DATABASE OPEN READ ONLY;

3. SQL*Plusでサーバー出力が有効になっていることを確認します。
たとえば、次のSQL*Plusコマンドを入力します。

SET SERVEROUTPUT ON

4. DBMS_TDB.CHECK_DBファンクションを実行します。
このチェックを実行すると、データベースの転送を妨げる条件がないことが確認されます。転送を妨げる条件には、不適切な互換性設定、インダウト・トランザクションやアクティブ・トランザクション、ソース・プラットフォームと転送先プラットフォーム間の互換性のないエンディアン形式などがあります。

CHECK_DBを引数指定せずにコールすると、ソース・データベースにトランスポートを妨げる条件があるかどうかを確認できます。このファンクションは、表27-1に示す引数を指定してコールすることもできます。

表27-1 CHECK_DBファンクションのパラメータ

パラメータ

説明

target_platform_name

V$DB_TRANSPORTABLE_PLATFORMビューに表示される宛先プラットフォームの名前。

このパラメータは任意ですが、skip_optionパラメータを使用する場合は必須です。省略すると、宛先プラットフォームがソース・プラットフォームと互換性があると想定され、プラットフォームの互換性に関連性のない条件のみがテストされます。

skip_option

データベースがトランスポート可能かどうかをチェックする際にスキップするデータベースの部分(適切な場合)を指定します。指定可能な値(NUMBER型)は次のとおりです。

- SKIP_NONE(または0): すべての表領域がチェックされます。

- SKIP_OFFLINE(または2): オフライン表領域内のデータファイルのチェックがスキップされます。

- SKIP_READONLY(または3): 読取り専用表領域内のデータファイルのチェックがスキップされます。

例27-1では、32ビットWindowsにデータベースを転送するために、32ビットLinuxプラットフォーム上でCHECK_DBを実行し、読取り専用表領域をスキップします。

例27-1 DBMS_TDB.CHECK_DBの実行

DECLARE
db_ready BOOLEAN;
BEGIN
db_ready :=
DBMS_TDB.CHECK_DB('Microsoft Windows IA (32-bit)',DBMS_TDB.SKIP_READONLY);
END;
/

PL/SQL procedure successfully completed.

警告が表示されない場合またはDBMS_TDB.CHECK_DBによってTRUEが戻された場合は、データベースをトランスポートできます。手順6に進みます。

警告が表示された場合またはDBMS_TDB.CHECK_DBによってFALSEが戻された場合は、この時点でデータベースをトランスポートできません。手順5に進みます。

5. 出力を調べてデータベースをトランスポートできない理由を確認し、可能な場合は問題を解決してから、手順4に戻ります。該当する条件については、DBMS_TDBのドキュメントを参照してください。

6. DBMS_TDB.CHECK_EXTERNALファンクションを実行して、すべての外部表、ディレクトリまたはBFILEを識別します。RMANは、これらのファイルのトランスポートを自動化できません。したがって、ファイルを手動でコピーしてデータベースのディレクトリを再作成する必要があります。
例27-2に、DBMS_TDB.CHECK_EXTERNALファンクションのコール方法を示します。

例27-2 DBMS_TDB.CHECK_EXTERNALの実行

DECLARE
external BOOLEAN;
BEGIN
/* value of external is ignored, but with SERVEROUTPUT set to ON
* dbms_tdb.check_external displays report of external objects
* on console */
external := DBMS_TDB.CHECK_EXTERNAL;
END;
/

外部オブジェクトが存在しない場合は、このプロシージャを実行しても出力は行われません。ただし、外部オブジェクトが存在する場合は、次のような出力が表示されます。

The following external tables exist in the database:
SH.SALES_TRANSACTIONS_EXT
The following directories exist in the database:
SYS.DATA_PUMP_DIR, SYS.MEDIA_DIR, SYS.DATA_FILE_DIR, SYS.LOG_FILE_DIR
The following BFILEs exist in the database:
PM.PRINT_MEDIA

PL/SQL procedure successfully completed.

データベースをトランスポートする場合のソース・ホストでのデータファイルの変換

データベース全体をトランスポートする場合は、宛先プラットフォームとの互換性が維持されるように、特定の形式のブロック(UNDOセグメント内のブロックなど)を再フォーマットする必要があります。ソース・プラットフォームと宛先プラットフォームのエンディアン形式が同じである場合でも、トランスポータブル・データベースのデータファイルは変換する必要があります。表領域をトランスポートする場合のように、あるプラットフォームから別のプラットフォームにデータファイルを単純にコピーすることはできません。

UNDO情報のあるデータファイルおよびHP Tru64プラットフォームからのデータファイルは、変換する必要があります。デフォルトでは、CONVERT DATABASEコマンドが実行されるとすべてのデータファイルが変換されます。ただし、CONVERT DATABASEコマンドでSKIP UNNECESSARY DATAFILESを使用した場合は、UNDOセグメントを含むデータファイルおよびHP Tru64プラットフォームからのデータファイルが変換されます。UNDOセグメントを含まないデータファイルは、FTP、オペレーティング・システムのコピー・コマンドなどのメカニズムを使用して、新しいデータベースにコピーできます。

この項では、CONVERT DATABASEのすべての前提条件をすでに満たし、「クロス・プラットフォーム・データベース変換の前のデータベースの確認」の手順を実行済であると想定しています。この手順の目的は、クロス・プラットフォーム・データベース・トランスポートの一部として、ソース・ホスト上のデータファイルの形式を変換することです。

Solaris上で実行されるデータベースをWindows上で実行されるデータベースに変換するとします。

ソース・プラットフォーム上のデータベースを変換する手順

1. ソース・データベースを読取り専用モードでオープンします。

ALTER DATABASE OPEN READ ONLY;

2. RMANを起動し、TARGETとしてソース・データベースに接続します。たとえば、次のコマンドを入力します。

% rman
RMAN> CONNECT TARGET SYS@source_db

3. CONVERT DATABASEコマンドを実行します。
例27-3に、CONVERT DATABASEコマンドを示します(出力例も示します)。TRANSPORT SCRIPTパラメータによって、生成されるSQLスクリプトの場所を指定します。このスクリプトを使用して、新しいデータベースを作成できます。TO PLATFORMパラメータによって、転送先データベースのプラットフォームを指定します。DB_FILE_NAME_CONVERTパラメータによって、生成されるデータファイルのネーミング方法を指定します。

例27-3 ソース・ホスト上のデータベースの変換

RMAN> CONVERT DATABASE
2>   NEW DATABASE 'newdb'
3>   TRANSPORT SCRIPT '/tmp/convertdb/transportscript.sql'
4>   TO PLATFORM 'Microsoft Windows IA (32-bit)'
5>   DB_FILE_NAME_CONVERT '/disk1/oracle/dbs' '/tmp/convertdb';

Starting convert at 25-NOV-06
using channel ORA_DISK_1

External table SH.SALES_TRANSACTIONS_EXT found in the database

Directory SYS.DATA_PUMP_DIR found in the database
Directory SYS.MEDIA_DIR found in the database
Directory SYS.DATA_FILE_DIR found in the database
Directory SYS.LOG_FILE_DIR found in the database

BFILE PM.PRINT_MEDIA found in the database

User SYS with SYSDBA and SYSOPER privilege found in password file
User OPER with SYSDBA privilege found in password file
channel ORA_DISK_1: starting datafile conversion
input datafile fno=00001 name=/disk1/oracle/dbs/tbs_01.f
converted datafile=/tmp/convertdb/tbs_01.f
channel ORA_DISK_1: datafile conversion complete, elapsed time: 00:00:15
channel ORA_DISK_1: starting datafile conversion
input datafile fno=00002 name=/disk1/oracle/dbs/tbs_ax1.f
converted datafile=/tmp/convertdb/tbs_ax1.f
channel ORA_DISK_1: datafile conversion complete, elapsed time: 00:00:03
.
.
.
channel ORA_DISK_1: starting datafile conversion
input datafile fno=00016 name=/disk1/oracle/dbs/tbs_52.f
converted datafile=/tmp/convertdb/tbs_52.f
channel ORA_DISK_1: datafile conversion complete, elapsed time: 00:00:01
Run SQL script /tmp/convertdb/transportscript.sql on the destination platform
to create database
Edit init.ora file init_00gb3vfv_1_0.ora. This PFILE will be used to
create the database on the destination platform
To recompile all PL/SQL modules, run utlirp.sql and utlrp.sql on
the destination platform
To change the internal database identifier, use DBNEWID Utility
Finished backup at 25-NOV-06

4. CONVERT DATABASEの完了後、ソース・データベースを読取り/書込みで再度オープンできます。

5. CONVERT DATABASEで生成されたデータファイルを宛先ホスト上の目的の場所に移動します。
例27-3では、このコマンドによって、ソース・ホストの/tmp/convertdb/ディレクトリにファイルが作成されます。宛先データベースのファイルが格納される宛先ホストのディレクトリに、これらのファイルを移動します。

6. データファイルのパスが宛先ホスト上でのパスと異なる場合は、データファイルの新しい場所が参照されるようにトランスポート・スクリプトを編集します。

7. 必要に応じて、初期化パラメータ・ファイルを編集して、宛先データベースの設定を変更します。
初期化パラメータ・ファイルの先頭のいくつかのエントリは、データベースを転送先プラットフォームに移動する際に編集する必要があります。たとえば、初期化パラメータ・ファイルは次のような内容になっている場合があります。

# Please change the values of the following parameters:
control_files            = "/tmp/convertdb/cf_D-NEWDBT_id-1778429277_00gb9u2s"
db_recovery_file_dest    = "/tmp/convertdb/orcva"
db_recovery_file_dest_size= 10737418240
instance_name            = "NEWDBT"
service_names            = "NEWDBT.example.com"
plsql_native_library_dir = "/tmp/convertdb/plsqlnld1"
db_name                  = "NEWDBT"

8. 必要に応じて、変換されたデータファイルの新しい名前を使用するようにトランスポート・スクリプトを編集します。
例27-3では、トランスポート・スクリプトの名前は/tmp/convertdb/transportscript.sqlです。データベースを作成するには、転送先ホストでこのスクリプトを実行します。したがって、データファイルの正しい名前を使用してこのスクリプトを編集する必要があります。

9. 転送先ホストでSQL*Plusを起動し、オペレーティング・システム認証を使用してSYSDBAとして転送先データベース・インスタンスに接続します。
たとえば、次のように接続します。

SQL> CONNECT / AS SYSDBA

オペレーティング・システム認証を使用しない場合は、まず、Oracle Netファイルを構成してパスワード・ファイルを作成し、リスナーを起動する必要があります。その後、ネット・サービス名を使用してインスタンスに接続できます。

10. SQL*Plusでトランスポート・スクリプトを実行し、宛先ホスト上に新しいデータベースを作成します。

SQL> @transportscript

トランスポート・スクリプトが終了すると、新しいデータベースの作成が完了します。

データベースをトランスポートする場合の宛先ホストでのデータファイルの変換

この項では、CONVERT DATABASEコマンドのすべての前提条件をすでに満たし、「クロス・プラットフォーム・データベース変換の前のデータベースの確認」の手順を実行済であると想定しています。この手順の目的は、クロス・プラットフォーム・データベース・トランスポートの一部として、宛先ホスト上のデータファイルの形式を変換することです。

データファイルの変換は、次のフェーズで実行します。

1. ソース・ホストでのデータファイル初期変換手順の実行

2. 転送先ホストでのデータファイルの変換

ソース・ホストでのデータファイル初期変換手順の実行

この手順では、ソース・ホスト上でCONVERT DATABASEコマンドを実行します。このコマンドによって、初期化パラメータ・ファイル、および宛先ホストで使用するために編集可能なスクリプトが生成されます。また、変換前のデータファイルをソース・ホストから宛先ホストにコピーします。

ソース・ホストでデータファイル初期変換を実行する手順

1. データベースが読取り専用モードでオープンしていることを確認します。

2. RMANを起動し、TARGETとしてソース・データベースに接続します。
たとえば、次のコマンドを入力します。

% rman
RMAN> CONNECT TARGET SYS@source_db

3. CONVERT DATABASE ON DESTINATION PLATFORMコマンドを実行します。
例27-4に、CONVERT DATABASEコマンドの例を示します(出力例も示します)。ON DESTINATION PLATFORMパラメータを使用して、データファイルで必要とされるすべてのCONVERTコマンドがソース・プラットフォームではなく転送先プラットフォームで実行されるように指定します。FORMATパラメータによって、生成されるファイルのネーミング方法を指定します。

例27-4 CONVERT DATABASE ON DESTINATION PLATFORMの実行

RMAN> CONVERT DATABASE
2>   ON DESTINATION PLATFORM
3>   CONVERT SCRIPT '/tmp/convertdb/convertscript-target'
4>   TRANSPORT SCRIPT '/tmp/convertdb/transportscript-target'
5>   NEW DATABASE 'newdbt'
6>   FORMAT '/tmp/convertdb/%U';

Starting convert at 28-JAN-05
using target database control file instead of recovery catalog
allocated channel: ORA_DISK_1
channel ORA_DISK_1: sid=39 devtype=DISK

External table SH.SALES_TRANSACTIONS_EXT found in the database

Directory SYS.DATA_PUMP_DIR found in the database
Directory SYS.MEDIA_DIR found in the database
Directory SYS.DATA_FILE_DIR found in the database
Directory SYS.LOG_FILE_DIR found in the database

BFILE PM.PRINT_MEDIA found in the database

User SYS with SYSDBA and SYSOPER privilege found in password file
User OPER with SYSDBA privilege found in password file
channel ORA_DISK_1: starting to check datafiles
input datafile fno=00001 name=/disk1/oracle/dbs/tbs_01.f
channel ORA_DISK_1: datafile checking complete, elapsed time: 00:00:00
channel ORA_DISK_1: starting to check datafiles
input datafile fno=00002 name=/disk1/oracle/dbs/tbs_ax1.f
channel ORA_DISK_1: datafile checking complete, elapsed time: 00:00:00
channel ORA_DISK_1: starting to check datafiles
input datafile fno=00017 name=/disk1/oracle/dbs/tbs_03.f
channel ORA_DISK_1: datafile checking complete, elapsed time: 00:00:00
.
.
.
channel ORA_DISK_1: starting to check datafiles
input datafile fno=00015 name=/disk1/oracle/dbs/tbs_51.f
channel ORA_DISK_1: datafile checking complete, elapsed time: 00:00:00
channel ORA_DISK_1: starting to check datafiles
input datafile fno=00016 name=/disk1/oracle/dbs/tbs_52.f
channel ORA_DISK_1: datafile checking complete, elapsed time: 00:00:00
Run SQL script /tmp/convertdb/transportscript-target on the destination platform to create database
Edit init.ora file /tmp/convertdb/init_00gb9u2s_1_0.ora. This PFILE will be used to create the database on the destination platform
Run RMAN script /tmp/convertdb/convertscript-target on destination platform to convert datafiles
To recompile all PL/SQL modules, run utlirp.sql and utlrp.sql on the destination platform
To change the internal database identifier, use DBNEWID Utility
Finished backup at 28-JAN-05

例27-4のコマンドでは、トランスポート・スクリプト、新しいデータベースの初期化パラメータ・ファイル、および変換される各データファイル用のRMANのCONVERT DATAFILEを含む変換スクリプトが作成されます。

注意:
CONVERT DATABASE ON DESTINATION PLATFORMでは、変換済データファイルのコピーは生成されません。このコマンドでは、スクリプトのみが作成されます。

4. オペレーティング・システム・ユーティリティを使用して、宛先ホストの一時格納場所に次のファイルをコピーします。

- 変換するデータファイル

- 変換スクリプト

- トランスポート・スクリプト

- 宛先データベースの初期化ファイル

5. ソース・データベースを読取り/書込みモードにします。

転送先ホストでのデータファイルの変換

この項では、前の項で作成したスクリプトを使用して、転送先ホストのデータファイルを変換する方法について説明します。

前の項で作成した変換スクリプトでは、ソース・データベース・ファイルの元のデータファイル名を使用します。FORMATパラメータによって、CONVERT DATABASEコマンドのFORMATまたはDB_FILE_NAME_CONVERTパラメータを使用して生成される名前を指定します。

同じパス名を使用して宛先ホストからソース・データベースのデータファイルにアクセス可能な場合、変換スクリプトは、ソース・データベースが読取り専用であるかぎり、変更せずに宛先ホストで実行できます。たとえば、ソース・ホストおよび宛先ホストの両方でNFSを使用してソース・データファイルを含むディスクがマウントされており、両方のホストのマウント・ポイントが/fs1/dbs/である場合、編集は必要ありません。

転送先ホスト上のデータファイルを変換する手順

1. 必要に応じて、変換スクリプトを編集します。
変換スクリプトでは、変換するデータファイルごとに1つのCONVERT DATAFILEコマンドが存在します。変換スクリプトで、変換前データファイルの現在の一時ファイル名および変換済データファイルの出力ファイル名を指定する必要があります。典型的な変換スクリプトは、次のような内容になります。

RUN
{
CONVERT
FROM PLATFORM 'Linux IA (32-bit)'
PARALLELISM 10
DATAFILE '/disk1/oracle/dbs/tbs_01.f'
FORMAT
'/tmp/convertdb/data_D-TV_I-1778429277_TS-SYSTEM_FNO-1_7qgb9u2s';

DATAFILE '/disk1/oracle/dbs/tbs_ax1.f'
FORMAT
'/tmp/convertdb/data_D-TV_I-1778429277_TS-SYSAUX_FNO-2_7rgb9u2s';

DATAFILE '/disk1/oracle/dbs/tbs_03.f'
FORMAT
'/tmp/convertdb/data_D-TV_I-1778429277_TS-SYSTEM_FNO-17_7sgb9u2s';

DATAFILE '/disk1/oracle/dbs/tbs_51.f'
FORMAT
'/tmp/convertdb/data_D-TV_I-1778429277_TS-TBS_5_FNO-15_8egb9u2u';

DATAFILE '/disk1/oracle/dbs/tbs_52.f'
FORMAT
'/tmp/convertdb/data_D-TV_I-1778429277_TS-TBS_5_FNO-16_8fgb9u2u';
}

変換スクリプト内の各DATAFILEコマンドを編集し、各データファイルの一時格納場所を入力として指定します。また、各コマンドのFORMATパラメータを編集し、トランスポート済データベースのデータファイルの任意の最終格納場所を指定します。

2. 必要に応じて、宛先ホスト上の初期化パラメータ・ファイルを編集し、宛先データベースの設定を変更します。
初期化パラメータ・ファイルの先頭のいくつかのエントリは、データベースを転送先プラットフォームに移動する前に編集する必要があります。たとえば、初期化パラメータ・ファイルは次のような内容になっている場合があります。

# Please change the values of the following parameters:
control_files            = "/tmp/convertdb/cf_D-NEWDBT_id-1778429277_00gb9u2s"
db_recovery_file_dest    = "/tmp/convertdb/orcva"
db_recovery_file_dest_size= 10737418240
instance_name            = "NEWDBT"
service_names            = "NEWDBT.example.com"
plsql_native_library_dir = "/tmp/convertdb/plsqlnld1"
db_name                  = "NEWDBT"

3. 宛先ホストで、SQL*Plusを使用してデータベース・インスタンスをNOMOUNTモードで起動します。
前の手順でコピーした初期化パラメータ・ファイルを指定します。たとえば、次のコマンドを入力します。

SQL> STARTUP NOMOUNT PFILE='/tmp/init_convertdb_00i2gj63_1_0.ora'

4. RMANを起動し、TARGETとして(ソース・データベースではなく)宛先データベースに接続します。たとえば、次のコマンドを入力します。

% rman
RMAN> CONNECT TARGET SYS@prod_dest

5. RMANプロンプトで、変換スクリプトを実行します。たとえば、次のコマンドを入力します。

RMAN> @/tmp/convertdb/convertscript-target

6. データベース・インスタンスを停止します。
実行する必要がある転送スクリプトにSTARTUP NOMOUNTコマンドがすでに含まれているため、この手順が必要となります。

7. 必要に応じて、変換されたデータファイルの新しい名前を使用するようにトランスポート・スクリプトを編集します。
例27-3では、トランスポート・スクリプトは/tmp/convertdb/transportscript.sqlです。データベースを作成するには、宛先ホストでこのスクリプトを実行します。したがって、データファイルの正しい名前を使用してこのスクリプトを編集する必要があります。

8. SQL*Plusでトランスポート・スクリプトを実行します。
たとえば、次のように入力して宛先ホスト上に新しいデータベースを作成します。

SQL> @/tmp/convertdb/transportscript

トランスポート・スクリプトが終了すると、宛先データベースが作成されます。

第VIII部

ユーザー管理のバックアップおよびリカバリの実行

次の章では、ユーザー管理のバックアップおよびリカバリ計画(RMANを必要としない計画)を使用してバックアップおよびリカバリを実行する方法について説明します。この部に含まれる章は、次のとおりです。

- 第28章「ユーザー管理データベース・バックアップの作成」

- 第29章「ユーザー管理のデータベースのフラッシュバックおよびリカバリの実行」

- 第30章「ユーザー管理のリカバリの実行: 高度な例」

28 ユーザー管理データベース・バックアップの作成

この章では、ユーザー管理バックアップおよびリカバリ計画(Recovery Manager (RMAN)を必要としない計画)でOracle Databaseをバックアップする方法について説明します。

この章の内容は次のとおりです。

- V$ビューの問合せによるバックアップ情報の取得

- データベース全体のユーザー管理バックアップの作成

- 表領域およびデータファイルのユーザー管理バックアップの作成

- 制御ファイルのユーザー管理バックアップの作成

- アーカイブREDOログのユーザー管理バックアップの作成

- SUSPENDモードでのユーザー管理バックアップの作成

- RAWデバイスへのユーザー管理バックアップの作成

- Volume Shadow Copy Service(VSS)を使用したバックアップの作成

- ユーザー管理データファイル・バックアップの検証

V$ビューの問合せによるバックアップ情報の取得

バックアップを作成する前に、データベース内のすべてのファイルを確認して、バックアップするファイルを決定する必要があります。V$ビューを使用すると、この情報を取得できます。

バックアップ前のデータベース・ファイルの表示

データベースのデータファイルおよび制御ファイルを確認するには、V$DATAFILEおよびV$CONTROLFILEビューを使用します。次に示す手順は、これらのファイルの名前を手動で付けた場合も、Oracle Managed Filesで付けた場合も、同様に使用できます。

注意:
オンラインREDOログ・ファイルはバックアップしないでください。

データファイルおよび制御ファイルを表示する手順

1. SQL*Plusを起動し、V$DATAFILEを問い合せてデータファイルのリストを取得します。たとえば、次のように入力します。

SELECT NAME FROM V$DATAFILE;

V$TABLESPACEビューとV$DATAFILEビューを結合して、データファイルのリストと、関連する表領域のリストを取得することもできます。

SELECT   t.NAME "Tablespace", f.NAME "Datafile"
FROM     V$TABLESPACE t, V$DATAFILE f
WHERE    t.TS# = f.TS#
ORDER BY t.NAME;

2. V$CONTROLFILEビューを問い合せて、現行の制御ファイルのファイル名を取得します。たとえば、次の問合せを発行します。

SELECT NAME FROM V$CONTROLFILE;

多重制御ファイルの場合は、バックアップする必要があるのは1つのコピーのみです。

3. ALTER DATABASE BACKUP CONTROLFILE TO 'filename'文を使用して制御ファイルのバックアップを実行する場合には、制御ファイルのバックアップとともに、すべてのデータファイルおよびオンラインREDOログ・ファイルのリストを保存します。現在のデータベース構造は、制御ファイルの特定のバックアップが作成された時点のデータベース構造とは異なる場合があるため、バックアップ制御ファイルに記録されたファイルのリストを保存しておくと、リカバリを行う際に便利です。

オンライン表領域バックアップのデータファイルのステータスの確認

データファイルが現行のオンライン表領域のバックアップの一部であるかどうかを確認するには、V$BACKUPビューを問い合せます。

このビューはユーザー管理のオンライン表領域バックアップでのみ有効です。RMANのバックアップおよびオフライン表領域のバックアップでは、表領域のデータファイルをバックアップ・モードに設定する必要がないためです。 一部のユーザー管理バックアップ手順では、分裂ブロックの発生を防ぐため、表領域をバックアップ・モードにする必要があります。ただし、バックアップ・モードでは、データベースへの更新によって通常より多くのREDOが作成されます。

V$BACKUPビューは、データベースがオープンしている場合に特に有効です。また、障害時のファイルのバックアップ・ステータスも表示されるため、インスタンス障害の直後にも有効です。この情報を使用して、バックアップ・モードのままになっている表領域があるかどうかを確認します。

現在使用されている制御ファイルが、リストアされたバックアップか、メディア障害の発生後に作成された新しい制御ファイルの場合には、V$BACKUPは役に立ちません。リストアされた制御ファイルまたは再作成された制御ファイルには、データベースがV$BACKUPを正確に移入するために必要とする情報が含まれていません。また、ファイルのバックアップをリストアした場合には、V$BACKUPの中のこのファイルのSTATUSは、最新のバージョンではなく、ファイルの古いバージョンのバックアップ・ステータスを反映したものになります。このため、このビューにはリストアされたファイルに関して誤解を招くデータが表示される場合があります。

たとえば、次の問合せを実行して、バックアップ・モードに設定された表領域に現在どのようなデータファイルが含まれているかを表示するとします。

SELECT t.name AS "TB_NAME", d.file# as "DF#", d.name AS "DF_NAME", b.status
FROM   V$DATAFILE d, V$TABLESPACE t, V$BACKUP b
WHERE  d.TS#=t.TS#
AND    b.FILE#=d.FILE#
AND    b.STATUS='ACTIVE';

次の出力例は、toolsおよびusers表領域が現在ACTIVEステータスであることを示しています。

TB_NAME                 DF#        DF_NAME                           STATUS
----------------------  ---------- --------------------------------  ------
TOOLS                   7          /oracle/oradata/trgt/tools01.dbf  ACTIVE
USERS                   8          /oracle/oradata/trgt/users01.dbf  ACTIVE

STATUS列にNOT ACTIVEが表示されている場合、ファイルが現在バックアップ・モードではない(ALTER TABLESPACE ... BEGIN BACKUPまたはALTER DATABASE BEGIN BACKUP文を実行していない)ことを意味します。ACTIVEが表示されている場合、ファイルが現在バックアップ・モードであることを意味します。

データベース全体のユーザー管理バックアップの作成

NORMAL、IMMEDIATEまたはTRANSACTIONALオプションを使用してデータベースを停止した後で、データベース全体のバックアップを実行し、データベース内のすべてのファイルのバックアップを作成できます。データベースのオープン中、またはインスタンス障害やSHUTDOWN ABORTコマンドの後に作成されたデータベース全体のバックアップは一貫性のないものになります。この場合のファイルは、データベース・チェックポイントSCNと一貫性がありません。

データベースをARCHIVELOGモードまたはNOARCHIVELOGモードのどちらで実行していても、データベース全体のバックアップを作成できます。ただし、データベースをNOARCHIVELOGモードで実行する場合は、バックアップ前にデータベースを正しく停止して、一貫性のあるバックアップを作成する必要があります。

一貫性のあるデータベース全体のバックアップによって作成されたバックアップ・ファイルのセットでは、すべてのファイルで同じSCNにチェックポイントが設定されているため、一貫性があります。一貫性のあるデータベースのバックアップは、リカバリを実行せずにリストアできます。データベースをARCHIVELOGモードで実行している場合は、バックアップ・ファイルをリストアした後で、追加のリカバリ手順を実行してデータベースをより新しい時点までリカバリできます。また、データベースがARCHIVELOGモードの場合には、一貫性のないデータベース全体のバックアップを作成することもできます。

制御ファイルは、データベースのリストアおよびリカバリに重要な役割を果たします。ARCHIVELOGモードで実行しているデータベースの場合には、ALTER DATABASE BACKUP CONTROLFILE TO 'filename'文を使用して、制御ファイルをバックアップしておくことをお薦めします。

参照:
制御ファイルのバックアップの詳細は、「制御ファイルのユーザー管理バックアップの作成」を参照してください。

一貫性のあるデータベース全体のバックアップの作成

この項では、オペレーティング・システム・ユーティリティを使用してデータベースをバックアップする方法を説明します。

一貫性のあるデータベース全体のバックアップを作成する手順

1. データベースがオープンしている場合は、SQL*Plusを使用して、NORMAL、IMMEDIATEまたはTRANSACTIONALオプションを指定してデータベースを停止します。

2. オペレーティング・システム・ユーティリティを使用して、すべてのデータファイルと、初期化パラメータ・ファイルのCONTROL_FILESパラメータで指定されたすべての制御ファイルのバックアップを作成します。また、初期化パラメータ・ファイルおよびその他のOracle製品の初期化ファイルもバックアップします。これらのファイルを検索するには、*.oraを使用して、Oracleホーム・ディレクトリから開始してすべてのサブディレクトリを再帰的に検索します。
たとえば、次に示すとおり、データファイル、制御ファイルおよびアーカイブ・ログを/disk2/backupにバックアップできます。

% cp $ORACLE_HOME/oradata/trgt/*.dbf /disk2/backup
% cp $ORACLE_HOME/oradata/trgt/arch/* /disk2/backup/arch

3. SQL*PlusでSTARTUPコマンドを使用して、データベースを再起動します。

関連項目:
データベースの起動および停止の詳細は、『Oracle Database管理者ガイド』を参照してください。

表領域およびデータファイルのユーザー管理バックアップの作成

表領域およびデータファイルのユーザー管理バックアップを作成する方法は、ファイルがオフラインかオンラインかによって異なります。

オフラインの表領域およびデータファイルのユーザー管理バックアップの作成

オフライン表領域のバックアップを行うときには、次のガイドラインに注意してください。

- SYSTEM表領域またはアクティブなUNDOセグメントを含む表領域をオフラインにすることはできません。このような表領域では、次の方法は使用できません。

- 表領域Primary内に表があり、その索引が表領域Indexにあるとします。表領域Indexをオフラインにし、表領域Primaryをオンラインのままにしておくと、Primary内にある索引付きの表に対してデータ操作言語(DML)が発行されたときにエラーが発生する可能性があります。この問題は、オプティマイザによって選択されたアクセス方法で、Index表領域内の索引へのアクセスが必要となった場合にのみ発生します。

オフライン表領域をバックアップする手順

1. 表領域のバックアップを開始する前に、DBA_DATA_FILESビューを問い合せて、表領域のデータファイルを確認します。たとえば、users表領域をバックアップするとします。SQL*Plusで次の文を入力します。

SELECT TABLESPACE_NAME, FILE_NAME
FROM SYS.DBA_DATA_FILES
WHERE TABLESPACE_NAME = 'USERS';

TABLESPACE_NAME                   FILE_NAME
-------------------------------   --------------------------------
USERS                             /oracle/oradata/trgt/users01.dbf

この例の/oracle/oradata/trgt/users01.dbfは、users表領域の中のデータファイルに対応する完全指定のファイル名です。

2. 可能であれば、通常優先度で表領域をオフラインにします。これによって、後で、リカバリを行わなくても表領域を確実にオンラインに戻せます。次に例を示します。

SQL> ALTER TABLESPACE users OFFLINE NORMAL;

3. オフライン・データファイルをバックアップします。次に例を示します。

% cp /oracle/oradata/trgt/users01.dbf /d2/users01_'date "+%m_%d_%y"'.dbf

4. 表領域をオンラインにします。次に例を示します。

ALTER TABLESPACE users ONLINE;

注意:
一時または即時優先度を使用して表領域をオフラインにした場合には、表領域のリカバリを実行しないかぎり、表領域をオンラインにすることはできません。

5. 表領域のバックアップのリカバリに必要なREDOがアーカイブされるように、アーカイブされていないREDOログをアーカイブします。たとえば、次のように入力します。

ALTER SYSTEM ARCHIVE LOG CURRENT;

オフラインの表領域およびデータファイルのユーザー管理バックアップの作成

データベースのオープン中は、オンライン表領域のすべてのデータファイルまたは特定のデータファイルをバックアップできます。オンライン表領域が読取り/書込みか読取り専用かによって手順は異なります。

注意:
一時表領域はバックアップしないでください。

オンラインの読取り/書込み表領域のユーザー管理バックアップの作成

表領域がオンラインで、データベースがオープンしているときに、データファイルのユーザー管理バックアップを作成するには、読取り/書込み表領域をバックアップ・モードに設定する必要があります。 ALTER TABLESPACE ... BEGIN BACKUP文を使用すると、表領域をバックアップ・モードに設定できます。バックアップ・モードでは、変更されたデータ・ブロック全体がREDOストリームにコピーされます。ユーザーがALTER TABLESPACE ... END BACKUPまたはALTER DATABASE END BACKUP文を使用して表領域のバックアップ・モードを終了すると、データファイル・チェックポイントSCNが現在のデータファイル・チェックポイントSCNまで進みます。

この方法でバックアップされたデータファイルをリストアすると、リカバリが必要な場合は、REDOログ・ファイルの適切なセットを適用するように求められます。REDOログには、データファイルをリカバリし、データファイルを一貫性のある状態にするために必要なすべての変更が含まれています。

オープン状態のデータベース中のオンラインの読取り/書込み表領域をバックアップする手順

1. 表領域のバックアップを開始する前に、DBA_DATA_FILESデータ・ディクショナリ・ビューを使用して、表領域内のすべてのデータファイルを確認します。たとえば、users表領域をバックアップするとします。次のように入力します。

SELECT TABLESPACE_NAME, FILE_NAME
FROM   SYS.DBA_DATA_FILES
WHERE  TABLESPACE_NAME = 'USERS';

TABLESPACE_NAME                   FILE_NAME
-------------------------------   --------------------
USERS                             /oracle/oradata/trgt/users01.dbf
USERS                             /oracle/oradata/trgt/users02.dbf

2. オンライン表領域のバックアップの開始をマークします。たとえば、次の文は、表領域usersのオンライン・バックアップの開始をマークします。

SQL> ALTER TABLESPACE users BEGIN BACKUP;

注意:
BEGIN BACKUPを使用してオンライン表領域のバックアップの開始をマークしなかったか、またはオンライン表領域のコピーを開始する前にその文が完了していなかった場合は、生成されたデータファイルのコピーをその後のリカバリ操作で使用できません。このようなバックアップのリカバリは危険であり、エラーが発生してデータの一貫性がなくなる可能性があります。たとえば、リカバリ操作を試みるとファジー・ファイルの警告が発行され、データベースの一貫性が失われ、データベースをオープンできなくなる可能性があります。

3. オペレーティング・システム・コマンドを使用して、オンライン表領域のオンライン・データファイルをバックアップします。たとえば、LinuxおよびUNIXユーザーは次のように入力できます。

% cp /oracle/oradata/trgt/users01.dbf /d2/users01_'date "+%m_%d_%y"'.dbf
% cp /oracle/oradata/trgt/users02.dbf /d2/users02_'date "+%m_%d_%y"'.dbf

4. オンライン表領域のデータファイルをバックアップした後、END BACKUPオプションを指定したSQL文ALTER TABLESPACEを実行します。たとえば、次の文は、表領域usersのオンライン・バックアップを終了します。

SQL> ALTER TABLESPACE users END BACKUP;

5. 表領域のバックアップのリカバリに必要なREDOがアーカイブされるように、アーカイブされていないREDOログをアーカイブします。たとえば、次のように入力します。

SQL> ALTER SYSTEM ARCHIVE LOG CURRENT;

注意:
表領域のバックアップ・モードを終了しないと、Oracle Databaseはこの表領域内のデータ・ブロックのコピーをオンラインREDOログに書き込み続けるため、パフォーマンスの問題が発生します。また、表領域がまだバックアップ・モードのときにデータベースを停止しようとすると、ORA-01149エラーが表示されます。

オンラインの読取り/書込み表領域の複数のユーザー管理バックアップの作成

複数のオンライン表領域をバックアップする場合には、シリアルまたはパラレルにバックアップできます。必要に応じて、次のいずれかの手順を使用してください。

オンライン表領域のパラレル・バックアップ

バックアップが必要な複数の表領域のデータファイルのコピーを、同時にバックアップ・モードで作成できます。 ただし、すべての表領域を一度にオンライン・モードに設定すると、それらの表領域で多くの更新が実行された場合に大量のREDOログが生成される可能性があります。REDOには、変更された各データファイルの変更された各データ・ブロックのコピーを含める必要があるためです。次に示す手順を実行する前に、生成されるREDOのサイズを検討してください。

オンライン表領域をパラレルにバックアップする手順

1. 必要なすべてのALTER TABLESPACE文を一度に発行して、オンライン表領域でバックアップの準備をします。たとえば、次のように表領域users、toolsおよびindxをバックアップ・モードにします。

SQL> ALTER TABLESPACE users BEGIN BACKUP;
SQL> ALTER TABLESPACE tools BEGIN BACKUP;
SQL> ALTER TABLESPACE indx BEGIN BACKUP;

すべての表領域をバックアップするには、次のコマンドを使用します。

SQL> ALTER DATABASE BEGIN BACKUP;

2. オンライン表領域のすべてのファイルをバックアップします。たとえば、LinuxまたはUNIXユーザーは、次のコマンドを実行して、*.dbfという接尾辞を持つデータファイルをバックアップできます。

% cp $ORACLE_HOME/oradata/trgt/*.dbf /disk2/backup/

3. 表領域のバックアップ・モードを終了します。たとえば、次のように入力します。

SQL> ALTER TABLESPACE users END BACKUP;
SQL> ALTER TABLESPACE tools END BACKUP;
SQL> ALTER TABLESPACE indx END BACKUP;

すべてのデータファイルを一度に処理する場合は、ALTER TABLESPACEのかわりにALTER DATABASEコマンドを使用できます。

SQL> ALTER DATABASE END BACKUP;

4. 表領域のバックアップのリカバリに必要なREDOを後でメディア・リカバリに使用できるように、オンラインREDOログをアーカイブします。たとえば、次のように入力します。

SQL> ALTER SYSTEM ARCHIVE LOG CURRENT;

オンライン表領域のシリアル・バックアップ

オンライン・バックアップが必要なすべての表領域を、1つずつバックアップ・モードに設定できます。ALTER TABLESPACE ... BEGIN/END BACKUP文の間の間隔が最小化されるため、シリアル・バックアップ・オプションをお薦めします。データ・ブロック全体がREDOログにコピーされるため、オンライン・バックアップ中は表領域に関してさらにREDO情報が生成されます。

オンライン表領域をシリアルにバックアップする手順

1. 表領域でオンライン・バックアップの準備をします。たとえば、表領域usersをバックアップ・モードにするには、次のように入力します。

SQL> ALTER TABLESPACE users BEGIN BACKUP;

この場合は、すべての表領域を同時にバックアップ・モードに設定するALTER DATABASE BEGIN BACKUPは使用しません。オンライン・モードの表領域に関するREDOログ情報がさらに生成されるためです。

2. 表領域のデータファイルをバックアップします。たとえば、次のように入力します。

% cp /oracle/oradata/trgt/users01.dbf /d2/users01_'date "+%m_%d_%y"'.dbf

3. 表領域のバックアップ・モードを終了します。たとえば、次のように入力します。

SQL> ALTER TABLESPACE users END BACKUP;

4. 残りの各表領域で、この手順を繰り返します。

5. 表領域のバックアップのリカバリに必要なREDOがアーカイブされるように、アーカイブされていないREDOログをアーカイブします。たとえば、次のように入力します。

SQL> ALTER SYSTEM ARCHIVE LOG CURRENT;

インスタンス障害またはSHUTDOWN ABORT後のバックアップの終了

次の場合には、表領域のバックアップが失敗し、不完全になることがあります。

- バックアップが完了したが、ユーザーがALTER TABLESPACE ... END BACKUP文を実行していない場合。

- インスタンス障害またはSHUTDOWN ABORTによってバックアップが中断された場合。

障害からのリカバリが必要なときに、バックアップ・モードのデータファイルをオープンしようとした場合、リカバリ・コマンドが発行されるか、またはデータファイルのバックアップ・モードが終了するまでは、データファイルはオープンされません。

たとえば、起動時に次のようなメッセージが表示される場合があります。

ORA-01113: file 12 needs media recovery
ORA-01110: data file 12: '/oracle/dbs/tbs_41.f'

ユーザーが表領域のオンライン・バックアップを終了しなかったために、複数の表領域のデータファイルでメディア・リカバリが必要であると表示された場合、データベースがマウントされているかぎり、ALTER DATABASE END BACKUP文を実行して、すべてのデータファイルで同時にバックアップ・モードを終了できます。

高可用性が必要な場合およびデータベース管理者(DBA)がデータベースを監視していない場合は、ユーザーの介入を必要とする事態は回避する必要があります。このために、次の内容の障害リカバリ・スクリプトを作成しておくことができます。

1. データベースをマウントする。

2. ALTER DATABASE END BACKUP文を実行する。

3. ALTER DATABASE OPENを実行し、システムが自動的に起動できるようにする。

ALTER DATABASE END BACKUPを含む自動化されたクラッシュ・リカバリ・スクリプトは、次の場合に特に有効です。

- Oracle Real Application Clusters(Oracle RAC)構成内のすべてのノードで障害が発生した場合。

- コールド・フェイルオーバー・クラスタ(最初のノードで障害が発生した場合に、2番目のノードでデータベースをマウントしてリカバリする必要があるOracle RAC構成ではないクラスタ)内の1つのノードで障害が発生した場合。

また、表領域がバックアップ・モードのときに発生したシステム障害後に、次の手動の方法を使用することもできます。

- データベースをリカバリし、END BACKUP文を発行せずに済ませる。

- データベースをマウントし、まだバックアップ・モードになっている各表領域に対してALTER TABLESPACE ... END BACKUP文を実行する。

ALTER DATABASE END BACKUP文を使用したバックアップ・モードの終了

複数の表領域がバックアップ・モードのままになっているときには、ALTER DATABASE END BACKUP文を実行できます。このコマンドの主な目的は、DBAの介入なしに、クラッシュ・リカバリ・スクリプトで障害の発生したシステムを再起動することです。また、次の手順を手動で実行することもできます。

複数の表領域でバックアップ・モードを同時に終了する手順

1. データベースをマウントしますが、オープンはしません。たとえば、次のように入力します。

SQL> STARTUP MOUNT

2. この手順を手動で(障害リカバリ・スクリプトの一部としてではなく)実行する場合は、V$BACKUPビューを問い合せて、データベースが再起動される前にバックアップされていた表領域のデータファイルのリストを表示します。

SQL>  SELECT * FROM V$BACKUP WHERE STATUS = 'ACTIVE';
FILE#      STATUS             CHANGE#    TIME
---------- ------------------ ---------- ---------
12 ACTIVE                  20863 25-NOV-02
13 ACTIVE                  20863 25-NOV-02
20 ACTIVE                  20863 25-NOV-02
3 rows selected.

3. ALTER DATABASE END BACKUP文を発行し、現在バックアップ・モードになっているすべてのデータファイルでバックアップ・モードを終了します。たとえば、次のように入力します。

SQL> ALTER DATABASE END BACKUP;

この文を使用できるのは、データベースがマウントされているが、オープンされていない場合のみです。データベースがオープンしている場合には、影響を受ける各表領域またはデータファイルに対して、ALTER TABLESPACE ... END BACKUPまたはALTER DATABASE DATAFILE ... END BACKUPを使用します。

注意:
影響を受けるファイルがバックアップからリストアされている場合は、ALTER DATABASE END BACKUPを使用しないでください。

SQL*PlusのRECOVERコマンドを使用したバックアップ・モードの終了

オンライン・バックアップが失敗した場合の対処方法は、ALTER DATABASE END BACKUP文を発行する以外にもあります。つまり、SQL*PlusのRECOVERコマンドを実行することもできます。他のユーザーがバックアップをリストアしているかどうかがわからない場合は、この方法が有効です。他のユーザーが実際にバックアップをリストアしていた場合に、RECOVERコマンドによってバックアップが最新に更新されるためです。ALTER DATABASE END BACKUPまたはALTER TABLESPACE ... END BACKUP文は、ファイルが現行のものであることが確実な場合にのみ実行してください。

注意:
オンライン・バックアップが開始されてから以降に生成されたREDOをスキャンする必要があるため、RECOVERコマンドを使用した方法には時間がかかります。

RECOVERコマンドを使用して表領域のバックアップ・モードを終了する手順

1. データベースをマウントします。たとえば、次のように入力します。

SQL> STARTUP MOUNT

2. データベースを通常どおりにリカバリします。たとえば、次のように入力します。

SQL> RECOVER DATABASE

3. V$BACKUPビューを使用して、アクティブなデータファイルがないことを確認します。

SQL>  SELECT * FROM V$BACKUP WHERE STATUS = 'ACTIVE';
FILE#      STATUS             CHANGE#    TIME
---------- ------------------ ---------- ---------
0 rows selected.

関連項目:
データベースのリカバリについては、第29章「ユーザー管理のデータベースのフラッシュバックおよびリカバリの実行」を参照してください。

読取り専用表領域のユーザー管理バックアップの作成

オンラインの読取り専用表領域をバックアップする場合は、オンライン・データファイルをバックアップするのみで実行できます。データベースではデータファイルに対する変更が許可されないため、表領域をバックアップ・モードに設定する必要はありません。

読取り専用表領域のセットが自己完結型の場合には、オペレーティング・システム・コマンドを使用して表領域をバックアップする以外に、トランスポータブル表領域機能を使用して、表領域のメタデータをエクスポートすることもできます。メディア・エラーまたはユーザー・エラー(読取り専用表領域の表を誤って削除するなど)が発生した場合、表領域を元のデータベースに戻すことができます。

関連項目:
表領域のトランスポート方法については、『Oracle Database管理者ガイド』を参照してください。

オープン状態のデータベースのオンラインの読取り専用表領域をバックアップする手順

1. DBA_TABLESPACESビューを問い合せて、読取り専用の表領域を確認します。たとえば、次の問合せを実行します。

SELECT TABLESPACE_NAME, STATUS
FROM DBA_TABLESPACES
WHERE STATUS = 'READ ONLY';

2. 読取り専用表領域のバックアップを開始する前に、DBA_DATA_FILESデータ・ディクショナリ・ビューを問い合せて、表領域のすべてのデータファイルを確認します。たとえば、history表領域をバックアップする場合、次の問合せを実行します。

SELECT TABLESPACE_NAME, FILE_NAME
FROM SYS.DBA_DATA_FILES
WHERE TABLESPACE_NAME = 'HISTORY';

TABLESPACE_NAME                   FILE_NAME
-------------------------------   --------------------
HISTORY                           /oracle/oradata/trgt/history01.dbf
HISTORY                           /oracle/oradata/trgt/history02.dbf

3. オペレーティング・システム・コマンドを使用して、読取り専用表領域のオンライン・データファイルをバックアップします。ユーザーによる読取り専用表領域への変更は自動的に防止されるため、表領域をオフラインにしたり、表領域をバックアップ・モードにする必要はありません。次に例を示します。

% cp $ORACLE_HOME/oradata/trgt/history*.dbf  /disk2/backup/

注意:
読取り専用表領域のバックアップをリストアする場合は、表領域をオフラインにし、データファイルをリストアした後、表領域をオンラインにします。読取り専用表領域がバックアップ後に読取り/書込みにされている場合にも、読取り専用表領域のバックアップは使用可能ですが、リストアされたバックアップでリカバリが必要になります。

4. 必要に応じて、読取り専用表領域のメタデータをエクスポートします。トランスポータブル表領域機能を使用すると、メディア障害またはユーザー・エラーの場合に、データファイルを迅速にリストアし、メタデータをインポートできます。たとえば、次のように、表領域historyのメタデータをエクスポートします。

% expdp DIRECTORY=dpump_dir1 DUMPFILE=hs.dmp TRANSPORT_TABLESPACES=history
LOGFILE=tts.log

関連項目:
DBA_DATA_FILESビューおよびDBA_TABLESPACESビューの詳細は、『Oracle Databaseリファレンス』を参照してください。

制御ファイルのユーザー管理バックアップの作成

ARCHIVELOGモードで実行中のデータベースの構造変更を行った後で、データベースの制御ファイルをバックアップします。データベースの制御ファイルをバックアップするには、ALTER DATABASEシステム権限が必要です。

制御ファイルのバイナリ・ファイルへのバックアップ

制御ファイルをバックアップする第一の手段は、SQL文を使用してバイナリ・ファイルを生成する方法です。バイナリ・バックアップにはアーカイブ・ログ履歴、読取り専用およびオフライン表領域のオフライン範囲、バックアップ・セットとコピー(RMANを使用する場合)などの追加情報が含まれるため、トレース・ファイル・バックアップよりもバイナリ・バックアップを使用することをお薦めします。COMPATIBLEが10.2以上の場合、制御ファイルのバイナリ・バックアップには、一時ファイル・エントリが含まれます。

構造変更の後に制御ファイルをバックアップする手順

1. データベースを変更します。たとえば、表領域を作成します。

CREATE TABLESPACE tbs_1 DATAFILE 'file_1.f' SIZE 10M;

2. 出力バイナリ・ファイルのファイル名を指定して、データベースの制御ファイルをバックアップします。次の例は、/disk1/backup/cf.bakに制御ファイルをバックアップします。

ALTER DATABASE BACKUP CONTROLFILE TO '/disk1/backup/cf.bak' REUSE;

REUSEを指定すると、新規の制御ファイルで既存の制御ファイルを上書きできます。

制御ファイルのトレース・ファイルへのバックアップ

制御ファイルは、CREATE CONTROLFILE文が含まれるテキスト・ファイルにバックアップできます。トレース・ファイルを編集し、トレース・ファイルの作成時点で現行のものであった制御ファイルに基づいて、新しい制御ファイルを作成するスクリプトを作成することができます。

SQL文でRESETLOGSオプションもNORESETLOGSオプションも指定しなかった場合は、トレース・ファイルにRESETLOGSとNORESETLOGSの両方のオプション用の制御ファイルが含まれます。ALTER TABLESPACE ... ADD TEMPFILE文を使用すると、出力に一時ファイル・エントリが含まれます。

NORMALモードでオフラインにされた表領域または読取り専用表領域をリカバリしないように、CREATE CONTROLFILE文を編集してそれらを除外してください。再作成された制御ファイルを使用してデータベースをオープンすると、データベースではこれらの省略されたファイルはMISSINGとしてマークされます。ALTER DATABASE RENAME FILE文を実行すると、それらのファイルを元のファイル名に戻すことができます。

CREATE CONTROLFILE文を含むトレース・ファイルは、DIAGNOSTIC_DEST初期化パラメータに指定されたサブディレクトリに格納されます。CREATE CONTROLFILE文が書き込まれるトレース・ファイルの名前および場所については、データベースのアラート・ログで確認できます。アラート・ログの場所を確認する方法については、『Oracle Database管理者ガイド』を参照してください。

制御ファイルをトレース・ファイルにバックアップする手順

1. データベースをマウントまたはオープンします。

2. 次のSQL文を実行します。

ALTER DATABASE BACKUP CONTROLFILE TO TRACE;

関連項目:
CREATE CONTROLFILE文に含まれる、読取り専用ファイル、NORMALモードでオフライン化されたファイルおよび一時ファイルに関連する特殊な問題については、「再作成された制御ファイルを使用した読取り専用ファイルのリカバリ」を参照してください。

アーカイブREDOログのユーザー管理バックアップの作成

プライマリのアーカイブ場所のディスク領域を節約するために、アーカイブ・ログをテープまたは代替のディスクの場所にバックアップできます。複数の場所にアーカイブするときには、各ログ順序番号の1つのコピーのみバックアップします。

アーカイブREDOログをバックアップする手順

1. V$ARCHIVED_LOGを問い合せて、データベースから生成されたアーカイブREDOログ・ファイルを確認します。たとえば、次の問合せを実行します。

SELECT THREAD#,SEQUENCE#,NAME
FROM V$ARCHIVED_LOG;

2. オペレーティング・システム・ユーティリティを使用して、各ログ順序番号で1つのコピーをバックアップします。この例では、プライマリのアーカイブ場所からログのバックアップ専用のディスクにすべてのログをバックアップします。

% cp $ORACLE_HOME/oracle/trgt/arch/* /disk2/backup/arch

関連項目:
データ・ディクショナリ・ビューの詳細は、『Oracle Databaseリファレンス』を参照してください。

SUSPENDモードでのユーザー管理バックアップの作成

この項の内容は、次のとおりです。

- 一時停止/再開機能

- 一時停止中のデータベースのバックアップの作成

一時停止/再開機能

サード・パーティ・ツールには、ディスクまたは論理デバイスのセットをミラー化(プライマリ・データの正確な複製を別の場所に保持)し、後でミラーを分割できるものがあります。ミラーの分割では、コピーが分離されるため、それぞれを別々に使用できます。

SUSPEND/RESUMEの機能を使用すると、データベースに対するI/Oを一時停止した後、ミラーを分割し、分割されたミラーのバックアップを作成できます。バックアップ・モード機能を補完するこの機能によって、I/Oが新しく実行されないように、データベースI/Oを一時停止できます。その後、一時停止中のデータベースにアクセスし、I/Oに影響を受けずにバックアップを作成できます。

ミラーの分割によるバックアップを作成するためにSUSPEND/RESUMEを使用する必要はありませんが、使用しているシステムで、ボリュームを分割する前にデータベース・キャッシュの使用済バッファを排除しておく必要がある場合には、このコマンドが必要になります。RAIDデバイスの中には、分割操作の実行中に書込みを一時停止できるものがあります。使用しているシステムでこの機能を使用できるかどうかは、RAIDのベンダーに確認してください。

ALTER SYSTEM SUSPEND文は、データファイル・ヘッダー、データファイルおよび制御ファイルに対するI/Oを停止して、データベースを一時停止します。データベースが一時停止すると、既存のすべてのI/O操作は完了できますが、データベースに対する新規のI/Oアクセスの試行はキューされます。

ALTER SYSTEM SUSPEND文およびALTER SYSTEM RESUME文は、インスタンスのみではなく、データベースに対して実行されます。ALTER SYSTEM SUSPEND文がOracle RAC構成中の1つのシステムで入力された場合は、内部のロッキング・メカニズムによって全インスタンスに停止要求が伝播され、クラスタ内のすべてのアクティブなインスタンスでI/O操作が一時停止されます。

一時停止中のデータベースのバックアップの作成

データベースが正常に一時停止した後、ディスクにデータベースをバックアップするか、ミラー化を解除できます。データベースを一時停止してもI/Oがすぐに終了されるとはかぎらないため、ALTER SYSTEM SUSPEND文の前にBEGIN BACKUP文を使用して、表領域をバックアップ・モードにすることをお薦めします。

分割されたミラーをバックアップするには、従来のユーザー管理バックアップ方式を使用する必要があります。データファイル・ヘッダーの読取りが必要になるため、RMANはデータベースのバックアップまたはコピーを作成できません。データベースのバックアップが終了するか、ミラーを復元した後、ALTER SYSTEM RESUME文を使用して、通常のデータベース操作を再開できます。

ミラーを分割せずに一時停止中のデータベースをバックアップすると、バックアップ中はデータベースにアクセスできなくなるため、データベースが長期間停止する可能性があります。ミラーを分割してバックアップを実行すると、停止は短時間で済みます。停止時間は、フラッシュするキャッシュのサイズ、データファイルの数、およびミラー化の解除に必要な時間によって異なります。

SUSPEND/RESUME機能には次の制限があります。

- Oracle RAC構成では、オリジナル・ノードの一時停止中に新規インスタンスを起動できません。

- ALTER SYSTEM SUSPEND文またはALTER SYSTEM RESUME文からはチェックポイントは開始されません。

- データベースの一時停止中は、IMMEDIATE、NORMALまたはTRANSACTIONALオプションを指定してSHUTDOWNコマンドを発行できません。

- 一時停止中のデータベースに対してSHUTDOWN ABORTを発行すると、データベースが再度アクティブになります。この操作により、メディア・リカバリまたは障害リカバリが無応答状態になるのを回避できます。

SUSPENDモードでミラーの分割によるバックアップを作成する手順

1. データベースの表領域をバックアップ・モードにします。たとえば、表領域usersをバックアップ・モードにするには、次のように入力します。

ALTER TABLESPACE users BEGIN BACKUP;

データベースのすべての表領域をバックアップする場合は、かわりに次のコマンドを使用できます。

ALTER DATABASE BEGIN BACKUP;

注意:
表領域をバックアップ・モードに設定する代替方法としてALTER SYSTEM SUSPEND文を使用しないでください。

2. ミラー化システムで、ディスクの書込み中にミラーの分割に問題が発生する場合には、データベースを一時停止します。たとえば、次の文を発行します。

ALTER SYSTEM SUSPEND;

3. V$INSTANCEビューを問い合せて、データベースが一時停止されていることを確認します。次に例を示します。

SELECT DATABASE_STATUS FROM V$INSTANCE;

DATABASE_STATUS
-----------------
SUSPENDED

4. オペレーティング・システムまたはハードウェア・レベルでミラーを分割します。

5. データベースの一時停止を終了します。たとえば、次の文を発行します。

ALTER SYSTEM RESUME;

6. V$INSTANCEビューを問い合せて、データベースがアクティブであることを確認します。たとえば、次のように入力します。

SELECT DATABASE_STATUS FROM V$INSTANCE;

DATABASE_STATUS
-----------------
ACTIVE

7. 指定した表領域のバックアップ・モードを終了します。たとえば、表領域usersのバックアップ・モードを終了するには、次の文を入力します。

ALTER TABLESPACE users END BACKUP;

8. 通常のバックアップの場合と同様に、制御ファイルをコピーして、オンラインREDOログをアーカイブします。

関連項目:

- 「RMANを使用したミラーの分割によるバックアップの実行」

- SUSPEND/RESUME機能の詳細は、『Oracle Database管理者ガイド』を参照してください。

- ALTER SYSTEM SUSPENDの構文については、『Oracle Database SQL言語リファレンス』を参照してください。

RAWデバイスへのユーザー管理バックアップの作成

RAWデバイスとは、ファイル・システムを持たないディスクまたはパーティションです。RAWデバイスに保管できるファイルは1つのみです。RAWデバイスにファイルをバックアップする場合は、オペレーティング・システム固有の問題が発生します。後続の項では、UNIX、LinuxおよびWindowsでのこれらの問題の一部について説明します。

LinuxおよびUNIXでのRAWデバイスへのバックアップ

RAWデバイスとの間でバックアップを行う場合は、LinuxおよびUNIXのddコマンドが最も一般的なバックアップ・ユーティリティになります。このユーティリティの詳細は、オペレーティング・システムのマニュアルを参照してください。

ddを効率的に使用するには、ご使用のデータベースに基づいて適切なオプションを指定する必要があります。表28-1に、ddに使用するオプションに影響を及ぼすデータベースの詳細を示します。

表28-1 ddの使用に重要なデータベースの詳細

データ

説明

ブロック・サイズ

ddでデータのコピーに使用するバッファのサイズを指定できます。たとえば、ddで8KB単位または64KB単位でデータをコピーするように指定できます。ddのブロック・サイズは、Oracleのブロック・サイズまたはオペレーティング・システムのブロック・サイズに対応している必要のない、コピーを行うときにddで使用されるバッファのサイズです。

RAWオフセット

システムによっては、RAWデバイス上のファイルの最初の部分が、オペレーティング・システムの使用のために確保されていることがあります。この記憶領域をRAWオフセットと呼びます。これらのバイトをバックアップまたはリストアしないでください。

Oracle Databaseブロック0のサイズ

すべてのOracle Databaseファイルの最初の部分には、オペレーティング・システム固有のコードによって、ブロック0(ゼロ)と呼ばれるOracleブロックが配置されます。Oracle汎用コードはこのブロックを認識しませんが、このブロックは、オペレーティング・システム上でファイルのサイズに含められます。一般的にこのブロックは、ファイル中の他のOracleブロックと同じサイズになります。

表28-1の情報を使用して、表28-2に示すddオプションを設定できます。

表28-2 ddコマンドのオプション

オプション

指定

if

入力ファイル、つまり読み込むファイルの名前。

of

出力ファイル、つまり書き出すファイルの名前。

bs

ddでデータのコピーに使用されるバッファ・サイズ。

skip

RAWオフセットが存在する場合に、入力RAWデバイスでスキップするddバッファの数。たとえば、64KBのRAWオフセットを持つRAWデバイス上のファイルをバックアップする場合、ddバッファ・サイズが8KBのときは、skip=8と指定すると、64KBのオフセットからコピーを開始できます。

seek

RAWオフセットが存在する場合に、出力RAWデバイスでスキップするddバッファの数。たとえば、64KBのRAWオフセットを持つRAWデバイス上にファイルをバックアップする場合、ddバッファ・サイズが8KBのときは、skip=8と指定すると、64KBのオフセットからコピーを開始できます。

count

ddでコピーする、入力RAWデバイス上のブロックの数。RAWデバイスからファイル・システムにコピーするときには、コピーする正確なブロック数を指定するのが最良です。そうでない場合、Oracleデータファイルで使用されない、RAWボリュームの最後の余分な領域がファイル・システムにコピーされることになります。

入力ファイルの合計サイズにブロック0(ゼロ)を必ず含めてください。たとえば、ddブロック・サイズが8KBのとき、30720KBのデータファイルをバックアップする場合は、count=3841と設定できます。countにこの値を指定すると、実際には30728KBがバックアップされます。追加の8KBはOracleブロック0(ゼロ)用です。

RAWデバイスはバックアップの入力または出力デバイスに使用できるため、4つのバックアップ・シナリオを想定できます。ddで選択できるオプションは、表28-3に示すように、どのシナリオを選択するかによって異なります。

表28-3 ddバックアップのシナリオ

バックアップ元

バックアップ先

ddコマンドで指定されるオプション

RAWデバイス

RAWデバイス

if、of、bs、skip、seek、count

RAWデバイス

ファイル・システム

if、of、bs、skip、count

ファイル・システム

RAWデバイス

if、of、bs、seek

ファイル・システム

ファイル・システム

if、of、bs

LinuxおよびUNIXでのddユーティリティを使用したバックアップの例

この項で示すddユーティリティの使用方法の例では、次のように想定しています。

- 30720KBのデータファイルをバックアップします。

- データファイルの最初には8KBのブロック0(ゼロ)があります。

- RAWオフセットは64KBです。

- コピーにRAWデバイスが関係するときには、ddブロック・サイズを8KBに設定します。

次の例では、1つのRAWデバイスから別のRAWデバイスにバックアップします。

% dd if=/dev/rsd1b of=/dev/rsd2b bs=8k skip=8 seek=8 count=3841

次の例では、RAWデバイスからファイル・システムにバックアップします。

% dd if=/dev/rsd1b of=/backup/df1.dbf bs=8k skip=8 count=3841

次の例では、ファイル・システムからRAWデバイスにバックアップします。

% dd if=/backup/df1.dbf of=/dev/rsd2b bs=8k seek=8

次の例では、ファイル・システムからファイル・システムにバックアップし、ブロック・サイズに大きい値を設定してI/Oパフォーマンスを高めます。

% dd if=/oracle/dbs/df1.dbf of=/backup/df1.dbf bs=1024k

WindowsでのRAWデバイスへのバックアップ

WindowsはLinuxおよびUNIXと同じようにRAWディスク・パーティションをサポートするため、データファイル、オンライン・ログおよび制御ファイルをこの中に格納できます。 各RAWパーティションにはドライブ文字または物理ドライブ番号が割り当てられます。ファイル・システムは含まれません。LinuxおよびUNIXの場合と同じように、Windowsでも各RAWパーティションは1つのファイルにマップされます。

Windowsでは、Oracleファイルのネーミング規則はLinuxおよびUNIXの場合と異なります。Windowsの場合、RAWデータファイル名は次のような形式になります。

\\.\drive_letter:
\\.\PHYSICALDRIVEdrive_number

たとえば、次の名前はRAWファイル名として使用できます。

\\.\G:
\\.\PHYSICALDRIVE3

RAWデータファイルのユーザー管理バックアップを作成する手順は、Windowsで提供されるcopy.exeまたはntbackup.exeユーティリティのかわりにOracleのOCOPYユーティリティを使用する必要があることを除いて、Windowsファイル・システムでのファイルのコピーと基本的に同じです。OCOPYは64ビットのファイルI/O、物理RAWドライブおよびRAWファイルをサポートします。OCOPYユーティリティはテープに直接バックアップできません。

OCOPYのオンライン・マニュアルを表示するには、WindowsプロンプトにOCOPYとのみ入力します。出力例を次に示します。

Usage of OCOPY:
ocopy from_file [to_file [a | size_1 [size_n]]]
ocopy -b from_file to_drive
ocopy -r from_drive to_dir

表28-4に、OCOPYの重要なオプションを示します。

表28-4 OCOPYのオプション

オプション

処理

b

入力ファイルを複数の出力ファイルに分割します。このオプションは、入力ファイルよりも小さいデバイスにバックアップする場合に有効です。

r

複数の入力ファイルを組み合せて、1つの出力ファイルに書き込みます。このオプションは、-bオプションを指定して作成したバックアップをリストアする場合に有効です。

OCOPYを使用したバックアップの例

この例では、次のように想定しています。

- データファイル12はRAWパーティション\\.\G:にマウントされています。

- C:ドライブにファイル・システムをマウントしています。

- データベースはオープンしています。

RAWパーティション\\.\G:上のデータファイルをローカル・ファイル・システムにバックアップするには、データファイル12をバックアップ・モードにした後で、プロンプトで次のコマンドを実行します。

OCOPY "\\.G:" C:\backup\datafile12.bak

OCOPYの-bおよび-rオプションの指定の例

この例では、次のように想定しています。

- \\.\G:はデータファイル7を含むRAWパーティションです。

- E:ドライブは取り外し可能なディスク・ドライブです。

- データベースはオープンしています。

データファイルをドライブE:にバックアップするには、データファイル7をバックアップ・モードにした後で、Windowsプロンプトで次のコマンドを実行します。

# first argument is filename, second argument is drive
OCOPY -b "\\.\G:" E:\

ドライブE:が一杯になると、別のディスクを使用できます。この方法で、データファイル7のバックアップを複数のファイルに分割できます。

同様に、バックアップをリストアするときには、データファイル7を含む表領域をオフラインにし、次のコマンドを実行します。

# first argument is drive, second argument is directory
OCOPY -r E:\ "\\.\G:"

Volume Shadow Copy Service(VSS)を使用したバックアップの作成

Volume Shadow Copy Service(VSS)は、アプリケーションでシャドウ・コピーと呼ばれる一貫性のあるスナップショットの作成を可能にするWindows APIのセットです。Oracle VSSライターは、Windowsシステム上でのサービスとして実行され、VSS対応アプリケーションと統合されます。これらのアプリケーションを使用すると、Oracleインスタンスによって管理されているデータベース・ファイルのスナップショットを作成できます。たとえば、Oracle Databaseを読取り/書込みでオープンしている場合は、そのOracle Databaseデータベースのシャドウ・コピーを作成できます。

関連項目:
VSS対応アプリケーションでデータベースをバックアップおよびリカバリする方法については、『Oracle Databaseプラットフォーム・ガイドfor Microsoft Windows』を参照してください。

ユーザー管理データファイル・バックアップの検証

バックアップがリカバリに使用可能なものであることを確認するために、バックアップを定期的に検証する必要があります。

データファイル・バックアップのリストアのテスト

データファイル・バックアップの有効性を確認する最適な方法は、別のホストにバックアップをリストアして、必要に応じてメディア・リカバリを実行し、データベースのオープンを試行する方法です。このオプションでは、リストア手順のために別のホストを使用できる必要があります。

関連項目:
SQL*Plusでのファイルのリカバリ方法については、「データベースの完全リカバリの実行」を参照してください。

DBVERIFYユーティリティの実行

DBVERIFYプログラムは、オフライン・データファイルに対して物理的なデータ構造の整合性チェックを実行する、外部のコマンドライン・ユーティリティです。DBVERIFYは、リストア前にデータファイルのユーザー管理バックアップが有効かどうかを確認するために使用したり、データ破損の問題が発生した場合の診断ツールとして使用します。

DBVERIFYの名前と位置はオペレーティング・システムごとに異なります。たとえば、LinuxまたはUNIX上でデータファイルusers01.dbfの整合性チェックを実行する場合は、次のようにdbvコマンドを実行します。

% dbv file=users01.dbf

dbvの出力例を次に示します。

DBVERIFY - Verification starting : FILE = users01.dbf

DBVERIFY - Verification complete

Total Pages Examined         : 250
Total Pages Processed (Data) : 1
Total Pages Failing   (Data) : 0
Total Pages Processed (Index): 0
Total Pages Failing   (Index): 0
Total Pages Processed (Other): 2
Total Pages Processed (Seg)  : 0
Total Pages Failing   (Seg)  : 0
Total Pages Empty            : 247
Total Pages Marked Corrupt   : 0
Total Pages Influx           : 0

関連項目:
DBVERIFYについては、『Oracle Databaseユーティリティ』を参照してください。

29 ユーザー管理のデータベースのフラッシュバックおよびリカバリの実行

この章では、データベースをリストアおよびリカバリする方法、およびユーザー管理のバックアップおよびリカバリ計画でOracle Databaseのフラッシュバック機能を使用する方法について説明します。ユーザー管理のバックアップおよびリカバリ計画は、RMANを必要としない方法です。

この章の内容は次のとおりです。

- SQL*Plusでのデータベースのフラッシュバックの実行

- ユーザー管理のメディア・リカバリの概要

- データベースの完全リカバリの実行

- データベースの不完全リカバリの実行

- NOARCHIVELOGモードでのデータベースのリカバリ

- メディア・リカバリのトラブルシューティング

SQL*Plusでのデータベースのフラッシュバックの実行

Oracle Flashback Databaseを使用すると、バックアップからファイルをリストアせずに、データベース全体を元の状態に戻すことができます。SQL*PlusのFLASHBACK DATABASEコマンドの機能は、RMANのFLASHBACK DATABASEコマンドと同じです。このコマンドを実行すると、データベースが元の状態に戻されます。

フラッシュバック・データベースを使用する場合は、データベース用の高速リカバリ領域を作成し、フラッシュバック・ログの収集を有効にする必要があります。フラッシュバック・データベース機能の動作、フラッシュバック・データベースの使用要件およびフラッシュバック・データベースに必要なフラッシュバック・ログの収集を有効にする方法の詳細は、第18章「フラッシュバックおよびデータベースのPoint-in-Timeリカバリの実行」を参照してください。RMANまたはSQL*Plusのいずれを使用する場合でも、要件および準備は同じです。

SQL*Plusでデータベースのフラッシュバックを実行する手順

1. ターゲット・データベースを問い合せて、フラッシュバックのSCNの範囲を確認します。次のSQL*Plus問合せを実行して、フラッシュバック・ウィンドウの最初と最後のSCNを示します。

SELECT CURRENT_SCN FROM V$DATABASE;

SELECT OLDEST_FLASHBACK_SCN, OLDEST_FLASHBACK_TIME
FROM   V$FLASHBACK_DATABASE_LOG;

2. 必要に応じて他のフラッシュバック機能を使用し、データベースに対する不要な変更のSCNまたは時刻を確認します。

3. 管理者権限を使用してSQL*Plusを起動し、データベースをマウントします(ただし、オープンはしません)。

4. FLASHBACK DATABASE文を実行し、データベースを以前のTIMESTAMPまたはSCNまで戻します。次に例を示します。

FLASHBACK DATABASE TO SCN 46963;
FLASHBACK DATABASE TO TIMESTAMP '2002-11-05 14:00:00';
FLASHBACK DATABASE
TO TIMESTAMP to_timestamp('2002-11-11 16:00:00', 'YYYY-MM-DD HH24:MI:SS');

5. 操作が完了したら、データベースを読取り専用でオープンし、問合せを実行して必要なデータがリカバリされていることを確認します。
選択した目標時点が十分に前の時点でなかった場合は、別のFLASHBACK DATABASE文を使用します。それ以外の場合は、RECOVER DATABASEを使用してデータベースを現在の時点に戻し、別のFLASHBACK DATABASE文を実行します。

6. 結果が適切である場合は、RESETLOGSオプションを指定してデータベースをオープンします。
必要に応じて、データ・ポンプ・エクスポートを使用して消失したデータを保存し、RECOVER DATABASEでデータベースを現在の状態に戻して、消失したオブジェクトを再インポートすることもできます。

関連項目:
Oracle Flashback Query、Oracle Flashback Transaction Queryなどの関連フラッシュバック機能の使用方法については、『Oracle Databaseアドバンスト・アプリケーション開発者ガイド』を参照してください。

ユーザー管理のメディア・リカバリの概要

この項では、SQL*Plusを使用したリカバリの概要について説明します。この項の内容は、次のとおりです。

- ユーザー管理のリストアおよびリカバリ

- RECOVERコマンドを使用した自動リカバリ

- アーカイブ・ログがデフォルトの場所にある場合のリカバリ

- アーカイブ・ログがデフォルト以外の場所にある場合のリカバリ

- リカバリの取消し

- パラレル・メディア・リカバリ

ユーザー管理のリストアおよびリカバリ

通常、メディア障害またはユーザー・エラーによって複数のデータファイルが破損したり削除された場合に、ファイルをリストアします。ユーザー管理のリストア操作では、オペレーティング・システムのユーティリティを使用してファイルのバックアップをリストアします。

メディア障害がデータファイルに影響を与えた場合、リカバリの手順は次の条件によって異なります。

- データベースのアーカイブ・モード(ARCHIVELOGまたはNOARCHIVELOG)

- メディア障害のタイプ

- メディア障害によって影響されるファイル(データファイル、制御ファイル、アーカイブREDOログおよびサーバー・パラメータ・ファイルはすべてリストア操作の対象となります。)

永続的または一時的なメディア障害によって、NOARCHIVELOGモードで実行しているデータベースのデータファイルが影響を受けた場合、データベースは自動的に停止します。メディア障害が一時的な場合は、原因となっている問題を解決し、データベースを再起動します。通常、クラッシュ・リカバリによって、コミット済のすべてのトランザクションがオンラインREDOログを使用してリカバリされます。メディア障害が永続的な場合は、「NOARCHIVELOGモードでのデータベースのリカバリ」の説明に従ってデータベースをリカバリします。

表29-1に、ARCHIVELOGモードで実行されているデータベースでファイルを消失した場合に実行するメディア・リカバリについての説明を示します。

表29-1 ユーザー管理のリストア操作

消失したもの

現在の状態

SYSTEM表領域内のデータファイルまたはアクティブなUNDOセグメントを持つデータファイル

データベースは自動的に停止します。ハードウェアの問題が一時的な場合には、問題を解決し、データベースを再起動します。通常、クラッシュ・リカバリによって、消失したトランザクションがリカバリされます。ハードウェアの問題が永続的な場合は、「クローズしているデータベースのリカバリの実行」の説明に従って、バックアップからデータファイルをリストアし、データベースをリカバリします。

SYSTEM表領域内のものではないデータファイル、またはアクティブなロールバック・セグメントまたはUNDOセグメントを含まないデータファイル

影響を受けたデータファイルがオフライン化されますが、データベースはオープンしたままです。データベースの影響を受けていない部分を使用可能なままにしておく必要がある場合には、データベースを停止しないでください。一時オプションを使用して、問題が発生したデータファイルを含む表領域をオフラインにした後、「オープンしているデータベースのリカバリの実行」の説明に従ってリカバリします。

現行の制御ファイルのすべてのコピー

バックアップ制御ファイルをリストアし、RESETLOGSオプションを指定してデータベースをオープンする必要があります。

バックアップがない場合には、制御ファイルを再作成してください。可能であれば、ALTER DATABASE BACKUP CONTROLFILE TO TRACEの出力に含まれるスクリプトを使用します。制御ファイルの構造を現在のデータベース構造と一致させるために追加作業が必要になることがあります。

多重制御ファイルの1つのコピー

影響を受けていない多重制御ファイルの1つを破損または欠落した制御ファイルの場所にコピーして、データベースをオープンします。元の場所に制御ファイルをコピーできない場合は、初期化パラメータ・ファイルを編集して新しい場所を反映するか、または破損した制御ファイルを削除します。その後、データベースをオープンします。

メディア・リカバリに必要な1つ以上のアーカイブ・ログ

リカバリを実行するには、これらのアーカイブ・ログのバックアップをリストアする必要があります。デフォルトの場所またはデフォルト以外の場所にリストアできます。バックアップがない場合には、欠落している最初のREDOログの前のSCNまで不完全リカバリを実行し、RESETLOGSでオープンする必要があります。

サーバー・パラメータ・ファイル(SPFILE)

サーバー・パラメータ・ファイルのバックアップがある場合には、これをリストアします。また、クライアント側の初期化パラメータ・ファイルのバックアップがある場合には、このファイルのバックアップをリストアし、インスタンスを起動した後、サーバー・パラメータ・ファイルを再作成できます。

注意:
Oracle Managed Filesのリストアおよびリカバリは、ユーザーが名前を付けたファイルのリストアおよびリカバリと同じです。

メディア・リカバリの実行には、SQL*PlusのRECOVER文を使用することをお薦めします。SQL文のALTER DATABASE RECOVERも使用できますが、通常、RECOVER文を使用した方が簡単です。どのような種類のメディア・リカバリを開始する場合でも、次の制約に従う必要があります。

- 管理者権限が必要です。

- すべてのリカバリ・セッションが互換である必要があります。

- 別のセッションが不完全メディア・リカバリを実行しているときに、もう1つのセッションで完全メディア・リカバリを開始することはできません。

- 共有サーバー・プロセスを使用してデータベースに接続している場合は、メディア・リカバリを開始できません。

RECOVERコマンドを使用した自動リカバリ

SQL*Plusを使用してメディア・リカバリを実行する場合、最も簡単な方法は、SQL*PlusのRECOVERコマンドで自動リカバリを実行する方法です。自動リカバリでは、個々のアーカイブREDOログの適用についてSQL*Plusの手動プロンプトなしに、リカバリが開始されます。

SQL*Plusを使用する場合は、リカバリ時に必要となるアーカイブREDOログのデフォルト・ファイル名の適用を自動化するために、次のオプションを使用できます。

- RECOVERコマンドを発行する前にSET AUTORECOVERY ONを発行する。デフォルトであるSET AUTORECOVERY OFFを実行した場合は、ファイル名を手動で入力するか、[Enter]キーを押して、提示されたファイル名を受け入れる必要があります。

- RECOVERコマンドのオプションとしてAUTOMATICキーワードを指定する。

いずれの場合にも、必要なファイルが正しい場所に正しい名前で存在しているかぎりRECOVERコマンドを発行したときに介入は必要ありません。データベースでREDOログ・ファイルが正常に適用された場合は、次のメッセージが戻されます。

Log applied.

その後、順序内の次のREDOログを求めるプロンプトが表示されます。最後に適用されたログが最後の必要なログである場合は、リカバリが終了します。

自動リカバリに使用されるファイル名は、LOG_ARCHIVE_FORMATの値とLOG_ARCHIVE_DEST_nの値を連結して導出されます。このnは、有効なすべてのローカル出力先の中で最大の値です。たとえば、データベース・インスタンスで初期化パラメータの次のような設定が有効になっているとします。

LOG_ARCHIVE_DEST_1 = "LOCATION=/arc_dest/loc1/"
LOG_ARCHIVE_DEST_2 = "LOCATION=/arc_dest/loc2/"
LOG_ARCHIVE_DEST_STATE_1 = DEFER
LOG_ARCHIVE_DEST_STATE_2 = ENABLE
LOG_ARCHIVE_FORMAT = arch_%t_%s_%r.arc

この場合、SQL*Plusは自動的に/arc_dest/loc2/arch_%t_%s_%r.arcというファイル名を提示します(この%tはスレッド、%sは順序、%rはRESETLOGのIDです)。

SET AUTORECOVERYを使用した自動リカバリ

データファイル・バックアップをリストアした後、SET AUTORECOVERY ONコマンドを実行すると、自動リカバリが有効になります。たとえば、SQL*Plusに次のコマンドを入力すると、自動リカバリを実行し、データベースをオープンできます。

STARTUP MOUNT
SET AUTORECOVERY ON
RECOVER DATABASE
ALTER DATABASE OPEN;

注意:
SQL*PlusのRECOVERコマンドを発行した後で、リカバリで考慮されたすべてのファイルをV$RECOVERY_FILE_STATUSビューで表示できます。V$RECOVERY_STATUSビューで、各ファイルのステータス情報にアクセスできます。これらのビューは、リカバリ・セッションの終了後はアクセスできません。

RECOVERコマンドのAUTOMATICオプションを使用した自動リカバリ

SET AUTORECOVERYを使用して自動リカバリを有効にする他にも、RECOVERコマンドでAUTOMATICキーワードを指定することもできます。たとえば、SQL*Plusに次のコマンドを入力すると、自動リカバリを実行し、データベースをオープンできます。

STARTUP MOUNT
RECOVER AUTOMATIC DATABASE
ALTER DATABASE OPEN;

Oracle Real Application Clusters構成を使用しているとき、ユーザーが不完全リカバリを実行するか、またはバックアップ制御ファイルを使用する場合は、最初のREDOスレッドから最初のアーカイブREDOログ・ファイルの名前を算出することのみが可能です。その他のREDOスレッドからは、最初のログ・ファイルを手動で適用する必要があります。特定のスレッド内の最初のログ・ファイルが提供されると、データベースは、このスレッド内の後続のログの名前を提示できます。

アーカイブ・ログがデフォルトの場所にある場合のリカバリ

アーカイブ・ログがデフォルトの場所にある場合のリカバリは、最も簡単です。ログが必要になると、ファイル名が提示されます。SQL*Plusを使用して、自動ではないメディア・リカバリを実行する場合には、出力は次の形式で表示されます。

ORA-00279: change 53577 generated at 11/26/02 19:20:58 needed for thread 1
ORA-00289: suggestion : /oracle/oradata/trgt/arch/arcr_1_802.arc
ORA-00280: change 53577 for thread 1 is in sequence #802
Specify log: [<RET> for suggested | AUTO | FROM logsource | CANCEL ]

ALTER DATABASE ... RECOVER文を使用した場合にも、同様のメッセージが戻されます。ただし、プロンプトは表示されません。

初期化パラメータLOG_ARCHIVE_DEST_n(このnは有効なすべてのローカル出力先の中で最大の値)およびLOG_ARCHIVE_FORMATの現在の値を連結し、制御ファイルのログ履歴情報を使用して、提示されるアーカイブ・ログのファイル名が構築されます。次のような設定が可能です。

LOG_ARCHIVE_DEST_1 = 'LOCATION = /oracle/oradata/trgt/arch/'
LOG_ARCHIVE_FORMAT = arcr_%t_%s.arc

SELECT NAME FROM V$ARCHIVED_LOG;

NAME
----------------------------------------
/oracle/oradata/trgt/arch/arcr_1_467.arc
/oracle/oradata/trgt/arch/arcr_1_468.arc
/oracle/oradata/trgt/arch/arcr_1_469.arc

このため、すべての必要なアーカイブ・ログ・ファイルがLOG_ARCHIVE_DEST_1という出力先にマウントされ、LOG_ARCHIVE_FORMATの値が変更されていない場合は、ログ・ファイルが提示および適用され、メディア・リカバリが自動的に実行されます。

アーカイブ・ログがデフォルト以外の場所にある場合のリカバリ

アーカイブ・ログがデフォルトの場所にない場合にメディア・リカバリを実行するには、追加の処理が必要です。次のいずれかの方法を選択します。

- アーカイブREDOログの場所を指定するLOG_ARCHIVE_DEST_nパラメータを編集し、通常どおりにリカバリします。

- リカバリ前にSQL*PlusのSET文を使用してデフォルト以外のログの場所を指定するか、RECOVERコマンドのLOGFILEパラメータを使用します。

アーカイブ・ログの場所の再設定

初期化パラメータ・ファイルを編集するか、ALTER SYSTEM文を発行して、アーカイブREDOログのデフォルトの場所を変更できます。

リカバリ前にアーカイブ・ログのデフォルトの場所を変更する手順

1. オペレーティング・システム・ユーティリティを使用して、アーカイブ・ログをデフォルト以外の場所にリストアします。たとえば、次のように入力します。

% cp /backup/arch/* /tmp/

2. アーカイブ・ログ・パラメータの値を、デフォルト以外の場所に変更します。インスタンスが起動されているときにALTER SYSTEM文を発行するか、初期化パラメータ・ファイルを編集した後にデータベース・インスタンスを起動します。たとえば、インスタンスの停止中にパラメータ・ファイルを次のように編集します。

LOG_ARCHIVE_DEST_1 = 'LOCATION=/tmp/'
LOG_ARCHIVE_FORMAT = arcr_%t_%s.arc

3. SQL*Plusを使用して、編集済の初期化パラメータ・ファイルを指定して新しいインスタンスを起動した後、データベースをマウントします。たとえば、次のように入力します。

STARTUP MOUNT

4. 通常どおりにメディア・リカバリを開始します。たとえば、次のように入力します。

RECOVER DATABASE

アーカイブ・ログの場所の変更

場合によっては、アーカイブの出力先パラメータの現在の設定を変更して、アーカイブ・ログ・ファイルの入力元を変更することもできます。

SET LOGSOURCEを使用して、デフォルト以外の場所のアーカイブ・ログをリカバリする手順

1. オペレーティング・システム・ユーティリティを使用して、アーカイブREDOログを代替の場所にコピーします。たとえば、次のように入力します。

% cp $ORACLE_HOME/oradata/trgt/arch/* /tmp

2. SQL*Plus内でリカバリ操作のための代替場所を指定します。SET文のLOGSOURCEパラメータを使用します。たとえば、SQL*Plusを起動して次のように実行します。

SET LOGSOURCE "/tmp"

3. オフライン表領域をリカバリします。たとえば、オフライン表領域usersをリカバリするには、次のコマンドを実行します。

RECOVER AUTOMATIC TABLESPACE users

4. また、SET LOGSOURCEを実行せずに、次のコマンドを実行することもできます。

RECOVER AUTOMATIC TABLESPACE users FROM "/tmp"

注意:
REDOログのソースを変更しても、アーカイブされているオンラインREDOログ・グループのアーカイブREDOログの出力先は影響を受けません。

リカバリの取消し

メディア・リカバリを開始した後で中断する必要がある場合は、REDOログ・ファイルのプロンプトに対してCANCELと入力します。また、個々のデータファイルのリカバリの実行時または自動リカバリの実行時に終了する必要がある場合は、オペレーティング・システムの割込みシグナルを使用します。リカバリが取り消された後、RECOVERコマンドを使用してリカバリを再開できます。リカバリは、取り消された位置から再開されます。

パラレル・メディア・リカバリ

Oracle Databaseは、メディア・リカバリのロールフォワード・フェーズのパフォーマンスを向上するために、デフォルトでパラレル・メディア・リカバリを使用します。メディアのパラレル・リカバリでは、ロールフォワード時に各データ・ブロックに別のプロセスを割り当てる分業体制を使用することで、処理の効率を高めています。使用されるプロセスの数は、CPU_COUNT初期化パラメータで指定されます。これは、デフォルトではシステム上のCPUの数と同じです。たとえば、CPU_COUNTが4のシステム上でパラレル・リカバリを実行した場合、リカバリ対象のデータファイルが1つのみである場合には、4つの起動されたプロセスがアーカイブ・ログからブロックを読み取り、REDOを適用します。

一般的に、メディア・リカバリはデータ・ブロックの読取りおよび書込みによって制限されます。パラレル・リカバリでは、パフォーマンスを向上させるために、システムで利用可能なI/O帯域幅がすべて使用されます。システムのI/Oボトルネックが存在するか、非同期I/Oが十分にサポートされていない場合を除いて、パラレル・リカバリによってリカバリのパフォーマンスが向上する可能性があります。

パラレル・リカバリが実行されるデフォルトの動作を変更するには、NOPARALLELオプションを指定してSQL*PlusのRECOVERコマンドを使用するか、またはRECOVER PARALLEL 0を使用します。RECOVERY_PARALLELISM初期化パラメータでは、インスタンス・リカバリまたはクラッシュ・リカバリのみが制御されます。メディア・リカバリは、RECOVERY_PARALLELISMで使用される値の影響を受けません。

関連項目:
SQL*PlusのRECOVER ... PARALLELおよびNOPARALLELコマンドの詳細は、『SQL*Plusユーザーズ・ガイドおよびリファレンス』を参照してください。

データベースの完全リカバリの実行

通常、メディア障害によって1つ以上のデータファイルにアクセスできなくなった場合に、データベースの完全リカバリを実行します。V$RECOVER_FILEビューに、リカバリが必要なファイルが示されます。データベースの完全リカバリを実行する場合は、使用可能なすべてのREDOを使用し、データベースを現行のSCNまでリカバリします。

状況に応じて、データベース全体で一度にリカバリを実行することも、個々の表領域またはデータファイルでリカバリを実行することもできます。完全リカバリの場合は、RESETLOGSオプションを指定してデータベースをオープンする必要はないため、最初に一部のデータファイルのリカバリを行ってから、後で残りのデータファイルのリカバリを行うこともできます。

この項の手順では、次のことが想定されています。

- 現行の制御ファイルが使用可能です。制御ファイルをリストアまたは再作成する必要がある場合は、「現行の制御ファイルがすべて消失した場合のリカバリ」および「制御ファイルの再作成」を参照してください。

- 必要なすべてのデータファイルのバックアップがあります。データファイルのバックアップが欠落している場合は、「バックアップが利用できない場合のデータファイルの再作成」を参照してください。

- 必要なすべてのアーカイブREDOログが使用可能です。データベースを完全にリカバリするために必要なREDOが欠落している場合は、データベースのPoint-in-Timeリカバリを実行する必要があります。詳細は、「データベースの不完全リカバリの実行」を参照してください。

この項では、完全メディア・リカバリ操作に必要な手順について説明します。この項の内容は、次のとおりです。

- クローズしているデータベースのリカバリの実行

- オープンしているデータベースのリカバリの実行

クローズしているデータベースのリカバリの実行

この項では、データベースをオープンしていないときに完全リカバリを実行する手順について説明します。破損したすべてのデータファイルに対して一度にリカバリ操作を実行することも、破損した個々のデータファイルに対して個別にリカバリ操作を実行することもできます。

破損または欠落しているデータファイルをリストアおよびリカバリする手順

1. データベースがオープンしている場合は、V$RECOVER_FILEを問い合せ、リカバリする必要があるデータファイルおよびリカバリする必要がある理由を確認します。

Point-in-Timeリカバリではなく完全リカバリの実行を計画している場合は、データベース全体ではなくリカバリが必要なデータファイルのみをリカバリすることができます。Point-in-Timeリカバリでは、TSPITRを実行しないかぎり、すべてのデータファイルをリストアおよびリカバリする必要があります(第21章「RMANの表領域のPoint-in-Timeリカバリ(TSPITR)の実行」を参照)。また、フラッシュバック・データベースも使用できますが、すべてのデータファイルが影響を受けるため、データベース全体が過去の状態に戻ります。

V$RECOVER_FILEビューを問い合せると、リカバリが必要なデータファイルを、そのステータス情報とエラー情報とともにデータファイル番号で表示できます。

SELECT FILE#, ERROR, ONLINE_STATUS, CHANGE#, TIME
FROM   V$RECOVER_FILE;

注意:
V$RECOVER_FILEは、バックアップからリストアされた制御ファイル、またはデータファイルに影響を及ぼすメディア障害の発生後に再作成された制御ファイルには使用できません。リストアされた制御ファイルまたは再作成された制御ファイルには、V$RECOVER_FILEを正確に更新するために必要な情報が含まれていません。

データファイル番号とV$DATAFILEおよびV$TABLESPACEビューを使用することによって便利な結合を実行して、データファイルおよび表領域の名前を取得することもできます。次のSQL*Plusコマンドを使用して、問合せの出力の書式を設定します。

COL DF# FORMAT 999
COL DF_NAME FORMAT A35
COL TBSP_NAME FORMAT A7
COL STATUS FORMAT A7
COL ERROR FORMAT A10
COL CHANGE# FORMAT 99999999
SELECT r.FILE# AS df#, d.NAME AS df_name, t.NAME AS tbsp_name,
d.STATUS, r.ERROR, r.CHANGE#, r.TIME
FROM   V$RECOVER_FILE r, V$DATAFILE d, V$TABLESPACE t
WHERE  t.TS# = d.TS#
AND    d.FILE# = r.FILE#;

ERROR列で、リカバリが必要な各ファイルに関する問題を識別します。

2. V$ARCHIVED_LOGおよびV$RECOVERY_LOGビューを問い合せて、必要なアーカイブREDOログ・ファイルを確認します。
V$ARCHIVED_LOGには、すべてのアーカイブREDOログのファイル名が表示されます。V$RECOVERY_LOGには、データベースでメディア・リカバリを実行する必要があるアーカイブREDOログのみが表示されます。後者のビューには、LOG_ARCHIVE_FORMATパラメータを使用して指定したネーミング規則に基づいて、考えられるファイルの名前も表示されます。

注意:
V$RECOVERY_LOGは、データファイルのメディア・リカバリが必要な場合にのみ移入されます。このため、ユーザー・エラーからのリカバリなど、計画されたリカバリにはこのビューは役に立ちません。
データファイルのリカバリが必要な場合に、データファイルのバックアップが存在しないときは、データベースにデータファイルが追加された後に生成されたすべてのREDOが必要です。

3. デフォルトの場所ですべてのアーカイブ・ログが使用可能な場合は、手順4にスキップします。

一部のアーカイブ・ログをリストアする必要があるときに、使用可能な領域が十分にある場合は、LOG_ARCHIVE_DEST_1で指定された場所に必要なアーカイブREDOログ・ファイルをリストアします。メディア・リカバリ中に正しいログが必要になると、自動的にログが検索されます。たとえば、LinuxまたはUNIXでは、次のコマンドを入力します。

% cp /disk2/arch/* $ORACLE_HOME/oradata/trgt/arch

使用可能な領域が十分にない場合は、必要なアーカイブREDOログ・ファイルの一部またはすべてを別の場所にリストアします。

4. データベースがオープンしている場合は、データベースを停止します。次に例を示します。

SHUTDOWN IMMEDIATE

5. メディアを検査して問題の原因を確認します。
メディア障害の原因であるハードウェアの問題が一時的なもので、データが破損していない場合(ディスクやコントローラの停電が発生した場合など)は、メディア・リカバリは必要ありません。データベースを起動して、通常の操作を再開します。

問題を解決できない場合は、手順6に進みます。

6. ファイルが永続的な損傷を受けた場合には、破損したファイルの最新のバックアップを識別します。メディア障害によって破損したデータファイルのみをリストアします。破損していないデータファイルまたはオンラインREDOログ・ファイルはリストアしないでください。
たとえば、破損したファイルがORACLE_HOME/oradata/trgt/users01.dbfのみであり、このファイルの最新のバックアップが/backup/users01_10_24_02.dbfであるとします。特定のデータファイルのバックアップがない場合には、リカバリするための空の置換ファイルを作成できます。

7. オペレーティング・システム・ユーティリティを使用して、デフォルトの場所または新しい場所にデータファイルをリストアします。たとえば、LinuxまたはUNIXユーザーがusers01.dbfをデフォルトの場所にリストアする場合は、次のコマンドを入力できます。

% cp /backup/users01_10_24_06.dbf $ORACLE_HOME/oradata/trgt/users01.dbf

次のガイドラインに従って、データファイルのバックアップをリストアする場所を決定します。

- ハードウェアの問題が解決され、デフォルトの場所にデータファイルをリストアできる場合は、デフォルトの場所にデータファイルをリストアし、メディア・リカバリを開始します。

- ハードウェアの問題が持続し、元の場所にデータファイルをリストアできない場合は、代替のストレージ・デバイスにデータファイルをリストアします。ALTER DATABASE RENAME FILE文を使用して、これらのファイルの新しい場所を制御ファイルで指定します。『Oracle Database管理者ガイド』を参照してください。

- データファイルをRAWディスクまたはRAWパーティションにリストアする場合の方法は、ファイル・システム上のファイルにリストアする場合と基本的に同じです。ただし、RAWデバイス上のファイルのネーミング規則(オペレーティング・システムよって異なる)に注意して、RAWデバイスをサポートするオペレーティング・システム・ユーティリティを使用する必要があります。

8. 管理者権限でデータベースに接続します。新しいインスタンスを起動して、データベースをマウントします(ただし、オープンはしません)。たとえば、次のように入力します。

STARTUP MOUNT

9. 1つ以上の破損したデータファイルを代替の場所にリストアした場合は、データベースの制御ファイルを更新して、新しいデータファイル名を反映させます。たとえば、表領域usersのデータファイルのファイル名を変更するには、次のように入力します。

ALTER DATABASE RENAME FILE '?/oradata/trgt/users01.dbf' TO
'/disk2/users01.dbf';

10. 現行の制御ファイルに通常付随するデータファイルのリストを調べるか、V$DATAFILEビューを問い合せて、すべてのデータファイルのデータファイル名およびステータスを取得します。たとえば、次のように入力します。

SELECT NAME,STATUS FROM V$DATAFILE;

11. リカバリが必要なすべてのデータファイルがオンラインにされていることを確認します。唯一の例外は、NORMALモードでオフラインにされたオフライン表領域内のデータファイルまたは読取り専用表領域内のデータファイルです。たとえば、/oracle/dbs/tbs_10.fという名前のデータファイルを確実にオンラインにするには、次のように入力します。

ALTER DATABASE DATAFILE '/oracle/dbs/tbs_10.f' ONLINE;

指定されたデータファイルがすでにオンラインにされている場合は、この文は無視されます。次の例のような、すべてのデータファイルを一度にオンラインにするスクリプトを作成することもできます。

SPOOL onlineall.sql
SELECT 'ALTER DATABASE DATAFILE '''||name||''' ONLINE;' FROM V$DATAFILE;
SPOOL OFF

SQL> @onlineall

12. アーカイブREDOログを代替格納場所にリストアした場合は、SQL*Plusで SETコマンドのLOGSOURCEパラメータを使用して、メディア・リカバリの前の場所を特定できます。たとえば、ログが/tmp内にステージングされている場合は、次のコマンドを入力できます。

SET LOGSOURCE /tmp

あるいは、手順12をスキップして、手順13に示すようにRECOVERコマンドでFROMパラメータを使用します。たとえば、ログが/tmp内にステージングされている場合は、次のコマンドを入力できます。

RECOVER AUTOMATIC FROM '/tmp' DATABASE

注意:
REDOログのソースを変更しても、アーカイブされているオンラインREDOログ・グループのアーカイブREDOログの出力先は影響を受けません。

13. データベース、表領域またはデータファイルのリカバリのための文を発行します。たとえば、次のいずれかのRECOVERコマンドを入力します。

RECOVER AUTOMATIC DATABASE   # whole database
RECOVER AUTOMATIC TABLESPACE users   # specific tablespace
RECOVER AUTOMATIC DATAFILE '?/oradata/trgt/users01.dbf'; # specific data file

アーカイブREDOログの適用を自動化しない場合は、ログが提示されるたびに、そのログを適用するかどうかを選択する必要があります。リカバリを自動化した場合は、ログは自動的に適用されます。必要なすべてのアーカイブおよびオンラインREDOログが、リストアされたデータファイルに適用されるまで、リカバリは続行されます。メディア・リカバリが完了すると、次のように通知されます。

Media recovery complete.

完全メディア・リカバリにアーカイブREDOログ・ファイルが必要でない場合は、必要なすべてのオンラインREDOログ・ファイルが適用され、リカバリが終了します。

14. リカバリ完了後に、データベースをオープンして使用します。

ALTER DATABASE OPEN;

関連項目:
REDOログ・ファイルの適用の詳細は、「ユーザー管理のメディア・リカバリの概要」および『Oracle Databaseリファレンス』を参照してください。

15. アーカイブ・ログを適用し、オフライン・ストレージに各アーカイブ・ログ・グループのコピーがまだ存在していることを確認した後、アーカイブREDOログ・ファイルのリストアされたコピーを削除してディスク領域を解放します。たとえば、次のように入力します。

% rm /tmp/*.arc

関連項目:
メディア・リカバリ中のログの適用の概要は、「ユーザー管理のメディア・リカバリの概要」を参照してください。

オープンしているデータベースのリカバリの実行

データベースをオープンしているときにメディア障害が発生した場合は、破損していないデータファイルはオンラインのまま使用できる場合があります。データベース・ライターがファイルに書き込めない場合は、破損したファイルは自動的にオフラインにされますが、破損したファイルを含む表領域はオフラインにされません。データベース・ライターがデータファイルをオープンできない場合は、引き続きエラーが戻されます。破損したファイルを読み取れない問合せはエラーを戻しますが、問合せが失敗したためにデータファイルがオフラインにされることはありません。たとえば、SQL問合せを実行すると、次のような出力が表示される場合があります。

ERROR at line 1:
ORA-01116: error in opening database file 3
ORA-01110: data file 11: '/oracle/oradata/trgt/cwmlite02.dbf'
ORA-27041: unable to open file
SVR4 Error: 2: No such file or directory
Additional information: 3

データベースのオープン中は、この項の手順を使用してSYSTEM表領域の完全メディア・リカバリを実行することはできません。メディア障害によってSYSTEM表領域のデータファイルが破損した場合は、データベースは自動的に停止します。

オープン状態のデータベースでデータファイルをリストアする手順

1. 「クローズしているデータベースのリカバリの実行」の手順1から3を実行します。

2. データベースがオープンしている場合は、破損したデータファイルを含むすべての表領域をオフラインにします。たとえば、破損したデータファイルが表領域usersおよびtoolsに含まれている場合は、次のSQL文を実行します。

ALTER TABLESPACE users OFFLINE TEMPORARY;
ALTER TABLESPACE tools OFFLINE TEMPORARY;

TEMPORARYを指定すると、Oracle Databaseによって、表領域内のすべてのオンライン・データファイルに対してチェックポイントが作成されます。この文の発行時にオフラインであるファイルでは、表領域をオンラインに戻す前に、メディア・リカバリが必要な場合があります。IMMEDIATEを指定すると、表領域をオンラインに戻す前に、表領域に対してメディア・リカバリを実行する必要があります。

3. メディアを検査して問題の原因を確認します。
DBVERIFYユーティリティを使用すると、オフライン・データファイルに対して整合性チェックを実行できます(「DBVERIFYユーティリティの実行」を参照)。

メディア障害の原因であるハードウェアの問題が一時的なもので、データが破損していない場合、メディア・リカバリは必要ありません。オフライン表領域をオンラインにし、通常の操作を再開することができます。問題を解決できない場合、またはDBVERIFYによって破損ブロックがレポートされた場合は、手順4に進みます。

4. ファイルが永続的に破損された場合は、オペレーティング・システム・コマンドを使用して、メディア障害によって破損されたデータファイルのみの最新のバックアップ・ファイルをリストアします。たとえば、データファイルusers01.dbfをリストアするには、LinuxまたはUNIXでcpコマンドを次のように実行します。

% cp /disk2/backup/users01.dbf $ORACLE_HOME/oradata/trgt/users01.dbf

ハードウェアの問題が解決され、データファイルを元の場所にリストアできる場合は、その場所にリストアします。それ以外の場合は、代替のストレージ・デバイスにデータファイルをリストアします。破損していないデータファイル、オンラインREDOログまたは制御ファイルはリストアしないでください。

注意:
状況によっては、特定のデータファイルのバックアップがない場合に、ALTER DATABASE CREATE DATAFILE文を使用して、リカバリ可能な空の置換ファイルを作成できることもあります。

5. 1つ以上の破損したデータファイルを代替の場所にリストアした場合は、データベースの制御ファイルを更新して、新しいデータファイル名を反映させます。たとえば、表領域usersのデータファイルのファイル名を変更するには、次のように入力します。

ALTER DATABASE RENAME FILE '?/oradata/trgt/users01.dbf' TO
'/disk2/users01.dbf';

6. アーカイブREDOログを代替格納場所にリストアした場合は、SQL*Plusで SETコマンドのLOGSOURCEパラメータを使用して、メディア・リカバリの前の場所を特定できます。たとえば、ログが/tmp内にステージングされている場合は、次のコマンドを入力できます。

SET LOGSOURCE /tmp

あるいは、手順6をスキップして、手順7に示すようにRECOVERコマンドでFROMパラメータを使用します。たとえば、ログが/tmp内にステージングされている場合は、次のコマンドを入力できます。

RECOVER AUTOMATIC FROM '/tmp' TABLESPACE users, tools;

注意:
REDOログのソースを変更しても、アーカイブされているオンラインREDOログ・グループのアーカイブREDOログの出力先は影響を受けません。

7. 管理者権限を使用してデータベースに接続します。一度の手順で、1つ以上のオフライン表領域の破損したすべてのデータファイルについて、オフライン表領域のリカバリを開始します。 たとえば、usersおよびtoolsのリカバリを行うには、次のように入力します。

RECOVER AUTOMATIC TABLESPACE users, tools;

必要なアーカイブREDOログおよびオンラインREDOログが適用され、リストアしたデータファイルが再構築されて、メディア・リカバリのロールフォワード・フェーズが開始されます。RECOVER AUTOMATICまたはSET AUTORECOVERY ONによってファイルの適用が自動化されていないかぎり、必要なREDOログ・ファイルごとにプロンプトが表示されます。

必要なすべてのアーカイブ・ログがデータファイルに適用されるまで、リカバリは続行されます。次に、オンラインREDOログがリストアされたデータファイルに自動的に適用され、メディア・リカバリが完了します。完全メディア・リカバリにアーカイブREDOログが必要ない場合は、プロンプトは表示されません。かわりに、必要なすべてのオンラインREDOログが適用され、メディア・リカバリが完了します。

8. 破損した表領域をメディア障害が発生した時点までリカバリできたら、オフラインの表領域をオンラインにします。たとえば、表領域usersおよびtoolsをオンラインにするには、次の文を発行します。

ALTER TABLESPACE users ONLINE;
ALTER TABLESPACE tools ONLINE;

関連項目:
データファイルを作成する方法については、『Oracle Database管理者ガイド』を参照してください。ALTER DATABASE RENAME FILEについては、『Oracle Database SQL言語リファレンス』を参照してください。

データベースの不完全リカバリの実行

通常、次のような場合にデータベースのPoint-in-Timeリカバリ(DBPITR)を実行します。

- ユーザー・エラーまたは管理エラーの前のSCNまでデータベースをリカバリする場合。

- データベースに破損ブロックが含まれている場合。

- 必要なすべてのアーカイブREDOログが使用可能ではなかったためデータベースの完全リカバリに失敗した場合。

- 本番データベース・バックアップからテスト・データベースまたはレポート・データベースを作成する場合。

データベースをARCHIVELOGモードで実行しているときに、アーカイブREDOログ・ファイルの唯一のコピーが破損した場合には、破損したファイルが、データベースの現在の動作に影響を与えることはありません。表29-2に、REDOログが書き込まれた場合、およびデータファイルをバックアップした場合に応じて発生する可能性がある状況を示します。

表29-2 アーカイブREDOログの消失

バックアップ対象

現在の状態

一杯になったオンラインREDOログ・グループ(現在アーカイブされている)が書き込まれた後のすべてのデータファイル

完全メディア・リカバリに、一杯になったオンラインREDOログ・グループのアーカイブされたバージョンは必要ありません。

一杯になったオンラインREDOログ・グループが書き込まれる前の特定のデータファイル

対応するデータファイルが永続的なメディア障害によって破損した場合は、破損したデータファイルの最新のバックアップを使用して、破損したアーカイブREDOログ・ファイルに至るまで、破損したデータファイルの表領域のPoint-in-Timeリカバリを実行します。

注意:
アーカイブREDOログ・グループが破損したことがわかっている場合は、破損したアーカイブREDOログを必要としない、データベース全体のバックアップを作成するために、すぐにすべてのデータファイルをバックアップします。

DBPITRでの方法は、特定の時刻またはSCNを指定するか、あるいはCANCELと入力することによって終了する点以外は、「クローズしているデータベースのリカバリの実行」に示す方法と非常に類似しています。取消しベースのリカバリでは、アーカイブREDOログ・ファイルの推奨ファイル名がプロンプトに表示されます。ユーザーがファイル名のかわりにCANCELを指定するか、すべてのREDOがデータファイルに適用されると、リカバリは停止します。リカバリを終了するアーカイブ・ログを制御する場合は、取消しベースのリカバリが最適な方法です。

この項の手順では、次のことが想定されています。

- 現行の制御ファイルが使用可能です。制御ファイルをリストアまたは再作成する必要がある場合は、「現行の制御ファイルがすべて消失した場合のリカバリ」を参照してください。

- 必要なすべてのデータファイルのバックアップがあります。データファイルのバックアップが欠落している場合は、「バックアップが利用できない場合のデータファイルの再作成」を参照してください。

この項の内容は、次のとおりです。

- 取消しベースの不完全リカバリの実行

- 時間ベースまたは変更ベースの不完全リカバリの実行

取消しベースの不完全リカバリの実行

取消しベースのリカバリでは、ユーザーに対してアーカイブREDOログ・ファイルのファイル名を提示するプロンプトを表示して、リカバリが進行していきます。ユーザーがファイル名のかわりにCANCELを指定するか、すべてのREDOがデータファイルに適用されると、リカバリは停止します。

取消しベースのリカバリを実行する手順

1. 「クローズしているデータベースのリカバリの実行」の手順1から8を実行します。

2. SQL*Plusで次のコマンドを発行し、取消しベースのリカバリを開始します。

RECOVER DATABASE UNTIL CANCEL

注意:
RECOVERコマンドのUNTIL句を指定しなかった場合は、完全リカバリを実行するとみなされ、すべてのREDOが適用されるまではデータベースをオープンできません。

リストアしたデータファイルを再構築するために必要なREDOログ・ファイルが適用されます。 データベースは、LOG_ARCHIVE_DEST_1から検索する名前を提示します。ユーザーは、そのログ・ファイルを適用するかどうかの決定を求められます。制御ファイルがバックアップの場合は、オンラインREDOログの変更を適用する場合、オンラインREDOログの名前を指定する必要があります。

3. リストアされたデータファイルに最後のログが適用されるまで、REDOログ・ファイルの適用を続けた後、次のコマンドを実行して、リカバリを取り消します。

CANCEL

リカバリが成功したかどうかが示されます。すべてのデータファイルが整合性のあるSCNまでリカバリされる前にリカバリを取り消し、その後データベースをオープンしようとすると、さらにリカバリが必要な場合は、ORA-1113エラーが表示されます。V$RECOVER_FILEを問い合せると、さらにリカバリが必要かどうか、または不完全リカバリの開始前にデータファイルのバックアップがリストアされていなかったかどうかを確認できます。

4. RESETLOGSオプションを指定してデータベースをオープンします。不完全リカバリまたはバックアップ制御ファイルを使用したリカバリの後は、ログをリセットする必要があります。次に例を示します。

ALTER DATABASE OPEN RESETLOGS;

ログのリセットが不適切な状況でOPEN RESETLOGSを使用しようとした場合、またはログをリセットする必要がある状況でログをリセットしなかった場合はエラーが戻され、データベースはオープンされません。問題を解決して再試行してください。

関連項目:
ALTER DATABASE OPEN RESETLOGSが正常に実行されない原因については、「ユーザー管理のメディア・リカバリの問題」を参照してください。

5. RESETLOGSオプションを使用してデータベースをオープンした後、アラート・ログを確認します。

注意:
トレース・ファイルおよびアラート・ログの場所を特定する最も簡単な方法は、SQL問合せSELECT NAME, VALUE FROM V$DIAG_INFOを実行する方法です。

RESETLOGSオプションを指定してオープンした場合は、リカバリが完全か不完全かによって、戻されるメッセージが異なります。完全リカバリの場合は、アラート・ログに次のメッセージが表示されます。

RESETLOGS after complete recovery through change scn

不完全リカバリの場合は、アラート・ログに次のメッセージが表示されます。ここで、scnは、不完全リカバリの終了位置を表します。

RESETLOGS after incomplete recovery UNTIL CHANGE scn

また、アラート・ログも確認して、データ・ディクショナリと制御ファイルの間の矛盾がデータベースで検出されていないかを調べます。表29-3に、2つの例を示します。

表29-3 データ・ディクショナリと制御ファイルの間の矛盾

制御ファイルに示されているデータファイル

データ・ディクショナリに示されているデータファイル

結果

あり

なし

示されていないデータファイルへの参照が、制御ファイルから削除されます。アラート・ログのメッセージに、検出された内容が表示されます。

なし

あり

制御ファイルのMISSINGnnnnnの項(nnnnnは10進数で示したファイル番号)に、プレースホルダ・エントリが作成されます。制御ファイルでMISSINGnnnnnには、オフラインで、メディア・リカバリが必要であるとのフラグが付けられます。MISSINGnnnnnにALTER DATABASE RENAME FILEを使用して、データファイルをポイントするようにすると、MISSINGnnnnnに対応するデータファイルをアクセス可能にできます。このデータファイルのバックアップがない場合は、表領域を削除します。

時間ベースまたは変更ベースの不完全リカバリの実行

この項では、リカバリの終了位置に対してSCNまたは時刻を指定する方法について説明します。データベースが季節的な時間変更(たとえば夏時間)の影響を受ける場合には、REDOログの中に1つの時間が2度出現し、2番目の、つまり後の時間までリカバリを行う場合に、問題が発生します。時間の変更を処理するには、取消しベースまたは変更ベースのリカバリを実行します。

変更ベースまたは時間ベースのリカバリを実行する手順

1. 「クローズしているデータベースのリカバリの実行」の手順1から8を実行します。

2. RECOVER DATABASE UNTIL文を発行してリカバリを開始します。特定のSCNまでリカバリする場合は、引用符を付けずに10進数を指定します。たとえば、SCN 10034までリカバリするには、次のコマンドを発行します。

RECOVER DATABASE UNTIL CHANGE 10034;

特定の時刻までリカバリする場合は、一重引用符で区切った書式('YYYY-MM-DD:HH24:MI:SS')で時刻を指定します。次の文は、指定された時刻までデータベースのリカバリを行います。

RECOVER DATABASE UNTIL TIME '2000-12-31:12:47:30'

3. リストアされたデータファイルのリカバリに必要なREDOログ・ファイルを適用します。正しい時刻になるとリカバリは自動的に停止し、リカバリが成功したかどうかを示すメッセージが戻されます。

注意:
リカバリが自動化されていないかぎり、名前はLOG_ARCHIVE_DEST_1から提示され、各ログを適用するかどうかの決定を求められます。制御ファイルがバックアップの場合は、アーカイブ・ログを適用した後で、オンライン・ログの名前を指定する必要があります。

4. 「取消しベースの不完全リカバリの実行」の手順4および5を実行します。

NOARCHIVELOGモードでのデータベースのリカバリ

メディア障害によって、NOARCHIVELOGモードのデータベースのデータファイルが破損した場合は、通常、一貫性のあるデータベース全体のバックアップをリストアすることによってのみリカバリできます。Oracle Data Pump Exportで作成した論理バックアップを使用して通常の物理バックアップを補完している場合は、データベースのエクスポートされたバックアップを、再作成したデータベースまたは古いバックアップからリストアしたデータベースにインポートして、データベースのリストアを試行することもできます。

最新のデータベース全体のバックアップをリストアおよびリカバリする手順

1. データベースがオープンしている場合は、データベースを停止します。たとえば、次のように入力します。

SHUTDOWN IMMEDIATE

2. 可能であれば、メディアの問題を解決して、バックアップ・データベース・ファイルを元の場所にリストアできるようにします。

3. オペレーティング・システム・コマンドを使用して、最新のデータベース全体のバックアップをリストアします。破損したファイルのみでなく、データベース全体のバックアップの、すべてのデータファイルおよび制御ファイルをリストアします。ハードウェアの問題が解決できず、データベース・ファイルの一部またはすべてを代替の場所にリストアする必要がある場合は、データベース全体のバックアップを新しい場所にリストアします。次の例は、データベース全体のバックアップをデフォルトの場所にリストアします。

% cp /backup/*.dbf $ORACLE_HOME/oradata/trgt/

4. 必要に応じて、リストアされた初期化パラメータ・ファイルを編集して、制御ファイルの新しい場所を示します。次に例を示します。

CONTROL_FILES = "/new_disk/oradata/trgt/control01.dbf"

5. リストアして編集したパラメータ・ファイルを使用してインスタンスを起動し、データベースをマウントします(ただし、オープンはしません)。次に例を示します。

STARTUP MOUNT

6. リストアされたデータファイルのファイル名が異なる場合(同じノードまたは異なるノードの異なるファイル・システムまたはディレクトリにリストアする場合など)、制御ファイルを更新して新しいデータファイルの場所を反映させます。たとえば、データファイル1の名前を変更するには、次のように入力します。

ALTER DATABASE RENAME FILE '?/oradata/trgt/system01.dbf' TO
'/new_disk/oradata/system01.dbf';

7. オンラインREDOログが破損したディスク上にある場合、ハードウェアの問題が解決されないときには、影響を受けた各オンライン・ログの新しい場所を指定します。たとえば、次のように入力します。

ALTER DATABASE RENAME FILE '?/oradata/trgt/redo01.log' TO
'/new_disk/oradata/redo_01.log';
ALTER DATABASE RENAME FILE '?/oradata/trgt/redo02.log' TO
'/new_disk/oradata/redo_02.log';

8. オンラインREDOログはバックアップされないため、データファイルおよび制御ファイルとともにリストアすることはできません。データベースでオンラインREDOログをリセットできるように、まず不完全リカバリを行う必要があります。

RECOVER DATABASE UNTIL CANCEL
CANCEL

9. RESETLOGSモードでデータベースをオープンします。このコマンドによって、オンラインREDOログが消去され、ログ順序が1にリセットされます。

ALTER DATABASE OPEN RESETLOGS;

NOARCHIVELOGモードのデータベースのバックアップをリストアした後、ログをリセットすると、バックアップが作成されてから障害が発生するまでの間にデータベースに対して行われたすべての変更が廃棄されます。

関連項目:
データファイルの名前の変更および場所の変更の詳細は、『Oracle Database管理者ガイド』を参照し、ALTER DATABASE RENAME FILEについては、『Oracle Database SQL言語リファレンス』を参照してください。

メディア・リカバリのトラブルシューティング

この項では、ユーザー管理のメディア・リカバリ(Recovery Manager (RMAN)を使用しないで実行するメディア・リカバリ)のトラブルシューティングの方法について説明します。この項の内容は、次のとおりです。

- ユーザー管理のメディア・リカバリの問題

- メディア・リカバリの問題の調査: フェーズ1

- ブロックを破損させない修正の試行: フェーズ2

- リカバリでブロックの破損とマークできるようにするかどうかの決定: フェーズ3

- リカバリでのブロックの破損の許可: フェーズ4

- 試行リカバリの実行

ユーザー管理のメディア・リカバリの問題

表29-4に、メディア・リカバリ中に発生する可能性がある問題を示します。

表29-4 メディア・リカバリの問題

問題

説明

アーカイブ・ログの欠落または名前の誤り

制御ファイルに記録されたアーカイブ・ログが見つからないため、リカバリは停止します。

データベースをオープンしようとすると、ORA-1113エラーが、データファイルのメディア・リカバリが必要であることを示す。

このエラーの一般的な原因は次のとおりです。

- 不完全リカバリを実行していますが、必要なすべてのデータファイル・バックアップがリストアされていません。

- データファイルが一貫性のあるSCNに達する前に、不完全リカバリが停止しました。

- オンライン・バックアップからデータファイルのリカバリを行っていますが、データファイルを一貫性のある状態にするための十分なREDOが適用されていません。

- バックアップ制御ファイルを使用してリカバリを行っていますが、必要なオンラインREDOログの場所が指定されていません。

- ユーザーがデータベースをオープンしようとしたときに、データファイルに対してメディア・リカバリが実行されていました。

- リカバリの必要なデータファイルは、RECOVER DATABASEコマンドの実行前にオンラインにされていなかったため、リカバリが行われていません。

REDOレコードの問題

2つの状況が考えられます。

- 一貫性チェックが失敗したためにリカバリが停止しました。スタック・リカバリと呼ばれる問題です。スタック・リカバリは、基礎となるオペレーティング・システムまたはストレージ・システムで、データベースの通常稼働中に発行された書込みが消失した場合に発生することがあります。

- REDOを適用するときに内部エラーが通知されました。この問題は、Oracle Databaseの不具合によって発生することがあります。チェックサム検証が使用されていない場合は、REDOまたはデータ・ブロックの破損によってエラーが発生することもあります。

アーカイブ・ログの破損

格納中またはストレージ・システム間でコピーされるときに、ログが破損した可能性があります。DB_BLOCK_CHECKSUMが有効になっている場合は、通常、チェックサム・エラーが通知されます。チェックサム・チェックが無効になっている場合、ログの破損がREDOの問題として表示されることがあります。

互換性のないパラレルREDOフォーマットによるアーカイブ・ログ

パラレルREDO機能を有効にした場合、REDOログが新規のフォーマットで生成されます。以前のリリースのOracleでは、パラレルREDOログを適用できません。ただし、Oracle9i Databaseリリース2(9.2)より前のリリースでは、パラレルREDOフォーマットを検出し、エラー・メッセージ「External error 00303, 00000, "パラレルREDOは処理できません"」によって非一貫性の存在を確認できます。

データ・ブロックの破損

データファイルのバックアップに破損したデータ・ブロックが含まれているか、リカバリ中またはバックアップにコピーされたときにデータ・ブロックが破損しました。DB_BLOCK_CHECKSUMが有効になっている場合、データベースは、通常の操作時にチェックサムを各ブロックで計算し、ブロックに保存してからディスクに書き込みます。データベースは、後でディスクからブロックを読み取る場合、チェックサムを再計算し、格納されている値と比較します。一致しない場合は、チェックサム・エラーを通知します。チェックサム・チェックが無効になっている場合は、問題がREDOの破損として表示されることがあります。

その他の問題

リカバリ中には、メモリーの破損や、その他の一時的な問題が発生することがあります。

メディア・リカバリの問題は通常、リカバリ中に通知される外部エラーまたは内部エラーとして出現します。たとえば、外部エラーは、REDOブロックまたはデータ・ブロックでチェックサム検証チェックが失敗したことを示します。内部エラーは、データベースの不具合か、基礎となるオペレーティング・システムおよびハードウェアに起因するエラーによって発生する可能性があります。

メディア・リカバリで、データベース・バックアップのリカバリ中に問題が発生した場合は、スタック・リカバリの問題またはREDO適用中の問題であるかどうかに関係なく、データベースは常に停止し、リカバリ中のデータファイルを一貫性のある状態、つまり、障害前の一貫性のあるSCNのままにします。次のいずれかを実行できます。

- データベースを読取り専用でオープンし、問題を調査します。

- RESETLOGSオプションを指定してデータベースをオープンします(RESETLOGSのオープンの要件が満たされている場合)。スタンバイ・データベースはメディア・リカバリの形態で更新されるため、RESETLOGSの制限は、フィジカル・スタンバイ・データベースをオープンする場合にも適用されます。

一般に、データベースを読取り専用でオープンしたり、RESETLOGSオプションを指定してオープンする場合には、すべてのオンライン・データファイルを同じSCNまでリカバリする必要があります。この要件が満たされない場合は、ユーザーがオープンを試行すると、ORA-1113またはその他のエラーが通知されることがあります。ORA-1113の一般的な原因については、表29-4を参照してください。

一般に、メディア・リカバリの問題には、次のように対処します。

1. 問題の原因を確認します。必要に応じて試行リカバリを実行します。

2. 問題がREDOログの欠落に関係するか、REDOログ、メモリーまたはデータ・ブロックが破損している可能性がある場合は、表29-5に示す方法で問題の解決を試みます。

3. 表29-5に示す方法を使用しても問題を解決できない場合は、次のいずれかを実行します。

- データベース全体のバックアップのリカバリを行う場合は、RESETLOGSオプションを指定してデータベースをオープンします。シリアル・メディア・リカバリを実行した場合は、データベースには、破損が発生したSCNの前までのすべての変更が含まれています。このSCN以降の変更は、データベースのリカバリされた部分に含まれていません。オンライン・バックアップをリストアした場合は、RESETLOGSによるオープンは、REDOストリーム中のすべてのALTER ... END BACKUP操作までリカバリが完了している場合にのみ成功します。

- データ・ブロックを破損させることをメディア・リカバリに許可して、リカバリを続行します。メディア・リカバリが完了した後、RMANを使用してブロック・メディア・リカバリを実行してください。

- それでも問題が解決しない場合は、Oracleサポート・サービスに連絡します。

関連項目:
ブロック・メディア・リカバリについては、「障害リカバリの実行」を参照してください。

メディア・リカバリの問題の調査: フェーズ1

メディア・リカバリで問題が発生した場合は、リカバリが停止した後、できるだけ多くの情報を入手してください。解決する問題を誤って時間を消費し、さらに問題を悪化させることを防ぐためです。

最初に、問題の原因が、設定の誤り、REDOログの破損、データ・ブロックの破損、メモリーの破損、またはその他の原因のどれかを確認します。データ・ブロックのチェックサムにエラーがある場合には、データ・ブロックが破損しています。REDOログ・ブロックのチェックサムにエラーがある場合には、REDOログが破損しています。

リカバリの問題の原因は、特定するのが困難な場合があります。問題の原因が完全にはわからない場合でも、この項に示す方法を使用すると、データベースのリカバリを迅速に実行できます。

メディア・リカバリの問題を調査する手順

1. alert.logを調べて、エラー・メッセージに問題の性質についての一般的な情報が記載されているかを確認します。たとえば、alert_SID.logにチェックサムのエラーが示されているかどうかを確認します。また、メディア・リカバリを続行するためにデータ・ブロックの破損を許可する必要があることが示されているかどうかを確認します。

2. リカバリ中にOracle Databaseによって生成されたトレース・ファイルを調べます。追加のエラー情報が含まれていることがあります。

ブロックを破損させない修正の試行: フェーズ2

メディア・リカバリの問題のタイプに応じて、いくつかの解決方法があります。表29-5に示す方法の1つ、あるいはその組合せを使用できます。これらの解決方法は、一般的な修復方法です。比較的安全に、ほとんどのメディア・リカバリの問題を解決できます。

表29-5 メディア・リカバリの解決方法

発生した可能性がある問題

現在の状態

アーカイブREDOログの欠落または名前の誤り

ファイル名が正しく入力されているかを確認します。正しく入力されていた場合には、オペレーティング・システムからログが欠落しているかを確認します。欠落している場合に、バックアップがあれば、バックアップをリストアし、ログを適用します。バックアップがない場合には、可能であれば、欠落したログの時点まで不完全リカバリを実行します。

ALTER DATABASE OPENでのORA-1113

表29-4で、このエラーの原因を検討します。リカバリが必要なすべての読取り/書込みデータファイルがオンラインにされていることを確認します。

リカバリにバックアップ制御ファイルを使用した場合には、制御ファイルとデータファイルのSCNに一貫性がないかぎり、データベースをオープンできません。必要なREDOがない場合には、制御ファイルを再作成する必要があります。

アーカイブ・ログの破損

ログREDOブロックのチェックサム検証が失敗したときには、ログが破損しています。リカバリ・セッション中、またはデータベースがREDOを生成したときにDB_BLOCK_CHECKSUMが有効になっていなかった場合には、リカバリの問題の原因としてログの破損が考えられます。ログが破損し、破損したログの代替コピーが使用できる場合には、このコピーを適用して、問題が修正されるかどうかを確認します。

DB_BLOCK_CHECKSUM初期化パラメータは、REDOログおよびデータ・ブロックに対してチェックサムを計算するかどうかを決定します。

互換性のないパラレルREDOフォーマットによるアーカイブ・ログ

Oracle9i Databaseリリース2より前のOracle Databaseリリースを実行している場合、パラレルREDOフォーマットで作成されたREDOログを適用するには、次の手順を実行する必要があります。

1. データベースをより新しいリリースにアップグレードします。

2. メディア・リカバリを実行します。

3. データベースを一貫した状態で停止し、バックアップを行います。

4. データベースを元のリリースにダウングレードします。

メモリーの破損または一時的な問題

データベースを停止してリカバリを再開すると、問題を解決できる場合があります。2回目の試行も失敗した場合は、データベースを一貫性のある状態のままにしておく必要があります。

データ・ブロックの破損

ユーザー管理の方法を使用して、データファイルのリストアおよびリカバリを再度実行するか、またはRMANのRECOVER ...BLOCKコマンドを使用して、個々のデータ・ブロックのリストアおよびリカバリを行います。この方法で問題が解決される場合もあります。

データ・ブロックのチェックサム検証が失敗した場合は、データ・ブロックが破損しています。DB_BLOCK_CHECKINGが無効である場合は、データ・ブロックの破損の問題が、REDOの問題として表示されることがあります。メディア・リカバリを続行する必要がある場合は、この時点ではブロックを破損とマークできるようにしてリカバリを続け、後でRMANを使用してブロック・メディア・リカバリを実行できます。

表29-5に示す方法で問題を解決できない場合は、データを消失せずに、簡単に問題を解決できる方法がない可能性があります。次のようなオプションがあります。

- RESETLOGSオプションを指定してデータベースをオープンします(データベース全体のリカバリのため)。
この解決方法では、REDOの問題が発生した時点以降のすべての変更が廃棄されますが、データベースの論理的一貫性は保証されます。

- メディア・リカバリで1つ以上のデータ・ブロックを破損させることを許可して、続行します。
このオプションは、アラート・ログに、データ・ブロックを破損させることを許可すればリカバリを続行できることが示されている場合にのみ成功します。これはほとんどのリカバリの問題に当てはまります。データベースを迅速に起動し、すべての変更をリカバリする必要がある場合は、このオプションが最適です。 このオプションを検討する場合は、「リカバリでブロックの破損とマークできるようにするかどうかの決定: フェーズ3」に進みます。

関連項目:
RECOVER ... BLOCKコマンドを使用してブロック・メディア・リカバリを実行する方法については、「ブロック・メディア・リカバリの実行」を参照してください。

リカバリでブロックの破損とマークできるようにするかどうかの決定: フェーズ3

メディア・リカバリで問題が発生した場合、問題の原因となっているデータ・ブロックを破損とマークできるようにすればリカバリを続行できることが、アラート・ログに示されていることがあります。アラート・ログには、ブロックに関する情報(ブロック・タイプ、ブロック・アドレス、所属する表領域など)が含まれています。ユーザー・データを含むブロックの場合は、データ・オブジェクト番号もアラート・ログで報告されることがあります。

この場合、問題のブロックに破損というマークを付けることが許可されれば、リカバリを続行できます。ただし、この方法は常に成功するとはかぎりません。たとえば、SYSTEM表領域の中の重要なブロックに破損というマークを付けると、最終的にはリカバリ済のデータベースをオープンできなくなる可能性があります。もう1つ考慮すべき点は、リカバリの問題を分離できるかどうかです。この問題の直後に、REDOストリームでその他の多数の問題が発生する場合は、RESETLOGSオプションを指定してデータベースをオープンする方がよい場合があります。

ユーザー・データを含むブロックの場合は、通常、データベースを問い合せて、そのブロックを所有するオブジェクトまたは表を確認できます。データベースがオープンしていない場合には、データベース全体のバックアップのリカバリ中であっても、データベースを読取り専用でオープンできます。次の例はリカバリを取り消して、データベースを読取り専用でオープンします。

CANCEL
ALTER DATABASE OPEN READ ONLY;

alert_SID.logで報告されているデータ・オブジェクト番号が8031であるとします。次の問合せを発行して、所有者、オブジェクト名およびオブジェクト型を確認できます。

SELECT OWNER, OBJECT_NAME, SUBOBJECT_NAME, OBJECT_TYPE
FROM DBA_OBJECTS
WHERE DATA_OBJECT_ID = 8031;

リカバリの問題が分離されているかどうかを確認するために、診断用の試行リカバリを実行できます。試行リカバリでは、REDOストリームをスキャンして問題が検索されますが、リカバリされたデータベースに対して実際の変更は行いません。試行リカバリでリカバリの問題が検出された場合、alert_SID.logで報告されます。試行リカバリを起動するには、「RECOVER ... TEST文の実行」で説明するように、RECOVER ... TEST文を使用します。

これらの調査を実行した後、表29-6のガイドラインに従って、リカバリでブロックの破損を許可するかどうかを決定します。

表29-6 リカバリでブロックの破損を許可するためのガイドライン

問題の状態

ブロック

現在の状態

分離されていない

多くの場合、RESETLOGSオプションを指定してデータベースをオープンする必要があります。スタック・リカバリはオペレーティング・システムまたはストレージ・システムで書込みが消失したために発生することがあるため、この対応はスタック・リカバリの問題にとって重要です。オペレーティング・システムまたはストレージ・システムで予期せぬエラーが発生した場合には、複数のブロックでスタック・リカバリの問題が発生する可能性があります。

分離されている

SYSTEM表領域内

最終的にデータベースをオープンできなくなる可能性があるため、ブロックは破損させないでください。ただし、SYSTEM表領域の中のデータが重要でない場合もあります。SYSTEMブロックを破損させ、すべての変更のリカバリを行う必要がある場合には、Oracleサポート・サービスに連絡してください。

分離されている

索引データ

データベースのリカバリ後に索引を再作成できるため、索引ブロックを破損させることを検討してください。

分離されている

ユーザー・データ

データの重要性に基づいて決定します。データファイルのリカバリを続行し、ブロックを破損させると、ブロック内のデータが消失します。ただし、データファイルのリカバリが完了した後で、RMANを使用してブロック・メディア・リカバリを実行できます。RESETLOGSでオープンすると、データベースは一貫性のあるものになりますが、リカバリが停止された時点以降のすべての変更は失われます。

分離されている

ロールバックまたはUNDOデータ

すべてのトランザクションがコミットされる場合は、ロールバックまたはUNDOブロックを破損させることを検討します。UNDOを生成したトランザクションをロールバックしない場合は、データベースに害はありません。ただし、これらのトランザクションをロールバックする場合は、UNDOブロックを破損させると問題が発生する可能性があります。判断できない場合は、Oracleサポート・サービスに連絡してください。

関連項目:
試行リカバリの実行方法については、「試行リカバリの実行」を参照してください。リカバリでブロックの破損を許可するように決定した場合は、「リカバリでのブロックの破損の許可: フェーズ4」を参照してください。

リカバリでのブロックの破損の許可: フェーズ4

リカバリの続行のために、ブロックの破損を許可することを決定した場合には、ALLOW n CORRUPTION句を指定してRECOVERコマンドを実行します。このnは、破損させることを許可するブロックの数です。

リカバリでブロックを破損させることを許可する手順

1. リカバリの通常の前提条件がすべて満たされていることを確認します。たとえば、データベースがオープンしている場合には、リカバリを試みる前に、表領域をオフライン化します。

2. 次の例に示すように、RECOVERコマンドを実行します。

RECOVER DATABASE ALLOW 5 CORRUPTION

試行リカバリの実行

スタック・リカバリなどの問題が発生した場合、判断が困難な場合があります。ブロックが比較的重要でなく、問題が分離されている場合は、通常、ブロックを破損させます。ただし、問題が分離されていない場合は、RESETLOGSオプションを指定してデータベースをオープンする方がよい場合があります。

このため、Oracle Databaseでは、試行リカバリがサポートされています。試行リカバリは、通常のメディア・リカバリと同じ方法でREDOを適用しますが、ディスクに変更を書き込むことはなく、必ず変更をロールバックします。試行リカバリはメモリー内でのみ発生します。

関連項目:
「リカバリでのブロックの破損の許可: フェーズ4」

試行リカバリの仕組み

デフォルトでは、試行リカバリでスタック・リカバリやその他の問題が検出されると、常に、メモリー内でデータ・ブロックに破損しているというマークが付けられます(このアクションによってリカバリを続行できる場合)。試行リカバリ中に生成されたエラーは、アラート・ファイルに書き込まれます。これらのエラーは、テスト実行のエラーであることが明示されます。

試行リカバリでは、通常のメディア・リカバリと同様に、アーカイブ・ログのファイル名を指定するプロンプトが表示され、ユーザーは、ログを適用するかどうかを判断するように求められます。試行リカバリは次の場合に終了します。

- 試行リカバリ用に使用できるメモリー内の最大バッファ数がすべて使用された場合

- リカバリ不能なエラー(データ・ブロックを破損させても解決できないエラー)が通知された場合

- ユーザーがリカバリ・セッションを取り消したか中断した場合

- REDOストリーム内の次のREDOレコードによって制御ファイルが変更された場合

- 必要なREDOがすべて適用された場合

試行リカバリが終了すると、アラート・ファイル内のエラー・メッセージを除き、テスト実行のすべての影響がシステムから削除されます。試行リカバリ中にインスタンスの障害が発生した場合は、試行リカバリが変更をディスクに書き込むことはないため、試行リカバリのすべての影響がシステムから削除されます。

試行リカバリを使用することによって、通常のリカバリを続行した場合に発生する可能性のある問題を予測できます。進行中のメモリーの破損を原因とする問題の場合は、試行リカバリと通常のリカバリで発生するエラーが異なることがあります。

RECOVER ... TEST文の実行

TESTオプションはすべてのRECOVERコマンドで使用できます。たとえば、SQL*Plusを起動して次のコマンドのいずれかを発行できます。

RECOVER DATABASE TEST
RECOVER DATABASE USING BACKUP CONTROLFILE UNTIL CANCEL TEST
RECOVER TABLESPACE users TEST
RECOVER DATABASE UNTIL CANCEL TEST

デフォルトでは、試行リカバリを実行すると、メモリー内でブロックの破損が常に試行されます(このアクションによって試行リカバリを続行できる場合)。試行リカバリはデフォルトで、いくつでもデータ・ブロックを破損させることができます。RECOVER ... TEST文でALLOW n CORRUPTION句を指定すると、試行リカバリの実行時にメモリー内で破損させることができるデータ・ブロックの数を制限できます。

試行リカバリのコマンドは、通常リカバリのコマンドを使用できるすべての場合に使用できます。ただし、試行リカバリを実行する必要があるのは、リカバリで問題が発生する場合のみです。

30 ユーザー管理のリカバリの実行: 高度な例

この章では、複数の一般的なメディア障害の例について説明します。ユーザー管理のバックアップおよびリカバリ計画(Recovery Managerを必要としない計画)を使用した場合に、各障害からリカバリする方法について説明します。この章の内容は、次のとおりです。

- 現行の制御ファイルのサブセットが消失した場合の対応

- 現行の制御ファイルがすべて消失した場合のリカバリ

- 制御ファイルの再作成

- バックアップが利用できない場合のデータファイルの再作成

- NOLOGGING表および索引のリカバリ

- トランスポータブル表領域のリカバリ

- オンラインREDOログ・ファイルが消失した後のリカバリ

- フラッシュバック機能を使用しない、削除された表のリカバリ

- SQL*Plusでのデータベースの削除

現行の制御ファイルのサブセットが消失した場合の対応

永続的なメディア障害によってデータベースの1つ以上の制御ファイルが破損したが、メディア障害によって消失していない現行の制御ファイルが1つ以上ある場合は、次の手順でデータベースをリカバリします。

多重制御ファイルのデフォルトの場所へのコピー

消失した制御ファイルを含むディスクおよびファイル・システムが影響を受けていない場合は、影響を受けていない制御ファイルを、欠落した制御ファイルの場所にコピーできます。この場合は、CONTROL_FILES初期化パラメータを編集する必要はありません。

多重制御ファイルをコピーして破損した制御ファイルを置き換える手順

1. インスタンスが実行されている場合は、停止します。

SQL> SHUTDOWN ABORT

2. メディア障害の原因であるハードウェアの問題を解決します。ハードウェアの問題をすぐに解決できない場合は、「多重制御ファイルのデフォルト以外の場所へのコピー」の説明に従って、破損した制御ファイルを代替のストレージ・デバイスにリストアしてデータベースのリカバリを続行します。

3. データベースの現行の制御ファイルの多重コピーから、影響を受けていないものを選択して、破損した制御ファイルを上書きします。たとえば、bad_cf.fをgood_cf.fで置き換えるには、次のように入力します。

% cp /oracle/good_cf.f /oracle/dbs/bad_cf.f

4. 新しいインスタンスを起動し、データベースをマウントしてオープンします。たとえば、次のように入力します。

SQL> STARTUP

多重制御ファイルのデフォルト以外の場所へのコピー

消失した制御ファイルを含むディスクおよびファイル・システムが影響を受けている場合は、正常な制御ファイルを、欠落した制御ファイルの場所に単純にコピーできません。この場合は、CONTROL_FILES初期化パラメータを変更して、欠落した制御ファイルの新しい場所を示す必要があります。

デフォルト以外の場所に制御ファイルをリストアする手順

1. インスタンスが実行されている場合は、停止します。

SQL> SHUTDOWN ABORT

2. メディア障害の原因であるハードウェアの問題を解決できない場合は、影響を受けていない制御ファイルを代替の場所にコピーします。
たとえば、正常なcontrol01.dbfを新しいディスクの場所にコピーするには、次のコマンドを発行します。

% cp /disk1/oradata/trgt/control01.dbf /new_disk/control01.dbf

3. CONTROL_FILESパラメータですべての制御ファイルの現在の場所が反映され、リストアされていないすべての制御ファイルが除外されるように、データベースのパラメータ・ファイルを編集します。
初期化パラメータ・ファイルの設定が次のようになっているとします。

CONTROL_FILES='/disk1/oradata/trgt/control01.dbf','/bad_disk/control02.dbf'

次のようにCONTROL_FILES初期化パラメータを編集します。

CONTROL_FILES='/disk1/oradata/trgt/control01.dbf','/new_disk/control02.dbf'

4. 新しいインスタンスを起動し、データベースをマウントしてオープンします。次に例を示します。

SQL> STARTUP

現行の制御ファイルがすべて消失した場合のリカバリ

永続的なメディア障害によってデータベースのすべての制御ファイルが破損したが、制御ファイルのバックアップがある場合は、次の手順を実行して、バックアップ制御ファイルをリストアします。制御ファイルにアクセスできない場合、インスタンスは起動できますが、データベースをマウントできません。制御ファイルを使用できないときにデータベースをマウントしようとすると、次のエラー・メッセージが表示されます。

ORA-00205: error in identifying control file, check alert log for more info

注意:
トレース・ファイルおよびアラート・ログの場所を特定する最も簡単な方法は、SQL問合せSELECT NAME, VALUE FROM V$DIAG_INFOを実行する方法です。

制御ファイルを再度アクセス可能にするまでは、データベースをマウントしてオープンすることはできません。バックアップ制御ファイルをリストアする場合は、RESETLOGSオプションを使用してデータベースをオープンする必要があります。

表30-1に示すように、制御ファイルのリストアの手順は、オンラインREDOログを利用できるかどうかによって異なります。

表30-1 制御ファイルが消失した場合のシナリオ

オンライン・ログのステータス

データファイルのステータス

リストア手順

使用可能

現行

リカバリに必要なREDOがオンライン・ログに含まれている場合には、バックアップ制御ファイルをリストアし、リカバリ時にログを適用します。データベースをオープンするためには、変更を含むオンライン・ログのファイル名を指定する必要があります。リカバリ後に、RESETLOGSオプションを使用してデータベースをオープンします。

注意: 制御ファイルを再作成するときに、オンラインREDOログにアクセスできる場合は、リカバリ後にOPEN RESETLOGSオプションを使用する必要はありません。

使用不可

現行

リカバリに必要なREDOがオンライン・ログに含まれている場合は、制御ファイルを再作成します。オンラインREDOログにはアクセスできないため、RESETLOGSでオープンします。

使用可能

バックアップ

バックアップ制御ファイルをリストアし、完全リカバリを実行し、RESETLOGSオプションを使用してデータベースをオープンします。

使用不可

バックアップ

バックアップ制御ファイルをリストアし、不完全リカバリを実行し、RESETLOGSでオープンします。

デフォルトの場所でのバックアップ制御ファイルを使用したリカバリ

可能であれば、元の場所に制御ファイルをリストアします。この方法では、初期化パラメータ・ファイルで制御ファイルの新しい場所を指定する必要はありません。

デフォルトの場所にバックアップ制御ファイルをリストアする手順

1. インスタンスが実行されている場合は、停止します。

SQL> SHUTDOWN ABORT

2. メディア障害の原因であるハードウェアの問題を解決します。

3. CONTROL_FILESパラメータ・ファイルで指定されたすべての場所にバックアップ制御ファイルをリストアします。たとえば、サーバー・パラメータ・ファイルに示される制御ファイルの場所が/disk1/oradata/trgt/control01.dbfおよび/disk2/oradata/trgt/control02.dbfの場合は、オペレーティング・システム・ユーティリティを使用して、これらの場所にバックアップ制御ファイルをリストアします。

% cp /backup/control01.dbf /disk1/oradata/trgt/control01.dbf
% cp /backup/control02.dbf /disk2/oradata/trgt/control02.dbf

4. 新しいインスタンスを起動し、データベースをマウントします。たとえば、次のように入力します。

SQL> STARTUP MOUNT

5. USING BACKUP CONTROLFILE句を指定してRECOVERコマンドを実行し、リカバリを開始します。不完全リカバリを実行する場合は、UNTIL CANCELを指定します。たとえば、次のように入力します。

SQL> RECOVER DATABASE USING BACKUP CONTROLFILE UNTIL CANCEL

6. プロンプトで指示されたアーカイブ・ログを適用します。必要なアーカイブ・ログがないことを告げる別のメッセージが表示された場合には、必要なREDOレコードがオンラインREDOログに入っていることが考えられます。インスタンスで障害が発生したときに、アーカイブされていない変更がオンライン・ログに入っていた場合には、このような状況が発生することがあります。
たとえば、次のメッセージが表示されたとします。

ORA-00279: change 55636 generated at 11/08/2002 16:59:47 needed for thread 1
ORA-00289: suggestion : /oracle/work/arc_dest/arcr_1_111.arc
ORA-00280: change 55636 for thread 1 is in sequence #111
Specify log: {<RET>=suggested | filename | AUTO | CANCEL}

オンラインREDOログの名前を指定し、[Enter]を押します(正しいログが見つかるまで何度か繰り返すことになる場合があります)。

ORACLE_HOME/oradata/redo01.dbf
Log applied.
Media recovery complete.

オンライン・ログにアクセスできない場合は、オンライン・ログを適用せずにリカバリを取り消すことができます。すべてのデータファイルが現行のものである場合に、リカバリに必要なREDOがオンライン・ログの中に含まれているときには、オンライン・ログを適用せずにデータベースをオープンすることはできません。オンライン・ログにアクセスできない場合は、「制御ファイルの再作成」に示す手順を実行して、制御ファイルを再作成する必要があります。

7. リカバリが終了した後、RESETLOGSオプションを指定してデータベースをオープンします。

SQL> ALTER DATABASE OPEN RESETLOGS;

デフォルト以外の場所でのバックアップ制御ファイルを使用したリカバリ

メディアの損傷が重大なため、元の場所に制御ファイルをリストアできない場合は、サーバー・パラメータ・ファイルで制御ファイルの新しい場所を指定する必要があります。CONTROL_FILES初期化パラメータで指定されたすべての場所に有効な制御ファイルが存在する必要があります。存在しない場合は、データベースをマウントできません。

デフォルト以外の場所に制御ファイルをリストアする手順

「デフォルトの場所でのバックアップ制御ファイルを使用したリカバリ」の手順に従いますが、手順2の後に、次の手順を追加します。

CONTROL_FILES初期化パラメータで指定されたすべての場所を編集して、制御ファイルの新しい場所を反映します。たとえば、サーバー・パラメータ・ファイルに制御ファイルの場所が次のように表示され、いずれのディスクにもアクセスできないとします。

CONTROL_FILES='/disk1/oradata/trgt/control01.dbf',
'/disk2/oradata/trgt/control02.dbf'

次の例のように初期化パラメータ・ファイルを編集して、アクセス可能な場所を指定できます。

CONTROL_FILES='/disk3/cf/control01.dbf','/disk4/cf/control02.dbf'

バックアップ制御ファイルを使用したデータファイルの追加を伴うリカバリ

バックアップ制御ファイルを使用したデータベースのリカバリが、CREATE TABLESPACEまたはALTER TABLESPACE ADD DATAFILE操作を伴ってロールフォワードされる場合は、追加されたファイルにREDOレコードを適用するときにリカバリが停止し、ユーザーによるファイル名の確認が行われます。

たとえば、次の操作を順に行うとします。

1. データベースをバックアップします。

2. /disk1/oradata/trgt/test01.dbfおよび/disk1/oradata/trgt/test02.dbfというデータファイルを含む表領域を作成します。

3. バックアップ制御ファイルをリストアし、CREATE TABLESPACE操作を伴うメディア・リカバリを実行します。

CREATE TABLESPACEのREDOデータの適用時に、次のエラーが表示される場合があります。

ORA-00283: recovery session canceled due to errors
ORA-01244: unnamed datafile(s) added to control file by media recovery
ORA-01110: data file 11: '/disk1/oradata/trgt/test02.dbf'
ORA-01110: data file 10: '/disk1/oradata/trgt/test01.dbf'

ADD DATAFILE操作を伴うリカバリを実行する手順

1. V$DATAFILEを問い合せて、追加されたファイルを表示します。たとえば、次のように入力します。

SELECT FILE#,NAME
FROM V$DATAFILE;

FILE#           NAME
--------------- ----------------------
1               /disk1/oradata/trgt/system01.dbf
.
.
.
10               /disk1/oradata/trgt/UNNAMED00001
11               /disk1/oradata/trgt/UNNAMED00002

2. 名前のないファイルが複数存在する場合は、次のいずれかの方法を使用して、どの名前なしファイルがどのデータファイルに対応するかを確認します。

- alert_SID.logを参照し、名前のない各ファイルの元のファイルの場所に関するメッセージを確認します。

- エラー・メッセージおよびV$DATAFILEから、名前のない各ファイルの元のファイルの場所を導出します。名前のないファイルは、エラー・メッセージの中の同じファイル番号のファイルに対応します。

3. ALTER DATABASE RENAME FILE文を発行して、データファイル名を変更します。たとえば、次のように入力します。

ALTER DATABASE RENAME FILE '/db/UNNAMED00001' TO
'/disk1/oradata/trgt/test01.dbf';
ALTER DATABASE RENAME FILE '/db/UNNAMED00002' TO
'/disk1/oradata/trgt/test02.dbf';

4. リカバリ文を発行してリカバリを続行します。次に例を示します。

RECOVER AUTOMATIC DATABASE USING BACKUP CONTROLFILE UNTIL CANCEL

バックアップ制御ファイルを使用した読取り専用表領域のリカバリ

読取り専用メディアまたは低速のメディア上に読取り専用表領域がある場合は、USING BACKUP CONTROLFILEオプションを指定してリカバリを実行すると、エラーが発生したり、パフォーマンスが低下することがあります。この状況は、制御ファイルがバックアップされたときに表領域が読取り/書込みであったことをバックアップ制御ファイルが示している場合に発生します。この場合、メディア・リカバリでファイルへの書込みが試行されることがあります。読取り専用メディアの場合には、ファイルへの書込みができないことを告げるエラー・メッセージが発行されます。テープでバックアップされる階層ストレージ・システムなど、低速メディアの場合には、パフォーマンスが低下することがあります。

これらの問題を回避するには、バックアップではなく、現行の制御ファイルを使用して、データベースのリカバリを行います。バックアップ制御ファイルを使用する必要がある場合には、読取り専用表領域がメディア障害の影響を受けていなければ、この問題を回避できます。バックアップ制御ファイルを使用する場合には、読取り専用または低速メディアのリカバリに次の代替方法を使用できます。

- バックアップ制御ファイルを使用してリカバリを実行する前に、読取り専用表領域のデータファイルをオフライン化し、メディア・リカバリの最後に、ファイルをオンライン化します。

- リカバリには正しいバージョンの制御ファイルを使用します。リカバリの完了時に表領域が読取り専用になる場合は、表領域が読取り専用であった時点の制御ファイルのバックアップを使用する必要があります。同様に、リカバリの終了時に表領域が読取り/書込みになる場合には、表領域が読取り/書込みであった時点の制御ファイルを使用する必要があります。

制御ファイルの再作成

永続的なメディア障害によってすべての制御ファイルが消失した場合は、すべてのオンラインREDOログ・メンバーが影響を受けていなければ、新しい制御ファイルを作成した後でデータベースをリカバリできます。リカバリ後にRESETLOGSオプションを指定してデータベースをオープンする必要はありません。

制御ファイルのバックアップの有無および作成日時に応じて、CREATE CONTROLFILE文のテキストを生成する際に表30-2に示すオプションを使用できます。データベースに対する変更はalert_SID.logに記録されるため、どのオプションを選択するかを決定する際は、このログを確認してください。

表30-2 制御ファイルの作成のオプション

状況 . .

説明 . .

データベースの最後の構造変更の後でALTER DATABASE BACKUP CONTROLFILE TO TRACE NORESETLOGSを実行し、SQLコマンド・トレース出力を保存してある場合

トレース出力のCREATE CONTROLFILE文をそのまま使用します。

データベースの構造変更を行う前に、最後のALTER DATABASE BACKUP CONTROLFILE TO TRACEを実行した場合

ALTER DATABASE BACKUP CONTROLFILE TO TRACEの出力を編集して、変更を反映します。たとえば、最近データベースにデータファイルを追加した場合には、このデータファイルをCREATE CONTROLFILE文のDATAFILE句に追加します。

ALTER DATABASE BACKUP CONTROLFILE TO filename文を使用して制御ファイルをバックアップした場合(TO TRACEオプションを使用しなかった場合)

制御ファイルのコピーを使用してSQL出力を取得します。一時的なデータベース・インスタンスを作成し、バックアップ制御ファイルをマウントして、ALTER DATABASE BACKUP CONTROLFILE TO TRACE NORESETLOGSを実行します。制御ファイルのコピーが最新の構造変更の前の日付になっている場合は、トレース・オプションを編集して変更を反映します。

TO TRACE形式でもTO filename形式でも制御ファイルのバックアップがない場合

CREATE CONTROLFILE文を手動で実行します(『Oracle Database SQL言語リファレンス』を参照)。

注意:
デフォルトのUS7ASCII以外のキャラクタ・セットを使用している場合には、CREATE CONTROLFILE文の引数としてキャラクタ・セットを指定する必要があります。データベース・キャラクタ・セットは、起動時にアラート・ログに書き込まれます。また、キャラクタ・セット情報はBACKUP CONTROLFILE TO TRACEの出力にも記録されます。

新しい制御ファイルを作成し、データベースをリカバリする手順

1. データベースをNOMOUNTモードで起動します。たとえば、次のように入力します。

STARTUP NOMOUNT

2. NORESETLOGSオプションを指定して、CREATE CONTROLFILE文で制御ファイルを作成します(オプションについては表30-2を参照)。次の例では、キャラクタ・セットがデフォルトのUS7ASCIIであるとします。

CREATE CONTROLFILE REUSE DATABASE SALES NORESETLOGS ARCHIVELOG
MAXLOGFILES 32
MAXLOGMEMBERS 2
MAXDATAFILES 32
MAXINSTANCES 16
MAXLOGHISTORY 1600
LOGFILE
GROUP 1 (
'/diska/prod/sales/db/log1t1.dbf',
'/diskb/prod/sales/db/log1t2.dbf'
)  SIZE 100K
GROUP 2 (
'/diska/prod/sales/db/log2t1.dbf',
'/diskb/prod/sales/db/log2t2.dbf'
)  SIZE 100K
DATAFILE
'/diska/prod/sales/db/database1.dbf',
'/diskb/prod/sales/db/filea.dbf';

制御ファイルを作成した後、インスタンスでデータベースがマウントされます。

3. データベースを通常どおりに(USING BACKUP CONTROLFILE句を指定せずに)リカバリします。

RECOVER DATABASE

4. リカバリが終了した後、データベースをオープンします(RESETLOGSオプションは必要ありません)。

ALTER DATABASE OPEN;

5. すぐに制御ファイルをバックアップします。次のSQL文は、/backup/control01.dbfにデータベースの制御ファイルをバックアップします。

ALTER DATABASE BACKUP CONTROLFILE TO '/backup/control01.dbf' REUSE;

関連項目:
「制御ファイルのトレース・ファイルへのバックアップ」および「バックアップが利用できない場合のデータファイルの再作成」を参照してください。

作成された制御ファイルを使用したRESETLOGSを伴うリカバリ

次の条件を満たす場合は、OPEN RESETLOGS操作を使用してバックアップをリカバリできます。

- 過去のインカネーションを検出する現行の制御ファイル、バックアップ制御ファイルまたは作成された制御ファイルがある

- すべてのアーカイブREDOログが使用可能である

制御ファイルを再作成する必要がある場合は、ALTER DATABASE BACKUP CONTROLFILE TO TRACEを使用してトレース・ファイルを生成すると、そのファイルにインカネーションの完全な履歴を再構築するために必要なコマンドが含まれます。V$DATABASE_INCARNATIONビューには制御ファイルのRESETLOGSの履歴が表示され、V$LOG_HISTORYビューにはアーカイブ・ログの履歴が表示されます。

インカネーションの履歴は、再作成された制御ファイルでは不完全な場合があります。たとえば、リカバリに必要なアーカイブ・ログが欠落している場合があります。この場合は、ALTER DATABASE REGISTER LOGFILE文を使用して、インカネーションの記録を明示的に作成できます。

次の例では、リカバリに必要だが再作成された制御ファイルには記録されていない4つのログを登録して、データベースをリカバリします。

ALTER DATABASE REGISTER LOGFILE '/disk1/oradata/trgt/arch/arcr_1_1_42343523.arc';
ALTER DATABASE REGISTER LOGFILE '/disk1/oradata/trgt/arch/arcr_1_1_34546466.arc';
ALTER DATABASE REGISTER LOGFILE '/disk1/oradata/trgt/arch/arcr_1_1_23435466.arc';
ALTER DATABASE REGISTER LOGFILE '/disk1/oradata/trgt/arch/arcr_1_1_12343533.arc';
RECOVER AUTOMATIC DATABASE;

再作成された制御ファイルを使用した読取り専用ファイルのリカバリ

リカバリに現行の制御ファイルまたはバックアップ制御ファイルを使用できない場合は、CREATE CONTROLFILE文を実行できます。リカバリでスキップできるように、読取り専用ファイルはCREATE CONTROLFILE文に含めないでください。リストアされた読取り専用データファイルのバックアップが、ファイルが読取り/書込みであった時点のものでないかぎり、読取り専用データファイルのリカバリは必要ありません。

制御ファイルを作成し、データベースのマウントおよびオープンを試行すると、制御ファイルにリストされたファイルに対してデータ・ディクショナリのチェックが実行されます。 CREATE CONTROLFILE文に含まれていないが、データ・ディクショナリに存在する各ファイルについては、制御ファイル内にエントリが作成されます。これらのファイルには、MISSINGnnnnnという名前が付けられます。このnnnnnは、0(ゼロ)から開始される5桁の数字です。

データベースをオープンした後、名前の前にMISSINGという接頭辞があるすべてのファイルについて、ALTER DATABASE RENAME FILE文を実行して、読取り専用ファイルの名前を正しいファイル名に変更します。

制御ファイルの再作成が必要となる状況に備えるための操作

データベースをマウントまたはオープンしているときに次の文を実行し、CREATE CONTROLFILE構文を取得します。

ALTER DATABASE BACKUP CONTROLFILE TO TRACE;

このSQL文によって、トレース・ファイルが作成されます。トレース・ファイルは、ユーザーが編集し、制御ファイルを再作成するためのスクリプトとして使用できます。RESETLOGSまたはNORESETLOGS(デフォルト)キーワードを指定して、CREATE CONTROLFILE ... RESETLOGSまたはCREATE CONTROLFILE ... NORESETLOGS対応のスクリプトを生成できます。

CREATE CONTROLFILE文の読取り専用ファイルに関連するすべての制限は、データベースをオープンした後で表領域をオンライン化する必要があることを除き、NORMALモードでオフライン化された表領域にも該当します。一時ファイルはCREATE CONTROLFILE文から除外し、データベースをオープンした後で追加する必要があります。

関連項目:
制御ファイルのトレース・バックアップの作成方法については、「制御ファイルのトレース・ファイルへのバックアップ」を参照してください。

バックアップが利用できない場合のデータファイルの再作成

データファイルが破損し、ファイルのバックアップが利用できない場合でも、次の条件を満たしていれば、データファイルをリカバリできます。

- 元のデータファイルの作成後に書き込まれたすべてのアーカイブ・ログ・ファイルを利用できる

- 制御ファイルに破損したファイルの名前が含まれている(制御ファイルは現行か、破損したデータファイルがデータベースに追加された後で作成されたバックアップである)

注意:
ALTER DATABASE文のCREATE DATAFILE句を使用してSYSTEM表領域のデータファイルを再作成することはできません。これは、必要なREDOを使用できないためです。

リカバリのためにデータファイルを再作成する手順

1. 新しい空のデータファイルを作成して、対応するバックアップのない、破損したデータファイルと置き換えます。たとえば、データファイル/disk1/oradata/trgt/users01.dbfが破損し、このファイルのバックアップがないとします。次の文は、元のデータファイル(同じサイズ)をdisk2上に再作成します。

ALTER DATABASE CREATE DATAFILE '/disk1/oradata/trgt/users01.dbf' AS
'/disk2/users01.dbf';

この文は、消失したファイルと同じサイズの、空のファイルを作成します。制御ファイルおよびデータ・ディクショナリ内の情報が検索され、サイズ情報が取得されます。古いデータファイルは新しいデータファイルとして名前を変更されます。

2. 空のデータファイルに対してメディア・リカバリを実行します。たとえば、次のように入力します。

RECOVER DATAFILE '/disk2/users01.dbf'

3. リカバリ時には、元のデータファイルが作成された後に書き込まれたすべてのアーカイブ・ログを、消失したデータファイルと置き換えた新しい空のファイルに適用する必要があります。

NOLOGGING表および索引のリカバリ

表および索引はCREATE TABLE AS SELECT文で作成できます。また、NOLOGGINGオプションを使用して作成するように指定することもできます。表または索引をNOLOGGINGとして作成した場合、操作のREDOログ・レコードは生成されません。このため、ARCHIVELOGモードで実行する場合でも、NOLOGGINGを使用して作成されたオブジェクトのリカバリを行うことはできません。

注意:
NOLOGGINGを使用して作成された表または索引の破損が許容できない場合は、リカバリ不能な表または索引を作成した後で、バックアップを作成します。

メディア・リカバリを実行する場合、表または索引の一部が通常どおりに作成され、その他がNOLOGGINGオプションを使用して作成されているときは、RECOVER操作を行うと、NOLOGGINGオブジェクトに論理的に破損しているというマークが付けられます。リカバリ不能なオブジェクトにアクセスを試みると、ORA-01578エラー・メッセージが戻されます。NOLOGGINGオブジェクトを削除し、必要に応じて再作成します。

NOLOGGINGオプションを使用して表を作成し、その表の索引をLOGGINGオプションを使用して作成できるため、メディア・リカバリの実行後、索引には論理的に破損しているというマークが付けられません。ただし、表はリカバリ不能であるため(リカバリ後に破損しているというマークが付けられます)、索引は破損ブロックをポイントします。索引を削除し、必要に応じて表および索引を再作成する必要があります。

関連項目:
データベースへのNOLOGGINGの影響の詳細は、『Oracle Data Guard概要および管理』を参照してください。

トランスポータブル表領域のリカバリ

Oracle Databaseのトランスポータブル表領域機能を使用すると、ユーザーは表領域のセットを1つのデータベースから別のデータベースにトランスポートできます。表領域をデータベースにトランスポートすることは、ロードされたデータを使用して表領域を作成することに似ています。この機能を使用することには、次の理由でメリットがあります。

- データファイルのコピーとメタデータの統合のみが行われるため、データ・ポンプ・エクスポートまたはSQL*Loaderユーティリティを使用した場合より高速です。

- 索引データを移動できるため、索引を再作成する必要がありません。

関連項目:
トランスポータブル表領域機能の使用方法の詳細は、『Oracle Database管理者ガイド』を参照してください。

トランスポータブル表領域は、通常の表領域と同じように、リカバリ可能です。ただし、通常の表領域はバックアップなしにリカバリできますが、トランスポートされた表領域のリカバリには、トランスポートされたデータファイルの一貫性が保持されているバージョンが必要です。

トランスポータブル表領域をリカバリする手順

1. データベースがオープンしている場合は、トランスポートされた表領域をオフライン化します。たとえば、users表領域をリカバリする場合は、次の文を発行します。

ALTER TABLESPACE users OFFLINE IMMEDIATE;

2. オペレーティング・システム・ユーティリティを使用して、トランスポートされたデータファイルのバックアップをリストアします。このバックアップは、トランスポートされたデータファイルの最初のバージョンでも、表領域がトランスポートされた後で作成されたバックアップでもかまいません。たとえば、次のように入力します。

% cp /backup/users.dbf $ORACLE_HOME/oradata/trgt/users01.dbf

3. 表領域を通常どおりにリカバリします。たとえば、次のように入力します。

RECOVER TABLESPACE users

CREATE TABLESPACE操作を伴うリカバリの場合と同じように、トランスポータブル表領域の操作を伴うリカバリでもエラーORA-01244が表示される場合があります。この場合は、「バックアップ制御ファイルを使用したデータファイルの追加を伴うリカバリ」の手順を使用して、名前のないファイルを正しい場所の名前に変更してください。

オンラインREDOログ・ファイルが消失した後のリカバリ

データベースのオンラインREDOログがメディア障害の影響を受けたときの正しいリカバリ手順は、次の考慮事項によって異なります。

- オンラインREDOログの構成: ミラー化されているかいないか

- メディア障害のタイプ: 一時的か永続的か

- メディア障害の影響を受けたオンラインREDOログ・ファイルのタイプ: 現行、アクティブ、アーカイブされていない、または非アクティブ

表30-3に、オンラインREDOログをリカバリする場合に重要になるV$LOGのステータス情報を示します。

表30-3 V$LOGのSTATUS列

ステータス

説明

UNUSED

このオンラインREDOログは書き込まれたことがありません。

CURRENT

このオンラインREDOログはアクティブです。インスタンス・リカバリに必要です。また、現在書込みが行われているログです。REDOログはオープンまたはクローズです。

ACTIVE

このオンラインREDOログはアクティブです。インスタンス・リカバリに必要です。ただし、現在書込みが行われているログではありません。ブロック・リカバリに使用されている可能性があります。また、アーカイブされる場合とされない場合があります。

CLEARING

このログは、ALTER DATABASE CLEAR LOGFILE文の後で、空のログとして、再作成中です。ログが消去されると、ステータスはUNUSEDに変更されます。

CLEARING_CURRENT

現在のログはクローズ・スレッドの消去中です。新しいログ・ヘッダーへの書込み時のI/Oエラーなど、なんらかのスイッチの障害が発生した場合には、ログがこのステータスのままになることがあります。

INACTIVE

このログはインスタンス・リカバリに必要とされなくなりました。メディア・リカバリで使用される場合があります。アーカイブされる場合とされない場合があります。

多重オンラインREDOログ・グループの一部のメンバーが消失した後のリカバリ

多重オンラインREDOログ・グループのメンバーが消失したら、リカバリを実行できます。次の条件が満たされている場合、データベースは通常どおりに機能し続けます。

データベースのオンラインREDOログが多重化されている場合は、各オンラインREDOログ・グループの1つ以上のメンバーがメディア障害の影響を受けていなければ、データベースは通常どおりに機能し続けることができます。ただし、データベースのログ・ライターのトレース・ファイルおよびalert_SID.logにエラー・メッセージが書き込まれます。

次のいずれかのアクションを実行して、多重オンラインREDOログ・グループのメンバー消失の問題を解決できます。

- ハードウェアの問題が一時的な場合は、問題を解決します。ログ・ライター・プロセスは、問題が発生しなかった場合と同様に、以前は使用不可であったオンラインREDOログ・ファイルにアクセスします。

- ハードウェアの問題が永続的な場合には、次の手順に従って、破損したメンバーを削除し、新しいメンバーを追加します。

注意:
新しく追加されたメンバーは、ログ・グループが再利用されるまでは、冗長性を提供しません。

1. V$LOGFILEで破損したメンバーのファイル名を検索します。ファイルにアクセスできない場合、ステータスはINVALIDになります。

SELECT GROUP#, STATUS, MEMBER
FROM V$LOGFILE
WHERE STATUS='INVALID';

GROUP#    STATUS       MEMBER
-------   -----------  ---------------------
0002      INVALID      /disk1/oradata/trgt/redo02.log

2. 破損したメンバーを削除します。たとえば、メンバーredo02.logをグループ2から削除するには、次の文を発行します。

ALTER DATABASE DROP LOGFILE MEMBER '/disk1/oradata/trgt/redo02.log';

3. グループに新しいメンバーを追加します。たとえば、redo02.logをグループ2に追加するには、次の文を発行します。

ALTER DATABASE ADD LOGFILE MEMBER '/disk1/oradata/trgt/redo02b.log'
TO GROUP 2;

追加するファイルが存在している場合には、グループの他のメンバーと同じサイズである必要があります。また、REUSEオプションを指定する必要があります。次に例を示します。

ALTER DATABASE ADD LOGFILE MEMBER '/disk1/oradata/trgt/redo02b.log'
REUSE TO GROUP 2;

オンラインREDOログ・グループのすべてのメンバーが消失した後のリカバリ

オンラインREDOログ・グループのすべてのメンバーがメディア障害によって破損した場合には、障害の影響を受けたオンラインREDOログ・グループのタイプと、データベースのアーカイブ・モードによって、想定されるシナリオが異なります。

破損したオンラインREDOログ・グループが現行のアクティブなものである場合は、このオンラインREDOログ・グループがクラッシュ・リカバリで必要になります。非アクティブなものである場合は、クラッシュ・リカバリで必要とされません。表30-4に、様々なリカバリ・シナリオの概要を示します。

表30-4 オンラインREDOログ・グループが消失した後のリカバリ

グループの状態 . .

現在の状態

ユーザーが取るべき処置 . .

非アクティブ

クラッシュ・リカバリで必要ありません

アーカイブされたグループまたはアーカイブされていないグループを消去します。

アクティブ

クラッシュ・リカバリで必要です

チェックポイントを発行してログを消去します。実行できない場合は、フラッシュバック・データベースを使用するか、またはバックアップをリストアし、使用可能な最新のREDOログの時点まで、不完全リカバリを実行する必要があります。

現行

現在書込みが行われているREDOログです

ログを消去します。消去できない場合は、フラッシュバック・データベースを使用するか、またはバックアップをリストアし、使用可能な最新のREDOログの時点まで、不完全リカバリを実行する必要があります。

破損したグループがアクティブか非アクティブかを確認します。

1. V$LOGFILEで消失したREDOログのファイル名を検索し、これに対応するグループ番号を検索します。 たとえば、次のように入力します。

SELECT GROUP#, STATUS, MEMBER FROM V$LOGFILE;

GROUP#    STATUS       MEMBER
-------   -----------  ---------------------
0001                    /oracle/dbs/log1a.f
0001                    /oracle/dbs/log1b.f
0002      INVALID       /oracle/dbs/log2a.f
0002      INVALID       /oracle/dbs/log2b.f
0003                    /oracle/dbs/log3a.f
0003                    /oracle/dbs/log3b.f

2. どのグループがアクティブかを確認します。
たとえば、次のSQL問合せを実行します(出力例も示します)。

SELECT GROUP#, MEMBERS, STATUS, ARCHIVED
FROM V$LOG;

GROUP#  MEMBERS           STATUS     ARCHIVED
------  -------           ---------  -----------
0001   2                 INACTIVE   YES
0002   2                 ACTIVE     NO
0003   2                 CURRENT    NO

3. 次のいずれかの処理を実行します。

- 影響を受けたグループが非アクティブな場合には、「非アクティブのオンラインREDOログ・グループの消失」の手順に従ってください。

- 影響を受けたグループがアクティブな場合(前述の例のような場合)には、「アクティブなオンラインREDOログ・グループの消失」の手順に従ってください。

非アクティブのオンラインREDOログ・グループの消失

INACTIVEステータスのオンラインREDOログ・グループのすべてのメンバーが破損した場合は、その非アクティブREDOログ・グループを破損させたメディアの問題を解決できるかどうかによって、手順が異なります。障害が一時的な場合は、問題を解決します。ログ・ライターは、必要な場合にREDOログ・グループを再利用できます。障害が永続的な場合は、破損した非アクティブのオンラインREDOログ・グループは最終的に、データベースの通常の実行を停止させます。この項の説明に従ってALTER DATABASE CLEAR LOGFILE文を発行し、破損したグループを手動で再初期化します。

非アクティブのアーカイブREDOの消去

データベースをオープンまたはクローズした状態で、非アクティブのREDOログ・グループを消去できます。手順は、破損したグループがアーカイブされているかどうかで異なります。

アーカイブされている、非アクティブのオンラインREDOログ・グループを消去する手順

1. データベースが停止している場合は、新しいインスタンスを起動してデータベースをマウントします。

STARTUP MOUNT

2. 破損したログ・グループを再初期化します。たとえば、REDOログ・グループ2を消去するには、次の文を発行します。

ALTER DATABASE CLEAR LOGFILE GROUP 2;

非アクティブのアーカイブされていないREDOの消去

アーカイブされていないREDOログを消去することによって、アーカイブせずに、ログを再利用できます。ログの中の最初の変更の前にファイルがオフライン化されておらず、ログの中の最後の変更前にバックアップが開始されている場合は、このアクションによってバックアップは使用できなくなります。このため、バックアップのリカバリのために消去されたログ・ファイルが必要となった場合は、このバックアップはリカバリできません。アーカイブされていないREDOログを消去すると、ログの欠落のため、バックアップからの完全リカバリを実行できなくなります。

アーカイブされていない、非アクティブのオンラインREDOログ・グループを消去する手順

1. データベースが停止している場合は、新しいインスタンスを起動してデータベースをマウントします。

SQL> STARTUP MOUNT

2. UNARCHIVEDキーワードを使用してログを消去します。
たとえば、ログ・グループ2を消去するには、次のSQL文を発行します。

SQL> ALTER DATABASE CLEAR UNARCHIVED LOGFILE GROUP 2;

消去されたログを使用してオンライン化する必要があるオフライン・データファイルが存在する場合は、UNRECOVERABLE DATAFILEキーワードが必要です。データファイルをオンライン化するために必要なREDOログが消去され、そのコピーもないため、そのデータファイルを削除する必要があります。たとえば、次のように入力します。

SQL> ALTER DATABASE CLEAR UNARCHIVED LOGFILE GROUP 2 UNRECOVERABLE DATAFILE;

3. オペレーティング・システム・ユーティリティを使用して、すぐにすべてのデータファイルをバックアップします。これによって、消去されたログ・グループを使用しなくても完全リカバリを実行できるバックアップを作成します。 たとえば、次のように入力します。

% cp /disk1/oracle/dbs/*.dbf /disk2/backup

4. ALTER DATABASE文を使用して、データベースの制御ファイルをバックアップします。たとえば、次のように入力します。

SQL> ALTER DATABASE BACKUP CONTROLFILE TO '/oracle/dbs/cf_backup.f';

CLEAR LOGFILE操作の失敗

次の操作を実行できない場合、メディア障害によるI/Oエラーによって、ALTER DATABASE CLEAR LOGFILE文が失敗することがあります。

- 現在構成されているREDOログのファイル名を基にREDOログ・ファイルを再作成し、REDOログ・ファイルを代替メディアへ再配置する

- 現在構成されているログ・ファイル名が(メディア障害などによって)無効または使用できなくなったため、その名前を再利用してREDOログ・ファイルを再作成する

これらの場合には、ALTER DATABASE CLEAR LOGFILE文は(I/Oエラーを受け取る前に)、ログが消去され、アーカイブが必要なかったことを、制御ファイルに正しく通知します。CLEAR LOGFILE文が新しいREDOログ・ファイルを作成して0(ゼロ)を書き込もうとした段階でI/Oエラーが発生します。この事実はV$LOG.CLEARING_CURRENTに反映されます。

アクティブなオンラインREDOログ・グループの消失

データベースがまだ実行中であり、消失したアクティブなREDOログが現行ログでない場合は、ALTER SYSTEM CHECKPOINT文を発行します。操作が正常に実行されると、アクティブなREDOログがアクティブでなくなるため、「非アクティブのオンラインREDOログ・グループの消失」の手順を実行できます。操作が正常に実行されなかったか、またはデータベースが停止した場合は、アーカイブ・モードに応じて、この項のいずれかの手順を実行します。

現行ログとは、LGWRによって現在書込みが行われているログです。LGWRのI/O操作が失敗すると、LGWRは終了し、インスタンスで障害が発生します。この場合には、バックアップをリストアし、不完全リカバリを実行し、RESETLOGSオプションを指定してデータベースをオープンする必要があります。

NOARCHIVELOGモードでのアクティブなログが消失した場合のリカバリ

この例では、データベースのアーカイブ・モードはNOARCHIVELOGです。

NOARCHIVELOGモードでアクティブなオンライン・ログ・グループが消失した場合にリカバリを実行する手順

1. メディア障害が一時的な場合は、必要に応じてデータベースがグループを再利用できるように、問題を解決します。

2. 一貫性のあるデータベース全体(データファイルおよび制御ファイル)のバックアップからデータベースをリストアします。たとえば、次のように入力します。

% cp /disk2/backup/*.dbf $ORACLE_HOME/oradata/trgt/

3. データベースをマウントします。

STARTUP MOUNT

4. オンラインREDOログはバックアップされないため、データファイルおよび制御ファイルとともにリストアすることはできません。データベースでオンラインREDOログをリセットできるように、まず不完全リカバリを行う必要があります。

RECOVER DATABASE UNTIL CANCEL
CANCEL

5. RESETLOGSオプションを使用してデータベースをオープンします。

ALTER DATABASE OPEN RESETLOGS;

6. 一貫性のある状態でデータベースを停止します。たとえば、次のように入力します。

SHUTDOWN IMMEDIATE

7. データベース全体のバックアップを実行します。

メディア障害が一時的な場合は、必要に応じてデータベースがグループを再利用できるように、問題を解決します。メディア障害が一時的なものでない場合には、次の手順を使用します。

ARCHIVELOGモードでのアクティブなログが消失した場合のリカバリ

この例では、データベースのアーカイブ・モードはARCHIVELOGです。

ARCHIVELOGモードでアクティブなオンラインREDOログ・グループが消失した場合にリカバリを実行する手順

1. 不完全メディア・リカバリを開始して、破損したログの前のログまでリカバリします。

2. 消失したREDOログの現在の名前を、新しく作成したファイルに使用できることを確認します。使用できない場合は、破損したオンラインREDOログ・グループのメンバーの名前を新しい場所で変更します。たとえば、次のように入力します。

ALTER DATABASE RENAME FILE "/disk1/oradata/trgt/redo01.log" TO "/tmp/redo01.log";
ALTER DATABASE RENAME FILE "/disk1/oradata/trgt/redo02.log" TO "/tmp/redo02.log";

3. RESETLOGSオプションを使用してデータベースをオープンします。

ALTER DATABASE OPEN RESETLOGS;

注意:
不完全リカバリのエンドポイントから現在までの間に実行されたすべての更新を、再度実行する必要があります。

複数のREDOログ・グループの消失

オンラインREDOログの複数のグループが消失した場合には、リカバリの最も困難なログのリカバリ方法を使用します。リカバリが困難な順に示します。

1. 現行のオンラインREDOログ

2. アクティブなオンラインREDOログ

3. アーカイブされていないオンラインREDOログ

4. 非アクティブのオンラインREDOログ

フラッシュバック機能を使用しない、削除された表のリカバリ

データベースから誤って表を削除することは少なくありません。一般に、最も高速で簡単な解決方法は、フラッシュバック・ドロップ機能を使用して、表の削除を無効にする方法です。フラッシュバック表を使用できない場合(フラッシュバック・ドロップが無効になっている場合や表がPURGEオプションで削除された場合など)は、この項の手順を実行できます。

この項では、フラッシュバック・データベース機能が無効であるためにFLASHBACK DATABASEコマンドは使用できないことを想定しています。ただし、データベースの物理バックアップは存在します。可能であれば、ユーザー・エラーが発生したデータベースをオンラインのまま保ち、使用できるようにします。

注意:
強力な権限を適切なユーザーのみに付与することによって、リカバリを必要とするユーザー・エラーを減らすことができます。

誤って削除された表をリカバリする手順

1. この手順の後の手順でエラーが発生した場合に備えて、既存のデータベースのすべてのデータファイルをバックアップします。

2. データベースの部分バックアップを代替の場所にリストアします。最低限、次のものをリストアします。

- SYSTEM表領域およびSYSAUX表領域

- UNDOセグメントまたはロールバック・セグメントを含む表領域

- 取得するデータが含まれている自己完結型の表領域

3. リストアされたバックアップ制御ファイルを使用して、表が削除された直前まで、このバックアップの不完全リカバリを実行します。

4. データ・ポンプ・エクスポートを使用して、データベースの一時的にリストアされたバージョンから、消失したデータをエクスポートします。この例では、誤って削除された表がエクスポートされます。

注意:
システム監査オプションがエクスポートされます。

5. データ・ポンプ・インポート・ユーティリティを使用して、本番データベースにデータをインポートします。

6. 領域の節約のためにデータベースの一時コピーのファイルを削除します。

関連項目:
Oracle Data Pumpの詳細は、『Oracle Databaseユーティリティ』を参照してください。

SQL*Plusでのデータベースの削除

データベース(データベースを構成するデータベース・ファイル)をオペレーティング・システムから削除する必要がある場合があります。たとえば、テスト・データベースを作成した後に、そのデータベースを使用しなくなった場合などがこれに当たります。SQL文DROP DATABASEを実行すると、データベースを削除できます。

関連項目:
同等の機能を持つRMANコマンドDROP DATABASEの使用方法については、「データベースの削除」を参照してください。

SQL*Plusでデータベースを削除する手順

1. 管理者権限を使用してターゲット・データベースに接続した後、データベースがマウントされているか、または制限モードでユーザーが接続していない状態でオープンしていることを確認します。
たとえば、次のコマンドを入力します。

SQL> STARTUP RESTRICT FORCE MOUNT

2. データファイルおよび制御ファイルを、オペレーティング・システムから削除します。サーバー・パラメータ・ファイル(SPFILE)を使用している場合は、それも削除されます。
たとえば、次のコマンドを入力します。

SQL> DROP DATABASE; # deletes all database files, both ASM and non-ASM

データベースがRAWディスクに配置されている場合、このコマンドではRAWディスクの実際の特殊ファイルを削除できません。

3. オペレーティング・システム・ユーティリティを使用して、データベースに関連するすべてのバックアップおよびアーカイブ・ログを削除します。
たとえば、LinuxおよびUnixでは、次のコマンドを入力します。

% rm /backup/* /disk1/oradata/trgt/arch/*

用語集

アクティブなデータベースの複製

ターゲット・データベースのバックアップをリストアせずに、ネットワーク上に複製データベースを作成することです。この方法は、バックアップベースの複製の代替方法です。

祖先インカネーション

親インカネーションは、OPEN RESETLOGS操作後にブランチされた現行のインカネーションの元となるデータベース・インカネーションです。親インカネーションの親が祖先インカネーションです。祖先インカネーションのすべての親も祖先インカネーションです。

アーカイブ・バックアップ

通常のバックアップおよびリカバリ計画から除外されたデータベース・バックアップ。通常、このバックアップは、別のストレージ・メディアにアーカイブされ、長期間保存されます。

アーカイブREDOログ

オンラインREDOログ・グループの一杯になったメンバーのコピーであり、データベースがARCHIVELOGモードの場合に作成されます。LGWRプロセスによって各オンラインREDOログがREDOレコードで一杯になると、ログは1つ以上のREDOログのアーカイブ先にコピーされます。このコピーがアーカイブREDOログとなります。RMANは、元のアーカイブREDOログとアーカイブREDOログのイメージ・コピーを区別せず、両方をイメージ・コピーとみなします。

アーカイブREDOログの削除方針

アーカイブREDOログを削除できる場合を制御する構成可能で永続的なRMANの方針の1つ。この方針は、CONFIGURE ARCHIVELOG DELETION POLICYコマンドを使用して構成できます。

アーカイブREDOログ・フェイルオーバー

一部のアーカイブ・ログの出力先でログが欠落している場合またはログに破損ブロックが存在する場合でも、バックアップを完了できるようにするRMANの機能。たとえば、RMANは、高速リカバリ領域にバックアップしたログが破損していると判断すると、他のアーカイブ場所にあるログを検索し、正常であればそのログをかわりにバックアップします。

ARCHIVELOGモード

一杯になったオンラインREDOログをOracle Databaseでディスクにコピーするためのデータベースのモード。このモードは、データベースの作成時に指定するか、またはALTER DATABASE ARCHIVELOG文を使用して指定します。

「アーカイブREDOログ」、「NOARCHIVELOGモード」も参照してください。

アーカイブ

一杯になったオンラインREDOログ・ファイルをオフライン・ログのアーカイブ先にコピーする操作。オンラインREDOログのオフライン・コピーは、アーカイブREDOログと呼ばれます。REDOログをアーカイブするには、データベースをARCHIVELOGモードで実行する必要があります。

非同期I/O

RMANがデータの読取りまたは書込みを行っているとき、サーバー・プロセスは、1つのI/Oを開始し、そのI/Oが完了するまで待機している間に別の作業を実行できます。また、RMANは1つ目のI/Oの完了の待機に入る前に、複数のI/O操作を開始することもできます。

自動チャネル割当て

ALLOCATE CHANNNELコマンドを使用せずに、バックアップおよびリストアのタスクを実行するRMANの機能。CONFIGUREコマンドを使用すると、ディスクおよびテープのチャネルを指定できます。その後、手動でチャネルを割り当てずに、RMANのコマンド・プロンプトでBACKUPやRESTOREなどのコマンドを発行できるようになります。RMANでは、コマンドを実行するために必要なすべての構成済のチャネルが使用されます。

自動診断リポジトリ(ADR)

データベース・トレース・ファイルおよびその他の診断データを格納および整理するためのシステム管理のリポジトリ。ADRでは、データベースで発生したすべての重大なエラーの包括的なビューが示され、問題の診断と最終的な解決に必要なすべての関連データが管理されます。リポジトリには、インシデント、トレース、ダンプ、アラート・メッセージ、データ修復レコード、データ整合性チェック・レコード、SQLトレース情報、コア・ダンプなどについて記述されたデータが含まれています。

ADRベースの場所は、DIAGNOSTIC_DEST初期化パラメータによって指定されます。この場所が、1つ以上のADRホームが含まれるディレクトリとなります。各ADRホームは、適切に定義されたサブディレクトリに診断データを格納するために製品または製品インスタンスで使用されます。たとえば、Oracle Databaseインスタンスの診断データは、専用のADRホームに格納されます。このADRホームには、アラート・メッセージ用のalertサブディレクトリ、トレース・ファイル用のtraceサブディレクトリなどがあります。トレース・ファイルおよびアラート・ログの場所を特定する最も簡単な方法は、SQL問合せSELECT NAME, VALUE FROM V$DIAG_INFOを実行する方法です。

自動ストレージ管理(ASM)

Oracle Databaseファイル専用に構築された、ファイル・システムとボリューム・マネージャの両方の垂直統合。ASMによって、簡単に管理可能なディスク・グループに複数のストレージ・デバイスが統合され、サード・パーティの論理的なボリューム・マネージャを必要とせずにミラー化やストライプ化などのメリットを実現できます。

自動UNDO管理モード

UNDOデータが専用のUNDO表領域に格納されるデータベース・モード。ユーザーが実行する必要があるUNDO管理操作は、UNDO表領域の作成のみです。他のすべてのUNDO管理操作は自動的に実行されます。

補助チャネル

補助インスタンスに接続されているRMANチャネル。補助チャネルは、ALLOCATE CHANNELまたはCONFIGURE CHANNELコマンドのAUXILIARYキーワードで指定します。

補助データベース

(1)RMANのDUPLICATEコマンドを使用して、ターゲット・データベースのバックアップから作成されたデータベース。

(2)表領域のPoint-in-Timeリカバリ(TSPITR)の実行中に新しい場所にリストアされ、その後新しいインスタンス名で起動される一時データベース。TSPITR補助データベースは、リカバリ・セットと補助セットで構成されます。

補助の宛先

トランスポータブル表領域の操作で、補助インスタンスのパラメータ・ファイル、データファイル(トランスポートする表領域のデータファイル以外)、制御ファイル、オンライン・ログなどの補助セット・ファイルを格納できるディスク上の場所。

補助インスタンス

補助データベース、あるいは表領域のPoint-in-Timeリカバリ(TSPITR)またはトランスポータブル表領域の操作で使用される一時インスタンスに関連付けられているOracleインスタンス。

補助セット

TSPITRにおいて、リカバリ・セットにはないファイルのセット。ただし、TSPITR操作を正しく実行するには、これらのファイルを補助データベースでリストアする必要があります。トランスポータブル表領域の操作では、データファイル以外に、表領域のトランスポートには必要ですが、それ自体はリカバリ・セットの一部ではないその他のファイルが補助セットに含まれます。

バックアップ

(1)データベース、表領域、表、データファイル、制御ファイル、アーカイブREDOログなどのデータのバックアップ・コピー。バックアップには、(データベース・ファイル・レベルでの)物理的なものと(データベース・オブジェクト・レベルでの)論理的なものがあります。物理バックアップは、RMANを使用して1つ以上のデータファイル、制御ファイルまたはアーカイブREDOファイルをバックアップすることによって作成することができます。論理バックアップは、データ・ポンプ・エクスポートを使用して作成することができます。

(2)RMANのコンテキストでは、BACKUPコマンドの出力。バックアップの出力形式は、バックアップ・セット、プロキシ・コピーまたはイメージ・コピーのいずれかです。データベースによってアーカイブされたログは、バックアップではなくコピーとみなされます。

バックアップおよびリカバリ

メディア障害またはユーザー・エラーによるデータの消失からデータベースを保護するために必要な概念、手順および計画のセット。

バックアップ制御ファイル

制御ファイルのバックアップ。制御ファイルは、RMANのbackupコマンドまたはSQL文のALTER DATABASE BACKUP CONTROLFILE TO 'ファイル名'を使用してバックアップすることができます。

バックアップの暗号化

V$RMAN_ENCRYPTION_ALGORITHMSに表示されているアルゴリズムの1つを使用して行われるバックアップ・セットの暗号化。RMANは、バックアップ・セットに書き込まれるデータを透過的に暗号化し、これらのバックアップ・セットがRESTORE操作で必要になると復号化します。RMANには、透過モード、パスワード保護モードおよびデュアル・モードの3つの暗号化モードがあります。

バックアップ・モード

オンライン・バックアップを実行する前にALTER TABLESPACE ... BEGIN BACKUPまたはALTER DATABASE BEGIN BACKUPコマンドを発行すると開始されるデータベースのモード(ホット・バックアップ・モードとも呼ばれます)。ALTER TABLESPACE ... END BACKUPまたはALTER DATABASE END BACKUPコマンドを発行する場合は、表領域のバックアップ・モードを終了します。

オンラインの表領域のデータファイルのユーザー管理バックアップを実行する場合は、分裂ブロックが作成されないように、表領域をバックアップ・モードにする必要があります。バックアップ・モードでは、データベースへの更新によって通常より多くのREDOが作成されます。データベースでは、バッファ・キャッシュ内のブロックが使用済になるたびに、データに対する変更の記録に加えて、変更されたブロックのイメージをREDOログ・ファイルに書き込む必要があります。RMANでは、データベースをバックアップ・モードにする必要はありません。

「破損ブロック」も参照してください。

バックアップの最適化

RMANで、すでにバックアップされているファイルのバックアップを自動的にスキップできるようにする構成。バックアップの最適化を有効または無効にするには、CONFIGUREコマンドを使用します。

バックアップ・ピース

RMANのバックアップ・セットの格納に使用される物理ファイルの形式。各論理バックアップ・セットには、1つ以上の物理バックアップ・ピースが含まれています。

バックアップの保存方針

メディア・リカバリを実行するためにバックアップおよびアーカイブ・ログを保存しておく必要がある期間を決定するユーザー定義の方針。保存方針は、バックアップ冗長性またはリカバリ期間で定義できます。RMANは、現行の保存方針を満たすために必要なデータファイル・バックアップ、およびこれらのデータファイル・バックアップの完全なリカバリに必要なすべてのアーカイブREDOログを保持します。

バックアップ・セット

1つ以上のデータファイル、制御ファイル、サーバー・パラメータ・ファイルおよびアーカイブREDOログ・ファイルのバックアップ。各バックアップ・セットは、1つ以上のバイナリ・ファイルで構成されます。各バイナリ・ファイルは、バックアップ・ピースと呼ばれます。バックアップ・ピースは、RMANによってのみ作成またはリストアできる独自の形式で書き込まれます。

バックアップ・セットは、RMANのBACKUPコマンドで作成します。バックアップ・セットは、通常は1つのバックアップ・ピースのみで構成されます。RMANは、ユーザーがALLOCATE CHANNELまたはCONFIGURE CHANNELコマンドのMAXPIECESIZEオプションを使用してバックアップ・ピースのサイズを制限した場合にのみ、バックアップ・セットの内容を複数のバックアップ・ピースに分割します。

「未使用ブロックの圧縮」、「多重化」、「RMAN」も参照してください。

UNDOのバックアップの最適化

コミットされたトランザクションを記述し、含んでいるためRMANバックアップのリカバリに不要となったUNDOを除外することです。UNDOのバックアップの最適化はレベル0のバックアップおよび全体バックアップに適用されます。これは、RMANに組み込まれた動作であり、無効にすることはできません。

たとえば、ユーザーがUSERS表領域内のSALARIES表を更新するとします。この変更はUSERS表領域に書き込まれ、データの変更前のイメージはUNDO表領域に書き込まれます。次回、RMANでUNDO表領域をバックアップする際に、給与の変更のUNDOは含まれない場合があります。

バックアップ期間

バックアップ・アクティビティを完了する必要がある時間の長さ。

バックアップベースの複製

ターゲット・データベースのバックアップをリストアおよびリカバリすることによって、複製データベースを作成することです。この方法は、アクティブなデータベースの複製の代替方法です。

ベース・リカバリ・カタログ

リカバリ・カタログ・スキーマ全体。ベース・リカバリ・カタログは、リカバリ・カタログのサブセットである仮想プライベート・カタログと区別されます。

バイナリ圧縮

RMANで、バックアップ・セット内のデータに圧縮アルゴリズムを適用する方法。

ブロック・チェンジ・トラッキング

各データベース更新によって影響を受けたデータファイル・ブロックを追跡するためのデータベース・オプション。追跡情報は、ブロック・チェンジ・トラッキング・ファイルに格納されます。ブロック変更トラッキングを有効にすると、RMANでは変更トラッキング・ファイルから変更されたブロックの記録を使用して、データファイル全体を読み取るのではなく、変更されたブロックのみを読み取ることで、増分バックアップのパフォーマンスを向上させます。

ブロック・チェンジ・トラッキング・ファイル

RMANで、増分バックアップのパフォーマンスを向上させるために、変更されたブロックの記録に使用されるバイナリ・ファイル。このファイルの作成および名前の変更には、ALTER DATABASE文を使用します。

ブロック・メディア・リカバリ

Recovery ManagerのRECOVER ... BLOCKコマンドを使用して、データファイル内の指定したブロックをリカバリすることです。ブロック・メディア・リカバリでは、影響を受けたデータファイルはオンラインのままで、損傷または破損したブロックのみがリストアおよびリカバリされます。

ミラー化の解除

ディスク・ミラー化プロシージャの中断。ミラー・イメージは最新の状態ではなくなります。

チャネル

RMANのチャネルは、バックアップ・デバイスに対する1つの双方向ストリームを表します。チャネルは、DISKチャネル(ディスクI/Oの実行に使用される)またはSBTチャネル(サード・パーティのメディア・マネージャを介したI/Oの実行に使用されます)のいずれかになります。割り当てられたチャネルごとに、新しいOracle Databaseセッションが開始されます。このセッションで、バックアップ、リストアおよびリカバリの操作が実行されます。

「ターゲット・データベース」も参照してください。

チャネルのパラレル化

RMANの操作に対して複数のチャネルを割り当てることです。

データ整合性チェック

状態モニターに登録される診断プロシージャであるチェッカの起動。

チェックポイント

データベースのREDOスレッドにSCNを定義するデータ構造。チェックポイントは、制御ファイルおよび各データファイル・ヘッダーに記録され、リカバリに不可欠な要素です。

チェックサム

データまたはREDOブロックに格納されているすべてのバイトから、データベースによって計算される数値。DB_BLOCK_CHECKSUM初期化パラメータが有効になっている場合は、データベースによって、すべてのデータファイルまたはオンラインREDOログ・ブロックのチェックサムが計算され、ディスクへの書込み時にブロック・ヘッダーに格納されます。データベースでは、このチェックサムの値を使用して一貫性がチェックされます。

循環再利用レコード

RMANでバックアップおよびリカバリの操作に使用される情報が含まれている制御ファイルのレコード。これらのレコードは、論理的に円形に配置されています。使用可能なレコード・スロットが一杯の場合、制御ファイルを拡大して新規レコード用の領域を確保するか、あるいは最も古いレコードを上書きします。CONTROL_FILE_RECORD_KEEP_TIME初期化パラメータで、レコードを上書きするまでの最短保管日数を制御します。CONTROL_FILE_RECORD_KEEP_TIMEのデフォルト値は7日間です。

「非循環再利用レコード」も参照してください。

クローズ状態のバックアップ

データベースがクローズされている場合に行われる1つ以上のデータベース・ファイルのバックアップ。通常、クローズ状態のバックアップはデータベース全体のバックアップです。データベースを一貫性のある状態でクローズした場合は、バックアップ内のすべてのファイルの一貫性が保たれます。そうしなかった場合は、バックアップの一貫性が保たれません。

「一貫性のある状態での停止」、「一貫性バックアップ」も参照してください。

コールド・バックアップ

「クローズ状態のバックアップ」を参照してください。

コマンド・ファイル

RMANのコンテキストでは、RMANの一連のコマンドが含まれているクライアント側のテキスト・ファイル。コマンド・ファイルは、@コマンドまたは@@コマンドを使用してRMAN内から実行するか、@パラメータまたはCMDFILEパラメータを使用してオペレーティング・システム・プロンプトから実行できます。

完全リカバリ

バックアップのリストア後に生成されたすべてのREDOに適用される1つ以上のデータファイルのリカバリ。通常、完全メディア・リカバリは、1つ以上のデータファイルまたは制御ファイルがメディア障害によって破損した場合に実行されます。損傷されたファイルは、バックアップのリストア以降に生成されたすべてのREDOを使用して、完全にリカバリされます。

「不完全リカバリ」も参照してください。

一貫性バックアップ

メディア・リカバリを実行することなく、RESETLOGSオプションを指定してオープンできるデータベース全体のバックアップ。一貫性を保つためにこのバックアップにREDOを適用する必要はありません。ただし、一貫性バックアップを作成した時点以降に生成されたREDOを適用しないかぎり、一貫性バックアップを作成した時点以降のすべてのトランザクションが失われます。

一貫性バックアップは、データベースの一貫性のある状態での停止を実行した後でのみ作成できます。データベースは、バックアップが完了するまで再オープンしないようにする必要があります。

「ファジー・ファイル」、「非一貫性バックアップ」も参照してください。

一貫性のある状態での停止

文のIMMEDIATE、TRASACTIONALまたはNORMALのオプションを使用して、データベースを停止することです。正しく停止されたデータベースにリカバリは不要です。このデータベースはすでに一貫性のある状態になっているためです。

制御ファイルの自動バックアップ

現在の制御ファイルおよびサーバー・パラメータ・ファイルの自動バックアップ。バックアップ後、およびデータベースがARCHIVELOGモードである場合は構造変更後に、RMANによって作成されます。

制御ファイルの自動バックアップにはデフォルトのファイル名があります。この名前によって、RMANは、制御ファイルおよびリカバリ・カタログが消失した場合でも、制御ファイルをリストアできます。 デフォルトのファイル名は変更できます。

変換スクリプト

CONVERT DATABASEコマンドで生成されるスクリプトであり、宛先ホスト上でデータファイル形式を変換するために使用できます。

コピー

Oracleファイル(Oracleのデータファイル、制御ファイルおよびアーカイブREDOログ)のビットごとのイメージをディスクにバックアップすることです。コピーには、次の2つの方法があります。

- オペレーティング・システムのユーティリティ(UNIXのcpやddなど)を使用する方法。

- RMANのBACKUP AS COPYコマンドを使用する方法。

「バックアップ」も参照してください。

破損ブロック

認識されているOracle形式ではないか、または内容に内部的な一貫性がないOracleブロック。通常、破損は、ハードウェアの障害またはオペレーティング・システムの問題によって発生します。Oracleでは、破損ブロックは、論理的な破損(Oracle内部エラー)またはメディア破損(不正なブロック形式)のいずれかに識別されます。

メディア破損ブロックは、ブロック・メディア・リカバリを使用して修復するか、または破損ブロックが別のオブジェクトで再利用されるようにそのブロックが含まれているデータベース・オブジェクトを削除することによって修復できます。メディア破損の原因がハードウェア故障の場合、前述のどちらの解決策も、そのハードウェアの故障を直さなければ効果がありません。

クラッシュ・リカバリ

シングル・インスタンス・データベースがクラッシュした後か、またはOracle Real Applications Clusters構成のすべてのインスタンスがクラッシュした後のいずれかで、オンラインREDOレコードがデータベースに自動的に適用されることです。クラッシュ・リカバリでは、オンライン・ログのREDOのみが必要となります。アーカイブREDOログは必要ありません。

「リカバリする」も参照してください。

クロスチェック

ディスクまたはメディア管理カタログのファイルが、RMANリポジトリのデータに対応しているどうかを確認するチェック。テープにはメディア・マネージャによって期限切れまたは使用不可のマークが付けられることがあり、ファイルはディスクから削除されたり破損することがあるため、RMANリポジトリにはバックアップに関する古い情報が含まれる場合があります。クロスチェックを行うには、CROSSCHECKコマンドを実行します。

「検証」も参照してください。

累積増分バックアップ

レベル0の最新のバックアップ以降に変更されたすべてのブロックをバックアップする増分バックアップ。累積増分バックアップを使用してリカバリするときは、最新の累積増分バックアップを1つのみ適用する必要があります。

「差分増分バックアップ」、「増分バックアップ」も参照してください。

現行のインカネーション

データベースでREDOが現在生成されているインカネーション。

現行のオンラインREDOログ

現時点において、LGWRバックグラウンド・プロセスでREDOレコードが記録されているオンラインREDOログ・ファイル。

「REDOログ」、「REDOログ・グループ」も参照してください。

データ修復

メディア・リカバリまたはOracleフラッシュバック技術を使用して、消失または破損したデータをリカバリすることです。

データ・リカバリ・アドバイザ

永続的なデータ障害を自動的に診断し、ユーザーに修復オプションを提示し、ユーザーの要求に応じて修復を実行するOracle Databaseツール。

データベース領域

Oracleによって管理されるデータファイル、制御ファイルおよびオンラインREDOログ・ファイル用の場所。データベース領域は、DB_CREATE_FILE_DEST初期化パラメータで指定されます。

データベース・チェックポイント

SCNが最も低いスレッド・チェックポイント。データベース・チェックポイントSCNより前のSCNを持つすべての有効なREDOスレッドにおけるすべての変更が、ディスクに書き込まれていることが保証されます。

「チェックポイント」、「データファイル・チェックポイント」も参照してください。

データベース識別子

「DBID」を参照してください。

データベースのPoint-in-Timeリカバリ(DBPITR)

指定した過去の目標時点、SCNまたはログ順序番号までデータベース全体をリカバリすることです。

「不完全リカバリ」、「表領域のPoint-in-Timeリカバリ(TSPITR)」も参照してください。

データベースの登録

「登録」を参照してください。

データファイル・チェックポイント

特定のデータファイル用のデータベースのREDOスレッドにSCNを定義するデータ構造。すべてのデータファイルにチェックポイントSCNがあります。このSCNは、V$DATAFILE.CHECKPOINT_CHANGE#で参照できます。このSCNより小さいSCNを持つすべての変更がそのデータファイル内に存在することが保証されます。

データファイル・メディア・リカバリ

リストアされたデータファイルをより現在に近い時点までロールフォワードするために、リストアされたデータファイルにREDOレコードを適用することです。ブロック・メディア・リカバリを実行している場合を除いて、リカバリ中はデータファイルをオフラインにする必要があります。

DBID

データベースを区別するために内部で一意に生成される番号。Oracleでは、データベースの作成時にこの番号が自動的に作成されます。

宛先ホスト

複製データベースが存在するコンピュータ。

宛先プラットフォーム

RMANのCONVERTコマンドの使用時に、宛先データベースが実行されるプラットフォーム。宛先データベースとは、データのトランスポート先となるデータベースのことです。

差分増分バックアップ

レベル1またはレベル0の最新のバックアップ以降に変更されたすべてのブロックをバックアップするタイプの増分バックアップ。たとえば、レベル1の差分バックアップでは、RMANは、レベル1またはレベル0の増分バックアップの最新のバックアップを判断し、そのバックアップ後に変更されたすべてのブロックをバックアップします。差分バックアップは、増分バックアップのデフォルト・タイプです。差分増分バックアップを使用してリカバリする場合、RMANは、リストアされたデータファイル・バックアップ以降のすべてのレベル1の差分増分バックアップを適用する必要があります。

「累積増分バックアップ」、「増分バックアップ」も参照してください。

直系祖先パス

OPEN RESETLOGS操作が複数回行われた場合の、現行のデータベース・インカネーションの親インカネーションおよび現行のインカネーションのそれぞれの祖先インカネーションを含むインカネーション・パス。

障害リカバリ

データベースのインストールに関連するすべてのデータの消失に対する計画。たとえば、データ・センターのサーバーが火事によって破壊されたため、Oracle Databaseを新しいサーバーに再インストールして、消失したデータベースをバックアップからリカバリする必要がある場合などです。

ディスク・コントローラ

1つ以上のディスク・ドライブを制御するハードウェア・コンポーネント。

ディスク・グループ

自動ストレージ管理(ASM)によってユニットとして管理されるディスクのコレクション。ディスク・グループの構成要素には、ディスク、ファイルおよび割当て単位が含まれています。

ディスク割当て制限

ユーザーが指定する高速リカバリ領域のサイズの制限。ディスク割当て制限に達すると、Oracleによって不要なファイルが自動的に削除されます。

多重バックアップ・セット

RMANでは、多重バックアップ・セットとは、RMANによって生成される、バックアップ・セットの同一コピーのことです。元のバックアップ・セット内の各バックアップ・ピースがコピーされ、それぞれのコピーに一意のコピー番号(0tcm8u2s_1_1、0tcm8u2s_1_2など)が付けられます。

複製データベース

RMANのDUPLICATEコマンドを使用して、ターゲット・データベースのバックアップから作成されるデータベース。

「補助データベース」も参照してください。

期限切れのバックアップ

RMANリポジトリ内のステータスが(バックアップが検出されなかったことを意味します)EXPIREDであるバックアップ。CROSSCHECKコマンドの実行時に、バックアップおよびコピーが存在していないか、またはバックアップおよびコピーにアクセスできない場合、RMANはそれらのファイルを期限切れとマークします。

エクスポート

データ・ポンプ・エクスポートを使用して、論理データ(つまり、物理ファイルではないデータ)をデータベースからバイナリ・ファイルに抽出することです。その後、データ・ポンプ・インポートを使用してデータをデータベースにインポートできます。

「論理バックアップ」も参照してください。

エクスポート・ダンプ・ファイル

データ・ポンプ・エクスポート・ユーティリティによって作成されるファイル。ダンプ・ファイル・セットは、表データ、データベース・オブジェクトのメタデータ、制御情報が含まれている1つ以上のディスク・ファイルで構成されます。各ファイルは、独自のバイナリ形式で書き込まれます。

障害

データ・リカバリ・アドバイザでは、障害とは、データベースによって診断された永続的なデータの破損のことです。障害は、エラー・メッセージやアラートなどの目に見える症状として示される場合がありますが、診断された問題を表すため、症状とは異なります。障害は、データベース外にある診断データ用のリポジトリに記録されます。

障害ごとに、その障害を明確に説明する問題陳述文がデータ・リカバリ・アドバイザによって生成されます。障害の例として、アクセスできないデータファイルや破損したUNDOセグメントなどがあります。データ・リカバリ・アドバイザによって、すべての障害が1つの修復オプションまたは修復オプションのセットにマップされます。

障害優先順位

データ・リカバリ・アドバイザによって診断される障害の優先順位。クローズされていないすべての障害のステータスは、CRITICAL、HIGHまたはLOWのいずれかになります。障害のHIGHおよびLOWのステータスは、CHANGEコマンドを使用して手動で変更できます。

障害ステータス

データ・リカバリ・アドバイザによって診断される障害のステータス。すべての障害のステータスは、OPENまたはCLOSEDのいずれかになります。

ファイル・セクション

データファイル内の連続するブロックの範囲。マルチセクション・バックアップは、各セクションを個別のバックアップ・ピースにコピーすることによって、大規模なファイルをパラレルで処理します。

高速リカバリ領域

制御ファイルのコピー、オンラインREDOログのコピー、アーカイブREDOログ・ファイル、フラッシュバック・ログ、RMANバックアップなどのリカバリ関連ファイルの格納のために使用可能なオプションのディスクの場所。高速リカバリ領域内のファイルは、Oracle DatabaseおよびRMANによって自動的に管理されます。高速リカバリ領域の最大サイズは、ディスク割当て制限で指定できます。以前はフラッシュ・リカバリ領域と呼ばれていました。

フラッシュバック・データ・アーカイブ

表内のすべてのレコードに対するトランザクション関連の変更を、それらのレコードの存続期間中保存する履歴リポジトリ。フラッシュバック・データ・アーカイブでは、いくつかの論理フラッシュバック機能を使用して、非常に古い履歴データに透過的にアクセスできます。

フラッシュバック・データベース・ウィンドウ

FLASHBACK DATABASEコマンドをサポートするための十分なフラッシュバック・ログ・データが現在存在するSCNの範囲。フラッシュバック・データベース・ウィンドウは、使用可能なフラッシュバック・ログの最も古いSCNより前に延長することはできません。

フラッシュバック・ログ

フラッシュバック・データベース操作の実行に使用する、Oracleで生成されるログ。データベースでは、高速リカバリ領域へのフラッシュバック・ログの書込みのみを実行できます。フラッシュバック・ログは、順次書き込まれ、アーカイブは行われません。また、ディスクへのバックアップはできません。

フラッシュバック保存目標

データベースのフラッシュバックで戻ることができる最も古い過去の時点を示す、ユーザーが指定する時刻またはSCN。

外部のアーカイブREDOログ

LogMinerセッションのロジカル・スタンバイ・データベースで受信されるアーカイブREDOログ。通常のアーカイブ・ログとは異なり、外部のアーカイブ・ログは異なるDBIDを持ちます。このため、ロジカル・スタンバイ・データベース上ではバックアップまたはリストアできません。

分裂ブロック

任意のSCNでヘッダーとフッターが一貫性していないブロック。ユーザー管理バックアップでは、DBWRがファイルを更新するときに、オペレーティング・システム・ユーティリティを使用してデータファイルをバックアップできます。オペレーティング・システム・ユーティリティは、更新途中の状態のブロックを読み取ることができるため、バックアップ・メディアにコピーされるブロックの前半は更新されていても、後半には古いデータが含まれていることがあります。この場合、ブロックは分裂しています。

RMANを使用しないバックアップの場合は、ALTER TABLESPACE ... BEGIN BACKUPまたはALTER DATABASE BEGIN BACKUPコマンドが、分裂ブロック問題の解決策となります。表領域がバックアップ・モードのときにデータ・ブロックを変更した場合は、ブロック・イメージ全体のコピーをログに記録してから変更が行われます。このため、メディア・リカバリによって、このブロックが分裂していることが検出された場合でも、データベースはブロックを再構築できます。

全体バックアップ

増分ではないRMANのバックアップ。全体とは、バックアップされるデータベースの量を表すのではなく、バックアップが増分ではないことを表します。したがって、1つのデータファイルの全体バックアップを作成できます。

完全再同期化

RMANの処理の1つ。データベースの制御ファイル内にある変更されたメタデータを使用して、リカバリ・カタログを更新します。RMANコマンドのRESYNC CATALOGを発行すると、完全なカタログ再同期化を開始できます。(RMANでは必要に応じて再同期化が自動的に行われるため、RESYNC CATALOGを使用する必要はほとんどありません。)

ファジー・ファイル

データファイル・ヘッダーのチェックポイントSCN以上のSCNを持つブロックが1つ以上含まれているデータファイル。データベース・ライターでは、ファイル・ブロックが書込まれるたびにファイル・ヘッダーのSCNが更新されないため、ファジー・ファイルは使用できません。たとえば、バックアップ・モードのデータファイルがOracleによって更新されると、このような状況が発生します。リストアされたファジー・ファイルには、常にメディア・リカバリを実行する必要があります。

保証付きリストア・ポイント

Oracle Flashback Databaseの操作を行うためにフラッシュバック・ログがデータベースで保持されていることが保証されたリストア・ポイント。通常のリストア・ポイントとは異なり、保証付きリストア・ポイントは制御ファイルからエージ・アウトされないため、明示的に削除する必要があります。保証付きリストア・ポイントでは高速リカバリ領域内の領域が使用されますが、この領域は定義する必要があります。

ホット・バックアップ

「オンライン・バックアップ」を参照してください。

ホット・バックアップ・モード

「バックアップ・モード」を参照してください。

イメージ・コピー

単一のデータファイル、アーカイブREDOログ・ファイルまたは制御ファイルのビット単位のコピーで、次のようなものを指します。

- そのまま使用して、リカバリを実行できるもの(未使用ブロックの圧縮を使用する、RMAN固有の形式のバックアップ・セットとは異なります)。

- RMANのBACKUP AS COPYコマンド、UNIXのcpなどのオペレーティング・システムのコマンド、またはOracleアーカイバ・プロセスによって生成されます。

インカネーション

データベースの個別のバージョン。データベースのインカネーションは、RESETLOGSオプションでデータベースをオープンすると変更されますが、必要なREDOを使用できるかぎり、以前のインカネーションからバックアップをリカバリできます。

不完全リカバリ

データベースのPoint-in-Timeリカバリ(DBPITR)の同義語。

「完全リカバリ」、「メディア・リカバリ」、「リカバリする」も参照してください。

非一貫性バックアップ

バックアップ内のファイルの一部に、ファイルのチェックポイント後に行われた変更が含まれているバックアップ。このタイプのバックアップは、一貫性を持たせるためにリカバリが必要です。通常、非一貫性バックアップは、オンライン・データベース・バックアップによって作成されます。次のいずれかの理由でデータベースがクローズされている際にデータファイルをバックアップした場合も、非一貫性バックアップが作成されることがあります。

- Oracleインスタンスの1つ(Oracle RAC構成ではすべてのインスタンス)がクラッシュした直後

- SHUTDOWN ABORTを使用してデータベースを停止した後

非一貫性バックアップは、データベースがARCHIVELOGモードで、バックアップ以降に作成されたすべてのアーカイブREDOログを使用できる場合にのみ有効です。

「一貫性バックアップ」、「オンライン・バックアップ」、「システム変更番号(SCN)」、「データベース全体のバックアップ」も参照してください。

増分バックアップ

修正されたブロックのみがバックアップされるRMANのバックアップ。増分バックアップはレベルによって分類されます。レベル0の増分バックアップは、使用されたすべてのブロックをバックアップするという点では全体バックアップと同じです。全体バックアップでは後続の増分バックアップでバックアップされたブロックに影響がないのに対し、増分バックアップでは影響がある点で異なります。

レベル1の増分バックアップでは、前回の増分バックアップ以降に変更されたブロックのみがバックアップされます。変更されなかったブロックはバックアップされません。増分バックアップは、差分増分バックアップまたは累積増分バックアップのいずれかです。

増分更新バックアップ

増分バックアップによって更新される、RMANのデータファイルのコピー。データファイルをコピーして増分バックアップを作成した後、その増分バックアップをイメージ・コピーにマージするバックアップ計画が効率的です。この計画では、データ・ブロックの最新の変更を使用してイメージ・コピーが更新されるため、メディア・リカバリに必要な時間が削減されます。

インスタンス障害

ハードウェアの障害、Oracle内部エラーまたはSHUTDOWN ABORT文が原因でOracleインスタンスが終了することです。インスタンス障害が発生した場合は、常にクラッシュ・リカバリまたはインスタンス・リカバリを実行する必要があります。

インスタンス・リカバリ

Oracle RAC構成で、別のインスタンスがクラッシュしたことを検出したインスタンスによって、オープン状態のデータベースにREDOデータが適用されることです。

「リカバリする」も参照してください。

ブロック間の破損

ブロックの破損の一種。破損がブロック自体内ではなく、ブロック間で発生します。このタイプの破損は、論理的な破損のみです。

ブロック内の破損

ブロックの破損の一種。破損がブロック自体内で発生します。このタイプの破損には、物理的な破損と論理的な破損があります。

レベル0の増分バックアップ

バックアップ対象のデータファイル内のすべてのデータ・ブロックをバックアップする、RMANの増分バックアップ。 レベル0の増分バックアップの内容は全体バックアップと同じです。ただし、レベル0のバックアップは、全体バックアップと異なり、増分バックアップ計画の一部とみなされます。

多重化レベル

同時に読み取られ、RMANの同じバックアップ・ピースに書き込まれる入力ファイルの数。

LogMiner

SQL文を使用してログ・ファイルの読取り、分析および解析ができるようにするためのユーティリティ。

「アーカイブREDOログ」も参照してください。

ログ順序番号

REDOログ・ファイル内の一連のREDOレコードを一意に識別する番号。Oracleでは、1つのオンラインREDOログ・ファイルが一杯になり、別のオンラインREDOログ・ファイルに切り替わると、その新しいファイルにログ順序番号が自動的に割り当てられます。

「ログ・スイッチ」、「REDOログ」も参照してください。

ログ・スイッチ

LGWRによって、アクティブなREDOログ・ファイルへの書込みが停止され、使用可能な次のREDOログ・ファイルに切り替えられる時点。LGWRでの切替えは、アクティブなログ・ファイルがREDOレコードで一杯になるか、ユーザーが手動で強制的に切り替えた場合に行われます。

「REDOログ」も参照してください。

論理バックアップ

表などのデータベース・スキーマ・オブジェクトのバックアップ。論理バックアップは、Oracle Data Pump Exportユーティリティによって作成およびリストアされます。オブジェクトを論理バックアップからリストアするには、データ・ポンプ・インポート・ユーティリティを使用します。

論理フラッシュバック機能

Oracle Flashback Database以外のOracleフラッシュバック技術機能のセット。この論理機能を使用すると、過去の時点の個々のデータベース・オブジェクトまたはトランザクションを表示したり、個々のデータベース・オブジェクトまたはトランザクションを過去の時点まで巻き戻すことができます。

論理的破損

ブロックのチェックサムが有効で、ヘッダーとフッターは一致しているなどの点は正常ですが、内容に論理的な一貫性がない破損。

長期バックアップ

バックアップ保存方針からは除外しますが、リカバリ・カタログには記録する必要があるバックアップ。通常、長期バックアップとは、将来、レポートの生成に使用する可能性があるデータベースのスナップショットのことです。

書込み欠落

実際には書込みが発生していないにもかかわらず、I/Oサブシステムからの情報に基づいて発生がデータベースで認識された、永続ストレージへの書込み。

平均リカバリ時間(MTTR)

リカバリを実行するために必要な時間。

メディア障害

Oracleで使用されるファイル(データファイル、アーカイブREDOログ・ファイルまたは制御ファイルなど)のいずれかが含まれているディスクの損傷。Oracleでは、メディア障害が検出されると、影響を受けているファイルがオフラインになります。

「メディア・リカバリ」も参照してください。

メディア・マネージャ

データベース・バックアップを3次ストレージに直接書き込むことができるようにRecovery Managerに統合可能な、サード・パーティのネットワーク型バックアップ・システム。

メディア・マネージャによる多重化

RMANによるバックアップ中に、RMANではなくメディア・マネージャによってブロックの組合せが管理される多重化。メディア・マネージャによる多重化のタイプの1つとして、メディア・マネージャが、複数のRMANチャネルからの同時出力を単一のシーケンシャル・デバイスに書き込んだ場合に発生するものがあります。また、別のタイプとして、バックアップによって同じテープ上にデータベース・ファイルとデータベース以外のファイルが混在した場合に発生するものもあります。

メディア管理カタログ

メディア・マネージャによって管理されるレコードのカタログ。このカタログは、RMANのリカバリ・カタログは完全に無関係です。メディア管理カタログの例としては、Oracle Secure Backupカタログがあります。

メディア管理ライブラリ

RMANで3次ストレージへのバックアップに使用できるソフトウェア・ライブラリ。SBTインタフェースは、公開されているAPIに準拠しており、メディア管理ベンダーによって提供されます。Oracle Secure Backupには、RMANで使用するためのSBTインタフェースが含まれています。

メディア・リカバリ

リストアされたバックアップ・データファイルまたは個々のデータ・ブロックにREDOまたは増分バックアップを適用することです。

メディア・リカバリを実行すると、データベース、表領域、データファイル、またはデータファイル内の一連のブロックをリカバリできます。メディア・リカバリは、完全リカバリ(REDOログ内のすべての変更が適用されます)または不完全リカバリ(指定した時点までの変更のみが適用されます)のいずれかで実行できます。メディア・リカバリは、データベースがARCHIVELOGモードの場合にのみ実行できます。

「ブロック・メディア・リカバリ」、「リカバリする」も参照してください。

ミラー化

1つ以上のディスクにデータの同一のコピーを保持することです。通常、ミラー化は複製ハード・ディスク上でオペレーティング・システム・レベルで実行されるため、1つのディスクが使えない場合でも、もう一方のディスクで要求の処理を中断せずに続行できます。ファイルのミラー化では、Oracle Databaseによって1回の書込みが行われますが、オペレーティング・システムによって複数のディスクへの書込みが行われます。ファイルの多重化では、Oracle Databaseによって同じデータが複数のファイルに書き込まれます。

MTTR

「平均リカバリ時間(MTTR)」を参照してください。

多重バックアップ・セット

複数の入力ファイルのブロックが含まれているバックアップ・セット。たとえば、10個のデータファイルを1つのバックアップ・セットに多重化することができます。バックアップ・セットには、ファイルの一部ではなくファイル全体が含まれています。

多重化

この用語の意味は、多重化されるファイルによって次のように異なります。

- オンラインREDOログ
オンラインREDOログの複数の同一コピーを自動的にメンテナンスすることです。

- 制御ファイル
データベースの制御ファイルの複数の同一コピーを自動的にメンテナンスすることです。

- バックアップ・セット
データベース・ファイルをディスクから同時に読み取り、そのブロックを同一のバックアップ・ピースに書き込むRMANの機能。

- アーカイブREDOログ
Oracleアーカイバ・プロセスによってREDOログの複数のコピーがアーカイブされることです。

「ミラー化」も参照してください。

マルチセクション・バックアップ

バックアップ・ピースごとに1つのファイル・セクション(データファイル内の連続するブロックの範囲)が含まれているRMANのバックアップ・セット。マルチセクション・バックアップ・セットには複数のバックアップ・ピースが含まれていますが、バックアップ・セットにはデータファイルの一部のみが含まれるのではありません。

マルチセクション・バックアップは、BACKUPコマンドでSECTION SIZEパラメータを指定して作成します。RMANのチャネルは、各ファイル・セクションをシリアルまたはパラレルのいずれかで個別に処理できます。このため、マルチセクション・バックアップでは、複数のチャネルで単一のファイルをバックアップできます。

固有の転送レート

テープ・ドライブで、圧縮なしでテープに書き込む場合の速度。この速度は、バックアップ・レートの上限を表します。

NOARCHIVELOGモード

一杯になったオンラインREDOログを上書きする前に、OracleによってそれらのオンラインREDOログのアーカイブを要求されないデータベースのモード。このモードは、データベースの作成時に指定するか、ALTER DATABASE NOARCHIVELOGコマンドを使用して指定します。

NOARCHIVELOGモードで実行すると、消失または破損したデータのリカバリの可能性が著しく制限されます。

「アーカイブREDOログ」、「ARCHIVELOGモード」も参照してください。

非循環再利用レコード

Oracle Databaseで必要とされる重要な情報が含まれている制御ファイルのレコード。これらのレコードが自動的に上書きされることはありません。非循環再利用レコードに含まれている情報の例としては、データファイルの場所およびオンラインREDOログがあります。

「循環再利用レコード」も参照してください。

通常のリストア・ポイント

SCNまたは時刻のラベル。SCNまたは時刻がサポートされているコマンドには、多くの場合、リストア・ポイントを指定できます。通常のリストア・ポイントは循環リストに含まれており、制御ファイル内で上書きできます。ただし、リストア・ポイントがアーカイブ・バックアップに関連する場合は、リカバリ・カタログに保存されます。

不要なバックアップ

現行のバックアップ保存方針を満たす必要がないバックアップ。たとえば、データファイルごとに1つのバックアップを保持する必要があると保存方針で定められている場合に、データファイル1のバックアップが2つ存在すると、データファイル1の2つ目のバックアップは不要であるとみなされます。

NORMALモードでのオフライン

表領域は、ALTER TABLESPACE ... OFFLINE NORMAL文でオフラインにされた場合、NORMALモードでオフラインにされます。この表領域内のデータファイルにはチェックポイントが設定されるため、オンラインに戻されるまでリカバリは不要となります。表領域がNORMALモードでオフラインされていない場合、その表領域内のデータファイルは、オンラインに戻す前にリカバリする必要があります。

オフサイトのバックアップ

RMANによってリストアされる前にメディア・マネージャで取得する必要があるSBTバックアップ。RESTORE ... PREVIEWを使用すると、オフサイトのバックアップを表示できます。

オンライン・バックアップ

データベースがオープンされ、データファイルがオンラインである場合に行われる1つ以上のデータファイルのバックアップ。データベースをオープンした状態でユーザー管理のバックアップを作成する場合は、ALTER TABLESPACE BEGIN BACKUPコマンドを発行して、表領域をバックアップ・モードにする必要があります。(ALTER DATABASE BEGIN BACKUPを使用して、データベース内のすべての表領域を1回の動作でバックアップ・モードにすることもできます。)

RMANを使用してバックアップを実行する際は、表領域をバックアップ・モードにしてはいけません。

オンラインREDOログ

オンラインREDOログは、データベースに行われたすべての変更が記録される2つ以上のファイルのセットです。データベースに変更が行われるたびに、OracleによってREDOバッファにREDOレコードが生成されます。LGWRプロセスによって、REDOバッファの内容がオンラインREDOログに書き込まれます。

現行のオンラインREDOログとは、LGWRによって現在書込みが行われているオンラインREDOログを指します。LGWRはファイルの最後に到達すると、ログ・スイッチを実行し、新しいログ・ファイルへの書込みを開始します。データベースをARCHIVELOGモードで実行している場合は、一杯になった各オンラインREDOログ・ファイルをLGWRで上書きする前に、1つ以上のアーカイブ場所にコピーする必要があります。

「アーカイブREDOログ」も参照してください。

オンラインREDOログ・グループ

OracleのオンラインREDOログは、2つ以上のオンラインREDOログ・グループで構成されています。各グループには、1つ以上の同一のオンラインREDOログ・メンバーが含まれています。オンラインREDOログ・メンバーは、REDOレコードを含む物理ファイルです。

オンラインREDOログ・メンバー

オンラインREDOログ・グループ内の物理的なオンラインREDOログ・ファイル。各ログ・グループには、1つ以上のメンバーが必要です。グループの各メンバーの内容は同じです。

オペレーティング・システムのバックアップ

「ユーザー管理バックアップ」を参照してください。

オペレーティング・システムのバックアップおよびリカバリ

「ユーザー管理のバックアップとリカバリ」を参照してください。

Oracle Flashback Database

RMANまたはSQLのFLASHBACK DATABASEコマンドによって、データベース全体を以前の一貫性のあるSCNまで戻すことです。データベース・フラッシュバックは、従来のメディア・リカバリとは異なります。これは、物理ファイルのリストアを必要とせず、かわりに変更されたデータ・ブロックの保存イメージを使用して現在のデータファイルを過去の状態にリストアするためです。この機能では、フラッシュバック・ログおよびアーカイブREDOログが使用されます。

Oracleフラッシュバック技術

データ保護の層を追加するためのOracle Database機能のセット。これらの機能には、Oracle Flashback Query、Oracle Flashback Version Query、Oracle Flashback Transaction Query、Oracle Flashback Transaction、Oracle Flashback Table、Oracle Flashback Drop、Oracle Flashback Databaseなどがあります。

フラッシュバック機能を使用して、データの過去の状態を表示したり、データベースの一部またはすべてを巻き戻すことができます。通常、フラッシュバック機能が適用されるほとんどの場合は、フラッシュバック機能の方がメディア・リカバリより効率的で簡単です。

Oracle Managed Files

Oracle Managed Files機能によって管理されるデータベース・ファイル。

Oracle Managed Files(OMF)

いくつかの初期化パラメータに基づいて、制御ファイル、REDOログ・ファイル、データファイルなどのデータベース・ファイルの名前の指定、場所の設定、作成、削除を自動化するサービス。Oracle Managed Filesは、VxFSやODMなどのホスト・オペレーティング・システムでサポートされている従来のファイル・システムに加えて使用できます。データベース管理の多くの側面について独自の方針を作成する必要をなくすことによって、それらの詳細を簡略化できます。

Oracle Secure Backup

ファイル・システムをテープにバックアップすることによって、信頼性の高いデータ保護を提供するOracleメディア・マネージャ。Oracle Secure BackupのSBTインタフェースを使用すると、RMANを使用してOracle Databaseをバックアップすることもできます。SAN、ギガビット・イーサネットおよびSCSI環境のすべての主要なテープ・ドライブおよびライブラリがサポートされています。

Oracle VSSライター

Oracle Databaseインスタンスとその他のVolume Shadow Copy Service(VSS)のコンポーネントの間のコーディネータとして機能するWindowsシステム上のサービス。このサービスによって、データ・プロバイダは、Oracleインスタンスで管理されるファイルのシャドウ・コピーを作成できます。たとえば、Oracle VSSライターでは、データファイルをホット・バックアップ・モードにして、それらのデータファイルのリカバリ可能なコピーをシャドウ・コピー・セットに作成できます。

Oracle推奨バックアップ計画

Oracle Enterprise Managerでウィザードを使用して実行できるバックアップ計画。この計画では、定期的にレベル1増分バックアップをレベル0バックアップに適用して、増分更新バックアップを作成します。この計画を毎日実行することによって、ディスクからのPoint-in-Timeリカバリが24時間実行できるようになります。

孤立したバックアップ

データベースの現行のインカネーションの直系祖先パス内で作成されなかったバックアップ。孤立したバックアップは、現行のインカネーションでは使用できません。

パラレル・リカバリ

複数のプロセスによって、REDOログ・ファイルからの変更が同時に適用されるリカバリの形式。RECOVERY_PARALLELISM初期化パラメータによって、インスタンスおよびクラッシュ・リカバリのパラレル化のレベルを決定します。RECOVERコマンドのPARALLELおよびNOPARALLELオプションを使用して、メディア・リカバリのパラレル化を制御できます。リカバリの最適な並列度は、Oracle Databaseによって自動的に選択されます。通常、インスタンス・リカバリ、クラッシュ・リカバリまたはメディア・リカバリのパラレル化のレベルを手動で設定することは推奨されないか、または不要です。

親インカネーション

OPEN RESETLOGS操作後にブランチされた現行のインカネーションの元となるデータベース・インカネーション。

部分再同期化

再同期化のタイプ。この同期化では、RMANはアーカイブ・ログ、バックアップ・セットおよびデータファイルのコピーに関するデータを、ターゲット制御ファイルからリカバリ・カタログに転送します。

パスワード・ファイル

ORAPWDコマンドによって作成され、SYSDBA権限またはSYSOPER権限を使用してネットワークを介して接続する場合に必要なファイル。パスワード・ファイルの詳細は、『Oracle Database管理者ガイド』を参照してください。

物理バックアップ

物理ファイルのバックアップ。物理バックアップは、表のエクスポートなどの論理バックアップと対比されます。

物理的破損

破損ブロックがデータベースで認識されない破損。チェックサムが無効であるか、ブロックの内容がすべて0(ゼロ)であるか、またはブロックのヘッダーとフッターが一致していないため、ブロックがデータベースで認識されない場合があります。

物理スキーマ

任意の時点でデータベースに存在するデータファイル、制御ファイルおよびREDOログ。表領域およびデータファイルのリストを取得するには、RMANのREPORT SCHEMAコマンドを発行します。

フィジカル・スタンバイ・データベース

障害保護の目的で使用できる本番データベースのコピー。

Point-in-Timeリカバリ

データベース・ファイルを現在以外の時刻に不完全にリカバリすることです。Point-in-Timeリカバリは、不完全リカバリとも呼ばれます。

「メディア・リカバリ」、「リカバリする」も参照してください。

問題

自動診断リポジトリ(ADR)に記録されているデータベースの重大エラー。重大エラーには、内部エラーおよび他のサーバー・エラーが含まれています。それぞれの問題には、その問題を記述する属性のセットである問題キーがあります。問題キーには、ORAエラー番号、エラー・パラメータ値および他の情報が含まれています。

プロキシ・コピー

RMANのバックアップ処理とリストア処理時に、メディア・マネージャがメディア・ストレージ・デバイスとディスク間のデータ転送を管理するバックアップ。

RAWデバイス

ファイル・システムを持たないディスクまたはパーティション。このため、ls、Windowsエクスプローラなどでこれらの内容を確認することはできません。RAWパーティションは、Oracle Databaseでは単一ファイルとして表示されます。

リカバリする

データベース・ファイルまたはデータベースのリカバリとは、通常、メディア・リカバリ、クラッシュ・リカバリまたはインスタンス・リカバリを実行することを指します。この用語は、消失したデータをなんらかの方法で再構築または再作成する操作の総称として使用される場合もあります。

「完全リカバリ」、「不完全リカバリ」も参照してください。

リカバリ

データベース・ファイルまたはデータベースに関して使用する場合は、消失した変更を再構築するために、REDOデータまたは増分バックアップをデータベース・ファイルに適用することです。リカバリには、インスタンス・リカバリ、クラッシュ・リカバリおよびメディア・リカバリの3つのタイプがあります。Oracle Databaseでは、オンラインのREDOレコードを使用して最初の2つのタイプのリカバリが自動的に実行されます。メディア・リカバリにのみ、バックアップの リストア およびコマンドの発行が必要です。

「完全リカバリ」、「不完全リカバリ」も参照してください。

リカバリ・カタログ

1つ以上のOracle Databaseに関するRMANのリポジトリ情報を格納するために、RMANで使用されるOracleの表およびビューのセット。RMANは、このメタデータを使用して、Oracle Databaseのバックアップ、リストアおよびリカバリを管理します。

リカバリ・カタログの使用は任意ですが、使用することを強くお薦めします。たとえば、Oracle Database 11g以上では、Data Guard環境で単一のリカバリ・カタログ・スキーマがすべてのデータベースのデータベース・ファイル名を追跡できます。また、このカタログ・スキーマは、すべてのデータベースのオンラインREDOログ、スタンバイREDOログ、一時ファイル、アーカイブREDOログ、バックアップ・セットおよびイメージ・コピーが作成される場所も追跡します。

データベースに関するRMANのリポジトリ情報の1次ストレージは、常にデータベースの制御ファイル内となります。リカバリ・カタログは、制御ファイルからのRMANのリポジトリ・データで定期的に更新されます。制御ファイルが消失した場合は、データベースのリストアおよびリカバリに必要となる、消失したメタデータの大部分またはすべてがリカバリ・カタログによって提供されます。リカバリ・カタログには、アーカイブ・バックアップのレコード、およびターゲット・データベースで使用するRMANストアド・スクリプトのレコードも記録できます。

「リカバリ・カタログ・データベース」も参照してください。

リカバリ・カタログ・データベース

リカバリ・カタログ・スキーマが含まれているOracle Database。リカバリ・カタログはターゲット・データベースには格納できません。

リカバリ・カタログ・スキーマ

リカバリ・カタログの表およびビューが含まれている、リカバリ・カタログ・データベースのスキーマ。

Recovery Manager (RMAN)

Oracle Databaseの物理バックアップおよびリカバリに使用されるプライマリ・ユーティリティ。RMANは、RMANリポジトリと呼ばれる独自の構造にOracle Databaseのレコードを保持し、バックアップのストレージを管理し、バックアップを検証します。これは、リカバリ・カタログと呼ばれる中央情報リポジトリとあわせて使用することも、またリカバリ・カタログなしで使用することもできます。リカバリ・カタログを使用しない場合、RMANは、バックアップおよびリカバリの操作に必要な情報を格納するために、データベースの制御ファイルを使用します。RMANをサード・パーティのメディア管理ソフトウェアとともに使用すると、ファイルを3次ストレージにバックアップできます。

「バックアップ・ピース」、「バックアップ・セット」、「コピー」、「メディア・マネージャ」、「リカバリ・カタログ」も参照してください。

リカバリ・セット

表領域のPoint-in-Timeリカバリ(TSPITR)の実行時、以前の時点までのリカバリが行われる1つ以上の表領域。TSPITRの実行後は、リカバリ・セット内のすべてのデータベース・オブジェクトが同じ時点までリカバリされています。

「補助セット」も参照してください。

リカバリ期間

RMANバックアップ保存方針のタイプの1つ。DBAが期間を指定し、RMANが、リカバリ期間内の任意の時点までのPoint-in-Timeリカバリに必要なバックアップおよびアーカイブREDOログが保存されることを保証します。この期間は常に、現在の時刻で終了し、ユーザーが指定した日数までさかのぼります。

たとえば、保存方針が7日間のリカバリ期間で設定されている場合、現在の時刻が火曜日の午前11時であれば、RMANは前の週の火曜日の午前11時までのPoint-in-Timeリカバリに必要なバックアップを保持します。

ごみ箱

削除されたオブジェクトに関する情報が含まれているデータ・ディクショナリ表。削除された表および関連するオブジェクト(索引、制約、ネストした表など)は、実際には削除されず、領域を占有しています。フラッシュバック・ドロップ機能では、削除されたオブジェクトを取得するためにごみ箱が使用されます。

REDOログ

オンラインREDOログ or an アーカイブREDOログのいずれかを指します。オンラインREDOログは、Oracleデータファイルおよび制御ファイルに対するすべての変更を記録する複数のREDOログ・グループのセットです。アーカイブREDOログは、オフラインの宛先に書き込まれたオンラインREDOログのコピーです。

REDOログ・グループ

オンラインREDOログの各メンバー(それぞれがオンラインREDOログ・ファイルに対応する)は、1つのREDOログ・グループに属しています。REDOログ・グループには、1つ以上のメンバーが含まれています。複数のメンバーが含まれているREDOログ・グループは、多重REDOログ・グループと呼ばれます。REDOログ・グループのすべてのメンバーの内容は同一です。

REDOスレッド

インスタンスによって生成されるREDO。データベースがシングル・インスタンス構成で実行されている場合、そのデータベースにはREDOのスレッドが1つのみ存在します。

冗長性

保存方針において、バックアップされた各ファイルの多数のコピーを保持するように指定する設定。冗長性ベースの保存方針は、リカバリ期間を使用する保存方針と対比されます。

冗長性セット

任意のOracle Databaseファイルの障害または消失からのリカバリを可能にするバックアップのセット。

登録

RMANで、REGISTER DATABASEコマンドを実行し、ターゲット・データベースの存在をリカバリ・カタログに記録します。ターゲット・データベースは、そのDBIDによってカタログ内で一意に識別されます。複数のデータベースを同じカタログに登録することも、同じデータベースを複数のカタログに登録することもできます。

修復

データ・リカバリ・アドバイザでは、修復とは1つ以上の障害を修正するための単一または一連の処理のことです。修復の例としては、ブロック・メディア・リカバリ、データファイルのメディア・リカバリ、Oracle Flashback Databaseなどがあります。

修復オプション

データ・リカバリ・アドバイザでは、障害を修復するために使用可能な方法の1つ。同じ問題を修正するための様々な修復オプションがありますが、それぞれの方法に、修復時間およびデータ消失の点で異なるメリットおよびデメリットがあります。

RESETLOGS

データベースをオープンする方法の1つ。現行のオンラインREDOログをアーカイブし(ARCHIVELOGモードを使用している場合)、ログ順序番号を1にリセットし、オンラインREDOログをクリアする方法です。ALTER DATABASE OPEN RESETLOGS文によって、新しいデータベース・インカネーションが開始されます。新しいインカネーションの開始SCN(RESETLOGS SCNとも呼ばれます)は、OPEN RESETLOGSの前に行われたメディア・リカバリの不完全リカバリSCNに1を足したものになります。

不完全リカバリまたはバックアップ制御ファイルを使用したリカバリの後には、ALTER DATABASE OPEN RESETLOGS文を実行する必要があります。OPEN RESETLOGS操作は、データベースのリカバリ可能性には影響を与えません。OPEN RESETLOGS操作前からのバックアップは有効なままであり、OPEN RESETLOGS操作後に行われたバックアップとともに、データベースの損傷の修復に使用できます。

分割されたミラーの復元

分割されたミラーの内容を、分割元のストレージ・デバイスの内容と同一にするプロセス。ミラーを管理しているオペレーティング・システムまたはハードウェアは、破損したミラーを最新のミラーから更新し、両方のミラーを保持します。

再開可能バックアップ

RMANで、指定した日付以降にバックアップされていないファイルのみをバックアップできるようにする機能。再開可能単位は最後に完了したバックアップ・セットまたはイメージ・コピーです。バックアップが失敗した場合にこの機能を使用すると、失敗したバックアップで処理されなかったデータベースの部分をバックアップできます。

リストア

消失または損傷したファイルをバックアップと置き換えることです。ファイルをリストアするには、UNIXのcpなどのコマンドまたはRMANのRESTOREコマンドを使用します。

リストア・フェイルオーバー

破損したバックアップまたはアクセスできないバックアップが検出された場合にリストア操作で使用できるバックアップをRMANで自動的に検索することです。

リストアの最適化

RMANで、可能な場合、バックアップからデータファイルがリストアされないようにするデフォルトの動作。

リストア・ポイント

データベースのSCNに関連付けられているユーザー定義の名前。SCNはリストア・ポイントが作成された時刻に対応します。リストア・ポイントには、保証付きリストア・ポイントまたは通常のリストア・ポイントがあります。

再同期化

ターゲット・データベースの制御ファイルの現行のメタデータを使用して、リカバリ・カタログを更新する操作。RESYNC CATALOGコマンドを発行すると、カタログの完全再同期化を開始できます。部分再同期化では、アーカイブREDOログ・ファイル、バックアップ・セットおよびデータファイルのコピーに関する情報をリカバリ・カタログに転送します。RMANは、必要に応じてリカバリ・カタログを自動的に再同期化します。

保存方針

「バックアップの保存方針」を参照してください。

逆再同期化

Data Guard環境では、リカバリ・カタログから取得したメタデータを使用して、プライマリ・データベースまたはスタンバイ・データベースの制御ファイルを更新することです。たとえば、接続されているターゲット・データベースではないスタンバイ・データベースにRMANの永続設定を構成すると、次回RMANがターゲットとしてスタンバイ・データベースに接続する際に逆再同期化が実行されます。このようにして、リカバリ・カタログではData Guard環境での制御ファイル内のメタデータが最新に保たれます。

RMAN

「Recovery Manager (RMAN)」を参照してください。

RMANバックアップ・ジョブ

単一のRMANセッション内で実行されるBACKUPコマンドのセット。たとえば、RMANクライアントを起動し、BACKUP DATABASE、BACKUP ARCHIVELOGおよびRECOVER COPYを実行してRMANクライアントを終了します。RMANバックアップ・ジョブは、データベースのバックアップおよびアーカイブREDOログのバックアップで構成されます。

RMANクライアント

コマンドを解釈し、それらのコマンドを実行するようにサーバー・セッションに指示し、そのアクティビティをターゲット・データベースの制御ファイルに記録するOracle Database実行可能ファイル。このRMAN実行可能ファイルは、データベースとともに自動的にインストールされ、通常、他のデータベース実行可能ファイルと同じディレクトリに配置されます。たとえば、Linux上のRMANクライアントはrmanと名付けられ、$ORACLE_HOME/binに格納されます。

RMANジョブ

RMANセッションで実行されるRMANコマンドのセット。たとえば、RMANクライアントを起動し、BACKUP DATABASE、BACKUP ARCHIVELOGおよびRECOVER COPYを実行してRMANクライアントを終了します。RMANジョブは、2回のバックアップ、およびデータファイルのコピーのロールフォワードで構成されます。

RMANのメンテナンス・コマンド

RMANのメタデータ・レコードおよびバックアップの管理に使用できるコマンド。メンテナンス・コマンドには、CATALOG、CHANGE、CROSSCHECKおよびDELETEがあります。

RMANリポジトリ

ターゲット・データベース上で行われたバックアップおよびリカバリ操作に関するRMANのメタデータのレコード。RMANリポジトリの正式なコピーは、常にターゲット・データベースの制御ファイルに格納されます。リカバリ・カタログを使用して、RMANリポジトリを長期間保存することもできます。また、リカバリ・カタログは、データベースの制御ファイルが消失した場合にRMANリポジトリ・データの代替ソースとして使用できます。

「リカバリ・カタログ・データベース」、「再同期化」も参照してください。

RMANセッション

RMANセッションは、RMANクライアントの起動時に開始され、クライアントの終了時またはRMANプロセスの完了時に終了します。単一のRMANセッションで複数のRMANコマンドを実行できます。

ロールバック・セグメント

データベースに対する変更の変更前のイメージが記録されたデータベース・セグメント。

ロールバック

リカバリのロールフォワード段階でデータベースに適用される、コミットされていない変更を、ロールバック・セグメントを使用して取り消すことです。

ロールフォワード

データファイルおよび制御ファイルに行われた変更のリカバリを行うために、それらのファイルに対してREDOレコードまたは増分バックアップを適用することです。

「ロールバック」も参照してください。

RUNブロック

順次実行される、一連のRMANコマンド。

SBT

テープへのシステム・バックアップ。この用語は、ディスク以外のバックアップ・デバイス・タイプを表します。通常はテープ・ライブラリまたはテープ・ドライブです。RMANでは、ディスクおよびSBTのタイプのチャネルがサポートされています。

シャドウ・コピー

Windows上のVolume Shadow Copy Service(VSS)インフラストラクチャでは、コンポーネントまたはボリュームの一貫性のあるスナップショットのことです。

スナップショット制御ファイル

Recovery Managerによって、オペレーティング・システム固有の場所に作成されたデータベース制御ファイルのコピー。RMANは、リカバリ・カタログの再同期化または制御ファイルのバックアップを行う際に使用する制御ファイルの一貫性のあるバージョンを確保するために、スナップショット制御ファイルを作成します。

ソース・データベース

複製データベースの作成時にコピーするデータベース。

ソース・ホスト

ソース・データベースが存在するホスト。

ソース・プラットフォーム

RMANのCONVERTコマンドの使用時に、ソース・データベースが実行されているプラットフォーム。ソース・データベースには、異なるプラットフォームで実行されているデータベースにトランスポートされるデータが含まれています。

ミラーの分割によるバックアップ

以前にミラー化されたデータベース・ファイルのバックアップ。サード・パーティ・ツールには、ディスクまたは論理デバイスのセットをミラー化(プライマリ・データの正確な複製を別の場所に保持)できるものがあります。ミラーを分割すると、ファイルのコピーが分離されるため、それぞれを別々に使用できます。データベース機能のALTER SYSTEM SUSPEND/RESUMEを使用すると、データベースに対するI/Oを一時停止した後、ミラーを分割し、分割されたミラーのバックアップを作成できます。

ストアド・スクリプト

リカバリ・カタログに格納された一連のRMANコマンド。ストアド・スクリプトには、グローバルとローカルの2種類があります。グローバル・スクリプトは、リカバリ・カタログに登録されたすべてのデータベースで共有できます。

同期I/O

RMANがデータの読取りまたは書込みをするとき、サーバー・プロセスは一度に1つのタスクのみを実行できます。

システム変更番号(SCN)

過去のある時点でのデータベースのコミットされたバージョンを定義するスタンプ。Oracleでは、コミットされたすべてのトランザクションに一意のSCNが割り当てられます。

表領域の格納場所

トランスポータブル表領域の操作では、表領域のトランスポートコマンドの完了時にデータファイルのコピーおよびその他の出力ファイルが(デフォルトで)含まれるディスク上の場所。

表領域のPoint-in-Timeリカバリ(TSPITR)

SYSTEM以外の1つ以上の表領域を現在以外の時刻にリカバリすることです。TSPITRの実行にはRMANを使用します。

タグ

RMANのバックアップの識別子。バックアップ・セットを生成した場合、タグはそのバックアップ・セットではなく、各バックアップ・ピースに割り当てられます。バックアップのタグを指定しなかった場合、RMANはタグを自動的に割り当てます。

ターゲット・データベース

RMAN環境では、TARGETとして接続されたデータベースのことです。ターゲット・データベースは、RMANの操作を実行するデータベースです。

ターゲット・ホスト

ターゲット・データベースが存在するコンピュータ。

ターゲット・インスタンス

RMAN環境では、ターゲット・データベースに関連付けられているインスタンスのことです。

一時ファイル

一時表領域に属し、TEMPFILEオプションで作成されたファイル。一時表領域には、表などの永続的なデータベース・オブジェクトを含めることはできません。通常、一時表領域はソートの目的で使用されます。一時ファイルには永続的オブジェクトが含まれていないため、RMANは一時ファイルをバックアップしません。ただし、RMANは制御ファイルの一時ファイルの場所を追跡し、リカバリ中、必要に応じてその場所に一時ファイルを再作成します。

トランスポート・スクリプト

CONVERT DATABASEコマンドによって生成されるスクリプト。このスクリプトには、宛先プラットフォーム上の新しいデータベースの作成に使用するSQL文が含まれています。

トランスポータブル表領域

表領域のセットを、1つのデータベースから別のデータベースに、または1つのデータベースからそのデータベース自身にトランスポートする機能。表領域をデータベースにトランスポートすることは、ロードされたデータを使用して表領域を作成することに似ています。

トランスポータブル表領域セット

トランスポータブル表領域操作での表領域のセットのデータファイル、および表領域のセットのメタデータが含まれているエクスポート・ファイル。エクスポートを実行するには、データ・ポンプ・エクスポートを使用します。

試行リカバリ

RMANまたはSQL*PlusのRECOVER ... TESTコマンドで開始されるリカバリのシミュレーション。試行リカバリは、通常のメディア・リカバリのような方法でREDOを適用しますが、ディスクに変更を書き込むことはなく、必ず変更をロールバックします。試行リカバリはメモリー内でのみ発生します。

UNDO保存期間

Oracle Databaseで、UNDO表領域内の古いUNDOデータを上書きするまでの最短保存期間。現行のUNDO保存期間より前の古い(コミットされた)UNDOデータは、期限切れと呼ばれます。現行のUNDO保存期間内の古いUNDOデータは、期限内と呼ばれます。

UNDO表領域

データベースが自動UNDO管理モードで実行されているときに、ロールバック情報のみが格納される専用表領域。

未使用ブロックの圧縮

RMANで、データ・ブロックをスキップすることによってデータファイル・バックアップ・セットのサイズを小さくする機能。RMANでは、一度も使用されていないブロックが常にスキップされます。特定の条件(『Oracle Databaseバックアップおよびリカバリ・リファレンス』のBACKUP AS BACKUPSETエントリに関する項を参照)では、以前に使用されていましたが、現在は使用されていないブロックもRMANによりスキップされます。

ユーザー管理バックアップ

オペレーティング・システムのユーティリティを使用する方法などのRMAN以外の方法を使用して行われるバックアップ。たとえば、Linuxでcpコマンドを実行するか、またはWindowsでCOPYコマンドを実行することによって、ユーザー管理バックアップを作成できます。ユーザー管理のバックアップは、オペレーティング・システムのバックアップとも呼ばれます。

ユーザー管理のバックアップとリカバリ

RMANを使用しないOracle Databaseのバックアップおよびリカバリ計画。オペレーティング・システムのバックアップおよびリカバリとも呼ばれます。オペレーティング・システムのユーティリティ(UNIXのcpコマンドなど)を使用してデータベース・ファイルをバックアップおよびリストアしてから、SQL*PlusのRECOVERコマンドを使用してリカバリできます。

検証

RMANのコンテキストでは、データベース・ファイルにブロックの破損がないかどうかをチェックするテスト、またはバックアップ・セットをチェックしてリストア可能かどうかを判断するテスト。RMANではブロックの物理的および論理的な破損をチェックできます。

仮想プライベート・カタログ

データベース・ユーザーがアクセス権限を付与されている、リカバリ・カタログ内のメタデータのサブセット。ベース・リカバリ・カタログの所有者は、他のデータベース・ユーザーに対してリカバリ・カタログへの制限付きアクセス権限の付与または取消しを行うことができます。制限付きユーザーは、それぞれ独自の仮想プライベート・カタログへの完全な読取り/書込み権限を持っています。

Volume Shadow Copy Service (VSS)

Windowsサーバー・プラットフォームのインフラストラクチャの一種。これによって、リクエスタ、ライターおよびプロバイダは、シャドウ・コピーと呼ばれる一貫性のあるスナップショットの作成に参加できます。VSSサービスでは、適切に定義されたCOMインタフェースが使用されます。VSSとともにRMANを使用する方法については、『Oracle Databaseプラットフォーム・ガイドfor Microsoft Windows』を参照してください。

データベース全体のバックアップ

データベースに属する制御ファイルおよびすべてのデータファイルのバックアップ。

索引
A B C D E F G H I J K L M N O P Q R S T U V W

記号

%b置換変数

SET NEWNAME, 25.1.1.1

%d置換変数

BACKUP FORMAT, 2.4.3

%f置換変数

SET NEWNAME, 25.1.1.1

%I置換変数

SET NEWNAME, 25.1.1.1

%N置換変数

SET NEWNAME, 25.1.1.1

%p置換変数

BACKUP FORMAT, 2.4.3

%s置換変数

BACKUP FORMAT, 2.4.3

%t置換変数

BACKUP FORMAT, 2.4.3

%U置換変数, 9.2.3.1

BACKUP FORMAT, 2.4.3

SET NEWNAME, 25.1.1.1

A

ABORTオプション

SHUTDOWN文, 29.5, 30.1.1, 30.1.2

アクティブなデータベースの複製, 4.5.4, 24.1.2.1.1 Advanced Compressionオプション, 6.2.5.3 Advanced Security Option, 6.2.6.1, 8.3.5 ADVISE FAILUREコマンド, 15.1.2.4, 15.4 アラート・ログ, 12.2.2, 23.1.1 ALLOCATE CHANNELコマンド, 5.1.4.1, 6.1.1, 9.2.3.1

MAXPIECESIZEオプション, 6.2.2

ALLOW ... CORRUPTION句, RECOVERコマンド, 29.6.5 ALTER DATABASE文

CLEAR LOGFILE句, 30.7.2.1.3

END BACKUP句, 28.3.2.3.1

OPEN RESETLOGS句, 13.8.5

RECOVER句, 29.2.4.2, 29.3.1, 29.3.2

RESETLOGSオプション, 29.5

ALTER SYSTEM文

KILL SESSION句, 23.4.1

RESUME句, 28.6.2

SUSPEND句, 28.6.2, 28.6.2

ALTER TABLESPACE文

BEGIN BACKUP句, 28.3.2.1, 28.3.2.2.2

END BACKUPオプション, 28.3.2.2.2

アプリケーション・エラー, 1.1.1.3 アーカイブ・バックアップ, 1.1.2, 9.6.1, 9.6.1, 12.4.2.2 アーカイブREDOログの削除方針, 5.6.1, 5.6.2, 9.4.3 アーカイブREDOログ・ファイル

メディア・リカバリ時の適用, 29.2.1, 29.2.3, 29.2.4.2

バックアップ, 9.4.2

RMANの使用, 9.4

他のバックアップ, 9.4.1.2

カタログに追加, 12.4.3 デフォルトの場所の変更, 29.2.4.1 破損, 29.6.1 削除, 14.3.1, 29.3.1 バックアップ後の削除, 9.4.1 フェイルオーバー, 9.4.1.1 互換性のないフォーマット, 29.6.1 リカバリ時の位置, 29.2.1 消失, 29.4 RMANを使用したリストア, 17.2.5 ARCHIVELOGモード

バックアップ, 2.4.1

AS SELECT句

CREATE TABLE文, 30.5

認証, RMAN, 2.2 自動バックアップ, 制御ファイル, 8.6, 8.6, 9.3.3, 9.6.2

構成, 5.1.5

書式, 5.1.5.1

自動修復

データ・リカバリ・アドバイザ, 1.4

自動チャネルの割当て, 6.1.1 自動チャネル, 3.3, 3.3.2

構成, 6.1.2

ネーミング規則, 3.3.2

上書き, 6.1

自動診断リポジトリ(ADR), 5.2.4.1, 8.6.2, 12.2.1, 15.1.2.2, 16.1.2.2, 16.1.2.4, 23.1.1 自動ストレージ管理(ASM)

バックアップ, 9.2.3

自動ワークロード・リポジトリ(AWR), 7.5.4 AUTORECOVERYオプション

SET文, 29.2.2

補助チャネル, 24.1.2.3 補助インスタンスのパラメータ・ファイル

TRANSPORT TABLESPACEを使用, 26.2

可用性

RMANのバックアップ, 12.4.2.1

AVAILABLEオプション

CHANGEコマンド, 12.4.2.1

B

バックアップおよびリカバリ

定義, 1.1

概要, 1

ソリューション, 1.2

計画, 1.1.1

ユーザー管理, 1.2

BACKUPコマンド, 2.4, 2.4.1, 2.4.2, 3.3.2, 3.7.2.3, 5.3.5, 5.5.1, 6.1.1, 6.2.1, 6.2.4, 8.1, 8.1, 8.3, 9.1.2, 9.4.3

ARCHIVELOGオプション, 9.4.1.2, 9.4.2

AS COMPRESSION BACKUPSETオプション, 9.2.5

AS COPYオプション, 2.4, 8.4.1, 8.4.1

BACKUPSETオプション, 6.2.6.1, 6.2.6.1, 8.5, 8.5.2.1, 8.5.2.1, 8.5.2.1, 9.7.1, 9.7.1, 9.7.2

CHANNELオプション, 5.1.4.3

COMPRESSED BACKUPSETオプション, 9.2.5

COPIESパラメータ, 8.5, 8.5.1

COPY OFオプション, 8.5, 8.5.2.2, 9.7.1, 9.7.3

CURRENT CONTROLFILEオプション, 9.3.3, 9.3.3.1

DATABASEオプション, 9.3.1

DATAFILEオプション, 9.3.2

DB_FILE_NAME_CONVERTパラメータ, 8.4.1, 8.4.1

DELETE INPUTオプション, 9.4.4, 9.4.4, 12.5.1.1

DELETEオプション, 9.4.1

DEVICE TYPE句, 5.1.2, 5.5.1, 9.2.1, 9.2.1, 9.3.3.1

DURATIONパラメータ, 10.8.2

FILESPERSETパラメータ, 8.3.9

FOR RECOVER OF COPYオプション, 9.5.4.1

FORMATパラメータ, 2.4.3, 5.2.3, 5.2.5.1, 8.3.6, 8.5.1, 9.2.3

INCREMENTALオプション, 2.4.4, 2.4.4, 2.4.4.1, 9.5, 9.5.3, 9.5.3.1

KEEPオプション, 9.6.1, 9.6.3.1, 9.6.3.1, 9.6.4

MAXSETSIZEパラメータ, 10.1

NOT BACKED UP句, 9.4.3

PLUS ARCHIVELOGオプション, 9.4.1.2, 9.4.1.2

PROXY ONLYオプション, 8.3.10, 8.3.10

PROXYオプション, 8.3.10

RECOVERY AREAオプション, 9.7.1

SECTION SIZEパラメータ, 8.3.1, 10.1.3

SPFILEオプション, 9.3.4

TABLESPACEオプション, 9.3.2

TAGパラメータ, 2.4.3, 9.2.4.1, 9.2.4.1

VALIDATEオプション, 2.4.5, 15.1.2.2, 15.3, 16.2

BACKUP CONTROLFILE句

ALTER DATABASE文, 28.1.1, 28.1.1

BACKUP COPIESパラメータ

CONFIGUREコマンド, 6.2.3

バックアップの暗号化, 6.2.6.1, 8.3.5, 14.2.1

バックアップの復号化, 17.3.1.2

デフォルト・アルゴリズム, 6.2.6

デュアル・モード, 6.2.6.1.3, 10.6.4

概要, 10.6

パスワード, 6.2.6.1.2, 10.6.3

透過, 6.2.6.1.1, 6.2.6.1.1, 10.6.2

バックアップ・モード, 8.4.2

ALTER DATABASE END BACKUPを使用した終了, 28.3.2.3.1

オンラインのユーザー管理バックアップ, 8.2, 28.3.2.1

インスタンス障害, 28.3.2.3

バックアップの最適化, 9.4.3

構成, 5.5, 10.2

定義, 5.5.1, 9.4.3

無効化, 5.5.1, 5.5.3

有効化, 5.5.1, 5.5.3

冗長性, 5.5.2.2

保存方針, 5.5.2

バックアップ・ピース, 8.3.1

定義, 2.4

最大サイズ, 6.2.2

名前, 8.3.6

テープ上の名前, 5.2.5.1

バックアップ保存方針, 1.1.2, 3.6, 5.3.1

バックアップの最適化への影響, 5.5.2

構成, 5.4, 5.4

冗長性の構成, 5.4.1

定義, 8.8

無効化, 5.4.3

バックアップの除外, 9.6.1, 12.4.2.2

リカバリ期間, 8.8

リカバリ期間, 5.4.2

冗長性, 8.8, 8.8.2

バックアップ・セット, 2.4, 8.1

バックアップ, 8.5.2.1, 8.5.2.1, 9.7.1

圧縮, 5.1.3, 6.2.5, 9.2.5

デフォルトの構成, 5.1.3

最大サイズの構成, 6.2.1

クロスチェック, 12.4.1.1

多重化, 10.4

RMANでの生成方法, 8.3.8

サイズの制限, 8.3.8

最大サイズ, 6.2.1, 10.1

多重, 2.4, 6.2.1, 8.3.9, 9.2.4.2, 22.2.1.1

ネーミング, 8.3.6

概要, 8.3

最大サイズの指定, 8.3.7

数の指定, 8.3.8

リストアのテスト, 17.2.4

バックアップ計画

高速リカバリ領域, 5.3

バックアップ・タグ, RMAN, 9.2.4 バックアップ方法, 比較, 1.2 バックアップ期間, 10.8.1 バックアップベースの複製, 24.1.2.1.1 バックアップ

アーカイブ, 1.1.2, 9.6.1

アーカイブREDOログ

RMANの使用, 9.4

可用性, 12.4.2.1 バックアップ・セット, 9.7.1 バックアップ, 8.5.2.1 クローズ, 28.2 一貫性, 28.2, 28.2

RMANを使用した作成, 8.1.1

制御ファイル, 9.3.3, 28.4 制御ファイル, 28.4

バイナリ, 28.4.1

RMANチャネルの関連付け, 23.2.2.2.1, 23.2.2.2.2 クロスチェック, 12.4.1, 12.4.1 累積増分, 8.7.1.2 データファイル

RMANの使用, 9.7.2, 9.7.3

DBVERIFYユーティリティ, 28.9 RMANのデフォルト・タイプ, 5.1.3 データファイルのステータスの確認, 28.1.2 多重化, 6.2.3, 6.2.3, 10.4 バックアップからの表領域の除外, 6.2.4 保存方針からの除外, 12.4.2.2 期限切れ, 削除, 12.5.4 レポートの生成, 11.1.2, 11.3.1 イメージ・コピー, 8.4 非一貫性, 28.2

RMANを使用した作成, 8.1.1

増分, 8.7.1.1, 9.5, 10.4.1, 10.4.2 増分更新, 9.5.4 必要なファイルの表示, 28.1 論理, 1.1.1 長期, 1.1.2 管理, 12.1.1 マルチセクション, 3.3.2, 8.3.1, 16.2 NOARCHIVELOGモード, 9.3.5 不要, 8.8.3, 12.5.5 オフライン, 28.3.1, 28.3.1, 28.3.1 オフサイト, 17.2.3.1 最適化, 5.5.1, 9.4.3 孤立, 14.3.2.3 物理, 1.1.1 プレビュー, 17.2.3 読取り専用表領域, 28.3.2.4 RESETLOGSの実行前のリカバリ, 18.6.3 リカバリ・カタログ, 13.6.1, 13.6.1 Recovery Manager, 9.1.2 バックアップが必要なオブジェクトのレポート, 11.3.2 再開可能, 10.7.1 ユーザー管理バックアップのリストア, 29.2.1 サーバー・パラメータ・ファイル, 9.3.4 ファイルのスキップ, 10.3 分割されたミラー, 8.4.2

RMANの使用, 10.5

ストアド・スクリプト, 13.1.2.4, 13.7.1 表領域, 28.3.2.2

RMANの使用, 9.3.2, 9.7.2, 9.7.3

RMANのテスト, 16.1.2.4, 16.2, 16.2, 16.3, 16.3

メディア・マネージャの使用, 5.2.4.2

ユーザー管理, 28 検証, 16.2, 16.2, 16.3, 16.3 検証, 28.9 データベース全体, 9.3.1, 9.3.1, 28.2 BEGIN BACKUP句

ALTER TABLESPACE文, 28.3.2.1

バックアップのバイナリ圧縮, 9.2.5 ブロック・チェンジ・トラッキング, 1.2, 8.7.2, 9.5.5, 9.5.5

使用されるディスク領域, 9.5.5.1.3

有効化と無効化, 9.5.5.2, 9.5.5.2, 9.5.5.3, 9.5.5.3

チェンジ・トラッキング・ファイルの移動, 9.5.5.5

ブロックの破損, 1.1.1.3

V$DATABASE_BLOCK_CORRUPTIONに格納, 16.2

ブロック・メディア・リカバリ, 1.1.1.3, 16.1.2.4

自動, 19.1.2

BSP。「Backup Solutions Program(BSP)」を参照, 3.5.3

C

取消しベースのメディア・リカバリ, 29.4.2

RMANコマンドの取消し, 23.4

CATALOGコマンド, 12.4.3, 12.4.3

START WITHパラメータ, 13.4

CHANGEコマンド

AVAILABLEオプション, 12.4.2.1

DB_UNIQUE_NAMEパラメータ, 13.8.3

RESET DB_UNIQUE_NAMEオプション, 3.7.2.2

UNCATALOGオプション, 12.4.4.1

CHANGE FAILUREコマンド, 15.6 チャネル, RMAN, 3.3, 3.3

補助, 24.1.2.3

構成, 5.1.4

高度なオプションの構成, 6.1

定義, 2.3, 3.3

一般, 5.1.4.1

ネーミング規則, 3.3.2

Oracle RAC環境, 6.1.2

パラレル, 5.1.4.3

キャラクタ・セット

RMANで使用される設定, 4.3

循環再利用レコード, 12.2.1 CLEAR LOGFILE句

ALTER DATABASE, 30.7.2.1.3

クライアント, RMAN, 2.1, 2.1, 3.1, 3.5 コールド・フェイルオーバー・クラスタ

定義, 28.3.2.3

コマンド・ファイル, RMAN, 2.4.6 コマンド・インタフェース

RMAN, 3.2

コマンド, Recovery Manager

ADVISE FAILURE, 15.1.2.4, 15.4

ALLOCATE CHANNEL, 5.1.4.1, 6.1.1, 6.2.2, 9.2.3.1

BACKUP, 2.4, 2.4, 2.4.1, 2.4.2, 2.4.3, 2.4.4, 2.4.4, 2.4.4.1, 2.4.5, 3.3.2, 3.7.2.3, 5.1.2, 5.1.4.3, 5.2.3, 5.2.5.1, 5.3.5, 5.3.5, 5.5.1, 5.5.1, 6.1.1, 6.2.1, 6.2.4, 6.2.6.1, 8.1, 8.3, 8.3.1, 8.3.9, 8.3.10, 8.3.10, 8.4.1, 8.4.1, 8.5, 8.5, 8.5.1, 8.5.1, 8.5.2.1, 8.5.2.2, 9.1.2, 9.2.1, 9.2.4.1, 9.2.5, 9.3.1, 9.3.2, 9.3.2, 9.3.3, 9.3.3.1, 9.3.4, 9.4.1, 9.4.1.2, 9.4.1.2, 9.4.3, 9.4.3, 9.4.4, 9.5, 9.5.3, 9.5.3.1, 9.5.4.1, 9.6.1, 9.6.3.1, 9.6.4, 9.7.1, 9.7.1, 9.7.1, 9.7.2, 9.7.3

PROXY ONLYオプション, 8.3.10

PROXYオプション, 8.3.10

BACKUP CURRENT CONTROLFILE, 9.3.3.1 取消し, 23.4 CATALOG, 12.4.3, 12.4.3, 12.4.3 CHANGE, 3.7.2.2, 12.4.1, 12.4.1 CHANGE FAILURE, 15.6 CONFIGURE, 3.7.1, 5.1.4.1, 5.4, 5.7, 6.1.1, 6.2.2, 6.2.6.2, 6.3 CREATE CATALOG, 13.2.3, 13.5.3 CREATE SCRIPT, 13.7.2 CROSSCHECK, 12.4.1, 12.4.1 DELETE, 12.4.1.1, 12.4.3.1, 12.4.3.1, 12.5 DROP CATALOG, 13.9 DROP DATABASE, 12.6 DUPLICATE, 24 EXECUTE SCRIPT, 13.7.1, 13.7.4 EXIT, 2.2 FLASHBACK DATABASE, 7.1.1, 13.8.5 GRANT, 13.5.2 RMANによる解析方法, 3.2 IMPORT CATALOG, 13.8.7 LIST, 2.5.1, 2.5.1, 11.1.2, 11.2, 11.2, 11.2.1, 13.8.5, 15.2

INCARNATIONオプション, 11.2.4, 13.8.5

MAXSETSIZE, 6.2.1 パイプ, 4.6 PRINT SCRIPT, 13.7.6 RECOVER, 14.3 REPAIR FAILURE, 15.5.1, 15.6 REPLACE SCRIPT, 13.7.3 REPORT, 2.5.2, 11.3.1, 11.3.2

NEED BACKUPオプション, 11.3.2

RESET DATABASE

INCARNATIONオプション, 13.8.5

RESTORE, 17.2.1.2, 17.2.1.2 RESYNC CATALOG, 13.6.2, 13.8.2, 13.8.2.3

FROM CONTROLFILECOPYオプション, 13.6.2

REVOKE, 13.5.4 SET, 6.2.6.1.2 SHOW, 2.3, 5.1.1 SPOOL, 15.5.1 SWITCH, 17.3.4 終了, 23.4, 23.4 UNREGISTER DATABASE, 13.8.4 UPGRADE CATALOG, 13.8.6.1 VALIDATE, 15.1.2.2, 15.3, 16.2 コマンド, SQL*Plus

RECOVER

UNTIL TIMEオプション, 29.4.2

SET, 29.2.2, 29.2.4.2, 29.3.1, 29.3.2 RMAN構文のコメント, 4.4.3 COMPATIBLE初期化パラメータ, 6.2.6.1 完全リカバリ

概要, 17.1

プロシージャ, 29.3

圧縮バックアップ, 5.1.3, 9.2.5

アルゴリズム, 6.2.5

CONFIGUREコマンド

AUXNAMEオプション, 6.3

BACKUP OPTIMIZATIONオプション, 5.5.3

CHANNELオプション, 5.1.4.1, 6.1.1

CONTROLFILE AUTOBACKUPオプション, 8.6.1, 9.6.2

DB_UNIQUE_NAMEオプション, 5.7

ENCRYPTIONオプション, 6.2.6.2

EXCLUDEオプション, 6.2.4

FOR DB_UNIQUE_NAMEオプション, 3.7.1

MAXPIECESIZEオプション, 6.2.2

MAXSETSIZEオプション, 6.2.1

RETENTION POLICY句, 8.8

RETENTION POLICYオプション, 5.4

メディア・マネージャの構成, 5.2.3

インストール, 5.2.1

前提条件, 5.2.1

Recovery Managerの構成

自動バックアップ, 5.1.5, 5.1.5.1, 8.6

バックアップの最適化, 5.5

バックアップ保存方針, 5.4

バックアップ・セットのサイズ, 6.2.1

デフォルトのバックアップ・タイプ, 5.1.3

デフォルト・デバイス, 5.1.2

概要, 5.1

共有サーバー, 6.5

スナップショット制御ファイルの場所, 6.4

特定のチャネル, 6.1.2

バックアップから除外する表領域, 6.2.4

一貫性バックアップ, 8.1.1

RMANの使用, 8.1.1

データベース全体, 28.2

制御ファイルの自動バックアップ, 12.2.3

データベースの構造変更後, 8.6

構成, 5.1.5, 5.1.5, 5.1.5, 5.1.5.1, 5.1.5.1, 8.6, 8.6

デフォルトの書式, 8.6.2

書式, 5.1.5.1

制御ファイル

バックアップ, 28.1.1, 28.4

バイナリ, 28.4.1

データベース・バックアップに含める, 9.3.3.1

リカバリ, 20.3.1

RMANの使用, 9.3.3

循環再利用レコード, 12.2.1 場所の構成, 5.3.4 すべてのコピーが消失した後の作成, 30.3 ファイル名の検索, 28.1.1 多重, 5.3.1, 5.3.4, 12.2.3, 17.2.1.1, 28.1.1, 29.2.1, 30.1.1

消失, 30.1

多重化, 12.2.3 再作成, 30.3 リストア, 20.3.1.1, 30.1.1, 30.1.2 スナップショット, 13.8.2.1

場所の指定, 6.4

すべてのコピーが消失した後のユーザー管理リストア, 30.3 CONTROL_FILE_RECORD_KEEP_TIME初期化パラメータ, 12.2.1, 12.2.2, 13.8.2.2.4 CONTROL_FILES初期化パラメータ, 5.3.4.2, 20.3.1.1, 21.6.1.2, 30.1.2 CONVERTコマンド

表領域およびデータファイル, 27

COPIESオプション

BACKUPコマンド, 10.4.2

破損ブロック, 14.1.1.2, 16.1.2.1, 29.6.1

リカバリ, 19.1.2.1, 19.1.2.1

RMAN, 10.7.1

CREATE CATALOGコマンド, 13.2.3, 13.5.3 CREATE DATAFILE句, ALTER DATABASE文, 30.4 CREATE SCRIPTコマンド, 13.7.2 CREATE TABLE文

AS SELECT句, 30.5

CREATE TABLESPACE文, 30.2.3 CROSSCHECKコマンド, 12.4.1, 12.4.1 クロスチェック, RMAN, 2.6, 12.1.2.2.1, 12.4.1, 12.4.1

定義, 12.4.1.1

リカバリ・カタログとメディア・マネージャ, 12.4.1.1

クロス・プラットフォーム・トランスポータブル表領域, 27 累積増分バックアップ, 2.4.4, 2.4.4.1, 8.7.1, 8.7.1.2

D

データ・ブロック, 破損, 1.1.1.3, 1.2, 2.7.1, 2.9.4, 14.1.1.2, 15.3, 15.6, 16.2, 19.1.1, 29.6.1, 29.6.1

データ・ディクショナリ・ビュー, 28.3.1, 28.3.2.1, 28.3.2.4

データファイル

バックアップ, 9.3.2, 9.7.2, 9.7.3, 28.3.1

ステータスの確認, 28.1.2

表示, 28.1

消失, 29.2.1

リカバリ

バックアップを利用しない, 30.4

再作成, 30.4 名前の変更

リカバリ後, 30.2.3

リストア, 14.2 Data Guard環境, 3.7.2.3

アーカイブ・ログの削除方針, 5.6.1.2

DB_UNIQUE_NAMEの変更, 13.8.3

RMANの構成, 5.7

レポート, 11.1.2.1

RMANバックアップ, 9.1.2

RMANバックアップ, アクセシビリティ, 3.7.2.3

RMANバックアップ, 関連付け, 3.7.2.2

RMANバックアップ, 互換性, 3.7.2.1, 9.3.3

RMANの使用方法, 3.7

データ整合性チェック, 1.4, 15.1.2.2, 15.3 データ保存, 定義, 1.1.2 データ保護

定義, 1.1.1

データ・リカバリ・アドバイザ, 2.7, 11.2.1, 14.1.2

自動修復, 1.4

データ整合性チェック, 15.1.2.2, 15.3

障害の統合, 15.1.2.3.3

障害優先順位, 15.1.2.3.2

障害, 15.1.2.1, 15.1.2.3

実行可能性チェック, 15.1.2.4

概要, 1.4

用途, 15.1.1

修復オプション, 15.4

障害の修復, 15.5.1

修復, 15.1.2.1, 15.1.2.4, 15.1.2.4.1

サポートされる構成, 15.1.2.5

ユーザー・インタフェース, 15.1.2.1

データ修復

概要, 14.1.1

方法, 14.1.2

データ送信, RMAN, 1.1.3 データベース接続

Recovery Manager

補助データベース, 4.5.4

パスワードの保護, 4.5.5

カタログの指定なし, 4.5

RMANに必要なSYSDBA, 4.5.1.1 RMANでのタイプ, 4.5.1 データベースのPoint-in-Timeリカバリ, 18.5

定義, 18.1.2.1

フラッシュバック・データベース, 7.1.1, 18.1

前提条件, 18.5.1

ユーザー管理, 29.4

データベース

バックアップ用の表示, 28.1

メディア・リカバリ手順, ユーザー管理, 29

メディア・リカバリの例, 30

リカバリ

制御ファイルの破損後, 30.1.1, 30.1.2

リカバリ・カタログへの登録, 13.3.2, 13.3.2 スキーマに関するレポート, 11.3.5 一時停止, 28.6.1 リカバリ・カタログからの登録解除, 13.8.4 DB_BLOCK_CHECKSUM初期化パラメータ, 16.1.2.1 DB_CREATE_FILE_DEST初期化パラメータ, 5.3.4.1, 9.5.5.2, 17.3.2 DB_FILE_NAME_CONVERT初期化パラメータ, 21.6.1.2 DB_FLASHBACK_RETENTION_TARGET初期化パラメータ, 5.3.2, 5.3.2.1, 5.3.2.3 DB_LOST_WRITE_PROTECT初期化パラメータ, 6.6 DB_NAME初期化パラメータ, 21.6.1.2 DB_RECOVERY_FILE_DEST初期化パラメータ, 2.1, 5.3.2, 5.3.4.1 DB_RECOVERY_FILE_DEST_SIZE初期化パラメータ, 2.1, 5.3.2 DB_UNIQUE_NAME初期化パラメータ, 3.7, 3.7.2.2, 5.7, 11.1.2.1 DBA_DATA_FILESビュー, 28.3.1, 28.3.2.1, 28.3.2.4 DBID

確認, 17.2.2

コピー・データベースの登録時の問題, 13.1.2.1

DBNEWIDを使用した設定, 13.3.1

DBMS_PIPEパッケージ, 4.6, 4.6 DBNEWIDユーティリティ, 13.3.1, 24.1.1 DBVERIFYユーティリティ, 28.9 DELETEコマンド, 12.4.3.1, 12.5, 12.5.3

EXPIREDオプション, 12.4.1.1, 12.5.4

OBSOLETEオプション, 8.8.3, 8.8.3, 12.5.5

バックアップの削除, 2.6.2, 12.5, 12.5, 12.5.1.1, 12.5.3 削除方針, アーカイブREDOログ, 5.6.1

有効化, 5.6.2

デバイス, デフォルトの構成, 5.1.2 差分増分バックアップ, 2.4.4, 8.7.1, 8.7.1.1 直系祖先パス, 14.3.2.2, 18.4.2, 18.6.2 障害リカバリ, 1.1.2

定義, 1.1.1.1

切断

Recovery Manager, 2.2

ディスクAPI, 5.2.4 ディスク障害, 1.1.1.1 ディスク使用量

監視, 12.3.2

DROP DATABASEコマンド, 12.6 削除された表, 取得, 18.3.1 データベースの削除, 12.6 リカバリ・カタログの削除, 13.9 デュアル・モードのバックアップ暗号化, 6.2.6.1.3, 6.2.6.1.3 デュアル・モードのバックアップ暗号化, 10.6.4 仮のAPI, 5.2.4 多重バックアップ・セット, 6.2.3, 6.2.3, 8.5.1, 10.4 DUPLICATEコマンド, 24

失敗後の再実行, 24.7

複製データベース, 3.1

アクティブなデータベースの複製, 4.5.4, 24.1.2.1.1

バックアップベースの複製, 24.1.2.1.2

ターゲット接続を行わない, 24.1.2.1.2

ターゲット/リカバリ接続を行わない, 24.1.2.1.2

ターゲット接続を行う, 24.1.2.1.2

ファイル名の生成, 24.2.2 RMANによる作成方法, 24.1.2.3 失敗後のDUPLICATEの再実行, 24.7 OFFLINE NORMALオプションによる表領域のスキップ, 25.5.2 読取り専用表領域のスキップ, 25.5 複製

失敗後の再実行, 24.7

DURATIONパラメータ, BACKUPコマンド, 10.8.2

E

暗号化バックアップ, 10.6, 14.2.1

復号化, 17.3.1.2

環境変数

NLS_DATE_FORMAT, 4.3

NLS_LANG, 4.3

エラー・コード

メディア・マネージャ, 23.1.3.2

RMAN, 23.1, 23.1.3, 23.1.3.1

エラー・メッセージ, RMAN

解釈, 23.1.4

エラー・スタック, RMAN

解釈, 23.1.4

EXECUTE SCRIPTコマンド, 13.7.4 EXITコマンド, 2.2 RMANの終了, 2.2 期限切れのバックアップ, 8.8, 12.4.1.1

削除, 12.5.4

EXPIREDオプション

DELETEコマンド, 12.5.4

F

フェイルオーバー, ファイルのリストア時, 14.2.2

障害

定義, 1.1.1

メディア, 1.1.1.1

「リカバリ」も参照

障害, データ・リカバリ・アドバイザ, 15.1.2.1, 15.1.2.3

統合, 15.1.2.3.3

優先順位, 15.1.2.3.2

高速リカバリ領域, 3.1, 3.6, 18.1.2.2.1

自動バックアップ, 5.1.5.1

場所の変更, 12.3.5

構成, 5.3

定義, 2.1

無効化, 12.3.6

保存方針の影響, 8.8.4

有効化, 5.3.2

フラッシュバック・データベース・ウィンドウ, 7.1.2

メンテナンス, 12.3

ディスク使用量の監視, 12.3.2

使用状況の監視, 12.3.2

Oracle Managed Files, 5.3.1.1

永続的なファイルおよび一時的なファイル, 5.3.1

RMANファイル, 5.3.5

場所の設定, 5.3.2.2

サイズの設定, 5.3.2.1

スナップショット制御ファイル, 6.4

領域管理, 5.3.1.2

実行可能性チェック, データ・リカバリ・アドバイザ, 15.1.2.4 ファイル名, バックアップ用の表示, 28.1 ファイル・セクション, 8.3.7, 8.3.9, 10.1.3, 16.2 フラッシュバック・データ・アーカイブ

定義, 1.3.1

FLASHBACK DATABASEコマンド, 7.1.1, 18.4.2 フラッシュバック・データベース・ウィンドウ, 7.1.2 フラッシュバック・ドロップ, 18.1.2.2.2, 18.3.1 フラッシュバック・ログ, 1.3.2, 2.8, 7.1.1, 12.3.3, 18.1.2.2.1

保証付きリストア・ポイント, 7.1.5

フラッシュバック保存目標, 7.1.1 フラッシュバック表, 18.1.2.2.2

使用, 18.2.1, 18.2.2

FLASHBACK TABLE文, 18.2.1, 18.2.1, 18.2.2 フラッシュバック技術, 18.1.2

論理機能, 18.1.2.2.2

概要, 1.3

フラッシュバック・アンドロップ

オブジェクトのリストア, 18.3.3

形式, RMANバックアップ用, 9.2.3 分裂ブロック, 8.2

検出, 8.2

全体バックアップ, 8.7

増分バックアップ, 2.4.4

G

汎用チャネル

定義, 5.1.4.1

GRANTコマンド, 13.5.2 グループ, REDOログ, 30.7.1, 30.7.1, 30.7.2, 30.7.2 保証付きリストア・ポイント, 1.3.2, 5.3.2.1

ストレージ・スナップショットにかわる機能, 7.1.5.1

ストレージ・スナップショットとの比較, 7.1.5.1

作成, 7.4.1

フラッシュバック・ログ, 7.1.5

要件, 7.3

高速リカバリ領域の領域使用状況, 7.4.2

H

状態モニター, 15.1.2.2

ホット・バックアップ・モード

失敗したバックアップ, 28.3.2.3, 28.3.2.3.1

オンラインのユーザー管理バックアップ, 28.3.2.1

I

イメージ・コピー, 2.4, 8.1, 8.4

定義, 8.4

リストアのテスト, 17.2.4

IMPORT CATALOGコマンド, 13.8.7 INCARNATIONオプション

LISTコマンド, 11.2.4, 13.8.5

RESET DATABASEコマンド, 13.8.5, 13.8.5

インカネーション, データベース, 11.2.4, 14.3.2, 18.4.2, 18.6.2 INCLUDE CURRENT CONTROLFILEオプション

BACKUPコマンド, 9.3.3.1

不完全メディア・リカバリ, 29.4 不完全リカバリ

定義, 18.5

Oracle Real Application Clusters構成, 29.2.2.2

概要, 14.3

時間ベース, 29.4.2

バックアップ制御ファイルを使用, 29.2.2.2

非一貫性バックアップ, 8.1.2

RMANの使用, 2.4.1, 8.1.1

増分バックアップ, 2.4.4, 9.5

ブロック・チェンジ・トラッキング, 9.5.5

差分, 8.7.1.1

RMANでの適用方法, 14.3.1

作成, 9.5

RMANの使用, 10.4.1, 10.4.2

初期化パラメータ・ファイル, 14.3 初期化パラメータ

CONTROL_FILES, 20.3.1.1, 30.1.2

DB_FILE_NAME_CONVERT, 21.6.1.2

DB_NAME, 21.6.1.2

LARGE_POOL_SIZE, 22.4.3

LOCK_NAME_SPACE, 21.6.1.2

LOG_ARCHIVE_DEST_n, 29.2.3

LOG_ARCHIVE_FORMAT, 29.2.3

LOG_FILE_NAME_CONVERT, 21.6.1.2

インスタンス障害

バックアップ・モード, 28.3.2.3

整合性チェック, 16.1.2 RMANエラー・スタックの解釈, 23.1.4 メディア・リカバリの中断, 29.2.5 I/Oエラー

バックアップへの影響, 10.7.1

J

ジョブ, RMAN

進捗状況の監視, 22.3.1

詳細の問合せ, 11.4.1

K

KEEPオプション

BACKUPコマンド, 12.4.2.2

L

レベル0の増分バックアップ, 2.4.4, 8.7.1, 8.7.1, 8.7.2

レベル1の増分バックアップ, 8.7.1.1, 8.7.1.2

LISTコマンド, 2.5.1, 11.1.2, 11.2, 11.2.1

FAILUREオプション, 15.2

INCARNATIONオプション, 13.8.5

LOCK_NAME_SPACE初期化パラメータ, 21.6.1.2 ログ順序番号, 29.2.1 LOG_ARCHIVE_DEST_n初期化パラメータ, 5.3.4.3, 17.2.5, 29.2.2, 29.2.3, 29.2.3, 29.3.1, 29.4.1, 29.4.2 LOG_ARCHIVE_FORMAT初期化パラメータ, 29.2.3 LOG_FILE_NAME_CONVERT初期化パラメータ, 21.6.1.2 論理バックアップ, 1.1.1 論理的なブロック破損, 16.1.2.2 LOGSOURCE変数

SET文, 29.2.4.2, 29.3.1, 29.3.2

ロング・ウェイト, 22.3.2.2 消失

非アクティブのログ・グループ, 30.7.2.1

消失書込み, 検出, 6.6

M

メンテナンス・コマンド, RMAN, 2.6, 3.3.2, 12.1.2

Data Guard環境, 12.1.2.2

RMANメタデータの管理, 11, 12, 12 MAXPIECESIZEパラメータ

SETコマンド, 5.2.5.1

MAXSETSIZEパラメータ

BACKUPコマンド, 6.2.1, 10.1

CONFIGUREコマンド, 6.2.1

メディア障害, 1.1.1

アーカイブREDOログ・ファイルの消失, 29.4

完全リカバリ, 29.3

完全リカバリ, ユーザー管理, 29.3

制御ファイルの消失, 30.3

データファイルの消失, 29.2.1

定義, 1.1.1.1

NOARCHIVELOGモード, 29.5

オンラインREDOログ・グループの消失, 30.7.2

リカバリ, 29.3

リカバリ手順

例, 29.2.1

メディア管理レイヤー(MML)API, 3.5, 6.2.2 メディア・マネージャ, 3.1, 3.3.1, 3.5, 3.5.2

ファイルのバックアップ, 3.5.1

バックアップ・ピース名, 5.2.5.1

Backup Solutions Program, 3.5.3

カタログ, 3.1

RMANとともに使用するための構成, 5.2.3

クロスチェック, 12.4.1.1

定義, 2.1

エラー・コード, 23.1.3.2

ファイル制限, 5.2.5.1

インストール, 5.2.1

ライブラリの場所, 5.2.2

リンク

テスト, 5.2.4

ソフトウェアへのリンク, 3.5.2, 5.2.2 バックアップの多重化, 8.3.9 構成の前提条件, 5.2.1 sbttestプログラム, 23.3.1 テスト, 5.2.4 バックアップのテスト, 5.2.4.2 APIのテスト, 23.3 サード・パーティ, 5.2 トラブルシューティング, 5.2.4.2 メディア・リカバリ, 8.7.4

ADD DATAFILE操作, 30.2.3

制御ファイルの破損後, 30.1.1, 30.1.2

アーカイブREDOログの適用, 29.2.1

取消しベース, 29.4, 29.4.2

完全, 29.3

クローズ状態のデータベース, 29.3.1

完全, ユーザー管理, 29.3 破損

許可, 29.6.4

データファイル

バックアップを利用しない, 30.4

エラー, 29.6.1 不完全, 29.4 中断, 29.2.5 消失したファイル

消失したアーカイブREDOログ・ファイル, 29.4

消失したデータファイル, 29.2.1

消失したミラー化制御ファイル, 30.1

NOARCHIVELOGモード, 29.5, 29.5 オープン状態のデータベースのオフライン表領域, 29.3.2 オンラインREDOログ・ファイル, 30.7 パラレル, 29.2.6 問題, 29.6.1, 29.6.1, 29.6.2, 29.6.3 再開, 29.2.5 リストア

データベース全体のバックアップ, 29.5

中断後の再開, 29.2.5 ロールフォワード・フェーズ, 29.2.1 例, 30 時間ベース, 29.4 トランスポータブル表領域, 30.6 試行, 29.6.6, 29.6.6, 29.6.6.1 トラブルシューティング, 29.6.1, 29.6.1 オンラインの破損していない表領域, 29.3.2 ユーザー管理, 29 Recovery Managerを使用, 14.3 メタデータ, RMAN, 3.4, 11, 12, 13 ミラー化ファイル

バックアップ, 10.5

分割, 28.6.1

一時停止/再開モード, 28.6.1

RMANの使用, 10.5

高速リカバリ領域の使用状況の監視, 12.3.2 RMANの監視, 23.2 MTTR, 15.1.1 多重バックアップ・セット, 6.2.1, 8.3.9, 9.2.4.2, 22.2.1.1 多重制御ファイル, 5.3.1, 5.3.4, 12.2.3, 12.2.3, 17.2.1.1, 28.1.1, 29.2.1, 30.1.1 マルチセクション・バックアップ, 3.3.2, 8.3.1, 8.3.7, 8.3.9, 10.1.3, 16.2

N

バックアップ・セット名の指定, 8.3.6

NLS_DATE_FORMAT環境変数, 4.3

NLS_LANG環境変数, 4.3

NOARCHIVELOGモード

バックアップ, 9.3.5

デメリット, 29.5

リカバリ, 29.5

O

不要なバックアップ, 8.8

定義, 8.8

削除, 2.6.2, 8.8.3, 12.5.5

オフサイト・バックアップ, 17.2.3.1 オンラインREDOログ, 30.7.2.1

アクティブ・グループ, 30.7.1, 30.7.2

メディア・リカバリ時の適用, 29.2.1

アーカイブ・グループ, 30.7.1, 30.7.2

消去

障害, 30.7.2.1.3

非アクティブのログの消去

アーカイブ, 30.7.2.1.1

アーカイブされていない, 30.7.2.1.2

場所の構成, 5.3.4 現行グループ, 30.7.1, 30.7.2 非アクティブのグループ, 30.7.1, 30.7.2 消失, 30.7.2.1

アクティブ・グループ, 30.7.2.2.1, 30.7.2.2.1

すべてのメンバー, 30.7.2

グループ, 30.7.2

リカバリ, 30.7

グループの消失, 30.7.2.2.1, 30.7.2.2.1 複数のグループの消失, 30.7.2.3 破損したメンバーの置換, 30.7.1 メンバーのステータス, 30.7.1, 30.7.2 OPEN RESETLOGS句

ALTER DATABASE文, 13.8.5, 14.3.2.1, 18.4.2, 18.6.1

ORA-01578エラー・メッセージ, 30.5 Oracle Backup Solutions Program(BSP), 3.5.3 Oracle Data Pump, 1.1.1, 18.4.2 Oracle Encryption Wallet

バックアップ, 6.2.6.1.1

Oracle Flashback Database。「フラッシュバック・データベース」を参照, 2.8, 14.1.2

フラッシュバック・データベース・ウィンドウの確認, 18.4.2

フラッシュバック・ログ, 1.3.2, 7.2.1

制限事項, 7.1.3

監視, 7.5.4

概要, 1.3.2

前提条件, 18.4.1

用途, 18.1.1

要件, 7.3

領域管理, 12.3.3

ディスク領域要件の見積り, 5.3.2.3

パフォーマンスのチューニング, 7.5.3 Oracle Flashback Drop, 1.3.1 Oracle Flashback Query, 1.3.1 Oracle Flashback Table, 1.3.1 Oracle Flashback Transaction, 1.3.1 Oracle Flashback Transaction Query, 1.3.1 Oracle Flashback Version Query, 1.3.1 Oracle Managed Files

高速リカバリ, 5.3.1.1

Oracle Real Application Clusters(Oracle RAC)

RMANチャネル, 6.1.2

Oracle Secure Backup, 3.5.2, 5.2 Oracle VSSライター, 5.3.1 Oracleウォレット, 6.2.6.1.1 孤立したバックアップ, 14.3.2.3 OSB Cloud Module

Oracle Databaseバックアップおよびリストア・リファレンスの「はじめに」も参照

P

パッケージ

DBMS_PIPE, 4.6, 4.6

バックアップのパスワード暗号化, 6.2.6.1.2, 6.2.6.1.2 パスワード・モードの暗号化, 10.6.3 パスワード

RMANへの接続, 4.5.5

パフォーマンス・チューニング

ショート・ウェイト

定義, 22.3.2.2

パフォーマンス・チューニング, RMAN

バックアップのパフォーマンス, 22.4

LARGE_POOL_SIZE初期化パラメータ, 22.4.3

ロング・ウェイト, 22.3.2.2

物理バックアップ, 1.1.1 物理的なブロック破損, 16.1.2.2 パイプ・インタフェース, RMAN, 4.6 リカバリ可能ポイント

リカバリ期間, 8.8.1

Point-in-Timeリカバリ, 29.4

実行

現行の制御ファイルの使用, 18.5.2

表領域, 18.1.2 PREVIEWオプション, RESTOREコマンド, 11.1.2 バックアップのプレビュー, 17.2.3 PRINT SCRIPTコマンド, 13.7.6 プロキシ・コピー, 3.5.1, 8.3.10 PROXYオプション

BACKUPコマンド, 8.3.10, 8.3.10

Q

QUITコマンド, 2.2

RMANの終了, 2.2

R

RAWデバイス

バックアップ先, 28.7

UNIXでのバックアップ, 28.7.1

Windowsでのバックアップ, 28.7.2

RC_ARCHIVED_LOGビュー, 11.5.1.1 RC_BACKUP_FILESビュー, 11.5.3 RC_BACKUP_PIECEビュー, 11.5.1 RC_BACKUP_SETビュー, 12.5.1 読取り専用表領域

バックアップ, 28.3.2.4

RECOVER句

ALTER DATABASE文, 29.2.4.2, 29.3.1, 29.3.2

RECOVERコマンド, 14.3

COPYオプション, 9.5.4

PARALLELおよびNOPARALLELオプション, 29.2.6

TESTオプション, 16.4

リカバリ不能なオブジェクトおよびスタンバイ・データベース, 30.5

UNTIL TIMEオプション, 29.4.2

USING BACKUP CONTROLFILE句, 30.2.4

リカバリ

ADD DATAFILE操作, 30.2.3

アーカイブ・ログの自動適用, 29.2.2

取消しベース, 29.4.2

完全, 17.1, 29.3

クローズ状態のデータベース, 29.3.1

オフライン表領域, 29.3.2

破損

意図的な許可, 29.6.4

データファイル, 29.2.1 データベース

NOARCHIVELOGモード, 20.1

データベース・ファイル

RMANでの適用方法, 14.3.1

概要, 14.3

データベースのPoint-in-Time, 18.5 RMANを使用した障害リカバリ, 20.4 削除された表, 30.8 エラー, 29.6.1 必要な障害, 1.1.1 中断, 29.2.5 メディア, 29, 29.6, 30 複数のREDOスレッド, 29.2.2.2 消失または破損したリカバリ・カタログ, 13.6.2 オンラインREDOログ, 30.7

グループの消失, 30.7.2

パラレル, 29.2.6 準備, 17.2.1.2 問題, 29.6.1

解決, 29.6.3

調査, 29.6.2

スタック, 29.6.1 時間ベース, 29.4.2 トランスポータブル表領域, 30.6 試行, 29.6.6

説明, 29.6.6.1

概要, 29.6.6

トラブルシューティング, 29.6.1 ユーザー・エラー, 30.8 ユーザー管理, 29, 29.6, 30 バックアップ制御ファイルの使用, 20.3.1

リカバリ・カタログを使用しない, 20.3.2

デフォルト以外の場所のログの使用, 29.2.4.1 デフォルトの場所のログの使用, 29.2.3 デフォルト以外の場所のログの使用, 29.2.4.2 リカバリ・カタログを使用しない, 12.2.3 リカバリ・カタログ, 3.4, 13.1

バックアップ, 13.6.1, 13.6.1

カタログへのバックアップの追加, 12.4.3, 13.4

メタデータの集中化, 13.1.2.2

作成, 13.2

クロスチェック, 12.4.1.1

DBIDの問題, 13.1.2.1

定義, 2.1, 3.1

バックアップの削除, 12.5

レコードの削除, 12.5.3

削除, 13.9

ログ・スイッチ・レコード, 12.4.3

サイズの管理, 13.8.2.2.4

使用する操作, 3.4

目的, 13.1.1

リカバリ, 13.6.2

リフレッシュ, 13.8.2

データベースの登録, 13.1.2.1, 13.3.1, 13.3.2, 13.3.2

再同期化, 13.8.2, 13.8.2.1

領域要件, 13.2.1.2

ストアド・スクリプト, 13.7.1

作成, 13.7.2

同期化, 13.8.2.1 データベースの登録解除, 13.8.4 更新

オペレーティング・システムの削除後, 12.4.4.2

アップグレード, 13.8.6, 13.8.6.1 ビュー, 問合せ, 11.5 仮想プライベート・カタログ, 3.4 リカバリ・カタログ

バックアップ, 13.6.1

削除, 13.9

インポート, 13.8.7

移動, 13.8.7.4

Recovery Manager

テープ・バッファの割当て, 22.2.3.1.1

アーカイブREDOログ

バックアップ, 9.4

認証, 2.2 バックアップ, 9.1.2

アーカイブREDOログ, 9.4

バックアップ, 8.5.2.1, 9.7.1

不要のバッチ削除, 8.8.3

制御ファイル, 9.3.3

データファイル, 9.3.2, 9.7.2, 9.7.3

多重化, 8.5.1

イメージ・コピー, 8.4

増分, 9.5, 10.4.1, 10.4.2

最適化, 5.5.1, 9.4.3

表領域, 9.7.2, 9.7.3

テスト, 16.1.2.4, 16.2, 16.2, 16.3, 16.3

検証, 16.2, 16.2, 16.3, 16.3

データベース全体, 9.3.1, 9.3.1

チャネル, 3.3, 3.3

ネーミング規則, 3.3.2

クライアント, 2.1 データベースに接続, 2.2 データファイル・ブロックの破損

I/Oエラーの処理, 10.7.1

リカバリ・カタログのクロスチェック, 12.4.1.1 データベース・キャラクタ・セット, 4.3 データベース接続, 4.5.1

補助データベース, 4.5.4

複製データベース, 4.5.4

パスワードの保護, 4.5.5

ターゲットに必要なSYSDBA, 4.5.1.1

カタログの指定なし, 4.5

DBMS_PIPEパッケージ, 4.6 定義, 2.1 切断, 2.2 複製データベース, 概要, 24.1.2.3 エラー・コード

メッセージ番号, 23.1.3.1

エラー, 23.1, 23.1.3

解釈, 23.1.4

ファイルの削除, 12.5.1.1 分裂ブロックの検出, 8.2 イメージ・コピー・バックアップ, 8.4 増分バックアップ

累積, 8.7.1.2

差分, 8.7.1.1

レベル0, 8.7.1

整合性チェック, 16.1.2 ジョブ, 進捗状況の監視, 22.3.1 ジョブ, 詳細の問合せ, 11.4.1 リスト, 11.2 メンテナンス・コマンド, 2.6 メディア管理

ファイルのバックアップ, 3.5.1

Backup Solutions Program(BSP), 3.5.3

クロスチェック, 12.4.1.1

メディア・マネージャ, リンク, 5.2.2

メタデータ, 3.4, 11, 12, 13 監視, 23.2 概要, 2.1, 3.2 パフォーマンス

監視, 23.2

パイプ・インタフェース, 4.6 プロキシ・コピー, 3.5.1 リカバリ

メディア全体の障害後, 20.4

リカバリ・カタログ, 13.1

バックアップ, 13.6.1

クロスチェック, 12.4.1.1

サイズの管理, 13.8.2.2.4

使用する操作, 3.4

リカバリ, 13.6.2

ターゲット・データベースの登録, 13.1.2.1, 13.3.1, 13.3.2

再同期化, 13.8.2

同期化, 13.8.2.1

アップグレード, 13.8.6.1

レポート, 11.3.1

データベース・スキーマ, 11.3.5

バックアップが必要なオブジェクト, 11.3.2

不要なバックアップ, 11.3.4

リポジトリ, 3.4 リストア

アーカイブREDOログ, 17.2.5

データファイル, 14.2

保存方針

構成, 5.4

リターン・コード, 23.1.5 時間パラメータの設定, 4.3 スナップショット制御ファイルの場所, 6.4 起動, 2.2 同期I/Oと非同期I/O, 22.2.1.2, 22.2.1.3, 22.2.3.1.3 コマンドの終了, 23.4 テスト・ディスクAPI, 5.2.4 バックアップのタイプ, 8.4 RMANコマンドの使用, 3.2 リカバリ期間, 5.4

リカバリ可能ポイント, 8.8.1

RECOVERY WINDOWパラメータ

CONFIGUREコマンド, 5.4.2

リカバリ期間

保存方針の構成, 5.4.2

定義, 8.8.1

RECOVERY_CATALOG_OWNERロール, 13.5.2 ごみ箱, 18.1.2.2.2, 18.3.2

オブジェクトのリストア, 18.3.3

REDOログ

互換性のないフォーマット, 29.6.1

ネーミング, 29.2.3

パラレルREDO, 29.6.1

REDOレコード

適用時の問題, 29.6.1

REGISTERコマンド, 13.3.2 REPAIR FAILUREコマンド, 15.5.1, 15.6 修復オプション, データ・リカバリ・アドバイザ, 15.4 修復, データ・リカバリ・アドバイザ, 15.1.2.1

統合, 15.1.2.4.1

手動および自動, 15.1.2.4

REPLACE SCRIPTコマンド, 13.7.3 REPORTコマンド, 2.5.2, 11.1.2, 11.3.1

NEED BACKUPオプション, 11.3.2, 11.3.2

OBSOLETEオプション, 8.8.3, 8.8.3

レポート, RMAN, 2.5, 11.1.2, 11.3.1, 11.3.1

バックアップ・ジョブ, 11.4.1

データベース・スキーマ, 11.3.5

バックアップが必要なファイル, 11.3.2

不要なバックアップ, 11.3.4

リカバリ不能なバックアップ, 11.3.4

リポジトリ, RMAN, 3.4, 3.4 RESET DATABASEコマンド

INCARNATIONオプション, 13.8.5

RESETLOGS操作

必要な場合, 14.3.2.1

RESETLOGSオプション

ALTER DATABASE, 29.5

再開可能バックアップ, 10.7.1 再開

失敗後の複製, 24.7

RESTOREコマンド, 14.2, 17.2.1.2

FORCEオプション, 14.2.4

PREVIEWオプション, 11.1.2, 17.2.3

VALIDATE HEADERオプション, 11.1.2, 17.2.3

リストアの最適化, 14.2.4 リストア・ポイント, 1.3.2, 2.8

作成, 7.4.1

フラッシュバック先, 18.6.2

保証付き, 1.3.2, 7.1.5

ストレージ・スナップショットとの比較, 7.1.5.1

表示, 7.4.2 要件, 7.3 リストアの検証, 17.2.4 リストア

制御ファイル, 20.3.1.1

デフォルトの場所へ, 30.1.1

デフォルト以外の場所へ, 30.1.2

データベース

デフォルトの場所へ, 29.5

データベース・ファイル, 14.2, 14.2.1, 14.2.4 サーバー・パラメータ・ファイル, 20.2, 20.2 テスト, 16.4, 17.2.4 ユーザー管理バックアップ, 29.2.1 RESUME句

ALTER SYSTEM文, 28.6.2

中断後のリカバリの再開, 29.2.5 RESYNC CATALOGコマンド, 13.8.2, 13.8.2.3

FROM CONTROLFILECOPYオプション, 13.6.2

リカバリ・カタログの再同期化, 3.7.1, 13.8.2, 13.8.2.3 リターン・コード

RMAN, 23.1.5

REVOKEコマンド, 13.5.4 RMANリポジトリ, 1.2, 2.1 RMANセッション, 2.7.2, 3.3

S

SBT, 3.3.1, 5.2.5.2

sbtio.log

RMAN, 23.1.1

sbttestプログラム, 23.3.1 例, Recovery Manager

NOARCHIVELOGバックアップ, 9.3.5

RESETLOGの実行前のバックアップのリカバリ, 18.6.3, 20.1

メディア全体の障害後のリカバリ, 20.4

スクリプト, RMAN, 2.4.6

置換変数, 9.6.3

サーバー・パラメータ・ファイル

自動バックアップ, 8.6

バックアップ, 9.3.4

自動バックアップの構成, 5.1.5, 5.1.5.1, 8.6

リストア, 20.2, 20.2

サーバー・セッション, Recovery Manager, 3.3 セッション・アーキテクチャ, Recovery Manager, 3.3 SETコマンド

DBIDオプション, 3.7.1

ENCRYPTIONオプション, 6.2.6.1.2

MAXCORRUPTオプション, 16.1.2.3

NEWNAMEオプション, 25.1.1.1

SET文

AUTORECOVERYオプション, 29.2.2

LOGSOURCE変数, 29.2.4.2, 29.3.1, 29.3.2

シャドウ・コピー, 9.5.3.1 共有サーバー

RMANとともに使用するための構成, 6.5

RMANの構成, 6.5

ショート・ウェイト

定義, 22.3.2.2

SHOWコマンド, 2.3, 2.3, 5.1.1 SHUTDOWN文

ABORTオプション, 29.5, 30.1.1, 30.1.2

バックアップ・セットのサイズ, 設定, 8.3.7 RMANバックアップ時のファイルのスキップ, 10.3 スナップショット制御ファイル, 6.4, 13.8.2.1

場所の指定, 6.4

分割されたミラー

一時停止/再開モード, 28.6.1

バックアップとして使用, 10.5

SPOOLコマンド, 15.5.1 スタンバイ・データベース, 3.1

DUPLICATEでの作成, 24.1.1

文, SQL

ALTER DATABASE, 29.2.4.2, 29.3.1, 29.3.2

ストレージ・スナップショット, 7.1.5.1 ストアド・スクリプト, 3.4, 9.6.3, 13.1.2.4, 13.7.1, 13.7.1, 13.8.7.1

RMANでの作成, 13.7.2

削除, 13.7.8, 13.7.8

動的, 13.7.5

実行, 13.7.9

名前の表示, 13.7.7

管理, 13.7.1

出力, 13.7.6

置換変数, 13.7.5

スタック・リカバリ, 29.6.1 置換変数, FORMATパラメータ, 5.2.5.1, 8.3.6, 8.4.1 置換変数, ストアド・スクリプト, 13.7.5 SUSPEND句

ALTER SYSTEM文, 28.6.2, 28.6.2

データベースの一時停止, 28.6.1 一時停止/再開モード, 28.6.1 SWITCHコマンド, 17.3.4 SYSDBA権限, 2.2 システム時刻

変更

リカバリへの影響, 29.4.2

T

表, 削除のリカバリ, 30.8

表領域のPoint-in-Timeリカバリ, 18.1.2

データファイル名の構成, 6.3

削除された表領域に対する実行, 21.1.1

計画, 21.3

補助インスタンスの準備, 21.6.1

制限事項, 21.2.2

実行理由, 21.1.1

表領域

バックアップ, 9.7.2, 9.7.3, 28.3.2.2

オフライン, 28.3.1

オンライン, 28.3.2.2

RMANを使用したバックアップ, 9.3.2 バックアップからの除外, 6.2.4 RMANバックアップからの除外, 6.2.4 読取り専用

バックアップ, 28.3.2.4

読取り/書込み

バックアップ, 28.3.2.1

リカバリのアクセス性

データベースがオープン状態の場合, 17.3.3

オープン状態のデータベースでのオフラインのリカバリ, 29.3.2 RMANを使用した転送, 26 テープ・デバイス, 3.5.2 ターゲット・データベース

接続, 2.2

定義, 2.1, 3.1

RMANコマンドの終了, 23.4 テスト・ディスクAPI, 5.2.4 RMANのテスト

バックアップ, 16.1.2.4, 16.2, 16.2, 16.3, 16.3

Media Management API, 23.3

時刻書式

RECOVER DATABASE UNTIL TIME文, 29.4.2

時間パラメータ

Recovery Managerで使用される設定, 4.3

時間ベースのリカバリ, 29.4.2 トレース・ファイル, RMAN, 23.1.1 バックアップの透過的暗号化, 6.2.6.1.1, 6.2.6.1.1 透過モードのバックアップ暗号化, 10.6.2 トランスポータブル表領域

RMANでの作成, 26.1.1

データ・ポンプ・エクスポート, 26.5.2

過去の時点, 26.5.1

補助の宛先, 26.1.2

補助インスタンスのパラメータ・ファイル, 26.2, 26.2.2

ファイルの場所, 26.5.3

初期化パラメータ, 26.2.1

クロス・プラットフォーム, 27 リカバリ, 30.6 表領域の転送, 26 試行リカバリ, 16.4, 29.6.6, 29.6.6.1 Recovery Managerのチューニング

V$ビュー, 23.2

U

UNAVAILABLEオプション

CHANGE, 12.4.2.1

UNCATALOGオプション

CHANGEコマンド, 12.4.4.1

リポジトリ・レコードの削除, 12.4.4.1

UNDOの最適化, バックアップ, 5.5.1, 8.3.4 リカバリ不能オブジェクト

リカバリ, 30.5, 30.5

UNREGISTER DATABASEコマンド, 13.8.4 データベースの登録解除, 13.8.4 UNTIL TIMEオプション

RECOVERコマンド, 29.4.2

リカバリ・カタログのアップグレード, 13.8.6.1 ユーザー・エラー

定義, 1.1.1.2

リカバリ, 30.8

ユーザー管理バックアップ, 28, 28.2

バックアップ・モード, 28.3.2.1, 28.3.2.3

制御ファイル, 28.4, 28.4

定義, 8.4.2

データファイルのステータスの確認, 28.1.2

ホット・バックアップ, 8.2, 28.3.2.3.1

ファイルの事前の表示, 28.1

オフライン表領域, 28.3.1, 28.3.1

読取り専用表領域, 28.3.2.4

表領域, 28.3.2.2

検証, 28.9

データベース全体, 28.2

ユーザー管理リカバリ, 29.4

ADD DATAFILE操作, 30.2.3

完全, 29.3

不完全, 29.4

中断, 29.2.5

例, 30

ユーザー管理のリストア操作, 29.2.1

V

V$ARCHIVED_LOGビュー, 5.3.2.3, 11.5.1.1, 18.5.2

すべてのアーカイブ・ログの表示, 28.5

V$BACKUPビュー, 28.1.2 V$BACKUP_ASYNC_IOビュー, 22.3.2 V$BACKUP_DATAFILEビュー, 9.5.2, 12.4.3.3 V$BACKUP_FILESビュー, 5.4.2, 12.4.1.1, 12.4.3.2 V$BACKUP_PIECEビュー, 11.5.1, 12.4.3.3 V$BACKUP_REDOLOGビュー, 12.4.3.3 V$BACKUP_SETビュー, 12.4.3.3, 12.5.1 V$BACKUP_SPFILEビュー, 12.4.3.3 V$BACKUP_SYNC_IOビュー, 22.3.2 V$BLOCK_CHANGE_TRACKINGビュー, 9.5.5.4 V$CONTROLFILEビュー, 9.3.3 V$DATABASEビュー, 11.5.2, 18.2.2, 18.6.1 V$DATABASE_BLOCK_CORRUPTIONビュー, 1.2, 2.9.4, 16.1.2.4, 16.2, 16.2, 19, 19.1.2.1, 19.1.2.1, 19.3, 19.4 V$DATABASE_INCARNATIONビュー, 13.8.5 V$DATAFILEビュー, 17.2.1.2.2, 21.6.1.2, 28.1.1

バックアップ用のファイルの表示, 28.1

V$DATAFILE_HEADERビュー, 11.1.2, 17.2.1.2.2, 17.2.1.2.2 V$DIAG_INFOビュー, 2.9.4, 19.3 V$EVENT_NAMEビュー, 23.2.1 V$FLASHBACK_DATABASE_LOGビュー, 5.3.2.3, 18.4.2, 18.6.1 V$FLASHBACK_DATABASE_STATビュー, 7.5.4 V$INSTANCEビュー, 17.2.1.2.2 V$LOG_HISTORYビュー

すべてのアーカイブ・ログの表示, 29.3.1

V$LOGFILEビュー, 21.6.1.2, 30.7.1, 30.7.2 V$PARAMETERビュー, 18.2.2 V$PROCESSビュー, 11.1.2, 23.2, 23.2.2 V$PROXY_ARCHIVEDLOGビュー, 8.3.10 V$PROXY_DATAFILEビュー, 8.3.10 V$RECOVER_FILEビュー, 17.2.1.2.2, 29.3.1 V$RECOVERY_AREA_USAGEビュー, 12.3.2, 12.3.2 V$RECOVERY_FILE_DEST, 12.3.2 V$RECOVERY_FILE_DESTビュー, 12.3.2, 12.3.2 V$RECOVERY_LOGビュー

リカバリに必要なログの表示, 29.3.1

V$RESTORE_POINTビュー, 18.2.2 V$RMAN_BACKUP_JOB_DETAILSビュー, 11.4.1 V$RMAN_BACKUP_SUBJOB_DETAILSビュー, 11.4.1 V$RMAN_ENCRYPTION_ALGORITHMSビュー, 6.2.6.1, 6.2.6.1, 6.2.6.3, 22.2.2 V$RMAN_OUTPUTビュー, 11.5.2 V$RMAN_STATUSビュー, 23.1.1 V$SESSIONビュー, 6.5, 11.1.2, 23.2, 23.2.2 V$SESSION_LONGOPSビュー, 22.3.1 V$SESSION_WAITビュー, 23.2, 23.2.1 V$SGASTATビュー, 22.4.3 V$SYSSTATビュー, 7.5.4 V$TABLESPACEビュー, 17.2.1.2.2, 28.1.1 VALIDATEコマンド, 15.1.2.2, 15.3, 16.2, 17.2.1.2.1

SECTION SIZEパラメータ, 16.2

VALIDATE HEADERオプション, RESTOREコマンド, 11.1.2 検証, RMAN, 15.3

バックアップ, 2.4.5, 16.2, 16.2, 16.2, 16.2, 16.3, 16.3, 16.3, 16.3

データベース・ファイル, 2.4.5, 16.2

リストア操作, 17.2.4

ビュー, リカバリ・カタログ, 11.1.2, 11.5 仮想プライベート・カタログ, 3.4

削除, 13.5.5

Volume Shadow Copy Service(VSS), 5.3.1, 9.5.3.1

W

ウォレット, 6.2.6.1.1

データベース全体のバックアップ

ARCHIVELOGモード, 28.2

非一貫性, 28.2

NOARCHIVELOGモード, 28.2

準備, 28.2

RMANの使用, 9.3.1, 9.3.1

オラクル社の法律上の注意点について

コピーライトについて

Copyright © 1994-2015, Oracle and/or its affiliates.All rights reserved.

商標と登録商標について

OracleおよびJavaはOracle Corporationおよびその関連企業の登録商標です。その他の名称は、それぞれの所有者の商標または登録商標です。

Intel、Intel Xeonは、Intel Corporationの商標または登録商標です。すべてのSPARCの商標はライセンスをもとに使用し、SPARC International, Inc.の商標または登録商標です。AMD、Opteron、AMDロゴ、AMD Opteronロゴは、Advanced Micro Devices, Inc.の商標または登録商標です。UNIXは、The Open Groupの登録商標です。

ライセンス制約の保証と結果的に生じる損害の免責

このソフトウェアおよび関連ドキュメントの使用と開示は、ライセンス契約の制約条件に従うものとし、知的財産に関する法律により保護されています。ライセンス契約で明示的に許諾されている場合もしくは法律によって認められている場合を除き、形式、手段に関係なく、いかなる部分も使用、複写、複製、翻訳、放送、修正、ライセンス供与、送信、配布、発表、実行、公開または表示することはできません。このソフトウェアのリバース・エンジニアリング、逆アセンブル、逆コンパイルは互換性のために法律によって規定されている場合を除き、禁止されています。

保証免責

ここに記載された情報は予告なしに変更される場合があります。また、誤りが無いことの保証はいたしかねます。誤りを見つけた場合は、オラクル社までご連絡ください。

制限付権利

このソフトウェアまたは関連ドキュメントを、米国政府機関もしくは米国政府機関に代わってこのソフトウェアまたは関連ドキュメントをライセンスされた者に提供する場合は、次の通知が適用されます。

U.S. GOVERNMENT END USERS: Oracle programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, delivered to U.S. Government end users are "commercial computer software" pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations.As such, use, duplication, disclosure, modification, and adaptation of the programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, shall be subject to license terms and license restrictions applicable to the programs.No other rights are granted to the U.S. Government.

危険な用途への使用について

このソフトウェアもしくはハードウェアは様々な情報管理アプリケーションでの一般的な使用のために開発されたものです。このソフトウェアもしくはハードウェアは、危険が伴うアプリケーション（人的傷害を発生させる可能性があるアプリケーションを含む）への用途を目的として開発されていません。このソフトウェアもしくはハードウェアを危険が伴うアプリケーションで使用する際、安全に使用するために、適切な安全装置、バックアップ、冗長性（redundancy）、その他の対策を講じることは使用者の責任となります。このソフトウェアもしくはハードウェアを危険が伴うアプリケーションで使用したことに起因して損害が発生しても、オラクル社およびその関連会社は一切の責任を負いかねます。

第三者のコンテンツ、製品、サービスに対する免責事項

このソフトウェアまたはハードウェア、そしてドキュメントは、第三者のコンテンツ、製品、サービスへのアクセス、あるいはそれらに関する情報を提供することがあります。オラクル社およびその関連会社は、第三者のコンテンツ、製品、サービスに関して一切の責任を負わず、いかなる保証もいたしません。オラクル社およびその関連会社は、第三者のコンテンツ、製品、サービスへのアクセスまたは使用によって損失、費用、あるいは損害が発生しても一切の責任を負いかねます。

ドラフトのアルファ版およびベータ版ドキュメントについて

このドキュメントが試作版の場合:

このドキュメントは試作版であり、デモおよび暫定使用のみを目的としたものです。このソフトウェアを使用するハードウェアに限定するものではありません。オラクル社およびその関連会社は、このドキュメントに関して一切の責任を負わず、いかなる保証もいたしません。また、このドキュメントを使用したことによって損失、費用、あるいは損害が発生しても、一切の責任を負いかねます。