Technical White Paper

dbFlashCopy 3.1

¿Cómo Proteger la Base de Datos con dbFlashCopy?

Autor: Martín Cabarique

dbFlashCopy es una solución para la administración de un centro activo de recuperación ante desastres.  Se denomina activo porque además de proteger la información, la copia también puede ser usada para reportes de todo tipo.

Su arquitectura se puede observar en la siguiente ilustración:

• Base de datos de producción: sobre esta base de datos se realizan todas las operaciones que alteran la información.
• Redologs: son los archivos que registran los cambios a la base de datos de producción.  Estos archivos son respaldados por la base de datos, los que se denominan Archivelogs. dbFlashCopy detecta y transporta dichos archivos (Archivelogs) luego de lo cual la información se considera protegida.
• Base de datos Standby: es la copia de la base de datos de producción.  dbFlashCopy aplica los Archivelogs de forma que en caso de falla, dicha base de datos puede operar como producción en pocos minutos.  Además administra la base de datos para que pueda ser usada con fines de consulta, lo que permite balancear la carga de los usuarios.

CARACTERÍSTICAS DE dbFlashCopy

Los servicios provistos por dbFlashCopy se clasifican de la siguiente forma:

• Servicios en permanente operación

• Protección: este servicio es el responsable de mantener protegida la Base de Datos de producción ante fallas de cualquier tipo.  Para ello realiza una detección permanente de nuevos Archivelogs en producción para luego transferirlos al servidor de la base de datos Standby.  En promedio dbFlashCopy garantiza detectar e iniciar el copiado de los cambios en 30 segundos.
• Sincronización: a través de este servicio se realiza el proceso de aplicación de los cambios desarrollados a la Base de Datos de Producción.  Dicha aplicación se puede hacer en línea cuando arriba un nuevo Archivelog o programada según un calendario definido por el DBA.  Además se puede establecer un retraso en la aplicación, 2 horas por ejemplo, para protección contra errores humanos.
• Base de datos para consultas: dbFlashCopy administra automáticamente la base de datos Standby para que pueda ser usada para consultas.  Según la configuración definida por el DBA responsable, dbFlashCopy sincroniza en los periodos establecidos luego de lo cual abre la base de datos Standby para consultas.  Si la misma está en RAC, abre la base de datos en todas las máquinas del cluster.
• Envío de alertas proactivas: cada dos minutos dbFlashCopy autodiagnostica el estado de los servicios y de la base de datos Standby.  De manera automática trata de resolver las alertas encontradas.  Sin embargo si luego de 10 minutos dicha alerta no ha sido superada, dbFlashCopy envía un email al DBA responsable para que participe oportunamente en la solución del problema.
• Envío de reporte de estado: cada noche dbFlashCopy envía al DBA un email con el estado de los servicios junto con el estado de generación, protección y aplicación de Archivelogs a la base de datos Standby.
• Administración del espacio usado por Archivelogs en el servidor de respaldo: dbFlashCopy periódicamente elimina los Archivelogs que ya han sido aplicados a la base de datos Standby, liberando así al DBA de tareas manuales de borrado de archivos, que además son una fuente frecuente de errores humanos.
• Cálculo de estadísticas históricas: diariamente dbFlashCopy recalcula las estadísticas históricas en base a la operación registrada en el dia anterior.

• Portal de Administración y monitoreo: este servicio permite al DBA monitorear el estado de los servicios de protección y sincronización de una forma amigable y desde cualquier navegador, así como hacer uso de los servicios de recuperación ante desastres.  Las siguientes ilustraciones permiten observar algunas de sus facilidades:

Home Page

• Status: refleja el estado de los servicios y es administrado en forma automática por dbFlashCopy en su operación interna.  dbFlashCopy se autodiagnostica cada dos minutos revisando dicho estado y en caso de encontrar alguna alerta, aplica los mecanismos de solución previstos para la misma.  Por ejemplo, si la Base de Datos Standby no está abierta para reportes (Standby not ready), procede a abrirle.  Algunos de los diagnósticos soportados son:

