Trouver l'édition et la version Oracle
- Détails
- Catégorie : Edition, version, option, usage, licence
- Publié le jeudi 1 février 2018 20:54
- Écrit par Administrator
- Affichages : 42310
Il peut arriver parfois d’avoir besoin de connaitre la version et l’édition d’un moteur Oracle sur un serveur alors qu’aucune base de données ne tourne, voir n’a été créée. Cela peut paraître trivial, mais il y a des cas, en particulier en 11g, où ce n’est pas toujours évident même avec une de base démarrée.
Cet article explique comment trouver la version : 11.2.0 .4, 12.2.0.1… et l’édition : Entreprise Standard Two, Express... d’un moteur Oracle même base de données éteinte. Il peut s’appliquer aux versions 10gR2 à 12cR2. Il devrait être applicable au version 9 et 8 (non testé) et peut être au versions 18 et plus (version non sortie à ce jour).
La Version
La version est l’information la plus facile à obtenir par rapport à l’édition, même base arrêtée.
Pour déterminer la version des binaires Oracle installés sur un serveur, quand il n’y a aucune base qui tourne et que l’on a accès au binaire du moteur, accès local donc, le plus rapide est de tester la version du sqlplus :
[oracle@ora12cR2 ~]$ sqlplus -version
SQL*Plus: Release 12.2.0.1.0 Production
Une méthode, plus rigoureuse, est d’interroger OPatch.
[oracle@ora12cR2 ~]$ $ORACLE_HOME/OPatch/opatch lsinventory|grep "Oracle Database"
Oracle Database 12c 12.2.0.1.0
[oracle@asmdbm01 ~]$ $ORACLE_HOME/OPatch/opatch lsinventory|grep "Oracle Database"
Oracle Database 11g 11.2.0.4.0
[oracle@saddbm ~]$ $ORACLE_HOME/OPatch/opatch lsinventory|grep "Oracle Database"
Oracle Database 10g 10.2.0.1.0
Oracle Database 10g Release 2 Patch Set 4 10.2.0.5.0
Contrairement à sqlplus, OPatch donne le niveau de patch (PSU ou bundle), il est donc plus précis d’utiliser OPatch. Dans l’exemple ci-dessous le moteur est un 12.1 avec le patchset 12.1.0.2 et le PSU d’octobre 2017 (171017):
[oracle@smndb01 ~]$ $ORACLE_HOME/OPatch/opatch lsinventory|grep "Patch description"
Patch description: "Database Patch Set Update : 12.1.0.2.171017 (26713565)"
Patch description: "OCW Patch Set Update : 12.1.0.2.171017 (26392192)"
Les 2 méthodes ci-dessus fonctionnent, si on a l’environnement Oracle de correctement configuré. D’ailleurs sur ces exemples, on voit que les commandes sont lancées avec le user oracle (voir prompt) et que l’on utilise la variable d’environnement ORACLE_HOME. Mais si on ne connait pas le user oracle, car il ne s’appelle pas oracle et que sur le serveur il y a plus de 100 users. Il faut alors en premier lieu trouver le chemin du binaire :
[root@oradbm ~]# find / -type f -name oracle
/var/spool/mail/oracle
/oracle/11.2.0.4/database/bin/oracle
Avec un ls -l, on en deduis alors le propriétaire, aisni que le ORACLE_HOME (/oracle/11.2.0.4/database dans cet exemple).On peut alors se connecter avec le user à qui appartient le binaire oracle trouvé pour exécuter les commandes précédentes ou bien avec root auquel cas il faudra impérativement setter les variables d’environnement :
[root@asmdbm01 ~]# export ORACLE_HOME=/oracle/11.2.0.4/database
[root@asmdbm01 ~]# export PATH=$PATH:$ORACLE_HOME/bin
[root@asmdbm01 ~]# /oracle/11.2.0.4/grid/bin/sqlplus -v
SQL*Plus: Release 11.2.0.4.0 Production
Une autre solution, un peu plus détournée, est de rechercher un fichier alert.log d’une base qui aurait déjà tourné sur le serveur et de l’éditer :
[root@asmdbm01 ~]# find / -type f -name "alert*log"
/oracle/oraBase/diag/asm/+asm/+ASM/trace/alert_+ASM.log
/oracle/oraBase/diag/rdbms/prod/PROD/trace/alert_PROD.log
/oracle/11.2.0.4/grid/log/asmdbm01/alertasmdbm01.log
Dans le fichier d’alert, on peut voir au démarrage de la base de données sa version, mais rien ne prouve que ce fichier correspond bien à la version du binaire Oracle que l’on recherche. Il peut y avoir eu plusieurs installations sur le serveur par exemple.
Wed Nov 25 19:12:51 2015
Starting ORACLE instance (normal)
[…]
LICENSE_MAX_USERS = 0
SYS auditing is disabled
Starting up:
Oracle Database 11g Enterprise Edition Release 11.2.0.4.0 - 64bit Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options.
ORACLE_HOME = /oracle/11.2.0.4/database
System name: Linux
Node name: asmdbm01
Si une base de données tourne (état OPEN ou MOUNT) alors il est extrêmement simple de déterminer la version du moteur Oracle, la vue v$version répond à la demande et l’on peut trouver la version sans connexion local au serveur de base de données, comme dans l’exemple suivant:
[winroc@client01 ~]$ sqlplus system/oracle@//asmdbm01:1521/PROD
SQL*Plus: Release 11.2.0.2.0 Production on Mon Jan 29 08:58:32 2018
Copyright (c) 1982, 2013, Oracle. All rights reserved.
Connected to:
Oracle Database 11g Enterprise Edition Release 11.2.0.4.0 - 64bit Production
With the Partitioning, Automatic Storage Management, OLAP, Data Mining and Real Application Testing options
SQL> select * from v$version;
BANNER
--------------------------------------------------------------------------------
Oracle Database 11g Enterprise Edition Release 11.2.0.4.0 - 64bit Production
PL/SQL Release 11.2.0.4.0 - Production
CORE 11.2.0.4.0 Production
TNS for Linux: Version 11.2.0.4.0 - Production
NLSRTL Version 11.2.0.4.0 - Production
D’ailleurs avant même d’interroger la vue, on peut voir dans l’exemple ci-dessus que le prompt indique la version mais attention de ne pas confondre la version du client sqlplus, ici : 11.2.0.2 et la version du moteur Oracle dans lequel on est connecté : 11.2.0.4. Il est à noter aussi que suivant la sécurité mis en place, ce prompt peut ne pas apparaitre, et donc l’interrogation à la vue v$version est obligatoire. Pour information cette vue ne nécessite aucun droit particulier pour être interrogée.
L'Edition
Pour déterminer l’édition sans base de données de démarrée ou de crée, il existe plusieurs solutions.
Une solution est de lire dans les logs de l’installation. Ils se trouvent dans le « oracle inventory ». Pour déterminer l’oracle inventory, on peut aller soit dans $ORACLE_HOME soit dans /etc et chercher le fichier oraInst.loc. Le fichier oraInst.loc contient alors le chemin de l’inventory :
[oracle@ora12cse2 database]$ cat oraInst.loc
inventory_loc=/oracle/oraInventory
inst_group=oinstall
Il faut alors aller dans l’inventory (inventory_loc) puis dans répertoire logs où se trouve le fichier de log de l’installation. Il suffit ensuite de chercher la chaîne de caractère « Database edition » (en version 11 et 12) ou bien la chaîne "Installation Type:" (en version 10) :
[oracle@ora12cse2 logs]$ grep "Database edition" *
installActions2016-03-15_12-03-31PM.log:INFO: - Database edition : Standard Edition Two (Install database software only)
[oracle@civdbm logs]$ grep "Installation Type:" *
installActions2016-10-12_05-52-32PM.log: Installation Type: Enterprise Edition
Remarque: En Express Edition ce fichier n’existe pas.
Cependant il peut y avoir eu plusieurs installations (plusieurs moteurs) ou tentatives d’installation, voir des désinstallations puis réinstallation. Pour être sûr et certain de la version du binaire il faut aller lire « dedans », la commande strings va faire l’affaire :
[oracle@s1dbm12c logs]$ strings $ORACLE_HOME/bin/oracle |grep -i "Oracle Database "|grep "Edition Release" |awk '{print $4}'
Enterprise
[oracle@ora12cse2 logs]$ strings $ORACLE_HOME/bin/oracle |grep -i "Oracle Database "|grep "Edition Release" |awk '{print $4}'
Standard
-bash-4.1$ strings $ORACLE_HOME/bin/oracle |grep -i "Oracle Database "|grep "Edition Release" |awk '{print $4}'
Express
Cette méthode ne fonctionne que sur Linux et pas sur tous les Unix comme AIX par exemple. Une autre méthode, un peu plus détourné, qui fonctionne aussi bien sur Linux qu’Unix et de chercher la librairie libvsn* dans $ORACLE_HOME/lib et de voir ce qu’elle contient. Si elle n’existe pas alors c’est que nous somme en Express Edition 11g ou 10g (Express 18c non encore sortie au moment de l’écriture de l’article) :
Exemple en 12.1 Standard Edition:
[oracle@ora12cse2 12.1.0.2.0]$ strings /oracle/12.1.0.2/database/lib/libvsn12.a|grep -i "Enterprise Edition Release"|wc -l
0
[oracle@ora12cse2 12.1.0.2.0]$ strings /oracle/12.1.0.2/database/lib/libvsn12.a|grep -i "Standard Edition Release"|wc -l
1
Exemple en 11.2 Entreprise Edition:
[oracle@s1dbm01 lib]$ strings /oracle/11.2.0.4/database/lib/libvsn11.a |grep -i release|grep -i "Enterprise Edition Release" |wc -l
1
[oracle@s1dbm01 lib]$ strings /oracle/11.2.0.4/database/lib/libvsn11.a |grep -i release|grep -i "Enterprise Standard Release" |wc -l
0
Exemple en 10.2 Entreprise Edition:
[oracle@civdbm lib]$ strings /oracle/10.2/database/lib/libvsn10.a |grep -i release|grep -i "Enterprise Edition Release" |wc -l
1
Ces 2 méthode, lecture dans le bianire oracle ou bien sur la librairie libvsn fonctionnent sans ambiguïté en 12c, car il n’y a qu’une édition Standard en 12c c’est la Standard Two. En revanche en 11g cela ne permet pas de déterminer si c’est une Standard Edition ou bien une Standard Edition One. Il faudra alors trouver le fichier de log de l’installation (méthode expliquer précédemment) pour pouvoir trancher :
[oracle@oradbm logs]$ grep "Database edition" *
installActions2014-02-25_13-59-06PM.log:INFO: - Standard Edition One (Install database software only)
Dans le cas où il y a une base de données de démarrée, alors comme pour la rechercher de la version, le prompt de connexion donne l’information.
Exemple en 12cR1 Standard Two :
[oracle@ora12cse2 logs]$ sqlplus / as sysdba
SQL*Plus: Release 12.1.0.2.0 Production on Tue Jan 30 09:13:36 2018
Copyright (c) 1982, 2014, Oracle. All rights reserved.
Connected to:
Oracle Database 12c Standard Edition Release 12.1.0.2.0 - 64bit Production
En 12c le prompt affiche Entreprise ou bien Standard mais en 10g et 11g, il affiche Entreprise pour Entreprise mais n’affiche rien pour Standard et Standard One. Donc si Enterprise ne s’affiche pas en 11g, c’est une Standard ou une Standard One, et il faut, comme dans les cas précédemment exposés aller chercher l’information les logs de l’installation.
En 12c, en plus du prompt l’information peut être retrouver dans la vue v$instance colonne edition (nouvelle colonne introduite en 12.1). Mais contrairement à v$version, l’accès à la vue v$instance nécessite un privilège.
SQL> select edition from v$instance;
EDITION
-------
SE
La lecture de la documentation de référence sur la vue v$instance est intéressante, elle fait apparaitre des versions que personnellement je ne connais ou bien en fait disparaitre !
En 12.1 d’après la documentation d’administration, la colonne edition peut prendre comme valeur :
- CORE EE --> CORE Entreprise Edition (connais pas)
- CORE SE --> CORE Standard Edition (connais pas)
- EE --> Entreprise Edition
- PO --> Personnal Edition (je connais mais jamais utilisé, installé ni même téléchargé)
- SE --> Standard Edition
- XE --> Express Edition
En 12.2 d’après la documentation d’administration, c’est exactement comme en 12.1 mais sans aucune référence aux versions standard, est-ce un bug de la documentation ?
{jcomments on}