Discussion :

[vincentmen75017]

Bonjour a tous,
Specs de notre infra:
Oracle RAC 12.1.0.2 avec 2 noeuds Windows 2016 server. Chaque bdd (3 au total) dispose d'une pluggable databases dans lequel sont stockés les données finales. On se connecte au cluster (donc aux bdd) sur une VIP les 2 noeuds étant actif/actif.

Nous avons une application (IIS) sur un autre serveur dans le même réseau que le cluster Oracle et la connexion depuis IIS sur la VIP du cluster fonctionne correctement (port 1521).

Voici notre problème:
Nous tentons de donner accès aux pluggables depuis l'exterieur (une autre société).
Pour cela, nous avons ouvert sur notre firewall et sur le firewall de l'autre société les ports 1521 en entrée/sortie et (je sais que ça n'a pas de sens mais cétait pour etre sur) la range de port 20000 - 80000.
Nous avons aussi créé de notre côté une NAT IP pour résoudre notre adresse IP public sur la VIP du cluster Oracle.
Concrètement l'autre société se connecte en utilisant les infos suivantes:
sqlplus user/pass@NotreIpPublic:1521/database. Une fois arrivé sur notre firewall l'adresse NotreIpPublic est traduite par l'@Ip de la VIP du cluster (je ne suis pas un expert mais c'est ce que j'ai compris).

Le problème c'est que lorsque l'autre société tente de se connecter à une pluggable database ils obtiennent l'erreur : "I/O network adapter could not establish the con vendor code 17002".
S'ils tentent de se connecter à l'instance (donc à la Container database ça passe):
CDBuser/pass@Notre@IpPublic:1521/containerDB -> Ok
PDBuser/pass@Notre@IpPublic:1521/pluggableDB -> KO -> avec l'erreur ci-dessus.

Nous avons essayé avec un tnsnames mais c'est pareil.

Voici l'output de notre lsnrctl stat:
race level user

Security ON: Local OS Authentication

SNMP OFF

...

RÚcapitulatif d'Úcoute des points d'extrÚmitÚ...

(DESCRIPTION=(ADDRESS=(PROTOCOL=ipc)(PIPENAME=\\.\pipe\LISTENER_SCAN3ipc)))

(DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=xxxx)(PORT=1521)))

RÚcapitulatif services...

Le service "-MGMTDBXDB" comporte 1 instance(s).

L'instance "-mgmtdb", statut READY, comporte 1 gestionnaire(s) pour ce service...

Le service "_mgmtdb" comporte 1 instance(s).

L'instance "-mgmtdb", statut READY, comporte 1 gestionnaire(s) pour ce service...

Le service "xxxx" comporte 1 instance(s).

L'instance "-mgmtdb", statut READY, comporte 1 gestionnaire(s) pour ce service...

Le service "PLUGGABLE1" comporte 2 instance(s).

L'instance "CDBx_1", statut READY, comporte 1 gestionnaire(s) pour ce service...

L'instance "CDBx_2", statut READY, comporte 1 gestionnaire(s) pour ce service...

Le service "PLUGGABLE2" comporte 2 instance(s).

L'instance "CDBy_1", statut READY, comporte 1 gestionnaire(s) pour ce service...

L'instance "CDBy_2", statut READY, comporte 1 gestionnaire(s) pour ce service...

Le service "PLUGGABLE3" comporte 2 instance(s).

L'instance "CDBz_1", statut READY, comporte 1 gestionnaire(s) pour ce service...

L'instance "CDBz_2", statut READY, comporte 1 gestionnaire(s) pour ce service...

Le service "CDBx" comporte 2 instance(s).

L'instance "CDBx_1", statut READY, comporte 1 gestionnaire(s) pour ce service...

L'instance "CDBx_2", statut READY, comporte 1 gestionnaire(s) pour ce service...

Le service "CDBxXDB" comporte 2 instance(s).

L'instance "CDBx_1", statut READY, comporte 1 gestionnaire(s) pour ce service...

L'instance "CDBx_2", statut READY, comporte 1 gestionnaire(s) pour ce service...

...

La commande a rÚussi


Le contenu de notre SQLNET.ora:
SQLNET.AUTHENTICATION_SERVICES= (NTS)

NAMES.DIRECTORY_PATH= (TNSNAMES, EZCONNECT)

ADR_BASE = C:\app\grid\12.1.0\grid\log

SQLNET.INBOUND_CONNECT_TIMEOUT=120


Pour information, dans les traces de notre listener, nous voyons bien les connexions arriver, et celles-ci sont toujours "Established" exemple:
date * (CONNECT_DATA=(CID=(PROGRAM=SQL Developer)(HOST=__jdbc__)(USER=OSuser))(SERVICE_NAME=PLUGGABLEDB)) * (ADDRESS=(PROTOCOL=tcp)(HOST=@ipsociété)(PORT=62316)) * establish * PLUGGABLEDB * 0
Pas d'erreur du coup.
Et lorsque l'on se connecte sur la CDB avec succès donc on a le même type de retour:
date * (CONNECT_DATA=(SID=CDB)(CID=(PROGRAM=SQL Developer)(HOST=__jdbc__)(USER=OSuser))) * (ADDRESS=(PROTOCOL=tcp)(HOST=@Ipdelasociété)(PORT=49631)) * establish * CDB_2 * 0



Auriez-vous des idées?

Par avance merci!

[vanagreg]

Bonjour,

Avec quel outil essaient-ils de se connecter?

[vincentmen75017]

On est avec SQLDevelopper v19.

La connexion a la pluggable est faite en utilisant le menu (coché) service_name. La connexion à la containerdb est faite avec la coche sur SID.
Pour info si je remonte la coche sur SID en précisant la pluggable ou que je saisi un SID non existant j'ai bien le retour dans mes logs et dans le prompt sqldev que le listener ne connait pas actuellement le service demandé.