• Stopped: Standby Server or dbFlashCopy's Standby repository is down or Communication errors
• Stopped: Primary Server or dbFlashCopy's Primary repository is down or Communication errors
• Inactive configuration after failover.  Need to reinstate the configuration
• Inconsistent dbFlashCopy properties.  Check the configuration
• Switchover in progress
• Failover in progress
• Switchover failed.  Reactivate the configuration
• Started with problems in the Protection Service
• Started with problems in the Sync Service
• Stopped
• Started
• Installing dbFlashCopy
• Primary Database Instances has been restarted.  dbFlashCopy will restart automatically
• Recovery Process unexpectly offline
• Protecting
• Invalid license
• Low Space for Archivelog Files on Standby
• Started with problems: there are not configure Sync Scheduler and configuration is Async Read Only
• Standby not ready

Este autodiagnóstico es el corazón de dbFlashCopy y no requiere que el DBA esté conectado al portal de administración.  Es equivalente a tener a un operador monitoreando dbFlashCopy y en caso de no poder resolver la alerta, envía un email al DBA responsable.

• State: este gráfico ilustra cómo se encuentran las bases de datos, standby y producción, junto con lo transportado, usando barras de colores que facilitan el análisis del DBA. Los números encima de cada barra identifican el último Archivelog generado, transportado y aplicado.
• Tacometros: muestran el diagnóstico tanto del servicio de protección como de sincronización.  Para el ejemplo ilustrado se puede concluir que todos los cambios hechos en producción se protegieron y aplicaron a la base de datos Standby.

Los colores ayudan también a identificar situaciones de potenciales problemas.  Por ejemplo la zona de color rojo indica peligro pues en caso de falla del servidor de producción a ese instante, se pueden perder los cambios registrados en dichos Archivelogs no transportados.

Performance

• Redo Generado: esto corresponde a las escrituras a los redologs en producción, los cuales equivalen al espacio ocupado por los Archivelogs en dicho periodo de tiempo.
• Network Speed: esta se muestra en Kbps, ilustrando el promedio, maximo y minimo de velocidad que la red ha soportado en el periodo de tiempo correspondiente.
• Last Year Statistics: muestra la información de Redo Generado y Network Speed para los últimos doce meses.

Administration

• Disaster Recovery Services: desde esta ventana se tiene acceso a las operaciones de recuperación antes desastres.  En la siguiente sección se detallarán las mismas.
• Manual Sync Standby: dbFlashCopy automáticamente sincroniza la base de datos Standby con producción sin necesidad de intervención del DBA.  El propósito de este Wizard es complementar dicha funcionalidad, dando control al DBA sobre dicho proceso cuando así la ocasión lo requiera.  Por ejemplo en caso de errores humanos, el DBA necesita aplicar los cambios solo hasta el momento antes del daño.  Si el daño ocurrió alrededor de la 1:50pm del 9 de Abril del 2014, usando el Wizard el DBA puede aplicar los cambios justo antes de esa hora:

Otro uso para este Wizard es cuando se desea mantener sincronizada la base de datos Standby en relación a procesos propios de la organización que no tienen una hora fija de finalización.  Por ejemplo luego del cierre diario contable.  En dicho caso de la misma forma el DBA puede usar este Wizard para sincronizar justo al tiempo en el cual dicho proceso se da por terminado.

Archives

