Aller au contenu
  • Nos offres
  • Blog
  • Contact
  • Carrières
Menu
  • Nos offres
  • Blog
  • Contact
  • Carrières
Inscrivez-vous à la newsletter

Inscrivez-vous à la newsletter

Abonnez-vous maintenant et nous vous tiendrons au courant.
Nous respectons votre vie privée. Vous pouvez vous désabonner à tout moment.

Blog

  • Accueil
  • Actualités
  • Cloud
  • Infrastructure
  • Données / Sécurité
  • Intégration
  • Dev / DevOps
  • SAM / FinOps
Menu
  • Accueil
  • Actualités
  • Cloud
  • Infrastructure
  • Données / Sécurité
  • Intégration
  • Dev / DevOps
  • SAM / FinOps
  • le 07/04/2017
  • Jean-François Famechon
  • Oracle

Problème d’accès à une base de données RAC par les services.

Partager sur linkedin
Partager sur twitter
Partager sur facebook

Il vous est peut-être déjà arrivé d’avoir des problèmes d’accès à une base de données RAC en utilisant un service de base de données qui passe par le scan listener, alors que tout semble normal.
Vous avez contrôlé la validité de votre chaine de connexion, et pourtant votre outils de connexion à la base favori vous informe que le service n’est pas connu du listener.
En vous connectant sur un des serveurs du cluster, vous avez vérifié que les scan listeners étaient bien actifs :
Sous le user root, après avoir positionné l’environnement correspondant au clusterware, lancez la commande suivante :

srvctl status scan_listener

et que le service en question était bien démarré. Pour cela, sous le user oracle et après avoir positionné l’environnement correspondant à la base de données, lancez la commande suivante :

srvctl status service –d Madatabase

Lorsque l’on lance sous le user oracle, la commande lsnrctl status, le nom du service apparait bien et lorsque l’on cherche à se connecter en passant par l’adresse vip, cela fonctionne.
Il faut savoir que la commande lsnrctl renvoie les informations connues par le listener local au serveur, et non pas des scan listeners. Pour résoudre notre problème, il faut donc vérifier que les instances s’enregistrent bien au niveau du scan listener.
Pour cela, pour chaque instance, lancez la séquence de commandes suivante :

sqlplus / as sysdba
show parameter remote_listener

sur chaque serveur, la réponse doit être du type :

clustername-scan:1521

Si ce n’est pas la cas, il faut modifier la valeur du paramètre au niveau de chaque instance. Pour cela :

sqlplus / as sysdba
alter system set remote_listener='clustername-scan:1521' ;
alter system register ;

 
La base de données doit maintenant être accessible à l’aide des services définis, en passant par les scan listeners.

Jean-François Famechon
Jean-François Famechon
Voir tous ses articles

Laisser un commentaire Annuler la réponse

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Articles récents
  • Azure Database pour PostgreSQL [PaaS]
  • Azure Logic Apps : l’outil d’intégration Cloud de Microsoft
  • Purge automatique des archivelogs en PL/SQL
  • ASM et l’importance du usable_file_mb
  • Préparer un Windows Server 2003 pour une migration sur Azure

Mentions légales & Politique de confidentialité

En poursuivant votre navigation, vous acceptez l'utilisation de cookies tiers destinés à réaliser des statistiques de visites et de suivi. Accepter Refuser Personnaliser En savoir plus
Politique de confidentialité et cookies

Politique de confidentialité

Les informations collectées au travers de nos cookies sont exploitées à des fins statistiques (Google Analytics).
Google Analytics
Enregistrer & appliquer

8 JUIN 2022 A PARIS | 8H30 - 18H30

TECH FOR CLIMATE ?

Opportunités et limites de la technologie pour faire face au défi climatique

Programme & Inscriptions

Un évènement imaginé avec 🖤 par Constellation