Recientemente he tenido la oportunidad de configurar Alfresco contra un Oracle RAC. Además la suerte ha sido doble porque inicialmente se configuró contra un RAC de 10g y posteriormente se ha migrado a un 11g, con lo cual hemos podido comprobar el funcionamiento en ambas versiones.
De cara a Alfresco el tema del RAC es transparente ya que los cambios de configuración se realizan a nivel del driver de conexión. Vamos a ver la configuración utilizada:
db.name=alfresco
db.username=alfresco
db.password=alfresco
db.driver=oracle.jdbc.OracleDriver
db.url=jdbc:oracle:thin:@(DESCRIPTION=(LOAD_BALANCE=on)(ADDRESS=(PROTOCOL=TCP)(HOST=nodo1-vip.red.dominio.es)(PORT=1521))(ADDRESS=(PROTOCOL=TCP)(HOST=nodo2-vip.red.dominio.es)(PORT=1521))(CONNECT_DATA=(SERVICE_NAME=LAN_APLICACIONES.red.dominio.es)))
db.pool.validate.query=SELECT 1 FROM DUAL
hibernate.default_schema=ALFRESCO
El cambio para Oracle RAC está en la cadena de conexión. Vamos a ver uno a uno los parámetros de esta cadena de conexión:
DESCRIPTION
contiene el descriptor de conexión, es decir todos los parámetros que se van a usar para conectar. En este caso teniamos el RAC con 2 nodos con lo cual solo teniamos un único descriptor. Sería posible para instalaciones mas complejas tener una lista de descriptores y cada descriptor a su vez con varios servidores. Por ejemplo:
(DESCRIPTION_LIST=
(DESCRIPTION=
(ADDRESS=(protocol_address_information))
(ADDRESS=(protocol_address_information))
(ADDRESS=(protocol_address_information))
(CONNECT_DATA=
(SERVICE_NAME=service_name)))
(DESCRIPTION=
(ADDRESS=(protocol_address_information))
(ADDRESS=(protocol_address_information))
(ADDRESS=(protocol_address_information))
(CONNECT_DATA=
(SERVICE_NAME=service_name))))
LOAD_BALANCE
Indica si se van a usar las direcciones de forma aleatoria (activo) o de forma secuencial (desactivado). Se puede especificar cualquiera de estos valores que podemos encontrar en diferentes ejemplos:
on | off | yes | no | true | false
ADDRESS contiene el PROTOCOL, ADDRESS, PORT
que se explican por si mismas
CONNECT_DATA contiene la identificación del servicio .
SERVICE_NAME
En este caso no estamos usando un SID, el cual apuntaría solo a uno de los nodos, si no que se define un servicio a nivel de Oracle y se apunta contra este.
Es posible que nos encontremos ejemplos en los que en la cadena de conexión aparece también el parámetro
FAILOVER. Este parámetro esta por defecto activado para los descriptores así que no será necesario incluirlo a no ser que queramos desactivarlo.
Desde el servidor podemos ver como las conexiones se empiezan a balancear entre los nodos:
[tomcat]# lsof -nPi |grep 1521
tnslsnr 22544 oracle 11u IPv6 996133 TCP *:1521 (LISTEN)
jsvc 28316 alfresco 231u IPv6 1026752 TCP 172.17.1.154:55223->172.17.31.23:1521 (ESTABLISHED)
jsvc 28316 alfresco 232u IPv6 1026753 TCP 172.17.1.154:55224->172.17.31.23:1521 (ESTABLISHED)
jsvc 28316 alfresco 233u IPv6 1026754 TCP 172.17.1.154:55667->172.17.31.21:1521 (ESTABLISHED)
jsvc 28316 alfresco 234u IPv6 1026755 TCP 172.17.1.154:55226->172.17.31.23:1521 (ESTABLISHED)
jsvc 28316 alfresco 235u IPv6 1026756 TCP 172.17.1.154:55227->172.17.31.23:1521 (ESTABLISHED)
jsvc 28316 alfresco 236u IPv6 1026757 TCP 172.17.1.154:55228->172.17.31.23:1521 (ESTABLISHED)
jsvc 28316 alfresco 237u IPv6 1026758 TCP 172.17.1.154:55671->172.17.31.21:1521 (ESTABLISHED)
jsvc 28316 alfresco 238u IPv6 1026759 TCP 172.17.1.154:55230->172.17.31.23:1521 (ESTABLISHED)
jsvc 28316 alfresco 239u IPv6 1026760 TCP 172.17.1.154:55231->172.17.31.23:1521 (ESTABLISHED)
Es importante recordar que el esquema para el parámetro
hibernate.default_schema se debe incluir siempre en mayúsculas, ya que de otro modo el primer arranque funcionará correctamente pero en el segundo recibiriamos un error de Schema upgrade failed
http://download.oracle.com/docs/cd/B28359_01/network.111/b28317/tnsnames.htm
http://wiki.alfresco.com/wiki/Database_Configuration#Oracle_example
