10gリリース2（10.2）
B19193-02
 目次 |
 索引 |
| Oracle Database バックアップおよびリカバリ基礎 10gリリース2（10.2） B19193-02 |
|
データベース・モードで、このモードの場合、Oracleは一杯になったオンラインREDOログをディスクにコピーする。このモードは、データベース作成時に指定するか、あるいはALTER DATABASE ARCHIVELOG文を使用して指定する。
「アーカイブREDOログ」、「NOARCHIVELOGモード」を参照。
一意となるように生成された内部番号で、データベースの識別に使用される。データベースを作成すると、Oracleが自動的にこの番号を作成する。
SQL文でログ・ファイルの読取り、分析および解析を行うためのユーティリティ。
「アーカイブREDOログ」を参照。
データベース・モードで、このモードの場合、Oracleは一杯になったオンラインREDOログを上書きする前にディスクにアーカイブすることを要求しない。このモードはデータベース作成時に指定するかまたはALTER DATABASE NOARCHIVELOGコマンドを使用して、モードを変更する。
NOARCHIVELOGモードで実行すると、失われたまたは破損したデータがリカバリされる可能性が限られる。
「アーカイブREDOログ」、「ARCHIVELOGモード」を参照。
表領域をNORMALモードでオフライン化するには、ALTER TABLESPACE ... OFFLINE NORMAL文を使用する。表領域内のデータ・ファイルにはチェックポイントが付けられるため、オンライン状態にする前にリカバリする必要はない。表領域がNORMALモードでオフライン化されなかった場合は、そのデータ・ファイルをオンラインにする前にリカバリする必要がある。
Recovery ManagerのFLASHBACKコマンドまたはSQL*PlusのFLASHBACK文によって、データベース全体を以前の一貫性のあるSCNに戻す機能。データベースのフラッシュバックは、物理ファイルをリストアせずに、変更されたデータ・ブロックの保存イメージを使用して現行のデータ・ファイルを過去の状態にリストアするという点で、従来のメディア・リカバリとは異なる。フラッシュバック・データベース・プロセスでは、フラッシュバック・ログとアーカイブREDOログが使用される。
Oracleデータベースの機能の1つ。ディスクの専用領域内でのOracleデータベース・ファイルの作成、命名および削除を管理し、DBAがその指定に関与する必要性を最小限にする。
Oracle Managed Files機能で管理されるデータベース・ファイル。
データベース・ファイルを現行以外の時刻まで不完全リカバリする。Point-in-Timeリカバリは、不完全リカバリまたは時間ベースのリカバリとも呼ばれる。
「完全リカバリ」、「不完全リカバリ」、「メディア・リカバリ」、「リカバリする」を参照。
Oracleデータベースの物理バックアップおよびリカバリのプライマリ・ユーティリティ。Recovery Managerは、OracleデータベースのレコードをRecovery Managerリポジトリと呼ばれる独自の構造で保持し、バックアップの記憶域を管理し、バックアップを検証する。これは、リカバリ・カタログと呼ばれる中央情報リポジトリとあわせて使用することも、またリカバリ・カタログなしで使用することもできる。リカバリ・カタログを使用しない場合、Recovery Managerはデータベースの制御ファイルを使用し、バックアップおよびリカバリ処理に必要な情報を格納する。Recovery Managerとサード・パーティのメディア・マネージャ・ソフトウェアをあわせて使用すると、テープなどの3次ストレージ・デバイスにファイルのバックアップを作成できる。
「バックアップ・ピース」、「バックアップ・セット」、「コピー」、「メディア・マネージャ」、「リカバリ・カタログ」を参照。
ターゲット・データベースでのバックアップ処理とリカバリ処理に関するRecovery Managerメタデータのレコード。Recovery Managerリポジトリの正式なコピーは、常にターゲット・データベースの制御ファイルに格納される。リカバリ・カタログを使用して、Recovery Managerリポジトリを長期間保存することもできる。また、リカバリ・カタログは、データベースの制御ファイルが消失した場合にRecovery Managerリポジトリ・データの代替ソースとして使用できる。
「リカバリ・カタログ」、「リカバリ・カタログ・データベース」、「再同期化」を参照。
インスタンスによって生成されるREDO。データベースがシングル・インスタンス構成で実行される場合、そのデータベースにはREDOスレッドが1つのみ存在する。
オンラインREDOログまたはアーカイブREDOログのいずれかを指す。オンラインREDOログは2つ以上のREDOログ・グループのセットで、Oracleデータ・ファイルと制御ファイルに対するすべての変更が記録される。アーカイブREDOログは、オフラインの宛先に書き込まれるオンラインREDOログのコピーである。
「アーカイブREDOログ」、「オンラインREDOログ」を参照。
（オンラインREDOログ・ファイルに対応する）各オンラインREDOログ・メンバーは1つのREDOログ・グループに属する。REDOログ・グループには、1つ以上のメンバーが含まれる。複数のメンバーが含まれているREDOログ・グループを、多重REDOログ・グループという。REDOログ・グループのすべてのメンバーの内容は同じである。
データベースをオープンする方法の1つ。この方法を使用すると、現行のオンラインREDOログがすべてアーカイブされ（ARCHIVELOGモードの場合）、ログ順序番号が1にリセットされ、オンラインREDOログが消去される。OPEN RESETLOGS操作を実行すると、新しいデータベース・インカネーションが開始される。新しいインカネーションの開始SCN（RESETLOGS SCNとも呼ばれる）は、OPEN RESETLOGSを実行する前のメディア・リカバリの不完全リカバリSCNに1を足したものである。
OPEN RESETLOGS操作は、不完全リカバリやバックアップ制御ファイルを使用したリカバリの後に実行する必要がある。
OPEN RESETLOGS操作を実行しても、データベースのリカバリ可能性に影響はない。OPEN RESETLOGS操作を実行する前のバックアップは有効のままになり、OPEN RESETLOGS操作の後に作成されたバックアップとともに使用して、データベースのすべての破損を修復できる。
「Recovery Manager」を参照。
System Backup to Tapeインタフェース。テープへのバックアップに使用されるRecovery Managerコマンドでバックアップ先を指定するために最も一般的に使用される。（"BACKUP DEVICE TYPE sbt DATABASE"など）
データベースのOracleデータ・ディクショナリ（データベースのすべての内容を記述するメタデータ）を含む表領域。他の表領域とは異なり、SYSTEM表領域でOracleが機能するには、表領域に含まれているすべてのデータ・ファイルがオンラインであることが必要である。メディア障害によってSYSTEM内のデータ・ファイルの1つが影響を受けた場合、データベースをマウントしてリカバリする必要がある。
データベースが自動UNDO管理モードで実行されているときに、ロールバック情報のみが格納される専用表領域。
一杯になったオンラインREDOログをオフライン・ログのアーカイブ先にコピーする操作。オンラインREDOログのオフライン・コピーは、アーカイブREDOログと呼ばれる。REDOログをアーカイブするには、データベースをARCHIVELOGモードで実行する必要がある。
一杯になったオンラインREDOログ・グループのメンバーのコピーで、データベースがARCHIVELOGモードのときに作成される。LGWRプロセスにより各オンラインREDOログがREDOレコードで一杯になると、アーカイバ・プロセスはこれらのログを1つ以上のREDOログのアーカイブ先にコピーする。このコピーが、アーカイブREDOログである。Recovery Managerでは、元のアーカイブREDOログとアーカイブREDOログのイメージ・コピーは区別されず、どちらもイメージ・コピーとみなされる。
一時表領域にあり、TEMPFILEオプションで作成されるファイル。一時表領域に表などの永続データベース・オブジェクトは格納できない。通常はソートに使用される。一時ファイルには永続オブジェクトが含まれないため、Recovery Managerによるバックアップは行われない。ただし、Recovery Managerは、一時ファイルの場所を制御ファイル内で追跡し、一時ファイルは、リカバリ時にそれらの場所に必要に応じて再作成される。
IMMEDIATE、TRANSACTIONALまたはNORMALオプションを指定して停止したデータベース。正しく停止されたデータベースは、すでに一貫性のある状態であるため、リカバリする必要はない。
メディア・リカバリを実行することなく、RESETLOGSオプションを指定してオープンできるデータベース全体のバックアップ。つまり、このバックアップにREDOを適用しなくても一貫性が保たれる。（ただし、一貫性バックアップの作成後に生成されたREDOを適用しないかぎり、その一貫性バックアップの作成以降のすべてのトランザクションが消失することに注意する。）
一貫性バックアップは、データベースの一貫性のある停止を実行した後でのみ作成できる。バックアップが完了するまで、データベースを再度オープンしないように注意する必要がある。
「ファジー・ファイル」、「非一貫性バックアップ」を参照。
単一のデータ・ファイル、アーカイブREDOログ・ファイルまたは制御ファイルのビット単位のコピーで、次のようなものを指す。
BACKUP AS COPYコマンド、UNIXのcpなどのオペレーティング・システムのコマンド、またはOracleアーカイバ・プロセスによって生成されたもの。
データベースの別バージョン。RESETLOGSオプションを指定してデータベースをオープンすると、データベースのインカネーションが変更されるが、必要なREDOが使用できるかぎり、以前のインカネーションからバックアップをリカバリできる。
Oracleインスタンスが、ハードウェア障害、Oracle内部エラーまたはSHUTDOWN ABORT文によって終了すること。インスタンス障害が発生した場合は、クラッシュ・リカバリまたはインスタンス・リカバリを必ず実行する必要がある。
RAC構成で、インスタンスを使用してREDOデータをオープン状態のデータベースに適用する。このインスタンスが、別のインスタンスのクラッシュを検出したときに実行される。
「リカバリする」を参照。
いずれかのOracleエクスポート・ユーティリティ（Data Pump Exportなど）を使用して、データベースから（物理ファイルではなく）バイナリ・ファイルに論理データを抽出すること。データをデータベースにインポートするには、対応するOracleインポート・ユーティリティを使用する。
「論理バックアップ」を参照。
「ユーザー管理のバックアップ」を参照。
「ユーザー管理のバックアップとリカバリ」を参照。
オンラインREDOログとは、データベースへのすべての変更が記録される、2つ以上のファイルのセットである。データベースが変更されるたびに、OracleはREDOレコードをREDOバッファに生成する。REDOバッファの内容は、LGWRプロセスによってオンラインREDOログにフラッシュされる。
現行のオンラインREDOログとは、LGWRによって現在書込みが行われているオンラインREDOログを指す。LGWRはファイルの最後に到達すると、ログ・スイッチを実行し、新しいログ・ファイルへの書込みを開始する。データベースをARCHIVELOGモードで実行している場合、一杯になった各オンラインREDOログ・ファイルを1つ以上のアーカイブ先にコピーしないと、LGWRで上書きできない。
「アーカイブREDOログ」を参照。
OracleのオンラインREDOログは、複数のオンラインREDOログ・グループで構成されている。各グループには、1つ以上の同一のオンラインREDOログ・メンバーが含まれている。オンラインREDOログ・メンバーは、REDOレコードを含む物理ファイルである。
オンラインREDOログ・グループ内の物理的なオンラインREDOログ・ファイル。各ログ・グループには、1つ以上のメンバーが必要である。グループの各メンバーの内容は同じである。
データベースがオープンしており、かつデータ・ファイルがオンラインのときに作成される、1つ以上のデータ・ファイルのバックアップ。データベースをオープンした状態でユーザー管理のバックアップを作成する場合は、ALTER TABLESPACE BEGIN BACKUPコマンドを発行して、表領域をバックアップ・モードにする必要がある。（ALTER DATABASE BEGIN BACKUPを使用して、1つの手順でデータベースのすべての表領域をバックアップ・モードにすることもできる。）
Recovery Managerを使用してバックアップを実行する際は、表領域をバックアップ・モードにしてはいけないことに注意する。
Recovery Managerの処理の1つ。データベースの制御ファイル内にある変更されたメタデータを使用して、リカバリ・カタログを更新する。Recovery ManagerコマンドのRESYNC CATALOGを発行すると、完全なカタログ再同期化を開始できる。（Recovery Managerは再同期化を必要に応じて自動的に実行するため、RESYNC CATALOGを使用する必要はほとんどない。）
リストアしたバックアップ以降に生成されたすべてのREDOを適用して1つ以上のデータ・ファイルをリカバリする。通常、完全リカバリは、1つ以上のデータ・ファイルまたは制御ファイルがメディア障害によって破損した場合に実行される。破損したファイルを完全にリカバリするには、リストアしたバックアップ以降に生成されたREDOをすべて使用する。
シングル・インスタンス・データベースのクラッシュ、あるいはOracle Real Applications Clusters構成の全インスタンスのクラッシュのどちらかが発生した場合に、オンラインREDOレコードをデータベースに自動的に適用すること。クラッシュ・リカバリに必須なのはオンライン・ログのREDOのみ。アーカイブREDOログは必須ではない。
「リカバリする」を参照。
データベースがクローズしている間に作成される、1つ以上のデータベース・ファイルのバックアップ。通常、クローズ状態のバックアップは、全体データベース・バックアップである。データベースが正常にクローズされた場合、バックアップに含まれているファイルはすべて一貫性が保たれた状態になっている。データベースが正常にクローズされなかった場合、バックアップの一貫性は保たれない。
ディスクまたはメディア管理カタログのファイルが、リポジトリおよび制御ファイルのデータに対応しているかどうかをチェックする。テープにはメディア・マネージャによって期限切れまたは使用不可のマークが付けられることがあり、ファイルはディスクから削除されたり破損することがあるため、Recovery Managerリポジトリにはバックアップに関する古い情報が含まれる場合がある。クロスチェックを実行するには、CROSSCHECKコマンドを実行する。 ファイルをリストアできるかどうかを判断するには、VALIDATE BACKUPSETまたはRESTORE ... VALIDATEを実行する。
「妥当性チェック」を参照。
現時点において、LGWRバックグラウンド・プロセスでREDOレコードが記録されているオンラインREDOログ・ファイル。
「REDOログ」、「REDOログ・グループ」を参照。
「クローズ状態のバックアップ」を参照。
Oracleファイル（Oracleデータ・ファイル、制御ファイルおよびアーカイブREDOログ）をビット単位で正確にディスクにバックアップすること。次の2つの方法でコピーできる。
「バックアップ」を参照。
データベースのインカネーションのバックアップであるが、そのインカネーションが現行のインカネーションの直接の祖先ではないか、または祖先のインカネーションが現行のインカネーションに向かって分岐したSCNの後に作成されたバックアップ。このようなバックアップは、現行のインカネーションで使用できない。
ターゲット・データベースの制御ファイルの現行情報を使用して、リカバリ・カタログを更新する処理。RESYNC CATALOGコマンドを発行すると、カタログの完全再同期化を開始できる。部分再同期化では、アーカイブREDOログ、バックアップ・セットおよびデータ・ファイルのコピーに関する情報をリカバリ・カタログに転送する。Recovery Managerは、必要に応じて再同期化を自動的に実行する。
レベル1またはレベル0の最新のバックアップ以降に変更されたすべてのブロックをバックアップするタイプの増分バックアップ。たとえば、レベル1の差分バックアップでは、Recovery Managerは、レベル1またはレベル0の最新のバックアップを判断し、そのバックアップ後に変更されたすべてのブロックをバックアップする。差分バックアップは増分バックアップのデフォルトのタイプとなっている。差分増分バックアップを使用してリカバリするときは、Recovery Managerでは、リストアされたデータ・ファイルがバックアップされた後のすべてのレベル1の差分増分バックアップを適用する必要がある。
「累積増分バックアップ」、「増分バックアップ」を参照。
コミットされたバージョンのデータベースを、ある時点で定義するスタンプ。Oracleは、コミットされたすべてのトランザクションに一意のSCNを割り当てる。
UNDOデータが専用のUNDO表領域に格納されるデータベース・モード。UNDO管理に関して実行する必要があるのは、UNDO表領域の作成のみである。その他のUNDO管理はすべて自動的に実行される。
ALLOCATE CHANNNELコマンドを使用せずにバックアップおよびリストア作業を実行するRecovery Managerの機能。CONFIGUREコマンドを使用すると、ディスクとテープのチャネルを指定できる。その後は、チャネルを手動で割り当てることなく、Recovery Managerコマンド・プロンプトでBACKUPやRESTOREなどのコマンドを発行できる。Recovery Managerは、コマンドの実行に必要な構成済のチャネルをすべて使用する。
情報が含まれている制御ファイル・レコード。バックアップとリカバリ操作時にRecovery Managerが使用する。これらのレコードは、論理的なリングに配置されている。使用可能なレコード・スロットが一杯の場合、制御ファイルを拡大して新規レコード用の領域を確保するか、あるいは最も古いレコードを上書きする。CONTROL_FILE_RECORD_KEEP_TIME初期化パラメータは、レコードが上書き可能になるまで保持される日数を制御する。CONTROL_FILE_RECORD_KEEP_TIMEのデフォルトは7日間。
「非循環再利用レコード」を参照。
Oracleデータベース・ファイルの障害や消失からのリカバリを可能にするバックアップのセット。
本番データベースのコピー。障害時の保護に使用できる。
リカバリ・カタログに格納された一連のRecovery Managerコマンド。
Recovery Managerがオペレーティング・システムの特定の位置に作成したデータベースの制御ファイルのコピー。Recovery Managerは、リカバリ・カタログの再同期化または制御ファイルのバックアップを実行する場合、スナップショット制御ファイルを作成して制御ファイルの一貫性のあるバージョンを取得する。
現行の制御ファイルの自動バックアップは、Recovery Managerが次の状況で実行する。
制御ファイルの自動バックアップではデフォルトのファイル名が使用されるため、制御ファイルやリカバリ・カタログが消失した場合でも、Recovery Managerはそのファイル名を使用して制御ファイルをリストアできる。デフォルトのファイル名は必要に応じて変更できる。
Recovery Managerによる非増分バックアップ。この場合の「全体」とは、データベースのバックアップの割合を示しているのではなく、バックアップが増分バックアップではないことを示している。したがって、1つのデータ・ファイルの全体バックアップを作成することは可能である。
修正されたブロックのみのバックアップが作成されるRecovery Managerバックアップ。増分バックアップはレベルによって分類される。レベル0の増分バックアップと全体バックアップは、使用済のブロックすべてのバックアップを作成するという点で、同じ機能である。ただし、全体バックアップでは、それ以降に実行される増分バックアップで、バックアップされるブロックに影響はないが、増分バックアップでは、それ以降に実行される増分バックアップでバックアップされるブロックに影響が及ぶという相違がある。
レベル1の増分バックアップの場合、前回の増分バックアップ以降に変更されたブロックのみのバックアップが作成される。前回の増分バックアップ以降変更されていないブロックのバックアップは作成されない。増分バックアップは、差分増分バックアップまたは累積増分バックアップのいずれかである。累積増分バックアップでは、レベル1の最新のバックアップが行われた後、変更されたすべてのブロックをバックアップする。差分増分バックアップでは、レベル1または0の最新の増分バックアップが行われた後、変更されたすべてのブロックをバックアップする。
Recovery Managerでバックアップまたはリストアするデータベース。
同じ内容の複数のオンラインREDOログのコピーを、自動的にメンテナンスすること。
同じ内容の複数のデータベース制御ファイルのコピーを、自動的にメンテナンスすること。
データベース・ファイルをディスクから同時に読み取り、そのブロックを同一のバックアップ・ピースに書き込むRecovery Managerの機能。
Oracleアーカイバ・プロセスは、REDOログのコピーを複数アーカイブできる。
「ミラー化」を参照。
バックアップがリストア可能かどうかをチェックするテスト。Recovery Managerはバックアップをスキャンし、チェックサムを参照してこれらの内容が正しくリストアできるかどうかを検証する。
「クロスチェック」、「メディア・マネージャ」、「リカバリ・カタログ」を参照。
データベースのREDOスレッドにSCNを定義するデータ構造。チェックポイントは制御ファイルと各データ・ファイル・ヘッダーに記録されており、リカバリの重要な要素である。
Recovery Managerとターゲット・データベースとの間の接続。割り当てられた各チャネルは、新しいOracleサーバー・セッションを開始する。このセッションは、バックアップ、リストアおよびリカバリ操作を実行する。チャネルは、DISKチャネル（ディスクI/Oの実行に使用される）またはsbtチャネル（サード・パーティのメディア・マネージャを介したI/Oの実行に使用される）のいずれかになる。
「メディア・マネージャ」、「ターゲット・データベース」を参照。
バックアップの保存方針からは逸脱するが、リカバリ・カタログには記録するバックアップ。通常、長期バックアップは、レポート生成に将来使用する可能性があるデータベースのスナップショットである。
より現在時刻に近い時点にロールフォワードするために、リストアされたデータ・ファイルにREDOレコードを適用する。ブロック・メディア・リカバリを実行している場合を除いて、リカバリ中はデータ・ファイルをオフラインにする必要がある。
「DBID」を参照。
制御ファイルおよびデータベースに属するすべてのデータ・ファイルのバックアップを作成する。
「バックアップ」を参照。
最も低いSCNのスレッド・チェックポイント。データベース・チェックポイントより前のすべての有効なスレッドにおけるすべての変更がディスクに書き込まれていることが保証される。
「チェックポイント」を参照。
データベース全体を、指定した過去の目標時点、SCNまたはログ順序番号の状態にリカバリする。
「不完全リカバリ」、「表領域のPoint-in-Timeリカバリ」を参照。
1つ以上のディスク・ドライブを制御するハードウェア・コンポーネント。
ユーザーが指定するフラッシュ・リカバリ領域のサイズの制限。ディスク割当て制限に達すると、不要になったファイルが自動的に削除される。
Recovery Managerで、REGISTER DATABASEコマンドを実行し、ターゲット・データベースの存在をリカバリ・カタログに記録する。ターゲット・データベースは、そのDBIDによってカタログ内で一意に識別される。同じカタログに複数のデータベースを登録することも、複数のカタログに同じデータベースを登録することもできる。
「DBID」を参照。
表領域のセットを、あるデータベースから別のデータベースに、または再度そのデータベースにトランスポートする機能。表領域をデータベースにトランスポートすることと、あらかじめロードされたデータを使用して表領域を作成することは類似している。
圧縮技術で、Recovery Managerがバックアップ・セットにバックアップされるデータに適用している圧縮アルゴリズム。
ORAPWDコマンドで作成され、ネットワークを介してSYSDBAまたはSYSOPERロールを使用して接続する場合に必要なファイル。パスワード・ファイルの詳細は、『Oracle Database管理者ガイド』を参照。
Oracle形式で認識されない、または内容に一貫性がないOracleブロック。通常、破損の原因はハードウェアの故障またはオペレーティング・システムの問題である。破損ブロックは、論理的破損（Oracle内部エラー）またはメディア破損（形式が正しくないブロック）のいずれかとして識別される。
メディア破損ブロックは、ブロックをリカバリするか、または破損ブロックを含むデータベース・オブジェクトを削除して他のオブジェクトで再利用できるようにすることで修復できる。メディア破損の原因がハードウェア故障の場合、前述のどちらの解決策も、そのハードウェアの故障を直さなければ効果がない。
「ブロック・メディア・リカバリ」を参照。
（1）データベース、表領域、表、データ・ファイル、制御ファイル、アーカイブREDOログなどのデータのバックアップ・コピー。バックアップは物理バックアップ（データベース・ファイル・レベル）または論理バックアップ（データベース・オブジェクト・レベル）として作成できる。物理バックアップは、Recovery Managerを使用して、1つ以上のデータ・ファイル、制御ファイルまたはアーカイブ・ログをバックアップすることによって作成できる。論理バックアップは、Oracleエクスポート・ユーティリティ（Data Pump Exportまたは従来のエクスポート）の1つを使用して作成できる。
（2）バックアップ・セット、プロキシ・コピーまたはディスク・ベースのイメージ・コピーを作成するRecovery Managerコマンド。
「コピー」、「バックアップ・セット」、「多重化」、「RMAN」を参照。
「データベース全体のバックアップ」を参照。
データベースをメディア障害やユーザー・エラーによるデータ消失から保護する作業に関係する概念、手順および方針。
制御ファイルのバックアップ。制御ファイルは、Recovery ManagerのbackupコマンドやSQLのALTER DATABASE BACKUP CONTROLFILE TO 'filename'文を使用してバックアップできる。
1つ以上のデータ・ファイル、制御ファイル、SPFILEおよびアーカイブREDOログ・ファイルのバックアップ。各バックアップ・セットは、バックアップ・ピースと呼ばれる1つ以上のバイナリ・ファイルで構成される。バックアップ・ピースは専用の形式で記述され、Recovery Managerによってのみ作成およびリストアされる。
バックアップ・セットは、Recovery ManagerのBACKUPコマンドで生成される。通常、バックアップ・セットは、1つのバックアップ・ピースのみで構成される。Recovery Managerでバックアップ・セットの内容が複数のバックアップ・ピースに分割されるのは、ALLOCATE CHANNELコマンドまたはCONFIGURE CHANNELコマンドのMAXPIECESIZEオプションを使用してバックアップ・ピース・サイズを制限している場合のみである。
「バックアップ・ピース」、「未使用ブロックの圧縮」、「多重化」、「RMAN」を参照。
Recovery Managerのバックアップ・セットの格納に使用される物理ファイルの形式。
「バックアップ」、「バックアップ・セット」、「RMAN」を参照。
「保存方針」を参照。
オンライン・バックアップを作成する前に、ALTER TABLESPACE ... BEGIN BACKUPコマンド、またはALTER DATABASE BEGIN BACKUPコマンドを発行するときに開始するデータベース・モード（ホット・バックアップ・モードとも呼ばれる）。 表領域のバックアップ・モードを解除するには、ALTER TABLESPACE ... END BACKUPまたはALTER DATABASE END BACKUPコマンドを発行する。
オンライン表領域のデータ・ファイルのユーザー管理バックアップを作成する場合は、このコマンドを使用する必要がある。Recovery Managerを使用している場合は、データベースをバックアップ・モードにする必要はない。バックアップ・モードでは、データベースを更新すると通常より多くのREDOが作成される。Oracleでは、バッファ・キャッシュ内のブロックが使用済になるたびに、データに対する変更の記録に加えて、変更されたブロックのイメージをREDOログに書き込む必要がある。
「破損ブロック」、「オンライン・バックアップ」を参照。
複数のチャネルを、Recovery Managerのバックアップ処理およびリカバリ処理に割り当てる。
リカバリ方式の1つで、複数のプロセスがREDOログ・ファイルからの変更を同時に適用する。RECOVERY_PARALLELISM初期化パラメータまたは、SQL*PlusのRECOVERコマンドにオプションを指定すると、インスタンスおよびメディア・リカバリのパラレル化を自動的に実行できる。
バックアップの一部のファイルに、それらのファイルのチェックポイント以降の変更が含まれるバックアップ。このタイプのバックアップに一貫性を持たせるには、リカバリ処理が必要である。非一貫性バックアップは、通常、オンライン・データベースのバックアップ時に作成される。非一貫性バックアップは、データベースがクローズ状態であっても、次のような場合に作成される。
非一貫性バックアップが有効なのは、データベースがARCHIVELOGモードであり、バックアップ以降に作成されたすべてのアーカイブREDOログが使用可能である場合のみである。
「一貫性バックアップ」、「オンライン・バックアップ」、「システム変更番号」、「データベース全体のバックアップ」を参照。
Oracleデータベースに必要な、重要な情報が含まれる制御ファイル・レコード。これらのレコードは、自動的に上書きされない。非循環再利用レコードに含まれる情報には、データ・ファイルやオンラインREDOログの場所などがある。
「循環再利用レコード」を参照。
1つ以上の非SYSTEM表領域を現行以外の時刻までリカバリする。Recovery Managerまたはユーザー管理の方式を使用して、TSPITRを実行できる。
チェックポイントSCNと同じか、より新しいSCNが割り当てられたブロックを、ブロック・ヘッダーに少なくとも1つ含んでいるデータ・ファイル。たとえば、バックアップ・モードのデータ・ファイルがOracleによって更新されると、このような状況が発生する。リストアされたファジー・ファイルは、必ずリカバリを実行する必要がある。
「完全リカバリ」、「メディア・リカバリ」、「リカバリする」を参照。
Recovery Managerのduplicateコマンドを使用して、ターゲット・データベースのバックアップから作成したデータベース。
「補助データベース」を参照。
ある時点でのデータベース内のデータ・ファイル、制御ファイルおよびREDOログ。表領域とデータ・ファイルのリストを取得するには、Recovery ManagerのREPORT SCHEMAコマンドを発行する。
再同期化のタイプ。この同期化では、Recovery Managerはアーカイブ・ログ、バックアップ・セットおよびデータ・ファイルのコピーに関するデータを、ターゲット制御ファイルからリカバリ・カタログに転送する。
データベースのフラッシュバック操作の実行に使用される、Oracleによって生成されるログ。フラッシュバック・ログは、フラッシュ・リカバリ領域にのみ書き込むことができる。フラッシュバック・ログは、ディスクにバックアップすることはできない。
リカバリに関連するファイル（制御ファイル、オンラインREDOログのコピー、アーカイブ・ログ、フラッシュバック・ログ、Recovery Managerバックアップなど）の格納に使用できる任意のディスクの位置。フラッシュ・リカバリ領域にあるファイルは、OracleやRecovery Managerによって自動的に管理される。フラッシュ・リカバリ領域の最大サイズは、ディスク割当て制限で指定できる。
Recovery Managerのバックアップ処理とリストア処理時に、メディア・マネージャがメディア・ストレージ・デバイスとディスク間のデータ転送を管理するバックアップ。
データベースの各更新に影響を受けたデータ・ファイル・ブロックをOracleに追跡させるデータベース・オプション。追跡情報は、チェンジ・トラッキング・ファイルと呼ばれる新しい形式のファイルで格納される。ブロック・チェンジ・トラッキングが有効になっている場合、Recovery Managerは、チェンジ・トラッキング・ファイル内の変更されたブロックの記録を使用して、データ・ファイル全体を読み取るのではなく、変更されたことがわかっているブロックのみを読み取ることによって、増分バックアップのパフォーマンスを向上させる。
Recovery ManagerのBLOCKRECOVERコマンドを使用してデータ・ファイル内の指定ブロックをリカバリする。ブロック・メディア・リカバリでは、対象となるデータ・ファイルはオンラインのままで、破損ブロックのみがリストアおよびリカバリされる。
データベースに関するクラッシュ・リカバリやメディア・リカバリの実行に必要とされる時間。メディア・リカバリのMTTRには、検出速度、メディア・リカバリの実行に使用する方法、データベース・サイズなどの様々な要因が影響を与える。
TSPITRにおいて、リカバリ・セットにはないファイルの集合。ただし、TSPITR操作を正しく実行するには、これらのファイルを補助データベースでリストアする必要がある。
（1）Recovery ManagerのDUPLICATEコマンドを使用して、ターゲット・データベースのバックアップから作成したデータベース。
（2）新しい場所にリストアされ、表領域のPoint-in-Timeリカバリ（TSPITR）時に新しいインスタンス名で起動される一時データベース。TSPITR補助データベースは、リカバリ・セットと補助セットで構成される。
「リカバリ・セット」、「補助セット」、「表領域のPoint-in-Timeリカバリ」を参照。
メディア・リカバリ用のバックアップとアーカイブ・ログの保存期間を決定するユーザー定義の方針。保存方針は、バックアップ冗長性またはリカバリ期間で定義できる。Recovery Managerは、現行の保存方針を満たすために必要なデータ・ファイル・バックアップ、およびそれらのデータ・ファイル・バックアップの完全リカバリに必要なすべてのアーカイブREDOログを保持する。
「オンライン・バックアップ」を参照。
「バックアップ・モード」を参照。
Recovery Managerがデータ・ファイルのバックアップを含むバックアップ・セットのサイズを縮小する方法。使用されていないデータ・ファイルのブロックをスキップすることで行われる。ブロックをスキップできる場合の詳細は、『Oracle Databaseバックアップおよびリカバリ・リファレンス』を参照。
データと同じ内容のコピーを1つ以上のディスクでメンテナンスすること。ミラー化は通常、二重化されたハードディスクにおいてオペレーティング・システム・レベルで実行する。したがって、いずれかのディスクが使用不可能になっても、中断することなくもう一方のディスクで要求の処理を継続できる。ファイルをミラー化すると、Oracleが1回書き込む間にオペレーティング・システムは複数のディスクに書込みを行う。ファイルを多重化すると、Oracleは複数のファイルに同じデータを書き込む。
Oracleで使用される任意のファイル（データ・ファイル、ログ・ファイル、制御ファイルなど）を含むディスクの破損。Oracleがメディア障害を検出すると、影響を受けたファイルがオフラインになる。
「メディア・リカバリ」を参照。
Recovery Managerと統合可能なサード・パーティのネットワーク対応バックアップ・システム。これによって、データベース・バックアップを3次ストレージに直接書き込むことができるようになる。
リストアされたバックアップ・データ・ファイルまたは個々のデータ・ブロックにREDOまたは増分バックアップを適用すること。
メディア・リカバリでは、データベース、表領域、データ・ファイルまたはデータ・ファイル内のブロックのセットをリカバリできる。メディア・リカバリは、完全リカバリ（REDOログ内のすべての変更が適用される）または不完全リカバリ（指定した時点までの変更のみが適用される）のいずれかで実行できる。メディア・リカバリは、データベースがARCHIVELOGモードの場合にのみ実行できる。
「ブロック・メディア・リカバリ」、「リカバリする」を参照。
Recovery Manager以外の方法（オペレーティング・システムのユーティリティなど）を使用して実行されるバックアップ。たとえば、UNIXのcpコマンドやWindowsのcopyコマンドを実行して、ユーザー管理のバックアップを作成できる。ユーザー管理のバックアップは、オペレーティング・システムのバックアップとも呼ばれる。
Recovery Managerを使用しないOracleデータベースのバックアップおよびリカバリ計画。オペレーティング・システムのバックアップおよびリカバリとも呼ばれる。オペレーティング・システムのユーティリティ（UNIXのcpコマンドなど）を使用してデータベース・ファイルをバックアップおよびリストアし、SQL*PlusのRECOVERコマンドを使用してリカバリできる。
データベース・ファイルまたはデータベースに関して使用される場合は、REDOデータまたは増分バックアップをデータベース・ファイルに適用して、消失した変更を再構築すること。リカバリには、インスタンス・リカバリ、クラッシュ・リカバリおよびメディア・リカバリの3つのタイプがある。Oracleでは、オンラインREDOレコードを使用して、最初の2つのタイプのリカバリを自動的に実行する。メディア・リカバリを実行する場合のみ、バックアップをリストアしてコマンドを発行する必要がある。
Recovery Managerが1つ以上のOracleデータベースのRecovery Managerリポジトリ情報を格納する、Oracleの表とビューのセット。Recovery Managerはこのデータを使用して、Oracleデータベースのバックアップ、リストアおよびリカバリを管理する。
リカバリ・カタログの使用はオプションである。データベースのRecovery Managerリポジトリ情報の主な格納場所は、常にターゲット・データベースの制御ファイルである。リカバリ・カタログは、制御ファイル内のRecovery Managerリポジトリ・データで定期的に更新される。制御ファイルが消失した場合、消失した情報のうち、データベースのリストアおよびリカバリに必要な情報のほとんどまたはすべてはリカバリ・カタログから取得できる。リカバリ・カタログには、長期バックアップおよびターゲット・データベースで使用するRecovery Managerストアド・スクリプトのレコードも記録できる。
「リカバリ・カタログ・データベース」を参照。
リカバリ・カタログのスキーマが設定されているOracleデータベース。リカバリ・カタログをターゲット・データベースに格納しないよう注意する。
Recovery Managerバックアップ保存方針のタイプの1つ。DBAが期間を指定し、Recovery Managerが、リカバリ期間内の任意の時点までのPoint-in-Timeリカバリに必要なバックアップおよびアーカイブREDOログが保存されることを保証する。この期間は常に、現在の時刻で終了し、ユーザーが指定した日数さかのぼる。
たとえば、保存方針が7日間のリカバリ期間で設定されている場合、現在の時刻が火曜日の午前11時であれば、Recovery Managerは前の週の火曜日の午前11時までのPoint-in-Timeリカバリに必要なバックアップを保持する。
「保存方針」を参照。
データベース・ファイルまたはデータベースのリカバリとは、通常、メディア・リカバリ、クラッシュ・リカバリまたはインスタンス・リカバリを実行することを指す。「データのリカバリ」のように、一般的に、失われたデータを再構築または再作成することを示す場合にも使用される。
「完全リカバリ」、「不完全リカバリ」、「インスタンス・リカバリ」、「クラッシュ・リカバリ」、「メディア・リカバリ」を参照。
表領域のPoint-in-Timeリカバリの実行時、以前の時点までのリカバリが行われる1つ以上の表領域。TSPITRを実行すると、リカバリ・セットのデータベース・オブジェクトがすべて同じ時点の状態にリカバリされる。
「補助セット」を参照。
消失したファイルまたは破損したファイルを、バックアップと置き換えること。ファイルをリストアするには、たとえば、UNIXのcpコマンドまたはRecovery ManagerのRESTOREコマンドを使用する。
レベル0の最新のバックアップ以降に変更されたすべてのブロックをバックアップする増分バックアップ。累積増分バックアップを使用してリカバリするときは、最新の累積増分バックアップを1つのみ適用する必要がある。
「差分増分バックアップ」、「増分バックアップ」を参照。
リカバリするのロールフォワード段階でデータベースに適用される、コミットされていない変更を、ロールバック・セグメントを使用して取り消すこと。
データベースの変更前のイメージを記録するデータベース・セグメント。
REDOレコードまたは増分バックアップをデータ・ファイルおよび制御ファイルに適用して、これらのファイルに加えた変更をリカバリすること。
REDOログ・ファイルのREDOレコードのセットを一意的に識別するための番号。あるオンラインREDOログ・ファイルが一杯になって別のオンラインREDOログ・ファイルに切り替わると、Oracleは新しいファイルにログ順序番号を自動的に割り当てる。
LGWRがアクティブなREDOログ・ファイルへの書込みを停止し、使用可能な次のREDOログ・ファイルに切り替える時点。アクティブなログ・ファイルがREDOレコードで一杯になった場合、あるいは手動で切替えを強制的に実行した場合に、LGWRによって切り替えられる。
「REDOログ」を参照。
表などの、データベース・スキーマ・オブジェクトのバックアップ。論理バックアップは、Oracle Data Pump Export UtilityまたはOracleエクスポート・ユーティリティを使用して作成およびリストアされる。バックアップの作成に使用されたユーティリティに対応するOracleインポート・ユーティリティを使用して、論理バックアップからオブジェクトをリストアできる。
|
 Copyright © 2006 Oracle Corporation. All Rights Reserved. |
|