Je viens de rencontrer un problème en essayant d'exporter un référentiel OWB 10.2.0.5 avec le Repository Assistant 11.2.0.1 sur une plate-forme Solaris (il faut dire que j'ai aussi rencontré le problème en lançant le repository assistant à partir de mon poste de travail windows XP sur lequel j'ai installé OWB 11.2.0.1 standalone).
L'export se déroule jusqu'à 86% et plus rien.
Dans la fenêtre unix où le script «$OWB_HOME/owb/bin/unix/reposinst.sh» a été lancé, on peut lire les messages suivants:
APIController.reInit - apiFactory = oracle.wh.repos.impl.CMPWBAPIFactory@1cca9e2
APIController.reInit - concurrencyControl = oracle.wh.repos.pdl.dispatcher.EventDispatcherImpl@1a547d1
APIController.reInit - transactionControl = oracle.wh.repos.pdl.transaction.TransactionManager@dfa92
Thread[TaskScheduler timer,5,main]CacheMediator.init:
Thread[TaskScheduler timer,5,main]CacheMediator: (@ Mon Aug 23 14:46:25 EDT 2010)
Hits : 0
Misses: 0
Objects instantiated (proxy+subject): 0
Instantiation time total: 0
Instantiation time SCOs : 0
# of cache loads (proxy+subject): 0
# of cache unloads (subject only): 0
# of cache reloads (subject only): 0
Memory mode next element id: 99
Transient next element id: -99
Repos mode next element id: 1
Repos mode max element id: 0
Thread[TaskScheduler timer,5,main]ComponentCache:
# of WBProxy elements in cache: 0
# of UOIDs in lookup map : 0
Thread[TaskScheduler timer,5,main]oracle.wh.repos.pdl.foundation.StaticCache@1bd95a1:
# of elements in staticCache : 0
# of elements in definitionCache: 0
# of UOIDs in uiodLookup : 0
Thread[TaskScheduler timer,5,main]oracle.wh.repos.pdl.foundation.MemoryManagerImpl@eb7ad2:
Memory used: 0.06723325
Thread[TaskScheduler timer,5,main]java.lang.Runtime@5a58e0:
Memory total: 1029963776
free: 960711856
Quoique le patch 9802120 permet de régler la plupart des problèmes d'export/import d'OWB, ce problème ci est plutôt lié à la mémoire.
La Note Metalink 1077755.1 (qui parle d'un import), m'a mis sur la voie.
En effet, j'ai arrêté mon export et j'ai modifié le fichier $OWB_HOME/owb/bin/unix/reposinst.sh comme suit:
$JAVAPATH/bin/java -Xms128m -Xmx2048m -DOWBCC_HOME=$OWBCC_HOME $CLASSPATH_LAUNCHER oracle.wh.ui.install.assistant.wizards.AssistantWizard
Initialement la valeur du Xmx était 1024. L'on peut adapter ces valeurs ( Xms et Xmx) selon ses besoins.
Après cette modification, j'ai relancé l'export et tout s'est bien déroulé.
mardi 24 août 2010
Comment installer un SSO pour l'OID 11g?
Ce article est le premier du genre car c'est la première fois que j'écris sur Oracle Fusion Middleware (OFM) et/ou Oracle Application Server (OAS).
Puisque le Single Sign-On (SSO) n'existe plus avec OFM 11g, l'on se demande comment faire si l'on veut continuer à utiliser cette fonctionnalité.
Eh bien, l'on peut utiliser le SSO 10g avec l'OID 11g car l'OFM 11g offre cette option. Voir la Note Metalink 1069426.1 pour plus de détails.
Pour que cela soit possible, Oracle a sorti un Metadata Repository Creation Assistant (MRCA) spécial. C'est cette version de MRCA 10.1.4.3.1 qui permet d'installer un SSO+DAS avec l'OID 11g. Cette version de MRCA est disponible pour téléchargement au même emplacement qu'OFM 11g: http://www.oracle.com/technology/software/products/middleware/htdocs/fmw_11_download.html
La procédure complète d'installation est décrite dans le chapitre 11 (Installing Oracle Single Sign-On and Oracle Delegated Administration Services Against OID) du document d'installation d'oracle Identitity Management:
http://download.oracle.com/docs/cd/E14571_01/install.1111/e12002/sso_das.htm#CIHEGHIG
Suivre donc cette procédure pour installer et tester cette configuration.
Dans cette procédure, il est très important de comprendre le rôle et les différentes options du script «inspre11.pl». Pour ce faire, commencer par cliquer sur le lien Understanding the inspre11.pl Script.
Continuer ensuite avec les points suivant pour procéder à l'installation:
Hope it helps !
Puisque le Single Sign-On (SSO) n'existe plus avec OFM 11g, l'on se demande comment faire si l'on veut continuer à utiliser cette fonctionnalité.
Eh bien, l'on peut utiliser le SSO 10g avec l'OID 11g car l'OFM 11g offre cette option. Voir la Note Metalink 1069426.1 pour plus de détails.
Pour que cela soit possible, Oracle a sorti un Metadata Repository Creation Assistant (MRCA) spécial. C'est cette version de MRCA 10.1.4.3.1 qui permet d'installer un SSO+DAS avec l'OID 11g. Cette version de MRCA est disponible pour téléchargement au même emplacement qu'OFM 11g: http://www.oracle.com/technology/software/products/middleware/htdocs/fmw_11_download.html
La procédure complète d'installation est décrite dans le chapitre 11 (Installing Oracle Single Sign-On and Oracle Delegated Administration Services Against OID) du document d'installation d'oracle Identitity Management:
http://download.oracle.com/docs/cd/E14571_01/install.1111/e12002/sso_das.htm#CIHEGHIG
Suivre donc cette procédure pour installer et tester cette configuration.
Dans cette procédure, il est très important de comprendre le rôle et les différentes options du script «inspre11.pl». Pour ce faire, commencer par cliquer sur le lien Understanding the inspre11.pl Script.
Continuer ensuite avec les points suivant pour procéder à l'installation:
Hope it helps !
vendredi 6 août 2010
Comment déplacer un datafile d'un diskgroup ASM vers un autre diskgroup?
Pour déplacer un fichier d'un diskgroup ASM à un autre, procéder comme suit:
1- Identifier le fichier à déplacer:
SYS@D104> select file_name from dba_data_files;
FILE_NAME
--------------------------------------------------------------------------------
+INFO_SYSDG01/d104/datafile/users.265.726235377
...
9 rows selected.
SYS@D104>
Note:
L'on voit que le fichier est dans le diskgroup «+INFO_SYSDG01».
2- Identifier le diskgroup où l'on veut déplacer le fichier:
SYS@D104 > select name from v$asm_diskgroup;
NAME
------------------------------
SYSDG01
FRADG01
FRADG02
DATADG01
INFO_SYSDG01
INFO_FRADG01
INFO_FRADG02
INFO_DATADG01
..
SYS@D104 >
Note:
Le datafile vâ être déplacé dans le diskgroup «+INFO_DATADG01».
3- Mettre le datafile à déplacer OFFLINE
SYS@D104 > ALTER DATABASE DATAFILE '+INFO_SYSDG01/d104/datafile/users.265.726235377' offline;
ALTER DATABASE DATAFILE '+INFO_SYSDG01/d104/datafile/users.265.726235377' offline *
ERROR at line 1:
ORA-01145: OFFLINE IMMEDIATE rejeté sauf si récupération après défaillance
matérielle validée
Note:
Ce message d'erreur est dû au fait que la BD est en mode NOARCHIVELOG.
Il faut donc la mettre en mode ARCHIVELOG (à vous de voir s'il s'agit d'une BD qu'on peut redémarrer)
Mettre donc la BD en mode ARCHIVELOG:
SYS@D104 > shutdown immediate
Database closed.
Database dismounted.
ORACLE instance shut down.
SYS@D104 > startup mount
ORACLE instance started.
Total System Global Area 1044193280 bytes
Fixed Size 2154688 bytes
Variable Size 754982720 bytes
Database Buffers 276824064 bytes
Redo Buffers 10231808 bytes
Database mounted.
SYS@D104 > alter database archivelog;
Database altered.
SYS@D104 > alter database open;
Database altered.
SYS@D104 > archive log list
Database log mode Archive Mode
Automatic archival Enabled
Archive destination +INFO_FRADG02
Oldest online log sequence 1
Next log sequence to archive 1
Current log sequence 1
SYS@D104 >
Maintenant l'on peut mettre de datafile OFFLINE:
SYS@D104 > ALTER DATABASE DATAFILE '+INFO_SYSDG01/d104/datafile/users.265.726235377' offline;
4- Copier le fichier avec RMAN
oracle@uhq002:/uhq002_u01/home/dba/oracle> rman target /
Recovery Manager: Release 11.2.0.1.0 - Production on Ven. Août 6 15:09:08 2010
Copyright (c) 1982, 2009, Oracle and/or its affiliates. All rights reserved.
connected to target database: D104 (DBID=3868786077)
RMAN> copy datafile '+INFO_SYSDG01/d104/datafile/users.265.726235377' to '+INFO_DATADG01';
Starting backup at 2010-08-06 15:09:42
using target database control file instead of recovery catalog
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=556 instance=D104 device type=DISK
channel ORA_DISK_1: starting datafile copy
input datafile file number=00006 name=+INFO_SYSDG01/d104/datafile/users.265.726235377
output file name=+INFO_DATADG01/d104/datafile/users.262.726241139 tag=TAG20100512T154150 RECID=12 STAMP=726241139
channel ORA_DISK_1: datafile copy complete, elapsed time: 00:00:07
Finished backup at 2010-08-06 15:09:59
RMAN>
Conserver la session RMAN (Ne pas la fermer)
Note:
Prendre en note le nom du nouveau fichier. C'est le «output file name» dans la session RMAN. Ce fichier sera utilisé dans la suite.
5- Renommer le fichier dans la BD:
SYS@D104 > alter database rename file '+INFO_SYSDG01/d104/datafile/users.265.726235377' to '+INFO_DATADG01/d104/datafile/users.262.726241139';
6- Switcher le datafile vers la copie dans RMAN:
RMAN> switch datafile '+INFO_DATADG01/d104/datafile/users.262.726241139' to copy;
datafile 6 switched to datafile copy "+INFO_DATADG01/d104/datafile/users.262.726241139"
7- Recover du datafile:
SYS@D104 > recover datafile '+INFO_DATADG01/d104/datafile/users.262.726241139';
Récupération après défaillance matérielle terminée.
8- Mettre le datafile ONLINE:
SYS@D104 > ALTER DATABASE datafile '+INFO_DATADG01/d104/datafile/users.262.726241139' online;
Base de données modifiée.
8- Vérifier le nouvel emplacement du datafile:
SYS@D104 > select file_name from dba_data_files;
FILE_NAME
--------------------------------------------------------------------------------
+INFO_DATADG01/d104/datafile/users.262.726241139
...
9 rows selected.
SYS@D104 >
Note:
Avec une bd 11gR2 et ASM 11gR2, l'ancien fichier a été automatiquement détruit.
9- Remettre la BD en mode NOARCHIVELOG
SYS@D104 > shutdown immediate
Database closed.
Database dismounted.
ORACLE instance shut down.
SYS@D104 > startup mount
ORACLE instance started.
Total System Global Area 1044193280 bytes
Fixed Size 2154688 bytes
Variable Size 754982720 bytes
Database Buffers 276824064 bytes
Redo Buffers 10231808 bytes
Database mounted.
SYS@D104 > alter database noarchivelog;
Database altered.
SYS@D104 > alter database open;
Database altered.
SYS@D104 >
1- Identifier le fichier à déplacer:
SYS@D104> select file_name from dba_data_files;
FILE_NAME
--------------------------------------------------------------------------------
+INFO_SYSDG01/d104/datafile/users.265.726235377
...
9 rows selected.
SYS@D104>
Note:
L'on voit que le fichier est dans le diskgroup «+INFO_SYSDG01».
2- Identifier le diskgroup où l'on veut déplacer le fichier:
SYS@D104 > select name from v$asm_diskgroup;
NAME
------------------------------
SYSDG01
FRADG01
FRADG02
DATADG01
INFO_SYSDG01
INFO_FRADG01
INFO_FRADG02
INFO_DATADG01
..
SYS@D104 >
Note:
Le datafile vâ être déplacé dans le diskgroup «+INFO_DATADG01».
3- Mettre le datafile à déplacer OFFLINE
SYS@D104 > ALTER DATABASE DATAFILE '+INFO_SYSDG01/d104/datafile/users.265.726235377' offline;
ALTER DATABASE DATAFILE '+INFO_SYSDG01/d104/datafile/users.265.726235377' offline *
ERROR at line 1:
ORA-01145: OFFLINE IMMEDIATE rejeté sauf si récupération après défaillance
matérielle validée
Note:
Ce message d'erreur est dû au fait que la BD est en mode NOARCHIVELOG.
Il faut donc la mettre en mode ARCHIVELOG (à vous de voir s'il s'agit d'une BD qu'on peut redémarrer)
Mettre donc la BD en mode ARCHIVELOG:
SYS@D104 > shutdown immediate
Database closed.
Database dismounted.
ORACLE instance shut down.
SYS@D104 > startup mount
ORACLE instance started.
Total System Global Area 1044193280 bytes
Fixed Size 2154688 bytes
Variable Size 754982720 bytes
Database Buffers 276824064 bytes
Redo Buffers 10231808 bytes
Database mounted.
SYS@D104 > alter database archivelog;
Database altered.
SYS@D104 > alter database open;
Database altered.
SYS@D104 > archive log list
Database log mode Archive Mode
Automatic archival Enabled
Archive destination +INFO_FRADG02
Oldest online log sequence 1
Next log sequence to archive 1
Current log sequence 1
SYS@D104 >
Maintenant l'on peut mettre de datafile OFFLINE:
SYS@D104 > ALTER DATABASE DATAFILE '+INFO_SYSDG01/d104/datafile/users.265.726235377' offline;
4- Copier le fichier avec RMAN
oracle@uhq002:/uhq002_u01/home/dba/oracle> rman target /
Recovery Manager: Release 11.2.0.1.0 - Production on Ven. Août 6 15:09:08 2010
Copyright (c) 1982, 2009, Oracle and/or its affiliates. All rights reserved.
connected to target database: D104 (DBID=3868786077)
RMAN> copy datafile '+INFO_SYSDG01/d104/datafile/users.265.726235377' to '+INFO_DATADG01';
Starting backup at 2010-08-06 15:09:42
using target database control file instead of recovery catalog
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=556 instance=D104 device type=DISK
channel ORA_DISK_1: starting datafile copy
input datafile file number=00006 name=+INFO_SYSDG01/d104/datafile/users.265.726235377
output file name=+INFO_DATADG01/d104/datafile/users.262.726241139 tag=TAG20100512T154150 RECID=12 STAMP=726241139
channel ORA_DISK_1: datafile copy complete, elapsed time: 00:00:07
Finished backup at 2010-08-06 15:09:59
RMAN>
Conserver la session RMAN (Ne pas la fermer)
Note:
Prendre en note le nom du nouveau fichier. C'est le «output file name» dans la session RMAN. Ce fichier sera utilisé dans la suite.
5- Renommer le fichier dans la BD:
SYS@D104 > alter database rename file '+INFO_SYSDG01/d104/datafile/users.265.726235377' to '+INFO_DATADG01/d104/datafile/users.262.726241139';
Note:
Remarquez l'utilisation du nouveau nom de fichier pris en note au point precedent.
6- Switcher le datafile vers la copie dans RMAN:
RMAN> switch datafile '+INFO_DATADG01/d104/datafile/users.262.726241139' to copy;
datafile 6 switched to datafile copy "+INFO_DATADG01/d104/datafile/users.262.726241139"
7- Recover du datafile:
SYS@D104 > recover datafile '+INFO_DATADG01/d104/datafile/users.262.726241139';
Récupération après défaillance matérielle terminée.
8- Mettre le datafile ONLINE:
SYS@D104 > ALTER DATABASE datafile '+INFO_DATADG01/d104/datafile/users.262.726241139' online;
Base de données modifiée.
8- Vérifier le nouvel emplacement du datafile:
SYS@D104 > select file_name from dba_data_files;
FILE_NAME
--------------------------------------------------------------------------------
+INFO_DATADG01/d104/datafile/users.262.726241139
...
9 rows selected.
SYS@D104 >
Note:
Avec une bd 11gR2 et ASM 11gR2, l'ancien fichier a été automatiquement détruit.
9- Remettre la BD en mode NOARCHIVELOG
SYS@D104 > shutdown immediate
Database closed.
Database dismounted.
ORACLE instance shut down.
SYS@D104 > startup mount
ORACLE instance started.
Total System Global Area 1044193280 bytes
Fixed Size 2154688 bytes
Variable Size 754982720 bytes
Database Buffers 276824064 bytes
Redo Buffers 10231808 bytes
Database mounted.
SYS@D104 > alter database noarchivelog;
Database altered.
SYS@D104 > alter database open;
Database altered.
SYS@D104 >
«503 Service Unavailable» lors de la connexion au Grid Control 10g
Il arrive que lorsque vous lancez le browser pour vous connecter au grid control 10g vous receviez le message:
"503 Service Unavailable
Service is not initialized correctly. Verifiy that the repository connection information provided is correct."
Cela peut être dû à plusieurs raisons. L'objet de cet article est de montrer une bonne piste pour rechercher la cause.
Puisque le message d'erreur parle d'initialisation vous vous dites l'OMS n'est pas démarré correctement, donc vous essayez de le démarrer et vous obtenez le message suivant:
oracle@udl001:/ucl03a_u01/home/dba/oracle> $OMS_HOME/bin/emctl start oms
error:
"Oracle Management server is not functioning because of the following reason:
Connection to repository failed.Verify that repository connection information provided is correct"
Vous essayez aussi de voir le status de l'agent:
oracle@udl001:/ucl03a_u01/home/dba/oracle> emctl status agent
Oracle Enterprise Manager 10g Release 5 Grid Control 10.2.0.5.0.
Copyright (c) 1996, 2009 Oracle Corporation. All rights reserved.
Agent Version : 10.2.0.5.0
OMS Version : 10.2.0.5.0
Protocol Version : 10.2.0.5.0
Agent Home : /ucl03a_u01/home/dba/oracle/product/agent10g
Agent binaries : /ucl03a_u01/home/dba/oracle/product/agent10g
Agent Process ID : 21970
Parent Process ID : 21464
Agent URL : http://udl001:3872/emd/main/
Repository URL : http://nobel:4889/em/upload/
Started at : 2010-03-18 16:48:17
Started by user : oracle
Last Reload : 2010-05-04 15:21:06
Last successful upload : (none)
Last attempted upload : (none)
Total Megabytes of XML files uploaded so far : 825.90
Number of XML files pending upload : 0
Size of XML files pending upload(MB) : 00.00
Available disk space on upload filesystem : 27.06%
Collection Status : Disabled by Upload Manager
Last attempted heartbeat to OMS : 2010-08-06 14:07:03
Last successful heartbeat to OMS : unknown
Agent is Running and Ready
oracle@udl001:/ucl03a_u01/home/dba/oracle>
Une bonne piste est de voir le contenu du fichier:
$OMS_HOME/sysman/log/emoms.log
Dans mon cas, il y avait le message d'erreur suivant:
2010-08-06 14:07:42,578 [ReadProxyFromRep] ERROR conn.ConnectionService verifyRepositoryEx.911 - Invalid Connection Pool. ERROR = ORA-00257: erreur du processus d'archivage ; connexion interne uniquement, jusqu'? lib?ration.
2010-08-06 14:07:49,695 [AJPRequestHandler-ApplicationServerThread-331] ERROR conn.ConnectionService verifyRepositoryEx.911 - Invalid Connection Pool. ERROR = ORA-00257: erreur
du processus d'archivage ; connexion interne uniquement, jusqu'? lib?ration.
Le message d'erreur indique qu'il y a un problème avec l'archivage. En effet, il n'y avait plus d'espace dans les diskgroup ASM qui hébergent les archives.
Après svoir fait de l'espace, j'ai pu démarrer l'OMS:
oracle@nobel:/nobel_u01/home/dba/oracle> emctl start oms
Oracle Enterprise Manager 10g Release 5 Grid Control
Copyright (c) 1996, 2009 Oracle Corporation. All rights reserved.
opmnctl: opmn is already running
Starting HTTP Server ...
Starting Oracle Management Server ...
Checking Oracle Management Server Status ...
Oracle Management Server is Up.
oracle@nobel:/nobel_u01/home/dba/oracle>
Un coup d'oeil sur le status de l'agent:
oracle@udl001:/ucl03a_u01/home/dba/oracle> emctl status agent
Oracle Enterprise Manager 10g Release 5 Grid Control 10.2.0.5.0.
Copyright (c) 1996, 2009 Oracle Corporation. All rights reserved.
---------------------------------------------------------------
Agent Version : 10.2.0.5.0
OMS Version : 10.2.0.5.0
Protocol Version : 10.2.0.5.0
Agent Home : /ucl03a_u01/home/dba/oracle/product/agent10g
Agent binaries : /ucl03a_u01/home/dba/oracle/product/agent10g
Agent Process ID : 21970
Parent Process ID : 21464
Agent URL : http://udl001:3872/emd/main/
Repository URL : http://nobel:4889/em/upload/
Started at : 2010-03-18 16:48:17
Started by user : oracle
Last Reload : 2010-05-04 15:21:06
Last successful upload : 2010-08-06 14:17:37
Total Megabytes of XML files uploaded so far : 825.90
Number of XML files pending upload : 0
Size of XML files pending upload(MB) : 0.00
Available disk space on upload filesystem : 27.06%
Last successful heartbeat to OMS : 2010-08-06 14:17:03
---------------------------------------------------------------
Agent is Running and Ready
oracle@udl001:/ucl03a_u01/home/dba/oracle>
Conclusion:
Le fichier $OMS_HOME/sysman/log/emoms.log est très important lorsqu'on recherche les causes d'un problème de démarrage de l'OMS.
"503 Service Unavailable
Service is not initialized correctly. Verifiy that the repository connection information provided is correct."
Cela peut être dû à plusieurs raisons. L'objet de cet article est de montrer une bonne piste pour rechercher la cause.
Puisque le message d'erreur parle d'initialisation vous vous dites l'OMS n'est pas démarré correctement, donc vous essayez de le démarrer et vous obtenez le message suivant:
oracle@udl001:/ucl03a_u01/home/dba/oracle> $OMS_HOME/bin/emctl start oms
error:
"Oracle Management server is not functioning because of the following reason:
Connection to repository failed.Verify that repository connection information provided is correct"
Vous essayez aussi de voir le status de l'agent:
oracle@udl001:/ucl03a_u01/home/dba/oracle> emctl status agent
Oracle Enterprise Manager 10g Release 5 Grid Control 10.2.0.5.0.
Copyright (c) 1996, 2009 Oracle Corporation. All rights reserved.
Agent Version : 10.2.0.5.0
OMS Version : 10.2.0.5.0
Protocol Version : 10.2.0.5.0
Agent Home : /ucl03a_u01/home/dba/oracle/product/agent10g
Agent binaries : /ucl03a_u01/home/dba/oracle/product/agent10g
Agent Process ID : 21970
Parent Process ID : 21464
Agent URL : http://udl001:3872/emd/main/
Repository URL : http://nobel:4889/em/upload/
Started at : 2010-03-18 16:48:17
Started by user : oracle
Last Reload : 2010-05-04 15:21:06
Last successful upload : (none)
Last attempted upload : (none)
Total Megabytes of XML files uploaded so far : 825.90
Number of XML files pending upload : 0
Size of XML files pending upload(MB) : 00.00
Available disk space on upload filesystem : 27.06%
Collection Status : Disabled by Upload Manager
Last attempted heartbeat to OMS : 2010-08-06 14:07:03
Last successful heartbeat to OMS : unknown
Agent is Running and Ready
oracle@udl001:/ucl03a_u01/home/dba/oracle>
Une bonne piste est de voir le contenu du fichier:
$OMS_HOME/sysman/log/emoms.log
Dans mon cas, il y avait le message d'erreur suivant:
2010-08-06 14:07:42,578 [ReadProxyFromRep] ERROR conn.ConnectionService verifyRepositoryEx.911 - Invalid Connection Pool. ERROR = ORA-00257: erreur du processus d'archivage ; connexion interne uniquement, jusqu'? lib?ration.
2010-08-06 14:07:49,695 [AJPRequestHandler-ApplicationServerThread-331] ERROR conn.ConnectionService verifyRepositoryEx.911 - Invalid Connection Pool. ERROR = ORA-00257: erreur
du processus d'archivage ; connexion interne uniquement, jusqu'? lib?ration.
Le message d'erreur indique qu'il y a un problème avec l'archivage. En effet, il n'y avait plus d'espace dans les diskgroup ASM qui hébergent les archives.
Après svoir fait de l'espace, j'ai pu démarrer l'OMS:
oracle@nobel:/nobel_u01/home/dba/oracle> emctl start oms
Oracle Enterprise Manager 10g Release 5 Grid Control
Copyright (c) 1996, 2009 Oracle Corporation. All rights reserved.
opmnctl: opmn is already running
Starting HTTP Server ...
Starting Oracle Management Server ...
Checking Oracle Management Server Status ...
Oracle Management Server is Up.
oracle@nobel:/nobel_u01/home/dba/oracle>
Un coup d'oeil sur le status de l'agent:
oracle@udl001:/ucl03a_u01/home/dba/oracle> emctl status agent
Oracle Enterprise Manager 10g Release 5 Grid Control 10.2.0.5.0.
Copyright (c) 1996, 2009 Oracle Corporation. All rights reserved.
---------------------------------------------------------------
Agent Version : 10.2.0.5.0
OMS Version : 10.2.0.5.0
Protocol Version : 10.2.0.5.0
Agent Home : /ucl03a_u01/home/dba/oracle/product/agent10g
Agent binaries : /ucl03a_u01/home/dba/oracle/product/agent10g
Agent Process ID : 21970
Parent Process ID : 21464
Agent URL : http://udl001:3872/emd/main/
Repository URL : http://nobel:4889/em/upload/
Started at : 2010-03-18 16:48:17
Started by user : oracle
Last Reload : 2010-05-04 15:21:06
Last successful upload : 2010-08-06 14:17:37
Total Megabytes of XML files uploaded so far : 825.90
Number of XML files pending upload : 0
Size of XML files pending upload(MB) : 0.00
Available disk space on upload filesystem : 27.06%
Last successful heartbeat to OMS : 2010-08-06 14:17:03
---------------------------------------------------------------
Agent is Running and Ready
oracle@udl001:/ucl03a_u01/home/dba/oracle>
Conclusion:
Le fichier $OMS_HOME/sysman/log/emoms.log est très important lorsqu'on recherche les causes d'un problème de démarrage de l'OMS.
mardi 3 août 2010
Problème de proprieté et de permission après avoir appliqué un patch au niveau du grid infrastructure 11.2.0.1
Avant d'appliquer un patch au niveau du grid infrastructure 11gR2, la procédure demande de déverrouiller le HOME du grid infrastructure avec la commande (étant connecté en tant que root):
# $GRID_HOME/crs/install/rootcrs.pl -unlock -crshome $GRID_HOME
Puis suivre les autres étapes pour appliquer le patch.
Note:
Je ne parlerai pas de toutes les étapes intermédiaires dépendemment du patch car ce n'est pas l'objectif de cet article. Je suis plutôt interessé par la procédure de déverrouillage/verrouillage du HOME sans perte des propriétaires et des permissions d'avant patch sur les fichiers.
Après avoir appliqué le patch il faut reverrouiller le HOME pour que les propriétaires et les permissions d'avant patch sur les fichiers soient restaurés.
La commande à utiliser est (en tant que root):
# $GRID_HOME/crs/install/rootcrs.pl -patch
Et c'est à ce niveau que se pose le problème.
En effet les proprietaires et les permissions d'avant patch ne sont pas restaurés.
Cela est dû au bug 8797450.
Voir la Note 1083982.1 pour plus de détails à ce sujet.
Lorsque j'ai rencontré ce problème, après plusieurs échanges avec Oracle et environ une semaine plus tard, Oracle a sorti la Note 1083982.1 pour proposer une solution.
Il faut dire que la solution permet d'éviter le problème si l'on l'applique avant de débuter l'installation du patch ou de corriger le problème sinon.
Selon Oracle, le bug sera corrigé dans la version 11.2.0.2 du grid infrastructure (attendons pour voir...).
L'objectif de cet article est de vous donner l'information de sorte que vous n'ayez pas à rencontrer le problème ou que vous ne perdiez pas beaucoup de temps à chercher la solution si malgré tout, vous y êtes confrontés.
En effet, Oracle ne fait aucune référence à cette note dans les README de patches du grid infrastructure 11.2.0.1.
Conséquence: Si vous n'avez pas l'information, et que vous suivez à la lettre les instructions du README, vous allez forcement rencontrer le problème et passer un certain temps en train de chercher une solution.
La solution proposée par Oracle consiste à ajouter une ligne dans le fichier $GRID_HOME/crs/install/crspatch.pm
Pour cela, procéder comme suit:
Prendre une copie du fichier avant de le modifier:
cd $GRID_HOME/crs/installcp crspatch.pm crspatch.pm.8797450
Dans le fichier, localiser la section:
instantiate_scripts ();
copy_wrapper_scripts ();
set_file_perms ();
Ajouter la ligne «create_dirs ();» de sorte à obtenir ceci:
instantiate_scripts ();
copy_wrapper_scripts ();
create_dirs ();
set_file_perms ();
Une fois le fichier modifié, déverrouiller et reverrouiller le HOME comme suit (Si vous êtes déjà confronté au problème):
En tant que root:
# $GRID_HOME/crs/install/rootcrs.pl -unlock -crshome $GRID_HOME
# $GRID_HOME/crs/install/rootcrs.pl -patch
Note:
- Si la modification est faite avant de débuter l'installation du patch (avant de déverrouiller le HOME), vous ne rencontrerez pas ce problème.
- Vérifier donc que cette ligne (create_dirs ();) existe dans le fichier crspatch.pm avant de débuter toute installation de patch au niveau du grid infrastructure 11.2.0.1 en attendant la version 11.2.0.2
# $GRID_HOME/crs/install/rootcrs.pl -unlock -crshome $GRID_HOME
Puis suivre les autres étapes pour appliquer le patch.
Note:
Je ne parlerai pas de toutes les étapes intermédiaires dépendemment du patch car ce n'est pas l'objectif de cet article. Je suis plutôt interessé par la procédure de déverrouillage/verrouillage du HOME sans perte des propriétaires et des permissions d'avant patch sur les fichiers.
Après avoir appliqué le patch il faut reverrouiller le HOME pour que les propriétaires et les permissions d'avant patch sur les fichiers soient restaurés.
La commande à utiliser est (en tant que root):
# $GRID_HOME/crs/install/rootcrs.pl -patch
Et c'est à ce niveau que se pose le problème.
En effet les proprietaires et les permissions d'avant patch ne sont pas restaurés.
Cela est dû au bug 8797450.
Voir la Note 1083982.1 pour plus de détails à ce sujet.
Lorsque j'ai rencontré ce problème, après plusieurs échanges avec Oracle et environ une semaine plus tard, Oracle a sorti la Note 1083982.1 pour proposer une solution.
Il faut dire que la solution permet d'éviter le problème si l'on l'applique avant de débuter l'installation du patch ou de corriger le problème sinon.
Selon Oracle, le bug sera corrigé dans la version 11.2.0.2 du grid infrastructure (attendons pour voir...).
L'objectif de cet article est de vous donner l'information de sorte que vous n'ayez pas à rencontrer le problème ou que vous ne perdiez pas beaucoup de temps à chercher la solution si malgré tout, vous y êtes confrontés.
En effet, Oracle ne fait aucune référence à cette note dans les README de patches du grid infrastructure 11.2.0.1.
Conséquence: Si vous n'avez pas l'information, et que vous suivez à la lettre les instructions du README, vous allez forcement rencontrer le problème et passer un certain temps en train de chercher une solution.
La solution proposée par Oracle consiste à ajouter une ligne dans le fichier $GRID_HOME/crs/install/crspatch.pm
Pour cela, procéder comme suit:
Prendre une copie du fichier avant de le modifier:
cd $GRID_HOME/crs/installcp crspatch.pm crspatch.pm.8797450
Dans le fichier, localiser la section:
instantiate_scripts ();
copy_wrapper_scripts ();
set_file_perms ();
Ajouter la ligne «create_dirs ();» de sorte à obtenir ceci:
instantiate_scripts ();
copy_wrapper_scripts ();
create_dirs ();
set_file_perms ();
Une fois le fichier modifié, déverrouiller et reverrouiller le HOME comme suit (Si vous êtes déjà confronté au problème):
En tant que root:
# $GRID_HOME/crs/install/rootcrs.pl -unlock -crshome $GRID_HOME
# $GRID_HOME/crs/install/rootcrs.pl -patch
Note:
- Si la modification est faite avant de débuter l'installation du patch (avant de déverrouiller le HOME), vous ne rencontrerez pas ce problème.
- Vérifier donc que cette ligne (create_dirs ();) existe dans le fichier crspatch.pm avant de débuter toute installation de patch au niveau du grid infrastructure 11.2.0.1 en attendant la version 11.2.0.2