L’une des plus grandes nouveautés d’Oracle 12c est probablement le multitenant, et c’est aussi celle qui effraye le plus, car elle bouleverse pas mal les vieux réflexes des DBA endurcis, habitués à ne trouver qu’une seule base derrière une instance.
Pour les accès distants, à partir d’un client, le multitenant est quasiment transparent, si toutefois vous respectez les deux règles suivantes :
1 – spécifiez dans vos TNSNAMES.ORA uniquement le SERVICE_NAME, et non le SID.
2 – les chaines de connection JDBC doivent respecter la syntaxe du type :
jdbc:oracle:thin@//<hostname <port>/<service_name> ,
et non plus :
jdbc:oracle:thin@<hostname>:<port>:<sid>
En multitenant, et en local sur le serveur, la traditionnelle commande « sqlplus / as sysdba » ne vous permet plus de vous connecter directement sur votre base de données favorite, mais sur la CDB (container database) qui l’héberge.
Pour vous connecter sur votre base favorite, il vous faut,
- soit fournir la chaîne de connexion complète à votre base
ex:sqlplus sys/<password>@<host>:<port>/<service_name>, -
soit vous connecter à la CDB (sqlplus / as sysdba), puis vous connecter à votre base en mentionnant son nom de container comme ceci :
alter session set container = <nom de votre base> ;
Attention cette commande de changement de container nécessite l’attribution du privilège SET CONTAINER si vous vous connectez avec un login autre que SYS.
Maintenant, imaginez autour de votre base de données toute une série de scripts et de traitements batch, qui, tous, font des CONNECT <login>/<password> ou des CONNECT / (authentification OS), ou pire encore …
Ces instructions de connexion aux bases sont codées en dur dans des programmes dont vous ne disposez plus des sources !!!
Dans tous ces cas, la connexion à votre base est tout simplement impossible, sauf en modifiant toutes vos chaines de connexion, ce qui n’est malheureusement pas toujours simple ni possible !
Alors voici pour vous réconcilier avec le multitenant, et vous convaincre qu’il n’est pas aussi compliqué que ça, une astuce simple et efficace, qui devrait vous permettre de retrouver la sérénité : utiliser la variable d’environnement TWO_TASK.
Prenons l’exemple d’une base PDB1 (pluggable database) rattachée à une instance nommée CDB (container database).
Il vous faut tout d’abord créer une entrée dans votre fichier d’alias TNSNAMES.ORA contenant les lignes suivantes :
PDB1 =
(DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP)(HOST = <hostname>)(PORT = <port>))
(CONNECT_DATA =
(SERVER = DEDICATED)
(SERVICE_NAME = PDB1)
)
)
Ensuite, il vous faut positionner les variables d’environnement Oracle pour vous connecter à votre PDB, en exécutant les commandes suivantes :
. oraenv
CDB -- Nom de la container database qui héberge votre PDB
export TWO_TASK=PDB1
$ sqlplus system/oracle
SQL*Plus: Release 12.1.0.2.0 Production on Tue Apr 11 08:02:37 2017
Copyright (c) 1982, 2014, Oracle. All rights reserved.
Last Successful login time: Mon Mar 27 2017 13:24:41 -04:00
Connected to:
Oracle Database 12c Enterprise Edition Release 12.1.0.2.0 - 64bit Production
With the Partitioning, Automatic Storage Management, OLAP, Advanced Analytics
and Real Application Testing options
SQL> show con_name
CON_NAME
------------------------------
PDB1
SQL>
Vous êtes bien connecté directement sur votre PDB, et remarquez que vous n’avez pas changé la façon de vous connecter à votre base.
Voyons maintenant le cas particulier de l’authentification OS, le fameux « / as sysdba » ou « connect / », pour se connecter sans avoir à renseigner le mot de passe.
La version 12c, en plus du multitenant, amène également beaucoup de nouveautés en termes de sécurité, au point que certains accès de type authentification OS sont désormais refusés.
Pour vous permettre les accès de type authentification OS sur une PDB au travers de la variable TWO_TASK, il vous faut renseigner le paramètre d’instance REMOTE_OS_AUTHENT = TRUE (Attention, ce paramètre n’est pas dynamique et nécessite un redémarrage de l’instance), mais même avec ce paramètre positionné, la connexion vous sera refusée si le compte OPS$<login> est muni d’un mot de passe !
Et oui, cette possibilité fonctionnait très bien jusqu’en version 11gR2 incluse, et permettait l’authentification OS (avec un CONNECT /) ainsi que la connexion à ces comptes OPS$<login> en fournissant le mot de passe associé.
Ex:
$ sqlplus /
SQL*Plus: Release 12.1.0.2.0 Production on Tue Apr 11 08:38:27 2017
Copyright (c) 1982, 2014, Oracle. All rights reserved.
ERROR:
ORA-01017: invalid username/password; logon denied
Pour passer outre, il vous faudra supprimer le mot de passe associé et déclarer ce compte OPS$<login> comme il aurait toujours du l’être :
ALTER USER OPS$<login> IDENTIFIED EXTERNALLY ;
$ sqlplus /
SQL*Plus: Release 12.1.0.2.0 Production on Tue Apr 11 08:52:04 2017
Copyright (c) 1982, 2014, Oracle. All rights reserved.
Last Successful login time: Tue Apr 11 2017 08:13:56 -04:00
Connected to:
Oracle Database 12c Enterprise Edition Release 12.1.0.2.0 - 64bit Production
With the Partitioning, Automatic Storage Management, OLAP, Advanced Analytics
and Real Application Testing options
SQL> show user
USER is "OPS$ORACLE"
SQL>
Cette solution ne peut toutefois pas être utilisée pour le fameux CONNECT / AS SYSDBA dont la sécurité a bien été renforcée en 12c, et nécessite désormais la fourniture du mot de passe dans la chaîne de connexion.
En résumé et à l’exception du CONNECT / AS SYSDBA, la technique du TWO_TASK vous simplifiera la tâche pour les environnements comprenant beaucoup de scripts ou de programmes, et je l’espère aussi, vous donnera envie d’aller vers le multitenant.
