用語集

適用インスタンス

Oracle Real Application Clusters(Oracle RAC)データベース環境で、アーカイブREDOデータをスタンバイ・データベースに適用する1つのインスタンスです。

ブローカ

Oracle Data Guard構成の作成、制御および監視に必要な、複雑な操作の大半を自動化および簡素化する分散管理フレームワーク。

ブローカ構成

Oracle Data Guard構成のプライマリ・データベースとスタンバイ・データベース(REDO転送サービスとログ適用サービスを含む)を論理的にグループ化したものです。

「Data Guard構成」も参照してください。

その他のスタンバイ・データベース

スイッチオーバー操作またはフェイルオーバー操作の対象でない、またはこれらの操作に直接関係のないスタンバイ・データベース。

構成オブジェクト

データベース・オブジェクトの名前付きの集合。Oracle Data Guard構成を抽象化したものです。

データベース・ガード

データベース・ガードは、ロジカル・スタンバイ・データベース内の表を変更可能かどうかを制御します。

データベース・オブジェクト

Oracle Data Guard構成内のプライマリ・データベースまたはスタンバイ・データベースに対応する名前付きオブジェクト。ブローカは、このオブジェクトを使用して単一データベースの状態を管理および制御し、プロパティをデータベースに関連付けます。

Data Guardコマンドライン・インタフェース

Oracle Data Guardコマンドライン・インタフェース(DGMGRL)では、Oracle Data Guard構成をDGMGRLプロンプトまたはスクリプト内から制御および監視できます。

Data Guard構成

予定されている停止時間(定期点検など)に加え、予定外のイベント(人為的エラー、環境災害、データの破損など)による損害を回避または最小限に抑える分散コンピュータ・システム。

「ブローカ構成」も参照してください。

Data Guard環境

プライマリ・データベース、スタンバイ・データベースおよび遠隔同期インスタンスの物理構成。環境は、次の項目を含む多数の要因に依存します。

プライマリ・データベースに関連するスタンバイ・データベースと遠隔同期インスタンスの数
データベースで使用されるホスト・システムの数
データベースで使用されるマシンのディレクトリ構造
ネットワーク構成
REDO転送サービス
ログ適用サービス

Oracle Data Guard環境には、DBAが手動で管理する方法、Enterprise ManagerまたはData Guardコマンドライン・インタフェース(DGMGRL)を使用して自動的に管理する方法、これらすべてを組み合せて行う方法があります。

デフォルト状態

構成のブローカ管理を有効化するときに、データベース・オブジェクトが実行される初期のランタイム状態。実際のデフォルト状態は、データベースが実行中のロール(プライマリまたはスタンバイ)によって異なることもあります。

「インテンド状態」も参照してください。

フェイルオーバー

スタンバイ・データベースをプライマリ・データベースのロールに変更し、元のプライマリ・データベースを無効化する操作。

「ファスト・スタート・フェイルオーバー」および「手動フェイルオーバー」も参照してください。

遠隔同期インスタンス

プライマリ・データベースからREDOを受け取り、それをOracle Data Guard構成全体にわたって再分配する、リモートのOracle Data Guardの宛先です。それは制御ファイルを管理する点でフィジカル・スタンバイ・データベースに類似しており、REDOをスタンバイREDOログ・ファイル(SRL)に受信し、それらのSRLをローカルのアーカイブREDOログ(ARL)にアーカイブします。しかしスタンバイ・データベースとは異なり、遠隔同期インスタンスはデータ・ファイルを管理せず、アクセスに対してオープンすることもできず、REDO適用を実行することもできません。

ファスト・スタート・フェイルオーバー

プライマリ・データベースが使用できなくなった場合にフェイルオーバーを自動的に有効化します。ファスト・スタート・フェイルオーバーを有効化すると、ブローカはフェイルオーバーの必要性を判断し、指定されたスタンバイに自動的、迅速かつ確実にフェイルオーバーを実行します。このとき、フェイルオーバーの起動に手動のステップを実行する必要はありません。

「手動フェイルオーバー」も参照してください。

インスタンス・オブジェクト

名前付きオブジェクト。データベース・オブジェクトは1つ以上の名前付きインスタンス・オブジェクトの集合です。ブローカはこのオブジェクトを使用して、インスタンスが関連付けられているデータベースの状態を管理および制御し、このデータベース・インスタンスにインスタンス固有のプロパティを関連付けます。

インテンド状態

ブローカによる管理が有効な間のデータベース・オブジェクトのランタイム状態。

「デフォルト状態」も参照してください。

完全自動コンピューティング

操作が自動化されており、管理者による操作がほとんど、またはまったく必要ないコンピューティング装置またはソフトウェアを指します。

完全自動という語は、コンピューティング・センターが1つの部屋にあり、そこで多数のサーバーが施錠され秘密に保管されていた頃に生じたものです。通常の動作では、この部屋に管理者が入ることはなく、この部屋のすべての操作が自動化されていました。

ロジカル・スタンバイ・データベース

