データベース2026年11月6日

Oracle Database@AWSに接続できない原因と対処

結論：接続できない原因の大半はODBネットワークの経路と名前解決
エラーメッセージ別の一次切り分け
上から順に確認する切り分け手順
契約・権限・クォータ側で詰まっているケース
よくある質問
再発防止：接続設計のチェックリストとさらに学ぶには

このテーマのまとめOracle Database運用トラブルの切り分け｜障害と性能劣化このテーマのまとめRDS・Aurora運用トラブルの切り分け｜接続断と性能劣化

本記事にはプロモーション（広告）が含まれています。

Oracle Database@AWS（AWSのデータセンター内で動くOracle Exadata Database ServiceおよびAutonomous Database）を立ち上げた直後、VMクラスタの作成までは成功したのに、EC2から sqlplus を叩くと無言で固まり ORA-12170 で終わる。この詰まり方はよくあります。原因はほぼネットワーク層です。

エラーメッセージ別の一次切り分け、上から順に確認する手順、オンボーディング（Marketplaceサブスクリプション、OCIテナンシ連携、クォータ）で詰まっているケースの見分け方を整理します。

結論：接続できない原因の大半はODBネットワークの経路と名前解決

Oracle Database@AWSでは、Exadata InfrastructureとVMクラスタが「ODBネットワーク」と呼ばれる専用ネットワーク内に配置されます。利用者のVPCとは別のアドレス空間なので、VPCからアクセスするにはODBピアリング接続を張り、VPC側のルートテーブルとセキュリティグループを通す必要があります。RDS for Oracleのように同じVPCのサブネットにENIが作られるモデルとは違う点が、最初につまずく箇所です。

接続不能の原因は、おおむね次の4つに分解できます。

経路がない。ODBピアリング接続が未作成、ルートテーブルにODBネットワークCIDR向けのルートがない、セキュリティグループのアウトバウンドで1521・2484が閉じている
名前解決ができない。SCAN名（*.oraclevcn.com などの内部ドメイン）をVPC側のリゾルバで引けない
リスナーかサービス名の不一致。経路は通っているが、接続記述子のSERVICE_NAMEがPDBに存在しない、またはサービスが未起動
TLS（TCPS）の設定不足。Autonomous Databaseや2484番ポート利用時のウォレット、証明書、DN照合

1と2が大半で、3以降はオンプレやRDSと同じ切り分けで対処できます。まずはエラーコードで層を特定してください。

エラーメッセージ別の一次切り分け

ORA-12170 / TNS-12535：タイムアウト系はネットワーク経路を疑う

ORA-12170: TNS:接続タイムアウトが発生しました
TNS-12535: TNS:操作がタイムアウトしました

TCPのSYNに応答が返らない状態です。名前解決は成功してIPまで判明しているのに、パケットが戻ってこない。原因はピアリング、ルーティング、セキュリティグループ、NACLのいずれかです。リスナーが停止している場合は後述の ORA-12541（接続拒否）になるので、タイムアウトならDBプロセスより先にネットワークを見るほうが速い。

切り分けは sqlplus を使わず、素のTCPで行います。

# SCAN名を解決してIPを確認（複数IPが返るのが正常）
dig +short exa1-scan.odbnet.oraclevcn.com

# 解決できた各IPに対してTCP到達性を確認
nc -zv 10.20.1.21 1521
nc -zv 10.20.1.22 1521

nc がタイムアウトするならDBには一切届いていません。ホスト名が解決できない場合は次節の名前解決へ進んでください。

ORA-12541 / ORA-12514：経路は通っているがリスナーかサービス名が不一致

ORA-12541: TNS:リスナーがありません
ORA-12514: TNS:リスナーは接続記述子でリクエストされたサービスを現在認識していません

ORA-12541 はポートまで到達して拒否された状態で、リスナー停止かポート番号違いです。ORA-12514 はリスナーが生きていて、要求したSERVICE_NAMEが登録されていない状態。接続文字列のタイプミスか、PDBサービスの未起動・未登録のどちらかです。

DBノードにSSHできる環境なら、grid（または oracle）ユーザで次を確認します。

# SCANリスナーの状態
srvctl status scan_listener

# リスナーに登録されているサービス一覧
lsnrctl status LISTENER_SCAN1
lsnrctl services LISTENER_SCAN1

# DB/サービスの起動状態
srvctl status database -db <db_unique_name>
srvctl status service -db <db_unique_name>

SQLからの確認はこうです。PDB構成では、接続先にPDBのサービス名を指定してください。

-- CDBルートで実行
SELECT name, pdb, con_id FROM v$services ORDER BY con_id;
SELECT name, open_mode, restricted FROM v$pdbs;

PDBが MOUNTED のままだとサービスは登録されません。ALTER PLUGGABLE DATABASE <pdb> OPEN; の実行漏れや、再起動時に自動オープンさせる SAVE STATE の設定漏れもよくある原因です。

接続文字列はまずEasy Connectで最小構成を試すと切り分けが早くなります。

