Oracle RAC(Real Application Clusters) 環境の構築が終わり、開発者から「tnsnames.ora の設定はどうすればいいですか？」と聞かれ、Oracle SCAN (スキャン) という聞き慣れない名前が出てきて戸惑っていませんか？
RAC 環境では、データベースのリスナーも Oracle Grid Infrastructure (GI) によってリソースとして管理されています。SCANリスナー とは何か、そして GI が管理するノード・リスナーとどう連携するのか、その仕組みを理解することが鍵となります。
この記事では、Oracle RAC への接続をシンプルにする「SCAN」の基本的な仕組みと、クライアント（アプリサーバー）に必要な tnsnames.ora の具体的な設定例を、初心者向けにわかりやすく解説します。
💰 【PR】Oracleエンジニアの市場価値、調べてみませんか？
Oracleのスキルは需要が高く、特定の資格や経験を持っていると年収が大幅にアップするケースがあります。まずはIT専門のエージェントで非公開求人をチェックしてみませんか？
この記事でわかること: SCAN 接続のための tnsnames.ora 最短設定例
Oracle RAC (19c/12c以降) 環境へ接続するための、最も標準的な tnsnames.ora の設定です。クライアントはこの設定ファイル（または同等の接続文字列）を使います。
# "V19RAC" は任意の接続識別子
V19RAC =
(DESCRIPTION =
# HOST にはクラスタの「SCAN名」を指定する
(ADDRESS = (PROTOCOL = TCP)(HOST = v19rac-scan)(PORT = 1521))
(CONNECT_DATA =
# SID ではなく「サービス名」を指定する
(SERVICE_NAME = v19rac)
)
)
ポイント:
CONNECT_DATA:SIDではなく、DBA が RAC 上で定義したSERVICE_NAMEを指定します。HOST: ノード名ではなく、クラスタの代表名である SCAN 名 を指定します。
■1 つめのセッション
[oracle@v19rac2 admin]$ cat tnsnames.ora
# tnsnames.ora Network Configuration File: /u01/app/oracle/product/19.0.0/dbhome_1/network/admin/tnsnames.ora
# Generated by Oracle configuration tools.
V19RAC =
(DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP)(HOST = v19rac-scan)(PORT = 1521))
(CONNECT_DATA =
(SERVER = DEDICATED)
(SERVICE_NAME = v19rac)
)
)
[oracle@v19rac2 admin]$ sqlplus system/oracle@v19rac
SQL*Plus: Release 19.0.0.0.0 - Production on 日 11月 16 01:12:19 2025
Version 19.3.0.0.0
Copyright (c) 1982, 2019, Oracle. All rights reserved.
Oracle Database 19c Enterprise Edition Release 19.0.0.0.0 - Production
Version 19.3.0.0.0
に接続されました。
SQL> set lin 1000
SQL> col instance_name for a20
SQL> select instance_name,status from v$instance;
INSTANCE_NAME STATUS
-------------------- ------------------------------------
v19rac1 OPEN
~~~~~~~★ノード 1
■2 つめのセッション
[oracle@v19rac2 ~]$ sqlplus system/oracle@v19rac
SQL*Plus: Release 19.0.0.0.0 - Production on 日 11月 16 01:14:01 2025
Version 19.3.0.0.0
Copyright (c) 1982, 2019, Oracle. All rights reserved.
Oracle Database 19c Enterprise Edition Release 19.0.0.0.0 - Production
Version 19.3.0.0.0
に接続されました。
SQL> set lin 1000
SQL> col instance_name for a20
SQL> select instance_name,status from v$instance;
INSTANCE_NAME STATUS
-------------------- ------------------------------------
v19rac2 OPEN
~~~~~~~★ノード 2
Oracle SCAN (Single Client Access Name) とは？
SCAN は “Single Client Access Name” の略で、その名の通り、Oracle RAC クラスタ全体への 「単一の（Single）」「クライアント（Client）」「接続窓口（Access Name）」 です。
技術的には、DNS サーバーに登録された「1つのホスト名」であり、この名前に複数のIPアドレス（通常3つ）が紐づいています。
なぜ SCAN が必要なのか？
SCAN が導入される前（11g R1 以前）は、RAC へ接続するために tnsnames.ora にクラスタを構成する全ノードの VIP (仮想IP) を列挙する必要があり、管理が煩雑でした。
- 古い方式の問題点: ノードを追加・削除するたびに、全クライアントの
tnsnames.oraを修正する必要がありました。
SCAN は、この問題を解決します。
SCAN のメリット:
クライアントは「SCAN 名」というクラスタの代表名さえ知っていれば良いため、クラスタ側でノードが何台に増減しようとも、クライアント側の tnsnames.ora を一切変更する必要がなくなりました。
SCAN リスナーとノード・リスナー: Grid Infrastructure による管理
Oracle RAC 環境では、SCAN リスナーも、各ノードで稼働する「ノード・リスナー」も、単体で動作しているわけではありません。これらはすべて Oracle Grid Infrastructure (GI) の一部である Oracle Clusterware によって「リソース」として自動管理されています。
- GI が管理する: 起動、停止、ノード障害時のフェイルオーバー（別ノードでの再起動）はすべて GI が自動で行います。
srvctlで制御: このため、lsnrctl start/stopといった古いコマンドでリスナーを制御するのではなく、srvctl start scan_listenerやsrvctl stop listenerといったsrvctlコマンドを使ってリソースとして制御するのが正しい作法です。listener.oraの場所: パラメータファイル (listener.ora) も、DB Home ではなく Grid Home (/u01/app/19.0.0/grid/network/admin/など) 配下に配置され、GI によって管理されます。
この2種類のリスナーの役割分担は以下の通りです。
- SCAN リスナー (受付・振り分け係):
- SCAN 名に紐づく「SCAN VIP」上で動作します。
- クライアントからの最初の接続要求を受け付けます。
- その時点でクラスタ内で最も負荷の低いノード（のノード・リスナー）を選び出し、その情報をクライアントに返します（リダイレクト）。
- ノード・リスナー (実際の接続担当):
- 各ノードの VIP 上で動作します（リソース名は
ora.LISTENER.lsnrなど）。 - SCAN リスナーから紹介（リダイレクト）されたクライアントからの接続要求を受け取り、担当ノードの DB インスタンスに接続を確立させます。
- 各ノードの VIP 上で動作します（リソース名は
【SCAN 接続の簡単な流れ】
(1) クライアント
「DNS さん、"v19-scan" の IP 教えて」
↓
(2) DNS
「はいよ。192.168.10.101 (SCAN VIP-1) ね」
↓
(3) クライアント
「192.168.10.101 (SCAN リスナー) さん、"v19rac_srv" に接続したい」
↓
(4) SCAN リスナー (ノード2で稼働中)
「OK。今ノード1が暇そうだから、"v19rac1-vip" (ノード1のVIP) に繋いでね」
↓
(5) クライアント
「"v19rac1-vip" (ノード・リスナー) さん、"v19rac_srv" に接続したい」
↓
(6) ノード・リスナー (ノード1)
「OK。DB インスタンス1 に繋ぎます」
↓
(7) 接続完了！
💰 【PR】Oracleエンジニアの市場価値、調べてみませんか？
Oracleのスキルは需要が高く、特定の資格や経験を持っていると年収が大幅にアップするケースがあります。まずはIT専門のエージェントで非公開求人をチェックしてみませんか？
srvctl と lsnrctl によるリスナーの確認
リスナーは GI リソースであるため、制御は srvctl、詳細確認は lsnrctl と使い分けるのが基本です。
1. srvctl による制御と稼働状況の確認
srvctl は、リソースが「クラスタ内のどのノードで稼働すべきか/しているか」を管理・確認するコマンドです。
# grid ユーザーで実行
# 全 SCAN リスナーの状態と稼働ノードを確認
$ srvctl status scan_listener
SCAN Listener LISTENER_SCAN1 is enabled
SCAN Listener LISTENER_SCAN1 is running on node v19rac2
SCAN Listener LISTENER_SCAN2 is enabled
SCAN Listener LISTENER_SCAN2 is running on node v19rac1
SCAN Listener LISTENER_SCAN3 is enabled
SCAN Listener LISTENER_SCAN3 is running on node v19rac1
実行結果の補足:
srvctl は、SCAN リスナーがクラスタ全体に分散して稼働していることを示します。
2. lsnrctl による詳細ステータスの確認
lsnrctl status は、指定したリスナーが「具体的にどの IP/ポートで」「どのサービスを」待ち受けているか、詳細を確認するコマンドです。
# grid ユーザーで実行
$ lsnrctl status LISTENER_SCAN1
[grid@v19rac1 ~]$ lsnrctl status LISTENER_SCAN1
LSNRCTL for Linux: Version 19.0.0.0.0 - Production on 16-11月-2025 01:07:45
Copyright (c) 1991, 2019, Oracle. All rights reserved.
(DESCRIPTION=(ADDRESS=(PROTOCOL=IPC)(KEY=LISTENER_SCAN1)))に接続中
リスナーのステータス
------------------------
別名 LISTENER_SCAN1
バージョン TNSLSNR for Linux: Version 19.0.0.0.0 - Production
開始日 16-11月-2025 00:39:30
稼働時間 0 日 0 時間 28 分 15 秒
トレース・レベル off
セキュリティ ON: Local OS Authentication
SNMP OFF
パラメータ・ファイル /u01/app/19.0.0/grid/network/admin/listener.ora
ログ・ファイル /u01/app/grid/diag/tnslsnr/v19rac1/listener_scan1/alert/log.xml
リスニング・エンドポイントのサマリー...
(DESCRIPTION=(ADDRESS=(PROTOCOL=ipc)(KEY=LISTENER_SCAN1)))
(DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=192.168.56.54)(PORT=1521)))
サービスのサマリー...
サービス"v19rac"には、2件のインスタンスがあります。
インスタンス"v19rac1"、状態READYには、このサービスに対する1件のハンドラがあり ます...
インスタンス"v19rac2"、状態READYには、このサービスに対する1件のハンドラがあり ます...
サービス"v19racXDB"には、2件のインスタンスがあります。
インスタンス"v19rac1"、状態READYには、このサービスに対する1件のハンドラがあり ます...
インスタンス"v19rac2"、状態READYには、このサービスに対する1件のハンドラがあり ます...
コマンドは正常に終了しました。
[grid@v19rac1 ~]$
実行結果の補足:
この出力から、以下の重要な事実がわかります。
- GI 管理の証拠:
パラメータ・ファイルのパスが DB Home ではなく Grid Home (/u01/app/19.0.0/grid/) になっており、GI リソースであることがわかります。 - SCAN VIP で待機:
HOST=192.168.56.54(SCAN VIP の一つ) で待機しています。 - クラスタ全体を認識:
v19rac1で稼働しているLISTENER_SCAN1が、v19rac1とv19rac2の両方のインスタンスの状態をREADYとして認識しています。これが、SCAN リスナーが負荷分散（リダイレクト）を行える理由です。
トラブルシューティング: SCAN 接続でよくあるエラー
| ORA-エラー例 | 原因の推測 | 確認・対処法 |
ORA-12545: Connect failed because target host... | DNS で SCAN 名が解決できない。 | クライアント側で nslookup <scan-name> を実行し、IP が返るか確認。返らない場合、DNS 設定を見直す。 |
ORA-12541: TNS:no listener | SCAN VIP または SCAN リスナーが停止している。 | サーバー側 (grid ユーザー)で srvctl status scan および srvctl status scan_listener を実行し、running 状態か確認。 |
ORA-12514: TNS:listener does not currently know of service | tnsnames.ora の SERVICE_NAME が間違っている。 | DB 側で正しいサービス名を確認する。または、サービスがリスナーに登録されていない（srvctl status service でサービスが起動しているか確認）。 |
Oracle SCAN に関する FAQ
Q. SCAN IP はなぜ3つ推奨なのですか？
A. 高可用性（HA）のためです。もし SCAN VIP が1つだけだと、その VIP が稼働するノードが停止した場合、クラスタ全体が稼働していても最初の接続（受付）ができなくなります。3つに分散することで、1ノード（または2ノード）が停止しても、残りの SCAN VIP/リスナーが接続要求を受け付けられます。
Q. tnsnames.ora に SCAN 名ではなく、ノードの VIP を直接書いてもいいですか？
A. 技術的には可能ですが、非推奨です。そのノードが停止した場合、フェイルオーバーが正しく機能しない（または遅延する）可能性があります。また、ノード追加時に tnsnames.ora の修正が必要になるなど、SCAN のメリットをすべて放棄することになります。
Q. lsnrctl status を実行したら SCAN リスナーが出てきません。
A. lsnrctl status (引数なし) は、デフォルトで LISTENER という名前の「ノード・リスナー」の状態を表示しようとします。SCAN リスナーは LISTENER_SCAN1 のような別名で、かつ Grid Infrastructure (GI) 管理下で動作しています。状態確認は grid ユーザーで srvctl status scan_listener を使うか、lsnrctl status LISTENER_SCAN1 のようにリスナー名を明示的に指定してください。
まとめ
Oracle RAC への接続における SCAN の役割は非常に重要です。
- RAC 環境のリスナーは、Grid Infrastructure (GI) によってリソースとして自動管理されます。
- SCAN は、RAC クラスタ全体への単一の接続窓口（代表名）です。
- SCAN を使うことで、クライアントはノードの増減や構成変更を意識する必要がなくなります。
- 「SCAN リスナー（受付）」が「ノード・リスナー（接続担当）」へリダイレクト（振り分け）を行います。
tnsnames.oraにはHOST=<scan-name>とSERVICE_NAME=<service-name>を指定するのが 19c での標準設定です。
本記事は Oracle Database 19c を対象に解説します（他バージョンは画面や既定値が異なる場合があります）。
💰 【PR】Oracleエンジニアの市場価値、調べてみませんか？
Oracleのスキルは需要が高く、特定の資格や経験を持っていると年収が大幅にアップするケースがあります。まずはIT専門のエージェントで非公開求人をチェックしてみませんか？
コメント