REAL APPLICATION CLUSTER

Transcripción

1 Oficina Técnica para la Gestión y Supervisión de Servicios TIC Subdirección de Tecnologías de la Información BEST PRACTICES DE CONFIGURACIÓN DE UN ORACLE STREAMS EN ENTORNOS ORACLE REAL APPLICATION CLUSTER Referencia documento: InfV5_JASAS_BestPractices_Streams_vs_RAC_V230.doc Fecha: Versión: 2.3.0

2 Registro de Cambios Fecha Autor Versión Notas 14 de Octubre de 2010 Jonathan Ortiz Versión inicial 13 de Enero de 2011 Jonathan Ortiz 2.10 Revision Enero 2011 Jonathan Ortiz Revision Abril 2011 Jonathan Ortiz Revisión Julio 2011 Revisiones Nombre Emilio Nestal Role Advanced Services Engineer Distribución Copia Nombre Empresa 1 Subdirección de Tecnologías de la Información 2 Servicio de Coordinación de Informática de la Consejería de Innovación Servicio Andaluz de Salud, Junta de Andalucía Consejería de Innovación, Junta de Andalucía Certificado ISO Pág. 2 / 11

3 Índice de Contenidos CONTROL DE CAMBIOS...4 INTRODUCCIÓN...5 OBJETIVOS DE ESTE DOCUMENTO...6 BEST PRACTICES PARA STREAMS EN ENTORNOS RAC...7 Configuración adicional a realizar en entornos RAC para una base de datos Origen de Streams..7 Configuración adicional a realizar en entornos RAC para una base de datos Destino de Streams10 Certificado ISO Pág. 3 / 11

4 Control de cambios Cambio Descripción Página No se han realizado cambios en esta versión Certificado ISO Pág. 4 / 11

5 Introducción Este documento recoge una serie de recomendaciones de Oracle Soporte planteadas como buenas prácticas para realizar una correcta configuración que hagan uso de Oracle RDBMS 10gR2 o 11g y Oracle Streams 10gR2 o 11g. Estas recomendaciones están encaminadas a minimizar los posibles problemas de configuración y rendimiento en bases de datos con Oracle Streams. Oracle Streams permite la compartición de datos a través de la replicación de datos desde una base de datos a otra, este documento esta centrado en la configuración de estas bases de datos en los casos de que formen parte de un Oracle Real Application Cluster. Certificado ISO Pág. 5 / 11

6 Objetivos de este documento A lo largo de los puntos de este documento se irá definiendo una guía de buenas prácticas para la configuración de bases de datos en clúster Oracle RDBMS Real Application Cluster (RAC) que a su vez forman parte de un entorno de replicación Oracle RDBMS Streams. El objetivo de esta guía de buenas prácticas tiene varios objetivos: Una correcta configuración de Oracle Streams en entornos Oracle RDBMS Real Application Cluster. Facilitar la gestión y administración y de las bases de datos en producción con sistemas basados en Oracle RDBMS Real Application Cluster y Oracle Streams. Certificado ISO Pág. 6 / 11

7 Best Practices para Streams en entornos RAC En este apartado se tendrá en cuenta si la base de datos en Oracle RAC, es la base de datos Origen o Destino de los datos de replicación. Configuración adicional a realizar en entornos RAC para una base de datos Origen de Streams Archive Logs Los threads de archivelogs de todas las instancias del clúster deben estar disponible desde cualquier otra instancia en ejecución para que pueda ser leído por un proceso de captura. Esto es cierto tanto para la captura local como para las realizadas en entornos Downstreams. Se recomienda que el área de recuperación flash (FRA) no sea la ubicación de los registros archivados, porque los archivos de archivelogs pueden ser borrados de la FRA, incluso si los procesos de captura esta pendiente de leerlos. Propietarios de las colas ( Queues ) Cuando Streams se configura en un entorno RAC, cada tabla queue tiene una instancia propietaria, es decir, cada cola esta asociada a una instancia especifica del cluster. Todas las colas que hagan uso de la misma tabla de colas estarán aosciadas a la misma instancia. Los componentes de Stremas (captura / propagación / aplicación) todos usaran esa misma instancia para realizar su trabajo. Esto significa que Un proceso de captura estara ejecutandose en la misma instancia que sea propietaria de la queue fuente. Un job de propagacion debe ejecutarse en la misma instancia que sea propietaria de la queue. Un job de propagacion debe conectar con la instancia que sea propietaria de la queue destino a la que tenga que propagar la información. La propiedad de la cola puede ser configurada para permanecer en una instancia específica, siempre que esa instancia está disponible, mediante el establecimiento de los parámetros PRIMARY_INSTANCE y SECONDARY_INSTANCE a través del siguiente procedimiento DBMS_AQADM.ALTER_QUEUE_TABLE. Si el primary_instance se establece en un caso específico (es decir, no es 0), la cola volverá a la instancia propietaria cada vez que la instancia este disponible. El proceso de Captura automáticamente se cambiara a la instancia propietaria de la cola. Si la instancia propietaria cambia mientras se está ejecutando procesos de Certificado ISO Pág. 7 / 11

