oracle@servidor1.oracleenespanol.blogspot.com [TESTDB1] /home/oracle oracle $ rman target system@TESTDB Recovery Manager: Release 11.2.0.3.0 - Production on Wed May 30 21:23:56 2012 Copyright (c) 1982, 2011, Oracle and/or its affiliates. All rights reserved. target database Password: RMAN-00571: =========================================================== RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS =============== RMAN-00571: =========================================================== RMAN-00554: initialization of internal recovery manager package failed RMAN-04005: error from target database: ORA-12537: TNS:connection closed
Lo primero que pensé es que el archivo de password estaba mal en el $RDBMS_ORACLE_HOME/dbs, lo cual no fue el caso.
Cabe decir que esta granja de servidores es nuevo, así que era la primera vez que estábamos haciendo pruebas de respaldos aquí.
Después de quebrarme un rato la cabeza buscando el problema en el sqlnet.ora , tnsnames.ora y el listener, me di cuenta de que el problema se encontraban en los permisos del binario de "oracle".
Ya que como sabes en RAC, el listener del SCAN pertenece al dueño del GI_HOME, que normalmente es el usuario grid, y de igual manera entre el usuario grid y el usuario oracle , el grupo de los binarios es el asmadmin.
Para diagnosticar el problema fue que como el usuario grid, tratamos de correr el comando de unix "ls", y me di cuenta que el listener no podía acceder a este archivo binario:
grid@servidor1.oracleenespanol.blogspot.com [TESTDB1] /home/grid grid $ ls -l $RDBMS_ORACLE_HOME/bin/oracle ls: /mount/oracle/product/11.2.0.3v1/bin/oracle: Permission denied
Una vez que me di cuenta de este problema, lo único que tenia que hacer es cambiar el grupo y los permisos del archivo binario "oracle" y de igual manera asegurarme que el bit suid del archivo sea el correcto, teniendo en si permisos 6751, y esto tiene que ser en todos los RBDMS_ORACLE_HOME de la granja de servidores que tienes
oracle@servidor1.oracleenespanol.blogspot.com [TESTDB1] /home/oracle oracle $ cd $ORACLE_HOME/bin oracle@servidor1.oracleenespanol.blogspot.com [TESTDB1] /mount/oracle/product/11.2.0.3v1/bin oracle $ ls -lart oracle -rwsr-s--x 1 oracle dba 232399431 Mar 17 07:57 oracle oracle@servidor1.oracleenespanol.blogspot.com [TESTDB1] /mount/oracle/product/11.2.0.3v1/bin oracle $ chgrp asmadmin oracle oracle@servidor1.oracleenespanol.blogspot.com [TESTDB1] /mount/oracle/product/11.2.0.3v1/bin oracle $ chmod 6751 oracle
Cuando cambiamos los permisos de este archivo, no tuvimos ningún problema en acceder vía el listener, así que no se te olvide este paso cuando estas instalando manualmente el RDBMS_ORACLE_HOME:
oracle@servidor1.oracleenespanol.blogspot.com [TESTDB1] /home/oracle oracle $ rman target system@TESTDB Recovery Manager: Release 11.2.0.3.0 - Production on Wed May 30 21:23:56 2012 Copyright (c) 1982, 2011, Oracle and/or its affiliates. All rights reserved. target database Password: connected to target database: TESTDB (DBID=643988434) RMAN> show all; using target database control file instead of recovery catalog RMAN configuration parameters for database with db_unique_name TESTDB are: CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF 35 DAYS; CONFIGURE BACKUP OPTIMIZATION ON; CONFIGURE DEFAULT DEVICE TYPE TO DISK; CONFIGURE CONTROLFILE AUTOBACKUP ON; CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO '/mount/copy01/TESTDB/oracle/TESTDB/control/%F'; CONFIGURE DEVICE TYPE DISK PARALLELISM 2 BACKUP TYPE TO COMPRESSED BACKUPSET; CONFIGURE DATAFILE BACKUP COPIES FOR DEVICE TYPE DISK TO 1; CONFIGURE ARCHIVELOG BACKUP COPIES FOR DEVICE TYPE DISK TO 1; CONFIGURE CHANNEL DEVICE TYPE DISK FORMAT '/mount/copy01/TESTDB/oracle/TESTDB/full/%U'; CONFIGURE MAXSETSIZE TO UNLIMITED; CONFIGURE ENCRYPTION FOR DATABASE OFF; CONFIGURE ENCRYPTION ALGORITHM 'AES128'; CONFIGURE COMPRESSION ALGORITHM 'BASIC' AS OF RELEASE 'DEFAULT' OPTIMIZE FOR LOAD TRUE; CONFIGURE ARCHIVELOG DELETION POLICY TO NONE; CONFIGURE SNAPSHOT CONTROLFILE NAME TO '/mount/copy01/TESTDB/oracle/TESTDB/control/snapcf_TESTDB.f';
Ha pasado mucho, pero algo parecido me ha pasado con una 19 montando el SE2HA, no me hacía el relocate al segundo nodo. Eran los permisos del binario de oracle:
ResponderBorrarEstaban así:
-rwxr-s--x.
Y deben esta así:
-rwsr-s--x.