Pour être informé des derniers articles, pensez à vous inscrire à la newsletter. Par ailleurs, n'hésitez pas à faire part
de vos remarques, suggestions,...
LAO.
proposition@lao-dba.com
LAO.
proposition@lao-dba.com
Mardi 9 décembre 2008
2
09
/12
/2008
21:46
Bonsoir,
Ce soir, je vais rédiger un petit post mais néanmoins utile. Comment connaitre la version d'ORACLE utilisée ?
Cette question au premier abord est assez simple, mais vous pouvez faire une petit test: Demandez autour de vous aux personnes qui s'occupent de vos bases ORACLE quelle est la version exacte d'Oracle installée et bien sur son niveau de patch, que ce soit des Patch Set (montée de version), des CPU (Critical Patch Update) qu'Oracle met en ligne tous les trimestres ou tout simplement des patches temporaires que l'on peut assimiler à des Hot fix.
Evidemment, je ne m'adresse pas aux DBA experts (qui connaissent la réponse) , mais plutôt à mes amis éditeurs qui sans forcement s'en rendre compte perdent un peu le controle d'une pièce essentielle de leur architecture : la base de données.
En effet, on a déjà vu dans ne nombreux cas, ou il arrivait que l'on ne puisse pas reproduire un problème client. Il est déjà bien compliqué d'utiliser la même version du logiciel fabriqué, mais parfois il arrive que le bug ou problème de perfermance ne soit pas lié à une malformation liés à un développement hasardeux, mais tout simplement à un bug ORACLE !
Or pour mettre à jour cela, encore faut il savoir sur quelle version on test,et quelle version a le client !
Exemple:
J'ouvre une commande DOS, et je m'assure que ma variable ORACLE_HOME est bien initialisée:
SET ORACLE_HOME= c:\oracle\product\10.2.0 (pour windows)
export ORACLE_HOME = \apps\..... (pour linux)
Et une fois cela fait, je vais utiliser l'utiliataire Opatch fournit par ORACLE.
windows:
%ORACLE_HOME%\Opatch\opatch lsinventory
linux:
$ORACLE_HOME/Opatch/optach lsinventory
Résultat:
On obtient des informations précieuses :
Dans mon exemple, on voit qu' à l'origine j'avais une version 10.2.0.1 qui a été mise à jour avec une 10.2.0.2.
Nous pouvons également voir que j'ai appliqué un patch temporaire avec le numéro de patch, la date et heure d'application, et cerise sur le gateau, la liste des bugs fixés par l'application du patch.
Un fichier de sortie contenant toutes ces informations a été crée dans %ORACLE_HOME%\cfgtoollogs\opatch\lsinv\
Cela peut quand même être utile de savoir cela !
LAO.
Ce soir, je vais rédiger un petit post mais néanmoins utile. Comment connaitre la version d'ORACLE utilisée ?
Cette question au premier abord est assez simple, mais vous pouvez faire une petit test: Demandez autour de vous aux personnes qui s'occupent de vos bases ORACLE quelle est la version exacte d'Oracle installée et bien sur son niveau de patch, que ce soit des Patch Set (montée de version), des CPU (Critical Patch Update) qu'Oracle met en ligne tous les trimestres ou tout simplement des patches temporaires que l'on peut assimiler à des Hot fix.
Evidemment, je ne m'adresse pas aux DBA experts (qui connaissent la réponse) , mais plutôt à mes amis éditeurs qui sans forcement s'en rendre compte perdent un peu le controle d'une pièce essentielle de leur architecture : la base de données.
En effet, on a déjà vu dans ne nombreux cas, ou il arrivait que l'on ne puisse pas reproduire un problème client. Il est déjà bien compliqué d'utiliser la même version du logiciel fabriqué, mais parfois il arrive que le bug ou problème de perfermance ne soit pas lié à une malformation liés à un développement hasardeux, mais tout simplement à un bug ORACLE !
Or pour mettre à jour cela, encore faut il savoir sur quelle version on test,et quelle version a le client !
Exemple:
J'ouvre une commande DOS, et je m'assure que ma variable ORACLE_HOME est bien initialisée:
SET ORACLE_HOME= c:\oracle\product\10.2.0 (pour windows)
export ORACLE_HOME = \apps\..... (pour linux)
Et une fois cela fait, je vais utiliser l'utiliataire Opatch fournit par ORACLE.
windows:
%ORACLE_HOME%\Opatch\opatch lsinventory
linux:
$ORACLE_HOME/Opatch/optach lsinventory
Résultat:
On obtient des informations précieuses :
Dans mon exemple, on voit qu' à l'origine j'avais une version 10.2.0.1 qui a été mise à jour avec une 10.2.0.2.
Nous pouvons également voir que j'ai appliqué un patch temporaire avec le numéro de patch, la date et heure d'application, et cerise sur le gateau, la liste des bugs fixés par l'application du patch.
Un fichier de sortie contenant toutes ces informations a été crée dans %ORACLE_HOME%\cfgtoollogs\opatch\lsinv\
Cela peut quand même être utile de savoir cela !
LAO.
Par LAO
-
Publié dans : Administration
-
Communauté : ORACLE
Ecrire un commentaire - Voir les 6 commentaires - Recommander
Ecrire un commentaire - Voir les 6 commentaires - Recommander
Commentaires
Archives
- février 2010 (1)
- juin 2009 (1)
- mars 2009 (1)
- février 2009 (6)
- janvier 2009 (6)
- décembre 2008 (10)
- novembre 2008 (15)
- octobre 2008 (17)
Catégories
- RMAN (1)
- FLASHBACK (1)
- ORACLE NET (1)
- PERFORMANCE (12)
- Administration (22)
- ORACLE 11 (7)
- SQL DEVELOPER (1)
- Dataguard (4)
- Clonage de base (3)
Recherche
Articles récents
- Oracle 11 & Dataguard active
- Administration - Opérations longues
- Historique volumétrie tablespace
- Dataguard - Physical Standby - Mise en place
- Dataguard - Présentation
- Connaitre la version Oracle qui tourne (32 ou 64 bit)
- Dataguard - Version standard - Mise en place d'une base "standby" (2)
- Dataguard - Version standard - Mise en place d'une base "standby" (1)
- Connexion à une base distante - ORA-01031
- Clonage d'une base - Archivelog - Serveur distant
Calendrier
| Mars 2010 | ||||||||||
| L | M | M | J | V | S | D | ||||
| 1 | 2 | 3 | 4 | 5 | 6 | 7 | ||||
| 8 | 9 | 10 | 11 | 12 | 13 | 14 | ||||
| 15 | 16 | 17 | 18 | 19 | 20 | 21 | ||||
| 22 | 23 | 24 | 25 | 26 | 27 | 28 | ||||
| 29 | 30 | 31 | ||||||||
|
||||||||||
Profil
- : LAO
-
- : Homme
- : 06/05/1972
- : IDF
il faut aller sur Metalink (http://metalink2.oracle.com) dans la partie "patches and updates".
Ensuite effectuer une "simple search" et taper 2617419 comme numéro de patch.
Ce qui te permettra de télécharger la dernière version d'Opatch en fonction de ta plateforme.
Il suffit ensuite de lire le read me pour déployer. Globalement il suffit de dezipper le fichier téléchargé dans ton ORACLE_HOME.
LAO.
Y en a même qui perdent des troupes !
Mais de rien Virginie, c'est un réel plaisir !
Merci pour les encouragement, ca donne un peu de force pour continuer dans ce sens.
Pour révenir à a question:
J'avoue que je ne pas de réponse sur le sujet. Mais il ne semble pas qu'OPATCH soit lié à la version d'oracle. Si tu as une machine de test, le plus simple serait d'essayer (je n'ai pas de V9 sous la main).
Mais sinon, tu peux certainement récuperer sur les CD ORACLE 9 la version d'Opatch associé à la version installée sur ta machine. Je suppose que si Opatch n'est pas installé, cela signifie qu'il n' a pas de patche passé.
Sur le CD d'installation il doit y avoir un répertoire oracle.swd.opatch qui se trouve dans \Database\stage\component
En déscendant l'arborscence, tu vas trouver des points jar. Il faut les extraire pour recréer le répertoire Opatch.
Peut être que tu peux également le faire via OUI.
LAO.
Etant donné qu'Opatch n'est pas installé avec le client par défaut et que par ailleur pour le faire fonctionner,il faut définir la variable d'environnement ORACLE_HOME, il me parait peu probable que l'on puisse l'utiliser depuis un poste client. Il faut se connecter sur le serveur (TSE pour windows ou un outil type putty avec connexion SSH pour du linux).
LAO
De mémoire, il me semble que la vue DBA_REGISTRY indique les différents composants installés et non pas l'historique des patchs (patchset, critical patch update, et mini patch).
Ce qui peut également être pratiques.
LAO.