O
O
R
R
A
A
C
C
L
L
E
E
R
R
E
E
C
C
O
O
V
V
E
E
R
R
Y
Y
M
M
A
A
N
N
A
A
G
G
E
E
R
R
(
(
R
R
M
M
A
A
N
N
)
)
1
1
0
0
g
g
:
:
リロ
リ
ロー
ーデ
デッ
ッド
ド
Tammy Bednar, Oracle
進化と改革
データベースのバックアップは、メディア障害から Oracle データベースを守る唯一の方法と言えます。重要なデータの リカバリが大切なことは明確なため、 データベース管理者(DBA)にはそのための多数のツールや方法が用意されていま す。テープによる単純なウイークリーのバックアップから、より複雑なファイル・スナップショット、スタンバイ・デー タベースにいたるまで、Oracle データを保護するために必要なコストと複雑さは多岐にわたります。Oracle Data Guard 1 は、企業の Oracle データベースに悪影響を及ぼす障害、人為的エラー、破損などの克服を容易にするよう構成します。 どのツールやオプションも、それぞれ継続的に利用できる独自の利点があり、Oracle データベースのバックアップやリカ バリ、あるいはその両方を迅速に行えます。 データの保護とリカバリに使用する方法やツールは、次の条件を備えている必要があります。 • 信頼性：リカバリに必要なすべてのファイルがバックアップされ、リカバリ操作で簡単にリストアできる。 • 柔軟性：Oracle データベースがデータベース、表領域、データファイルおよびブロック・レベルでバックアップでき、 リストアできる。 • 管理性：バックアップ・ファイルがリストア操作で使用できるよう編成され管理されている。 • 可用性：バックアップ操作がデータベース・トランザクション処理に干渉せず、リカバリ操作が迅速かつ効率的であ る。
Oracle Recovery Manager は、Oracle Database 10g の革新的な技術の進歩により、ユーザーが待ち望んでいた使い易さと信 頼性を実現した自動リカバリ・ツールとして強化されました。このホワイト・ペーパーでは、バックアップ・ファイルと リカバリ・ファイルの管理、拡張された増分バックアップ、異なるプラットフォーム間での表領域データの共有などに対 応した Oracle Database 10g の新機能を説明します。いま改革が始まります。
RECOVERY MANAGER
Recovery Manager (RMAN)は、データベースのバックアップと、さらに重要なデータベースのリカバリを管理する Oracle のユーティリティです。これにより操作上の複雑さが解消され、同時にデータベースは優れたパフォーマンスと可用性を 発揮します。Oracle8 とともにデビューした Recovery Manager は、DBA にバックアップとリカバリの統合的なソリューショ ンを提供します。
Recovery Manager は要求されたバックアップやリストア、あるいはリカバリ操作の最も効率的な方法を決定し、Oracle データベース・サーバーで操作を実行します。Recovery Manager とサーバーはデータベース構造の変更を自動的に特定し、 要求された操作を調整してこの変更にダイナミックに適応させます。
Oracle Database 10g Recovery Manager 機能セットは、障害の起きた重要な Oracle データのリカバリに改革をもたらします。 抽出の負担も追加のインストールもまったく必要とせず、RMAN は Oracle データベース・ファイルのバックアップとリ カバリを管理します。RMAN は Oracle カーネルと緊密に統合されているため、Oracle データベースを効果的にリカバリ するために最適な方法を決定します。
FLASH RECOVERY AREA
今日、ディスク領域の価格は 5 年前、あるいは 1 年前と比べても安価になっています。ディスクのサイズが大きく、現在 の格納に必要なのは数ギガのディスク領域にすぎず、記憶域が未使用のまま残っている場合があります。 このような空きディスク領域はどう扱えばよいか、悩んでいませんか。そのようなディスク領域にデータベースのバック アップを取ることは検討に値します。ディスクへのバックアップは、テープ書込みのボトルネックが解消されるため、速 度が向上します。しかしさらに重要なことは、もしデータベース・メディア・リカバリが必要となった場合、データファ イルのバックアップが使用可能だということです。リストアとリカバリの操作時間も減少します。必要なデータファイル とアーカイブ・ログをリストアするために、テープと空きテープ・デバイスを探す必要はないからです。 しかし、ここで少し考えてみましょう。ディスクへのバックアップは、別に新しい考え方ではありません。DBA は、こ のタイプのバックアップとリカバリの方針を何年も前から採用しています。RMAN では、常にディスクからデータベー スのバックアップとリカバリが可能でした。そこで、Flash Recovery Area とは何か、なぜそれが DBA にとってきわめて 貴重なのか、です。Flash Recovery Area は、Oracle データベース中のリカバリ関連ファイルおよびアクティビティすべての統一格納場所です。 init.ora に 1 つのパラメータを定義するのみで、RMAN のバックアップ、アーカイブ・ログ、制御ファイルの自動バック アップ、データファイル・コピーすべてが、指定のファイル・システムあるいは ASM Disk Group に自動的に書き込まれ ます。
DB_RECOVERY_FILE_DEST = /oracle/flash_recovery_area
Flash Recovery Area に十分な領域を割り当てれば、Oracle データベースのリカバリはより高速で簡単、そして自動的にな ります。このためリカバリ時間の目標達成は、リカバリ関連のファイルを割り当てられる空き領域の量に依存します。あ る調査によれば、大部分のリカバリ操作では、その 95%が 3 日分のバックアップしか必要としません。したがって、3 日 分のデータベース・バックアップおよびアーカイブ・ログを維持するためのディスク領域があれば、必要なバックアップ もローカルで実行できます。システム管理者は必要なバックアップ・ファイルをリストアするために、テープを取得する こともテープ・デバイスを空けることも不要です。 Oracle Database 10g は、リカバリ関連ファ イルをディスク上の 1 つの位置に編成す るためのパラメータを備えています。 「すでに、自分のディスクにバックアップ を行い、必要なすべてのアーカイブ・ロ グ・デスティネーションを構成できるの に、それが何の役に立つのか」と疑問に 思いますか？おおいに意味があります。 Flash Recovery Area はディスク上のファ イルを管理します。Flash Recovery Area は RMAN RETENTION POLICY を構成す ることにより、この構成に基づいて不要 なバックアップとアーカイブ・ログを自 動的に削除します。ユーザーが
に必要なすべてのバックアップを保存します。全リカバリ・ファイルのために十分なディスク領域を用意しておけば、他 に必要なのはオフサイトの障害からのリカバリと、長期的保管の必要性に備えてテープにバックアップすることだけです。
メディア障害からデータベースを完全にリカバリするために必要なファイルはすべて、Flash Recovery Area にあります。 リカバリ関連のこれらファイルは次のとおりです。
• 制御ファイル：データベースの作成時、Flash Recovery Area の場所にコピーが作成されます。
• アーカイブ・ログ・ファイル：Flash Recovery Area の構成時、Flash Recovery Area 内およびその他構成済の
LOG_ARCHIVE_DEST_n の位置に、アーカイバのバックグラウンド・プロセスによってアーカイブ・ファイルが作成 されます。
• フラッシュバック・ログ：Flash Recovery Area は Flashback Database ログを自動的に管理します。
• 制御ファイルの自動バックアップ：制御ファイルのデフォルト位置です。
• データ・ファイルのコピー：RMAN が作成したデータ・ファイル・コピーのデフォルト位置は、Flash Recovery Area
に格納されます。
• RMANのバックアップ：RMAN がバックアップおよびコピー操作の際、ファイルを作成するためのデフォルト位置で す。またこれは、リカバリ・タスクの際にアーカイブ・ログが必要とされた場合、これらログをテープからリストア するためのデフォルト位置でもあります。
Enterprise Manager は Flash Recovery Area を定義するため のインタフェースとなります。
Flash Recovery Area により次のことが可能です。
• 関連する複数のリカバリ・ファイルの統一的な格納場所 • リカバリ・ファイルに割り当てられたディスク領域の管理 • データベース管理タスクの簡素化 • バックアップの大幅な高速化 • リストアの大幅な高速化 • ディスク本来の信頼性による大幅な信頼性向上
AUTOMATIC STORAGE MANAGEMENT
バックアップとリカバリを検討する場合、同時にファイル・ストレージについても検討する必要があります。両者は密接 に関連して機能します。
Oracle 10g は、DBA にストレージ・リソースのための簡素化された管理インタフェースを与えます。それは Automatic Storage Management (ASM)で、これによって手作業によるパフォーマンス・チューニングが不要になります。ASM は、物 理的記憶域を仮想ディスクのセットにグルーピングします。これら仮想ディスクは、高レベルの保護が可能な冗長性オプ ションを提供します。ASM は、既存アプリケーションの変更を必要としない記憶域割当てを容易にし、自動的リバラン シングを可能にします。また使用可能な記憶域全体にデータベース・ファイルを分散させ、パフォーマンスとリソースの 利用を最適化します。さらに手作業によるタスクを自動化し、より大きいデータベースをほとんどの場合、より高い効率 で管理する能力を高め、DBA の時間を節約します。
Flash Recovery Area は ASM を使用して構成します。ASM は耐障害性であり、ディスクあるいはアレイに障害が発生する と、自動的に再ミラーリングするよう設計されているため、バックアップは自動的に保護されます。さらに ASM は、リ カバリに使用するユーザー・ファイルが、Oracle 以外のプロセスによって上書き、あるいは破損するのを防止します。 ASM の詳細は、『OracleWorld technical white paper 40140 - Oracle Database 10g: Simplify Your Job with Automatic Storage Management』を参照してください。
変更追跡ファイル
増分バックアップは、RMAN が Oracle8 で初めてリリースされて以来、サポートされています。増分バックアップは、前 回のバックアップ以降変更されたブロックのみをバックアップする機能です。Oracle Database 10g は、変更追跡ファイル 機能を実装し、増分をより速く取得する能力があります ブロック変更追跡機能を使用可能にしておくと、Oracle はあらゆるデータベース変更の物理的位置を追跡します。 RMAN は変更追跡ファイルを自動的に使用して、増分バックアップでどのブロックを読む必要があるかを判断し、この ブロックに直接アクセスしてバックアップします。ブロック変更追跡が有効にされていない場合は、前回のバックアップ 以降、そのファイルのごく一部しか変更されていなくとも、変更のあるブロックを検索してバックアップするために、増 分バックアップのたびにデータファイル全体を読み取ります。ブロック変更追跡を有効にするには、次のコマンドを使用 します。ALTER DATABASE ENABLE BLOCK CHANGE TRACKING;
増分バックアップと変更追跡ファイルをバックアップ方針の一部にしておくと、次のことが可能です。 • 毎日のバックアップに必要な時間の削減 • ネットワーク経由でバックアップする場合、ネットワーク帯域幅の節約 • ログのないデータベース変更のリカバリ、たとえば NOLOGGING オプションがダイレクト・ロードで使用された場 合、インサートによる REDO ログ・エントリの作成は行われず、その変更をメディア・リカバリで適用するのは不可 能です。増分バックアップでは変更されたブロック・イメージが取得され、リカバリに使用できます。 • バックアップ・ファイルの記憶域の削減更新されるブロックの数やバックアップの頻度に影響されますが、増分バッ クアップは全データベースのバックアップよりも規模、消費する記憶域ともに小さくて済みます。 • 変更されたブロックの高速バックアップが可能
INCREMENTALLY UPDATED BACKUPS
Oracle’s Database 10g の Incrementally Updated Backups 機能は、データファイルのイメージ・コピーに RMAN の増分バッ クアップを適用する機能です。この機能を実行すると、イメージ・コピーは、増分バックアップで取得されたブロック変 更によって更新されます。イメージ・コピーへの増分バックアップの適用は、RMAN RECOVER コマンドで実行します。 この処理はバックグラウンドで行われ、データベース・インスタンスを必要としません。 バックアップ・ウィンドウの短縮はもはや問題ではなくなります。Oracle は、データファイル・イメージ・コピーを最新 の増分バックアップにより継続的に更新する機能によって、データベース全体のバックアップを不要にしました。 このバックアップの段階的な更新に基づくバックアップ方針を採用すれば、データベースのメディア・リカバリに必要な 時間を最小限に保つことができます。RMAN はデータベースのイメージ・コピーの段階的更新をリストアし、前回のバッ クアップ以降生成されたアーカイブ・ログの適用以外何も必要としません。この場合メディア・リカバリに必要な時間は、 増分バックアップを作成し、これをイメージ・コピーに適用する頻度に依存します。 増分バックアップのデータ・ファイル・イメージ・コピーへの適用には、次のような効果があります。 • データベース全体のバックアップを不要にする。 • イメージ・コピーが最新のブロック変更で更新されるため、メディア・リカバリに必要な時間が削減される。
ORACLE の推奨方針
Flash Recovery Area、増分バックアップおよび Incrementally Updated Backups を利用したバックアップ・ソリューションで は、Oracle データベースの高速かつ容易なリカバリが可能です。Enterprise Manager バックアップ・ウィザードはデータ ベース・バックアップを構成し、そのスケジュールを作成するためのメカニズムです。
バックアップ・ウィザードでは、次のことを求めるプロンプトが表示されます。
1. すべての RMAN バックアップとアーカイブ・ログが指定のディレクトリに書き込まれるよう、Flash Recovery Area を構成すること。 2. ホスト上でバックアップを実行する最適の時間を決定すること。通常バックアップは、ユーザーのアクティビティ が最低の時間に設定されます。 3. バックアップの時間を見直し確認すること。Enterprise Manager は、バックアップ・ジョブが毎晩同時刻に実行さ れるようサブミットします。 各データファイルについて、Oracle の推奨方針では、バックアップを次のように行うよう求めています。 • 第 1 日目の初め（予定された最初のジョブが実行されるとき）、増分レベル 0 のデータファイル・コピーのバックアッ プを作成。このバックアップには第 1 日目の初めのデータファイル内容が含まれます。リストア・アンド・リカバリ・ シナリオでは、第 1 日目からの REDO ログを使用して、この日の任意の時点にリカバリすることができます。 • 第 2 日目の初め、増分レベル 1 のバックアップを作成。これには第 1 日目に変更されたブロックが含まれます。 リストア・アンド・リカバリ・シナリオの場合、この増分レベル 1 は、第 2 日目の初めにロールフォワードされたレ ベル 0 のバックアップを、速やかにリカバリするために適用でき、また REDO ログを使用してこの日の任意の時点に リカバリすることができます • 第 3 日目以降各 n 日の初め、第 n-1 日目の初めからのレベル 1 のバックアップをレベル 0 のバックアップに適用しま す。 これによりデータファイル・コピーは、第 n-1 日目の初めの状態になり、次いで新たにレベル 1 が作成されます。
これには第 n-1 日目に変更されたブロックが含まれます。リストア・アンド・リカバリ・シナリオの場合、この増分 レベル 1 はリストア済のバックアップを第 n 日目の初めに、速やかにリカバリするために適用でき、また REDO ログ を使用してこの日の任意の時点にリカバリすることができます.
この方針は一見複雑なようですが、Enterprise Manager ですべて自動化されています。ユーザーはまた各バックアップ・ ウィンドウで、次の 2 つの RMAN コマンドを実行するだけで、推奨方針を独自に実行することもできます。
RECOVER COPY OF DATABASE WITH TAG oracle_strategy;
BACKUP INCREMENTAL LEVEL 0 DATABASE FOR RECOVER OF COPY WITH TAG oracle_strategy;
バックアップの管理
Enterprise Manager 10g には、RMAN バックアップのリストを作成し修正する機能があります。また RMAN バックアップ、 アーカイブ・ログ、制御ファイル・バックアップ、イメージ・コピーの点検もできます。RMAN バックアップのリンク を選択すると、そのバックアップ中にあるすべてのファイルが表示されます。 Oracle の 推奨方針の 開始 EM がスケジュール を作成した バックアップの実行 前夜の増分バックアップ を使用して イメージ・コピーを ロールフォワード 別の増分 バックアップを 作成
クロス・プラットフォームな移動性
Oracle トランスポータブル表領域機能は、複数の Oracle データベースの間で表領域を迅速に移動で きます。これは複数のデータベース間で、バルク・ データを移動する最も効率的な方法です。 この方法によるデータの移動は、同じデータをエ クスポート/インポートあるいはアンロード/ロー ドするよりはるかに高速です。これは表領域の移 動にデータファイルのコピーと表領域構造情報の 統合以外、必要とされないためです。またこの機能を使用して索引データを移動することもできます。これにより表デー タをインポートまたはロードするとき、実行が必要な索引の再構築を回避できます。 Oracle Database 10g は、複数のプラットフォーム間で表領域を移動する機能を備えています。この機能は次の目的に使用 できます。 • 構造化データを公開し、別プラットフォーム上で Oracle を使用している顧客にこのデータを配布するための、より簡 単かつ効率的な手段をコンテンツ・プロバイダに提供する。 • 小規模なプラットフォームを運用することが多い、データ・マートへのデータ・ウェアハウス環境からのデータ配布 を簡素化する。 • 異なるクラスタ全体にわたる読込み専用表領域の共有を有効にする。 • あるプラットフォームから別プラットフォームへのデータベースの移行を可能にする。 すべてではありませんが、多くのプラットフォームではクロス・プラットフォームな表領域移行機能がサポートされてい ます。プラットフォームのサポートを確認し、そのプラットフォーム ID とエンディアン・フォーマット（バイトの並び 順）を判定するには、V$TRANSPORTABLE_PLATFORM ビューに問合せます。 もしソース・プラットフォームとターゲット・プラットフォームのエンディアンが異なる場合、移動される表領域をター ゲットのフォーマットに変換するため、追加の変換ステップをいずれかの側のプラットフォームで実行する必要がありま す。もし双方のエンディアンが同じであれば変換は不要で、表領域は同一プラットフォームの場合と同様に移動できます。表領域を別プラットフォームに移動するためには、互換性が 10.0.0 以上に設定された Oracle 10g データベース内で少なく とも 1 回、この表領域が読み/書きされている必要があります。これは、この読み/書きによって表領域内のデータファイ ルにプラットフォームを意識させる、つまり各ファイルにその属するプラットフォームを識別させるためです。
さらに進む改革
これまで Oracle Database 10g の主なリカバリ機能を紹介してきましたが、他にも紹介したい機能があります。 • アーカイブ・ログとバックアップの圧縮： ディスク領域がプレミアムの場合、RMAN バックアップとアーカイブ・ ログをディスク上に圧縮して保持することができ、これによりデータベースをリカバリする時間の短縮も可能です。 リカバリ操作では圧縮バックアップ・ファイルが使用できるため、バックアップ・ファイルの解凍は不要です。 • バックアップの紛失あるいは破損でもリストアが可能： RMAN は、既知のバックアップすべてを備えたデータベー スのリストアを意図しています。データベースの完全なリカバリには前回のバックアップを使用するのが理想的です。 しかし、もし前回のバックアップが利用できない場合、RMAN は次に妥当なバックアップを自動的に判定して、リカ バリに使用します。 • 以前のPoint-in-Timeリカバリによる自動化リカバリ：データベースのリカバリを以前の時点で行い、次いで RESETLOGS オプションでデータベースをオープンする必要がある場合があります。Oracle 10g 以前では、もしデー タベースが resetlog の後に損傷し、かつ全体バックアップを行う前で、resetlogs 前の前回のバックアップを使用して リカバリを行う必要がある場合、リカバリ処理は複雑でエラーがおきる可能性がありました。10g では、RESETLOGS のオープン前に取られたバックアップから、一部のデータファイルがリストアされたようなケースでも、Oracle のリ カバリ機能により透過的に処理されます。 • 全自動による表領域のPoint-in-Timeリカバリ： RMAN が備えた 1 つのコマンドだけで、表領域を過去の一時点でリ カバリできます。この操作は全自動であり、リカバリ終了とともに表領域は利用可能となります。 • バックアップまたはリストア時の自動チャンネル・フェイルオーバー：バックアップあるいはリストア操作が完了す る直前になって、エラーによるチャンネル停止のため、最後のファイル操作が完了しないことがよくあります。 RMAN では、割り当てられた他のどのチャンネルでも、その後、操作完了まで自動的に継続します。 • 表領域の名称変更：複数の表領域が同じ名前を持つことがあります。とくに表領域がクローンである場合はそうです。 クロス・プラットフォーム・トランスポータブル表領域機能により、データを表領域レベルで移動することがはるか に容易になります。この表領域名称変更機能は、表領域の移動性を高める機能です。 • データベースの削除：データベースが試験と適格性判定のため、定期的に作成される場合、この一時的データベース の使用が終わった後は、これに属するファイルを削除する必要があります。削除しないとディスクはオーファンの データファイルでいっぱいになります。新設の RMAN DROP DATABASE コマンドは、OS から全データベース・ファ イルを削除するプロセスを提供します。RMAN とユーザー管理によるリカバリとの比較
Recovery Manager を使用すると、Oracle データベースを効率的にリカバリできます。しかし多くの DBA はバックアップ 操作、リカバリ操作のために自社製のスクリプトを使用し続けています。次の表は、RMAN とユーザー管理によるリカ バリに共通な操作を比較したものです。 操作 Recovery Manager での手順 ユーザー管理によるリカバリでの手順 データファイルの 喪失 1. データファイルまたは表領域、 あるいは両方をオフラインにす る。 2. RMAN がデータファイル・ バックアップをリストアする。 3. RMAN がデータファイルを リカバリしながら、必要なアーカ イブ・ログを自動的にリストアす る。 4. データファイルまたは表領域、 あるいは両方をオンラインにす る。 1. バックアップ、特に最近のバックアップを見つけ出す。 2. バックアップがテープ上にある場合、ファイルのリストアを要求 する。 3. データファイルまたは表領域、あるいは両方をオフラインにす る。 4. データファイルのリカバリ・コマンドを発行する。 5. アーカイブ・ログが要求された場合、これをリストアする。 6. リカバリ・コマンドから要求されたアーカイブ・ログを適用する。 7. データファイルまたは表領域、あるいは両方をオンラインにす る。 破損ブロックの修復 1. block_number のブロック・ リカバリを実行する。 1. データをエクスポートする。 2. 破損ブロック内のデータは、スタンバイ・データベースまたは 前回のバックアップから抽出できなければ失われる。また破損 ブロックが 1 つのみであっても、このブロックより先にある表 データの抽出はきわめて困難である。 3. 表データをインポートする。 表領域 Point-in-Time リカバリ
1. RECOVER TABLESPACE users, tools UNTIL TIME ‘July 7, 2003’ を実行する。 1. 一時データベースのために an init.ora ファイルを作成する。 2. System、Undo、Users および Tools のためのバックアップを リストアする。. 3. リカバリに必要な必須のアーカイブ・ログをリカバリする。 4. 一時データベースをマウントし、2003 年 7 月 7 日までのリカバリ を実行する。 5. Data Pump ファシリティを使用してデータ・ディクショナリの データを抽出し、Users 表領域と Tools 表領域がデータベースに プラグインできるようにする。 6. Users 表領域と Tools 表領域を本番データベースにプラグイン する。 7. TSPITR 操作のためにリストアされた一時データベース・ファイ ルを削除する。 全オンライン制御 ファイルの喪失 1. RESTORE CONTROLFILE を 実行する。 1. データベース・ファイルとオンライン・ログすべてを含んだ 制御ファイル作成スクリプトを作成する。 2. スクリプトを実行して制御ファイルを作成する。 注: RMAN バックアップおよびアーカイブ済ログ情報はすべて 失われる。 バックアップの 妥当性チェック 1. リストア・データベースの妥当性 チェックを実行する。 利用できるツールがないため実行不可能。
グリッド・クラスタ
進化は改革をもたらします。グリッド・コンピューティングは、コンピュータ利用方法の改革を約束するものです。そし て、これからの道のりはたどることが容易な進化の道です。グリッドに向かって、一歩づつ容易に進むことができます。 一歩ごとに恩恵はますます大きくなります。 企業はその全ニーズのためにリソースを購入し、必要に応じあるいは方針に基づいて個々の適用に備えることができます。 これにより企業リソースの効率的な活用がもたらされ、また開発、配布、管理のコストが大幅に削減されます。 また組織のコンピュータ利用リソースをどのように配布するかを決定し、組織のニーズの変化に応じてその配布を速やか に変更することができます。 データがどこに置かれていても、RMAN は、必要なデータのバックアップを認知しており、クロス・プラットフォーム・ トランスポータブル表領域機能を使用して、どのプロラットフォームからでもデータをプラグインすることができます。 グリッドの詳細は『Oracle World paper 40123 – Oracle and the Grid』を参照してください。結論
データベースのバックアップは、重要データのリカバリを行うための保険です。Oracle Database 10g はリカバリ関連のファ イルを Flash Recovery Area で編成し、管理するメカニズムを備えています。これにより、バックアップの位置を突き止め るための、またそれがリカバリのために必要でなくなったときに削除するための手作業が不要になります。また RMAN は新しい変更追跡ファイル機能を備えているため、もしバックアップ・ウィンドウが縮小している場合、前回のバックアッ プ以降変更されたブロックのみを読み出すことが可能です。Oracle Database 10g の先進的なテクノロジと Enterprise Manager を使用して、リカバリ時間の目標を達成するリカバリ方針の実施は今、実現可能となりました。 データの保護とリカバリのために使用する方法あるいはツールは、次の条件を備えている必要があります。 • 信頼性 • 柔軟性 • 管理性 • 可用性 RMAN は上記の条件をすべて備えています。RMAN を、ぜひ一度お試しください。優れたバックアップ・テクノロジは まだ失われていません。そのすべては Oracle Database 10g から始まります。
