Oracle Standby Database, un amigo para 1000 casos…

Reciban estimados tecnólogos Oracle un cordial saludo. A través del presente artículo, tendremos la oportunidad de visualizar y adentrarnos un poco en el tema de que es un “Standby database” y como puede este ayudarnos en nuestra gestión como “DBAs”. Podemos definir de una manera sencilla que un “Standby Database” es una Base de Datos ( BBDD ) copia ( Física o Lógica ) de una BBDD origen, a la BBDD origen comúnmente se le denomina BBDD primaria. Los posibles usos de bases de datos “Standby” son múltiples, pueden ser útiles para un sin numero de casos entre los cuales podríamos citar los siguientes:

• BBDD de contingencia para casos de desastres e indisponibilidad de BBDD origen
• Reportería
• “Offload” de respaldos de BBDD primaria
• Pruebas temporales en modo Read/Write
• BBDD intermedia como futuro elemento de “Upgrade”
• Y muchas mas de las cuales seguiremos conversando..

La concepción importante de este articulo es plasmar cuales son algunos de los posibles casos en los cuales nosotros los “DBAs” podemos apoyarnos en “Standby Databases” para llevar a cabo actividades múltiples.

De forma típica el “Standby Database” puede ser visualizado como un elemento diseñado para una solución de “Disaster/Recovery” pero es allí donde hago referencia del titulo del articulo… el “Standby Database” puede ser un amigo invisible que puede ayudarnos en su funcionamiento con el objetivo de ser útil mas allá de su uso conceptual típico.

En mi caso particular, trabajo y conozco los “Standby Databases” desde versión Oracle8, al principio de mi carrera tenia el concepto básico de que un “Standby Database“ constituía un tipo de configuración que estaba principalmente orientado a establecerse con el objetivo de realizar un restablecimiento de operaciones de BBDD para la continuidad de negocios en caso de desastre con el sitio primario, sin embargo la utilidad de las mismas va mas allá del mencionado caso. La concepción operacional de un “Standby Database” es bastante sencilla. La misma representa una BBDD replicada de forma Física o Lógica en el tiempo. Veamos cuales son las diferecias:

“Standby Físico”

Representa la conformación de una BBDD que es replicada bloque a bloque respecto a la BBDD primaria.Cuando lo realizamos de forma física, uno de los aspectos más importantes a tener en cuenta es que la replicación se llevara a cabo en base a bloques de Oracle, los bloques de Oracle representan información codificada en el sistema operativo en el cual fueron creados. Con esa descripción tan sencilla pero clave podremos tener un fuerte fundamento de cuales son algunas restricciones que podríamos tener con replicaciones físicas.

Endian Format:  No podremos conformar un “Standby” físico en un sistema operativo que posea un “Endiat Format” distinto porque esto requeriría una conversión de bloques en vivo durante la replicación, aspecto que hasta la ultima versión de “11gR2” no había sido desarrollado. Ej: no puede replicar de forma directa bloques generados en un sistema operativo con “Endian Format” “Big” provenientes de un sistema operativo con “Endian Format” “Little” y viceversa.

Versión de Manejador: se podrán realizar instanciaciones y procesos de recuperación en versiones de manejador superiores para realizar “Rolling Upgrades”. Nota: lo referente a la versión y “Rolling Upgrades” es solo para “Standby” físicos, en el caso de los “Standby” Lógicos ya la BBDD estará abierta y posiblemente en la versión superior.

“Standby Lógico”

Las BBDDs con replicación lógica se realizan a través de replicación de “SQL Statements”. Una de las principales limitaciones que poseerá, estará basada en los tipos de datos que no podrá replicar, las versiones de “Oracle Database” han ido evolucionando respecto a dicho punto y dependerá de cual versión use.

Posee como ventaja entre tantas otras, el poder recibir una replicación Multi-Versión, es decir, una BBDD en versión “10g” pudiese estar replicando cambios a una BBDD en versión “11g” de forma directa, estando la BBDD destino en modo “Read-Write”. A continuación ilustrare algunos posibles usos de los “Standby Databases”:

“Disaster/Recovery”: este el uso mas típico de la mencionada solución y/o configuración. En un ambiente de producción típico se posee(n) la(s) BBDD(s) de producción en un determinado Centro de Computo en una localización geográfica “x” y la solución habitual deseada se basa en establecer un “Standby Database” en un Centro de Computo en una localización geográfica distinta, todo esto con el objetivo de poseer una BBDD de contingencia para poseer disponibilidad de servicio en caso de fallo de la BBDD Primaria.

