11g リリース1（11.1）
E05700-03
 目次 |
 索引 |
| Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド 11g リリース1（11.1） E05700-03 |
|
一杯になったオンラインREDOログをOracle Databaseでディスクにコピーするためのデータベースのモード。このモードは、データベースの作成時に指定するか、またはALTER DATABASE ARCHIVELOG文を使用して指定する。
「アーカイブREDOログ」、「NOARCHIVELOGモード」を参照。
データベースを区別するために内部で一意に生成される番号。Oracleでは、データベースの作成時にこの番号が自動的に作成される。
SQL文を使用してログ・ファイルの読取り、分析および解析ができるようにするためのユーティリティ。
「アーカイブREDOログ」を参照。
「平均リカバリ時間」を参照。
一杯になったオンラインREDOログを上書きする前に、OracleによってそれらのオンラインREDOログのアーカイブを要求されないデータベースのモード。このモードは、データベースの作成時に指定するか、ALTER DATABASE NOARCHIVELOGコマンドを使用して指定する。
NOARCHIVELOGモードで実行すると、消失または破損したデータのリカバリの可能性が著しく制限されることに注意すること。
「アーカイブREDOログ」、「ARCHIVELOGモード」を参照。
表領域は、ALTER TABLESPACE ... OFFLINE NORMAL文でオフラインにされた場合、NORMALモードでオフラインされる。この表領域内のデータファイルにはチェックポイントが設定されるため、オンラインに戻されるまでリカバリは不要となる。表領域がNORMALモードでオフラインされていない場合、その表領域内のデータファイルは、オンラインに戻す前にリカバリする必要がある。
Recovery ManagerまたはSQLのFLASHBACK DATABASEコマンドを使用して、データベース全体を以前の一貫性のあるSCNまで戻すこと。データベース・フラッシュバックは、物理ファイルをリストアせずに、変更されたデータ・ブロックの保存イメージを使用して、現行のデータファイルの過去の状態にリストアするため、従来のメディア・リカバリとは異なる。この機能では、フラッシュバック・ログおよびアーカイブREDOログが使用される。
いくつかの初期化パラメータに基づいて、制御ファイル、REDOログ・ファイル、データファイルなどのデータベース・ファイルの名前の指定、場所の設定、作成、削除を自動化するサービス。Oracle管理ファイルは、VxFSやODMなどのホスト・オペレーティング・システムでサポートされている従来のファイル・システムに加えて使用できる。データベース管理の多くの側面について独自の方針を作成する必要をなくすことによって、それらの詳細を簡略化できる。
ファイル・システムをテープにバックアップすることによって、信頼性の高いデータ保護を提供するOracleメディア・マネージャ。Oracle Secure BackupのSBTインタフェースを使用すると、Recovery Managerを使用してOracle Databaseをバックアップすることもできる。SAN、ギガビット・イーサネットおよびSCSI環境のすべての主要なテープ・ドライブおよびライブラリがサポートされている。
Oracle Databaseインスタンスとその他のVolume Shadow Copy Service（VSS）のコンポーネントの間のコーディネータとして機能するWindowsシステム上のサービス。このサービスによって、データ・プロバイダは、Oracleインスタンスで管理されるファイルのシャドウ・コピーを作成できる。たとえば、Oracle VSSライターでは、データファイルをホット・バックアップ・モードにして、それらのデータファイルのリカバリ可能なコピーをシャドウ・コピー・セットに作成できる。
Oracle Managed Files機能によって管理されるデータベース・ファイル。
Oracle Enterprise Managerでウィザードを使用して実行できるバックアップ計画。この計画では、定期的にレベル1増分バックアップをレベル0バックアップに適用して、増分更新バックアップを作成する。この計画を毎日実行することによって、ディスクからのPoint-in-Timeリカバリが24時間実行できるようになる。
データ保護の層を追加するための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などがある。
フラッシュバック機能を使用して、データの過去の状態を表示したり、データベースの一部またはすべてを巻き戻すことができる。通常、フラッシュバック機能が適用されるほとんどの場合は、フラッシュバック機能の方がメディア・リカバリより効率的で簡単である。
データベース・ファイルを現在以外の時刻に不完全にリカバリすること。Point-in-Timeリカバリは、不完全リカバリとも呼ばれる。
ファイル・システムを持たないディスクまたはパーティション。このため、ls、Windowsエクスプローラなどでこれらの内容を確認することはできない。RAWパーティションは、Oracle Databaseでは単一ファイルとして表示される。
「Recovery Manager（RMAN）」を参照。
Oracle Databaseの物理バックアップおよびリカバリに使用されるプライマリ・ユーティリティ。Recovery Managerは、Recovery Managerリポジトリと呼ばれる独自の構造にOracle Databaseのレコードを保持し、バックアップのストレージを管理し、バックアップを検証する。これは、リカバリ・カタログと呼ばれる中央情報リポジトリとあわせて使用することも、またリカバリ・カタログなしで使用することもできる。リカバリ・カタログを使用しない場合、Recovery Managerは、バックアップおよびリカバリの操作に必要な情報を格納するために、データベースの制御ファイルを使用する。Recovery Managerをサード・パーティのメディア管理ソフトウェアとともに使用すると、ファイルを3次ストレージにバックアップできる。
「バックアップ・ピース」、「バックアップ・セット」、「コピー」、「メディア・マネージャ」、「リカバリ・カタログ」を参照。
コマンドを解釈し、それらのコマンドを実行するようにサーバー・セッションに指示し、そのアクティビティをターゲット・データベースの制御ファイルに記録するOracle Database実行可能ファイル。このRecovery Manager実行可能ファイルは、データベースとともに自動的にインストールされ、通常、他のデータベース実行可能ファイルと同じディレクトリに配置される。たとえば、Linux上のRecovery Managerクライアントはrmanと名付けられ、$ORACLE_HOME/binに格納される。
Recovery Managerセッションで実行されるRecovery Managerコマンドのセット。たとえば、Recovery Managerクライアントを起動し、BACKUP DATABASE、BACKUP ARCHIVELOGおよびRECOVER COPYを実行してRecovery Managerクライアントを終了する。Recovery Managerジョブは、2回のバックアップ、およびデータファイルのコピーのロールフォワードで構成される。
Recovery Managerセッションは、Recovery Managerクライアントの起動時に開始され、クライアントの終了時またはRecovery Managerプロセスの完了時に終了する。単一のRecovery Managerセッションで複数のRecovery Managerコマンドを実行できる。
Recovery Managerのメタデータ・レコードおよびバックアップの管理に使用できるコマンド。メンテナンス・コマンドには、CATALOG、CHANGE、CROSSCHECKおよびDELETEがある。
単一のRecovery Managerセッション内で実行されるBACKUPコマンドのセット。たとえば、Recovery Managerクライアントを起動し、BACKUP DATABASE、BACKUP ARCHIVELOGおよびRECOVER COPYを実行してRecovery Managerクライアントを終了する。Recovery Managerバックアップ・ジョブは、データベースのバックアップおよびアーカイブREDOログのバックアップで構成される。
ターゲット・データベース上で行われたバックアップおよびリカバリ操作に関するRecovery Managerのメタデータのレコード。Recovery Managerリポジトリの正式なコピーは、常にターゲット・データベースの制御ファイルに格納される。リカバリ・カタログを使用して、Recovery Managerリポジトリを長期間保存することもできる。また、リカバリ・カタログは、データベースの制御ファイルが消失した場合にRecovery Managerリポジトリ・データの代替ソースとして使用できる。
「リカバリ・カタログ・データベース」、「再同期化」を参照。
インスタンスによって生成されるREDO。データベースがシングル・インスタンス構成で実行されている場合、そのデータベースにはREDOのスレッドが1つのみ存在する。
オンラインREDOログまたはアーカイブREDOログのいずれかを指す。オンラインREDOログは、Oracleデータファイルおよび制御ファイルに行われたすべての変更が記録される2つ以上のREDOログ・グループのセットである。アーカイブREDOログは、オフラインの転送先に書き込まれたオンラインREDOログのコピーである。
オンラインREDOログの各メンバー（それぞれがオンラインREDOログ・ファイルに対応する）は、1つのREDOログ・グループに属している。REDOログ・グループには、1つ以上のメンバーが含まれている。2つ以上のメンバーが含まれているREDOログ・グループは、多重REDOログ・グループと呼ばれる。REDOログ・グループのすべてのメンバーの内容は同一である。
データベースをオープンする方法の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操作後に行われたバックアップとともに、データベースの損傷の修復に使用できる。
順次実行される、一連のRecovery Managerコマンド。
System Backup to Tape（テープへのシステム・バックアップ）の略称。この用語は、ディスク以外のバックアップ・デバイス・タイプを表す。通常はテープ・ライブラリまたはテープ・ドライブである。Recovery Managerでは、ディスクおよびSBTのタイプのチャネルがサポートされている。
すでにコミットされたトランザクションを記述しているためRecovery Managerバックアップのリカバリに不要となったUNDOを除外すること。たとえば、ユーザーがUSERS表領域内のsalaries表を更新するとする。この変更はUSERS表領域に書き込まれ、データの変更前のイメージはUNDO表領域に書き込まれる。次回、Recovery ManagerでUNDO表領域をバックアップする際に、給与の変更のUNDOは含まれない場合がある。UNDOのバックアップの最適化は、Recovery Managerに組み込まれた動作であり、無効にすることはできない。
データベースが自動UNDO管理モードで実行されているときに、ロールバック情報のみが格納される専用表領域。
Oracle Databaseで、UNDO表領域内の古いUNDOデータを上書きするまでの最短保存期間。現行のUNDO保存期間より前の古い（コミットされた）UNDOデータは、期限切れと呼ばれる。現行のUNDO保存期間内の古いUNDOデータは、期限内と呼ばれる。
Windowsサーバー・プラットフォームのインフラストラクチャの一種。これによって、リクエスタ、ライターおよびプロバイダは、シャドウ・コピーと呼ばれる一貫性のあるスナップショットの作成に参加できる。VSSサービスでは、適切に定義されたCOMインタフェースが使用される。VSSとともにRecovery Managerを使用する方法については、Oracle Databaseのプラットフォーム・ガイドを参照。
一杯になったオンラインREDOログ・ファイルをオフライン・ログのアーカイブ先にコピーする操作。オンラインREDOログのオフライン・コピーは、アーカイブREDOログと呼ばれる。REDOログをアーカイブするには、データベースをARCHIVELOGモードで実行する必要がある。
オンラインREDOログ・グループの一杯になったいずれかのメンバーのコピー。データベースがARCHIVELOGモードの場合に作成される。LGWRプロセスによって各オンラインREDOログがREDOレコードで一杯になると、ログは1つ以上のREDOログのアーカイブ先にコピーされる。このコピーがアーカイブREDOログとなる。Recovery Managerは、元のアーカイブREDOログとアーカイブREDOログのイメージ・コピーを区別せず、両方をイメージ・コピーとみなす。
アーカイブREDOログを削除できる場合を制御する構成可能で永続的なRecovery Managerの方針の1つ。この方針は、CONFIGURE ARCHIVELOG DELETION POLICYコマンドを使用して構成できる。
一部のアーカイブ・ログの出力先でログが欠落している場合またはログに破損ブロックが存在する場合でも、バックアップを完了できるようにするRecovery Managerの機能。たとえば、Recovery Managerは、フラッシュ・リカバリ領域にバックアップしたログが破損していると判断すると、他のアーカイブ場所にあるログを検索し、正常であればそのログをかわりにバックアップする。
通常のバックアップおよびリカバリ計画から除外されたデータベース・バックアップ。通常、このバックアップは、別のストレージ・メディアにアーカイブされ、長期間保存される。
ターゲット・データベースのバックアップをリストアせずに、ネットワーク上に複製データベースを作成すること。この方法は、バックアップベースの複製の代替方法である。
一時表領域に属し、TEMPFILEオプションで作成されたファイル。一時表領域には、表などの永続的なデータベース・オブジェクトを含めることはできない。通常、一時表領域はソートの目的で使用される。一時ファイルには永続的オフジェクトが含まれていないため、Recovery Managerは一時ファイルをバックアップしない。ただし、Recovery Managerは、制御ファイル内の一時ファイルの場所を追跡し、リカバリ中、必要に応じてその場所に一時ファイルを再作成する。
文のIMMEDIATE、TRASACTIONALまたはNORMALのオプションを使用して、データベースを停止すること。正しく停止されたデータベースにリカバリは不要である。このデータベースはすでに一貫性のある状態になっているためである。
メディア・リカバリを実行することなく、RESETLOGSオプションを指定してオープンできるデータベース全体のバックアップ。つまり、一貫性を保つためにこのバックアップにREDOを適用する必要はない。ただし、一貫性バックアップを作成した時点以降に生成されたREDOを適用しないかぎり、一貫性バックアップを作成した時点以降のすべてのトランザクションが失われる。
一貫性バックアップは、データベースの一貫性のある状態での停止を実行した後でのみ作成できる。データベースは、バックアップが完了するまで再オープンしないようにする必要がある。
「ファジー・ファイル」、「非一貫性バックアップ」を参照。
単一のデータファイル、アーカイブREDOログ・ファイルまたは制御ファイルのビット単位のコピーで、次のようなものを指す。
BACKUP AS COPYコマンド、UNIXのcpなどのオペレーティング・システムのコマンド、またはOracleアーカイバ・プロセスによって生成される。
データベースの個別のバージョン。データベースのインカネーションは、RESETLOGSオプションでデータベースをオープンすると変更されるが、必要なREDOを使用できるかぎり、以前のインカネーションからバックアップをリカバリできる。
ハードウェアの障害、Oracle内部エラーまたはSHUTDOWN ABORT文が原因でOracleインスタンスが終了すること。インスタンス障害が発生した場合は、常にクラッシュ・リカバリまたはインスタンス・リカバリを実行する必要がある。
Oracle RAC構成で、別のインスタンスがクラッシュしたことを検出したインスタンスによって、オープン状態のデータベースにREDOデータが適用されること。
「リカバリする」を参照。
データ・ポンプ・エクスポートを使用して、論理データ（つまり、物理ファイルではないデータ）をデータベースからバイナリ・ファイルに抽出すること。その後、データ・ポンプ・インポートを使用してデータをデータベースにインポートできる。
「論理バックアップ」を参照。
データ・ポンプ・エクスポート・ユーティリティによって作成されるファイル。ダンプ・ファイル・セットは、表データ、データベース・オブジェクトのメタデータ、制御情報が含まれている1つ以上のディスク・ファイルで構成される。各ファイルは、独自のバイナリ形式で書き込まれる。
Recovery Managerによってリストアされる前にメディア・マネージャで取得する必要があるSBTバックアップ。RESTORE ... PREVIEWを使用すると、オフサイトのバックアップを表示できる。
「ユーザー管理バックアップ」を参照。
「ユーザー管理のバックアップとリカバリ」を参照。
OPEN RESETLOGS操作後にブランチされた現行のインカネーションの元となるデータベース・インカネーション。
オンラインREDOログは、データベースに行われたすべての変更が記録される2つ以上のファイルのセットである。データベースに変更が行われるたびに、OracleによってREDOバッファにREDOレコードが生成される。LGWRプロセスによって、REDOバッファの内容がオンラインREDOログに書き込まれる。
現行のオンラインREDOログとは、LGWRによって現在書込みが行われているオンラインREDOログを指す。LGWRはファイルの最後に到達すると、ログ・スイッチを実行し、新しいログ・ファイルへの書込みを開始する。データベースをARCHIVELOGモードで実行している場合は、一杯になった各オンラインREDOログ・ファイルをLGWRで上書きする前に、1つ以上のアーカイブ場所にコピーする必要がある。
「アーカイブREDOログ」を参照。
OracleのオンラインREDOログは、2つ以上のオンラインREDOログ・グループで構成されている。各グループには、1つ以上の同一のオンラインREDOログ・メンバーが含まれている。オンラインREDOログ・メンバーは、REDOレコードを含む物理ファイルである。
オンラインREDOログ・グループ内の物理的なオンラインREDOログ・ファイル。各ログ・グループには、1つ以上のメンバーが必要である。グループの各メンバーの内容は同じである。
データベースがオープンされ、データファイルがオンラインである場合に行われる1つ以上のデータファイルのバックアップ。データベースをオープンした状態でユーザー管理のバックアップを作成する場合は、ALTER TABLESPACE BEGIN BACKUPコマンドを発行して、表領域をバックアップ・モードにする必要がある。（ALTER DATABASE BEGIN BACKUPを使用して、データベース内のすべての表領域を1回の動作でバックアップ・モードにすることもできる。）
Recovery Managerを使用してバックアップを実行する際は、表領域をバックアップ・モードにしてはいけない。
LogMinerセッションのロジカル・スタンバイ・データベースで受信されるアーカイブREDOログ。通常のアーカイブ・ログとは異なり、外部のアーカイブ・ログは異なるDBIDを持つ。このため、ロジカル・スタンバイ・データベース上ではバックアップまたはリストアできない。
データベース・ユーザーがアクセス権限を付与されている、リカバリ・カタログ内のメタデータのサブセット。ベース・リカバリ・カタログの所有者は、他のデータベース・ユーザーに対してリカバリ・カタログへの制限付きアクセス権限の付与または取消しを行うことができる。制限付きユーザーは、それぞれ独自の仮想プライベート・カタログへの完全な読取り/書込み権限を持っている。
Recovery Managerの処理の1つ。データベースの制御ファイル内にある変更されたメタデータを使用して、リカバリ・カタログを更新する。Recovery ManagerコマンドのRESYNC CATALOGを発行すると、完全なカタログ再同期化を開始できる。（Recovery Managerでは必要に応じて再同期化が自動的に行われるため、RESYNC CATALOGを使用する必要はほとんどないことに注意。）
バックアップのリストア後に生成されたすべてのREDOに適用される1つ以上のデータファイルのリカバリ。通常、完全メディア・リカバリは、1つ以上のデータファイルまたは制御ファイルがメディア障害によって破損した場合に実行される。損傷されたファイルは、バックアップのリストア以降に生成されたすべてのREDOを使用して、完全にリカバリされる。
「不完全リカバリ」を参照。
Recovery Managerリポジトリ内のステータスが（バックアップが検出されなかったことを意味する）EXPIREDであるバックアップ。CROSSCHECKコマンドの実行時に、バックアップおよびコピーが存在していないか、またはバックアップおよびコピーにアクセスできない場合、Recovery Managerはそれらのファイルを期限切れとマークする。
Data Guard環境では、リカバリ・カタログから取得したメタデータを使用して、プライマリ・データベースまたはスタンバイ・データベースの制御ファイルを更新すること。たとえば、接続されているターゲット・データベースではないスタンバイ・データベースにRecovery Managerの永続設定を構成すると、次回Recovery Managerがターゲットとしてスタンバイ・データベースに接続する際に逆再同期化が実行される。このようにして、リカバリ・カタログではData Guard環境での制御ファイル内のメタデータが最新に保たれる。
シングル・インスタンス・データベースがクラッシュした後か、またはOracle Real Applications Clusters構成のすべてのインスタンスがクラッシュした後のいずれかで、オンラインREDOレコードがデータベースに自動的に適用されること。クラッシュ・リカバリでは、オンライン・ログのREDOのみが必要となる。アーカイブREDOログは必要ない。
「リカバリする」を参照。
データベースがクローズされている場合に行われる1つ以上のデータベース・ファイルのバックアップ。通常、クローズ状態のバックアップはデータベース全体のバックアップである。データベースを一貫性のある状態でクローズした場合は、バックアップ内のすべてのファイルの一貫性が保たれる。そうしなかった場合は、バックアップの一貫性が保たれない。
「一貫性のある状態での停止」、「一貫性バックアップ」を参照。
ディスクまたはメディア管理カタログのファイルが、Recovery Managerリポジトリのデータに対応しているどうかを確認するチェック。テープにはメディア・マネージャによって期限切れまたは使用不可のマークが付けられることがあり、ファイルはディスクから削除されたり破損することがあるため、Recovery Managerリポジトリにはバックアップに関する古い情報が含まれる場合がある。クロスチェックを行うには、CROSSCHECKコマンドを実行する。
「検証」を参照。
データベースでREDOが現在生成されているインカネーション。
現時点において、LGWRバックグラウンド・プロセスでREDOレコードが記録されているオンラインREDOログ・ファイル。
「REDOログ」、「REDOログ・グループ」を参照。
Recovery Managerのコンテキストでは、データベース・ファイルにブロックの破損がないかどうかをチェックするテスト、またはバックアップ・セットをチェックしてリストア可能かどうかを判断するテスト。Recovery Managerではブロックの物理的および論理的な破損をチェックできる。
「クローズ状態のバックアップ」を参照。
Oracleファイル（Oracleのデータファイル、制御ファイルおよびアーカイブREDOログ）のビットごとのイメージをディスクにバックアップすること。コピーには、次の2つの方法がある。
「バックアップ」を参照。
Recovery Managerのコンテキストでは、Recovery Managerの一連のコマンドが含まれているクライアント側のテキスト・ファイル。コマンド・ファイルは、@コマンドまたは@@コマンドを使用してRecovery Manager内から実行するか、@パラメータまたはCMDFILEパラメータを使用してオペレーティング・システム・プロンプトから実行できる。
削除されたオブジェクトに関する情報が含まれているデータ・ディクショナリ表。削除された表および関連するオブジェクト（索引、制約、ネストした表など）は、実際には削除されず、領域を占有している。フラッシュバック・ドロップ機能では、削除されたオブジェクトを取得するためにごみ箱が使用される。
テープ・ドライブで、圧縮なしでテープに書き込む場合の速度。この速度は、バックアップ・レートの上限を表す。
データベースの現行のインカネーションの直系祖先パス内で作成されなかったバックアップ。孤立したバックアップは、現行のインカネーションでは使用できない。
Recovery Managerで、指定した日付以降にバックアップされていないファイルのみをバックアップできるようにする機能。再開可能単位は最後に完了したバックアップ・セットまたはイメージ・コピーである。バックアップが失敗した場合にこの機能を使用すると、失敗したバックアップで処理されなかったデータベースの部分をバックアップできる。
ターゲット・データベースの制御ファイルの現行のメタデータを使用して、リカバリ・カタログを更新する操作。RESYNC CATALOGコマンドを発行すると、カタログの完全再同期化を開始できる。部分再同期化では、アーカイブREDOログ・ファイル、バックアップ・セットおよびデータファイルのコピーに関する情報をリカバリ・カタログに転送する。Recovery Managerは、必要に応じてリカバリ・カタログを自動的に再同期化する。
レベル1またはレベル0の最新のバックアップ以降に変更されたすべてのブロックをバックアップするタイプの増分バックアップ。たとえば、レベル1の差分バックアップでは、Recovery Managerは、レベル1またはレベル0の増分バックアップの最新のバックアップを判断し、そのバックアップ後に変更されたすべてのブロックをバックアップする。差分バックアップは、増分バックアップのデフォルト・タイプである。差分増分バックアップを使用してリカバリする場合、Recovery Managerは、リストアされたデータファイル・バックアップ以降のすべてのレベル1の差分増分バックアップを適用する必要がある。
「累積増分バックアップ」、「増分バックアップ」を参照。
Recovery ManagerまたはSQL*PlusのRECOVER ... TESTコマンドで開始されるリカバリのシミュレーション。メディア・リカバリは、通常のメディア・リカバリと同じ方法でREDOを適用しますが、ディスクに変更を書き込むことはなく、必ず変更をロールバックする。試行リカバリはメモリー内でのみ発生する。
過去のある時点でのデータベースのコミットされたバージョンを定義するスタンプ。Oracleでは、コミットされたすべてのトランザクションに一意のSCNが割り当てられる。
UNDOデータが専用のUNDO表領域に格納されるデータベース・モード。ユーザーが実行する必要があるUNDO管理操作は、UNDO表領域の作成のみである。他のすべてのUNDO管理操作は自動的に実行される。
データベース・トレース・ファイルおよびその他の診断データを格納および整理するためのシステム管理のリポジトリ。ADRでは、データベースで発生したすべての重大なエラーの包括的なビューが示され、問題の診断と最終的な解決に必要なすべての関連データが管理される。リポジトリには、インシデント、トレース、ダンプ、アラート・メッセージ、データ修復レコード、データ整合性チェック・レコード、SQLトレース情報、コア・ダンプなどについて記述されたデータが含まれている。
ADRベースの場所は、DIAGNOSTIC_DEST初期化パラメータによって指定される。この場所が、1つ以上のADRホームが含まれるディレクトリとなる。各ADRホームは、適切に定義されたサブディレクトリに診断データを格納するために製品または製品インスタンスで使用される。たとえば、Oracle Databaseインスタンスの診断データは、専用のADRホームに格納される。このADRホームには、アラート・メッセージ用のalertサブディレクトリ、トレース・ファイル用のtraceサブディレクトリなどがある。トレース・ファイルおよびアラート・ログの場所を特定する最も簡単な方法は、SQL問合せSELECT NAME, VALUE FROM V$DIAG_INFOを実行する方法である。
Oracle Databaseファイル専用に構築された、ファイル・システムとボリューム・マネージャの両方の垂直統合。ASMによって、簡単に管理可能なディスク・グループに複数のストレージ・デバイスが統合され、サード・パーティの論理的なボリューム・マネージャを必要とせずにミラー化やストライプ化などのメリットを実現できる。
ALLOCATE CHANNNELコマンドを使用せずに、バックアップおよびリストアのタスクを実行するRecovery Managerの機能。CONFIGUREコマンドを使用すると、ディスクおよびテープのチャネルを指定できる。その後、手動でチャネルを割り当てずに、Recovery Managerのコマンド・プロンプトでBACKUPやRESTOREなどのコマンドを発行できるようになる。Recovery Managerでは、コマンドを実行するために必要なすべての構成済のチャネルが使用される。
Windows上のVolume Shadow Copy Service（VSS）インフラストラクチャでは、コンポーネントまたはボリュームの一貫性のあるスナップショットのことである。
データ・リカバリ・アドバイザのコンテキストでは、修復とは1つ以上の障害を修正するための単一または一連の処理のことである。修復の例としては、ブロック・メディア・リカバリ、データファイルのメディア・リカバリ、Oracle Flashback Databaseなどがある。
データ・リカバリ・アドバイザのコンテキストでは、障害を修復するために使用可能な方法の1つ。同じ問題を修正するための様々な修復オプションがあるが、それぞれの方法に、修復時間およびデータ消失の点で異なるメリットおよびデメリットがある。
Recovery Managerでバックアップおよびリカバリの操作に使用される情報が含まれている制御ファイルのレコード。これらのレコードは、論理的に円形に配置されている。使用可能なレコード・スロットが一杯の場合、制御ファイルを拡大して新規レコード用の領域を確保するか、あるいは最も古いレコードを上書きする。CONTROL_FILE_RECORD_KEEP_TIME初期化パラメータで、レコードを上書きするまでの最短保管日数を制御する。CONTROL_FILE_RECORD_KEEP_TIMEのデフォルト値は7日間である。
「非循環再利用レコード」を参照。
データ・リカバリ・アドバイザのコンテキストでは、障害とは、データベースによって診断された永続的なデータの破損のことである。障害は、エラー・メッセージやアラートなどの目に見える症状として示される場合があるが、診断された問題を表すため、症状とは異なる。障害は、データベース外にある診断データ用のリポジトリに記録される。
障害ごとに、その障害を明確に説明する問題陳述文がデータ・リカバリ・アドバイザによって生成される。障害の例として、アクセスできないデータファイルや破損したUNDOセグメントなどがある。データ・リカバリ・アドバイザによって、すべての障害が1つの修復オプションまたは修復オプションのセットにマップされる。
データ・リカバリ・アドバイザによって診断される障害のステータス。すべての障害のステータスは、OPENまたはCLOSEDのいずれかになる。
データ・リカバリ・アドバイザによって診断される障害の優先順位。クローズされていないすべての障害のステータスは、CRITICAL、HIGHまたはLOWのいずれかになる。障害のHIGHおよびLOWのステータスは、CHANGEコマンドを使用して手動で変更できる。
データベースのインストールに関連するすべてのデータの消失に対する計画。たとえば、データ・センターのサーバーが火事によって破壊されたため、Oracle Databaseを新しいサーバーに再インストールして、消失したデータベースをバックアップからリカバリする必要がある場合など。
実際には書込みが発生していないにもかかわらず、I/Oサブシステムからの情報に基づいて発生がデータベースで認識された、永続ストレージへの書込み。
保存方針では、バックアップした各ファイルの保存するコピーの数を決定する設定。冗長性ベースの保存方針は、リカバリ期間を使用する保存方針と対比される。
任意のOracle Databaseファイルの障害または消失からのリカバリを可能にするバックアップのセット。
リカバリ・カタログに格納された一連のRecovery Managerコマンド。ストアド・スクリプトには、グローバルとローカルの2種類がある。グローバル・スクリプトは、リカバリ・カタログに登録されたすべてのデータベースで共有できる。
Recovery Managerによって、オペレーティング・システム固有の場所に作成されたデータベース制御ファイルのコピー。Recovery Managerは、リカバリ・カタログの再同期化または制御ファイルのバックアップを行う際に使用する制御ファイルの一貫性のあるバージョンを確保するために、スナップショット制御ファイルを作成する。
現在の制御ファイルおよびサーバー・パラメータ・ファイルの自動バックアップ。バックアップ後、およびデータベースがARCHIVELOGモードである場合は構造変更後に、Recovery Managerによって作成される。
制御ファイルの自動バックアップにはデフォルトのファイル名がある。この名前によって、Recovery Managerは、制御ファイルおよびリカバリ・カタログが消失した場合でも、制御ファイルをリストアできる。デフォルトのファイル名は変更できる。
増分ではないRecovery Managerのバックアップ。全体とは、バックアップされるデータベースの量を表すのではなく、バックアップが増分ではないことを表す。したがって、1つのデータファイルに対して全体バックアップを作成できる。
複製データベースの作成時にコピーするデータベース。
Recovery ManagerのCONVERTコマンドの使用時に、ソース・データベースが実行されているプラットフォーム。ソース・データベースには、異なるプラットフォームで実行されているデータベースに転送されるデータが含まれている。
ソース・データベースが存在するホスト。
増分バックアップを使用して更新される、Recovery Managerのデータファイルのコピー。データファイルをコピーして増分バックアップを作成した後、その増分バックアップをイメージ・コピーにマージするバックアップ計画が効率的である。この計画では、データ・ブロックの最新の変更を使用してイメージ・コピーが更新されるため、メディア・リカバリに必要な時間が削減される。
修正されたブロックのみがバックアップされるRecovery Managerのバックアップ。増分バックアップはレベルによって分類される。レベル0の増分バックアップは、使用されたすべてのブロックをバックアップするという点では全体バックアップと同じである。ただし、全体バックアップでは後続の増分バックアップでバックアップされるブロックに影響は及ばないが、増分バックアップでは後続の増分バックアップでバックアップされるブロックに影響が及ぶ点が異なる。
レベル1の増分バックアップでは、前回の増分バックアップ以降に変更されたブロックのみがバックアップされる。変更されなかったブロックはバックアップされない。増分バックアップは、差分増分バックアップまたは累積増分バックアップのいずれかである。
親インカネーションは、OPEN RESETLOGS操作後にブランチされた現行のインカネーションの元となるデータベース・インカネーションである。親インカネーションの親が祖先インカネーションである。祖先インカネーションのすべての親も祖先インカネーションである。
Recovery Manager環境では、ターゲット・データベースに関連付けられているインスタンスのことである。
Recovery Manager環境では、TARGETとして接続されたデータベースのことである。ターゲット・データベースは、Recovery Managerの操作を実行するデータベースである。
ターゲット・データベースが存在するコンピュータ。
Recovery Managerのバックアップの識別子。バックアップ・セットを生成した場合、タグはそのバックアップ・セットではなく、各バックアップ・ピースに割り当てられる。バックアップのタグを指定しなかった場合、Recovery Managerはタグを自動的に割り当てる。
この用語の意味は、多重化されるファイルによって次のように異なる。
オンラインREDOログの2つ以上の同一コピーを自動的にメンテナンスすること。
データベースの制御ファイルの2つ以上の同一コピーを自動的にメンテナンスすること。
データベース・ファイルをディスクから同時に読み取り、そのブロックを同一のバックアップ・ピースに書き込むRecovery Managerの機能。
Oracleアーカイバ・プロセスによってREDOログの複数のコピーがアーカイブされること。
「ミラー化」を参照。
同時に読み取られ、Recovery Managerの同じバックアップ・ピースに書き込まれる入力ファイルの数。
Recovery Managerでは、多重バックアップ・セットとは、Recovery Managerによって生成される、バックアップ・セットの同一コピーのことである。元のバックアップ・セット内の各バックアップ・ピースがコピーされ、それぞれのコピーに一意のコピー番号（0tcm8u2s_1_1、0tcm8u2s_1_2など）が付けられる。
複数の入力ファイルのブロックが含まれているバックアップ・セット。たとえば、10個のデータファイルを1つのバックアップ・セットに多重化することができる。バックアップ・セットには、ファイルの一部ではなくファイル全体が含まれている。
データまたはREDOブロックに格納されているすべてのバイトから、データベースによって計算される数値。DB_BLOCK_CHECKSUM初期化パラメータが有効になっている場合は、データベースによって、すべてのデータファイルまたはオンラインREDOログ・ブロックのチェックサムが計算され、ディスクへの書込み時にブロック・ヘッダーに格納される。データベースでは、このチェックサムの値を使用して一貫性がチェックされる。
データベースのREDOスレッドにSCNを定義するデータ構造。チェックポイントは、制御ファイルおよび各データファイル・ヘッダーに記録され、リカバリに不可欠な要素である。
Recovery Managerのチャネルは、バックアップ・デバイスに対する1つの双方向ストリームを表す。チャネルは、DISKチャネル（ディスクI/Oの実行に使用される）またはSBTチャネル（サード・パーティのメディア・マネージャを介したI/Oの実行に使用される）のいずれかになる。割り当てられたチャネルごとに、新しいOracleサーバー・セッションが開始される。このサーバー・セッションで、バックアップ、リストアおよびリカバリの操作が実行される。
「ターゲット・データベース」を参照。
Recovery Managerの操作に対して複数のチャネルを割り当てること。
バックアップ保存方針からは除外するが、リカバリ・カタログには記録する必要があるバックアップ。通常、長期バックアップとは、将来、レポートの生成に使用する可能性があるデータベースのスナップショットのことである。
OPEN RESETLOGS操作が複数回行われた場合の、現行のデータベース・インカネーションの親インカネーションおよび現行のインカネーションのそれぞれの祖先インカネーションを含むインカネーション・パス。
SCNまたは時刻のラベル。SCNまたは時刻がサポートされているコマンドには、多くの場合、リストア・ポイントを指定できる。通常のリストア・ポイントは循環リストに含まれており、制御ファイル内で上書きできる。ただし、リストア・ポイントがアーカイブ・バックアップに関連する場合は、リカバリ・カタログに保存される。
メディア・リカバリまたはOracleフラッシュバック技術を使用して、消失または破損したデータをリカバリすること。
状態モニターに登録される診断プロシージャであるチェッカの起動。
特定のデータファイル用のデータベースのREDOスレッドにSCNを定義するデータ構造。すべてのデータファイルにチェックポイントSCNがある。このSCNは、V$DATAFILE.CHECKPOINT_CHANGE#で参照できる。このSCNより小さいSCNを持つすべての変更がそのデータファイル内に存在することが保証される。
リストアされたデータファイルをより現在に近い時点までロールフォワードするために、リストアされたデータファイルにREDOレコードを適用すること。ブロック・メディア・リカバリを実行している場合を除いて、リカバリ中はデータファイルをオフラインにする必要がある。
「DBID」を参照。
制御ファイルおよびデータベースに属するすべてのデータファイルのバックアップを作成する。
SCNが最も低いスレッド・チェックポイント。データベース・チェックポイントSCNより前のSCNを持つすべての有効なREDOスレッドにおけるすべての変更が、ディスクに書き込まれていることが保証される。
「チェックポイント」、「データファイル・チェックポイント」を参照。
指定した過去の目標時点、SCNまたはログ順序番号までデータベース全体をリカバリすること。
「不完全リカバリ」、「表領域のPoint-in-Timeリカバリ」を参照。
「登録」を参照。
Oracleによって管理されるデータファイル、制御ファイルおよびオンラインREDOログ・ファイル用の場所。データベース領域は、DB_CREATE_FILE_DEST初期化パラメータで指定される。
永続的なデータ障害を自動的に診断し、ユーザーに修復オプションを提示し、ユーザーの要求に応じて修復を実行するOracle Databaseツール。
自動ストレージ管理によってユニットとして管理されるディスクのコレクション。ディスク・グループの構成要素には、ディスク、ファイルおよび割当て単位が含まれている。
1つ以上のディスク・ドライブを制御するハードウェア・コンポーネント。
ユーザーが指定するフラッシュ・リカバリ領域のサイズの制限。ディスク割当て制限に達すると、Oracleによって不要なファイルが自動的に削除される。
Recovery ManagerのCONVERTコマンドの使用時に、転送先データベースが実行されるプラットフォーム。転送先データベースとは、データの転送先となるデータベースのことである。
複製データベースが存在するコンピュータ。
CONVERT DATABASEコマンドによって生成されるスクリプト。このスクリプトには、転送先プラットフォーム上の新しいデータベースの作成に使用するSQL文が含まれている。
Recovery Managerがデータの読取りまたは書込みをするとき、サーバー・プロセスは一度に1つのタスクのみを実行できる。
Recovery Managerで、REGISTER DATABASEコマンドを実行し、ターゲット・データベースの存在をリカバリ・カタログに記録する。ターゲット・データベースは、そのDBIDによってカタログ内で一意に識別される。2つ以上のデータベースを同じカタログに登録することも、同じデータベースを複数のカタログに登録することもできる。
表領域のセットを、1つのデータベースから別のデータベースに、または1つのデータベースからそのデータベース自身に転送する機能。表領域をデータベースに転送することは、あらかじめロードされたデータを使用して表領域を作成することに似ている。
トランスポータブル表領域操作での表領域のセットのデータファイル、および表領域のセットのメタデータが含まれているエクスポート・ファイル。エクスポートを実行するには、データ・ポンプ・エクスポートを使用する。
Recovery Managerで、バックアップ・セット内のデータに圧縮アルゴリズムを適用する方法。
ORAPWDコマンドによって作成され、SYSDBA権限またはSYSOPER権限を使用してネットワークを介して接続する場合に必要なファイル。パスワード・ファイルの詳細は、『Oracle Database管理者ガイド』を参照。
認識されているOracle形式ではないか、または内容に内部的な一貫性がないOracleブロック。通常、破損は、ハードウェアの障害またはオペレーティング・システムの問題によって発生する。Oracleでは、破損ブロックは、論理的な破損（Oracle内部エラー）またはメディア破損（不正なブロック形式）のいずれかに識別される。
メディア破損ブロックは、ブロック・メディア・リカバリを使用して修復するか、または破損ブロックが別のオブジェクトで再利用されるようにそのブロックが含まれているデータベース・オブジェクトを削除することによって修復できる。メディア破損の原因がハードウェア故障の場合、前述のどちらの解決策も、そのハードウェアの故障を直さなければ効果がない。
（1）データベース、表領域、表、データファイル、制御ファイル、アーカイブREDOログなどのデータのバックアップ・コピー。バックアップには、（データベース・ファイル・レベルでの）物理的なものと（データベース・オブジェクト・レベルでの）論理的なものがある。物理バックアップは、Recovery Managerを使用して1つ以上のデータファイル、制御ファイルまたはアーカイブREDOファイルをバックアップすることによって作成することができる。論理バックアップは、データ・ポンプ・エクスポートを使用して作成することができる。
（2）Recovery Managerのコンテキストでは、BACKUPコマンドの出力。バックアップの出力形式は、バックアップ・セット、プロキシ・コピーまたはイメージ・コピーのいずれかである。データベースによってアーカイブされたログは、バックアップではなくコピーとみなされる。
メディア障害またはユーザー・エラーによるデータの消失からデータベースを保護するために必要な概念、手順および計画のセット。
バックアップ・アクティビティを完了する必要がある時間の長さ。
制御ファイルのバックアップ。制御ファイルは、Recovery ManagerのbackupコマンドまたはSQL文のALTER DATABASE BACKUP CONTROLFILE TO 'ファイル名'を使用してバックアップすることができる。
1つ以上のデータファイル、制御ファイル、サーバー・パラメータ・ファイルおよびアーカイブREDOログ・ファイルのバックアップ。各バックアップ・セットは、1つ以上のバイナリ・ファイルで構成される。各バイナリ・ファイルは、バックアップ・ピースと呼ばれる。バックアップ・ピースは、Recovery Managerによってのみ作成またはリストアできる独自の形式で書き込まれる。
バックアップ・セットは、Recovery ManagerのBACKUPコマンドで作成する。バックアップ・セットは、通常は1つのバックアップ・ピースのみで構成される。Recovery Managerは、ユーザーがALLOCATE CHANNELまたはCONFIGURE CHANNELコマンドのMAXPIECESIZEオプションを使用してバックアップ・ピースのサイズを制限した場合にのみ、バックアップ・セットの内容を複数のバックアップ・ピースに分割する。
「未使用ブロックの圧縮」、「多重化」、「Recovery Manager」を参照。
V$RMAN_ENCRYPTION_ALGORITHMSに表示されているアルゴリズムの1つを使用して行われるバックアップ・セットの暗号化。Recovery Managerは、バックアップ・セットに書き込まれるデータを透過的に暗号化し、これらのバックアップ・セットがRESTORE操作で必要になると復号化する。Recovery Managerには、透過モード、パスワード保護モードおよびデュアル・モードの3つの暗号化モードがある。
Recovery Managerで、すでにバックアップされているファイルのバックアップを自動的にスキップできるようにする構成。バックアップの最適化を有効または無効にするには、CONFIGUREコマンドを使用する。
メディア・リカバリを実行するためにバックアップおよびアーカイブ・ログを保存しておく必要がある期間を決定するユーザー定義の方針。保存方針は、バックアップ冗長性またはリカバリ期間で定義できる。Recovery Managerは、現行の保存方針を満たすために必要なデータファイル・バックアップ、およびこれらのデータファイル・バックアップの完全なリカバリに必要なすべてのアーカイブREDOログを保持する。
Recovery Managerのバックアップ・セットの格納に使用される物理ファイルの形式。各論理バックアップ・セットには、1つ以上の物理バックアップ・ピースが含まれている。
ターゲット・データベースのバックアップをリストアおよびリカバリすることによって、複製データベースを作成すること。この方法は、アクティブなデータベースの複製の代替方法である。
オンライン・バックアップを実行する前にALTER TABLESPACE ... BEGIN BACKUPまたはALTER DATABASE BEGIN BACKUPコマンドを発行すると開始されるデータベースのモード（ホット・バックアップ・モードとも呼ばれる）。ALTER TABLESPACE ... END BACKUPまたはALTER DATABASE END BACKUPコマンドを発行する場合は、表領域のバックアップ・モードを終了する。
オンラインの表領域のデータファイルのユーザー管理バックアップを実行する場合は、分裂ブロックが作成されないように、表領域をバックアップ・モードにする必要がある。バックアップ・モードでは、データベースへの更新によって通常より多くのREDOが作成される。データベースでは、バッファ・キャッシュ内のブロックが使用済になるたびに、データに対する変更の記録に加えて、変更されたブロックのイメージをREDOログ・ファイルに書き込む必要がある。Recovery Managerでは、データベースをバックアップ・モードにする必要はない。
「破損ブロック」を参照。
複数のプロセスによって、REDOログ・ファイルからの変更が同時に適用されるリカバリの形式。RECOVERY_PARALLELISM初期化パラメータによって、インスタンスおよびクラッシュ・リカバリのパラレル化のレベルを決定する。RECOVERコマンドのPARALLELおよびNOPARALLELオプションを使用して、メディア・リカバリのパラレル化を制御できる。
リカバリの最適な並列度は、Oracle Databaseによって自動的に選択される。ほとんどの場合、インスタンス・リカバリ、クラッシュ・リカバリまたはメディア・リカバリのパラレル化のレベルを手動で設定することは推奨されないか、または不要である。
バックアップ内のファイルの一部に、ファイルのチェックポイント後に行われた変更が含まれているバックアップ。このタイプのバックアップは、一貫性を持たせるためにリカバリが必要である。通常、非一貫性バックアップは、オンライン・データベース・バックアップによって作成される。次のいずれかの理由でデータベースがクローズされている際にデータファイルをバックアップした場合も、非一貫性バックアップが作成されることがある。
非一貫性バックアップは、データベースがARCHIVELOGモードで、バックアップ以降に作成されたすべてのアーカイブREDOログを使用できる場合にのみ有効である。
「一貫性バックアップ」、「オンライン・バックアップ」、「システム変更番号」、「データベース全体のバックアップ」を参照。
Oracle Databaseで必要とされる重要な情報が含まれている制御ファイルのレコード。これらのレコードが自動的に上書きされることはない。非循環再利用レコードに含まれている情報の例としては、データファイルの場所およびオンラインREDOログがある。
「循環再利用レコード」を参照。
Recovery Managerがデータの読取りまたは書込みを行っているとき、サーバー・プロセスは、1つのI/Oを開始し、そのI/Oが完了するまで待機している間に別の作業を実行できる。また、1つ目のI/Oの完了の待機に入る前に、複数のI/O操作を開始することもできる。
SYSTEM以外の1つ以上の表領域を現在以外の時刻にリカバリすること。TSPITRの実行にはRecovery Managerを使用する。
トランスポータブル表領域の操作では、表領域の転送コマンドの完了時にデータファイルのコピーおよびその他の出力ファイルが（デフォルトで）含まれるディスク上の場所。
データファイル内の連続するブロックの範囲。マルチセクション・バックアップは、各セクションを個別のバックアップ・ピースにコピーすることによって、大規模なファイルをパラレルで処理する。
データファイル・ヘッダーのチェックポイントSCN以上のSCNを持つブロックが1つ以上含まれているデータファイル。データベース・ライターでは、ファイル・ブロックが書込まれるたびにファイル・ヘッダーのSCNが更新されないため、ファジー・ファイルは使用できない。たとえば、バックアップ・モードのデータファイルがOracleによって更新されると、このような状況が発生する。リストアされたファジー・ファイルには、常にメディア・リカバリを実行する必要がある。
障害保護の目的で使用できる本番データベースのコピー。
「完全リカバリ」、「メディア・リカバリ」、「リカバリする」を参照。
Recovery ManagerのDUPLICATEコマンドを使用して、ターゲット・データベースのバックアップから作成されるデータベース。
「補助データベース」を参照。
任意の時点でデータベースに存在するデータファイル、制御ファイルおよびREDOログ。表領域およびデータファイルのリストを取得するには、Recovery ManagerのREPORT SCHEMAコマンドを発行する。
破損ブロックがデータベースで認識されない破損。チェックサムが無効であるか、ブロックの内容がすべて0（ゼロ）であるか、またはブロックのヘッダーとフッターが一致していないため、ブロックがデータベースで認識されない場合がある。
物理ファイルのバックアップ。物理バックアップは、表のエクスポートなどの論理バックアップと対比される。
再同期化のタイプ。この同期化では、Recovery Managerはアーカイブ・ログ、バックアップ・セットおよびデータファイルのコピーに関するデータを、ターゲット制御ファイルからリカバリ・カタログに転送する。
現行のバックアップ保存方針を満たす必要がないバックアップ。たとえば、データファイルごとに1つのバックアップを保持する必要があると保存方針で定められている場合に、データファイル1のバックアップが2つ存在すると、データファイル1の2つ目のバックアップは不要であるとみなされる。
表内のすべてのレコードに対するトランザクション関連の変更を、それらのレコードの存続期間中保存する履歴リポジトリ。フラッシュバック・データ・アーカイブでは、いくつかの論理フラッシュバック機能を使用して、非常に古い履歴データに透過的にアクセスできる。
FLASHBACK DATABASEコマンドをサポートするための十分なフラッシュバック・ログ・データが現在存在するSCNの範囲。フラッシュバック・データベース・ウィンドウは、使用可能なフラッシュバック・ログにある最も古いSCNより前には拡張できない。
データベースのフラッシュバックで戻ることができる最も古い過去の時点を示す、ユーザーが指定する時刻またはSCN。
フラッシュバック・データベース操作の実行に使用する、Oracleで生成されるログ。データベースでは、フラッシュ・リカバリ領域へのフラッシュバック・ログの書込みのみを実行できる。フラッシュバック・ログは、順次書き込まれ、アーカイブは行われない。また、ディスクへのバックアップはできない。
制御ファイルのコピー、オンラインREDOログのコピー、アーカイブREDOログ・ファイル、フラッシュバック・ログ、Recovery Managerバックアップなどのリカバリ関連ファイルの格納のために使用可能なオプションのディスクの場所。フラッシュ・リカバリ領域内のファイルは、Oracle DatabaseおよびRecovery Managerによって自動的に管理される。フラッシュ・リカバリ領域の最大サイズは、ディスク割当て制限で指定できる。
Recovery Managerのバックアップ処理とリストア処理時に、メディア・マネージャがメディア・ストレージ・デバイスとディスク間のデータ転送を管理するバックアップ。
ブロックの破損の一種。破損がブロック自体内ではなく、ブロック間で発生する。このタイプの破損は、論理的な破損のみである。
各データベース更新によって影響を受けたデータファイル・ブロックを追跡するためのデータベース・オプション。追跡情報は、ブロック・チェンジ・トラッキング・ファイルに格納される。ブロック・チェンジ・トラッキングが有効になっている場合、Recovery Managerは、チェンジ・トラッキング・ファイルに含まれている変更されたブロックのレコードを使用して、データファイル全体を読み取るのではなく、変更されたことがわかっているブロックのみを読み取ることによって、増分バックアップのパフォーマンスを向上させる。
Recovery Managerで、増分バックアップのパフォーマンスを向上させるために、変更されたブロックの記録に使用されるバイナリ・ファイル。このファイルの作成および名前の変更には、ALTER DATABASE文を使用する。
ブロックの破損の一種。破損がブロック自体内で発生する。このタイプの破損には、物理的な破損と論理的な破損がある。
Recovery ManagerのRECOVER ...BLOCKコマンドを使用して、データファイル内の指定したブロックをリカバリすること。ブロック・メディア・リカバリでは、影響を受けたデータファイルはオンラインのままで、損傷または破損したブロックのみがリストアおよびリカバリされる。
任意のSCNでヘッダーとフッターが一貫性していないブロック。ユーザー管理バックアップでは、DBWRがファイルを更新するときに、オペレーティング・システム・ユーティリティを使用してデータファイルをバックアップできる。オペレーティング・システム・ユーティリティは、更新途中の状態のブロックを読み取ることができるため、バックアップ・メディアにコピーされるブロックの前半は更新されていても、後半には古いデータが含まれていることがある。この場合、ブロックは分裂している。
Recovery Managerを使用しないバックアップの場合は、ALTER TABLESPACE ... BEGIN BACKUPまたはALTER DATABASE BEGIN BACKUPコマンドが、分裂ブロック問題の解決策となる。表領域がバックアップ・モードのときにデータ・ブロックを変更した場合は、ブロック・イメージ全体のコピーをログに記録してから変更が行われる。このため、メディア・リカバリによって、このブロックが分裂していることが検出された場合でも、データベースはブロックを再構築できる。
リカバリ・カタログ・スキーマ全体。ベース・リカバリ・カタログは、リカバリ・カタログのサブセットである仮想プライベート・カタログと区別される。
リカバリを実行するために必要な時間。
CONVERT DATABASEコマンドで生成されるスクリプト。転送先ホスト上でデータファイル形式を変換するために使用できる。
補助データベース、あるいは表領域のPoint-in-Timeリカバリまたはトランスポータブル表領域の操作で使用される一時インスタンスに関連付けられているOracleインスタンス。
Oracle Flashback Databaseの操作を行うためにフラッシュバック・ログがデータベースで保持されていることが保証されたリストア・ポイント。通常のリストア・ポイントとは異なり、保証付きリストア・ポイントは制御ファイルからエージ・アウトされないため、明示的に削除する必要がある。保証付きリストア・ポイントではフラッシュ・リカバリ領域内の領域が使用されるが、この領域は定義する必要がある。
TSPITRにおいて、リカバリ・セットにはないファイルのセット。ただし、TSPITR操作を正しく実行するには、これらのファイルを補助データベースでリストアする必要がある。トランスポータブル表領域の操作では、データファイル以外に、表領域の転送には必要であるが、それ自体はリカバリ・セットの一部ではないその他のファイルが補助セットに含まれる。
補助インスタンスに接続されているRecovery Managerチャネル。補助チャネルは、ALLOCATE CHANNELまたはCONFIGURE CHANNELコマンドのAUXILIARYキーワードで指定する。
（1）Recovery ManagerのDUPLICATEコマンドを使用して、ターゲット・データベースのバックアップから作成されたデータベース。
（2）表領域のPoint-in-Timeリカバリの実行中に新しい場所にリストアされ、その後新しいインスタンス名で起動される一時データベース。TSPITR補助データベースは、リカバリ・セットと補助セットで構成される。
トランスポータブル表領域の操作で、補助インスタンスのパラメータ・ファイル、データファイル（転送する表領域のデータファイル以外）、制御ファイル、オンライン・ログなどの補助セット・ファイルを格納できるディスク上の場所。
「バックアップの保存方針」を参照。
「オンライン・バックアップ」を参照。
「バックアップ・モード」を参照。
バックアップ・ピースごとに1つのファイル・セクション（データファイル内の連続するブロックの範囲）が含まれているRecovery Managerのバックアップ・セット。マルチセクション・バックアップ・セットには複数のバックアップ・ピースが含まれているが、バックアップ・セットにはデータファイルの一部のみが含まれるのではないことに注意すること。
マルチセクション・バックアップは、BACKUPコマンドでSECTION SIZEパラメータを指定して作成する。Recovery Managerのチャネルは、各ファイル・セクションをシリアルまたはパラレルのいずれかで個別に処理できる。このため、マルチセクション・バックアップでは、複数のチャネルで単一のファイルをバックアップできる。
Recovery Managerで、データ・ブロックをスキップすることによってデータファイル・バックアップ・セットのサイズを小さくする機能。Recovery Managerでは、一度も使用されていないブロックが常にスキップされる。特定の条件（『Oracle Databaseバックアップおよびリカバリ・リファレンス』のBACKUP AS BACKUPSETエントリに関する項を参照）では、以前に使用されていたが、現在は使用されていないブロックもスキップされる。
1つ以上のディスクにデータの同一のコピーを保持すること。通常、ミラー化は複製ハード・ディスク上でオペレーティング・システム・レベルで実行されるため、一方のディスクが使えない場合でも、もう一方のディスクで要求の処理を中断せずに続行できる。ファイルのミラー化では、Oracle Databaseによって1回の書込みが行われるが、オペレーティング・システムによって複数のディスクへの書込みが行われる。ファイルの多重化では、Oracle Databaseによって同じデータが複数のファイルに書き込まれる。
ディスク・ミラー化プロシージャの中断。ミラー・イメージは最新の状態ではなくなる。
ミラーを管理しているオペレーティング・システムまたはハードウェアに、破損したミラーを最新のミラーから更新する必要があることを通知し、両方のミラーを保持する。
以前にミラー化されたデータベース・ファイルのバックアップ。サード・パーティ・ツールには、ディスクまたは論理デバイスのセットをミラー化（プライマリ・データの正確な複製を別の場所に保持）できるものがある。ミラーを分割すると、ファイルのコピーが分離されるため、それぞれを別々に使用できる。データベース機能のALTER SYSTEM SUSPEND/RESUMEを使用すると、データベースに対するI/Oを一時停止した後、ミラーを分割し、分割されたミラーのバックアップを作成できる。
メディア・マネージャによって管理されるレコードのカタログ。このカタログは、Recovery Managerのリカバリ・カタログとは完全に無関係である。メディア管理カタログの例としては、Oracle Secure Backupカタログがある。
Recovery Managerで3次ストレージへのバックアップに使用できるソフトウェア・ライブラリ。SBTインタフェースは、公開されているAPIに準拠しており、メディア管理ベンダーによって提供される。Oracle Secure Backupには、Recovery Managerで使用するためのSBTインタフェースが含まれている。
Oracleで使用されるファイル（データファイル、アーカイブREDOログ・ファイルまたは制御ファイルなど）のいずれかが含まれているディスクの損傷。Oracleでは、メディア障害が検出されると、影響を受けているファイルがオフラインになる。
「メディア・リカバリ」を参照。
データベース・バックアップを3次ストレージに直接書き込むことができるようにRecovery Managerに統合可能な、サード・パーティのネットワーク型バックアップ・システム。
Recovery Managerによるバックアップ中に、Recovery Managerではなくメディア・マネージャによってブロックの組合せが管理される多重化。メディア・マネージャによる多重化のタイプの1つとして、メディア・マネージャが、複数のRecovery Managerチャネルからの同時出力を単一のシーケンシャル・デバイスに書き込んだ場合に発生するものがある。また、別のタイプとして、バックアップによって同じテープ上にデータベース・ファイルとデータベース以外のファイルが混在した場合に発生するものもある。
リストアされたバックアップ・データファイルまたは個々のデータ・ブロックにREDOまたは増分バックアップを適用すること。
メディア・リカバリを実行すると、データベース、表領域、データファイル、またはデータファイル内の一連のブロックをリカバリできる。メディア・リカバリは、完全リカバリ（REDOログ内のすべての変更が適用される）または不完全リカバリ（指定した時点までの変更のみが適用される）のいずれかで実行できる。メディア・リカバリは、データベースがARCHIVELOGモードの場合にのみ実行できる。
「ブロック・メディア・リカバリ」、「リカバリする」を参照。
自動診断リポジトリに記録されているデータベースの重大エラー。重大エラーには、内部エラーおよび他のサーバー・エラーが含まれている。それぞれの問題には、その問題を記述する属性のセットである問題キーがある。問題キーには、ORAエラー番号、エラー・パラメータ値および他の情報が含まれている。
Recovery Managerを使用しないOracle Databaseのバックアップおよびリカバリ計画。オペレーティング・システムのバックアップおよびリカバリとも呼ばれる。オペレーティング・システムのユーティリティ（UNIXのcpコマンドなど）を使用してデータベース・ファイルをバックアップおよびリストアしてから、SQL*PlusのRECOVERコマンドを使用してリカバリできる。
オペレーティング・システムのユーティリティを使用する方法などのRecovery Manager以外の方法を使用して行われるバックアップ。たとえば、Linuxでcpコマンドを実行するか、またはWindowsでCOPYコマンドを実行することによって、ユーザー管理バックアップを作成できる。ユーザー管理のバックアップは、オペレーティング・システムのバックアップとも呼ばれる。
データベース・ファイルまたはデータベースに関して使用する場合は、消失した変更を再構築するために、REDOデータまたは増分バックアップをデータベース・ファイルに適用すること。リカバリには、インスタンス・リカバリ、クラッシュ・リカバリおよびメディア・リカバリの3つのタイプがある。Oracleでは、最初の2つのリカバリはオンラインREDOレコードを使用して自動的に実行される。メディア・リカバリのみは、ユーザーがバックアップをリストアしてコマンドを発行する必要がある。
1つ以上のOracle Databaseに関するRecovery Managerのリポジトリ情報を格納するために、Recovery Managerで使用されるOracleの表およびビューのセット。Recovery Managerは、このメタデータを使用して、Oracle Databaseのバックアップ、リストアおよびリカバリを管理する。
Data Guard環境でRecovery Managerを使用しない場合は、リカバリ・カタログの使用は任意である。Data Guard環境で使用する場合は必須である。データベースに関するRecovery Managerのリポジトリ情報の1次ストレージは、常にデータベースの制御ファイル内となる。リカバリ・カタログは、制御ファイルからのRecovery Managerのリポジトリ・データで定期的に更新される。制御ファイルが消失した場合は、データベースのリストアおよびリカバリに必要となる、消失したメタデータの大部分またはすべてがリカバリ・カタログによって提供される。リカバリ・カタログには、アーカイブ・バックアップのレコード、およびターゲット・データベースで使用するRecovery Managerストアド・スクリプトのレコードも記録できる。
「リカバリ・カタログ・データベース」を参照。
リカバリ・カタログの表およびビューが含まれている、リカバリ・カタログ・データベースのスキーマ。
リカバリ・カタログ・スキーマが含まれているOracle Database。リカバリ・カタログはターゲット・データベースには格納できない。
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コマンドを使用する。
Recovery Managerで、可能な場合、バックアップからデータファイルがリストアされないようにするデフォルトの動作。
破損したバックアップまたはアクセスできないバックアップが検出された場合にリストア操作で使用できるバックアップをRecovery Managerで自動的に検索すること。
データベースのSCNに関連付けられているユーザー定義の名前。SCNはリストア・ポイントが作成された時刻に対応する。リストア・ポイントには、保証付きリストア・ポイントまたは通常のリストア・ポイントがある。
レベル0の最新のバックアップ以降に変更されたすべてのブロックをバックアップする増分バックアップ。累積増分バックアップを使用してリカバリするときは、最新の累積増分バックアップを1つのみ適用する必要がある。
「差分増分バックアップ」、「増分バックアップ」を参照。
バックアップ対象のデータファイル内のすべてのデータ・ブロックをバックアップする、Recovery Managerの増分バックアップ。レベル0の増分バックアップの内容は全体バックアップと同じである。ただし、レベル0のバックアップは、全体バックアップと異なり、増分バックアップ計画の一部とみなされる。
リカバリするのロールフォワード段階でデータベースに適用される、コミットされていない変更を、ロールバック・セグメントを使用して取り消すこと。
データベースに対する変更の変更前のイメージが記録されたデータベース・セグメント。
データファイルおよび制御ファイルに行われた変更のリカバリするを行うために、それらのファイルに対してREDOレコードまたは増分バックアップを適用すること。
「ロールバック」を参照。
REDOログ・ファイル内の一連のREDOレコードを一意に識別する番号。Oracleでは、1つのオンラインREDOログ・ファイルが一杯になり、別のオンラインREDOログ・ファイルに切り替わると、その新しいファイルにログ順序番号が自動的に割り当てられる。
LGWRによって、アクティブなREDOログ・ファイルへの書込みが停止され、使用可能な次のREDOログ・ファイルに切り替えられる時点。LGWRでの切替えは、アクティブなログ・ファイルがREDOレコードで一杯になるか、ユーザーが手動で強制的に切り替えた場合に行われる。
「REDOログ」を参照。
ブロックのチェックサムが有効で、ヘッダーとフッターは一致しているなどの点は正常だが、内容に論理的な一貫性がない破損。
表などのデータベース・スキーマ・オブジェクトのバックアップ。論理バックアップは、Oracle Data Pump Exportユーティリティによって作成およびリストアされる。オブジェクトを論理バックアップからリストアするには、データ・ポンプ・インポート・ユーティリティを使用する。
Oracle Flashback Database以外のOracleフラッシュバック技術機能のセット。この論理機能を使用すると、過去の時点の個々のデータベース・オブジェクトまたはトランザクションを表示したり、個々のデータベース・オブジェクトまたはトランザクションを過去の時点まで巻き戻すことができる。
|
 Copyright © 2003, 2008, Oracle Corporation. All Rights Reserved. |
|