Actualización, consolidación, migración y contingencia de un entorno hardware y software para la gestión de bases de datos
Abstract
El objetivo de este trabajo es el de actualizar un entorno de gestión de bases de datos existente a la versión 11.2 del software de bases de datos Oracle y a una plataforma hardware de última generación. Se migran con tiempo de parada cero varias bases de datos dispersas en distintos servidores a un entorno consolidado de dos nodos dispuestos en alta disponibilidad tipo "activo-activo" mediante Oracle RAC y respaldado por un entorno de contingencia totalmente independiente y sincronizado en tiempo real mediante Oracle GoldenGate. Se realiza un estudio del entorno actual y, realizando una estimación de crecimiento, se propone una configuración de hardware y software mínima para implementar con garantías de éxito los requerimientos del entorno de gestión de bases de datos a corto y medio plazo. Una vez adquirido el hardware, se lleva a cabo la instalación, actualización y configuración del Sistema Operativo y el acceso redundado de los servidores a la cabina de almacenamiento. Posteriormente se instala el software de clúster de Oracle, el software de la base de datos y se crea una instancia que albergará los esquemas requeridos de las bases de datos a consolidar. Seguidamente se migran los esquemas al entorno consolidado y se establece la replicación de éstos en tiempo real con la máquina de contingencia usando en ambos casos Oracle GoldenGate. Finalmente se crea y prueba un esquema de copias de seguridad que incluye copias lógicas y físicas de la propia base de datos y de archivos de configuración del clúster a partir de los cuales será posible restaurar el entorno completamente.
Full text
Actualización, consolidación, migración y contingencia de un entorno hardware y software para la gestión de bases de datos Autor: Juan Rafael García Santana Tutor: Gabino Padrón Morales Departamento de Informática y Sistemas Las Palmas de Gran Canaria, 30 de agosto de 2013
Índice Índice ................................................................................................................................ 3 Prólogo ............................................................................................................................. 7 Agradecimientos ............................................................................................................... 8 Contexto actual ................................................................................................................. 9 Entorno de software y hardware ................................................................................... 9 Problemática actual .................................................................................................... 10 Objetivos ......................................................................................................................... 12 Objetivos académicos .................................................................................................. 12 Objetivos de este Trabajo de Fin de Grado ................................................................ 12 Competencias ................................................................................................................. 14 CII01............................................................................................................................ 14 CII02............................................................................................................................ 14 CII04............................................................................................................................ 15 Introducción ......................................................................................................... 15 Marco del proyecto ............................................................................................... 16 Objetivos del proyecto ....................................................................................... 16 Alcance del proyecto ......................................................................................... 16 Requisitos técnicos ............................................................................................ 19 Planificación ......................................................................................................... 19 Descripción del equipo de trabajo .................................................................... 19 Plan de trabajo .................................................................................................. 20 Anexo I. Planificación temporal del proyecto ...................................................... 21 Servicio de Análisis genérico previo a la migración ........................................ 21 Servicio de migración completa de las instancias de base de datos ................. 21 Servicio de creación y puesta en marcha del servidor de contingencia ........... 25 Aspectos que están fuera del alcance de esta propuesta ...................................... 26 Condiciones generales .......................................................................................... 26 Condiciones económicas ...................................................................................... 27 Condiciones legales .............................................................................................. 27
CII18............................................................................................................................ 28 Aportación al entorno socio-económico ........................................................................ 29 Actualización y mejora del hardware ......................................................................... 29 Actualización del software de gestión de bases de datos ............................................ 29 Reorganización y mejora de la infraestructura .......................................................... 30 Normativa y legislación .................................................................................................. 32 Normativa y regulación de la información en el ámbito internacional .................. 32 Estados Unidos ..................................................................................................... 33 Alemania ............................................................................................................... 33 Austria .................................................................................................................. 33 Gran Bretaña ........................................................................................................ 34 Holanda ................................................................................................................ 34 Francia ................................................................................................................. 34 Chile ..................................................................................................................... 35 Normativa y regulación de la informática en el ámbito europeo ............................ 35 Normativa y regulación de la informática en el ámbito nacional ........................... 36 Leyes y Decretos Ley. ........................................................................................... 36 Código penal ............................................................................................................ 37 Recomendaciones de la Agencia de Protección de Datos. ...................................... 37 Información en la recogida de datos .................................................................... 37 Finalidad para la que se recogen los datos ......................................................... 38 Seguridad en el intercambio de datos .................................................................. 38 Protección jurídica de programas de ordenador (piratería informática) ........... 39 ¿En qué casos se infringe la Ley? ........................................................................ 39 Medidas judiciales ................................................................................................ 40 Licencias de software ............................................................................................... 40 Plan de trabajo ............................................................................................................... 42 Análisis ........................................................................................................................... 44 Requerimientos de software ........................................................................................ 44 Requerimientos de hardware ...................................................................................... 46 Procesador ............................................................................................................... 46 Memoria RAM .......................................................................................................... 48
Almacenamiento ....................................................................................................... 49 Nodos del RAC. Almacenamiento local ................................................................ 49 Nodos del RAC. Almacenamiento externo ............................................................ 50 Servidor de contingencia. Almacenamiento local ................................................ 52 Conectividad ............................................................................................................ 52 Nodos del RAC ..................................................................................................... 53 Servidor de contingencia ...................................................................................... 54 Despliegue usando VLANs ................................................................................... 55 Red de almacenamiento y red pública .................................................................. 58 Hardware. Resumen de la configuración mínima recomendada............................. 60 Configuración definitiva adquirida por el cliente....................................................... 61 Distribución del almacenamiento ............................................................................... 62 Desarrollo ....................................................................................................................... 67 Instalación del hardware y configuración de la cabina de discos .............................. 67 Instalación de Oracle Linux ........................................................................................ 69 Instalación de Oracle Clusterware ............................................................................. 80 Instalación del software de Oracle RAC ..................................................................... 86 Creación de la instancia de base de datos en RAC..................................................... 95 Creación de la base de datos de contingencia .......................................................... 101 Instalación de Oracle GoldenGate en el RAC .......................................................... 104 Instalación de GoldenGate en la máquina de contingencia ..................................... 106 Instalación de GoldenGate en el servidor ROSS ...................................................... 107 Replicación del esquema FIN ................................................................................... 109 Aplicación del Patch Set Update al software de Oracle en el RAC .......................... 115 Configuración de GoldenGate en Alta Disponibilidad en el RAC............................ 117 Instalación de GoldenGate en la máquina APTAE ................................................... 121 Migración de los esquemas de Alfresco y Administración Electrónica .................... 122 Migración de los esquemas de SIME ........................................................................ 130 Instalación de STATSPACK en la base de datos del RAC y en la de contingencia . 140 Esquema de copias de seguridad propuesto para el clúster y su base de datos ...... 146 Esquema de copias. Visión general ....................................................................... 147 Esquema de copias. Detalle ................................................................................... 147
Diferencias de configuración de los scripts de copia en cada nodo ..................... 150 Modificaciones a los scripts de copia al añadir o eliminar un nodo .................... 151 Modificaciones al añadir o eliminar una instancia de base de datos ................... 152 Ejemplo de recuperación del servicio tras la pérdida total de discos del clúster . 152 Scripts de backup del clúster y de la base de datos en RAC ..................................... 161 Habilitar “huge pages” en las máquinas del RAC y contingencia........................... 191 Replicación de los esquemas de Alfresco y Admón. Electrónica en contingencia ... 198 Replicación de los esquemas de SIME en contingencia ........................................... 207 Conclusiones ................................................................................................................. 214 Bibliografía ................................................................................................................... 216
Actualización consolidación, migración y contingencia de un entorno hardware y software para la gestión de bases de datos Página 7 Prólogo En los entornos informáticos es habitual la realización de actualizaciones de los componentes tanto hardware como software por distintos motivos. La obsolescencia de los componentes que ya no se adaptan a los requerimientos del negocio o la modificación de éstos requerimientos a lo largo del tiempo figuran entre los motivos principales por los que, llegado el momento, una organización decide actualizar sus sistemas informáticos. El escenario de migración en el que está basado este Trabajo Fin de Grado se enmarca dentro de un proyecto real de migración de un entorno completo de hardware y software para el soporte de un gestor de bases de datos Oracle. En este escenario, la organización para la que se realizaron los trabajos necesitaba actualizar los componentes hardware que habían quedado obsoletos a lo largo de los años y necesitaba, así mismo, consolidar en un entorno centralizado las distintas bases de datos dispersas en varios servidores dentro de la organización además de actualizarlas a la última versión de Oracle disponible en el momento del comienzo del proyecto. Dado que la magnitud del proyecto real de migración escaparía a los objetivos de este Trabajo de Fin de Grado, se han reflejado en este trabajo las tareas principales del mismo de tal forma que el conjunto de todas ellas permita tomar este documento como base para realizar cualquier migración de este tipo con garantías de éxito.
Actualización consolidación, migración y contingencia de un entorno hardware y software para la gestión de bases de datos Página 8 Agradecimientos Quisiera expresar mi más sincero agradecimiento a todas aquellas personas que, en alguna medida, me han aportado algo durante el desarrollo de este Trabajo de Fin de Grado. En primer lugar agradecer a mi familia por el apoyo incondicional imprescindible para realizar este trabajo y la paciencia para soportar mis rabietas y cambios de humor cuando algo no salía como esperaba. A mis compañeros de la empresa en la que trabajo por al apoyo y por sus sabios consejos basados en su dilatada experiencia. Y, por supuesto, a mi tutor, Gabino, por su apoyo, ayuda y consejos y por empujarme constantemente para que no me durmiera en los laureles y llevar este Trabajo a feliz término.
Actualización consolidación, migración y contingencia de un entorno hardware y software para la gestión de bases de datos Página 9 Contexto actual Entorno de software y hardware El entorno software actual objeto de la migración consta de tres bases de datos Oracle todas ellas con distintas versiones de software ya obsoletas que carecen de soporte por parte del vendedor. Una de las bases de datos, además, está en un entorno virtualizado que tampoco está soportado por el fabricante. La base de datos principal se denomina DRAGO y tiene como características principales: • Versión: Oracle 9i (9.2.0.4) Enterprise Edition • Tamaño aproximado de archivos de datos: 300GB • Aproximadamente 200 tablespaces • Aproximadamente 360 usuarios/esquemas Los esquemas de esta base de datos soportan la gran mayoría de las aplicaciones empleadas en la organización, tanto propietarias como de terceros, que tienen como “backend” una base de datos Oracle. La segunda base de datos a migrar se denomina ROSS y sus características principales son: • Versión: Oracle 10g (10.2.0.3) Enterprise Edition • Tamaño aproximado de archivos de datos: 16 GB • Aproximadamente 10 tablespaces • Aproximadamente 30 usuarios/esquemas Esta base de datos da soporte a la aplicación ECOFIN exclusivamente. Finalmente, la tercera base de datos a migrar se denomina APTE y éstas son sus características principales: • Versión: Oracle 10g (10.2.0.1) Enterprise Edition • Tamaño aproximado de archivos de datos: 180 GB • Aproximadamente 30 tablespaces • Aproximadamente 40 usuarios/esquemas La organización no necesita migrar todos los esquemas de las bases de datos pues muchos de ellos pertenecen a aplicaciones que ya están obsoletas, son esquemas de
Actualización consolidación, migración y contingencia de un entorno hardware y software para la gestión de bases de datos Página 16 elaborar esta propuesta, se ha entendido que deben estar fuera del alcance de la misma. ANEXO I.- Planificación Temporal de los Trabajos. Marco del proyecto Objetivos del proyecto El proyecto persigue los siguientes objetivos: Asesoramiento previo al Cliente indicando los posibles problemas y adaptaciones necesarias identificados por Oracle para el proceso de migración y consolidación de base de datos. Estudio de licenciamiento de los productos Oracle necesarios para implementar el esquema de consolidación propuesto. Migración de las bases de datos de la Oraganización a Oracle RAC 11gR2 de 2 nodos. Establecimiento de un mecanismo de contingencia para las bases de datos migradas. Alcance del proyecto El proyecto abarca los siguientes aspectos: Servicio de análisis genérico previo a la migración 1. Recopilación de información genérica sobre la migración Se recopilará, a nivel genérico y a partir de notas de Oracle Support, información sobre la migración. De esta forma se identificarán los problemas, cambios y errores que pueden producirse en la migración a la versión 11g y que podrían afectar a las bases de datos y a las aplicaciones que soportan. La información recopilada incluye las matrices de certificación y errores encontrados para los conectores ODBC, JDBC y ODP.NET. 2. Elaboración y envío al cliente de un informe con la información recopilada. Esta información permitirá al cliente conocer de antemano los problemas identificados por Oracle a la hora de migrar bases de datos 9i y 10g a la versión 11g con la que podrá informar a los proveedores de las aplicaciones de los posibles cambios a realizar en las mismas. Servicio de migración completa de las instancias de base de datos Para la realización de este servicio es imprescindible que se hayan completado todas las tareas del servicio “Análisis previo a la migración”.
Actualización consolidación, migración y contingencia de un entorno hardware y software para la gestión de bases de datos Página 17 En este servicio se realiza la migración de las bases de datos ROSS, APTAE y DRAGO a un RAC 11gR2 de dos nodos. Para las tareas de migración se utilizará el software Oracle GoldenGate que reducirá al mínimo el tiempo de parada de la actividad a usuarios y aplicaciones. A continuación se describen las tareas a realizar. 1. Determinar e informar al cliente sobre los requisitos de hardware y software (sistema operativo y parches) necesarios para la instalación y puesta en marcha del RAC y de las bases de datos destino. En particular se informa al cliente de los requisitos de licenciamiento de productos Oracle necesarios. 2. Preparación del entorno en los dos servidores del RAC para la instalación del software de clúster (Grid Infrastructure) y el software de base de datos Oracle. 3. Instalación en ambos nodos del software de cluster que incluye la creación de las dos instancias ASM para la administración del almacenamiento compartido. Esta tarea requiere que el servidor tenga instalado el sistema operativo y los parches mínimos para la instalación. Es necesario, así mismo, que el almacenamiento externo y compartido por los dos nodos del RAC esté configurado y visible en ambos nodos y que la infraestructura de red necesaria para el RAC esté configurada (red de interconexión entre nodos y la red pública) y esté disponible el conjunto de direcciones IP virtuales requerido. 4. Instalación de la nueva versión del software de Base de Datos Oracle en los dos nodos del RAC. Esta tarea requiere que el servidor tenga instalado el sistema operativo y los parches mínimos para la instalación. 5. Creación de las instancias de base de datos en el RAC destino. 6. Estudio previo de los entornos origen y destino y configuración de ambos entornos para la instalación de Oracle GoldenGate. 7. Instalación y pruebas de Oracle GoldenGate en las tres máquinas origen y en los dos nodos del RAC. 8. Configuración de Oracle GoldenGate para la lectura de las bases de datos origen y configuración de Oracle GoldenGate para la entrega de los datos leídos en origen. Estas tareas incluyen las correspondientes pruebas de funcionamiento. 9. Exportación consistente de las bases de datos origen a un punto concreto en el tiempo (o SCN) e importación en el entorno RAC destino. 10. Activación de la réplica entre las bases de datos origen y destino.
Actualización consolidación, migración y contingencia de un entorno hardware y software para la gestión de bases de datos Página 18 11. Pruebas de compatibilidad de las aplicaciones existentes con las nuevas bases de datos. Estas pruebas serán realizadas por el Cliente. 12. Seguimiento del funcionamiento del sistema migrado para detectar posibles problemas. 13. Ajustes post-migración a las bases de datos. 14. Configuración y prueba de la política de copias de seguridad de la base de datos. 15. Elaboración y envío al cliente de un informe describiendo las tareas realizadas. Servicio de creación y puesta en marcha de un servidor de contingencia Con este servicio se configura un tercer servidor externo al RAC con el software de base de datos 11gR2 y con memoria y almacenamiento suficientes para montar tres instancias de bases de datos DRAGO, ROSS y APTAE que se mantendrán constantemente sincronizadas a través de Oracle GoldenGate con sus homólogas del RAC. Las tareas correspondientes a este servicio son las siguientes: 1. Determinar e informar al cliente sobre los requisitos de hardware y software (sistema operativo y parches) necesarios para la instalación y puesta en marcha del servidor de contingencia. 2. Preparación del entorno para la instalación del software de base de datos Oracle y comprobación de requisitos. 3. Instalación del software de base de datos Oracle 11g en el servidor. 4. Creación de las instancias de base de datos en el servidor de contingencia. 5. Estudio previo y configuración del servidor de contingencia para la instalación de Oracle GoldenGate. 6. Instalación y pruebas de GoldenGate en el servidor de contingencia. 7. Configuración del entorno origen (RAC) para la lectura de datos con Oracle GoldenGate y del entorno destino (servidor de contingencia) para la entrega. Esta fase incluye las pruebas necesarias para garantizar el correcto funcionamiento de la instalación. 8. Exportación inicial consistente a un punto en el tiempo (o SCN) en origen e importación en destino. 9. Activación de la entrega con GoldenGate en destino.
Actualización consolidación, migración y contingencia de un entorno hardware y software para la gestión de bases de datos Página 19 Requisitos técnicos Salvo cuando las tareas a realizar requieran la presencia del técnico en las instalaciones del cliente, las actuaciones se realizarán de forma remota. Por ello, el cliente deberá habilitar y garantizar al personal técnico el acceso remoto a los sistemas y bases de datos a migrar y a los sistemas resultantes de la consolidación. Cuando las actuaciones deban realizarse en las oficinas del cliente, éste dispondrá de un PC para realizar las labores de administración con el software necesario instalado, o en su defecto, se tendrá acceso al propio servidor de la base de datos. Para la prestación del servicio, es necesario que el técnico designado disponga de privilegios de administrador de las bases de datos, por lo que, en el momento en que se vayan a realizar tareas que requieran la introducción de la clave de administrador del servidor, deberá estar presente el personal del Cliente que conozca la clave necesaria en cada caso o en su defecto el técnico debe conocer dicha clave. El técnico no se responsabiliza de los resultados provocados por cualquier cambio de configuración, instalación de software o hardware o cualquier tipo de corrección realizada por el cliente que puedan afectar al sistema objeto de los trabajos si no ha habido recomendación expresa por parte del técnico para ser realizados. Cualquier pérdida de datos, parada total o parcial del sistema productivo o fallo del sistema provocado por esos cambios será responsabilidad exclusiva del cliente. Planificación A continuación se describen el equipo de trabajo, plan de trabajo y la planificación temporal del proyecto. Descripción del equipo de trabajo Un proyecto de estas características requiere una composición mixta de responsables y técnicos tanto del Cliente como de la empresa consultora. El éxito del mismo depende de la formación, experiencia e interacción de dicho equipo mixto. La composición del equipo de proyecto propuesta es la que se describe a continuación: Por parte del cliente: Un (1) Responsable de Área Técnica. Esta persona realizará las funciones de interlocutor técnico con el administrador de base de datos. Tendrá la capacidad de tomar decisiones a nivel técnico, así
Actualización consolidación, migración y contingencia de un entorno hardware y software para la gestión de bases de datos Página 20 como de autorizar los acuerdos que se alcancen entre el técnico y el cliente. Por parte del técnico de servicios: Un (1) Administrador de Bases de datos Oracle con experiencia en proyectos de administración en entornos Oracle. Se encargará, en colaboración directa con el Responsable de Área Técnica del Cliente, de llevar a cabo las tareas descritas en la sección “Alcance del proyecto” y de la elaboración de los entregables. Para garantizar el éxito del proyecto es necesario que exista una comunicación efectiva entre los responsables del Cliente y los Administradores de bases de datos. Es importante reducir la pérdida de productividad debido a las comunicaciones en un proyecto, consiguiendo que el trabajo se realice en los plazos estimados y con la calidad deseada. Para que esto sea posible, los responsables del Cliente adscritos al proyecto deben implicarse en todo momento, dedicando tiempo y esfuerzo a los requerimientos solicitados por el equipo de consultores y agilizando el proceso de toma de decisiones. Plan de trabajo El Anexo I (Planificación temporal de los trabajos) detalla la planificación temporal de los trabajos para los diversos equipos de trabajo. Los trabajos se realizarán remotamente excepto en los casos que haya que visitar las dependencias del Cliente, para la realización de entrevistas, reuniones, planificación de tareas, etc. o si se estimase oportuno por alguna de las partes. La jornada laboral se realizará de acuerdo al siguiente horario: lunes a viernes de 08:00h a 15:00 h salvo que la realización de algunas tareas requieran su ejecución fuera del horario laboral.
Actualización consolidación, migración y contingencia de un entorno hardware y software para la gestión de bases de datos Página 21 Anexo I. Planificación temporal del proyecto A continuación se detallan las tareas a realizar para los distintos servicios y los tiempos estimados para su ejecución: Servicio de Análisis genérico previo a la migración TAREA Tiempo del técnico (horas) Recopilación de datos del entorno actual de las bases de datos DRAGO, APTAE y ROSS 3 Recopilación de información sobre las aplicaciones 6 Recopilación de información sobre la migración 12 Elaboración del informe final con la información recopilada y conclusiones 4 TOTAL 25 Servicio de migración completa de las instancias de base de datos Tarea Tarea Cliente (horas) Técnico (horas) PREPARATIVOS Elaboración y envío de documento con los requisitos software y hardware de los dos nodos del RAC, del almacenamiento externo y de la infraestructura de red incluyendo servidor DNS e IPs. 0 2,4 Configuración de servidores, electrónica de red y configuración de cabina de almacenamiento 4,8 2,4 Configuración del sistema operativo y parches en los dos nodos del RAC 0 1,2 Creación de grupos, usuarios y rutas para la instalación 0 0,6 Modificaciones necesarias al servidor DNS 0,3 0 INSTALACIÓN Y CONFIGURACIÓN DE ORACLE CLUSTERWARE Comprobación de requisitos de hardware y software en ambos nodos del RAC, lanzamiento de la herramienta de certificación del Cluster 0 0 2,1 0 Chequeo de almacenamiento externo y de la infraestructura de red
Actualización consolidación, migración y contingencia de un entorno hardware y software para la gestión de bases de datos Página 22 Tarea Cliente (horas) Técnico (horas) incluyendo servidor DNS e IPs Diseño de la configuración de almacenamiento en Oracle ASM 0 2,4 Configuración de ASMLIB 0 1,5 Instalación de Oracle ClusterWare en ambos nodos 0 2,25 Tareas post-instalación. Descarga y aplicación de parches postinstalación y ajuste del sistema 0 2,4 Reunión con el cliente para el diseño de la política de copias de seguridad 2 2 INSTALACIÓN Y CONFIGURACIÓN DEL SOFTWARE DE BD Y ORACLE GOLDENGATE Lanzamiento, comprobación y ajustes con la herramienta Cluster Verification Utility para RAC 0 2,4 Instalación del software de base de datos Oracle 0 1,5 Descarga e instalación de parches al software de base de datos Oracle 0 1,65 Configuración de Oracle Net en el RAC 0 0,9 Preparativos para la instalación de Oracle GoldenGate. Identificación y validación de arquitectura y requisitos. Revisión del estado de los sistemas origen y el nuevo destino. Recopilación de los elementos para la instalación (usuarios en sistemas involucrados, componentes de GoldenGate a desplegar, estado de las bases de datos), documentación 0 7,2 Instalación de GoldenGate en RAC: Despliegue de componentes Oracle GoldenGate, configuración de Oracle GoldenGate en entorno RAC, pruebas de funcionamiento, documentación 0 14,4 CREACIÓN, PARAMETRIZACIÓN Y MIGRACIÓN DE INSTANCIAS DE BBDD ORACLE (ROSS) ROSS. Estudio de parámetros de la base de datos, extracción de información y scripts de creación de tablespaces 0 1,2 ROSS. Creación de la base de datos ROSS de dos instancias en el RAC usando DBUA 0 2,1 ROSS. Aplicación de scripts post-patch a la instancia base de datos 0 1,5 ROSS. Instalación de GoldenGate en servidor origen: Despliegue de componentes de Oracle GoldenGate, configuración de Oracle GoldenGate para lectura de la base de datos origen. Configuración de la entrega de datos en el RAC. Pruebas de funcionamiento, 0 7,2
Actualización consolidación, migración y contingencia de un entorno hardware y software para la gestión de bases de datos Página 23 Tarea Cliente (horas) Técnico (horas) documentación. ROSS. Instanciación inicial en el RAC: Confirmación de captura GoldenGate, exportación consistente de la base de datos a un SCN/Punto del tiempo. Importación en el RAC. 0 7,2 ROSS. Activación réplica de ROSS en RAC: Activación de entrega con GoldenGate en destino a SCN/Punto del tiempo determinado, validación de resultados, documentación 0 7,2 ROSS. Monitorización del comportamiento de la BD, ajustes postimportación 0 1,5 ROSS. Creación, prueba y lanzamiento de los scripts de copia de seguridad, según la política definida 0 2,4 ROSS. Ajuste y prueba de las aplicaciones contra la base de datos ROSS en el RAC 24 0 ROSS. Monitorización del comportamiento de la BD y ajustes finales 0 2,4 CREACIÓN Y PARAMETRIZACIÓN Y MIGRACIÓN DE INSTANCIAS DE BBDD ORACLE (APTAE) APTAE. Estudio de parámetros de la base de datos, extracción de información y scripts de creación de tablespaces. 0 1,2 APTAE. Creación de la base de datos APTAE de dos instancias en el RAC usando DBUA. 0 2,1 APTAE. Aplicación de scripts post-patch a la instancia base de datos. 0 1,5 APTAE. Instalación de GoldenGate en servidor origen: Despliegue de componentes de Oracle GoldenGate, configuración de Oracle GoldenGate para lectura de la base de datos origen. Configuración de la entrega de datos en el RAC. Pruebas de funcionamiento, documentación. 0 7,2 APTAE. Instanciación inicial en el RAC: Confirmación de captura GoldenGate, exportación consistente de la base de datos a un SCN/Punto del tiempo. Importación en el RAC. 0 14,4 APTAE. Activación réplica de APTAE en RAC: Activación de entrega con GoldenGate en destino a SCN/Punto del tiempo determinado, validación de resultados, documentación 0 7,2 APTAE. Monitorización del comportamiento de la BD, ajustes postimportación. 0 1,5 APTAE. Creación, prueba y lanzamiento de los scripts de copia de seguridad, según la política definida. 0 2,4 APTAE. Ajuste y prueba de las aplicaciones contra la base de datos 24 0
Actualización consolidación, migración y contingencia de un entorno hardware y software para la gestión de bases de datos Página 24 Tarea Cliente (horas) Técnico (horas) ROSS en el RAC. APTAE. Monitorización del comportamiento de la BD y ajustes finales. 0 2,4 CREACIÓN Y PARAMETRIZACIÓN Y MIGRACIÓN DE INSTANCIAS DE BBDD ORACLE (DRAGO) DRAGO. Estudio de parámetros de la base de datos, extracción de información y scripts de creación de tablespaces. 0 3 DRAGO. Creación de la base de datos DRAGO de dos instancias en el RAC usando DBUA. 0 2,1 DRAGO. Aplicación de scripts post-patch a la instancia base de datos. 0 1,5 DRAGO. Instalación de GoldenGate en servidor origen: Despliegue de componentes de Oracle GoldenGate, configuración de Oracle GoldenGate para lectura de la base de datos origen. Configuración de la entrega de datos en el RAC. Pruebas de funcionamiento, documentación. 0 14,4 DRAGO. Instanciación inicial en el RAC: Confirmación de captura GoldenGate, exportación consistente de la base de datos a un SCN/Punto del tiempo. Importación en el RAC, documentación 0 14,4 DRAGO. Activación réplica de DRAGO en RAC: Activación de entrega con GoldenGate en destino a SCN/Punto del tiempo determinado, validación de resultados, documentación 0 7,2 DRAGO. Monitorización del comportamiento de la BD, ajustes postimportación. 0 2,4 DRAGO. Creación, prueba y lanzamiento de los scripts de copia de seguridad, según la política definida. 0 2,4 DRAGO. Ajuste y prueba de las aplicaciones contra la base de datos ROSS en el RAC. 24 0 DRAGO. Monitorización del comportamiento de la BD y ajustes finales 0 2,4 Total horas: 79,2 169,8
Actualización consolidación, migración y contingencia de un entorno hardware y software para la gestión de bases de datos Página 25 Servicio de creación y puesta en marcha del servidor de contingencia Tarea Cliente (horas) Técnico (horas) PREPARATIVOS Elaboración y envío de documento con los requisitos software y hardware del servidor de contingencia 1 Configuración del servidor, electrónica de red y configuración de cabina de almacenamiento (si procede) 8 1 Configuración del sistema operativo y parches en el servidor 0,5 Creación de grupos, usuarios y rutas para la instalación 0,5 INSTALACIÓN Y CONFIGURACIÓN DEL SOFTWARE DE BD Y ORACLE GOLDENGATE Comprobación de requisitos de hardware y software y preparaciones previas a la instalación 0,875 Instalación del software de base de datos Oracle 1,25 Descarga e instalación de parches al software de base de datos Oracle 1,375 Configuración de Oracle Net 0,625 Configuración de las rutas en disco para la ubicación de los archivos de las tres instancias de BD 0,375 Creación, configuración y arranque de las tres instancias de BD 3 Instalación de GoldenGate: Despliegue de componentes Oracle GoldenGate, configuración de Oracle GoldenGate, pruebas de funcionamiento, documentación. 4 Configuración de Oracle GoldenGate en el RAC en modo lectura: Despliegue de componentes de Oracle GoldenGate para la lectura de las tres bases de datos, configuración para la entrega en el servidor de contingencia, pruebas de funcionamiento, documentación. 4 Instanciación inicial de BD ROSS: Confirmación Captura GoldenGate, exportación consistente de ROSS a un SCN/Punto del tiempo determinado, importación en entorno de contingencia, documentación. 6 Activación de réplica de ROSS en nuevo entorno secundario: activación de entrega con GoldenGate en destino a SCN/Punto en el tiempo determinado, validación de resultados, documentación. 6 Instanciación inicial de BD APT-AE: Confirmación Captura GoldenGate, exportación consistente de APT-AE a un SCN/Punto del tiempo determinado, importación en entorno de contingencia, documentación. 6
Actualización consolidación, migración y contingencia de un entorno hardware y software para la gestión de bases de datos Página 32 Normativa y legislación Un análisis de las legislaciones que se han promulgado en diversos países arroja que las normas jurídicas que se han puesto en vigor están dirigidas a proteger la utilización abusiva de la información reunida y procesada mediante el uso de computadoras, e incluso en algunas de ellas se ha previsto formar órganos especializados que protejan los derechos de los ciudadanos amenazados por los ordenadores. Desde hace aproximadamente diez años la mayoría de los países europeos han hecho todo lo posible para incluir dentro de la ley, la conducta punible penalmente, como el acceso ilegal a sistemas de cómputo o el mantenimiento ilegal de tales accesos, la difusión de virus o la interceptación de mensajes informáticos. En la mayoría de las naciones occidentales existen normas similares a los países europeos. Todos estos enfoques están inspirados por la misma de preocupación de contar con comunicaciones electrónicas, transacciones e intercambios tan confiables y seguros como sea posible. Dar un concepto sobre delitos informáticos no una labor fácil y esto en razón de que su misma denominación alude a una situación muy especial, ya que para hablar de "delitos" en el sentido de acciones tipificadas o contempladas en textos jurídicopenales, se requiere que la expresión "delitos informáticos" este consignada en los códigos penales, lo cual en nuestro país, al igual que en muchos otros, no ha sido objeto de tipificación aún; sin embargo, muchos especialistas en derecho informático emplean esta alusión a los efectos de una mejor conceptualización. Normativa y regulación de la información en el ámbito internacional En el contexto internacional, son pocos los países que cuentan con una legislación apropiada. Entre ellos, destacan, Estados Unidos, Alemania, Austria, Gran Bretaña, Holanda, Francia, España, Argentina y Chile. Por esta razón a continuación se mencionan algunos aspectos relacionados con la ley en los diferentes países, así como con los delitos informáticos que persigue.
Actualización consolidación, migración y contingencia de un entorno hardware y software para la gestión de bases de datos Página 33 Estados Unidos Este país adoptó en 1994 el Acta Federal de Abuso Computacional que modificó al Acta de Fraude y Abuso Computacional de 1986. Con la finalidad de eliminar los argumentos hiper-técnicos acerca de qué es y que no es un virus, un gusano, un caballo de Troya y en que difieren de los virus, la nueva acta proscribe la transmisión de un programa, información, códigos o comandos que causan daños a la computadora, a los sistemas informáticos, a las redes, información, datos o programas. La nueva ley es un adelanto porque está directamente en contra de los actos de transmisión de virus. Asimismo, en materia de estafas electrónicas, defraudaciones y otros actos dolorosos relacionados con los dispositivos de acceso a sistemas informáticos, la legislación estadounidense sanciona con pena de prisión y multa, a la persona que defraude a otro mediante la utilización de una computadora o red informática. En el mes de Julio del año 2000, el Senado y la Cámara de Representantes de este país, tras un año largo de deliberaciones, establece el Acta de Firmas Electrónicas en el Comercio Global y Nacional. La ley sobre la firma digital responde a la necesidad de dar validez a documentos informáticos, mensajes electrónicos y contratos establecidos mediante Internet, entre empresas (para el B2B) y entre empresas y consumidores (para el B2C). Alemania Este país sancionó en 1986 la Ley contra la Criminalidad Económica, que contempla los siguientes delitos: • Espionaje de datos. • Estafa informática. • Alteración de datos. • Sabotaje informático. Austria La Ley de reforma del Código Penal, sancionada el 22 de Diciembre de 1987, sanciona a aquellos que con dolo causen un perjuicio patrimonial a un tercero influyendo en el resultado de una elaboración de datos automática a través de la
Actualización consolidación, migración y contingencia de un entorno hardware y software para la gestión de bases de datos Página 34 confección del programa, por la introducción, cancelación o alteración de datos o por actuar sobre el curso del procesamiento de datos. Además contempla sanciones para quienes cometen este hecho utilizando su profesión de especialistas en sistemas. Gran Bretaña Debido a un caso de hacking en 1991, comenzó a regir en este país la Computer Misuse Act (Ley de Abusos Informáticos). Mediante esta ley el intento, exitoso o no, de alterar datos informáticos es penado con hasta cinco años de prisión o multas. Esta ley tiene un apartado que específica la modificación de datos sin autorización. Holanda El 10 de Marzo de 1993 entró en vigencia la Ley de Delitos Informáticos, en la cual se penaliza los siguientes delitos: • El hacking. • El preaking (utilización de servicios de telecomunicaciones evitando el pago total o parcial de dicho servicio). • La ingeniería social (arte de convencer a la gente de entregar información que en circunstancias normales no entregaría). La distribución de virus. Francia En enero de 1988, este país dictó la Ley relativa al fraude informático, en la que se consideran aspectos como: • Intromisión fraudulenta que suprima o modifique datos. • Conducta intencional en la violación de derechos a terceros que haya impedido o alterado el funcionamiento de un sistema de procesamiento automatizado de datos. • Conducta intencional en la violación de derechos a terceros, en forma directa o indirecta, en la introducción de datos en un sistema de procesamiento
Actualización consolidación, migración y contingencia de un entorno hardware y software para la gestión de bases de datos Página 35 automatizado o la supresión o modificación de los datos que éste contiene, o sus modos de procesamiento o de transmisión. • Supresión o modificación de datos contenidos en el sistema, o bien en la alteración del funcionamiento del sistema (sabotaje). Chile Chile fue el primer país latinoamericano en sancionar una Ley contra delitos informáticos, la cual entró en vigencia el 7 de junio de 1993. Esta ley se refiere a los siguientes delitos: • La destrucción o inutilización de los de los datos contenidos dentro de una computadora es castigada con penas de prisión. Asimismo, dentro de esas consideraciones se encuentran los virus. • Conducta maliciosa tendiente a la destrucción o inutilización de un sistema de tratamiento de información o de sus partes componentes o que dicha conducta impida, obstaculice o modifique su funcionamiento. • Conducta maliciosa que altere, dañe o destruya los datos contenidos en un sistema de tratamiento de información. Normativa y regulación de la informática en el ámbito europeo Hasta ahora, el principal esfuerzo europeo por regular el tema de los delitos informáticos dio como resultado el “Convenio sobre la Ciberdelincuencia", de 21 de noviembre de 2001. Este documento fue firmado por los representantes de cada país miembro del Consejo de Europa, aunque su eficacia depende de su posterior refrendo por los órganos nacionales de cada país firmante. El “Convenio sobre la Ciber-delincuencia" permitió la definición de los delitos informáticos y algunos elementos relacionados con éstos, tales como “sistemas informáticos", “datos informáticos", o “proveedor de servicios". Estos delitos informáticos fueron clasificados en cuatro grupos: • Delitos contra la confidencialidad, la integridad y la disponibilidad de los datos y sistemas informáticos. o Acceso ilícito a sistemas informáticos. o Interceptación ilícita de datos informáticos. o Interferencia en el sistema mediante la introducción, transmisión, provocación de daños, borrado, alteración o supresión e estos.
Actualización consolidación, migración y contingencia de un entorno hardware y software para la gestión de bases de datos Página 36 o Abuso de dispositivos que faciliten la comisión de delitos • Delitos informáticos. o Falsificación informática que produzca la alteración, borrado o supresión de datos informáticos que ocasionen datos no auténticos. o Fraudes informáticos. • Delitos relacionados con el contenido. o Delitos relacionados con la pornografía infantil. • Delitos relacionados con infracciones de la propiedad intelectual y derechos afines. Conviene destacar que en el “Convenio sobre la Ciberdelincuencia" se encomienda a cada parte que tome las medidas necesarias para tipificar como delito en su derecho interno cada uno de los apartados descritos en cada categoría. En la Disposición 14221 del BOE núm. 226 de 2010, encontramos el Instrumento de Ratificación del Convenio sobre la Ciberdelincuencia, hecho en Budapest el 23 de noviembre de 2001. Normativa y regulación de la informática en el ámbito nacional Leyes y Decretos Ley. Ley Orgánica de Protección de datos de carácter personal: régimen sancionador aplicable (BOE no298 de 14/XII/99 que publicó la Ley Org. 15/1999 de 13 de Dic.) Objeto: Proteger y garantizar las libertades públicas y derechos fundamentales de las personas, especialmente su HONOR e INTIMIDAD personal y familiar. Aspectos de interés: Serán responsables: “Los responsables de los ficheros o de los tratamientos" y “los encargados de los tratamientos" . Tipos de Infracciones: • Leves (art.44.2): multas de 100.000 a 10M pts. Ejemplo: rectificar datos o no comunicarlos a la Agencia de Protección Datos. • Graves (art.43): multas de 10M a 50M pts. Ejemplo: no mantener sistemas de seguridad, obstrucción a inspección, uso en provecho propio, ….
Actualización consolidación, migración y contingencia de un entorno hardware y software para la gestión de bases de datos Página 37 • Muy Graves (art.45): multas de 50M a 100M (“Conductas reprochables") Ej. Vulnerar a propósito el secretismo, etcétera. Ley 7/1998 de 13 de Abril que regula las condiciones generales de contratación. R.D. 1906/1999 de 17/XII que regula la contratación telefónica. R.D. Ley 14/1999 de 17/XII sobre Firma Electrónica (BOE No224 de 18/XII) Firma electrónica: Dispositivo electrónico que permite la identificación del signatario de las operaciones realizadas por Internet. Identifica: El firmante (autentificación) y Evita el retracto (no repudio). Código penal Ley Orgánica 10/1995 de 23/XI . Tipifica delitos y faltas por el uso de la informática, concretamente contra la Intimidad, Patrimonio, Socioeconómicos y Propiedad Intelectual. Título X: “Delitos contra la intimidad, derecho a la propia imagen y la inviolabilidad del Domicilio". • Apoderarse de papeles, e-mails, mensajes, otros, …. • Cracks: delitos . • Obtener datos de terceros, …. Recomendaciones de la Agencia de Protección de Datos. Información en la recogida de datos • Cuando suministre datos personales a cualquier organización (proveedores de acceso, proveedores de contenido, vendedores a través de comercio electrónico, etc.) sea consciente de a quién se los facilita y con qué finalidad. • Procure averiguar la política de sus proveedores y administradores de listas y directorios en lo que se refiere a venta, intercambio o alquiler de los datos que les suministra. Solicite que sus datos personales no vayan unidos a su identificación de acceso a Internet.
Actualización consolidación, migración y contingencia de un entorno hardware y software para la gestión de bases de datos Página 38 Finalidad para la que se recogen los datos • Desconfíe si los datos que le solicitan son excesivos para la finalidad con la que se recogen o innecesarios para el servicio que se le presta. • Tenga en cuenta que cuando introduce su dirección de correo electrónico en un directorio, lista de distribución o grupo de noticias, dicha dirección puede ser recogida por terceros para ser utilizada con una finalidad diferente, como por ejemplo, remitirle publicidad no deseada. • Cuando navegue por Internet, sea consciente de que los servidores Web que visita pueden registrar tanto las páginas a las que accede como la frecuencia y los temas o materias por las que busca, aunque no le informen de ello. • Asimismo, su pertenencia a determinados grupos de noticias y listas de distribución puede contribuir a la elaboración de perfiles más o menos detallados sobre su persona. En el caso de que no desee dejar constancia de sus actividades en la red, utilice los mecanismos para preservar el anonimato que se describen en el cuerpo de este documento. Seguridad en el intercambio de datos • Utilice, siempre que sea posible, las últimas versiones de los programas navegadores, ya quecada vez suelen incorporar mejores medidas de seguridad. • Considere la posibilidad de activar en dichos programas las opciones que alerten sobre los intercambios de datos no deseados y no rellene aquellos datos que no desee hacer públicos (por ejemplo, dirección de correo electrónico, nombre, apellidos, etc.). • No realice transacciones comerciales electrónicas a través de proveedores con sistemas inseguros o no fiables. Consulte el manual de su navegador para averiguar cómo informa de que se ha establecido una conexión con un servidor seguro. • Recuerde que existen sistemas de dinero electrónico que preservan el anonimato de sus compras en Internet. • Utilice los mecanismos de seguridad que tenga a su alcance para proteger sus datos de accesos no deseados. El medio más fiable para conseguirlo es el cifrado de los mismos.
Actualización consolidación, migración y contingencia de un entorno hardware y software para la gestión de bases de datos Página 39 • Salvo que se utilicen mecanismos de integridad, autenticación y certificación (firma digital, notarios electrónicos, etc.) no confíe ciegamente en que la persona u organización que le remite un mensaje es quien dice ser y en que el contenido del mismo no se ha modificado, aunque esto sea así en la inmensa mayoría de las ocasiones. • Siempre que se le soliciten datos personales que no esté obligado legalmente a suministrar, sopese los beneficios que va a recibir de la organización que los recoge frente a los posibles riesgos de utilización irregular de los mismos. • Ante cualquier duda sobre la legalidad de la utilización de sus datos de carácter personal, póngase en contacto con la Agencia de Protección de Datos. Protección jurídica de programas de ordenador (piratería informática) • El Real Decreto Legislativo 1/1996, por el que se aprueba el Texto Refundido sobre Propiedad Intelectual, la protección jurídica de los programas de ordenador, antes regulada por la Ley de Protección Jurídica de Programas de Ordenador y por la Ley de Propiedad Intelectual, crea un marco jurídico en contra de la piratería informática. • El Texto Refundido desarrolla una serie de medidas para combatir la piratería informática, como la posibilidad de que los fabricantes de programas de ordenador soliciten a la justicia española la realización de un registro sorpresa en empresas en las que existan sospechas fundadas o evidencias de delito. España es uno de los países en los que se puede acudir a esta medida cautelar. De esta manera se erradica la posibilidad de que los presuntos infractores puedan destruir las pruebas existentes, lo cual, indudablemente ocurrirá si se les notifica por adelantado la realización de un registro. ¿En qué casos se infringe la Ley? • Al copiar o distribuir un programa de ordenador o la documentación que le acompaña, incluidas aplicaciones, datos, códigos y manuales, sin permiso expreso o licencia del propietario de los derechos de explotación. • Al utilizar un programa sin la correspondiente licencia o autorización del fabricante, con independencia de que se utilice en un solo ordenador o en varios de forma simultánea. • Al utilizar programas de ordenador en un número de copias superior al autorizado por el fabricante en sus contratos o licencias de uso.
Actualización consolidación, migración y contingencia de un entorno hardware y software para la gestión de bases de datos Página 40 • En empresas y demás organizaciones, al fomentar, consciente o inconscientemente, permitir, obligar o presionar a los empleados a realizar o distribuir copias no autorizadas del programa. • Al efectuar copias no autorizadas porque alguien lo requiere u obliga a ello. Al ceder o prestar el programa de forma que pueda ser copiado o al copiarlo mientras está en su posesión en calidad de cedido o prestado. • Al crear, importar, poseer o negociar con artículos destinados a burlar o neutralizar cualquier medio técnico aplicado para proteger el programa de ordenador. Medidas judiciales Si finalmente existe evidencia de delito, las medidas judiciales que pueden adoptarse son: • Solicitar al Juez un registro sorpresa de las instalaciones del presunto infractor, tanto por la vía civil, como por la penal. • Solicitar al Juez la adopción urgente de medidas cautelares de protección. • Exigir indemnizaciones acordes con los daños materiales y morales causados. • El cierre del centro de actividad del infractor. • El secuestro de todos aquellos medios destinados a suprimir los dispositivos técnicos que protegen un programa desarrollado y comercializado por un fabricante de programas. Licencias de software En el apartado de licenciamiento del software empleado para este Trabajo, cabe distinguir dos categorías: el del licenciamiento de los productos de software de Oracle y el del Sistema Operativo elegido para el entorno: Oracle Linux 6. En el caso del licenciamiento del software de Oracle, se ha trabajado codo a codo con el fabricante tanto en la elección de los productos Oracle a usar como en la verificación del correcto licenciamiento de éstos. En este caso se ha tomado como guía el documento proporcionado por el fabricante y que puede consultarse en la siguiente URL: http://www.oracle.com/us/corporate/pricing/databaselicensing-070584.pdf Oracle España ha estado informado en todo momento sobre las configuraciones de software y hardware empleadas y ha validado su correcto licenciamiento. Este
Actualización consolidación, migración y contingencia de un entorno hardware y software para la gestión de bases de datos Página 41 software está sujeto a las leyes de propiedad intelectual descritas anteriormente en este documento. En el caso del Sistema Operativo, Oracle Linux 6 está distribuido gratuitamente por Oracle bajo licencia GPL (GNU General Public License). La licencia GNU declara que el software protegido por esta licencia es Software Libre y está protegido de intentos de apropiación que restrinjan las libertades de los usuarios. Éstos podrán usar, compartir y modificar el software a voluntad quedando el software resultante cubierto también por la misma licencia GNU.
Actualización consolidación, migración y contingencia de un entorno hardware y software para la gestión de bases de datos Página 48 Memoria RAM Para la estimación de los requisitos de memoria se ha tomado como base las recomendaciones de los asesores de memoria de las distintas instantáneas StatsPack recogidas en las tres bases de datos a lo largo del período estudiado: MEMORIA BD (GB) SGA (advisor) PGA (advisor) large pool (advisor) shared pool (advisor) DRAGO 3,6 1,5 0,5234375 0,75 ROSS 0,922851563 0,244140625 0 0,390625 APTAE (64 bits) 0,87890625 0,390625 0 0,25 En el caso de DRAGO y ROSS, y siguiendo las recomendaciones de Oracle, se ha estimado la duplicación del tamaño de la área de memoria “shared pool” y “large pool” al tratarse de una migración de 32 a 64 bits (APTAE ya está en 64 bits). Así mismo se ha estimado un crecimiento del 25% de las necesidades de memoria a medio plazo. De esta forma se han obtenido las necesidades de memoria SGA y PGA totales para las tres instancias: MEMORIA BD (GB) SGA (corrigiendo shared) SGA (corrigiendo large) SGA (+25%) PGA (+25%) DRAGO 4,35 4,8734375 6,091796875 1,875 ROSS 1,313476563 1,313476563 1,641845703 0,305175781 APTAE (64 bits) 0,87890625 0,87890625 1,098632813 0,48828125 8,832275391 2,668457031 Siguiendo las recomendaciones de Oracle, y disponiendo de un RAC de 2 nodos, necesitaríamos la mitad del tamaño total de la SGA en cada nodo + 15% de “overhead” del RAC y exactamente la mitad de la PGA total para cada nodo. Reservamos un 20% de la capacidad de memoria empleada por Oracle para el Sistema Operativo. El RAC de la Standard Edition obliga a emplear el gestor de almacenamiento en cluster de Oracle en vez de cualquier otro mecanismo de terceros: Oracle ASM (Automatic Storage Management). ASM levanta una instancia especial de Oracle en cada nodo (además de las instancias normales de las bases de datos que tengamos en el
Actualización consolidación, migración y contingencia de un entorno hardware y software para la gestión de bases de datos Página 49 RAC) que tiene mínimo impacto en los requisitos de procesamiento pero su peso si es relativamente importante en cuanto al consumo de memoria. Esto, unido a que los procesos de mantenimiento del Cluster de Oracle consumen bastante memoria (especialmente desde la versión 11.2 en adelante), nos ha llevado a reservar 1,5 GB de RAM para el “clusterware” en cada nodo del RAC. Con todo esto, los requisitos mínimos de memoria para los dos nodos del RAC serían los siguientes: MEMORIA SRV (SGA TOTAL/2) +15% PGA TOTAL / 2 Sist. Operativo Clusterware (incl. ASM) Memoria Total NODO 1 RAC 5,07855835 1,334228516 1,282557373 1,5 9,195344238 NODO 2 RAC 5,07855835 1,334228516 1,282557373 1,5 9,195344238 CONTINGENCIA 8,832275391 2,668457031 2,300146484 0 13,80087891 Que podríamos redondear a 16GB por servidor insistiendo en que esta sería la cantidad de memoria mínima requerida. Si opcionalmente se decidiera prescindir (total o parcialmente) del mecanismo de conexión mediante “shared server” por motivos de rendimiento y aprovechando la infraestructura del RAC, podría ser preciso ampliar los requisitos de memoria a 32 o incluso 48GB. Almacenamiento Nodos del RAC. Almacenamiento local En el caso de los nodos del RAC la mayor parte del almacenamiento necesario para la gestión de la base de datos va a ser externo y estará ubicado en una cabina de almacenamiento. El almacenamiento local estará dedicado principalmente al software de base de datos, al software de clúster, al sistema operativo y a los ficheros de logs y de configuración local de cada instancia de base de datos Oracle y de la instancia ASM de cada nodo. Para este tipo de almacenamiento, en cada nodo del RAC, bastaría con 2 discos duros locales dispuestos en RAID 1 dando una capacidad neta de como mínimo 256GB.
Actualización consolidación, migración y contingencia de un entorno hardware y software para la gestión de bases de datos Página 50 Nodos del RAC. Almacenamiento externo En un RAC de Oracle casi todo el almacenamiento necesario es externo a la máquina, está compartido entre todos los nodos del RAC y su gestión se lleva a cabo obligatoriamente en el RAC Standard Edition mediante Oracle ASM. Comenzamos por obtener los requisitos de almacenamiento de los ficheros de datos actuales distinguiendo entre el almacenamiento propio de la base de datos (tablespaces SYSTEM, SYSAUX, UNDO y temporales) y el de los distintos esquemas de la misma (resto). Un resumen de los datos recopilados se muestra en la siguiente tabla: DATAFILES (GB) TEMP UNDO (x2) SYSTEM SYSAUX RESTO DRAGO 21,1416016 47,1347656 1,20507813 1,5 411 ROSS 1 11,3867188 0,56640625 1,234375 23,9921875 APTAE (64 bits) 19,1142578 7,55859375 0,48828125 0,52734375 92,4501953 En el caso de la base de datos DRAGO, al ser 9i, no existe el tablespace SYSAUX por lo que se ha estimado de manera “ficticia” el tamaño que ocuparía su tablespace SYSAUX. En el caso del tablespace de UNDO se ha duplicado el valor recogido de las bases de datos actuales porque en RAC cada una de las dos instancias tiene su propio tablespace de UNDO. Si estimamos un crecimiento de los requerimientos de espacio de un 15% para los ficheros de datos del sistema y un 25% para los ficheros de datos de los esquemas de usuario podemos tener los totales estimados para el almacenamiento: DATAFILES (GB) TOTAL SISTEMA (+15%) RESTO (+25%) TOTAL DRAGO 70,98144531 513,75 584,731445 ROSS 14,1875 29,99023438 44,1777344 APTAE (64 bits) 27,68847656 115,5627441 143,251221 772,1604 Por otra parte, y a partir de la observación de la cantidad de información de REDO generada por las bases de datos actualmente, se ha estimado la cantidad de
Actualización consolidación, migración y contingencia de un entorno hardware y software para la gestión de bases de datos Página 51 archivelogs generados a diario. Suponiendo que se vayan a mantener en disco los archivelogs de una semana y estimando un crecimiento a medio plazo de un 10% de la cantidad de REDO generada, obtenemos los requisitos de almacenamiento para la información de REDO que se muestran en la siguiente tabla: REDO (GB) DIARIO SEMANAL SEMANAL (+10%) DRAGO 1,2 8,4 9,24 ROSS 0,146484375 1,025390625 1,127929688 APTAE (64 bits) 2,5 17,5 19,25 29,61792969 Finalmente se ha supuesto que se almacenará en disco al menos una copia de seguridad lógica y otra física (con RMAN). Se han tomado los tamaños actuales de los exports parciales de los esquemas para los que se están haciendo copias actualmente y se ha estimado un crecimiento del volumen de datos generado de un 25% a medio plazo. Para el caso de la estimación del tamaño de las copias RMAN se ha tomado el tamaño estimado de la base de datos a medio plazo (actual + 25%), se le ha añadido el tamaño de la información de REDO acumulado de 1 semana y se le ha aplicado un coeficiente del 35% de reducción. El valor del 35% se ha obtenido empíricamente basándonos en la relación entre tamaño de la base de datos y tamaño de la copia completa con RMAN que el técnico ha observado por experiencia en su trabajo con otros clientes. BACKUP (GB) Export actual RMAN (estimado 35% datafiles y redo) Export + 25% TOTAL (estimado) DRAGO 60 200,4904453 75 275,4904453 ROSS 17 15,50698242 21,25 36,75698242 APTAE (64 bits) 25 50,18543701 31,25 81,43543701 393,6828647 El resto de ficheros de la base de datos a ubicar en almacenamiento compartido no tiene un tamaño significativo y, por lo tanto, no se tiene en cuenta para estas estimaciones.
Actualización consolidación, migración y contingencia de un entorno hardware y software para la gestión de bases de datos Página 52 Se estima, por lo tanto, que el almacenamiento externo necesario para los dos nodos del RAC y las copias de seguridad será de como mínimo unos 1,2 TB. Nótese que la cantidad de 1,2 TB está expresada como almacenamiento neto. Se ha supuesto, como recomienda Oracle, que la redundancia del almacenamiento (nivel de RAID) se realiza en la cabina de discos (y no a nivel de ASM). Servidor de contingencia. Almacenamiento local En el caso del servidor de contingencia no es posible usar el mismo almacenamiento externo común que las máquinas del RAC pues la cabina de almacenamiento se convertiría en un punto único de fallo. Vamos a suponer que no se dispone de almacenamiento externo alternativo y que, por lo tanto, todos los ficheros de la base de datos estarán en almacenamiento local en el servidor de contingencia. Al igual que sucedía con los nodos del RAC, el almacenamiento local estará dedicado al software de base de datos, al sistema operativo y a los ficheros de logs y de configuración de cada instancia de base de datos Oracle (en este caso no es necesario implementar ASM). Para este tipo de almacenamiento bastaría con 2 discos duros locales dispuestos en RAID 1 dando una capacidad neta de como mínimo 256GB. Como hemos supuesto que el servidor de contingencia no tendrá acceso a almacenamiento externo necesitamos almacenamiento local para los ficheros de datos de las tres instancias de base de datos actuales. Como se indicó en el apartado anterior, se estima que los ficheros de la base de datos ocupen unos 772GB que, dadas las capacidades de los discos duros de hoy en día podríamos redondear a 1TB. Oracle recomienda que este tipo de ficheros se almacene en RAID 10. Como mínimo, y dado que se va a tratar de un servidor de contingencia que se usará para producción en circunstancias excepcionales, se recomienda implementar un RAID 5 de 3 discos con capacidad neta de 1TB. Conectividad En este apartado se describirán las necesidades de conectividad de las distintas máquinas que componen el entorno propuesto a efectos de Oracle. No se incluye en esta descripción el hardware necesario para la conectividad de los nodos del RAC (y opcionalmente del servidor de contingencia) al sistema de almacenamiento externo como, por ejemplo, interfaces de red adicionales para iSCSI o tarjetas de fibra.
Actualización consolidación, migración y contingencia de un entorno hardware y software para la gestión de bases de datos Página 53 Nodos del RAC La infraestructura del RAC requiere que cada nodo disponga de, al menos dos interfaces de red. Uno de ellos estará conectado a la red pública (la red por la que acceden los clientes de la base de datos) y el otro estará conectado a la red privada que interconecta a los nodos del RAC. En este contexto se entiende por “red pública” la red por la que los clientes de la base de datos acceden a ésta y, por lo tanto, no tiene que ser necesariamente una red externa. De hecho, lo normal es que no lo sea. Sólo es una forma de diferenciar la red de interconexión entre los nodos y la red por la que se conectan los clientes a la base de datos. Se requiere que los interfaces de la red privada estén conectados a un switch dedicado en exclusiva para este fin y que todo el conjunto funcione a velocidades Gigabit. Así mismo, los interfaces de red de la red privada sólo deben usarse para la interconexión entre nodos. Por seguridad se recomienda tener redundados los dos interfaces de red bien en activo-pasivo o activo-activo tanto para la red pública como la red privada. Si es posible, y para evitar que el switch de interconexión se convierta también en un punto único de fallo puede optarse por una configuración con dos switches (siempre que soporten trunk).
Actualización consolidación, migración y contingencia de un entorno hardware y software para la gestión de bases de datos Página 54 Por lo visto anteriormente se recomienda que cada nodo del RAC disponga de dos tarjetas de red duales (4 bocas en total) con velocidad mínima de 1 Gigabit. Servidor de contingencia Los requisitos de conectividad para el servidor de contingencia son menores al no estar en RAC. Recomendamos dos interfaces de red con velocidad mínima de 1 Gigabit dispuestos en “bonding” para garantizar la conectividad.
Actualización consolidación, migración y contingencia de un entorno hardware y software para la gestión de bases de datos Página 55 Despliegue usando VLANs Tradicionalmente se han usado switches y NICs dedicados para la red de interconexión y Oracle siempre ha sido conservadora en este aspecto pues las consecuencias de la degradación del rendimiento o fallos en la red de interconexión pueden ocasionar altos costes: Los principales requisitos que debe cumplir la red de interconexión entre nodos son: • Fiabilidad. • Baja latencia. • Alto ancho de banda. Oracle es consciente de que en muchos despliegues, por distintos motivos, no es posible dedicar electrónica de red exclusiva a la red de interconexión y soporta el uso de redes Ethernet compartidas particionadas mediante el uso de Virtual Local Area Networks (VLANs). De esta forma es posible consolidar distintos tipos de tráfico (público, interconexión, almacenamiento) en un mismo dispositivo (switch) siempre que cada uno de ellos esté en VLANs distintas. Las topologías de red implementadas con VLANs pueden cumplir con los requisitos citados anteriormente y son soportadas por Oracle siempre y cuando la red de interconexión sea no-enrutable, esté aislada de todo tráfico distinto al de la interconexión entre nodos, los valores de latencia y ancho de banda satisfagan los “Service Level Agreements” (SLA) de las aplicaciones a las que da soporte el clúster y
Actualización consolidación, migración y contingencia de un entorno hardware y software para la gestión de bases de datos Página 56 dichos valores no superen los valores de “timeout” del propio clúster o de la base de datos. Todo ello es factible pues los switches de última generación: • Soportan mayor ancho de banda • Son multicapa y soportan VLANs • Permiten MTU variable • Bonding • QoS Si bien los valores de latencia requeridos para la interconexión son relativamente predecibles, el ancho de banda requerido es difícil de calcular antes del despliegue definitivo pues depende de gran cantidad de componentes software y hardware (número de CPUs, pila de red, etc.). A modo de ejemplo se muestran las latencias mínimas para distintos tamaños de bloques UDP en una red 1GbE: Los valores de latencia máximos vienen marcados por los SLA de las distintas aplicaciones que soporta el Clúster teniendo un valor tope bastante generoso de 30 segundos. Superados los 30 segundos se activa el mecanismo “Split-brain prevention node fencing” (los nodos del RAC pierden contacto entre sí actuando como instancias únicas intentando reiniciar el otro nodo) y producen una degradación notable del rendimiento debido a las retransmisiones de paquetes (los enlaces 1GbE se saturan al llegar al 80%-90% de su capacidad). La mejor forma de determinar si se cumplen los requisitos de latencia y ancho de banda consiste en realizar simulaciones en un entorno de pre-producción. Siempre que se cumplan los requisitos de latencia y ancho de banda es posible usar VLANs en la red de interconexión de nodos. Adicionalmente, deben cumplirse los siguientes requisitos: • Todos los nodos del RAC deben estar en el mismo dominio de “broadcast” y la comunicación de un nodo a cualquier otro debe hacerse con un solo salto. Esto es, cada nodo debe estar conectado directamente al mismo switch (principal y redundante, si lo hubiere).
Actualización consolidación, migración y contingencia de un entorno hardware y software para la gestión de bases de datos Página 57 • El protocolo STP (Spaning Tree Protocol) debe deshabilitarse en la VLAN de interconexión de los nodos del RAC para evitar que los avisos de cambios de la topología de la red inunden la red e interfieran con el tráfico de interconexión. En su defecto, deben habilitarse soluciones de optimización de convergencia STP propietarias como Port Fast definitions, RootGuard o BPDU filtering. En todo caso, los eventos de convergencia STP deben durar menos que el umbral de “heartbeat” del Clusterware de Oracle o que los requisitos SLA de las aplicaciones. • Oracle soporta VLAN trunking para la red de interconexión. Los trunks manejan tráfico de todos los switches pues, por defecto, en un puerto “trunk” todas las VLANs están habilitadas y, por lo tanto, deben soportar el ancho de banda necesario para todo el tráfico que pasa por ellos. Las VLANs usan protocolos multicast y broadcast para la comunicación y, para facilitar la configuración de VLANs algunos vendedores habilitan la propagación de las definiciones de VLANs por defecto. Si bien esto tiene sentido para el tráfico de la red pública, es muy desaconsejado para el tráfico de interconexión de Oracle Clusterware. Es por esto que es necesario habilitar VLAN pruning o deshabilitar la VLAN de interconexión en el puerto trunk de tal forma que el tráfico multicast y broadcast no se propague más allá de la capa de acceso. Es importante indicar que la consolidación de distintos tipos de tráfico (interconexión, almacenamiento, público) en una misma VLAN está especialmente desaconsejado por Oracle. La implementación de la redundancia de conexiones mediante el uso de dos switches también está soportada cuando se usa una configuración con VLANs. Para ello la electrónica de red debe permitir la extensión de VLANs entre switches mediante protocolos de trunking propietarios (como VTP de Cisco) o mediante protocolos de “tagging” (como ISL de Cisco o el estándar IEEE 802.1). Ambos switches deben detectar las VLANs de los segmentos de red a los que están conectados y deben soportar el protocolo apropiado. Una característica altamente deseable y que tiene gran impacto en el rendimiento de la red de interconexión es el soporte de “jumbo frames” en los switches. Esto es debido a que los tamaños de bloque de datos de la base de datos (normalmente 8KB) no son apropiados para el tamaño estándar de trama red de 1500 bytes y se incurre en un “overead” adicional en la división del bloque en varias tramas. A continuación se muestra un ejemplo de despliegue que resume los requisitos expuestos anteriormente:
Actualización consolidación, migración y contingencia de un entorno hardware y software para la gestión de bases de datos Página 64 Desglose almacenamiento ZFS pool_db Nº de discos 6 logzilla (SSD) 1 Spare disks 0 Perfil Mirrored Espacio neto 1,58 TB ASM Diskgroups DATA 800 FRA 125 ACFS (GG) 50 CRS 2 Total ocupado (+25%)(GB) 977 Espacio libre en el pool (GB) 715,92 Todo este almacenamiento será visible simultáneamente desde ambos nodos del clúster, que llamaremos APT-ORA1 y APT-ORA2 a través de conexiones redundadas iSCSI: iSCSI LUNs (pool_db) Visibilidad ASM Diskgroup 8 x LUN de 100 GB APT-ORA1, APT-ORA2 DATA 2 x LUN de 25 GB APT-ORA1, APT-ORA2 FRA 3 x LUN de 25 GB APT-ORA1, APT-ORA2 FRA 2 x LUN de 25 GB APT-ORA1, APT-ORA2 ACFS (GG) 1 x LUN de 2 GB APT-ORA1, APT-ORA2 CRS En la tabla anterior se detallan también el número y tamaño de las LUNs que componen cada uno de los grupos de discos ASM a crear.
Actualización consolidación, migración y contingencia de un entorno hardware y software para la gestión de bases de datos Página 65 En el caso del “pool” lento, que llamaremos “pool_backup”, tenemos la siguiente distribución del almacenamiento: pool_backup Nº de discos 5 logzilla (SSD) 0 Spare disks 0 Perfil RAIDZ 2 Espacio Neto 1,57 TB ASM Diskgroups ACFS (BACKUP) 500 Total ocupado (+25%)(GB) 500 Espacio libre en el pool (GB) 1107,68 iSCSI LUNs (pool_backup) Visibilidad 5 x LUN de 100 GB APT-ORA1, APT-ORA2 En este caso se han reservado 5 LUNs de 100GB para un grupo de discos ASM llamado BACKUP que será visible a ambos nodos del RAC mediante ADVM y que contendrá los archivos de backup de las distintas bases de datos antes de que el software de backup los envíe a cinta. Con esta distribución, tendremos un almacenamiento neto de unos 3TB en la cabina de almacenamiento. Éstas serían las estimaciones de los requisitos de almacenamiento de la base de datos, suponiendo un incremento futuro de las necesidades de espacio del 25%: Estimación Almacenamiento ASM DISK GROUPS "+DATA" "+FRA" ACFS (GG) ACFS (ORCL) Datafiles BD (+25%) 773 Redo (+25%) 40 RMAN (+25%) 270,55 Export (+25%) 160 GG (origen y destino) 52,5 Total (GB) 773 40 52,5 430,55
Actualización consolidación, migración y contingencia de un entorno hardware y software para la gestión de bases de datos Página 66 Seguidamente se muestra la estimación de ocupación de los archivos de log generados por la base de datos suponiendo un incremento futuro total del 25%: Redo Semanal (GB) total + 10% DRAGO ROSS APTAE total Sup Log total + 25% 11 4 14 29 31,9 39,875 En cuanto a los requerimientos de espacio estimados para las copias lógicas de la base de datos: Export (GB) DRAGO ROSS APTAE total Sup Log total + 25% 60 7 60 127 158,75 Finalmente, se muestran las estimaciones de espacio temporal ocupado por el software de replicación Oracle GoldenGate: GoldenGate (GB) soft temp trails (1 semana) total RAC como destino 0,25 10 16 26,25 RAC como origen 0,25 10 16 26,25 52,5
Actualización consolidación, migración y contingencia de un entorno hardware y software para la gestión de bases de datos Página 67 Desarrollo Instalación del hardware y configuración de la cabina de discos La instalación del hardware corrió a cargo del personal de Sun-Oracle bajo mi supervisión. En concreto instalaron, subieron el firmware a la última versión y realizaron pruebas de verificación de los tres servidores y de la cabina de discos. Siguiendo los requisitos de almacenamiento especificados en el apartado anterior, el personal de Oracle configuró el almacenamiento disponible en la cabina de discos. El conexionado de red corrió a cargo del cliente. Todas las conexiones de red están redundadas aunque existe un punto único de fallo pues el cliente consideró que sólo era necesario un switch en vez de dos recomendados por Oracle. El switch está configurado mediante VLANs para separar el tráfico de la red de almacenamiento, el tráfico de la red de interconexión de los nodos del clúster y el tráfico de la red pública. La conexión de los servidores con la cabina se realiza a través de iSCSI. La configuración de red de la cabina corrió de mi cuenta. Se definió un “datalink” compuesto de dos interfaces de red agregados por LACP y con MTU de 9000
Actualización consolidación, migración y contingencia de un entorno hardware y software para la gestión de bases de datos Página 68 que quedó asociado al siguiente interface para la red de almacenamiento: El otro “datalink” lo compone un único interfaz de red y se destinará a la red de administración quedando un último interfaz de red libre para usos futuros: Finalmente, se procedió a configurar la visibilidad de las LUNs a los distintos “initiator groups”:
Actualización consolidación, migración y contingencia de un entorno hardware y software para la gestión de bases de datos Página 69 Instalación de Oracle Linux Para la instalación del RAC, Oracle recomienda realizar una instalación de Linux con el conjunto de paquetes estándar con algún interfaz gráfico instalado. Así se hizo en los tres servidores. Tras configurar los repositorios para conectarlo a ULN (Unbreakable Linux Network) se procedió a actualizar los paquetes, incluyendo el kernel, a su última versión.
Actualización consolidación, migración y contingencia de un entorno hardware y software para la gestión de bases de datos Página 70 La configuración de los interfaces de red quedó de la siguiente manera: Nodo 1 del RAC (apt-ora1): [root@apt-ora1 ~]# cat /etc/resolv.conf nameserver 10.5.10.10 nameserver 10.5.10.11 search example.local [root@apt-ora1 ~]# cat /etc/sysconfig/network NETWORKING=yes HOSTNAME=apt-ora1 GATEWAY=10.5.10.1 NOZEROCONF=yes [root@apt-ora1 ~]# cat /etc/hosts 127.0.0.1 localhost localhost.localdomain localhost4 localhost4.localdomain4 #Red publica 10.5.10.31 apt-ora1 apt-ora1.example.local 10.5.10.32 apt-ora2 apt-ora2.example.local #Red privada 10.5.11.31 apt-ora1-priv 10.5.11.32 apt-ora2-priv #IPs virtuales en la red publica 10.5.10.39 apt-ora1-vip 10.5.10.40 apt-ora2-vip [root@apt-ora1 ~]# cat /etc/modprobe.d/bonding.conf alias bond0 bonding alias bond1 bonding alias bond2 bonding [root@apt-ora1 network-scripts]# cat ifcfg-* DEVICE="bond0" BOOTPROTO="none" IPV6INIT="no" NM_CONTROLLED="no" ONBOOT="yes" IPADDR=10.5.10.31 NETMASK=255.255.255.0 BONDING_OPTS="miimon=100 mode=4" MTU=1500 DEVICE="bond1" BOOTPROTO="none" IPV6INIT="no" NM_CONTROLLED="no" ONBOOT="yes" IPADDR=10.5.12.31 NETMASK=255.255.255.0 #GATEWAY=10.5.12.1 MTU=9000 BONDING_OPTS="miimon=100 mode=4" DEVICE="bond2" BOOTPROTO="none" IPV6INIT="no" NM_CONTROLLED="no" ONBOOT="yes" IPADDR=10.5.11.31 NETMASK=255.255.255.0 MTU=9000 BONDING_OPTS="miimon=100 mode=4" DEVICE="eth0" BOOTPROTO="none" HWADDR="00:00:00:00:00:00" IPV6INIT="no" NM_CONTROLLED="no" ONBOOT="yes"
Actualización consolidación, migración y contingencia de un entorno hardware y software para la gestión de bases de datos Página 71 MASTER="bond0" SLAVE=yes DEVICE="eth1" BOOTPROTO="none" HWADDR="00:00:00:00:00:00" IPV6INIT="no" NM_CONTROLLED="no" ONBOOT="yes" MASTER="bond1" SLAVE=yes DEVICE="eth2" BOOTPROTO="none" HWADDR="00:00:00:00:00:00" IPV6INIT="no" NM_CONTROLLED="no" ONBOOT="yes" MASTER="bond2" SLAVE=yes DEVICE="eth3" BOOTPROTO="none" HWADDR="00:00:00:00:00:00" IPV6INIT="no" NM_CONTROLLED="no" ONBOOT="yes" MASTER="bond2" SLAVE=yes DEVICE="eth4" BOOTPROTO="none" HWADDR="00:00:00:00:00:00" IPV6INIT="no" NM_CONTROLLED="no" ONBOOT="yes" MASTER="bond1" SLAVE=yes DEVICE="eth5" BOOTPROTO="none" HWADDR="00:00:00:00:00:00" IPV6INIT="no" NM_CONTROLLED="no" ONBOOT="yes" MASTER="bond0" SLAVE=yes Nodo 2 del RAC (apt-ora2): [root@apt-ora2 ~]# cat /etc/resolv.conf nameserver 10.5.10.10 nameserver 10.5.10.11 search example.local [root@apt-ora2 ~]# cat /etc/hosts 127.0.0.1 localhost localhost.localdomain localhost4 localhost4.localdomain4 #Red publica 10.5.10.31 apt-ora1 apt-ora1.example.local 10.5.10.32 apt-ora2 apt-ora2.example.local #Red privada 10.5.11.31 apt-ora1-priv 10.5.11.32 apt-ora2-priv #IPs virtuales en la red publica 10.5.10.39 apt-ora1-vip 10.5.10.40 apt-ora2-vip [root@apt-ora2 ~]# cat /etc/sysconfig/network NETWORKING=yes HOSTNAME=apt-ora2 GATEWAY=10.5.10.1 NOZEROCONF=yes
Actualización consolidación, migración y contingencia de un entorno hardware y software para la gestión de bases de datos Página 72 [root@apt-ora2 ~]# cat /etc/modprobe.d/bonding.conf alias bond0 bonding alias bond1 bonding alias bond2 bonding [root@apt-ora2 ~]# cat /etc/sysconfig/network-scripts/ifcfg-* DEVICE="bond0" BOOTPROTO="none" IPV6INIT="no" NM_CONTROLLED="no" ONBOOT="yes" IPADDR=10.5.10.32 NETMASK=255.255.255.0 BONDING_OPTS="miimon=100 mode=4" MTU=1500 DEVICE="bond1" BOOTPROTO="none" IPV6INIT="no" NM_CONTROLLED="no" ONBOOT="yes" IPADDR=10.5.12.32 NETMASK=255.255.255.0 #GATEWAY=10.5.12.1 MTU=9000 BONDING_OPTS="miimon=100 mode=4" DEVICE="bond2" BOOTPROTO="none" IPV6INIT="no" NM_CONTROLLED="no" ONBOOT="yes" IPADDR=10.5.11.32 NETMASK=255.255.255.0 MTU=9000 BONDING_OPTS="miimon=100 mode=4" DEVICE="eth0" BOOTPROTO="none" HWADDR="00:00:00:00:00:00" IPV6INIT="no" NM_CONTROLLED="no" ONBOOT="yes" MASTER="bond0" SLAVE=yes DEVICE="eth1" BOOTPROTO="none" HWADDR="00:00:00:00:00:00" IPV6INIT="no" NM_CONTROLLED="no" ONBOOT="yes" MASTER="bond1" SLAVE=yes DEVICE="eth2" BOOTPROTO="none" HWADDR="00:00:00:00:00:00" IPV6INIT="no" NM_CONTROLLED="no" ONBOOT="yes" MASTER="bond2" SLAVE=yes DEVICE="eth3" BOOTPROTO="none" HWADDR="00:00:00:00:00:00" IPV6INIT="no" NM_CONTROLLED="no" ONBOOT="yes" MASTER="bond2" SLAVE=yes DEVICE="eth4" BOOTPROTO="none"
Actualización consolidación, migración y contingencia de un entorno hardware y software para la gestión de bases de datos Página 73 HWADDR="00:00:00:00:00:00" IPV6INIT="no" NM_CONTROLLED="no" ONBOOT="yes" MASTER="bond1" SLAVE=yes DEVICE="eth5" BOOTPROTO="none" HWADDR="00:00:00:00:00:00" IPV6INIT="no" NM_CONTROLLED="no" ONBOOT="yes" MASTER="bond0" SLAVE=yes Contingencia (apt-ora3): [root@apt-ora2 ~]# cat /etc/modprobe.d/bonding.conf alias bond0 bonding alias bond1 bonding [root@apt-ora3 network-scripts]# cat /etc/resolv.conf nameserver 10.5.10.10 nameserver 10.5.10.11 search example.local [root@apt-ora3 network-scripts]# cat /etc/hosts 127.0.0.1 localhost localhost.localdomain localhost4 localhost4.localdomain4 ::1 localhost localhost.localdomain localhost6 localhost6.localdomain6 [root@apt-ora3 network-scripts]# cat /etc/sysconfig/network NETWORKING=yes HOSTNAME=apt-ora3 GATEWAY=10.5.10.1 [root@apt-ora3 ~]# cat /etc/sysconfig/network-scripts/ifcfg-* DEVICE="bond0" BOOTPROTO="none" IPV6INIT="no" NM_CONTROLLED="no" ONBOOT="yes" IPADDR=10.5.10.33 NETMASK=255.255.255.0 BONDING_OPTS="miimon=100 mode=4" MTU=1500 DEVICE="bond1" BOOTPROTO="none" IPV6INIT="no" NM_CONTROLLED="no" ONBOOT="yes" IPADDR=10.5.12.33 NETMASK=255.255.255.0 #GATEWAY=10.5.12.1 MTU=9000 BONDING_OPTS="miimon=100 mode=4" DEVICE="eth0" BOOTPROTO="none" HWADDR="00:00:00:00:00:00" IPV6INIT="no" NM_CONTROLLED="no" ONBOOT="yes" MASTER="bond0" SLAVE=yes DEVICE="eth1" BOOTPROTO="none" HWADDR="00:00:00:00:00:00" IPV6INIT="no" NM_CONTROLLED="no"
Actualización consolidación, migración y contingencia de un entorno hardware y software para la gestión de bases de datos Página 80 service nscd start En los tres servidores configuramos el NTP: [root@apt-ora1 ~]# cat /etc/sysconfig/ntpd # Drop root to id 'ntp:ntp' by default. OPTIONS="-u ntp:ntp -x -p /var/run/ntpd.pid -g" [root@apt-ora1 ~]# chkconfig --level 35 ntpd on [root@apt-ora1 ~]# cat /etc/ntp.conf server 10.5.10.11 #server 0.rhel.pool.ntp.org #server 1.rhel.pool.ntp.org #server 2.rhel.pool.ntp.org … [root@apt-ora1 ~]# service ntpd start En los dos nodos del RAC: CVUQDISK_GRP=oinstall; export CVUQDISK_GRP [root@apt-ora1 rpm]# rpm -iv /u01/source/grid/rpm/cvuqdisk-1.0.9-1.rpm Añadimos “umask 022” al “bash_profile” de los usuarios grid y oracle en ambos nodos y añadimos a /etc/security/limits.conf las siguientes líneas: grid soft nofile 1024 grid hard nofile 65536 grid soft nproc 2047 grid hard nproc 16384 grid soft stack 10240 grid hard stack 32768 Instalación de Oracle Clusterware Comenzamos la instalación de Oracle Clusterware, el software de clúster de Oracle en el nodo 1:
Actualización consolidación, migración y contingencia de un entorno hardware y software para la gestión de bases de datos Página 81 Seleccionamos el disco CRS presentado por ASMlib para los archivos de gestión del clúster:
Actualización consolidación, migración y contingencia de un entorno hardware y software para la gestión de bases de datos Página 82 Elegimos una contraseña común para todas las cuentas: Podemos ignorar el error que indica que no es posible determinar “la posibilidad de compartir” los discos indicados. Según la nota de My Oracle Support 372358.1, se debe a que iSCSI no entrega un número de serie en su identificación. Si comprobamos que todos los discos ASM son visibles desde ambos nodos, como así ocurre, podemos ignorar la advertencia. La advertencia del tamaño de la partición de swap puede también ignorarse. En realidad tenemos 16G sólo se diferencia en unos KBs.
Actualización consolidación, migración y contingencia de un entorno hardware y software para la gestión de bases de datos Página 83 Ejecutamos los comandos indicados como root en ambos nodos: Comprobamos el estado del clúster: [root@apt-ora1 grid]# /u01/app/11.2.0/grid/bin/crsctl check crs CRS-4638: Oracle High Availability Services is online CRS-4537: Cluster Ready Services is online CRS-4529: Cluster Synchronization Services is online CRS-4533: Event Manager is online [root@apt-ora2 source]# /u01/app/11.2.0/grid/bin/crsctl check crs CRS-4638: Oracle High Availability Services is online CRS-4537: Cluster Ready Services is online CRS-4529: Cluster Synchronization Services is online CRS-4533: Event Manager is online [root@apt-ora1 grid]# /u01/app/11.2.0/grid/bin/srvctl status asm
Actualización consolidación, migración y contingencia de un entorno hardware y software para la gestión de bases de datos Página 84 ASM se está ejecutando en apt-ora1,apt-ora2 [root@apt-ora1 ~]# /u01/app/11.2.0/grid/bin/crsctl stat res –t -------------------------------------------------------------------------------- NAME TARGET STATE SERVER STATE_DETAILS -------------------------------------------------------------------------------- Local Resources -------------------------------------------------------------------------------- ora.CRS.dg ONLINE ONLINE apt-ora1 ONLINE ONLINE apt-ora2 ora.LISTENER.lsnr ONLINE ONLINE apt-ora1 ONLINE ONLINE apt-ora2 ora.asm ONLINE ONLINE apt-ora1 Started ONLINE ONLINE apt-ora2 Started ora.gsd OFFLINE OFFLINE apt-ora1 OFFLINE OFFLINE apt-ora2 ora.net1.network ONLINE ONLINE apt-ora1 ONLINE ONLINE apt-ora2 ora.ons ONLINE ONLINE apt-ora1 ONLINE ONLINE apt-ora2 -------------------------------------------------------------------------------- Cluster Resources -------------------------------------------------------------------------------- ora.LISTENER_SCAN1.lsnr 1 ONLINE ONLINE apt-ora2 ora.LISTENER_SCAN2.lsnr 1 ONLINE ONLINE apt-ora1 ora.LISTENER_SCAN3.lsnr 1 ONLINE ONLINE apt-ora1 ora.apt-ora1.vip 1 ONLINE ONLINE apt-ora1 ora.apt-ora2.vip 1 ONLINE ONLINE apt-ora2 ora.cvu 1 ONLINE ONLINE apt-ora1 ora.oc4j 1 ONLINE ONLINE apt-ora1 ora.scan1.vip 1 ONLINE ONLINE apt-ora2 ora.scan2.vip 1 ONLINE ONLINE apt-ora1 ora.scan3.vip 1 ONLINE ONLINE apt-ora1 [root@apt-ora1 ~]# /u01/app/11.2.0/grid/bin/crsctl stat res -t -------------------------------------------------------------------------------- NAME TARGET STATE SERVER STATE_DETAILS -------------------------------------------------------------------------------- Local Resources -------------------------------------------------------------------------------- ora.CRS.dg ONLINE ONLINE apt-ora1 ONLINE ONLINE apt-ora2 ora.LISTENER.lsnr ONLINE ONLINE apt-ora1 ONLINE ONLINE apt-ora2 ora.asm ONLINE ONLINE apt-ora1 Started ONLINE ONLINE apt-ora2 Started ora.gsd OFFLINE OFFLINE apt-ora1 OFFLINE OFFLINE apt-ora2 ora.net1.network ONLINE ONLINE apt-ora1 ONLINE ONLINE apt-ora2 ora.ons ONLINE ONLINE apt-ora1 ONLINE ONLINE apt-ora2 -------------------------------------------------------------------------------- Cluster Resources
Actualización consolidación, migración y contingencia de un entorno hardware y software para la gestión de bases de datos Página 85 -------------------------------------------------------------------------------- ora.LISTENER_SCAN1.lsnr 1 ONLINE ONLINE apt-ora2 ora.LISTENER_SCAN2.lsnr 1 ONLINE ONLINE apt-ora1 ora.LISTENER_SCAN3.lsnr 1 ONLINE ONLINE apt-ora1 ora.apt-ora1.vip 1 ONLINE ONLINE apt-ora1 ora.apt-ora2.vip 1 ONLINE ONLINE apt-ora2 ora.cvu 1 ONLINE ONLINE apt-ora1 ora.oc4j 1 ONLINE ONLINE apt-ora1 ora.scan1.vip 1 ONLINE ONLINE apt-ora2 ora.scan2.vip 1 ONLINE ONLINE apt-ora1 ora.scan3.vip 1 ONLINE ONLINE apt-ora1 [root@apt-ora1 ~]# /u01/app/11.2.0/grid/bin/olsnodes -n apt-ora1 1 apt-ora2 2 [root@apt-ora1 ~]# /u01/app/11.2.0/grid/bin/srvctl status asm -a ASM se está ejecutando en apt-ora1,apt-ora2 ASM está activada. [root@apt-ora1 ~]# /u01/app/11.2.0/grid/bin/ocrcheck Status of Oracle Cluster Registry is as follows : Version : 3 Total space (kbytes) : 262120 Used space (kbytes) : 2592 Available space (kbytes) : 259528 ID : 1119624359 Device/File Name : +CRS Device/File integrity check succeeded Device/File not configured Device/File not configured Device/File not configured Device/File not configured Cluster registry integrity check succeeded Logical corruption check succeeded [root@apt-ora1 ~]# /u01/app/11.2.0/grid/bin/crsctl query css votedisk ## STATE File Universal Id File Name Disk group -- ----- ----------------- --------- --------- 1. ONLINE 4d572d1f49574fdabf15c52652c34c22 (ORCL:CRS) [CRS]
Actualización consolidación, migración y contingencia de un entorno hardware y software para la gestión de bases de datos Página 86 Instalación del software de Oracle RAC Instalamos el software de RAC en los dos nodos con la opción de sólo software. De momento no instalamos la base de datos. Instalamos la versión Estándar de la BD:
Actualización consolidación, migración y contingencia de un entorno hardware y software para la gestión de bases de datos Página 87 Tal y como comentamos en la instalación del software de clúster, podemos ignorar con seguridad estos dos “problemas”. Ejecutamos el script “root.sh” y finalizamos la instalación. A continuación instalamos la nueva versión del Opatch en el “Oracle Home” de la base de datos tal y como hicimos con el home de la infraestructura en ambos nodos. Aplicamos el PSU de enero de 2013 tanto al home del Grid como al de la BD. En realidad deberemos aplicar el parche “p12983005_112035_Linux-x86-64.zip” que incluye el PSU de Enero y corrige el bug que impide usar ACFS con kernels de la serie “2.6.39-400.*” Generamos el fichero de response que nos pedirá el software del parche (hay que hacerlo en los 2 OH y en los dos nodos Y una vez que hayamos actualizado OPatch a la última versión): [grid@apt-ora1 ~]$ cd /u01/app/11.2.0/grid/OPatch/ocm/bin/ [grid@apt-ora1 bin]$ ./emocmrsp -no_banner Provide your email address to be informed of security issues, install and initiate Oracle Configuration Manager. Easier for you if you use your My Oracle Support Email address/User Name. Visit http://www.oracle.com/support/policies.html for details. Email address/User Name: You have not provided an email address for notification of security issues. Do you wish to remain uninformed of security issues ([Y]es, [N]o) [N]: Y The OCM configuration response file (ocm.rsp) was successfully created. Repetimos la operación con el Opatch del OH de la base de datos. Aplicamos el parche primero al home de la infraestructura: Y luego al home de la BD (nótese que hemos especificado explícitamente el OH):
Actualización consolidación, migración y contingencia de un entorno hardware y software para la gestión de bases de datos Página 88 Repetimos los pasos anteriores para el NODO2. Creamos los volúmenes +DATA , +FRA y +GG usando “asmca”. Para +DATA seleccionamos los discos ORCL:DATA1 a ORCL:DATA8, con redundancia externa y fijamos la AU a 4MB:
Actualización consolidación, migración y contingencia de un entorno hardware y software para la gestión de bases de datos Página 89 Para +FRA seleccionamos los discos ORCL:FRA1 y ORCL:FRA2, redundancia externa y AU de 4MB: Creamos el grupo de discos +GG con los discos ORCL:GG1 y ORCL:GG2. Nótese la compatibilidad ADVM 11.2 para permitir volúmenes ADVM:
Actualización consolidación, migración y contingencia de un entorno hardware y software para la gestión de bases de datos Página 96
Actualización consolidación, migración y contingencia de un entorno hardware y software para la gestión de bases de datos Página 97 En principio, evitaremos usar Shared Server: Creamos 3 grupos de redologs para cada una de los dos threads de redo:
Actualización consolidación, migración y contingencia de un entorno hardware y software para la gestión de bases de datos Página 98 Ejecutamos el postpatch del PSU de Enero: cd $ORACLE_HOME/rdbms/admin sqlplus /nolog SQL> CONNECT / AS SYSDBA SQL> STARTUP SQL> @catbundle.sql psu apply SQL> QUIT SQL> select count(0) from dba_objects where status <> 'VALID'; COUNT(0) ---------- 0 select comp_name, version, status from dba_registry COMP_NAME VERSION STATUS ------------------------------------------------------------ ------------------------------ ----------- OWB 11.2.0.3.0 VALID Oracle Application Express 3.2.1.00.12 VALID Oracle Enterprise Manager 11.2.0.3.0 VALID OLAP Catalog 11.2.0.3.0 VALID Spatial 11.2.0.3.0 VALID Oracle Multimedia 11.2.0.3.0 VALID Oracle XML Database 11.2.0.3.0 VALID Oracle Text 11.2.0.3.0 VALID Oracle Expression Filter 11.2.0.3.0 VALID Oracle Rules Manager 11.2.0.3.0 VALID Oracle Workspace Manager 11.2.0.3.0 VALID Oracle Database Catalog Views 11.2.0.3.0 VALID Oracle Database Packages and Types 11.2.0.3.0 VALID
Actualización consolidación, migración y contingencia de un entorno hardware y software para la gestión de bases de datos Página 99 JServer JAVA Virtual Machine 11.2.0.3.0 VALID Oracle XDK 11.2.0.3.0 VALID Oracle Database Java Packages 11.2.0.3.0 VALID OLAP Analytic Workspace 11.2.0.3.0 VALID Oracle OLAP API 11.2.0.3.0 VALID Oracle Real Application Clusters 11.2.0.3.0 VALID Comprobamos que está deshabilitado el acceso a los Management Packs: SQL> r 1* select inst_id, name, value from gv$parameter where name like '%management_pack%' INST_ID NAME VALUE ---------- ---------------------------------------- ------------------------- 1 control_management_pack_access NONE 2 control_management_pack_access NONE SQL> alter system set control_management_pack_access=NONE scope=SPFILE SID='*'; Sistema modificado. SQL> select inst_id, name, value from gv$spparameter where name like '%management_pack%'; INST_ID NAME VALUE ---------- ---------------------------------------- ------------------------- 1 control_management_pack_access NONE 2 control_management_pack_access NONE
Actualización consolidación, migración y contingencia de un entorno hardware y software para la gestión de bases de datos Página 100 Creamos el listener de la máquina de contingencia con la utilidad “netca”:
Actualización consolidación, migración y contingencia de un entorno hardware y software para la gestión de bases de datos Página 101 Creación de la base de datos de contingencia Creamos la instancia de base de datos de contingencia con los mismos parámetros vistos para la base de datos RAC usando la herramienta “dbca”. Las diferencias con ésa se muestran a continuación:
Actualización consolidación, migración y contingencia de un entorno hardware y software para la gestión de bases de datos Página 102 Al igual que con la base de datos del RAC, aplicamos el script post-patch PSU de Enero y nos aseguramos que está deshabilitado el acceso a los Management Packs. Habilitamos el recurso ‘ora.registry.acfs’ en el cluster que nunca llegó a habilitarse por realizarse la instalación de ACFS antes de aplicar el PSU que proporciona la compatibilidad con las últimas versiones de kernel de Linux: [root@apt-ora1 ~]# acfsroot enable Seguidamente configuramos la base de datos del RAC en modo archivelog: SQL> archive log list Modo log de la base de datos Modo de No Archivado Archivado automatico Desactivado Destino del archivo USE_DB_RECOVERY_FILE_DEST Secuencia de log en linea mas antigua 67 Secuencia de log actual 69 SQL> select name, log_mode from v$database; NAME LOG_MODE --------- ------------ APTORA NOARCHIVELOG SQL> alter system set cluster_database=false scope=spfile sid='APTORA1'; [oracle@apt-ora1 ~]$ srvctl stop database -d APTORA SQL> startup mount SQL> alter database archivelog; SQL> alter system set cluster_database=true scope=spfile sid='APTORA1'; SQL> shutdown immediate [oracle@apt-ora1 ~]$ srvctl start database -d APTORA [oracle@apt-ora1 ~]$ srvctl status database -d APTORA La instancia APTORA1 se está ejecutando en el nodo apt-ora1 La instancia APTORA2 se está ejecutando en el nodo apt-ora2
Actualización consolidación, migración y contingencia de un entorno hardware y software para la gestión de bases de datos Página 103 SQL> archive log list Modo log de la base de datos Modo de Archivado Archivado automatico Activado Destino del archivo USE_DB_RECOVERY_FILE_DEST Secuencia de log en linea mas antigua 67 Siguiente secuencia de log para archivar 69 Secuencia de log actual 69 SQL> alter system switch logfile; SQL> select name from v$archived_log; NAME -------------------------------------------------------------------------------- +FRA/aptora/archivelog/2013_04_18/thread_1_seq_69.263.813085249 SQL> show parameter recover NAME TYPE VALUE ------------------------------------ ----------- ------------------------------ db_recovery_file_dest string +FRA db_recovery_file_dest_size big integer 51000M db_unrecoverable_scn_tracking boolean TRUE recovery_parallelism integer 0 Cambiamos el parámetro de inicio de la base de datos “db_files” a 1024 en el RAC: SQL> alter system set db_files = 1024 scope = spfile sid = '*'; @apt-ora1 ~]$ /u01/app/grid/xag_home/bin/agctl stop goldengate gg_1 oracle@apt-ora1 ~]$ /u01/app/grid/xag_home/bin/agctl status goldengate gg_1 oldengate instance 'gg_1' is not running oracle@apt-ora1 ~]$ srvctl stop database -d APTORA oracle@apt-ora1 ~]$ srvctl start database -d APTORA oracle@apt-ora1 ~]$ /u01/app/grid/xag_home/bin/agctl start goldengate gg_1 [oracle@apt-ora1 ~]$ /u01/app/grid/xag_home/bin/agctl status goldengate gg_1 Goldengate instance 'gg_1' is running on apt-ora2 [oracle@apt-ora1 ~]$ /u01/app/grid/xag_home/bin/agctl relocate goldengate gg_1 --node apt-ora1 [oracle@apt-ora1 ~]$ /u01/app/grid/xag_home/bin/agctl status goldengate gg_1 Goldengate instance 'gg_1' is running on apt-ora1 Y en contingencia: SQL> alter system set db_files = 1024 scope = spfile sid = '*'; Sistema modificado. [oracle@apt-ora3 app]$ cd /u01/gg/ [oracle@apt-ora3 gg]$ ./ggsci GGSCI (apt-ora3) 3> stop mgr Manager process is required by other GGS processes. Are you sure you want to stop it (y/n)? y Sending STOP request to MANAGER ... Request processed. Manager stopped. SQL> shutdown immediate Base de datos cerrada. Base de datos desmontada. Instancia ORACLE cerrada. SQL> startup Instancia ORACLE iniciada. Total System Global Area 1,0122E+10 bytes Fixed Size 2237088 bytes Variable Size 1677725024 bytes Database Buffers 8422162432 bytes Redo Buffers 19468288 bytes Base de datos montada. Base de datos abierta. SQL> show parameter db_files
Actualización consolidación, migración y contingencia de un entorno hardware y software para la gestión de bases de datos Página 104 NAME TYPE VALUE ------------------------------------ ----------- ------------------------------ db_files integer 1024 GGSCI (apt-ora3) 1> start mgr Manager started. Instalación de Oracle GoldenGate en el RAC Creamos la IP virtual (VIP) para GG: [root@apt-ora1 ~]# /u01/app/11.2.0/grid/bin/appvipcfg create -network=1 -ip=10.5.10.26 -vipname=apt-ggate-vip -user=root [root@apt-ora1 ~]# crsctl setperm resource apt-ggate-vip -u user:grid:r-x [root@apt-ora1 ~]# crsctl start resource apt-ggate-vip Descargamos e instalamos los “bundled agents de GoldenGate para custerware” de http://www.oracle.com/goto/clusterware [grid@apt-ora1 xag]$ sh xagsetup.sh --install --directory /u01/app/grid/xag_home --all_nodes Añadimos la siguiente entrada al tnsnames.ora del home del grid del nodo 1: ASM = (DESCRIPTION = (ADDRESS = (PROTOCOL = BEQ) (PROGRAM = /u01/app/11.2.0/grid/bin/oracle) (ARGV0 = oracle+ASM1) (ARGS = '(DESCRIPTION=(LOCAL=YES)(ADDRESS=(PROTOCOL=BEQ)))') (ENVS = 'ORACLE_HOME=/u01/app/11.2.0/grid,ORACLE_SID=+ASM1') ) (CONNECT_DATA = (SERVICE_NAME = +ASM) (INSTANCE_NAME = +ASM1) ) ) Añadimos la siguiente entrada al tnsnames.ora del home del grid del nodo 2: ASM = (DESCRIPTION = (ADDRESS = (PROTOCOL = BEQ) (PROGRAM = /u01/app/11.2.0/grid/bin/oracle) (ARGV0 = oracle+ASM2) (ARGS = '(DESCRIPTION=(LOCAL=YES)(ADDRESS=(PROTOCOL=BEQ)))') (ENVS = 'ORACLE_HOME=/u01/app/11.2.0/grid,ORACLE_SID=+ASM2') ) (CONNECT_DATA = (SERVICE_NAME = +ASM) (INSTANCE_NAME = +ASM2) ) ) SQL> select * from gv$pwfile_users order by inst_id; INST_ID USERNAME SYSDB SYSOP SYSAS ---------- ------------------------------ ----- ----- ----- 1 SYS TRUE TRUE TRUE 1 ASMSNMP TRUE FALSE FALSE 2 SYS TRUE TRUE TRUE 2 ASMSNMP TRUE FALSE FALSE alter system set remote_login_passwordfile = shared scope=spfile sid='*';
Actualización consolidación, migración y contingencia de un entorno hardware y software para la gestión de bases de datos Página 105 Reiniciamos los nodos del cluster secuencialmente. Seguidamente instalamos GG en almacenamiento compartido y realizamos la configuración inicial: cd /u01/gg unzip /u01/source/p16582701_112105_Linux-x86-64.zip tar -xvf fbo_ggs_Linux_x64_ora11g_64bit.tar [oracle@apt-ora1 gg]$ ln -s /u01/app/oracle/product/11.2.0/dbhome_1/lib/libnnz11.so [oracle@apt-ora1 gg]$ ln -s /u01/app/oracle/product/11.2.0/dbhome_1/lib/libclntsh.so.11.1 [oracle@apt-ora1 gg]$ ./ggsci GGSCI (apt-ora1) 1> create subdirs GGSCI (apt-ora1) 2> edit params ./GLOBALS GGSCHEMA GGUSER CHECKPOINTTABLE gguser.chkpt GGSCI (apt-ora1) 1> edit param mgr port 7840 --AutoStart REPLICAT RRFIN1 --AutoRestart REPLICAT RRFIN1, retries 4, WaitMinutes 4 -- Alfresco y Administracion Electronica --AutoStart REPLICAT RALFOC31 --AutoRestart REPLICAT RALFOC31, retries 4, WaitMinutes 4 -- Mensajeria --AutoStart REPLICAT RSIME1 --AutoRestart REPLICAT RSIME1, retries 4, WaitMinutes 4 StartupValidationDelay 5 userid gguser@APTORA, password xxxxx, ENCRYPTKEY default PURGEDDLHISTORY MINKEEPDAYS 14 MAXKEEPDAYS 30 PURGEMARKERHISTORY MINKEEPDAYS 14 MAXKEEPDAYS 30 PurgeOldExtracts dirdat/*, UseCheckpoints, MinKeepDays 7 GGSCI (apt-ora1) 1> start mgr Creamos en la base de datos del RAC las estructuras de datos necesarias para el soporte de GoldenGate: create tablespace DATOS_GGS; CREATE USER GGUSER IDENTIFIED BY "xxxxx" DEFAULT TABLESPACE DATOS_GGS TEMPORARY TABLESPACE TEMP PROFILE DEFAULT ACCOUNT UNLOCK; GRANT RESOURCE TO GGUSER; GRANT CONNECT TO GGUSER; ALTER USER GGUSER DEFAULT ROLE ALL; GRANT UNLIMITED TABLESPACE TO GGUSER; GRANT SELECT ANY DICTIONARY TO GGUSER; GRANT SELECT ANY TABLE TO GGUSER; GRANT CREATE TABLE TO GGUSER; GRANT ALTER SESSION TO GGUSER; GRANT CREATE SESSION TO GGUSER; GRANT FLASHBACK ANY TABLE TO GGUSER; GRANT LOCK ANY TABLE TO GGUSER; grant dba to gguser; SQL> alter database add supplemental log data; SQL> select supplemental_log_data_min from v$database; SUPPLEME -------- YES GGSCI (apt-ora1) 1> encrypt password Xxxxx1 encryptkey default Using default key...
Actualización consolidación, migración y contingencia de un entorno hardware y software para la gestión de bases de datos Página 112 Conectado a: Oracle Database 10g Release 10.2.0.3.0 - Production Exportaci¾n realizada en el juego de caracteres WE8DEC y el juego de caracteres NCHAR AL16UTF16 el servidor utiliza el juego de caracteres WE8MSWIN1252 (posible conversión de juego de caracteres) Exportando los usuarios especificados ... . exportando acciones y objetos de procedimiento pre-esquema . exportando nombres de biblioteca de funciones ajenas para el usuario FIN ... La exportación ha terminado correctamente y sin advertencias. Antes de importar en destino, es necesario crear los esquemas, tablespaces y roles referenciados: CREATE ROLE GEM_USER NOT IDENTIFIED; GRANT SELECT ON SYS.COL$ TO GEM_USER; GRANT SELECT ON SYS.DBA_CLU_COLUMNS TO GEM_USER; GRANT SELECT ON SYS.DEPENDENCY$ TO GEM_USER; GRANT SELECT ON SYS.ICOL$ TO GEM_USER; GRANT SELECT ON SYS.IND$ TO GEM_USER; GRANT SELECT ON SYS.OBJ$ TO GEM_USER; GRANT SELECT ON SYS.USER$ TO GEM_USER; GRANT SELECT ON SYS.V_$PARAMETER TO GEM_USER; GRANT SELECT ON SYS.V_$SESSION TO GEM_USER; GRANT CREATE SESSION TO GEM_USER; GRANT CREATE TRIGGER TO GEM_USER; GRANT CREATE PROCEDURE TO GEM_USER; CREATE ROLE GEM_DEV NOT IDENTIFIED; GRANT CREATE VIEW TO GEM_DEV; GRANT CREATE TABLE TO GEM_DEV; GRANT ALTER SESSION TO GEM_DEV; GRANT CREATE CLUSTER TO GEM_DEV; GRANT CREATE DATABASE LINK TO GEM_DEV; GRANT GEM_USER TO GEM_DEV; CREATE ROLE GEM_DBA NOT IDENTIFIED; GRANT SELECT ON SYS.DBA_ROLE_PRIVS TO GEM_DBA; GRANT SELECT ON SYS.DBA_ROLES TO GEM_DBA; GRANT SELECT ON SYS.DBA_TABLESPACES TO GEM_DBA; GRANT SELECT ON SYS.DBA_USERS TO GEM_DBA; GRANT DROP USER TO GEM_DBA WITH ADMIN OPTION; GRANT ALTER USER TO GEM_DBA WITH ADMIN OPTION; GRANT CREATE USER TO GEM_DBA WITH ADMIN OPTION; GRANT DROP PUBLIC DATABASE LINK TO GEM_DBA WITH ADMIN OPTION; GRANT CREATE PUBLIC DATABASE LINK TO GEM_DBA WITH ADMIN OPTION; GRANT GEM_DEV TO GEM_DBA WITH ADMIN OPTION; GRANT GEM_USER TO GEM_DBA WITH ADMIN OPTION; SQL> CREATE ROLE APT_CONSULTOR_FACTURACION NOT IDENTIFIED; Role created. CREATE USER FIN IDENTIFIED BY VALUES 'xxxxx' DEFAULT TABLESPACE DATOS_FIN TEMPORARY TABLESPACE TEMP PROFILE DEFAULT ACCOUNT UNLOCK; -- 1 Role for FIN GRANT GEM_DBA TO FIN WITH ADMIN OPTION; ALTER USER FIN DEFAULT ROLE ALL; -- 2 System Privileges for FIN GRANT CREATE VIEW TO FIN WITH ADMIN OPTION; GRANT CREATE TRIGGER TO FIN WITH ADMIN OPTION; -- 1 Tablespace Quota for FIN ALTER USER FIN QUOTA UNLIMITED ON DATOS_FIN; -- 10 Object Privileges for FIN GRANT SELECT ON SYS.CCOL$ TO FIN WITH GRANT OPTION; GRANT SELECT ON SYS.CDEF$ TO FIN WITH GRANT OPTION; GRANT SELECT ON SYS.COL$ TO FIN WITH GRANT OPTION; GRANT SELECT ON SYS.CON$ TO FIN WITH GRANT OPTION;
Actualización consolidación, migración y contingencia de un entorno hardware y software para la gestión de bases de datos Página 113 GRANT SELECT ON SYS.ICOL$ TO FIN WITH GRANT OPTION; GRANT SELECT ON SYS.IND$ TO FIN WITH GRANT OPTION; GRANT SELECT ON SYS.OBJ$ TO FIN WITH GRANT OPTION; GRANT SELECT ON SYS.SEG$ TO FIN WITH GRANT OPTION; GRANT SELECT ON SYS.TS$ TO FIN WITH GRANT OPTION; GRANT SELECT ON SYS.USER$ TO FIN WITH GRANT OPTION; Comprobamos los sinónimos públicos en origen y los jobs definidos: select * from dba_synonyms where table_owner not in ('SYS', 'SYSTEM', 'WMSYS', 'EXFSYS', 'DMSYS', 'CTXSYS','XDB','ORDSYS','MDSYS', 'OLAPSYS','PERFSTAT','SYSMAN'); no rows selected. select * from dba_jobs; Sólo están definidos los jobs de STATSPACK y el del sistema con SYSMAN que invoca EMD_MAINTENANCE.EXECUTE_EM_DBMS_JOB_PROCS(); Sólo existen objetos directorios del sistema por lo que no es preciso crear objetos directorio de usuarios: column directory_name format a30 column directory_path format a50 column owner format a25 set linesize 2000 select * from dba_directories; Realizamos la importación inicial en destino: [oracle@apt-ora1 backup]$ export NLS_LANG=AMERICAN_AMERICA.WE8MSWIN1252 [oracle@apt-ora1 backup]$ imp system file=expFIN.dmp log=impFIN.log fromuser=FIN touser=FIN ignore=y Import: Release 11.2.0.3.0 - Production on Tue Apr 23 17:39:39 2013 Copyright (c) 1982, 2011, Oracle and/or its affiliates. All rights reserved. Password: Connected to: Oracle Database 11g Release 11.2.0.3.0 - 64bit Production With the Real Application Clusters and Automatic Storage Management options Export file created by EXPORT:V10.02.01 via conventional path import done in WE8MSWIN1252 character set and AL16UTF16 NCHAR character set export client uses WE8DEC character set (possible charset conversion) . importing FIN's objects into FIN . . importing table "ACCOUNT_TYPES" 6 rows imported ... La importación fue correcta aunque fue necesario recompilar manualmente 12 vistas. Deshabilitamos los triggers en destino: select 'alter trigger '||owner||'.'||trigger_name|| ' disable ;' from all_triggers where owner = '&SCHEMA'; alter trigger FIN.SALES_ORDER_LINE_DETAIL_QTYS disable ; ... alter trigger FIN.AR_TRANSACTIONS disable ;
Actualización consolidación, migración y contingencia de un entorno hardware y software para la gestión de bases de datos Página 114 Ahora configuramos en el RAC el proceso replicador que aplicará los cambios a la base de datos en RAC: GGSCI (apt-ora1) 1> edit param RRFIN1 Replicat RRFIN1 -- Replicat para el esquema ROSS.FIN SETENV (ORACLE_HOME = "/u01/app/oracle/product/11.2.0/dbhome_1") SETENV (ORACLE_SID = "APTORA") SETENV (NLS_LANG = AMERICAN_AMERICA.WE8MSWIN1252) userid gguser@APTORA, password xxxx, ENCRYPTKEY default HandleCollisions AssumeTargetDefs Map FIN.*, Target FIN.* ; GGSCI (apt-ora1) 10> dblogin userid gguser password Xxxxx1 GGSCI (apt-ora1) 11> add checkpointtable GGUSER.CHKPNT GGSCI (apt-ora1) 3> add replicat RRFIN1, exttrail dirdat/R1 REPLICAT added. GGSCI (apt-ora1) 19> edit param mgr port 7840 AutoStart REPLICAT RRFIN1 AutoRestart REPLICAT RRFIN1, retries 4, WaitMinutes 4 -- Alfresco y Administracion Electronica --AutoStart REPLICAT RALFOC31 --AutoRestart REPLICAT RALFOC31, retries 4, WaitMinutes 4 -- Mensajeria --AutoStart REPLICAT RSIME1 --AutoRestart REPLICAT RSIME1, retries 4, WaitMinutes 4 StartupValidationDelay 5 userid gguser@APTORA, password xxx, ENCRYPTKEY default PURGEDDLHISTORY MINKEEPDAYS 14 MAXKEEPDAYS 30 PURGEMARKERHISTORY MINKEEPDAYS 14 MAXKEEPDAYS 30 PurgeOldExtracts dirdat/*, UseCheckpoints, MinKeepDays 7 Y lo arrancamos: GGSCI (apt-ora1) 20> stop mgr GGSCI (apt-ora1) 21> start mgr GGSCI (apt-ora1) 27> info all, detail Program Status Group Lag at Chkpt Time Since Chkpt MANAGER RUNNING REPLICAT RUNNING RRFIN1 00:00:00 00:00:07 GGSCI (apt-ora1) 30> info replicat RRFIN1, detail REPLICAT RRFIN1 Last Started 2013-04-23 23:50 Status RUNNING Checkpoint Lag 00:00:00 (updated 00:00:00 ago) Log Read Checkpoint File dirdat/R1000000 2013-04-23 14:36:56.081558 RBA 3225944 Extract Source Begin End dirdat/R1000000 * Initialized * 2013-04-23 14:36 dirdat/R1000000 * Initialized * First Record Current directory /u01/gg Report file /u01/gg/dirrpt/RRFIN1.rpt Parameter file /u01/gg/dirprm/rrfin1.prm Checkpoint file /u01/gg/dirchk/RRFIN1.cpr Checkpoint table GGUSER.CHKPNT Process file /u01/gg/dirpcs/RRFIN1.pcr Stdout file /u01/gg/dirout/RRFIN1.out Error log /u01/gg/ggserr.log
Actualización consolidación, migración y contingencia de un entorno hardware y software para la gestión de bases de datos Página 115 Alternativamente podríamos haber arrancado el “replicat” con GGSCI (apt-ora1) 8> start rep RRFIN1 , aftercsn 3361941110 Sending START request to MANAGER ... REPLICAT RRFIN1 starting Una vez sincronizado el esquema comentamos la línea del “handle collisions”: GGSCI (apt-ora1) 37> stop replicat RRFIN1 Sending STOP request to REPLICAT RRFIN1 ... Request processed. GGSCI (apt-ora1) 38> start replicat RRFIN1 Sending START request to MANAGER ... REPLICAT RRFIN1 starting Comprobamos en una tabla con campos que contengan caracteres no estándar (acentos, etc..) que tanto en origen como en destino, los caracteres “extraños” se codifican correctamente: select dump(code_description, 16), code_description from fin.GL_TRANSACTION_TYPES; En este momento los dos esquemas, origen y destino quedaron sincronizados. En un momento posterior, cuando el cliente lo indicó, se detuvo la aplicación que usa el esquema, se canceló la replicación entre ROSS y el RAC, se redirigió la aplicación a la base de datos en el RAC, y ya quedó esta base de datos como base de datos en producción. Aplicación del Patch Set Update al software de Oracle en el RAC Los “patchsets updates” son parches de seguridad y rendimiento que libera Oracle periódicamente para sus productos y para los que recomienda encarecidamente su aplicación. Aplicaremos el PSU de abril al software de Oracle instalado en el RAC: Actualizamos OPatch a la versión: 11.2.0.3.4 en los ORACLE_HOME y GRID_HOME de los dos nodos: [oracle@apt-ora1 dbhome_1]$ rm -rf OPatch-old/ [oracle@apt-ora1 dbhome_1]$ mv OPatch OPatch-old [oracle@apt-ora1 dbhome_1]$ unzip /software/p6880880_112000_Linux-x86-64.zip Creamos el fichero de recpuesta automatic para OCM desde el HOME del Grid: [grid@apt-ora1 grid]$ cd OPatch/ocm/bin/ [grid@apt-ora1 bin]$ ./emocmrsp -no_banner Detenemos el EM en ambos nodos: [oracle@apt-ora1 ~]$ emctl stop dbconsole [oracle@apt-ora1 ~]$ ssh apt-ora2 [oracle@apt-ora2 ~]$ emctl stop dbconsole
Actualización consolidación, migración y contingencia de un entorno hardware y software para la gestión de bases de datos Página 116 Detenemos la base de datos [oracle@apt-ora1 ~]$ srvctl stop database -d APTORA Detenemos GoldenGatr (sólo el proceso MGR ya que no tenemos ningún otro proceso tipo captura, replicación, etc. Por este mismo motivo no tenemos procesos “pump” de GoldenGate en origen): [oracle@apt-ora1 ~]$ cd /u01/gg/ [oracle@apt-ora1 gg]$ ./ggsci GGSCI (apt-ora1) 2> info all Program Status Group Lag at Chkpt Time Since Chkpt MANAGER RUNNING REPLICAT STOPPED RRFIN1 00:00:00 67:41:17 GGSCI (apt-ora1) 3> stop mgr Manager process is required by other GGS processes. Are you sure you want to stop it (y/n)? y Sending STOP request to MANAGER ... Request processed. Manager stopped. Desmontamos los filesystems ACFS (en ambos nodos): [root@apt-ora1 ~]# umount /u01/gg [root@apt-ora1 ~]# umount /u01/backup [root@apt-ora1 ~]# umount /u01/gg [root@apt-ora1 ~]# umount /u01/backup [root@apt-ora2 11.2.0]# acfsutil info fs acfsutil info fs: ACFS-03036: no mounted ACFS file systems [root@apt-ora1 ~]# acfsutil info fs acfsutil info fs: ACFS-03036: no mounted ACFS file systems Detenemos la instalación del PSU hasta que Oracle de indicaciones de que hacer con el conflicto entre el parche 16083653 (PSU April) y el parche 12983005 (2.6.39 (UEK) support for ACFS que incluye el PSU de Enero). Volvemos a arrancar la base de datos, montar los sistemas de ficheros ACFS, arrancar EM y arrancar GoldenGate: [oracle@apt-ora1 ~]$ srvctl start database -d APTORA En ambos nodos: mount -t acfs /dev/asm/gg-220 /u01/gg mount –t acfs /dev/asm/backup-328 /u01/backup En el nodo en el que tengamos la VIP de GoldenGate: [oracle@apt-ora1 ~]$ cd /u01/gg/ [oracle@apt-ora1 gg]$ ./ggsci GGSCI (apt-ora1) 1> start mgr Manager started. Arrancamos la DB Console en ambos nodos: [oracle@apt-ora1 gg]$ export ORACLE_UNQNAME=APTORA [oracle@apt-ora1 gg]$ emctl start dbconsole
Actualización consolidación, migración y contingencia de un entorno hardware y software para la gestión de bases de datos Página 117 Configuración de GoldenGate en Alta Disponibilidad en el RAC Realizamos la configuración de GoldenGate en HA y aprovechamos para instalar la nueva versión de los “bundle agents”. Comenzamos deteniendo GoldenGate: GGSCI (apt-ora1) 2> stop mgr El filesystem compartido para GoldenGate se creó en su momento como de tipo “General Purpouse ACFS” y debe ser del tipo “CRS Managed ACFS”, cambiamos de tipo.: [root@apt-ora1 ~]# /bin/umount -t acfs /u01/gg [root@apt-ora2 ~]# /bin/umount -t acfs /u01/gg [root@apt-ora1 ~]# acfsutil registry Mount Object: Device: /dev/asm/gg-220 Mount Point: /u01/gg Disk Group: GG Volume: GG Options: none Nodes: all Mount Object: Device: /dev/asm/backup-328 Mount Point: /u01/backup Disk Group: BACKUP Volume: BACKUP Options: none Nodes: all [root@apt-ora1 ~]# acfsutil registry -d /dev/asm/gg-220 acfsutil registry: successfully removed ACFS volume /dev/asm/gg-220 from Oracle Registry [root@apt-ora1 ~]# srvctl add filesystem -d /dev/asm/gg-220 -m /u01/gg -v GG -g GG -u grid [root@apt-ora1 ~]# srvctl start filesystem -d /dev/asm/gg-220 Re-creamos la VIP de GoldenGate con permisos para el usuario “oracle” (la habíamos creado con permisos para el usuario “root”: [root@apt-ora1 apt-ora1]# crsctl stop res apt-ggate-vip [root@apt-ora1 apt-ora1]# appvipcfg delete -vipname apt-ggate-vip [root@apt-ora1 apt-ora1]# /u01/app/11.2.0/grid/bin/appvipcfg create -network=1 -ip=10.5.10.26 -vipname=apt-ggate-vip -user=oracle Desinstalamos la versión anterior de los bundle agents e instalamos la nueva: [grid@apt-ora1 ~]$ cd /u01/app/grid/xag_home/ [grid@apt-ora1 xag_home]$ ./xagsetup.sh --deinstall --force --all_nodes [grid@apt-ora1 grid]$ unzip /software/xagpack_130320.zip [grid@apt-ora1 grid]$ cd xag/ [grid@apt-ora1 xag]$ ./xagsetup.sh --install --directory /u01/app/grid/xag_home --all_nodes [oracle@apt-ora1 xag_home]$ cd /u01/app/grid/xag_home [oracle @apt-ora1 xag_home]$ export CRS_HOME=/u01/app/11.2.0/grid [oracle @apt-ora1 xag_home]$ ./agctl.pl add goldengate gg_1 --gg_home /u01/gg --instance_type both --nodes apt-ora1,apt-ora2 --filesystems ora.gg.gg.acfs --oracle_home /u01/app/oracle/product/11.2.0/dbhome_1 --databases ora.aptora.db --monitor_extracts --monitor_replicats --vip_name apt-ggate-vip [oracle@apt-ora1 xag_home]$ ./agctl.pl start goldengate gg_1 --node apt-ora1 [oracle@apt-ora1 xag_home]$ ./agctl.pl status goldengate gg_1 Goldengate instance 'gg_1' is running on apt-ora1 [root@apt-ora1 apt-ora1]# crsctl stat res -t
Actualización consolidación, migración y contingencia de un entorno hardware y software para la gestión de bases de datos Página 118 -------------------------------------------------------------------------------- NAME TARGET STATE SERVER STATE_DETAILS -------------------------------------------------------------------------------- Local Resources -------------------------------------------------------------------------------- ora.BACKUP.dg ONLINE ONLINE apt-ora1 ONLINE ONLINE apt-ora2 ora.CRS.dg ONLINE ONLINE apt-ora1 ONLINE ONLINE apt-ora2 ora.DATA.dg ONLINE ONLINE apt-ora1 ONLINE ONLINE apt-ora2 ora.FRA.dg ONLINE ONLINE apt-ora1 ONLINE ONLINE apt-ora2 ora.GG.dg ONLINE ONLINE apt-ora1 ONLINE ONLINE apt-ora2 ora.LISTENER.lsnr ONLINE ONLINE apt-ora1 ONLINE ONLINE apt-ora2 ora.asm ONLINE ONLINE apt-ora1 Started ONLINE ONLINE apt-ora2 Started ora.gg.gg.acfs ONLINE ONLINE apt-ora1 mounted on /u01/gg ONLINE ONLINE apt-ora2 mounted on /u01/gg ora.gsd OFFLINE OFFLINE apt-ora1 OFFLINE OFFLINE apt-ora2 ora.net1.network ONLINE ONLINE apt-ora1 ONLINE ONLINE apt-ora2 ora.ons ONLINE ONLINE apt-ora1 ONLINE ONLINE apt-ora2 ora.registry.acfs ONLINE ONLINE apt-ora1 ONLINE ONLINE apt-ora2 -------------------------------------------------------------------------------- Cluster Resources -------------------------------------------------------------------------------- apt-ggate-vip 1 ONLINE ONLINE apt-ora1 ora.LISTENER_SCAN1.lsnr 1 ONLINE ONLINE apt-ora1 ora.LISTENER_SCAN2.lsnr 1 ONLINE ONLINE apt-ora2 ora.LISTENER_SCAN3.lsnr 1 ONLINE ONLINE apt-ora2 ora.apt-ora1.vip 1 ONLINE ONLINE apt-ora1 ora.apt-ora2.vip 1 ONLINE ONLINE apt-ora2 ora.aptora.db 1 ONLINE ONLINE apt-ora1 Open 2 ONLINE ONLINE apt-ora2 Open ora.cvu 1 ONLINE ONLINE apt-ora2 ora.oc4j 1 ONLINE ONLINE apt-ora2 ora.scan1.vip 1 ONLINE ONLINE apt-ora1 ora.scan2.vip 1 ONLINE ONLINE apt-ora2 ora.scan3.vip 1 ONLINE ONLINE apt-ora2 xag.gg_1.goldengate 1 ONLINE ONLINE apt-ora1
Actualización consolidación, migración y contingencia de un entorno hardware y software para la gestión de bases de datos Página 119 Probamos el failover: [oracle@apt-ora1 xag_home]$ ./agctl.pl relocate goldengate gg_1 --node apt-ora2 [root@apt-ora1 apt-ora1]# crsctl stat res xag.gg_1.goldengate NAME=xag.gg_1.goldengate TYPE=xag.goldengate.type TARGET=ONLINE STATE=ONLINE on apt-ora2 [root@apt-ora1 apt-ora1]# crsctl stat res apt-ggate-vip NAME=apt-ggate-vip TYPE=app.appvip_net1.type TARGET=ONLINE STATE=ONLINE on apt-ora2 [oracle@apt-ora1 xag_home]$ ./agctl.pl relocate goldengate gg_1 --node apt-ora1 [root@apt-ora1 apt-ora1]# crsctl stat res xag.gg_1.goldengate NAME=xag.gg_1.goldengate TYPE=xag.goldengate.type TARGET=ONLINE STATE=ONLINE on apt-ora1 [root@apt-ora1 apt-ora1]# crsctl stat res apt-ggate-vip NAME=apt-ggate-vip TYPE=app.appvip_net1.type TARGET=ONLINE STATE=ONLINE on apt-ora1 Preparamos el script de autoarranque de la base de datos, listener, EM y GG en el servidor de contingencia: [root@apt-ora3 ~]# cd /etc/init.d/ [root@apt-ora3 init.d]# vi dbora #!/bin/bash # chkconfig: 345 99 10 # description: Oracle auto start-stop script. # Set ORA_OWNER to the user id of the owner of the # Oracle database in ORA_HOME. ORA_OWNER=oracle RETVAL=0 case "$1" in 'start') # Start the Oracle databases: # The following command assumes that the oracle login # will not prompt the user for any values su - $ORA_OWNER -c "/home/oracle/EMPR/ora_start.sh" touch /var/lock/subsys/oracle ;; 'stop') # Stop the Oracle databases: # The following command assumes that the oracle login # will not prompt the user for any values su - $ORA_OWNER -c "/home/oracle/EMPR/ora_stop.sh" rm -f /var/lock/subsys/oracle ;; *) echo $"Usage: $0 {start|stop}" RETVAL=1 esac exit $RETVAL [root@apt-ora3 init.d]# chmod 750 dbora [root@apt-ora3 init.d]# chkconfig --add dbora [oracle@apt-ora3 ~]$ cat /etc/oratab
Actualización consolidación, migración y contingencia de un entorno hardware y software para la gestión de bases de datos Página 120 # This file is used by ORACLE utilities. It is created by root.sh # and updated by either Database Configuration Assistant while creating # a database or ASM Configuration Assistant while creating ASM instance. # A colon, ':', is used as the field terminator. A new line terminates # the entry. Lines beginning with a pound sign, '#', are comments. # # Entries are of the form: # $ORACLE_SID:$ORACLE_HOME:<N|Y>: # # The first and second fields are the system identifier and home # directory of the database respectively. The third filed indicates # to the dbstart utility that the database should , "Y", or should not, # "N", be brought up at system boot time. # # Multiple entries with the same $ORACLE_SID are not allowed. # # APTORA2:/u01/app/oracle/product/11.2.0/dbhome_1:Y [oracle@apt-ora3 ~]$ cd /home/oracle/EMPR/ [oracle@apt-ora3 EMPR]$ cat ora_start.sh #!/bin/bash # script to start the Oracle database, listener, dbconsole and GoldenGate export ORACLE_SID=APTORA2 export ORACLE_UNQNAME=APTORA2 export ORACLE_BASE=/u01/app/oracle export ORACLE_HOME=/u01/app/oracle/product/11.2.0/dbhome_1 export GG_HOME=/u01/gg # start the listener and the database $ORACLE_HOME/bin/dbstart $ORACLE_HOME # start the Enterprise Manager db console $ORACLE_HOME/bin/emctl start dbconsole # start GoldenGate $GG_HOME/ggsci PARAMFILE /home/oracle/EMPR/startGG exit 0 [oracle@apt-ora3 EMPR]$ cat ora_stop.sh #!/bin/bash # script to stop the Oracle database, listener, dbconsole and GoldenGate export ORACLE_SID=APTORA2 export ORACLE_UNQNAME=APTORA2 export ORACLE_BASE=/u01/app/oracle export ORACLE_HOME=/u01/app/oracle/product/11.2.0/dbhome_1 export GG_HOME=/u01/gg # stop GoldenGate $GG_HOME/ggsci PARAMFILE /home/oracle/EMPR/stopGG # stop the Enterprise Manager db console $ORACLE_HOME/bin/emctl stop dbconsole # stop the listener and the database $ORACLE_HOME/bin/dbshut $ORACLE_HOME exit 0 [oracle@apt-ora3 EMPR]$ cat startGG start manager
Actualización consolidación, migración y contingencia de un entorno hardware y software para la gestión de bases de datos Página 121 exit [oracle@apt-ora3 EMPR]$ cat stopGG stop extract * stop replicat * stop manager ! exit Instalación de GoldenGate en la máquina APTAE Descomprimimos el fichero “p14768905_112104_MSWIN-x86-64.zip” en el directorio raíz de GG (E:\DATAFILE\GG). E:\DATAFILE\GG>ggsci.exe GGSCI (Apt-AE-Ora) 1> create subdirs Creating subdirectories under current directory E:\DATAFILE\GG Parameter files E:\DATAFILE\GG\dirprm: already exists Report files E:\DATAFILE\GG\dirrpt: created Checkpoint files E:\DATAFILE\GG\dirchk: created Process status files E:\DATAFILE\GG\dirpcs: created SQL script files E:\DATAFILE\GG\dirsql: created Database definitions files E:\DATAFILE\GG\dirdef: created Extract data files E:\DATAFILE\GG\dirdat: created Temporary files E:\DATAFILE\GG\dirtmp: created Stdout files E:\DATAFILE\GG\dirout: created GGSCI (Apt-AE-Ora) 2> edit param ./GLOBALS MGRSERVNAME GG_MGR_APTAE GGSCHEMA GGUSER CHECKPOINTTABLE gguser.chkpt E:\DATAFILE\GG>install.exe ADDSERVICE CREATE TABLESPACE DATOS_GGS DATAFILE 'E:\DATAFILE\APTAE\GGS01.DBF' SIZE 1M AUTOEXTEND ON NEXT 1M MAXSIZE 4096M LOGGING ONLINE PERMANENT EXTENT MANAGEMENT LOCAL AUTOALLOCATE BLOCKSIZE 8K SEGMENT SPACE MANAGEMENT AUTO FLASHBACK ON; CREATE USER GGUSER IDENTIFIED BY "Xxxxx1" DEFAULT TABLESPACE DATOS_GGS TEMPORARY TABLESPACE TEMP PROFILE DEFAULT ACCOUNT UNLOCK; GRANT RESOURCE TO GGUSER; GRANT CONNECT TO GGUSER; ALTER USER GGUSER DEFAULT ROLE ALL; GRANT UNLIMITED TABLESPACE TO GGUSER; GRANT SELECT ANY DICTIONARY TO GGUSER; GRANT SELECT ANY TABLE TO GGUSER; GRANT CREATE TABLE TO GGUSER; GRANT ALTER SESSION TO GGUSER; GRANT CREATE SESSION TO GGUSER; GRANT FLASHBACK ANY TABLE TO GGUSER; GRANT LOCK ANY TABLE TO GGUSER; grant dba to gguser; GGSCI (Apt-AE-Ora) 1> edit param mgr port 7840
Actualización consolidación, migración y contingencia de un entorno hardware y software para la gestión de bases de datos Página 128 ALTER USER EAREGISTRO DEFAULT ROLE ALL; -- 8 System Privileges for EAREGISTRO GRANT CREATE SESSION TO EAREGISTRO; GRANT CREATE TABLE TO EAREGISTRO; GRANT CREATE PROCEDURE TO EAREGISTRO; GRANT CREATE TRIGGER TO EAREGISTRO; GRANT UNLIMITED TABLESPACE TO EAREGISTRO; GRANT CREATE VIEW TO EAREGISTRO; GRANT CREATE SEQUENCE TO EAREGISTRO; GRANT CREATE SYNONYM TO EAREGISTRO; Seguidamente realizamos el “import”: [oracle@apt-ora1 backup]$ export NLS_LANG=AMERICAN_AMERICA.WE8MSWIN1252 [oracle@apt-ora1 backup]$ imp system fromuser=ALF,OC3B,OC3C,OC3EC,OC3ES,OC3F,OC3RC,OC3RS,EAREGISTRO touser=ALF,OC3B,OC3C,OC3EC,OC3ES,OC3F,OC 3RC,OC3RS,EAREGISTRO file=expAPTAE1.dmp log=impAPTAE1.log ignore=y Import: Release 11.2.0.3.0 - Production on Fri May 3 14:13:27 2013 Copyright (c) 1982, 2011, Oracle and/or its affiliates. All rights reserved. Password: ... . importing OC3RS's objects into OC3RS . importing EAREGISTRO's objects into EAREGISTRO Import terminated successfully with warnings. No hay “grants” de otros esquemas a éstos: select 'grant '|| privilege|| ' on '||owner||'.'||table_name||' to '||grantee||';' from dba_tab_privs where grantee in ('ALF', 'OC3B', 'OC3C', 'OC3EC', 'OC3ES', 'OC3F', 'OC3RC', 'OC3RS', 'EAREGISTRO') order by owner, table_name; no rows selected. No hay dblinks que nos afecten ni sinónimos públicos. select 'CREATE PUBLIC SYNONYM '||synonym_name||' FOR "'||table_owner||'"."'||table_name||'";' from dba_synonyms where owner = 'PUBLIC' and table_owner not in ('MDSYS','DMSYS','CTXSYS','OLAPSYS','SYSTEM','EXFSYS', 'ORDSYS','SYSMAN','XDB','SYS','WMSYS','PERFSTAT')order by table_owner; no rows selected. Deshabilitamos las constraints en destino: set echo off set verify off set pagesize 2000 set linesize 250 set trim on set heading off set feedback off select '-- '||status|| ', '||deferrable||', '||deferred||chr(10)||'alter table '||owner||'.'||table_name||' disable constraint '||constraint_name||';' from all_constraints where delete_rule = 'CASCADE' and owner in ('ALF', 'OC3B', 'OC3C', 'OC3EC', 'OC3ES', 'OC3F', 'OC3RC', 'OC3RS', 'EAREGISTRO') order by owner; -- ENABLED, NOT DEFERRABLE, IMMEDIATE alter table ALF.ALF_PROP_LINK disable constraint FK_ALF_PROPLN_VAL; ...
Actualización consolidación, migración y contingencia de un entorno hardware y software para la gestión de bases de datos Página 129 Ninguno de los esquemas tienen triggers. Añadimos en destino el REPLICAT y su fichero “trail”: GG> add replicat RALFOC31, exttrail dirdat/R2 Arrancamos el REPLICAT en destino con AFTERCSN y esperamos a que se ponga al día: GG> start rep RALFOC31, aftercsn 3371802643 GG> lag rep RALFOC31 GG> info rep RALFOC31, showch GG> stats rep RALFOC31 Añadimos el autoarranque del “replicat” en el MGR de destino: GG> edit param mgr -- Alfresco y Administracion Electronica AutoStart REPLICAT RALFOC31 AutoRestart REPLICAT RALFOC31, retries 4, WaitMinutes 4 Editamos el “replicat” y comentamos la línea de HANDLECOLLISIONS: GG> edit param RALFOC31 -- HandleCollisions Detenemos el REPLICAT y reiniciamos el MGR en destino GG> stop rep RALFOC31 GG> stop mgr GG> start mgr Tampoco era necesario reiniciar el “replicat”. Podíamos haber editado el fichero y haber modificado directamente al REPLICAT: GG> send replicat RALFOC31, NOHANDLECOLLISIONS Creamos un DBLINK para comparar la base de datos Origen y Destino: create public database link "OLD_APTAE_LNK" connect to GGUSER identified by "xxxxx" using 'OLD_APTAE'; Comprobamos las sequencias en origen y destino: with diff_seq as (select * from dba_sequences@OLD_APTAE_LNK where sequence_owner in ('ALF', 'OC3B', 'OC3C', 'OC3EC', 'OC3ES', 'OC3F', 'OC3RC', 'OC3RS', 'EAREGISTRO') minus select * from dba_sequences where sequence_owner in ('ALF', 'OC3B', 'OC3C', 'OC3EC', 'OC3ES', 'OC3F', 'OC3RC', 'OC3RS', 'EAREGISTRO') ) select origen.*, destino.* from diff_seq, dba_sequences@OLD_APTAE_LNK origen, dba_sequences destino where origen.sequence_owner = diff_seq.sequence_owner and origen.sequence_name = diff_seq.sequence_name and origen.sequence_owner = destino.sequence_owner and origen.sequence_name = destino.sequence_name; Todo está correcto incluyendo la secuencia ALF.ALF_PROP_ROOT_SEQ que tiene un valor de NEXTVALUE mayor en destino. Comparación de prueba entre los esquemas origen y destino con la herramienta “dbForge Data Compare”. Fue satisfactoria para los 9 esquemas:
Actualización consolidación, migración y contingencia de un entorno hardware y software para la gestión de bases de datos Página 130 Migración de los esquemas de SIME Preparamos la replicación de SIME ejecutando el script de compatibilidad con GoldenGate: ------ Tables With No Primary Key or Unique Index in the Schema: NTX_SIME TABLE_NAME ------------------------------ BERMAN_MEDIDAS_OPE_TB BLOQUEO_HISTORICO_IFCSUM_TB
Actualización consolidación, migración y contingencia de un entorno hardware y software para la gestión de bases de datos Página 131 DR$MENSAJES_XML_IX01$I DR$MENSAJES_XML_IX01$R FORMULARIO_ERROR_TB FORMULARIO_MAESTROS_TB ------ Tables Defined with Triggers in the Schema: NTX_SIME TABLE_NAME TRIGGER_COUNT ------------------------------ ------------- SECUENCIAS_CONSOLIDADAS_TB 1 USUARIOS_TB 1 CONSULTAS_TB 1 ALERTAS_TB 1 BERMAN_CAMBIO_ESTADO_TB 1 PLANTILLAS_DETALLE_TB 2 TRANSFORMACION_SERVICIOS_TB 1 VALIDACION_SERVICIOS_TB 1 FILTROS_TB 1 IFC_CONOCIM_EMBARQUES_TB 1 IFC_ERRORES_TB 1 REGISTRO 1 FORMULARIOS_TB 1 IFCSUM_CONSOLIDACION_TB 1 NOTIFICACIONES_TB 1 PLANTILLAS_SECCIONES_TB 2 TIPO_BANDEJAS_TB 1 TRANSFORMACION_LOG_TB 1 ERROR 1 LISTA_DISTRIBUCION_TB 1 PERFILES_TB 1 TIPO_MENSAJES_DETALLE_TB 1 TIPO_PLANTILLAS_TB 1 USUARIO_REGISTRO_LOG_TB 1 MENSAJES_DETALLE_TB 2 MENSAJES_TB 2 M_MODO_COMUNICACION_TB 1 TRANSFORMACION_CAMPOS_TB 1 VALIDACION_MAESTROS_TB 1 VALIDACION_RANGOS_TB 1 ESCALAS_CONSOLIDADAS_TB 1 FILTROS_GENERICOS_TB 1 IFC_CABECERA_TB 2 IFC_EQUIPAMIENTO_TB 2 IFC_PARTIDAS_TB 1 MENSAJES_DETALLE_HISTORICO_TB 1 VALIDACION_LOG_TB 1 VALIDACION_TB 1 OBJETOS_TB 1 BLOQUEO_HISTORICO_IFCSUM_TB 1 BANDEJAS_TB 1 FILTROS_USUARIOS_VALOR_TB 1 LISTA_DISTRIBUCION_DETALLE_TB 1 MENSAJES_HISTORICO_TB 2 PLANTILLAS_TB 2 ------ Sequence numbers: NTX_SIME SEQUENCE_OWNER SEQUENCE_NAME MIN_VALUE MAX_VALUE INCR CYCLE ORDER CACHE_SIZE LAST_NUMBER --------------- ------------------------------ ---------- ---------- ---- ----- ----- ---------- ----------- NTX_SIME FORMULARIOS_ID_SQ 1 9999999999 1 N Y 0 32 NTX_SIME ACTIVACION_ESCALA_SQ 1 9999999999 1 N Y 20 84421 NTX_SIME LISTA_DISTRIBUCION_SQ 1 9999999999 1 N Y 0 538 NTX_SIME TRANSFORMACION_SER_SQ 1 9999999999 1 N Y 0 38 NTX_SIME FILTROS_SQ 1 9999999999 1 N Y 0 326 NTX_SIME USUARIOS_ID_SQ 1 999999999 1 N Y 0 62 NTX_SIME MENSAJES_ID_SQ 1 9999999999 1 N Y 0 288076 NTX_SIME NOTIFICACIONES_SQ 1 9999999999 1 N Y 0 52537 NTX_SIME ALERTAS_SQ 1 9999999999 1 N Y 0 597703 NTX_SIME VALIDACIONMAE_SQ 1 9999999999 1 N Y 0 665 NTX_SIME PERFILES_ID_SQ 1 999999999 1 N Y 0 57 NTX_SIME OBJETOS_ID_SQ 1 999999999 1 N Y 0 73 NTX_SIME VALIDACION_SQ 1 9999999999 1 N Y 0 833 NTX_SIME USUARIO_REGISTRO_LOG_ID_SQ 1 9999999999 1 N Y 0 4131 NTX_SIME ERRORES_SQ 1 9999999999 1 N Y 0 601768 NTX_SIME VALIDACIONRAN_SQ 1 9999999999 1 N Y 0 63 NTX_SIME CONSOLIDACION_SOL_ID_SQ 1 9999999999 1 N Y 20 53941 NTX_SIME MENSAJES_HISTORICO_SQ 1 9999999999 1 N Y 0 1664544 NTX_SIME VALIDACION_LOG_SQ 1 9999999999 1 N Y 0 291335 NTX_SIME APERAK_REF_SQ 1 1,0000E+14 1 N Y 20 214500
Actualización consolidación, migración y contingencia de un entorno hardware y software para la gestión de bases de datos Página 132 NTX_SIME VALIDACIONSER_SQ 1 9999999999 1 N Y 0 179 NTX_SIME MODO_COMUNICACION_SQ 1 99 1 N Y 0 4 NTX_SIME PLANTILLAS_SQ 1 9999999999 1 N Y 0 79 NTX_SIME TRANSFORMACION_CAMPOS_SQ 1 9999999999 1 N Y 0 1784 NTX_SIME TRANSFORMACION_LOG_SQ 1 9999999999 1 N Y 0 371139 NTX_SIME PLANTILLAS_SECCIONES_SQ 1 9999999999 1 N Y 0 65 NTX_SIME ALERTAS_MODIFICACION_SQ 1 9999999999 1 N Y 0 433647 NTX_SIME NOTIFICACIONES_MODIFICACION_SQ 1 9999999999 1 N Y 0 251000 NTX_SIME BERMAN_MM_SQ 1 1,0000E+14 1 N Y 20 132141 NTX_SIME BERMAN_CAMBIO_ESTADO_SQ 1 9999999999 1 N Y 20 363049 NTX_SIME REGISTRO_SQ 1 9999999999 1 N Y 0 25177558 NTX_SIME CUSRES_IFCSUM_SQ 1 99999999 1 N Y 20 169798 NTX_SIME FILTROS_GENERICOS_SEQ 1 1,0000E+27 1 N N 0 22 NTX_SIME CONSULTAS_SQ 1 999 1 N Y 0 4 ------ Tables With No Primary Key or Unique Index in the Schema: NTX_SIME_HIS TABLE_NAME ------------------------------ MENSAJES_DETALLE_HISTORICO_TB No tenemos resolución para esta tabla por parte de los desarrolladores. Empíricamente y para los datos actuales: select count(0) from ntx_sime_his.mensajes_detalle_historico_tb 767331 select count(0) from (select distinct mensaje_id, cab_id from ntx_sime_his.mensajes_detalle_historico_tb) 767331 Parece que la combinación de campos “mensaje_id” y “cab_id” actúan como clave única. No hay referencias de otros esquemas fuera del grupo a NTX_SIME_HIS y NTX_SIME. Añadimos el “supplemental log data” a las tablas a replicar de ambos esquemas: add trandata NTX_SIME.BERMAN_MEDIDAS_OPE_TB ... add trandata NTX_SIME.IFCSUM_ADUANA_RELACION_TB add trandata NTX_SIME_HIS.MENSAJES_HISTORICO_TB add trandata NTX_SIME_HIS.MENSAJES_DETALLE_HISTORICO_TB Preparamos la configuración de los procesos “extract” y “pump” para los esquemas de SIME en la máquina origen: GGSCI (Apt-AE-Ora) 107> edit param LSIME1 extract LSIME1 -- Local Extract para los esquemas de Mensajeria (tablas sin KEYCOLS) SETENV (ORACLE_HOME = "C:\oracle\product\10.2.0\db_1") SETENV (ORACLE_SID = "APTAE") SETENV (NLS_LANG = AMERICAN_AMERICA.WE8MSWIN1252) userid gguser@APTAE, password XXXXXX, ENCRYPTKEY default ExtTrail dirdat/L2 TableExclude NTX_SIME.DR$*; Table NTX_SIME.*; Table NTX_SIME_HIS.*; Table EMPR_TEST.*; Sequence NTX_SIME.*; Sequence EMPR_TEST.*; ReportCount Every 30 minutes, Rate Report at 01:00 ReportRollover at 01:15 --DDL Include Mapped DiscardFile dirrpt/LSIME1.dsc, Append DiscardRollover at 02:00
Actualización consolidación, migración y contingencia de un entorno hardware y software para la gestión de bases de datos Página 133 GG> add extract LSIME1, TRANLOG, BEGIN NOW GG> add exttrail dirdat/L2, extract LSIME1, MEGABYTES 100 GGSCI (Apt-AE-Ora) 111> start extract LSIME1 GGSCI (Apt-AE-Ora) 112> info all Program Status Group Lag at Chkpt Time Since Chkpt MANAGER RUNNING EXTRACT RUNNING LSIME1 00:00:00 00:02:13 GGSCI (Apt-AE-Ora) 114> flush sequence NTX_SIME.* Successfully flushed 34 sequence(s) NTX_SIME.* set line 2000 set pagesize 99999 column owner format a25 column object_name format a40 select owner, object_name, object_type, status from dba_objects where status <>'VALID' and owner in ('NTX_SIME', 'NTX_SIME_HIS') order by owner, object_type; OWNER OBJECT_NAME OBJECT_TYPE STATUS ------------------------- ---------------------------------------- ------------------- ------- NTX_SIME RUTA_MENSAJES_VS VIEW INVALID NTX_SIME PUBLICADOR_RECURSOS_VS VIEW INVALID Realizamos el export consistente y lo enviamos al RAC: select dbms_flashback.get_system_change_number from dual; E:\DATAFILE>exp system owner=NTX_SIME,NTX_SIME_HIS file=expNTX_SIME_Y_HIS.dmp log=expNTX_SIME_Y_HIS.log statistics=none consistent=y flashback_scn=3379004287 Y lo copiamos a destino (RAC). Preparamos el entorno para el proceso “pump” y lo arrancamos: Extract PSIME1 -- Extract tipo DataPump para los esquemas de Mensajeria (sin KEYCOLS) SETENV (ORACLE_HOME = "C:\oracle\product\10.2.0\db_1") SETENV (ORACLE_SID = "APTAE") SETENV (NLS_LANG = AMERICAN_AMERICA.WE8MSWIN1252) PassThru RmtHost apt-ggate-vip, MgrPort 7840, TCPBUFSIZE 100000, COMPRESS RmtTrail dirdat/R3 TableExclude NTX_SIME.DR$*; Table NTX_SIME.*; Table NTX_SIME_HIS.*; Table EMPR_TEST.*; Sequence NTX_SIME.*; Sequence EMPR_TEST.*; ReportCount Every 30 minutes, Rate Report at 01:00 ReportRollover at 01:15 DiscardFile dirrpt/PSIME1.dsc, Append DiscardRollover at 02:00 GG> add extract PSIME1, EXTTRAILSOURCE dirdat/L2 GG> add rmttrail dirdat/R3, extract PSIME1, MEGABYTES 100 GGSCI (Apt-AE-Ora) 4> start extract PSIME1 Sending START request to MANAGER ('GG_MGR_APTAE') ... EXTRACT PSIME1 starting Preparamos el entorno en el RAC: CREATE TABLESPACE NTX_SIME_DATA_TS DATAFILE
Actualización consolidación, migración y contingencia de un entorno hardware y software para la gestión de bases de datos Página 134 '+DATA/aptora/datafile/ntx_sime_data_ts.287.814987357' SIZE 1M AUTOEXTEND ON NEXT 1M MAXSIZE 4096M, '+DATA/aptora/datafile/ntx_sime_data_ts.288.814987357' SIZE 1M AUTOEXTEND ON NEXT 1M MAXSIZE 4096M, '+DATA/aptora/datafile/ntx_sime_data_ts.289.814987549' SIZE 1M AUTOEXTEND ON NEXT 1M MAXSIZE 4096M, '+DATA/aptora/datafile/ntx_sime_data_ts.290.814987549' SIZE 1M AUTOEXTEND ON NEXT 1M MAXSIZE 4096M, '+DATA/aptora/datafile/ntx_sime_data_ts.291.814987549' SIZE 1M AUTOEXTEND ON NEXT 1M MAXSIZE 4096M, '+DATA/aptora/datafile/ntx_sime_data_ts.292.814987549' SIZE 1M AUTOEXTEND ON NEXT 1M MAXSIZE 4096M, '+DATA/aptora/datafile/ntx_sime_data_ts.293.814987549' SIZE 1M AUTOEXTEND ON NEXT 1M MAXSIZE 4096M, '+DATA/aptora/datafile/ntx_sime_data_ts.294.814987549' SIZE 1M AUTOEXTEND ON NEXT 1M MAXSIZE 4096M, '+DATA/aptora/datafile/ntx_sime_data_ts.295.814987549' SIZE 1M AUTOEXTEND ON NEXT 1M MAXSIZE 4096M, '+DATA/aptora/datafile/ntx_sime_data_ts.296.814987549' SIZE 1M AUTOEXTEND ON NEXT 1M MAXSIZE 4096M, '+DATA/aptora/datafile/ntx_sime_data_ts.297.814987551' SIZE 1M AUTOEXTEND ON NEXT 1M MAXSIZE 4096M, '+DATA/aptora/datafile/ntx_sime_data_ts.298.814987551' SIZE 1M AUTOEXTEND ON NEXT 1M MAXSIZE 4096M, '+DATA/aptora/datafile/ntx_sime_data_ts.299.814987551' SIZE 1M AUTOEXTEND ON NEXT 1M MAXSIZE 4096M, '+DATA/aptora/datafile/ntx_sime_data_ts.300.814987551' SIZE 1M AUTOEXTEND ON NEXT 1M MAXSIZE 4096M, '+DATA/aptora/datafile/ntx_sime_data_ts.301.814987551' SIZE 1M AUTOEXTEND ON NEXT 1M MAXSIZE 4096M, '+DATA/aptora/datafile/ntx_sime_data_ts.302.814987551' SIZE 1M AUTOEXTEND ON NEXT 1M MAXSIZE 4096M, '+DATA/aptora/datafile/ntx_sime_data_ts.303.814987551' SIZE 1M AUTOEXTEND ON NEXT 1M MAXSIZE 4096M, '+DATA/aptora/datafile/ntx_sime_data_ts.304.814987551' SIZE 1M AUTOEXTEND ON NEXT 1M MAXSIZE 4096M, '+DATA/aptora/datafile/ntx_sime_data_ts.305.814987553' SIZE 1M AUTOEXTEND ON NEXT 1M MAXSIZE 4096M, '+DATA/aptora/datafile/ntx_sime_data_ts.306.814987553' SIZE 1M AUTOEXTEND ON NEXT 1M MAXSIZE 4096M, '+DATA/aptora/datafile/ntx_sime_data_ts.307.814987553' SIZE 1M AUTOEXTEND ON NEXT 1M MAXSIZE 4096M, '+DATA/aptora/datafile/ntx_sime_data_ts.308.814987553' SIZE 1M AUTOEXTEND ON NEXT 1M MAXSIZE 4096M, '+DATA/aptora/datafile/ntx_sime_data_ts.309.814987553' SIZE 1M AUTOEXTEND ON NEXT 1M MAXSIZE 4096M, '+DATA/aptora/datafile/ntx_sime_data_ts.310.814987555' SIZE 1M AUTOEXTEND ON NEXT 1M MAXSIZE 4096M LOGGING ONLINE PERMANENT EXTENT MANAGEMENT LOCAL AUTOALLOCATE BLOCKSIZE 8K SEGMENT SPACE MANAGEMENT AUTO FLASHBACK ON; CREATE TABLESPACE NTX_SIME_INDEX_TX DATAFILE SIZE 1M AUTOEXTEND ON NEXT 1M MAXSIZE 4096M; Tablespace created. CREATE TABLESPACE NTX_SIME_HIS DATAFILE SIZE 1M AUTOEXTEND ON NEXT 1M MAXSIZE 8192M; ALTER TABLESPACE NTX_SIME_HIS ADD DATAFILE SIZE 1M AUTOEXTEND ON NEXT 1M MAXSIZE 8192M; ALTER TABLESPACE NTX_SIME_HIS ADD DATAFILE SIZE 1M AUTOEXTEND ON NEXT 1M MAXSIZE 8192M; ALTER TABLESPACE NTX_SIME_HIS ADD DATAFILE SIZE 1M AUTOEXTEND ON NEXT 1M MAXSIZE 8192M; ALTER TABLESPACE NTX_SIME_HIS ADD DATAFILE SIZE 1M AUTOEXTEND ON NEXT 1M MAXSIZE 8192M; ALTER TABLESPACE NTX_SIME_HIS ADD DATAFILE SIZE 1M AUTOEXTEND ON NEXT 1M MAXSIZE 8192M; ALTER TABLESPACE NTX_SIME_HIS ADD DATAFILE SIZE 1M AUTOEXTEND ON NEXT 1M MAXSIZE 8192M; ALTER TABLESPACE NTX_SIME_HIS ADD DATAFILE SIZE 1M AUTOEXTEND ON NEXT 1M MAXSIZE 4096M; ALTER TABLESPACE NTX_SIME_HIS ADD DATAFILE SIZE 1M AUTOEXTEND ON NEXT 1M MAXSIZE 4096M; ALTER TABLESPACE NTX_SIME_HIS ADD DATAFILE SIZE 1M AUTOEXTEND ON NEXT 1M MAXSIZE 4096M; ALTER TABLESPACE NTX_SIME_HIS ADD DATAFILE SIZE 1M AUTOEXTEND ON NEXT 1M MAXSIZE 4096M; ALTER TABLESPACE NTX_SIME_HIS ADD DATAFILE SIZE 1M AUTOEXTEND ON NEXT 1M MAXSIZE 4096M; ALTER TABLESPACE NTX_SIME_HIS ADD DATAFILE SIZE 1M AUTOEXTEND ON NEXT 1M MAXSIZE 4096M; ALTER TABLESPACE NTX_SIME_HIS ADD DATAFILE SIZE 1M AUTOEXTEND ON NEXT 1M MAXSIZE 4096M; ALTER TABLESPACE NTX_SIME_HIS ADD DATAFILE SIZE 1M AUTOEXTEND ON NEXT 1M MAXSIZE 4096M; CREATE TABLESPACE NTX_SIME_HIS_INDEX_TS DATAFILE SIZE 1M AUTOEXTEND ON NEXT 1M MAXSIZE 4096M;
Actualización consolidación, migración y contingencia de un entorno hardware y software para la gestión de bases de datos Página 135 -- DROP USER NTX_SIME CASCADE CREATE USER NTX_SIME IDENTIFIED BY VALUES 'XXXX' DEFAULT TABLESPACE NTX_SIME_DATA_TS TEMPORARY TABLESPACE TEMP PROFILE DEFAULT ACCOUNT UNLOCK; -- 1 Role for NTX_SIME GRANT CONNECT TO NTX_SIME; ALTER USER NTX_SIME DEFAULT ROLE ALL; -- 7 System Privileges for NTX_SIME GRANT CREATE TABLE TO NTX_SIME; GRANT CREATE PROCEDURE TO NTX_SIME; GRANT CREATE SEQUENCE TO NTX_SIME; GRANT UNLIMITED TABLESPACE TO NTX_SIME; GRANT CREATE SESSION TO NTX_SIME; GRANT CREATE TRIGGER TO NTX_SIME; GRANT CREATE VIEW TO NTX_SIME; -- 14 Object Privileges for NTX_SIME GRANT ALTER, DELETE, INDEX, INSERT, REFERENCES, SELECT, UPDATE, ON COMMIT REFRESH, QUERY REWRITE, DEBUG, FLASHBACK ON NTX_SIME_HIS.MENSAJES_DETALLE_HISTORICO_TB TO NTX_SIME WITH GRANT OPTION; GRANT ALTER, DELETE, INDEX, INSERT, REFERENCES, SELECT, UPDATE, ON COMMIT REFRESH, QUERY REWRITE, DEBUG, FLASHBACK ON NTX_SIME_HIS.MENSAJES_HISTORICO_TB TO NTX_SIME WITH GRANT OPTION; -- DROP USER NTX_SIME_HIS CASCADE CREATE USER NTX_SIME_HIS IDENTIFIED BY VALUES 'xxxxxxx' DEFAULT TABLESPACE NTX_SIME_HIS TEMPORARY TABLESPACE TEMP PROFILE DEFAULT ACCOUNT UNLOCK; -- 1 Role for NTX_SIME_HIS GRANT CONNECT TO NTX_SIME_HIS; ALTER USER NTX_SIME_HIS DEFAULT ROLE ALL; -- 7 System Privileges for NTX_SIME_HIS GRANT UNLIMITED TABLESPACE TO NTX_SIME_HIS; GRANT CREATE TRIGGER TO NTX_SIME_HIS; GRANT CREATE VIEW TO NTX_SIME_HIS; GRANT CREATE SESSION TO NTX_SIME_HIS; GRANT CREATE TABLE TO NTX_SIME_HIS; GRANT CREATE SEQUENCE TO NTX_SIME_HIS; GRANT CREATE PROCEDURE TO NTX_SIME_HIS; Configuramos el proceso replicador en el RAC: GGSCI (apt-ora1) 1> edit param RSIME1 Replicat RSIME1 -- Replicat para los esquemas de Mensajeria (tablas sin KEYCOLS) SETENV (ORACLE_HOME = "/u01/app/oracle/product/11.2.0/dbhome_1") SETENV (ORACLE_SID = "APTORA") SETENV (NLS_LANG = AMERICAN_AMERICA.WE8MSWIN1252) userid gguser@APTORA, password XXXXXX, ENCRYPTKEY default --HandleCollisions AssumeTargetDefs ReportCount Every 30 minutes, Rate Report at 01:00 ReportRollover at 01:15 DiscardFile dirrpt/RSIME1.dsc, Append DiscardRollover at 02:00 SQLEXEC "alter session set time_zone = '+00:00'" Map NTX_SIME.BERMAN_MEDIDAS_OPE_TB, Target NTX_SIME.BERMAN_MEDIDAS_OPE_TB, KEYCOLS(OPE_MEDIDA_ID, OPE_MEDIDA_DIM_ID); Map NTX_SIME.BLOQUEO_HISTORICO_IFCSUM_TB, Target NTX_SIME.BLOQUEO_HISTORICO_IFCSUM_TB, KEYCOLS(MENSAJE_ID, FECHA_ALTA); Map NTX_SIME.FORMULARIO_ERROR_TB, Target NTX_SIME.FORMULARIO_ERROR_TB, KEYCOLS(FORMULARIO_ID, NODO_ID); Map NTX_SIME.FORMULARIO_MAESTROS_TB, Target NTX_SIME.FORMULARIO_MAESTROS_TB, KEYCOLS(FORMULARIO_ID, MAESTRO_ID); Map NTX_SIME.*, Target NTX_SIME.*; Map NTX_SIME_HIS.*, Target NTX_SIME_HIS.*; Map EMPR_TEST.PRODUCTS, Target EMPR_TEST.PRODUCTS, KEYCOLS(product_id,supplier_id);
Actualización consolidación, migración y contingencia de un entorno hardware y software para la gestión de bases de datos Página 136 Map EMPR_TEST.*, Target EMPR_TEST.*; Añadimos “trandatas” específicos para las columnas clave de tablas con keycols: delete trandata NTX_SIME.BERMAN_MEDIDAS_OPE_TB delete trandata NTX_SIME.BLOQUEO_HISTORICO_IFCSUM_TB delete trandata NTX_SIME.FORMULARIO_ERROR_TB delete trandata NTX_SIME.FORMULARIO_MAESTROS_TB delete trandata NTX_SIME_HIS.MENSAJES_DETALLE_HISTORICO_TB add trandata NTX_SIME.BERMAN_MEDIDAS_OPE_TB, COLS(OPE_MEDIDA_ID, OPE_MEDIDA_DIM_ID), NOKEY add trandata NTX_SIME.BLOQUEO_HISTORICO_IFCSUM_TB, KEYCOLS(MENSAJE_ID, FECHA_ALTA), NOKEY add trandata NTX_SIME.FORMULARIO_ERROR_TB, KEYCOLS(FORMULARIO_ID, NODO_ID), NOKEY add trandata NTX_SIME.FORMULARIO_MAESTROS_TB, KEYCOLS(FORMULARIO_ID, MAESTRO_ID), NOKEY add trandata NTX_SIME_HIS.MENSAJES_DETALLE_HISTORICO_TB, KEYCOLS(MENSAJE_ID, CAB_ID), NOKEY info trandata NTX_SIME.BLOQUEO_HISTORICO_IFCSUM_TB info trandata NTX_SIME.FORMULARIO_ERROR_TB info trandata NTX_SIME.FORMULARIO_MAESTROS_TB info trandata NTX_SIME_HIS.MENSAJES_DETALLE_HISTORICO_TB stats ext LSIME1 TABLE NTX_SIME.BLOQUEO_HISTORICO_IFCSUM_TB stats ext LSIME1 TABLE NTX_SIME.FORMULARIO_ERROR_TB stats ext LSIME1 TABLE NTX_SIME.FORMULARIO_MAESTROS_TB stats ext LSIME1 TABLE NTX_SIME_HIS.MENSAJES_DETALLE_HISTORICO_TB Realizamos un export de prueba sin filas en origen y lo importamos en destino: [oracle@apt-ora1 backup]$ imp system fromuser=NTX_SIME,NTX_SIME_HIS touser=NTX_SIME,NTX_SIME_HIS file=expNTX_SIME_Y_HIS_NOROWS.dmp log=impNTX_SIME_Y_HIS.log ignore=y rows=n Import: Release 11.2.0.3.0 - Production on Fri May 10 14:40:49 2013 Copyright (c) 1982, 2011, Oracle and/or its affiliates. All rights reserved. Password: Connected to: Oracle Database 11g Release 11.2.0.3.0 - 64bit Production With the Real Application Clusters and Automatic Storage Management options Export file created by EXPORT:V10.02.01 via conventional path import done in US7ASCII character set and AL16UTF16 NCHAR character set import server uses WE8MSWIN1252 character set (possible charset conversion) export client uses WE8MSWIN1252 character set (possible charset conversion) . importing NTX_SIME's objects into NTX_SIME . importing NTX_SIME_HIS's objects into NTX_SIME_HIS . importing NTX_SIME's objects into NTX_SIME ... IMP-00003: ORACLE error 4052 encountered ORA-04052: se ha producido un error al consultar el objeto remoto . importing NTX_SIME_HIS's objects into NTX_SIME_HIS . importing NTX_SIME's objects into NTX_SIME About to enable constraints... Import terminated successfully with warnings. Aumentamos temporalmente el grupo de discos +FRA en 100GB para soportar la gran cantidad de información de “redo” que van a generar los imports : Disco /dev/sdu: 26.8 GB, 26843545600 bytes 64 heads, 32 sectors/track, 25600 cylinders Units = cilindros of 2048 * 512 = 1048576 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk identifier: 0xa218bc8a Disposit. Inicio Comienzo Fin Bloques Id Sistema /dev/sdu1 1 25600 26214272 83 Linux Disco /dev/sdv: 26.8 GB, 26843545600 bytes 64 heads, 32 sectors/track, 25600 cylinders Units = cilindros of 2048 * 512 = 1048576 bytes
Actualización consolidación, migración y contingencia de un entorno hardware y software para la gestión de bases de datos Página 137 Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk identifier: 0xc8eb6952 Disposit. Inicio Comienzo Fin Bloques Id Sistema /dev/sdv1 1 25600 26214272 83 Linux Disco /dev/sdw: 26.8 GB, 26843545600 bytes 64 heads, 32 sectors/track, 25600 cylinders Units = cilindros of 2048 * 512 = 1048576 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk identifier: 0x7f6b78de Disposit. Inicio Comienzo Fin Bloques Id Sistema /dev/sdw1 1 25600 26214272 83 Linux [root@apt-ora1 ~]# oracleasm createdisk FRA3 /dev/sdu1 [root@apt-ora1 ~]# oracleasm createdisk FRA4 /dev/sdv1 [root@apt-ora1 ~]# oracleasm createdisk FRA5 /dev/sdw1 [root@apt-ora2 ~]# service oracleasm stop [root@apt-ora2 ~]# service iscsi stop [root@apt-ora2 ~]# service iscsi start [root@apt-ora2 ~]# service oracleasm start [root@apt-ora2 ~]# oracleasm listdisks BCK1 BCK2 BCK3 BCK4 BCK5 CRS DATA1 DATA2 DATA3 DATA4 DATA5 DATA6 DATA7 DATA8 FRA1 FRA2 FRA3 FRA4 FRA5 GG1 GG2 [root@apt-ora1 ~]# crsctl start crs [root@apt-ora2 ~]# crsctl start crs Ampliamos la FRA a nivel de base de datos: SQL> alter system set db_recovery_file_dest_size = 127000M scope=BOTH sid='*'; SQL> show parameter recovery NAME TYPE VALUE ------------------------------------ ----------- ------------------------------ db_recovery_file_dest string +FRA db_recovery_file_dest_size big integer 127000M recovery_parallelism integer 0 Realizamos el import con filas : export NLS_LANG=AMERICAN_AMERICA.WE8MSWIN1252 [oracle@apt-ora1 backup]$ imp system fromuser=NTX_SIME,NTX_SIME_HIS touser=NTX_SIME,NTX_SIME_HIS file=expNTX_SIME_Y_HIS.dmp log=impNTX_SIME_Y_HIS.log ignore=y Una vez finalizado el import deshabilitamos los triggers: set echo off set verify off set pagesize 2000
Actualización consolidación, migración y contingencia de un entorno hardware y software para la gestión de bases de datos Página 144 Conectados al NODO1 como PERFSTAT creamos el “job” propiamente dicho: BEGIN dbms_scheduler.create_job( job_name => 'APTORA_PERFSTAT_COLLECT_N1', program_name => 'PROC_RAC_STATSPACK', start_date => SYSTIMESTAMP, repeat_interval=>'FREQ=minutely; INTERVAL=30;', job_class => 'statspack_apt_ora1_class', comments => 'Recopilación de STATSPACK para APTORA1', enabled => TRUE); dbms_scheduler.create_job (job_name=>'APTORA_PERFSTAT_PURGE_N1', job_type=>'PLSQL_BLOCK', job_action=>'begin STATSPACK.PURGE(15); end;', start_date=>SYSTIMESTAMP, repeat_interval=>'FREQ=DAILY; BYHOUR=23; BYMINUTE=30', job_class => 'statspack_apt_ora1_class', enabled=>TRUE); END; / Conectados al NODO2 con el usuario PERFSTAT hacemos lo mismo: BEGIN dbms_scheduler.create_job( job_name => 'APTORA_PERFSTAT_COLLECT_N2', program_name => 'PROC_RAC_STATSPACK', start_date => SYSTIMESTAMP, repeat_interval=>'FREQ=minutely; INTERVAL=30;', job_class => 'statspack_apt_ora2_class', comments => 'Recopilación de STATSPACK para APTORA2', enabled => TRUE); dbms_scheduler.create_job (job_name=>'APTORA_PERFSTAT_PURGE_N2', job_type=>'PLSQL_BLOCK', job_action=>'begin STATSPACK.PURGE(15); end;', start_date=>SYSTIMESTAMP, repeat_interval=>'FREQ=DAILY; BYHOUR=23; BYMINUTE=30',
Actualización consolidación, migración y contingencia de un entorno hardware y software para la gestión de bases de datos Página 145 job_class => 'statspack_apt_ora2_class', enabled=>TRUE); END; / set line 2000 alter session set nls_date_format='dd-mm-yy hh24:mi:ss'; select INSTANCE_NUMBER, SNAP_TIME from stats$snapshot order by 1, 2; INSTANCE_NUMBER SNAP_TIME --------------- ------------------- 1 11-05-13 19:53:40 1 16-05-13 12:48:57 1 16-05-13 12:50:40 1 16-05-13 12:53:02 2 11-05-13 19:54:46 2 16-05-13 12:40:52 2 16-05-13 12:48:13 2 16-05-13 12:53:46 Instalamos STATSPACK en la máquina de contingencia: CREATE TABLESPACE STATSPACK_TS DATAFILE SIZE 1M AUTOEXTEND ON NEXT 1M MAXSIZE 4096M; SQL> @?/rdbms/admin/spcreate Choose the PERFSTAT user's password ----------------------------------- Not specifying a password will result in the installation FAILING Introduzca un valor para perfstat_password: Xxxxx1 xxxxx Choose the Default tablespace for the PERFSTAT user --------------------------------------------------- Below is the list of online tablespaces in this database which can store user data. Specifying the SYSTEM tablespace for the user's default tablespace will result in the installation FAILING, as using SYSTEM for performance data is not supported. Choose the PERFSTAT users's default tablespace. This is the tablespace in which the STATSPACK tables and indexes will be created. TABLESPACE_NAME CONTENTS STATSPACK DEFAULT TABLESPACE ------------------------------ --------- ---------------------------- DATOS_GGS PERMANENT STATSPACK_TS PERMANENT SYSAUX PERMANENT * USERS PERMANENT Pressing <return> will result in STATSPACK's recommended default tablespace (identified by *) being used. Introduzca un valor para default_tablespace: STATSPACK_TS Using tablespace STATSPACK_TS as PERFSTAT default tablespace. Choose the Temporary tablespace for the PERFSTAT user ----------------------------------------------------- Below is the list of online tablespaces in this database which can store temporary data (e.g. for sort workareas). Specifying the SYSTEM tablespace for the user's temporary tablespace will result in the installation FAILING, as using SYSTEM for workareas is not supported. Choose the PERFSTAT user's Temporary tablespace. TABLESPACE_NAME CONTENTS DB DEFAULT TEMP TABLESPACE ------------------------------ --------- -------------------------- TEMP TEMPORARY * Pressing <return> will result in the database's default Temporary
Actualización consolidación, migración y contingencia de un entorno hardware y software para la gestión de bases de datos Página 146 tablespace (identified by *) being used. Introduzca un valor para temporary_tablespace: Using tablespace TEMP as PERFSTAT temporary tablespace. ... Creating PERFSTAT user ... SQL> grant create job to perfstat; Conectados como PERFSTAT creamos el job: BEGIN DBMS_SCHEDULER.CREATE_JOB ( job_name => 'APTORA2_PERFSTAT_COLLECT', job_type => 'PLSQL_BLOCK', job_action => 'begin statspack.snap(7); end;', start_date => SYSTIMESTAMP, repeat_interval => 'FREQ=minutely; INTERVAL=30;', enabled => TRUE, comments => 'Recoplicación de STATSPACK para APTORA2'); END; / BEGIN dbms_scheduler.create_job (job_name=>'APTORA2_PERFSTAT_PURGE', job_type=>'PLSQL_BLOCK', job_action=>'begin STATSPACK.PURGE(15); end;', start_date=>SYSTIMESTAMP, repeat_interval=>'FREQ=DAILY; BYHOUR=23; BYMINUTE=30', comments => 'Recoplicación de STATSPACK para APTORA2', enabled=>TRUE); END; / set line 2000 alter session set nls_date_format='dd-mm-yy hh24:mi:ss'; select INSTANCE_NUMBER, SNAP_TIME from stats$snapshot order by 1, 2; INSTANCE_NUMBER SNAP_TIME --------------- ------------------- 1 16-05-13 14:59:29 Añadimos un datafile a STATSPACK_TS tanto en el RAC como en contingencia: ALTER TABLESPACE STATSPACK_TS ADD DATAFILE SIZE 1M AUTOEXTEND ON NEXT 1M MAXSIZE 4096M ; Esquema de copias de seguridad propuesto para el clúster y su base de datos El esquema de copias se ha diseñado como una extensión para el entorno RAC de los scripts usados para realizar copias de seguridad de las bases de datos no-RAC. Los objetivos son: Recopilación de toda la información necesaria para restaurar desde cero el clúster de Oracle (incluyendo la pérdida de todos los discos en la SAN). Crear scripts modulares que sean:
Actualización consolidación, migración y contingencia de un entorno hardware y software para la gestión de bases de datos Página 147 o Flexibles para ejecutarse desde cualquier instancia (si el nodo que hace habitualmente las copias está caído, cualquier otro nodo puede ejecutar los scripts de backup con mínimas modificaciones) o Soporte para realizar backups de varias instancias de bases de datos dentro del RAC o Flexible para añadir más instancias de bases de datos al esquema de backup o Flexible para añadir más nodos del RAC al esquema de backup Aprovechar los scripts existentes adaptándolos al entorno RAC. Esquema de copias. Visión general A grandes rasgos, el esquema de copias consiste en un script maestro que se ejecuta como usuario “root” en un nodo elegido del clúster y que, mediante invocaciones a otros scripts más específicos, realiza una copia física en caliente (no requiere parada) con RMAN y un “export” con EXPDP (copia lógica) de todas las instancias de bases de datos del clúster asociadas al ORACLE_HOME. El script recopila información de los “homes” de las instancias de bases de datos, de las instancias ASM del clúster, y del propio clúster (tanto del Oracle Clúster Registry (OCR) como del Oracle Local Registry (OLR), entre otros). Así mismo se realiza un backup de los principales archivos de configuración de GoldenGate y de los logs y reports generados por éste. Toda la información recopilada se almacena en el filesystem ACFS compartido por los dos nodos del clúster de Oracle y montado bajo la ruta “/u01/backup/BCK_APTORA”. Al residir los ficheros del backup en almacenamiento compartido, son fácilmente accesibles por cualquier nodo en caso de tener que recurrir a ellos para la restauración de la base de datos. Esquema de copias. Detalle Para describir el esquema de copias iremos detallando las tareas realizadas por cada uno de los siete scripts implicados. Comenzaremos la descripción de abajo hacia arriba, esto es, primero describiremos la función de los scripts más básicos para acabar con el script maestro de la copia de seguridad.
Actualización consolidación, migración y contingencia de un entorno hardware y software para la gestión de bases de datos Página 148 La ubicación de los scripts es arbitraria pero todos ellos deben estar en el mismo directorio que, a su vez, debe tener un subdirectorio llamado “log”. Así mismo, por defecto, el script espera que todos los nodos tengan ubicados los scripts en la misma carpeta. En nuestro caso el directorio será “/home/oracle/EMPR/backup”. Los scripts están ubicados en almacenamiento local en cada nodo. Como se comentó, son ligeramente diferentes para cada uno. No es posible colocarlos en almacenamiento compartido en el clúster por restricciones de licenciamiento de Oracle. Para que el script maestro de backup pueda invocar comandos de manera remota a través de SSH en cualquier nodo se habilitó la equivalencia de usuario por SSH para “root”. Pasamos a describir cada uno de los scripts del esquema de copias: cluster_info.sh Este script se encarga de recopilar la configuración del clúster, tanto del registro local del nodo en el que se ejecuta (OLR) como del registro global del clúster (OCR). Se ejecuta con el usuario propietario del clúster (grid) y se invoca remotamente (por SSH) desde el script maestro de backup del clúster. node_info.sh Se encarga de recopilar toda la información de las instancias locales de bases de datos y de las instancias ASM (las que gestionan, entre otras, el almacenamiento compartido del clúster) en el nodo en el que se ejecuta. Entre otras, recopila la siguiente información: • Carpeta “dbs” del home de la base de datos y del home de la instancia ASM • Carpeta “diag” con los logs de ambos homes (DB y ASM) • Carpeta “network/admin” de ambos homes (DB y ASM) • PFILE y SPFILE de la instancia ASM local • Metadatos de las cabeceras de los discos ASM • Listados de los grupo de discos y discos de ASM • Información sobre sistemas de ficheros ACFS • Otros ficheros del nodo (oratab, oracleasm, etc, …) Se ejecuta como “root” y, al igual que “cluster_info.sh”, este script se invoca remotamente (por SSH) desde el script maestro de backup del clúster.
Actualización consolidación, migración y contingencia de un entorno hardware y software para la gestión de bases de datos Página 149 backup_cluster.sh Este script, a partir de un listado de nombres de nodo configurado en la variable “NODE_NAMES”, va recorriendo cada uno de los nodos indicados ejecutando remotamente los scripts “node_info.sh” y “cluster_info.sh” y transfiriendo al nodo desde donde se está ejecutando los ficheros “.tgz” producidos por dichos scripts. La información recopilada de todos los nodos se almacena entonces en el directorio de copias especificado (en nuestro caso “/u01/backup/BCK_APTORA”). backup_rman.sh, backup_expdp.sh, backup_ggate.sh “backup_rman.sh” realiza copias de seguridad RMAN de la instancia especificada como parámetro. Así, hace una copia, entre otros, de los datafiles, los archivelogs antiguos (borrando los que ya no son necesarios), los archivelogs nuevos, el SPFILE, y del controlfile. “backup_expdp.sh” realiza una copia lógica (export) “full” usando la herramienta “expdp” de la instancia especificada como parámetro. “backup_ggate.sh” realiza un backup de los principales ficheros de configuración del “home” de una instalación de GG pasada como parámetro así como los principales logs generados por la herramienta. backup_apt-ora-cluster.sh Este es el script maestro que hay que programar como entrada en el “cron” del usuario “root” en el nodo desde el que se vayan a efectuar las copias y que se encarga de realizar el backup completo del clúster mediante llamadas a los scripts vistos anteriormente. En primer lugar invoca a “backup_cluster.sh” para recopilar la información sobre las instancias de bases de datos del clúster y sobre las instancias ASM. A continuación invoca a “backup_ggate.sh” para recopilar información sobre la configuración y reports de GoldenGate. Seguidamente, y para cada instancia de base de datos configurada en el clúster (dependiente del ORACLE_HOME en el que estamos), invoca a “backup_rman.sh” y a “backup_expdp.sh” para realizar una copia con RMAN y otra full con EXPDP de las mismas.
Actualización consolidación, migración y contingencia de un entorno hardware y software para la gestión de bases de datos Página 150 Diferencias de configuración de los scripts de copia en cada nodo Los distintos scripts de copia de seguridad del RAC están diseñados de tal forma que se puedan adaptar con las mínimas modificaciones a cada uno de los nodos del RAC. Como se comentó anteriormente, la copia de seguridad se realiza desde un solo nodo (normalmente APT-ORA1). Sin embargo, y aunque sólo se vayan a realizar copias de seguridad desde ese nodo, es obligatorio configurar en cada nodo del RAC los scripts siguientes: cluster_info.sh node_info.sh Esto es debido a que el nodo que realiza la copia llama remotamente a éstos scripts en cada uno de los nodos para recopilar información sobre las instancias de bases de datos y ASM de éstos. Adicionalmente, y si queremos tener preparados todos los nodos de forma que cualquiera de ellos pueda realizar las copias de seguridad, por ejemplo en caso de que el nodo que hace las copias habitualmente esté offline, será preciso tener correctamente configurados en cada nodo los siguientes scripts: backup_aptcora-cluster.sh backup_cluster.sh backup_rman.sh backup_expdp.sh backup_ggate.sh La gran mayoría de las modificaciones consistirán en la modificación del valor de las variables que aparecen en la parte inicial del script (normalmente en el apartado “Configuración del script”). Para ver las modificaciones necesarias a los scripts a la hora de adaptarlos a otros nodos, tomaremos como base los scripts configurados para el nodo 1 y haremos las modificaciones oportunas para adaptarlos al nodo 2. En este caso supondremos que la ubicación de los scripts y de los destinos de copia, tanto locales como remotos, son los mismos en todos los nodos del clúster.
Actualización consolidación, migración y contingencia de un entorno hardware y software para la gestión de bases de datos Página 151 cluster_info.sh Los cambios a realizar se limitan a cambiar la ubicación por defecto en la que Oracle hace el backup automático del OLR: DEFAULT_LOCAL_BACKUP_LOCATION=/u01/app/11.2.0/grid/cdata/apt-ora2 node_info.sh En este script modificamos los datos relativos a la instancia de bases de datos (que ahora será APTORA2) y de la instancia ASM (que ahora será +ASM2). En realidad APTORA2 sólo se usa para nombrar los ficheros que hacen el backup de los directorios “dbs”, “network\admin” y “diag” (los logs) del home de la base de datos. Como estos directorios están compartidos por todas las instancias de bases de datos que dependan de este home, no es necesario realizar un backup usando los SIDs de otras instancias (si las hubiere). En este script sólo será necesario modificar el valor de las dos variables siguientes: DB_ORACLE_SID=APTORA2 ASM_ORACLE_SID=+ASM2 backup_apt-ora-cluster.sh El único cambio obligatorio en el script, está en el listado de SIDs de las instancias del clúster que se ejecutan en el nodo y que dependen de este ORACLE_HOME. Para ello cambiamos el valor de la variable: DATABASE_SIDS=( "APT-ORA2" ) backup_cluster.sh, backup_rman.sh, backup_expdp.sh, backup_ggate.sh Como hemos supuesto que las ubicaciones de los scripts y destinos de copia son los mismos en cada nodo del clúster, no es necesario realizar modificaciones a estos scripts en ninguno de los nodos. Recordemos, así mismo, que GoldenGate está completamente contenido en el sistema de ficheros de clúster ACFS compartido por ambos nodos. Modificaciones a los scripts de copia al añadir o eliminar un nodo Si hemos añadido un nodo al clúster o bien lo hemos dado de baja (por ejemplo porque está dando problemas) deberemos hacer unas mínimas modificaciones a los scripts de copia de todos los nodos del clúster.
Actualización consolidación, migración y contingencia de un entorno hardware y software para la gestión de bases de datos Página 152 Si fuésemos a añadir un nuevo nodo, “apt-ora3”, deberíamos hacer una copia de los scripts de copia de otro nodo al nuevo, realizar, sólo en el nuevo nodo, las modificaciones descritas en el apartado anterior y modificar el siguiente script en todos los nodos del clúster: backup_cluster.sh El único cambio obligatorio en el script, está en el listado de nodos del clúster. Para ello cambiamos el valor de la variable: NODE_NAMES =( "apt-ora1" "apt-ora2" "apt-ora3" ) Si fuésemos a eliminar un nodo, modificaríamos la misma variable pero esta vez eliminando el nombre del nodo al que damos de baja. Modificaciones al añadir o eliminar una instancia de base de datos Si fuésemos a añadir una nueva instancia de base de datos (supongamos que se llama APT-NEW) al esquema de copias del clúster sólo es necesario modificar el script siguiente, en todos los nodos del clúster: backup_apt-ora-cluster.sh El único cambio obligatorio en el script, está en el listado de SIDs de las instancias del clúster que se ejecutan en el nodo y que dependen de este ORACLE_HOME. Para ello cambiamos el valor de la variable: DATABASE_SIDS=( "APTORAx" “APT-NEWx” ) En este caso sustituimos la “x” por el número de instancia cuyo script estemos editando. Si vamos a eliminar una instancia del esquema de copias, sólo habremos de modificar la variable anterior y borrar el nombre de la instancia a dar de baja. Ejemplo de recuperación del servicio tras la pérdida total de discos del clúster Si el fallo afecta al propio servidor y necesitamos reinstalarlo completamente desde cero, y suponiendo que el clúster se mantenga en perfectas condiciones en el otro nodo, sería necesario reinstalar el sistema operativo, el software de clúster (Grid Infrastructure) y el software de base de datos, aplicar los parches correspondientes a
Actualización consolidación, migración y contingencia de un entorno hardware y software para la gestión de bases de datos Página 153 todos ellos y ejecutar el procedimiento que indica el manual de Oracle para reincorporar el nodo al clúster. Si el fallo afectara a ambos nodos del clúster, pero no a la cabina, habría que repetir el proceso de reinstalación descrito en el párrafo anterior para cada nodo. Si la cabina también se ha visto afectada, además de reinstalar los nodos, deberemos seguir las indicaciones del apartado siguiente. Simulación de la pérdida de discos En este caso práctico vamos a simular la pérdida completa de las LUNes de la SAN asociadas al clúster de Oracle e intentaremos recuperar totalmente el servicio a partir de los archivos generados por los scripts de backup vistos anteriormente. Supondremos que el backup se realizó en el nodo 2 (apt-ora2) e intentaremos restaurar el clúster en el nodo 1 (apt-ora1). En un caso real, y suponiendo que se hubieran perdido todas las LUNes asociadas al RAC, el administrador de la SAN nos habría asignado nuevas LUNes y las habría hecho visible a los nodos del RAC. Éstos lo verían como un dispositivo “/dev/xxx”. En breve indicaremos cómo obtener la información sobre del número de discos y su tamaño para poderle indicar al administrador de la SAN las LUNes que necesitamos. En nuestra prueba nosotros simularemos este hecho machacando las cabeceras de los discos con el comando “dd” de Linux: apt-ora1:~ # blkid apt-ora1:~ # dd if=/dev/zero of=/dev/sdf1 bs=1024 count=1 apt-ora1:~ # dd if=/dev/zero of=/dev/sdb1 bs=1024 count=1 apt-ora1:~ # dd if=/dev/zero of=/dev/sda1 bs=1024 count=1 apt-ora1:~ # dd if=/dev/zero of=/dev/sdc1 bs=1024 count=1 apt-ora1:~ # dd if=/dev/zero of=/dev/sdd1 bs=1024 count=1 apt-ora1:~ # dd if=/dev/zero of=/dev/sde1 bs=1024 count=1 Evidentemente ASMLIB ya no reconoce los discos: apt-ora1:~ # /etc/init.d/oracleasm scandisks Scanning the system for Oracle ASMLib disks: done apt-ora1:~ # /etc/init.d/oracleasm listdisks Apagamos todos los nodos del clúster y reiniciamos aquel con el que vamos a realizar la restauración.