8 captura, el proceso de captura parara en la antigua instancia propietaria y se reiniciara en la nueva instancia propietaria de la cola. Para colas creadas con Oracle Database 10g Release 2, un servicio se creará con el nombre del servicio igual a schema.queue y el nombre de la red SYS$schema.queue.global_name para esa cola. Si el global_name de la base de datos no coincide con el nombre db_name.db_domain de la base de datos, asegúrese de incluir la global_name como un nombre de servicio en el init.ora. Para propagaciones creadas con la base de datos Oracle 10g Release 2 con el parámetro queue_to_queue a TRUE, el job de propagación solo lo entregara a la cola específica. Además, el DBLink en la base de datos origen hacia la base de datos destino debe especificar el servicio correcto (nombre global de la base de datos de destino) para conectarse a la base de datos de destino. Por ejemplo, la entrada tnsnames.ora para la base de datos de destino debe incluir la cláusula de CONNECT_DATA en el descriptor de conexión para la base de datos de destino. Este clausula debe especificar (CONNECT_DATA=(SERVICE_NAME='global_name de base de datos destino' )). No incluya una instancia específica en la cláusula CONNECT_DATA. Por ejemplo, considere configurar el archivo tnsnames.ora de una base de datos con el global name la db_name.db_domain. Asumiendo que el nombre de la primera instancia es DB1 y que el nombre de la segunda instancia de DB2. El archivo tnsnames.ora de la base de datos podría incluir las siguientes entradas: Entradas en el fichero de Tnsnames.ora db_name.db_domain= (description= (load_balance=on) (address=(protocol=tcp)(host=node1-vip)(port=1521)) (address=(protocol=tcp)(host=node2-vip)(port=1521)) (connect_data= (service_name=db_name.db_domain))) db1.db_domain = (description= (address=(protocol=tcp)(host=node1-vip)(port=1521)) (connect_data= (service_name db_name.db_domain) (instance_name=db1))) db2.db_domain= (description= (address=(protocol=tcp)(host=node2-vip)(port=1521)) (connect_data= (service_name= db_name.db_domain) (instance_name=db2))) Certificado ISO Pág. 8 / 11

9 Usar la entrada en negrita del tnsnames.ora mostrado en la tabla anterior dentro de la clausula using dentro del database link que se cree hacia la base de datos destino. DBA_SERVICES lista todos los servicios de la base de datos. GV$ACTIVE_SERVICES identifica todos los activos servicios para la base de datos, en entornos single-instance el service_name típicamente coincide con el global_name. Sin embargo es posible que usuarios manualmente creen servicios alternativos y hagan uso de ellos en la especificación del parámetro connect_data de la entrada en el tnsnames.ora. Para Configuraciones en RAC, el servicio aparecerá en las vistas como SYS$schema.queue.global_name. Reinicio del proceso de Propagacion Usa el procedimiento de START_PROPAGATION y STOP_PROPAGATION desde el paquete DBMS_PROPAGATION_ADM para habilitar y deshabilitar la programación de la propagación. Estos procedimientos son ejecutados automáticamente cuando esta configurado la propagación queue_to_queue. Ejemplo de comando de propagación Parada del proceso de propagación: DBMS_PROPAGATION_ADM.stop_propagation('name_of_propagation'); DBMS_PROPAGATION_ADM.stop_propagation('name_of_propagation',force=> true); Arranque del proceso de propagación: DBMS_PROPAGATION_ADM.start_propagation('name_of_propagation'); Si utiliza los procedimientos del paquete DBMS_AQADM para administrar la programación de la propagación, asegúrese de especificar explícitamente el nombre destination_queue cuando la propagación se ha configurado con queue_to_queue. Ejemplo de comando de propagación Certificado ISO Pág. 9 / 11