• Remove Unneeded Archivelog Files: como se mencionó anteriormente en la sección de servicios permanentes, dbFlashCopy de manera automática elimina periódicamente los Archivelogs que ya han sido aplicados a la base de datos Standby.  Esta opción le otorga control adicional al DBA sobre dicho proceso de manera que pueda bajo demanda eliminar los Archivelogs sobrantes, liberando el espacio ocupado.  Por ejemplo si necesita hacer un Export de la base de datos y necesita espacio, esta opción puede ser usada.
• Archivelog File Details: de manera automática dbFlashCopy envía nuevamente Archivelogs que se detecten como corruptos en el servidor Standby.  Esta opción le da además el control al DBA para cuando, por necesidades especiales que el determine, quiera reenviar un archivelog desde producción.  Para ello basta con editar el Archivelog como en la ilustración anterior y cambiar el valor del campo Copy to Standby a No.

Users Administration

• dbFlashCopy cuenta con dos tipos de usuarios: Administrador y Operador.  Mientras el Administrador puede realizar todas la operaciones soportadas por dbFlashCopy, el operador solo puede realizar operaciones de diagnóstico.  El administrador puede además crear, modificar o eliminar usuarios, como en la ilustración.

MANEJO DE EMERGENCIAS

dbFlashCopy provee las siguientes operaciones de recuperación ante desastres:

• Switchover: este servicio es usado cuando se presenten imprevistos que afecten la operación de manera crítica, pero que permiten a la Base de Datos de producción llegar al estado mount.  Es el caso por ejemplo de daños de discos o eliminación accidental de archivos de la base de datos.  También puede usarse en casos de mantenimientos programados o migraciones hacia otros servidores.

El resultado de este servicio es que la configuración se invierte, dejando la Base de Datos de producción como standby y la standby como producción.  Las aplicaciones se conectarán hacia el servidor standby (ahora producción) y los cambios realizados se aplicarán sobre el nuevo standby (anterior producción).

Para realizar esta acción se debe ingresar a las opciones de Administration mostradas anteriormente y ejecutar el Wizard que se ilustra a continuación:

• Current Sessions: muestra las sesiones actuales sobre la base de datos de producción. Puede hacer filtros para consultar por ejemplo por sesiones de un usuario en particular, u ordenar por cualquiera de las columnas del reporte.  Una consulta tradicional antes de un Switchover es saber si hay transacciones activas, con cambios pendientes por aplicar y que tan grandes son.  Eso fácilmente se puede obtener ordenando por la columna Record To Undo o con un filtro que muestre valores NOT NULL en dicha columna y luego ordenando.
• Proceed with Switchover: cuando esté seguro de hacer el proceso, presione este botón para ejecutar el proceso.  Aparecerá la siguientes ventana para dar seguimiento al proceso:

Cuando alcance el 100% sus usuarios se pueden conectar nuevamente y continuar la operación normal de las aplicaciones.  
dbFlashCopy traslada en forma automática los servicios que estén configurados hacia la nueva base de datos de producción de forma que para los usuarios sea transparente a que servidor se están conectando.  Para ello es necesario que los usuarios tengan en su configuración definida una cadena de conexión que incluya a ambos servidores, producción y Standby.  Un ejemplo complejo de la cadena de conexión soportada para un ambiente donde ambas bases de datos están en RAC sería:

DEMODBT =

  (DESCRIPTION =

    (ADDRESS_LIST =

      (ADDRESS = (PROTOCOL = TCP)(HOST = dbFlashCopy1-vip)(PORT = 1521))

      (ADDRESS = (PROTOCOL = TCP)(HOST = dbFlashCopy2-vip)(PORT = 1521))

      (LOAD_BALANCE = yes)

    )

    (ADDRESS_LIST =

      (ADDRESS = (PROTOCOL = TCP)(HOST = ha1-vip)(PORT = 1521))

      (ADDRESS = (PROTOCOL = TCP)(HOST = ha2-vip)(PORT = 1521))

      (LOAD_BALANCE = yes)

    )

    (LOAD_BALANCE = yes)

    (CONNECT_DATA =

      (SERVICE_NAME = demo)

      (FAILOVER_MODE =

        (TYPE = SELECT)

        (METHOD = BASIC)

        (RETRIES = 180)

        (DELAY = 5)

      )

    )

  )