ロジカル・スタンバイ・データベースは、標準のOracleアーカイブREDOログ・ファイルを取得し、SQLトランザクションに再変換した後で、オープン状態のスタンバイ・データベースに適用します。変更はエンド・ユーザー・アクセスと同時に適用されますが、再生成されたSQLトランザクションを介してメンテナンスされている表で許可されるのは、ロジカル・スタンバイ・データベースのユーザーに対する読取り専用アクセスです。データベースは、再構成されたSQLトランザクションを適用できるようにオープン状態になっているため、プライマリ・データベースとは物理的に異なります。データベース表の索引や物理特性は対応するプライマリ・データベースと異なる場合がありますが、スタンバイ・データ・ソースとしてのロールを遂行するために、表はアプリケーション・アクセスの観点から論理的な一貫性を保つ必要があります。

手動フェイルオーバー

DBAが開始するフェイルオーバー。DBAは、まずフェイルオーバーが必要であることを判断してから、Enterprise ManagerでFAILOVERをクリックするか、DGMGRLのFAILOVERコマンドを発行してフェイルオーバーを起動します。手動という用語は、このタイプのフェイルオーバーとファスト・スタート・フェイルオーバーを比較する目的で使用します。

「ファスト・スタート・フェイルオーバー」も参照してください。

オブザーバ

プライマリ・データベースおよびターゲット・スタンバイ・データベースを継続的に監視し、フェイルオーバーの必要性を評価して、条件を満たしたときにファスト・スタート・フェイルオーバーを開始するDGMGRLクライアント。

フィジカル・スタンバイ・データベース

プライマリ・データベースの正確なコピーであるスタンバイ・データベース。プライマリ・データベースがオープンされてアクティブな状態で、REDO Applyによりプライマリ・データベースから受け取ったREDOデータがフィジカル・スタンバイ・データベースに適用されます。REDO Applyは、マウントされたフィジカル・スタンバイ・データベース・インスタンスで実行できます。Oracle Active Data Guardオプションのライセンスを購入済の場合は、REDO Applyをオープン状態のフィジカル・スタンバイ・データベース・インスタンスでも実行できます。詳細は、『Oracle Data Guard概要および管理』を参照してください。

プライマリ・データベース

1つ以上のスタンバイ・データベースが作成され、メンテナンスされる本番データベース。すべてのスタンバイ・データベースは、1つのプライマリ・データベースと関連付けられます。しかし、1つのプライマリ・データベースは、複数のスタンバイ・データベースをサポートできます。Oracle Data Guard Brokerモニター(DMON)は、プライマリ・データベースを使用してバイナリ構成ファイルのマスター・コピーをメンテナンスし、変更があった場合に各スタンバイ・データベースのファイル・コピーが確実に更新されるようにします。

ブローカは、グローバルで一意に定義されているDB_UNIQUE_NAME初期化パラメータの値を使用して、このデータベースを参照します。

読取り専用モード

このモードでデータベースをオープンすると、データベースの問合せは実行できますが、変更はできません。

フィジカル・スタンバイ・データベースを読取り専用でオープンすると、スタンバイ・データベースに対する問合せを実行できます。Oracle Active Data Guardオプションのライセンスを購入済の場合は、REDO Applyがアクティブなときにフィジカル・スタンバイ・データベースをオープン状態にしておくことができます。この機能はリアルタイム問合せと呼ばれます。詳細は、『Oracle Data Guard概要および管理』を参照してください。

REDO Apply

フィジカル・スタンバイ・データベースは、REDO Applyによってプライマリ・データベースとの同期が保たれます。REDO Applyでは、プライマリ・データベースから受け取ったREDOデータがリカバリされ、このREDOがフィジカル・スタンバイ・データベースに適用されます。

回復

回復とは、フェイルオーバー操作後に無効化された元のプライマリ・データベースなどのデータベースを、新規プライマリ・データベースの実行可能なスタンバイ・データベースにするプロセスです。データベースを回復するには、データベース上でフラッシュバック・データベースを有効化する必要があります。

スナップショット・スタンバイ・データベース

スナップショット・スタンバイ・データベースは、フィジカル・スタンバイ・データベースから作成される完全に更新可能なスタンバイ・データベースです。スナップショット・スタンバイ・データベースは、REDOデータを受け取りますが、スナップショット・スタンバイ・データベースがフィジカル・スタンバイ・データベースに逆変換されるまでは適用されません。

SQL Apply

ロジカル・スタンバイ・データベースは、SQL Applyによってプライマリ・データベースとの同期が保たれます。SQL Applyでは、プライマリ・データベースから受け取ったREDOのデータがSQL文に変換され、スタンバイ・データベースでこのSQL文が実行されます。

スタンバイ・データベース

プライマリ・データベースのバックアップを使用して作成されたプライマリ・データベースのコピー。各スタンバイ・データベースにはプライマリ・データベースからアーカイブREDOデータが適用され、各スタンバイ・データベースとプライマリ・データベースとの同期が保たれます。スタンバイ・データベースは、プライマリ・データベースから処理を引き継ぐことができ、ほぼ継続的なデータベースの可用性を提供します。スタンバイ・データベースには、独自のサーバー・パラメータ・ファイル、制御ファイルおよびデータファイルがあります。また、ブローカ構成ファイルのコピーがあり、プライマリ・データベース・インスタンスで実行中のDMONプロセスにより常に最新の状態に保たれます。

ブローカは、スタンバイ・データベースをDB_UNIQUE_NAME初期化パラメータに格納されているグローバルな一意名で参照します。

「ロジカル・スタンバイ・データベース」、「フィジカル・スタンバイ・データベース」および「スナップショット・スタンバイ・データベース」も参照してください。