Multi-instance Oracle sur une même machine

[dhtlse07]

Bonjour,

Je travaille sous Oracle 9i (AIX 5.3.5).

Sur cette machine, je dois installer la même application pour les différents entités.
Je vais donc avois trois instances Oracle (exemple : INST_A, INST_B et INST_C). Ces trois instances sont gérés par le même listener avec le numéro port 1521. J'utilise une gestion de orapasswd password file pour chaque instance (mode EXCLUSIVE).

Je souhaiterais garder le même nom de la base (DB_NAME=INST) pour ces trois instances. Mais apparammement, ça pose du problème quand tous les instances tournent avec les bases montées. Elle ne veut qu'une seule base montée à la fois en sachant que la base porte le même nom.

Est-ce qu'en ajoutant des entréees supplémentaires sur le listener.ora (port 1522, 1523 pour les deux autres ainstances), je pourrai monter mes trois bases à la fois sans changer le DB_NAME (le nom de la base) ?

Merci pour ceux qui pourraient me répondre.

[lapincretin]

Pourquoi garder le DB_NAME ?

Pourquoi ne pas faire les choses simplement ?

* Un utilisateur OS spécifique par environnement Oracle
* Un SID differents pour chaques instance
* Un listener different pour chaque instance

Pour répondre plus a tes besoins, je pense qu'un listener peut écouter plusieurs bases, il faudra rajouter les services a écouter dans le listener.ora, mais je ne pense pas que c'est possible d'avoir des doublons pour le SID (est donc pour le DB_NAME), sur un meme réseau.

A confirmer par des plus experts que moi

[13thFloor]

Pour un même user système, 3 bases => 3 noms différents (1 seul noyau installé).
Par contre, il me semble que 3 users système différents (mais même environnement : $ORACLE_HOME...) doivent pouvoir démarrer chacun une instance qui porte le même nom.
A tester.

[pifor]

D'après Tom Kyte:

• db_name peut être différent de ORACLE_SID.
• ORACLE_SID identifie l'instance (processus + mémoire partagée)
• db_name est le nom enregistré dans les fichiers de la base et peut être différent de ORACLE_SID.

Sous Unix, ORACLE_SID + ORACLE_HOME est utilisé pour générer la clé de mémoire partagée qui identifie la SGA. Donc on ne peut pas avoir sur la même machine plusieurs instances avec le même ORACLE_SID si elles partagent le même ORACLE_HOME.

[djeant]

A mon humble avis le SID (ou DB_NAME) doit être unique...
Car ça risque d'être la panique au niveau de la mémoire et du spfile.

De plus, il me semble la séparation ce fait au niveau du group et non du compte système.

J'ai fait le test suivant :
2 utilisateurs system (oracle et oracle2 tous les deux du group DBA) avec le même ORACLE_HOME, et le même ORACLE_SID=ORCL
Resultat :
je démarre l'instance ORCL avec le compte oracle,
et je peux l'arrêter avec oracle2 et la redémarrer avec oracle2

dans ces conditions, je pense que ce que suggère 13thFloor n'est pas réalisable.

Si tu veux vraiment avoir l'impression d'avoir 3 instances avec le même nom,
tu peux géré ça avec la couche SQL*Net.

Pas au niveau du listener, mais au niveau de la résolution des nom locaux (fichier tnsnames.ora).

Par exemple :

Tu crée 3 fichiers tnsnames.ora (dans des répertoires différents) avec le même alias mais qui pointent vers des instances différentes.
En suite tu positionne la variable d'environnement TNS_ADMIN vers le fichier tnsnames.ora qui te conviens.

Bon courrage

A+

[argoet]

J'ai aussi vu bon nombre de machine avec plusieurs Instances ORACLE sans aucune valeur ajoutée !!

1 seule instance avec "n" schema ORACLE faisant au final l'affaire

[pifor]

J'ai aussi vu bon nombre de machine avec plusieurs Instances ORACLE sans aucune valeur ajoutée !!

1 seule instance avec "n" schema ORACLE faisant au final l'affaire

Je suis assez d'accord sous réserve que les applications soient compatibles avec cette centralisation: si les noms des schémas ou des rôles sont codés en dur ou s'il y a des synonymes publics, il est pratiquement impossible de centraliser 2 environnements pour la même application dans la même base (par exemple: un environnement de développement et un environnement de test). Il faut aussi convaincre les responsables applicatifs que c'est possible ... Enfin, le DBA doit être prêt à restaurer un ou plusieurs schémas sans restaurer toute la base: ce qui suppose au moins de concevoir correctement la correspondance schémas/tablespaces et de pratiquer le tablespace point in time recovery.

[dhtlse07]

Bonjour,

A la fin, j'ai fini par opté de mettre en place pour chaque instance une identification unique :

* Un SID differents pour chaques instance
* Un listener different pour chaque instance
* un DB_NAME différent pour chaque instance.

La gestion du orapasswd différente pour chaque instance : j'ai mis en place la gestion par orapasswd parque j'en ai besoin pour la mise en place de base de secours par Dataguard Physique.


Merci à tous pour vos réponse.

[boussafi]

salem

je ne sais pas pourquoi une pour trois

on peut utiliser un listener pour +sieurs instance pour le gain de memoire.
Bon courage
Zoheir BOUSSAFI