domingo, 28 de agosto de 2011

Como vincular los binarios de Oracle

En este cuarto de año, mi equipo y yo estamos aplicando una seria de parches y el PSU de Julio 2011 a nuestras bases de datos, decidimos que para reducir el tiempo de baja de las Bases de Datos, vamos a construir un nuevo ORACLE_HOME con estos parches y PSU, y solamente bajar la instancia,cambiar la variable de ambiente ORACLE_HOME a la nueva y empezar la instancia.

En este metodo, lo que hicimos fue construir un solo ORACLE_HOME y clonarlo a los demas servidores, pero en este proceso nos dimos cuenta que nuestra copia "base", habia sido borrado el archivo $ORACLE_HOME/network/admin/shrept.lst. Esto causaba que la clonacion a la hora de vincular los binarios de Oracle con el sistema operativo fallaba con el siguiente error:

INFO: Calling Action unixActions10.2.0.3.0 make
registerOnly = false
installMakePath = /usr/ccs/bin/make
installMakeFileName = /mount/oracle/product/11.2.0.2v2/rdbms/lib/ins_rdbms.mk
installTarget = client_sharedlib
undoMakeFileName =
installArguments = ORACLE_HOME=/mount/oracle/product/11.2.0.2v2
logFile = /mount/oracle/product/11.2.0.2v2/install/make.log
undoTarget =
progMsg = Building Client Shared Libraries

INFO: The output of this make operation is also available at: '/mount/oracle/product/11.2.0.2v2/install/make.log'
INFO:

INFO: Start output from spawned process:
INFO: ----------------------------------
INFO:

INFO: /mount/oracle/product/11.2.0.2v2/bin/genclntsh

INFO: genclntsh: Could not locate /mount/oracle/product/11.2.0.2v2/network/admin/shrept.lst
genclntsh: exiting ...

INFO: make: Fatal error: Command failed for target `client_sharedlib'

INFO: *** Error code 1

Para poder entender lo que hicimos para solucionar este problema, hay que entender que en cualquier distribucion de un sistema operativo basado en Unix, el software de Oracle viene como archivos tipo objeto (object files) o como archivos tipo fuente (source files), estos al ser instalados en Unix se vinculan con las librerias del sistema operativo para generar el ejecutable de oracle.

Lo primero que tuvimos que hacer es recrear el archivo, ya sea de otra instalacion de 11.2.0.2 que tuviera el archivo o lo puedes extraer del cd de instalacion (Metalink id 340978.1), en este caso el contenido de nuestro archivo, es como se menciona abajo:

oracle@localhost [DBATEST] /mount/oracle/product/11.2.0.2v2/network/admin
root $ cat shrept.lst
# function entry points for genclntsh.sh

network : snaumihi_inithostinfo
network : snaumbg_gmt
network : naedpwd_encrypt
network : naumbsb_bld_singlebyte
network : ztapis
network : nlgh

Una vez que reconstruimos el archivo con el usuario oracle y permisos 644, bajamos todas las instancias y listeners que estuvieran corriendo en el ORACLE_HOME donde fallo la instalacion, y utilizamos el comando $ORACLE_HOME/bin/relink all

oracle@localhost [DBATEST] /mount/oracle/product/11.2.0.2v2/bin
root $ ./relink all
writing relink log to: /mount/oracle/product/11.2.0.2v2/install/relink.log

Este comando no te regresa un mensaje de exito, es mas bien si ocurre un error durante esta fase te muestra el mensaje de falla, como por ejemplo

'Fatal error', 'Ld: fatal', 'Exit Code 1'

Si te llega a suceder un error, lo mas recomendable es buscar en metalink, si hay otro suceso de este error o abrir un SR con oracle para resolverlo.

Conclusion
El comando de relink all es una herramienta muy util, sobre todo cuando por alguna razon los vinculos se perdieron entre Oracle y las librerias del sistema operativo.

miércoles, 17 de agosto de 2011

Problema clonando un nuevo ORACLE_HOME bug 3823729 en 11.2.0.2

En estos dias estamos tratando de crear un nuevo ORACLE_HOME que contenga el PSU de Julio asi como unos parches que requerimos, para disminuir el tiempo que necesitamos bajar la base de datos al aplicar los parches al ORACLE_HOME actual, decidimos crear un nuevo ORACLE_HOME aplicar los parches en este nuevo ORACLE_HOME, clonar este ORACLE_HOME a los servidores necesarios y nada mas mover la base de datos al nuevo ORACLE_HOME. Todo iba bien, hasta que llego el punto de clonar el nuevo ORACLE_HOME, nos topamos con un bug en donde si ya tenemos un ORACLE_HOME previo, detecta procesos arriba y no te permite continuar con la clonacion


oracle@localhost /mount/oracle
oracle $ $ORACLE_HOME/perl/bin/perl clone.pl ORACLE_BASE="/mount/oracle" ORACLE_HOME="/mount/oracle/product/11.2.0.2v2" ORACLE_HOME_NAME=11gR202v2
.
.
.
oracle $ cat /mount/oracle/oraInventory/logs/silentInstall2011-08-15_02-12-06AM.log
silentInstall2011-08-15_02-12-06AM.log
Oracle Universal Installer has detected that there are processes running in the currently selected Oracle Home. The following processes need to be shutdown before continuing:
/mount/oracle/product/11.2.0.2v1/bin/tnslsnr PSAESRV PSDSTSRV PSMONITORSRV PSMSTPRC PSPRCSRV PSRUN ora_mman_DBATEST
Oracle Universal Installer has detected that there are processes running in the currently selected Oracle Home. The following processes need to be shutdown before continuing:
/mount/oracle/product/11.2.0.2v1/bin/tnslsnr PSAESRV PSDSTSRV PSMONITORSRV PSMSTPRC PSPRCSRV PSRUN ora_mman_DBATEST
This silent installation was unsuccessful.

Como al dia de hoy no existe un parche para este bug, hicimos los siquientes pasos para poder instalar el nuevo ORACLE_HOME Con el usuario de root

root@localhost /root
root $ which fuser
/sbin/fuser

root@localhost /root
root $ mv /sbin/fuser /sbin/fuser.18082011

root@localhost /root
root $ touch /sbin/fuser

root@localhost /root
root $ chmod +x /sbin/fuser

Una vez que hicimos los pasos anteriores como root, volvemos a intentar con el usuario de oracle la clonacion del nuevo ORACLE_HOME

oracle@localhost /mount/oracle
oracle $ $ORACLE_HOME/perl/bin/perl clone.pl ORACLE_BASE="/mount/oracle" ORACLE_HOME="/mount/oracle/product/11.2.0.2v2" ORACLE_HOME_NAME=11gR202v2
.
.
.
oracle $ cat silentInstall2011-08-16_06-56-02PM.log
silentInstall2011-08-16_06-56-02PM.log
WARNING:
The following configuration scripts need to be executed as the "root" user.
/mount/oracle/product/11.2.0.2v2/root.sh
To execute the configuration scripts:
1. Open a terminal window
2. Log in as "root"
3. Run the scripts

The cloning of 11gR202v2 was successful.

Ya terminada la clonacion, ahora nada mas regresamos el archivo fuser que movimos al principio a su locacion original

root@localhost /root
root $ mv /sbin/fuser.16082011 /sbin/fuser
mv: overwrite `/sbin/fuser'? y

Conclusion 
Espero que este bug con el me tope te sirva si te llegas a topar tu con el, segun oracle esto se va a corregir en la version 11.2.0.3.