“Upgrade/Manual Rolling Upgrade”: planteemos que se posea una BBDD en un Servidor “A” de 25TB en versión 10g(10.2.0.5) y deseemos llevar a cabo el “Upgrade” de la misma a versión 11g(11.2.0.3) en un servidor “B”. Para llevar a cabo esta tarea tendríamos que emplear un técnica que nos provea de un “Upgrade” de “Downtime” corto o como es llamado en el mercado, un “Upgrade” de tipo “Zero Downtime”, dicha filosofía se ajusta a BBDDs que poseen una actividad critica y cuyo objetivo siempre estará basado en permanecer en no servicio el menor tiempo posible. Por las medidas mencionadas, el aplicar un método lógico con el uso de utilitarios tales como: “exp/imp/expdp/impdp”, tornaría inviable el “Upgrade” en base a la cantidad considerable de tiempo que tomaria.  Para este caso lo ideal es construir un “Standby Database” en modo “Cross Version”, llevar a cabo una restauración y recuperación de BBDD en el manejador versión 11gR2 en base a “backups” y “Redo Log Archives” provenientes de 10g, el “Restore/Recover”, estas operaciones mencionadas no formaran parte del “Upgrade Downtime”, de esta forma se podrá conformar una imagen de BBDD sincronizada en la versión destino hasta llegado el momento de la migración real. En líneas generales un “Standby Database” “Cross-version” no es mas que un “Standby Database” tradicional configurados entre versiones distintas y que tendrá la salvedad de que su método de apertura será distinto al método tradicional, en este caso, el método de apertura se realizara en modo “Upgrade” ( “Startup Upgrade”).

“Upgrade/Oracle Streams”: “Oracle Streams” en una solución de propagación de mensajes a través de formaciones en paquetes, los mensajes transportan información entre “Schemas”, bases de datos y mas. “Oracle Streams” realiza una replicación a través de la red en paquetes de información que se transmiten vía “SQL*Net messages”, dicha información transmitida esta en codificación de lenguaje SQL, siendo esta versátil para usarse en cualquier plataforma o sistema operativo. La replica con “Oracle Streams” pudiese llevarse a cabo bajo diversas condiciones iníciales. La que se alinea con el contexto que estamos presentando es aquella donde una replicación con esta solucion necesite una BBDD originalmente instanciada para iniciar su proceso de replicación en un determinado “SCN” o a un determinado punto del tiempo. Entonces, bajo este caso nosotros podríamos proveer una imagen inicial para el proceso de replica a través del establecimiento de un “Standby Database”.

“Upgrade/Oracle Golden Date”: “Oracle Golden Gate” “OGG” es una solución de extracción y replicación de información entre “Schemas” , bases de datos y otros utilizando un sistema de archivos particulares propias de la solución. La replica con “OGG” pudiese llevarse a cabo bajo diversas condiciones iníciales. La que se alinea con el contexto que estamos presentando es aquella donde una replicación con “OGG” necesite una BBDD originalmente instanciada para iniciar su proceso de replicación en un determinado “SCN” o a un determinado punto del tiempo. Entonces, bajo este caso nosotros podríamos proveer una imagen inicial para el proceso de replica a través del establecimiento de un “Standby Database”.

“Reporting”: Es común que la mayoría de empresas posean BBDDs para ejecutar reportes que podrían tornarse muy pesados y degradantes para la BBDD de producción, un “Standby Database” es un aliado perfecto para este objetivo.

“Offload de Backups”: Siendo un “Standby Database” una copia exacta bloque a bloque de la BBDDs de producción. Se puede tomar ventaja de esta característica para que nuestros respaldos se realicen en los “Standby Databases” en vez de realizarlos directamente contra el Servidor de la BBDD de producción. Esta característica esta disponible a partir de “Oracle Database 11g”. Las señaladas solo son algunos enfoques de utilidad de los “Standby Databases”. Hago remembranzas de una reunión, que en una ocasión sostuve con unos clientes donde les mencionaba las ventajas que podían tener con el uso de “Standby Databases” y me mencionaban que no podían implementar “Data Guard” porque no poseían licencia de servidor “Enterprise”, en ese momento les explique que un “Standby Database” es el elemento motivo de la solución denominada “Data Guard”, es decir, que aunque ambos conceptos estaban relacionados, pero que no eran lo mismo. Divise la misma duda en diversos clientes y por ello decidí incluir una breve descripción al respecto en este articulo. Un “Standby Database” por si solo es una configuración de replicación de BBDDs ( Física o Lógica ) que se puede llevar a cabo con versiones inclusive como la “Standard”, la funcionalidad esta basada en una instanciación de BBDD controlada por un “Controlfile” tipo “Standby” el cual nos permite establecer diversos modos en una imagen de BBDDs recuperable. Cuando se posee un “Standby Database” la misma se puede establecer en modo: “Recover”: puede aplicar “Archive Redo Logs” provenientes de la BBDD de producción “Read only”: puede ser consultado en modo consulta contando con la funcionalidad de que posteriormente puede volver a establecerse en modo “Recover”, esto es una propiedad que solo poseen las “ Standby Database”, para el caso presente la BBDD detiene su proceso de “Recover” y se mantiene con una imagen consistente a nivel a nivel de bloques. “Read Only with Recover”: esta opcion esta disponible a partir de versión 11g. La misma tiene la posibilidad de poseer la BBDD en modo “Read Only” con el proceso de “Recover” activo, esta opción es licenciada y es denominada “Active Data Guard”. Cuando se posee un “Standby Database” que no es manejado por la solución “Data Guard”, la replicación y aplicación de “Archive Redo Logs” es manual. El DBA debe implantar “scripts” de automatización, control y monitoreo para el mismo.