10 Ejemplo de comando de propagación DBMS_AQADM.UNSCHEDULE_PROPAGATION('source_queue_name','destination',destination_queue=>'specific_queue'); DBMS_AQADM.SCHEDULE_PROPAGATION('source_queue_name','destination',d estination_queue=>'specific_queue'); DBMS_AQADM.ENABLE_PROPAGATION_SCHEDULE('source_queue_name','destina tion',destination_queue=>'specific_queue'); DBMS_AQADM.DISABLE_PROPAGATION_SCHEDULE('source_queue_name','destin ation',destination_queue=>'specific_queue'); DBMS_AQADM.ALTER_PROPAGATION_SCHEDULE('source_queue_name','destinat ion',destination_queue=>'specific_queue'); Cambio del GLOBAL_NAME en la base de datos Origen de datos La siguiente recomendación es una consideración adicional que tenemos que tener en cuenta en un entorno de Streams cuando se ejecuta en bases de datos en RAC. Si el GLOBAL_NAME de la base de dats es modificado, asegurate que todos los procesos de propagación son borrados y recreados con el parámetro queue_to_queue modificado a TRUE. Ademas, si el GLOBAL_NAME no coincide con db_name.db_domain de la base de datos, incluye el global_name para la queue ( Network_name en dba_queue ) en la lista de servicios dentro del fichero de parameteros para la base de datos. Configuración adicional a realizar en entornos RAC para una base de datos Destino de Streams Propietario de la Cola (Queue) Cuando Stremas esta configurado en un entorno en RAC, cada tabla queue esta asociada a una instancia que es propietaria de esta cola. Todas las co Cuando Streams se configura en un entorno RAC, cada tabla queue tiene una instancia propietaria, es decir, cada cola esta asociada a una instancia especifica del cluster. Todas las colas que hagan uso de la misma tabla de colas estarán aosciadas a la misma instancia. Los componentes de Stremas (captura / propagación / aplicación) todos usaran esa misma instancia para realizar su trabajo. Esto significa que El database link especificado en el proceso de propagacion debe conectar con la instancia propietaria de la cola destino. Certificado ISO Pág. 10 / 11

11 El proceso de apply tiene que estar ejecutandose en la misma instancia donde se encuentra la queue destino. La propiedad de la cola puede ser configurada para permanecer en una instancia específica, siempre que esa instancia está disponible, mediante el establecimiento de los parámetros PRIMARY_INSTANCE y SECONDARY_INSTANCE a través del siguiente procedimiento DBMS_AQADM.ALTER_QUEUE_TABLE. Si el primary_instance se establece en un caso específico (es decir, no es 0), la cola volverá a la instancia propietaria cada vez que la instancia este disponible. El proceso de Apply automáticamente se cambiara a la instancia propietaria de la cola. Si la instancia propietaria cambia mientras se está ejecutando procesos de apply, el proceso de apply parara en la antigua instancia propietaria y se reiniciara en la nueva instancia propietaria de la cola. Cambio del GLOBAL_NAME de la base de datos Destino Si el GLOBAL_NAME de la base de datos es modificado, asegurar que la queue esta vacia antes de cambiar el nombre del global_name y que el proceso de apply es borrado y recreado con el parámetro apply_captured a TRUE. Ademas, si el GLOBAL_NAME no coincide con el db_name.db_domain de la base de datos, incluir el GLOBAL_NAME en la lista de servicios del fichero de parámetros de la base de datos. Certificado ISO Pág. 11 / 11