はじめに

Oracle Real Application Clusters (RAC)の構築において、クライアント接続を管理するために重要となる「SCAN (Single Client Access Name)」と「サービス接続」の機能と役割について解説します。

SCANの一部であるSCANリスナーは、クライアントからの接続リクエストを受け付け、クラスタ内の適切なデータベース・インスタンスへリダイレクトし、負荷分散を実現します。これにより、通常のリスナーとの役割分担を明確にし、より効率的な運用を目指します。

目次

SCANリスナーとは 　　-SCAN概要 　　-SCANリスナーの役割 　　　-DNSラウンドロビン 　　-SCANリスナーのまとめ 　データベース・サービス接続 　　-データベースサービス接続の位置づけ 　　-デフォルトで存在するサービス 　　-Oracleクライアントからの接続 　　-データベース・サービスの利点 　　　-Database Resource Managerでの利点 　　　-パフォーマンス分析での利点

SCANリスナーとは

SCAN概要

Oracle Database RAC 11g R2以降では、各ノードのOracle Grid Infrastructure(GI)が管理するローカル・リスナーとは別に、クラスタリソースとして次の要素がセットで起動します。

• SCANリスナー : 接続リクエストをリダイレクトする専用のリスナー
  
• SCAN VIP: SCANリスナーに対応するSCANの仮想IPアドレス

これらは可用性向上のために複数起動し、SCAN VIPのIPアドレスはDNSで1つのホスト名に対応付けられます。SCANリスナーが起動しているノードで障害が発生した場合、SCANリスナーとSCAN VIPは別の正常ノードにフェイルオーバーします。

SCANを利用するためには、初期化パラメータ「remote_listener」にSCANホスト名とSCANリスナーのポート番号を指定します。通常「local_listener」はインスタンス起動後に動的に設定されます。

SCANリスナーの役割

SCANリスナーを利用する構成では、Oracleインスタンスは自身のローカル・ノードのOracleリスナーに加え、SCANリスナーにも担当サービスを登録します。これにより、SCANリスナーはクラスタ内の全インスタンスの負荷状況や提供サービスを統合的に把握します。

• SCANリスナー: リダイレクト専用。インスタンスの負荷状況や提供サービスの情報をもとに、接続要求を最適なノードのローカル・リスナーへ振り分けます。

• ローカル・リスナー: 実際のセッション確立を担当します。

DNSラウンドロビン

SCANを利用するためには、1つのSCANホスト名に対して複数のSCAN VIPをDNSで登録する必要があります。この仕組みはDNSの「ラウンドロビン」と呼ばれます。

SCANリスナーのまとめ

• SCANリスナーは、接続要求を適切なローカル・リスナーへリダイレクトする機能です。
• 実際のセッション確立と通信は、各ノード上のローカル・リスナー（通常のリスナー）が担います。
• SCANを利用するためには、DNSのラウンドロビン機能が必要です。これによりクライアントは複数のSCAN VIPのいずれかに接続を試みます。
• データベース初期化パラメータlocal_listenerおよびremote_listenerが設定されることで、SCANによる接続リダイレクトとサーバサイド・ロード・バランシングが有効になります。

データベース・サービス接続

データベース・サービス接続の位置づけ

Oracle Real Application Clusters (RAC) 環境において、クライアントがデータベースへ接続する際の複雑さを抽象化し、透過的な接続を実現するのがデータベース・サービス接続です。この仕組みにより、クライアントは接続先のデータベースがRACの複数ノード構成であるかどうかを意識することなく、一貫してデータベース・サービス名を指定して接続します。

デフォルトで存在するサービス

データベース・サービス接続を利用するOracle環境では、ユーザーが任意に追加するサービスとは別に、デフォルトで存在するいくつかのサービスがあります。これらのサービスは、ワークロードの区別やパフォーマンス分析の基礎情報として重要な役割を果たします。

• ワークロードの区別: V$SERVICE_STATSなどのビューにより、サービスごとのワークロードが区別・統計管理されています。
• サービスの種別: Oracleリスナーに登録されるサービスとは別に、内部的なサービスも存在し、すべてデータ・ディクショナリ上でも区別されています。

