Oracle Database10g バックアップおよびリカバリ概要
ナビゲーションに移動
検索に移動
目次
- 1 Oracle Database10g バックアップおよびリカバリ概要
- 1.1 物理バックアップと論理バックアップ
- 1.2 バックアップからのリカバリが必要なエラーおよび障害
- 1.3 バックアップおよびリカバリ・ソリューション
- 1.4 バックアップおよびリカバリ: 基本概念
- 1.5 データ・リカバリの方式
- 1.6 Recovery Managerを使用したバックアップおよびリカバリ
- 1.7 Recovery ManagerでのOracleデータベースのバックアップのタイプ
- 1.8 自動ディスク・ベース・バックアップおよびリカバリ: フラッシュ・リカバリ領域
Oracle Database10g バックアップおよびリカバリ概要
物理バックアップと論理バックアップ
- 物理バックアップは、安全なバックアップおよびリカバリ計画の基礎
- 論理バックアップは、様々な状況で物理バックアップを補足するために役立ちますが、物理バックアップがなければデータ消失に十分に対処することはできない。
物理バックアップ
- データベースの保存およびリカバリに使用する物理ファイルをバックアップしたもの
- データ・ファイル、制御ファイル、アーカイブ REDOログなどが対象
- 他の場所(ディスクや、テープなどのオフラインの記憶域)にデータベース情報を保存するファイルのコピーは、すべて物理バックアップ
論理バックアップ
- Oracleエクスポート・ユーティリティを使用してデータベースからエクスポートし、バイナリ・ファイルに格納した論理データ（表、ストアド・プロシージャなど）
- 対応するOracleインポート・ユーティリティを使用してデータベースに再インポートできる。
バックアップからのリカバリが必要なエラーおよび障害
- 通常、DBAが介入してメディア・リカバリを行う必要があるのは、メディア障害およびユーザー・エラーの2つの問題が発生した場合のみ
ユーザー・エラーの理解
- アプリケーション・ロジックのエラーまたは誤操作のため、データベースのデータが誤って変更または削除された場合に発生
- ユーザー・エラーによるデータ消失とは、誤操作によって重要な表を削除したり、表の内容を削除または変更することを指す。
- ユーザー・エラーによるデータ消失が発生したときに、消失したデータをすみやかにリカバリできるかどうかは、バックアップ計画にかかっている。
メディア障害の理解
- データベースの稼働に必要なディスク・ファイルに対する読取りまたは書込みの障害
- メディア障害からの適切なリカバリ方法は、障害の影響を受けたファイル、および使用できるバックアップのタイプによって異なる。
バックアップおよびリカバリ・ソリューション
Recovery Manager
- コマンドライン・クライアント・インタフェースおよびEnterprise Manager GUIインタフェースを備えたツール
- Oracleサーバー上で動作するセッションと一体になって、各種のバックアップおよびリカバリ操作を実行し、バックアップに関する履歴データのリポジトリの管理を行う。
ユーザー管理のバックアップとリカバリ
- ホスト・オペレーティング・システムのコマンドと、SQL*Plusのバックアップおよびリカバリ関連機能の両方を使用
- データベースを構成するファイルを直接管理する方法。
バックアップおよびリカバリ: 基本概念
データのリカバリで使用されるデータベースの物理構造
| 物理構造 | 内容 |
|---|---|
| データ・ファイルおよびデータ・ブロック | 一貫性のある停止によってクローズされていないデータ・ファイルは、通常は最新の状態になっていない。どのバックアップでも重要 |
| REDOログ | データベースのデータ・ファイルに対する変更をすべて記録。アーカイブREDOログがない場合、データベースをバックアップするには、まずデータベースをオフラインにする必要がある。バックアップからデータベースをリストアする必要がある場合でも、データベースで使用できるのはバックアップした時点での内容のみ |
| UNDOセグメント | リカバリの処理では、UNDO情報は、データ・ファイルのすべての変更がREDOログからデータ・ファイルに適用された直後に、コミットされていないトランザクションの影響を元に戻すために使用。 |
| 制御ファイル | データベースの物理構造とその状態に関する記録が格納。制御ファイルを失うと、データ消失からのリカバリは非常に困難 |
データ・リカバリの方式
データ・ファイルのメディア・リカバリ: データ・ファイルのリストアとREDOの適用
- メディア・リカバリは、ユーザーが開始するデータ・リカバリの最も基本的な方式
- 現行のデータ・ファイルまたはSPFILE、制御ファイルの消失または破損からリカバリするときに使用
- OFFLINE NORMALオプションを使用せずにオフラインにしたために、REDOログには記録されていても、表領域のデータ・ファイルには書き込まれなかった変更をリカバリするためにも使用できる。
- Recovery Managerまたはユーザー管理のバックアップおよびリカバリの、いずれの方法でも実行できる。
- バックアップからリストアする必要があるかどうかは、自動的には検出されない。
- 最初の手順では、バックアップからデータ・ファイルをコピーして手動でリストア
- バックアップからデータ・ファイルをリストアすると、そのデータ・ファイルが古いものであり、メディア・リカバリを実行する必要があることが、データベースで自動的に検出される
完全、不完全およびPoint-in-Timeリカバリ!
完全リカバリ
- コミットされたトランザクションによる変更を失うことなく、データベースを最新の時点までリカバリすること
- 通常、リカバリとは完全リカバリを指します。
不完全リカバリ、Point-in-Timeリカバリ
- 場合によっては、データベースを過去のある時点の状態に戻したい場合、たとえば、表または表の内容の削除などのユーザー・エラーの結果を元に戻したい場合には、データベースを内容が削除される前の状態に戻す必要がある。
- 不完全リカバリは、Point-in-Timeリカバリとも呼ばれ、データベースを過去のターゲットSCNまたは時刻までリストアするための機能。
- Point-in-Timeリカバリは、ユーザー・エラー、気付かぬうちに進行した論理的な破損などによって発生したデータ消失に対処する方法の1つ。
- Point-in-Timeリカバリは、リカバリを実行する際に、リストアしたバックアップから、リカバリのターゲットSCNまでの間を埋めるアーカイブ・ログがないことに気付いたときに実行できる唯一の方法。
インスタンス障害後の自動リカバリ: クラッシュ・リカバリ
- クラッシュ・リカバリ処理は、特殊なリカバリの方式で、クラッシュ後（またはSHUTDOWN ABORT後）、初めてOracleデータベース・インスタンスを起動するときに実行される。
- データ・ファイルをトランザクションの一貫性がある状態に戻し、インスタンス障害が発生した時点までのコミットされた変更をすべて維持することを目的とする。
Recovery Managerを使用したバックアップおよびリカバリ
Recovery Managerで可能なリカバリ方式と機能
| 機能 | 内容 |
|---|---|
| 増分バックアップ | バックアップの容量をより小さくまとめ（変更されたブロックのみを格納し）、データ・ファイルのメディア・リカバリを高速化 |
| ブロック・メディア・リカバリ | 破損データ・ブロックが少ないデータ・ファイルを、オフラインにすることも、バックアップからリストアすることもなく修復。 |
| 未使用ブロックの圧縮 | Recovery Managerがバックアップ時に未使用のデータ・ファイル・ブロックをスキップできます。 |
| バイナリ圧縮 | 圧縮メカニズムを使用して、バックアップのサイズを小さくします。 |
| 暗号化バックアップ | 暗号化機能を使用して、バックアップを暗号化された形式で格納 |
Recovery ManagerでのOracleデータベースのバックアップのタイプ
一貫性バックアップと非一貫性バックアップ
一貫性バックアップ
- 一貫性バックアップは、データベースに一貫性がある状態、つまりREDOログ内のすべての変更がデータ・ファイルに適用されているときに作成されたバックアップ
- 一貫性バックアップからリストアしたデータベースは、メディア・リカバリを実行することなく、すぐにオープンできる。
- ただし、一貫性バックアップは、一貫性のある状態で停止した後にのみ作成できます。クラッシュの発生後、またはSHUTDOWN ABORTの実行後には作成できません。
非一貫性バックアップ
- 可用性を高めるため、Oracleデータベースは、データベースをオープンしたままで作成できる非一貫性バックアップを使用した場合でも、正常に動作するように設計されている。
- ただし、データベースを非一貫性バックアップからリストアした場合は、メディア・リカバリを実行して、オンラインおよびアーカイブREDOログ内の保留になっているすべての更新情報をそのデータベースで適用できるようにしてから、データベースを再度オープンする必要がある。
- メディア・リカバリにはアーカイブ・ログが必要なため、非一貫性バックアップを使用するには、データベースをARCHIVELOGモードで実行する必要がある。
全体バックアップおよび増分バックアップ
全体バックアップ
増分バックアップ
- 増分バックアップは、データ・ファイル内の変更されたデータ・ブロックだけのコピーを作成するという考え方に基づいている。
- リカバリでは、バックアップで対処できる時間内に、REDOを適用して個々のデータ・ファイルを更新するかわりに、増分バックアップから変更されたブロック全体を抽出することで、リカバリに要する時間を大幅に短縮できる。
- 増分バックアップは、Recovery Managerによってのみ作成できる。
イメージ・コピー、バックアップ・セットおよびバックアップ・ピース
イメージ・コピー
- データベース・ファイルと完全に同一のコピー。
- Recovery Managerを使用して、イメージ・コピーのバックアップを作成できる。
- ただし、作成時に、オペレーティング・システム固有のファイル・コピー・ユーティリティでは実行できない内容の破損状況の確認が実行される。
- Recovery Managerでは、作成されたイメージ・コピーがRecovery Managerリポジトリに記録されるため、データベースのリストア時に使用できる。
- イメージ・コピーは、cp（UNIXの場合）、COPY（Windowsの場合）など、オペレーティング・システムのコマンドを使用しても作成できる。
バックアップ・セット
- Recovery Managerを使用して、バックアップ・セットと呼ばれるRecovery Manager固有の形式でバックアップを格納することも可能。
- バックアップ・セットは、バックアップ・ピースと呼ばれるファイルの集合
- 各バックアップ・ピースには、1つ以上のデータベース・ファイルが含まれる。
- Recovery Managerで実行するバックアップ作業で、1つ以上のバックアップ・セットを作成できまる。
- バックアップ・セットは、Recovery Managerリポジトリに記録されまる。
- バックアップ・セットは、Recovery Managerによって、テープ・ライブラリなどのメディア・マネージャ・デバイスにバックアップを書き込む場合に使用できる唯一の形式
- バックアップ・セットを作成して取り扱うには、Recovery Managerを使用する必要がある。
自動ディスク・ベース・バックアップおよびリカバリ: フラッシュ・リカバリ領域
- フラッシュ・リカバリ領域を使用すると、バックアップ関連ファイル用のディスク領域を手動で管理したり、ファイルのタイプごとに使用する領域を調整する必要が最小限になります。
Oracle Flashback Technology: Point-in-Timeリカバリの代替方法
- Oracle Flashback Technologyでは、データベースの大部分をバックアップからリストアしたり、Point-in-Timeリカバリを実行せずに、データの過去の状態を表示したり、データを過去の任意の時点にリカバリすることができる、有効な代替機能を提供
- Oracleのフラッシュバック機能が使用可能なほとんどの環境では、これらの機能はメディア・リカバリよりも効率的で簡単。
| 機能 | 内容 |
|---|---|
| Oracle Flashback Query | 目標時点を指定してデータベースに対する問合せを実行し、その時点での状態を示す結果を表示できる。表に対する誤った更新などの不要な変更からリカバリするには、その変更が発生する前の目標時点を選択し、問合せを実行して消失または変更した行の内容を取得 |
| Oracle Flashback Version Query | 指定した期間に1度でも表に存在したすべての行のすべてのバージョンを、表に更新が適用された状態で表示できる。この機能は、消失したデータの値のリカバリおよび問い合せた表への変更の監査の両方に使用できます。 |
| Oracle Flashback Transaction Query | 1つのトランザクションまたは一定期間内のすべてのトランザクションによる変更を表示できます。 |
| Oracle Flashback Table | 表を過去の時点の状態に戻すことができます。データベースがオンラインである間に表データをリストアし、指定した表に対する変更のみを取り消すことができます。 |
| Oracle Flashback Drop | DROP TABLE文の影響を無効にできます。 |
- 上記はいずれもUNDOデータに依存する。
Flashback Query
- 表の過去の状態を問い合せるには、SELECT文のAS OF句を使用
データを登録 09-07-12 23:54:50
SQL> insert into test values (1, 'abcdefg', systimestamp); 1行が作成されました。 SQL> select * from test; ID VALUE UPD_DATE ---------- ---------------------------------------- ------------------------------------ 1 abcdefg 09-07-12 23:54:50.411615
更新しコミット 09-07-12 23:58:24
SQL> update test set value = 'hijklmn', upd_date = systimestamp where id = 1; 1行が更新されました。 SQL> select * from test; ID VALUE UPD_DATE ---------- ---------------------------------------- ------------------------------ 1 hijklmn 09-07-12 23:58:24.976423 SQL> commit; コミットが完了しました。
変更前の状態を検索 09-07-12 23:58:00
- 変更前の情報が検索された
SQL> select * from test as of timestamp to_timestamp('2009-07-12 23:58:00', 'YYYY-MM-DD HH24:MI-SS') 2 where id = 1 3 / ID VALUE UPD_DATE ---------- ---------------------------------------- ------------------------------------------------ 1 abcdefg 09-07-12 23:54:50.411615
変更前の状態に復元
SQL> delete from test where id = 1; 1行が削除されました。 SQL> insert into test (select * from test as of timestamp to_timestamp 2 ('2009-07-12 23:58:00', 'YYYY-MM-DD HH24:MI-SS')) 3 / 1行が作成されました。 SQL> select * from test; ID VALUE UPD_DATE ---------- ---------------------------------------- ------------------------------------- 1 abcdefg 09-07-12 23:54:50.411615
Flashback Table
前提条件
- 表で行の移動が有効である必要がある。 行の移動を有効にするには、次のSQL文を使用。
ALTER TABLE table ENABLE ROW MOVEMENT;
- FLASHBACK ANY TABLEシステム権限または表に対するFLASHBACKオブジェクト権限を持っている必要
- 指定した目標時点またはSCNまでのFLASHBACK TABLE操作に必要な過去の時点までのUNDO情報が、UNDO表領域に保持されている必要
Timestampを指定してFlashback Tableを実行する
- 行移動を有効に
SQL> alter table test enable row movement; 表が変更されました。
- 時間とを確認し行を削除
SQL> select systimestamp from dual; SYSTIMESTAMP --------------------------------------------------------------------------- 09-07-13 00:31:50.401411 +09:00 SQL> select * from test; ID VALUE UPD_DATE ---------- ---------------------------------------- ------------------------------- 1 abcdefg 09-07-12 23:54:50.411615 SQL> delete from test; 1行が削除されました。 SQL> commit; コミットが完了しました。
- Flashback Tableを実行
SQL> flashback table test to timestamp to_timestamp('2009-07-13 00:31:50', 'YYYY-MM-DD HH24:MI-SS'); フラッシュバックが完了しました。
- 戻った
SQL> select * from test; ID VALUE UPD_DATE ---------- ---------------------------------------- --------------------------------- 1 abcdefg 09-07-12 23:54:50.411615
SCNを指定して Flashback Tableを実行する
- 行を挿入しコミット
SQL> insert into test values (3, 'aaaaa', systimestamp); 1行が作成されました。 SQL> commit; コミットが完了しました。
- 行を変更しコミット
SQL> update test set value = 'bbbbb', upd_date = systimestamp where id = 3; 1行が更新されました。 SQL> commit; コミットが完了しました。
- SCNのバージョンを確認し、更新前に戻す
SQL> select id,value,versions_startscn, versions_operation 2 from test versions between scn minvalue and maxvalue 3 where id = 3 4 / ID VALUE VERSIONS_STARTSCN VE ---------- ---------------------------------------- ----------------- -- 3 bbbbb 3103901 U 3 aaaaa 3103865 I SQL> flashback table test to scn 3103865; フラッシュバックが完了しました。
- 戻った
SQL> select * from test where id = 3; ID VALUE UPD_DATE ---------- ---------------------------------------- ------------------------- 3 aaaaa 09-07-13 01:08:53.175519
Flashback Drop
- 表を削除した場合、その表に関連付けられた領域はすぐには削除されません。
- 表の名前が変更され、関連付けられたオブジェクトとともにデータベースのごみ箱に移動されます。
- 削除のフラッシュバック操作を実行すると、その表がごみ箱からリカバリされます
- ごみ箱に格納される依存オブジェクトには、索引、制約、トリガー、ネストした表、LOBセグメント、LOB索引セグメントが含まれます。
ゴミ箱の有効無効切り替え
- データベースでパラメータ・ファイル（PFILE）を使用している場合は、パラメータ・ファイルのRECYCLEBINの値を指定できます。
RECYCLEBIN=OFF
- ユーザー独自のデータベース・セッションにごみ箱の動作を指定する
ALTER SESSION SET RECYCLEBIN=OFF;
- データベース全体に対し、ごみ箱の動作を指定する
ALTER SYSTEM SET RECYCLEBIN=OFF;
テーブルを削除してみる
- ゴミ箱に移動させない削除は、drop table table_name purge とする
SQL> drop table test; 表が削除されました。
- 削除された
SQL> select * from test; select * from test * 行1でエラーが発生しました。: ORA-00942: table or view does not exist
ゴミ箱の内容を問い合わせる
SQL> show recyclebin;
ORIGINAL NAME RECYCLEBIN NAME OBJECT TYPE DROP TIME ---------------- ------------------------------ ------------ ------------------- TEST BIN$boRfKFw95+vgQAB/AQAnzw==$0 TABLE 2009-07-13:00:49:06
Flashback Tableでもとに戻す
SQL> flashback table test to before drop; フラッシュバックが完了しました。
- これでもよい
SQL> flashback table "BIN$boRfKFw95+vgQAB/AQAnzw==$0" to before drop;
元に戻った
SQL> select * from test; ID VALUE UPD_DATE ---------- ---------------------------------------- -------------------------- 1 abcdefg 09-07-12 23:54:50.411615
ゴミ箱の消去
purge recyclebin;
© 2006 矢木浩人