En este caso el servicio que está administrando dbFlashCopy se llama demo.

Otra opción comúnmente usada para hacer transparente a los usuarios la conexión al servidor primario o standby es definir un nuevo nombre en el DNS distinto a de los dos servidores, y usar dicho nombre en la cadena de conexión.  De esta forma basta con modificar en el DNS la IP asociada a dicho nombre para que los usuarios se conecten al servidor apropiado.

También se puede ejecutar en modo de comandos.  Para ello ingrese a la Base de Datos de dbFlashCopy como usuario RCD y ejecutar el siguiente comando:

remote_copy_database.execute_switchover;

• Failover: este servicio es usado cuando se presente un imprevisto que impide a la Base de Datos llegar al estado mount.  En este caso la Base de Datos standby es activada con los cambios aplicados hasta el último paso de información, perdiéndose solo los cambios almacenados en el current redolog.  Dado que este servicio no garantiza que todos los cambios sean aplicados, esta es la última opción y debe usarse solo en casos extremos de pérdida total del servidor o Base de Datos de producción.  Es conveniente consultar con nuestro centro de soporte antes de usar esta operación.  

Para usar esta opción se debe ingresar por Administration y allí seleccionar el botón Failover.  El resultado es:

Si ya hizo todas las validaciones del caso, presione Continue Failover.

Método Manual:  ingresar a la Base de Datos de dbFlashCopy con usuario RCD o LCD según corresponda al servidor Standby y ejecute el siguiente comando:

remote_copy_database.execute_failover;

• Convert Standby to Read Only: esta operación es usada en caso de errores humanos.  La misma detiene la aplicación de cambios a la base de datos Standby y permite al DBA con un sencillo wizard la aplicación de los cambios hasta antes de daño.  De esta forma la base de datos Standby puede ser usada para Exportar la información a la base de datos de producción.  Hay múltiples métodos soportados para este paso de información: exp, expdp o dblinks.

CREACIÓN DEL STANDBY DATABASE

Para facilidad de la creación del standby database, dbFlashCopy provee de un sencillo Wizard llamado Create or Reinstate dbFlashCopy Configuration, el cual desarrolla todo el proceso completo de configuración, partiendo desde la Base de Datos de producción para crear la Base de Datos Standby y finalmente dejar activos los servicios de protección correspondientes.  Las siguientes ilustraciones muestran un ejemplo de la ejecución del wizard:

• Acceso al Wizard de activación de la configuración:
• Información de directorio de backups y controlfiles.  El DBA es responsable de la existencia, permisos y espacio en dichos directorios:
• Conversión de ubicación de archivos en producción a estructura de directorios de standby. El DBA es responsable por la existencia, permisos y espacio en dichos directorios.  

Esta información se provee como una serie de tuplas, cada una registrando un posible cambio en la ubicación de los datafiles y redologs:

• Verificación de configuración de estructura de datafiles de la Base de Datos.  Las tuplas anteriores generan cambios en la ubicación de los datafiles, las cuales se observan en el wizard.  Esta ubicación también puede ser cambiada directamente o puede regresar a la opción anterior para crear o modificar una de las tuplas:
• Actualización de parámetros de la instancia.  Es muy importante recordar que durante la instalación realizada se especificaron las siguientes variables cuyos valores deben coincidir con la información aquí registrada:

• alert file: la variable background_dump_dest es el directorio donde se escribe dicho archivo.  Aunque no es un requisito, es deseable mantener la estructura OFA, de manera que las variables user_dump_dest, audit_file_dest y core_dump_dest deberían coincidir con dicha especificación también.
• log archive dest: la variable standby_archive_dest y log_archive_dest deben coincidir con la especificación realizada.

• Activación de la configuración: este último paso se monitorea con el siguiente tacómetro:

Al momento que este llegue al 100% la configuración se ha concluido y los servicios de dbFlashCopy estarán activos.