Ahora… Que es Data Guard ? es una solución de replicación automatizada de BBDDs basada en “Standby Databases”. “Oracle Data Guard” es una solución que ofrece el mecanismo que conformar “Standby Databases” con mecanismos automatizados propios de la solución, el DBA ya no tendrá que generar “scripts” para automatizar, controlar y monitorear la solución. Aparte de lo mencionado, “Oracle Data Guard” posee funcionalidades adicionales dependiendo si se posee licenciado su opción “Active”. Con la opción “Active Data Guard” se poseerán las siguientes características adicionales:

1.- Apertura de la BBDD en modo “Read Only” con aplicación de cambios en tiempo real: Para el usuario será una BBDD que refleja los cambios de producción en modo real y constante en el tiempo, teniendo la posibilidad de consultar la misma sin aplicar cambio de estatus a la misma. Se posee lectura y proceso de recuperación constante.

2.- Auto-corrección de bloques corruptos en vivo: Este mecanismo permite corregir posibles defectos de escritura de bloque en la BBDD primaria. La replicación de información entre bases de datos se realiza bloque a bloque directamente desde la memoria de la BBDD primaria, esto asegura que el bloque que va hacia el destino no posee posibles errores producto de su escritura en medios físicos en el primario.

3.- “Offload Backups” activando la opción “Block Change Tracking” se podrán obtener respaldos del “Standby Database” con la misma consistencia como si se estuviera realizando contra la BBDD primaria

4.- “Snapshot Standby Database”: existe la posibilidad de apertura de alguna de las “Standby Databases” en modo “Read-Write” para llevar a cabo pruebas. Los cambios realizados se guardaran en “Flash Logs” y se establecerá un tiempo de retorno, tiempo descriptivo de cuando se realizo el cambio a “Read-Write”. Los cambios ejecutados por los usuarios modificaran la BBDD, una vez que se culminen las actividades, se retornara la misma a modo “Recover”. Para ello el mecanismo de “Snapshot” aplicara un proceso de deshacer en todas las transacciones que se realizaron desde el punto en que la BBDD se estableció en modo “Read Write”, se realizara un cambio de estatus de la BBDD a modo “Recover” y la misma continuara sus actividades en dicho estado.   

“Oracle Data Guard” posee un “framework” de administración denominado “Data Guard Broker” en cual se pueden automatizar funcionalidades de administración como realizar cambios de roles entre BBDD primaria y “Standby Database” ( “Switchover” & Failover ). Dichos mecanismos tuviesen que gestarse manualmente si se tuviese una “Standby Database” no gestada con “Oracle Data Guard”.

Joel es un experto DBA con más de 12 años de experiencia, especializado en bases de datos con especial énfasis en la soluciones de alta disponibilidad (RAC, Data Guard, y otras). Es un conferencista habitual en eventos de Oracle como: OTN LAD TOUR y otros. Consultor Internacional con trabajos en más de 20 países alrededor del mundo. Fue el primer latinoamericano en ser nombrado "Experto OTN" en el año 2003, Oracle ACE año 2004 y actualmente Oracle ACE Director.

Yenugula Venkata Ravikumar es un DBA con más de 15 años de experiencia especializada en entornos de alta disponibilidad de bases de datos (RAC, Data Guard, entre otros), afinamiento y rendimiento, migraciones, backup y recuperación, Oracle Exadata X2 y X3, es experto en sistemas operativos tales como AIX, HP-UX y Linux. Ha participado como conferencista en varios eventos de Oracle en la India, donde reside actualmente. Obtuvo el título "Oracle Certified Master (OCM 10g)" en el 2009.