Oracleデータベースの重要な用語の理解

本資格試験の概要ページに記載されている「Oracleデータベースの重要な用語の理解」について、Oracle データベースの基本的な動作と構造の観点から解説します。

ユーザープロセス

ユーザープロセスは、クライアントマシン上で起動するプロセスで、SQL*Plusなどのクライアントアプリケーションを起動すると生成されるプロセスです。

リスナープロセス

リスナープロセスは、データベースサーバーで起動するプロセスで、データベースサーバー上で接続要求を待ち受けるプロセスです。

ユーザープロセスがリスナープロセスに対してデータベースへの接続要求を送ります。

サーバープロセス

サーバープロセスは、データベースサーバー側で起動するプロセスで、ユーザープロセスからSQLなどの処理要求に対応する役割を持ちます。

インスタンスとデータベースファイル

接続の受付とSQLの処理を分けて考える

専用サーバー接続を例にすると、まずユーザー・プロセスがリスナーへ接続を要求します。リスナーは要求先のサービスを調べ、サーバー・プロセスへの接続を取り次ぎます。接続後はユーザー・プロセスがSQLを送り、サーバー・プロセスが処理を行って結果を返します。

つまり、リスナーは接続の入口、サーバー・プロセスはSQLの実行担当です。リスナーがSQL文を解析して表を検索するわけではありません。また、SQL*Plusはクライアント・アプリケーションなので、データベース・サーバーと同じコンピュータ上で起動しても、クライアントとして処理を依頼する役割は変わりません。

Oracle公式資料：接続とリスナーの役割

可用性を支えるRAC、ASM、Data Guard

可用性は、必要なときにシステムを利用できることを意味します。サーバーの故障、ディスクの故障、拠点の停止では影響する範囲が異なります。Oracleの関連機能も、それぞれ何を複数にするのか、何を管理するのかを分けて理解すると整理できます。

Oracle RAC：一つのデータベースを複数のインスタンスで扱う

Oracle Real Application Clusters（RAC）は、複数のサーバー上のインスタンスから、一つの共有データベースへアクセスする構成です。それぞれのインスタンスが自分のSGAとバックグラウンド・プロセスを持ち、データベース・ファイルを共有します。

例えばサーバーAとサーバーBの両方にインスタンスを置けば、処理を複数のインスタンスへ分散できます。一方のサーバーに障害が起きたときも、残った側でサービスを継続できるように構成できます。ただし、障害が起きたインスタンスに接続していた処理が、すべて無条件に途切れず続くという意味ではありません。接続やサービスの切替えも含めた構成が必要です。

RACの各SGAが一つの共有メモリーになっているわけではありません。必要なデータ・ブロックをインスタンス間の専用通信経路で受け渡す仕組みがCache Fusionです。共有データベースを複数のインスタンスで扱いながら、一貫したデータを利用できるように協調します。

問題文の「複数のインスタンスが一つのデータベースを共有する」「サーバーを追加して処理能力を拡張する」という条件は、RACを考える手掛かりです。インスタンスが複数だから、独立したデータベースのコピーも同じ数だけある、とは判断しません。

Oracle Clusterware：クラスタの資源を監視・管理する

Oracle Clusterwareは、複数サーバーをクラスタとして運用するための基盤です。サーバーやデータベース・サービスなどの資源を監視し、障害時の再起動や、別のサーバーへの切替えなどを管理します。Oracle Grid Infrastructureに含まれ、RACを支える役割を持ちます。

Clusterware自体が業務データを表として保存したり、SQLを処理したりするわけではありません。「クラスタのメンバーや資源を監視する機能」と「データベースを処理するインスタンス」を区別します。

Oracle ASM：データベース・ファイルのストレージを管理する

Oracle Automatic Storage Management（ASM）は、Oracle Databaseのファイルを保存するストレージを管理する機能です。複数のディスクをディスク・グループとしてまとめ、データファイル、制御ファイル、REDOログ・ファイルなどの配置を管理します。

機能	働き
ストライピング	ファイルの内容を複数のディスクに分散して配置し、I/Oを分散します。
ミラーリング	冗長性の設定に応じて、内容の複製を保持します。通常冗長性や高冗長性ではASMがミラーリングし、外部冗長性では外部のストレージ機能などに冗長性を委ねます。
リバランス	ディスクの追加・削除などに合わせてデータの配置を調整し、ディスク・グループ内の領域を利用しやすくします。

ASMの管理には、通常のデータベース・インスタンスとは別にASMインスタンスを使用します。ASMインスタンスが管理するのはストレージの情報で、利用者が業務表に対してSQLを実行するデータベースそのものではありません。

ASMはRAC専用ではなく、単一インスタンスのデータベースでも利用できます。また、ミラーリングは冗長性の設定によるため、「ASMを使えば、設定に関係なく必ず複数コピーを作る」とは覚えないようにします。

Oracle Data Guard：別のデータベースへ変更を送る

Oracle Data Guardは、業務を処理するプライマリ・データベースと、その変更を反映するスタンバイ・データベースを組み合わせる機能です。プライマリで生成したREDOをスタンバイへ転送し、適用することで、別のデータベースを維持します。

スタンバイを別の拠点に用意すれば、プライマリ側のサーバーだけでなく、その拠点全体が利用できなくなる障害にも備えられます。障害時にはスタンバイを新しいプライマリとして利用するフェイルオーバーを行います。計画的に役割を入れ替える操作はスイッチオーバーです。

スタンバイの種類	変更の反映方法	データの構成
フィジカル・スタンバイ	REDO Applyでブロック単位の変更を適用します。	プライマリと物理的に対応するデータベースです。
ロジカル・スタンバイ	REDOからSQLを構成し、SQL Applyで変更を適用します。	論理的に対応するデータを維持し、物理構成は同じでなくても構いません。

フィジカル・スタンバイを参照用に使うこともできます。REDOを適用しながら同時に読取り専用の問合せを実行する構成には、Oracle Active Data Guardの機能と対応するライセンスが必要です。単に「スタンバイだから常に更新を適用しながら問合せもできる」と一括りにしないようにします。

RACとData Guardを見分ける

比較する点	RAC	Data Guard
複数になるもの	一つの共有データベースに接続するインスタンス。	プライマリとスタンバイという、別々のデータベース。
データの扱い	データベース・ファイルを共有し、インスタンス間で協調します。	REDOを転送・適用して、別のデータベースへ変更を反映します。
代表的な目的	サーバー障害に備えたサービス継続、複数インスタンスによる処理分散。	別のデータベースへの切替えや、拠点災害への備え。

両者は組み合わせて使うこともできます。また、RAC、ASMのミラーリング、Data Guardのいずれも、過去の状態を残すバックアップと同じではありません。例えば誤った更新が正しく実行されれば、冗長化された側にもその変更が反映されます。サービスを続けるための仕組みと、過去の状態へ戻すための備えを合わせて考えます。

公式資料：Oracle RACの概要、Oracle Clusterwareの概要、Oracle ASMの概要、ASMインスタンスの管理、Oracle Data Guardの概要、フィジカル・スタンバイの管理

Oracleデータベースは、「インスタンス」と「データベースファイル」で構成されています。

SGAとバックグラウンドプロセス（インスタンス）

インスタンスは、Oracleデータベースの処理を担う常駐部分のことです。「システムグローバル領域（SGA:System Global Area）とバックグラウンドプロセスから構成されます。

データファイル・REDOログファイル・制御ファイル（データベースファイル）

データベースファイルは、データファイル、REDOログファイル、制御ファイルで構成されているデータベースを構成するファイルです。