sqlplus admin/'<password>'@//exa1-scan.odbnet.oraclevcn.com:1521/pdb1.odbnet.oraclevcn.com

これが通るなら、tnsnames.ora 側の記述を見直します。ドメイン名の付与、SERVICE_NAME と SID の混同、sqlnet.ora の NAMES.DEFAULT_DOMAIN あたりが候補です。

ORA-28759 / ORA-29024：TCPS（2484番）利用時のウォレットと証明書

ORA-28759: ファイルのオープンに失敗しました
ORA-29024: 証明書の検証に失敗しました

Autonomous DatabaseへのmTLS接続や、Exadata側でTCPSを有効化して2484番で接続する構成では、TLSハンドシェイクの段階で失敗します。確認順は次のとおり。

WALLET_LOCATION のパスが実在し、クライアントプロセスの実行ユーザから読めるか（ORA-28759 の大半はパス誤りか権限）
ウォレット内の cwallet.sso（auto-login）が存在するか。ewallet.p12 だけだとパスワード入力を求められて失敗する
配布されたウォレットZIPを展開したパスに合わせて、sqlnet.ora の DIRECTORY を書き換えているか
ssl_server_dn_match=yes のときは、接続記述子の SSL_SERVER_CERT_DN が証明書のDNと一致しているか

# sqlnet.ora
WALLET_LOCATION = (SOURCE = (METHOD = FILE) (METHOD_DATA = (DIRECTORY = /opt/oracle/wallet)))
SSL_SERVER_DN_MATCH = yes

証明書チェーンは openssl で手早く確認できます。

openssl s_client -connect <host>:2484 -showcerts </dev/null

ハンドシェイク自体が始まらず固まる場合は、2484番がセキュリティグループで開いていないだけのこともあります。

上から順に確認する切り分け手順

ODBネットワークとVPCの経路・セキュリティ設定を確認する

AWS CLIでODBネットワークとピアリング接続の状態を確認します。サブコマンド名はCLIのバージョンで差異があるため、aws odb help で実際の一覧を見てください。

# ODBネットワークの一覧と詳細（CIDR、DNS設定を確認）
aws odb list-odb-networks --region ap-northeast-1
aws odb get-odb-network --odb-network-id <id>

# ピアリング接続の状態（ACTIVE 以外なら経路は通らない）
aws odb list-odb-peering-connections

# VM クラスタのSCAN/ホスト情報
aws odb list-cloud-vm-clusters
aws odb get-cloud-vm-cluster --cloud-vm-cluster-id <id>

ここで見るべき判断基準は4点です。

ODBネットワークのクライアントサブネットCIDRがVPCのCIDRと重複していないか。重複するとピアリングを作成できない、または作成できても戻りの経路が通りません。設計段階で分離しておきます
クライアントを置くサブネットのルートテーブルに、ODBネットワークCIDR向けのルートがあるか
EC2やLambda、ECSタスク側のアウトバウンドで1521（必要なら2484）がODBネットワークCIDRに向けて許可されているか。デフォルトのSGは全許可ですが、絞っている環境では高頻度で原因になります
ネットワークACLはステートレスなので、戻りのエフェメラルポート（1024-65535）のインバウンドを塞いでいないか

Exadata側のアクセス制御はマネージドで、ピアリングしたVPCのCIDRからの通信が許可されます。許可範囲はコンソールやCLIの出力で確認し、ドキュメントの最新仕様と突き合わせてください。

プライベートDNSの名前解決とリスナー登録状況を確認する

SCAN名はODBネットワーク側のプライベートDNSゾーン（*.oraclevcn.com 形式のドメイン）に登録されます。VPC内のクライアントがこのゾーンを引けるかが第二の関門です。

# VPCのリゾルバ（.2アドレス）経由で引けるか
dig @169.254.169.253 exa1-scan.odbnet.oraclevcn.com

# 名前解決の経路を確認
dig +trace exa1-scan.odbnet.oraclevcn.com

NXDOMAIN や SERVFAIL が返る場合、VPC側のリゾルバがODBネットワークのゾーンを知りません。対処の方向性は2つです。Route 53 Resolverの転送ルールとアウトバウンドエンドポイント、またはプライベートホストゾーンの関連付けで当該ドメインを解決できるようにします。暫定の切り分けなら、SCANのIPを /etc/hosts に書いて nc と sqlplus が通るか確認します。

/etc/hosts で接続できたなら原因はDNSで確定です。ただしSCANは複数IPを返して負荷分散とフェイルオーバーを行う仕組みなので、/etc/hosts による固定は本番運用では使わないでください。IPが1つに固定されていると、ノード障害時やパッチ適用時に接続できなくなります。

名前解決が通ったあとで ORA-12514 が出る場合は、前述の lsnrctl services と v$services でサービス登録を確認します。接続・起動まわりの一般的な切り分け手順は Oracle Database運用トラブルの切り分け｜障害と性能劣化に症状別で整理しているので、ネットワークを疑い切ったあとの調査に使えます。