サービス名	Oracleリスナーへの登録	データ・ディクショナリ
追加したサービス	登録される	ワークロード分別
DB_UNIQUE_NAME（と同じ値） データベース名を基にしたデフォルト・サービス	登録される	ワークロード分別
SYS$USERS サービス名を持たないセッションのサービス	登録されない	ワークロード分別
SYS$BACKGROUND バックグラウンド・プロセスが属するサービス	登録されない	ワークロード分別

Oracleクライアントからの接続

OracleクライアントがRACデータベースに接続するための記述（tnsnames.ora等）は、基本的にはシングル・インスタンスの場合と同様です。

• ADDRESS: SCANホスト名とSCANポート番号を指定します。
• SERVICE_NAME: 接続先のデータベース・サービス名を指定します。

これにより、クライアントは背後のノード構成（何台のサーバーがあるか）を意識することなく、一つのSCAN名を通じてデータベースにアクセスできます。

データベース・サービスの利点

データベース・サービスを用途ごとに分けて使用ノード（インスタンス）を振り分けることで、OSリソース（CPUやメモリ）を効率的に活用できます。
業務ごとにサービスを分離しておくと、Database Resource Managerによるリソース制御や、AWR／EMCCを用いたパフォーマンス分析が容易になります。

Database Resource Managerでの利点

Database Resource Manager（Enterprise Editionで利用可能）によるリソース制御の単位には様々な指定方法がありますが、DBインフラの観点からは、データベース・サービス名で絞り込むことが最も容易です。例えば、ユーザ名などは入れ替えや変更が発生しやすく、その都度設定を見直す必要があるため、運用管理が煩雑になりがちです。

• リソース制御可能な単位の例
  
  • Oracle Databaseのユーザー名
  • Oracle Databaseのサービス名
  • クライアントが接続元にするコンピュータ名
  • ログインしたクライアントのオペレーティング・システムのユーザー名
  • サーバーにログインするために使用したクライアント・プログラム名

Resource Managerにサービス名を登録する例

begin
dbms_resource_manager.set_consumer_group_mapping (
attribute => DBMS_RESOURCE_MANAGER.SERVICE_NAME,
value => 'SERVICE_1',
consumer_group => 'GROUP1');
end;
/

begin
dbms_resource_manager.set_consumer_group_mapping (
attribute => DBMS_RESOURCE_MANAGER.SERVICE_NAME,
value => 'AP',
consumer_group => 'GROUP2');
end;
/

パフォーマンス分析での利点

データベース・サービスを利用することで、ワークロード分析が容易になります。前項で述べた通り、業務用途に応じてサービスを分割しているため、サービス単位という大きな枠組みでの評価が可能です。

AWRレポート抜粋

Service Statistics DB/Inst: ORCL/orcl1 Snaps: 6948-6949
-> ordered by DB Time

Physical Logical
Service Name DB Time (s) DB CPU (s) Reads (K) Reads (K)
---------------------------- ------------ ------------ ------------ ------------
SERVICE_1 4,192 2,433 5,566 445,638
SYS$USERS 5 5 0 22
SYS$BACKGROUND 1 1 1 2,266
orcl 0 0 0 0
------------------------------------------------------

Service Wait Class Stats DB/Inst: ORCL/orcl1 Snaps: 6948-6949
-> Wait Class info for services in the Service Statistics section.
-> Total Waits and Time Waited displayed for the following wait
classes: User I/O, Concurrency, Administrative, Network
-> Time Waited (Wt Time) in seconds

Service Name
----------------------------------------------------------------
User I/O User I/O Concurcy Concurcy Admin Admin Network Network
Total Wts Wt Time Total Wts Wt Time Total Wts Wt Time Total Wts Wt Time
--------- --------- --------- --------- --------- --------- --------- ---------
SERVICE_1
5570695 1565 715 0 0 0 6158168 6
SYS$USERS
761 0 427 0 0 0 1695 0
SYS$BACKGROUND
7281 5 8546 0 0 0 0 0
orcl
0 0 0 0 0 0 0 0
------------------------------------------------------

まとめ

SCANリスナーは接続のリダイレクトと負荷分散を担い、ローカル・リスナーはセッション確立を担うという明確な役割分担により、クライアント接続の可用性と効率性が向上します。また、データベース・サービス接続を利用することで、RACの透過性を保ちつつ、Database Resource ManagerやAWRによるサービスごとの詳細なリソース管理・ワークロード分析が可能になります。これらの機能は、大規模システムにおけるOracle RACの安定運用に不可欠です。