CONTROL DE PARÁMETROS DE OPERACIÓN

La arquitectura de los servicios de dbFlashCopy ha sido diseñada para ser controlada a través de parámetros de fácil control en su entorno gráfico de Administración.  Para acceder a dichos controles, se debe navegar al tab Configuration, el cual muestra el siguiente resumen de la configuración actual:

Para cambiar la configuración actual, presionar el botón Edit, el cual despliega los siguientes controles:

• Database Name - Nombre de la Base de Datos que se está protegiendo.  Equivale al parámetro de la BD db_name.
• dbFlashCopy Starter Status - Acepta los siguientes valores de configuración:

• Started: los servicios de dbFlashCopy se mantendrán arriba.
• Stopped: los servicios se mantendrán abajo.

• Services – Usado para implementar la funcionalidad de Transparent Application Failover, de forma que las aplicaciones se conecten de forma transparente al nuevo servidor de producción ante una falla de la base de datos.

Para su correcta operación es necesario que los usuarios tengan una cadena de conexión usando alguno de los servicios definidos en este parámetro.  Por ejemplo si se configura este parámetro en 'oltp','dss','crm', la cadena de conexión de usuarios de CRM debería definirse como:

CRM =

     (DESCRIPTION =

         (ADDRESS = (PROTOCOL = TCP)(HOST = dbFlashCopy1)(PORT = 1521))

         (ADDRESS = (PROTOCOL = TCP)(HOST = ha1)(PORT = 1521))

         (LOAD_BALANCE = yes)

         (CONNECT_DATA =

             (SERVICE_NAME = crm)

         )

     )

• Transport Mode - Permite elegir entre los dos modos de operación de dbFlashCopy.  Estos son:

• Best Performance: reduce el consumo de recursos al mínimo, operando de una manera suspendida, en la cual el consumo de recursos es imperceptible, y activándose al momento llenarse un redolog y generar un archivelog.
• Best Protection: privilegia la protección de la información, permitiendo establecer una ventana de tiempo en minutos, como máximo periodo durante el cual la información esta en riesgo.  En caso de eventualidades, el riesgo de pérdida de información está limitado a dicha ventana de tiempo.

• Maximum Risk Time (Minutes) - Configura la ventana de tiempo para el modo de operación Best Protection. El valor mínimo es un minuto.
• Standby Mode – Determina la forma de operación automática que realizará dbFlashCopy sobre la base de datos Standby,  Los valores soportados son:

• Recovery: la base de datos standby se usará sólo con propósitos de recuperación.  Por tanto su estado es Mount, el cual permite la aplicación de los cambios de manera inmediata cuando arriben al servidor.
• Async Read Only: la base de datos se mantendrá abierta para consultas y los cambios se aplicarán de forma asincrónica según la configuración en el Sync Scheduler (revisar su configuración más adelante en Architecture).
• Manual: al igual que el modo Async Read Only, esta forma de operar la base de datos Standby permite el uso de la misma con fines de consulta.  Sin embargo en este modo la sincronización es controlada y ejecutada directamente por el DBA.  

Use este modo cuando se requiere disponer de la Base de Datos Standby sincronizada a tiempos determinados por procesos externos, como por ejemplo el cierre de la contabilidad.  

• Trace Level - Activa o desactiva el trace de las operaciones de dbFlashCopy.  Usualmente debe permanecer apagada esta opción y solo activar en casos de resolución de problemas.

• Archives Lifetime in Hours -  Configura el periodo de tiempo en horas usado para hacer el mantenimiento automático de los archivelogs en el servidor standby.  Por ejemplo si se configura en 24, dbFlashCopy liberará el espacio de los archivelogs no requeridos cada 24 horas.  
• Compress - Activa o desactiva la compresión de la información enviada por dbFlashCopy. Active este control cuando implemente dbFlashCopy en una red WAN con baja capacidad de transferencia, lo que ahorrara mas del 80% del tráfico en la red.  

