Discussion :

[CinePhil]

Bonjour,

J'ai fini par réussir à cloner une base sur le même serveur, à y accéder par sql Developer et même à y passer des patches SQL par ce même moyen.

J'ai modifié les paramètres d'une application pour qu'elle s'adresse à cette nouvelle base et j'obtiens un méchant message d'erreur dans les logs de l'application qui, bien sûr, ne fonctionne pas :

ORA-12505, TNS:listener does not currently know of SID given in connect descriptor.

Une recherche sur le net m'a orienté vers la modification de mes fichiers listener.ora et tnsnames.ora. Si je comprends bien ce qu'il y a dans sqlnet.ora, c'est le tnsnames qui est pris en compte.
Le voici :

# tnsnames.ora Network Configuration File: /Bases/oracle/product/11.2.0/dbhome_1/network/admin/tnsnames.ora
# Generated by Oracle configuration tools.

COCKTAILTEST =
(DESCRIPTION =
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = TCP)(HOST = 172.26.1.54)(PORT = 1521))
)
(CONNECT_DATA =
(SERVICE_NAME = cocktail)
)
)

CKTL =
(DESCRIPTION =
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = TCP)(HOST = 172.26.1.54)(PORT = 1521))
)
(CONNECT_DATA =
(SERVICE_NAME = cktl)
)
)

SCOLTEST =
(DESCRIPTION =
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = TCP)(HOST = 172.26.1.54)(PORT = 1521))
)
(CONNECT_DATA =
(SERVICE_NAME = scoltest)
)
)

RHTEST =
(DESCRIPTION =
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = TCP)(HOST = 172.26.1.54)(PORT = 1521))
)
(CONNECT_DATA =
(SERVICE_NAME = rhtest)
)
)

La nouvelle base est RHTEST mais elle n'est pas prise en compte, malgré un redémarrage du serveur, si j'en crois le résultat de lsnrctl status :

LSNRCTL for Linux: Version 11.2.0.1.0 - Production on 22-NOV. -2016 17:58:07

Copyright (c) 1991, 2009, Oracle. All rights reserved.

Connexion à (ADDRESS=(PROTOCOL=tcp)(HOST=)(PORT=1521))
STATUT du PROCESSUS D'ECOUTE
------------------------
Alias LISTENER
Version TNSLSNR for Linux: Version 11.2.0.1.0 - Production
Date de départ 22-NOV. -2016 16:50:48
Durée d'activité 0 jours 1 heures 7 min. 18 sec
Niveau de trace off
Sécurité ON: Local OS Authentication
SNMP OFF
Fichier de paramètres du processus d'écoute /Bases/oracle/product/11.2.0/dbhome_1/network/admin/listener.ora
Fichier journal du processus d'écoute /Bases/oracle/diag/tnslsnr/linoratest/listener/alert/log.xml
Récapitulatif d'écoute des points d'extrémité...
(DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=linoratest.enfa.fr)(PORT=1521)))
Récapitulatif services...
Le service "cktl" comporte 1 instance(s).
L'instance "cktl", statut READY, comporte 1 gestionnaire(s) pour ce service...
Le service "cocktail" comporte 1 instance(s).
L'instance "cocktail", statut READY, comporte 1 gestionnaire(s) pour ce service...
Le service "formgfc" comporte 1 instance(s).
L'instance "formgfc", statut READY, comporte 1 gestionnaire(s) pour ce service...
Le service "scoltest" comporte 1 instance(s).
L'instance "scoltest", statut READY, comporte 1 gestionnaire(s) pour ce service...
La commande a réussi

Qu'est-ce qui cloche ?

[CinePhil]

Ce matin, donc après avoir modifié hier les fichiers tnsnames.ora et listener.ora, je n'arrive plus non plus à me connecter à la nouvelle base via sql developer.

Qu'est-ce qui manque dans ma configuration ?
Y a t-il une autre liste de bases à activer au démarrage d'Oracle ?

[CinePhil]

J'ai fini par comprendre que c'est le MEMORY TARGET qui plante parce que /dev/shm n'est pas assez gros.

J'ai arrêté une autre base moins utile et démarré la nouvelle ; ça fonctionne.

Il me reste à trouver comment augmenter le /dev/shm pour permettre à toutes les bases de démarrer.

[13thFloor]

Il me reste à trouver comment augmenter le /dev/shm pour permettre à toutes les bases de démarrer.

Ou réduire le MEMORY TARGET pour que la somme des SGA tienne dans la valeur définie par /dev/shm

[CinePhil]

Mais est-ce que ça ne risque pas de nuire à la performance de la ou des bases, même s'il ne s'agit que d'un serveur de test ?

[13thFloor]

L'effet négatif devrait être minime, sauf si la réduction est considérable (50% par exemple).
Autre solution : ne pas utiliser l'AMM (Automatic Memory Management), renseigner PGA_AGGREGATE_TARGET et SGA_TARGET et utiliser les hugepages (si linux).
Dans certains cas, l'AMM est pénalisant car oracle gère lui-même ses besoins en mémoire pour les différentes zones (cache, shared pool...) et augmente régulièrement la partie cache sql au détriment du cache des datas.
A tester dans ton cas.

[IndianaAngus]

Il me reste à trouver comment augmenter le /dev/shm pour permettre à toutes les bases de démarrer.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

mount -o remount,size=100% /dev/shm

Comme cela, /dev/shm sera égale à votre RAM

[CinePhil]

Il n'y avait que 1 Go de RAM sur ce serveur (machine virtuelle) pour 2 Go de /dev/shm. J'ai fait monter la RAM à 3 Go et appliqué la solution proposée par IndianaAngus :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

mount -o remount,size=100% /dev/shm

Mais ma nouvelle base ne démarre toujours pas car c'est la dernière à démarrer.

Je voudrais explorer la solution suivante :

Ou réduire le MEMORY TARGET pour que la somme des SGA tienne dans la valeur définie par /dev/shm

Comment puis-je faire cela ?

Autre idée : changer l'ordre de démarrage des bases pour placer la base de test moins utile (et même quasiment inutilisée) en dernier afin que ce soit moins gênant si elle ne démarre pas. Comment puis-je faire ça, sachant que ma nouvelle base (rhtest) n'est pourtant pas en dernière position dans tnsnames.ora ?