この記事のテーマをさらに学べる本

Oracle Database 23cやクラウドサービスまで含めた製品全体像を図解で確認できる第6版です。

図解入門よくわかる最新Oracleデータベースの基本と仕組み［第6版］水田巴

楽天ブックスで詳しく見る Yahoo!ショッピングで見る

契約・権限・クォータ側で詰まっているケース

接続の前段として、そもそもリソースが作れない、コンソールに表示されない場合はオンボーディング側を疑います。

Oracle Database@AWSはAWS Marketplace経由（プライベートオファーを含む）で契約します。サブスクリプションが有効化されていない、あるいは Pending のままだとリソース作成が通りません
AWSアカウントとOCIテナンシのリンクが完了しているか。連携が切れていると、作成APIは受け付けられても後続の処理が失敗します
IAM権限は odb:* 系のアクションに加え、裏側の連携に必要なサービスリンクロールの作成権限が必要です。権限不足は AccessDeniedException に該当アクション名が出るので、そのままポリシーに追加するのが確実です
Exadata Infrastructureの作成可能数はリージョンごとに制限があり、初期値ではPoCに足りないことがあります。Service Quotasから引き上げを申請します
提供リージョンは順次拡大しているため、使いたいリージョンとAZで該当シェイプを選択できるか確認します

これらは「エラーが出ないのに作成が進まない」形で現れることがあります。CloudTrailでAPI呼び出しの結果を確認すると原因を絞り込めます。

よくある質問

RDS for OracleからOracle Database@AWSへ移行できる？

可能ですが、物理移行（RMANのリストア）は取りづらく、論理移行が現実的です。RDS for OracleはOSレベルのアクセスがなく、Exadata Database Serviceとはストレージ構成も異なります。実務ではData Pumpによるエクスポートとインポート、ダウンタイムを抑えたい場合はOracle GoldenGateやZero Downtime Migration（ZDM）を使った構成が候補になります。

Exadata側ではRAC、Multitenant、パーティショニング、Advanced CompressionなどExadata/EEの機能が使え、sys 権限やOSレベルの操作も可能になります。RDS for Oracleで制限されていた機能を使いたい、というのが主な移行動機です。

Data PumpやGoldenGateなど既存の運用ツールはそのまま使える？

Exadata Database Service上のOracle Databaseは通常のOracleなので、Data Pump、RMAN、GoldenGate、AWR/ASH、Enterprise Managerといった既存の運用ツールは基本的に同じ使い方ができます。注意点は3つ。

オンプレやVPC内のサーバからダンプを転送するなら、ODBピアリング経由の帯域とポートを設計に入れてください。Data Pumpの DIRECTORY はDBノードのファイルシステムを指すため、RDS for Oracleで DATA_PUMP_DIR とS3統合を組み合わせる手順とは変わります。バックアップは、Oracle側のマネージド機能と自前のRMANスクリプトのどちらで運用するかを先に決めておきます。

利用できるリージョンや課金のまとめ方は？

提供リージョンは拡大中で、選べるシェイプも変わります。課金はAWS Marketplace経由のため、Oracle側の利用料をAWSの請求書に合算できる点が運用上のメリットです。ライセンスの持ち込み（BYOL）やサポート特典の扱いは契約形態によって変わるので、金額や適用条件は最新の公式ドキュメントと見積りで確認してください。

再発防止：接続設計のチェックリストとさらに学ぶには

構築時にこの順番で確認しておくと、接続試験の段階で慌てずに済みます。

切り分けの原則は下の層から上へ。nc でTCPが通らないうちは、sqlplus の出力を読んでも時間を使うだけです。TCP到達性、名前解決、リスナー、サービス名、認証、TLSの順に一つずつ確定させてください。

接続の次は、実行計画や待機イベントを見ながらの性能チューニング、そしてPostgreSQLへの移行検討といったテーマに進みます。関連する内容は以下でまとめています。

移行先としてPostgreSQLを検討している場合、型やNULLの扱いの違いで想定外の挙動が出やすい点は Oracle PostgreSQL移行の注意点｜症状別の切り分けと対処にまとめています。

結論：接続できない原因の大半はODBネットワークの経路と名前解決

エラーメッセージ別の一次切り分け

ORA-12170 / TNS-12535：タイムアウト系はネットワーク経路を疑う

ORA-12541 / ORA-12514：経路は通っているがリスナーかサービス名が不一致

ORA-28759 / ORA-29024：TCPS（2484番）利用時のウォレットと証明書

上から順に確認する切り分け手順

ODBネットワークとVPCの経路・セキュリティ設定を確認する

プライベートDNSの名前解決とリスナー登録状況を確認する

契約・権限・クォータ側で詰まっているケース

よくある質問

RDS for OracleからOracle Database@AWSへ移行できる？

Data PumpやGoldenGateなど既存の運用ツールはそのまま使える？

利用できるリージョンや課金のまとめ方は？

再発防止：接続設計のチェックリストとさらに学ぶには

関連記事

新着記事