Es necesario considerar que la compresión sólo opera cuando los archivelogs no son almacenados en ASM tanto en la BD primary cómo standby.  En caso de usar RAC, use un file system de Cluster como OCFS, ACFS o también puede usar NFS para presentar los directorios destino donde se almacenan los archivelogs en el servidor donde se instale dbFlashCopy.

• Delay in Minutes - Configura la protección contra errores humanos.  Este control determina la diferencia en tiempo de sincronización entre la BD de producción y el sitio alterno.  De esta forma, en caso de un error humano en producción, se tiene esta ventana de tiempo durante la cual se puede recuperar la información del sitio alterno.
• Send Alerts – Determina el manejo de las alertas detectadas por dbFlashCopy. Los valores soportados son:

• Alerts & Daily Report: envía tanto las alertas como un reporte diario del estado de los servicios a los correos definidos en la configuración.
• No send any alert: no hay envío alguno al email
• Daily Report: envía un reporte diario del estado de los servicios.  Un ejemplo de las estadísticas enviadas es: Las estadísticas enviadas

• SMTP Server - nombre o dirección IP del servidor SMTP para envío de las alertas
• SMTP Port - puerto del servidor SMTP
• Sender - email usado como remitente de los mails de alerta
• e-mail to Send Alerts - emails a los que se desea enviar las alertas.  Sin son varios, separar con coma entre los mismos.
• Max Archives Not Copied – Número mínimo de archivelogs registrados como aún no copiados al servidor standby para que se genere una alerta.  
• Max Archives Not Applied – Número mínimo de archivelogs no aplicados a base de datos standby para que genere una alerta
• Min Free Space – Espacio mínimo en Mb que debe estar disponible en el servidor standby para la escritura de archivelogs.  En caso de alcanzarse este valor, dbFlashCopy en forma automática eliminará los archivelogs ya aplicados.  Si aún así el espacio disponible es inferior al valor establecido, se generará una alerta.
• License Id – Código de la licencia.  Comunicarse con Soporte del producto para obtener el código correspondiente.

MANEJO DE BASE DE DATOS STANDBY

dbFlashCopy provee de tres forma para administrar su base de datos Standby:

• Recovery: en este modo la base de datos se mantiene constantemente sincronizada con la base de datos de producción.  Cada vez que un nuevo archivelog arriba al servidor Standby, el mismo es aplicado en forma inmediata o con un retraso en minutos según el parámetro Delay in Minutes.
• Async Read Only: en este modo la base de datos standby se mantiene abierta en modo Read Only de manera que se use para generación de reportes.  De esta forma los reportes más pesados que usan la información histórica usarán los recursos del servidor Standby en lugar del servidor de producción.  Se recomienda usar este modo para balancear el uso de recursos entre los servidores de la configuración.
• Manual: este modo de operación, similar al modo Async Read Only, tambien sirve para operar la Base de Datos como fuente de información para reportes y balanceo de carga.  Sin embargo en este modo la sincronización es controlada en forma directa por el DBA.  Es útil para ambientes donde se desea tener un mayor control en la sincronización del Standby, por ejemplo en dependencia con la finalización de procesos especiales de cierre de día.

La siguiente ilustración muestra cómo cambiar el modo de operación del Standby.  Para ello navegue a Configuration :

La administración de la base de datos Standby es automática según la forma como se halla configurado el parámetro Standby Mode.  

CONCLUSIONES

dbFlashCopy es una solución de fácil implementación y fácil uso en caso de daños de la base de datos Oracle.  Su funcionalidad es provista en versiones Standard y Standard Edition One, permitiendo alcanzar óptimos niveles de protección de la información así como garantizando una rápida recuperación de los servicios de la Base de Datos.

Su interfaz de Administración es de sencillo uso y pone al alcance del DBA los controles necesarios para garantizar tanto que la información esté debidamente protegida como facilita el que hacer cuando una falla se presente.