Apuntar OBIEE a una nueva DB

Migrar una DB a la que apunta una instancia de OBIEE debe ser fácil, es cosa de apuntar al nuevo servidor de DB desde la configuración de OBIEE y reiniciar los servicios que corresponda. Total, por algo OBIEE es un producto tan caro ¿Cierto?

No, aún después de haber hecho lo anterior quedarán archivos residuales que aún apuntan a la DB antigua. Mal que mal, por algo se tiene trabajo como consultor de Oracle.

En fin. Es buena idea dar de baja la base de datos antigua para asegurarse que OBIEE ya no puede conectarse a ella (y de paso arruinar la consistencia de los datos).

Al reiniciar los servicios habrán tres componentes que no funcionarán. EssbaseStudio, Essbase y BIScheduler. Vamos por parte:

EssbaseStudio

Con locate encuentra un archivo server.properties, por ejemplo en un path como este: /u01/..../instances/instance1/EssbaseStudio/essbasestudio1/bin/server.properties

Allí hay unas credenciales que apuntan a la DB de _BIPLATFORM. Además de modificar la URL o IP a la nueva DB, es necesario recrear el hash de la contraseña.

Con locate busca un archivo llamado encryptPassword.sh.template, renombrarlo como .sh y añadir las variables de entorno JAVA_HOME, ORACLE_HOME y ORACLE_INSTANCE según corresponda.

Le das permisos de ejecución con chmod +x y lo ejecutas con la contraseña como parámetro.

Si te da un error de formato con caracteres extraños es porque los de Oracle se las ingenian para dejar pifias raras en sus productos. La primera vez me costó descubrir el problema, pero una vez encontrada la solución uno se dice "¿cómo no me di cuenta antes?". Para arreglar el problema basta con ejecutar el siguiente comando:

dos2unix encryptPassword.sh

Ahora si. Debería funcionar y ya puedes modificar el archivo server.properties con los parámetros que corresponden.

Essbase

Luego de revisar los logs, encontré que habían dos archivos más que seguían apuntando a la IP antigua, también necesitaban el nuevo hash. Estos archivos de llaman reg.properties y se encuentran en dos paths distintos: locate reg.properties

Con la modificación anterior se crea una inconsistencia, por lo que sigue sin poder levantarse el componente. Para ello es necesario borrar un archivo binario llamado essbase.sec (locate essbase.sec; mv essbase.sec essbase.sec.bak) y copiar un data-template llamado essbase.sec_linux en el path del archivo sec eliminado.

Con esto es posible subir el componente EssBase utilizando opmnctl y sólo nos queda un componente que arreglar.

BIScheduler

Como el componente no podía iniciarse, se sospechaba que era una regla de firewall (según los problemas que había tenido la vez anterior), pero al revisar los logs descubrí que el usuario de la DB estaba bloqueado, pero en la DB nueva no habían usuarios bloqueados a esta altura (luego de reiniciar EssbaseStudio y Essbase). Entonces la única explicación viable era que BIScheduler aún estaba apuntando a la IP antigua.

Con find hice una búsqueda recursiva y encontré la IP antigua en un archivo instanceconfig.xml, añadí los nuevos datos de conexión y recién pude subir el componente que faltaba con opmnctl.

Conclusiones

No es secreto que considero demasiado defectuosos los productos de Oracle para el precio en el que los venden. La excepción a mi gusto sería el motor de DB, que cada año es mejor. Pero bueno, estos errores tan tontos a veces nos dan trabajo, y un sueldo. Así que es mejor no quejarse.

Referencias en la documentación oficial: Doc ID 2103494.1, Note: 1676072.1, NOTE:1636367.1 y NOTE:1676072.1