Estrategia de disaster recovery hibrido "On-Premises/Cloud" con Dataguard

Seguir las prácticas de Oracle’s Maximum Availability Architecture (Oracle MAA) es la mejor manera para proteger y mantener la disponibilidad de los datos cuando utilizamos base de datos Oracle.

Tanto sea el caso que estas están desplegadas en nubes privadas, públicas o hibridas.

Dataguard y Active Dataguard permiten la recuperación de bases de datos ante desastres (disaster recovery), de manera muy rápida, y cuando los objetivos de RTO no se puede alcanzar realizando la restauración desde un backup.

La utilización de este tipo de soluciones implica implementar uno o más réplicas sincronizadas (bases de datos standby) de una base de datos de producción (base de datos primaria) en

ubicaciones físicamente separadas y las cuales  proporcionan  de esta manera alta disponibilidad, protección integral de datos y recuperación ante desastres a bases de datos de misión crítica.

Oracle Cloud: Creando una Base de datos Standby Lógica en la nube (Parte III)

Base de datos lógica

Convirtiendo la base de datos Standby física en una base de datos lógica

1. Verificamos tipos de datos y tablas no soportadas

Antes de comenzar a configurar la base de datos Standby lógica, debemos asegurarnos que ésta pueda soportar los tipos de datos y tablas de nuestra base de datos Primaria.

Esta verificación la realizamos desde la misma base de datos Primaria ejecutando la siguiente consulta:

SELECT DISTINTC OWNER FROM DBA_LOGSTDBY_UNSUPPORTED;

Oracle Cloud: Creando una Base de datos Standby Lógica en la nube (Parte II)

Trabajando con la futura base de datos standby

Ahora abrimos dos instancias diferentes usando “Putty” y nos conectamos vía SSH a ambas máquinas virtuales en la nube.

 

Verificamos el “hostname” y el proceso pmon en cada servidor:

Oracle Cloud: Creando una Base de datos Standby Lógica en la nube (Parte I)

En esta serie de artículos les mostraremos como crear una base de datos standby lógica en la nube. Para realizar esto necesitamos tener dos instancias en Oracle Cloud.

Creación de Instancia Primaria:

Iniciamos sesión en "Oracle Database Cloud Service" y creamos un nuevo servicio, en la página de creación seguimos los siguientes pasos:

• Indicamos un nombre de servicio. (“Primary”)
• Seleccionamos el service level ("Oracle Database Cloud Service" ).
• Seleccionamos la frecuencia de medición (Metering Frequency)(Monthly)
• Seleccionamos versión de software ("Oracle Database 11g Release 2").
• Seleccionamos edición de software ( "Enterprise Edition").
• Tipo de base de datos (“Single Instance”)
• Finalmente hacemos click en “Next” para continuar. 

Failover y Reinstating usando "dbaascli" en Oracle Cloud

En este nuevo artículo sobre Data Guard + Oracle cloud, Nassyam Basha nos explica ahora cómo realizar el failover  de una base de datos “standby” para convertirla en primaria  y posteriormente instanciar la primaria original en una standby física, todo esto utilizando la versátil herramienta de línea de comandos "dbaascli" en Oracle Cloud. Con la adopción de Oracle Cloud y la utilización del “Cloud Tooling”, el trabajo del DBA se torna por momentos bastante más fácil ya que no necesita una verificación minucioso de cada proceso, un mínimo control resulta suficiente. En el artículo que les comparto,  podemos ver el procedimiento paso a paso para realizar la tarea que antes les mencionaba

Poedemos leer el artículo completo de Nassyam Basha en el siguiente link:

Failover & Reinstating using "dbaascli" on Oracle Cloud 

 

Transición de roles Data Guard en Oracle Cloud usando “dbaascli”

En el post anterior (Desplegando Data Guard en Oracle Cloud), vimos como Nassyam Basha nos muestra en su artículo "Deploying Data Guard on Oracle Cloud" la manera de realizar el deployment de Data Guard en Oracle Cloud. Ahora en este otro artículo, podemos ver cómo realizar el switchover utilizando la herramienta dbaascli de Oracle Cloud. El Switchover es la transición planificada de roles, para cambiar de primaria a standby y viceversa. Existen varios métodos diferentes para realizar esta tarea, una es hacerlo de la manera tradicional utilizando comandos SQL, otra con Data Guard Broker, herramienta incorporada a la gestión más tarde, y otra opción es utilizar consolas gráficas como EM/EMGC. En este artículo, Nassyam, nos muestra una nueva forma de administrar Data Guard utilizando la herramienta propia de Oracle Cloud "dbaascli" y cómo realizar el switchover de un  Data Guard en la nube de Oracle.

Poedemos leer el artículo completo de Nassyam Basha en el siguiente link:

Data Guard Role Transitions on Oracle Cloud using “dbaascli”

Desplegando Data Guard en Oracle Cloud

Como DBAs desde hace muchos años estamos muy familiarizados a trabajar primero con bases standby y luego con Data Guard con el ambientes locales, lo que hoy llamamos "on-premises" cosa que hoy genera gastos importantes de infraestructura cuando la idea es alojar un sitio de DR en una ubicación geográficamente diferente. Esta lógica puede resolverse mediante la implementación de Data Guard en la nube, con un modelo de implementación simple utilizando la infraestructura administrada por Oracle. Este modelo se puede establecer sin inconsistencia de datos o corrupciones, protección de datos y otros beneficios. En el siguiente artículo escrito por el Oracle ACED Nassyam Basha, podemos ver cómo implementar Data Guard en Cloud.

Poedemos leer el artículo completo en el siguiente link:

Deploying Data Guard on Oracle Cloud - #DRaaS

                           

Disaster Recovery to the Oracle Cloud Production on Premises, DR in the Cloud (White Paper)

Oracle White Paper
Disaster Recovery to the Oracle Cloud Production on Premises, DR in the Cloud

Introduction
Oracle’s Maximum Availability Architecture (Oracle MAA) is the best practices blueprint for data protection and availability for Oracle databases deployed on private, public or hybrid clouds. Data Guard and Active Data Guard provide disaster recovery (DR) for databases with recovery time objectives (RTOs) that cannot be met by restoring from backup. Customers use these solutions to deploy one or more synchronized replicas (standby databases) of a production database (the primary database) in physically separate locations to provide high availability, comprehensive data protection, and disaster recovery for mission critical data.

An effective disaster recovery plan can be costly due to the need to establish, equip and manage a remote data center. The Oracle Cloud offers a great alternative for hosting standby databases for customers who do not have a DR site or who prefer not to deal with the cost or complexity of managing a remote data center. Existing production databases remain on-premises and standby databases used for DR are deployed on the Oracle Cloud. 
This mode of deployment is commonly referred to as a hybrid cloud implementation.
Customers may choose to deploy either a Data Guard or an Active Data Guard standby on the cloud depending upon their requirements. While there are some unique considerations to a hybrid cloud DR configuration, it follows the same Oracle MAA best practices as with any Data Guard deployment. This Oracle MAA blueprint details Oracle MAA Best Practices and provides a procedural overview for deploying DR on the Oracle Cloud using Database as a Service. This paper is intended for a technical audience having knowledge of Oracle Database, Data Guard or Active Data Guard, and Oracle Database backup and recovery. This paper also assumes a basic understanding of services offered on the Oracle Cloud.

http://www.oracle.com/technetwork/database/availability/dr-to-oracle-cloud-2615770.pdf

Redo Apply Best Practices- Oracle Data Guard and Active Data Guard (White Paper)

Oracle White Paper

Redo Apply Best Practices

Oracle Data Guard and Active Data Guard

Introduction

Oracle media recovery is a fundamental element of Oracle Maximum Availability Architecture (Oracle MAA) environments. Media recovery occurs when one or more datafiles or the controlfiles are restored from a previous backup or when using Data Guard Redo Apply (physical standby database). The goal of media recovery is to recover a database to a consistent point in time or to apply all primary database transactions to a physical standby database.

In most cases, the default Oracle settings result in satisfactory performance for media recovery. As applications and databases increase in size and throughput, however, media recovery operations can benefit from additional tuning to further optimize recovery time or Redo Apply throughput on a standby database. The goal of this paper is to provide best practices for monitoring media recovery performance and, if necessary, for tuning media recovery for optimal performance.

This technical paper is intended for Oracle Database Administrators familiar experienced with Oracle Database recovery and having a working knowledge of Data Guard and Active Data Guard.

http://www.oracle.com/technetwork/database/availability/redo-apply-2745943.pdf

Data Guard Fast-Start Failover - Automatic Database Failover for High Availability in an MAA Configuration

En esta demo podemos ver el switchover automático entre una base de datos primaria Oracle RAC y una base de datos standby también en RAC con una configuración MAA. Después del failover, la primaria se restablece automáticamente como standby y se vuelve a sincronizar automáticamente con la nueva primaria. La alta disponibilidad y la "maximum data protection" se alcanzan durante un fallo del sitio sin la necesidad de ningún tipo de intervención manual. Haga click en el enlace para descargar la demo y ejecutarla en su máquina, puede usar el control en la parte inferior de la pantalla para iniciar la demostración. Haga click aquí para ver la presentación adicional que incluye las experiencias en producción de Amazon.com con Data Backup Fast Start Failover.

Descargar la demo

Extended Datatype Support for SQL Apply

El Extended Datatype Support (EDS)  permite que SQL Apply y Streams puedan replicar los cambios en las tablas que contienen tipos de datos no soportados nativamente de una base de datos a otra. Sin EDS, sólo se pueden replicar las tablas que contienen tipos de datos soportados nativamente. Haga click aquí para obtener más información accediendo al paper de best practices de MAA que se adjunta.

Ver la demo

Global Temporary Tables and Sequences - Active Data Guard

A partir de la versión 12.1 de la Base de Datos de Oracle 12c, la nueva funcionalidad "temporary undo" permite que el undo para cambios en una Global Temporary Table (GTT) se almacene en el tablespace temporal en lugar que en el tablespace de undo. Lo info de "undo" almacenada en el tablespace temporal no genera "redo", permitiendo así cambios bajos en generación de "redo" en global temporary tables. Esto permite operaciones DML en tablas globales temporales en Active Data Guard standbys. Además, se puede acceder a las secuencias creadas en la base de datos primaria desde las bases de datos de standby de Active Data Guard, tanto globales a toda la configuración de Data Guard, como locales sólo a la sesión actual. En esta demo podemos ver cómo habilitar y usar GTTs y Secuencias globales y de sesión en una base de datos standby de Active Data Guard.

Ver demo
Descargar demo

Far Sync Zero Data Loss at any Distance - Active Data Guard

El impacto que la protección sincrónica de zero data loss protection tiene en el rendimiento de la base de datos puede conducir a compromisos indeseables. Los clientes con gran distancia entre sitios deben comprometer la protección y utilizar el transporte asíncrono, aceptando la posible pérdida de datos a cambio de una performance aceptable. Active Data Guard Far Sync, una nueva capacidad de Oracle Database 12c, elimina el compromiso al extender a cualquier base de datos de standby ubicada a cualquier distancia de una primaria, a un costo mínimo y sin complejidad adicional. En esta demo podemos ver cómo se configura Active Data Guard 12c Far Sync y como se realizan "failovers zero data loss".

Ver demo
Descargar demo

Data Guard Broker Demo

En esta demo de la serie High Availability Demonstrations podemos ver las capacidades de Oracle Database 11.2.0.3 para crear fácilmente una configuración de Data Guard Broker, usar el Broker para validar que Data Guard está funcionando correctamente y realizar tareas básicas de administración con la interfaz de línea de comandos Data Guard Broker DGMGRL. Las tareas de gestión que se muestran, incluyen el switchover y reinicio automático de los servicios de base de datos en la nueva base de datos primaria, failovery reinicio automático de los servicios de base de datos y la publicación de eventos FAN (Fast Application Notification) para informar a los clientes OCI y JDBC de que se ha producido un failover y facilmente reinstanciar la base primaria original como una standby sincronizada de la nueva base primaria. Luego de descargar e iniciar la demostración, haga click en la barra de menú en la parte inferior de la página para avanzar manualmente a través de cada una de las operaciones. Aquí la documentación de Data Guard Broker.

Descargar la demo

Data Guard Protection from Lost-Write Corruption

En esta demo de la serie High Availability Demonstrations podemos ver cómo Data Guard proporciona una protección única contra la corrupción de datos causada por escrituras perdidas ("Lost Writes"). Una escritura perdida de bloque de datos ocurre cuando un subsistema de E/S entiende que la escritura del bloque ya ha finalizado, mientras que de hecho esto no ha ocurrido realmente en el storage. Cuando se detecta una corrupción del tipo "Lost Write" en una base de datos física Standby de Data Guard, el proceso Redo Apply (MRP) se detendrá y la standby mostrará un error ORA-752 para indicar explícitamente que se ha producido un error de "Lost Write" en la primaria. (Esto lo hace para prevenir que el problema se propague a la standby). Para obtener más información sobre "Lost Write Protection" y comocer sobre otras formas de como Oracle Data Guard puede prevenir, detectar o reparar automáticamente corrupción de datos, consulte la nota de MOS 1302539.1

Descargar la demo

Oracle High Availability Demonstrations

Comparto aqui un link a High Availability Demonstrations en el sitio de Oracle
Realmente muy interesante, son demostraciones de casos de HA divididos por categorias:

• Data Guard
• Active Data Guard
• Recovery Manager (RMAN)
• Flashback Technology
• Data Guard and Applications
• Oracle Secure Backup (OSB)
• Global Data Services (GDS)
• Oracle GoldenGate
• Oracle Sharding
• Cloud MAA

En futuros posts les iré comentando un poco más sobre cada caso.

Consultando el sttandby database SCN - x$kcvfh

En este post , Emre Baransel comparte un caso interesante:

The case was to roll forward a physical standby with an RMAN SCN incremental backup taken from primary. The standby database was just restored and necessary archived logs was missing somehow (That's another story). It was something i already did in the past so we set to work with my previous notes. Took the backup, copied files to standby server and recovered standby database. But the problem was, RECOVER DATABASE NOREDO statement was doing nothing so media recovery was asking for the same archived logs. 

Cross-checked the steps with Data Guard Concepts and Administration Guide there was nothing we were missing.

http://docs.oracle.com/cd/E11882_01/server.112/e41134/rman.htm#SBYDB00759

And then after the warning of my team-mate, checked the note on MyOracle Support "Steps to perform for Rolling forward a standby database using RMAN Incremental Backup. (Doc ID 836986.1)" and voila! My note and Administration Guide said "check the SCN on the standby database using V$DATABASE" and support note was saying:

 "You need to use the 'lowest SCN' from the the 3 queries below"

 SQL> SELECT CURRENT_SCN FROM V$DATABASE;

 SQL> select min(fhscn) from x$kcvfh;

 SQL> select min(f.fhscn) from x$kcvfh f, v$datafile d where f.hxfil =d.file# and d.enabled != 'READ ONLY';

Renombrando un datafile en una base Primaria (Dataguard)

A continuación el procedimiento para renombrar un datafile en una base primaria dataguard:

When you rename one or more datafiles in the primary database, the change is not propagated to the standby database. Therefore, if you want to rename the same datafiles on the standby database, you must manually make the equivalent modifications on the standby database because the modifications are not performed automatically, even if the STANDBY_FILE_MANAGEMENT initialization parameter is set to AUTO.
The following steps describe how to rename a datafile in the primary database and manually propagate the changes to the standby database.

1- To rename the datafile in the primary database, take the tablespace offline:

SQL> ALTER TABLESPACE tbs_4 OFFLINE;

2- Exit from the SQL prompt and issue an operating system command, such as the following UNIX mv command, to rename the datafile on the primary system:

% mv /disk1/oracle/oradata/payroll/tbs_4.dbf
/disk1/oracle/oradata/payroll/tbs_x.dbf

3- Rename the datafile in the primary database and bring the tablespace back online:

SQL> ALTER TABLESPACE tbs_4 RENAME DATAFILE -
> '/disk1/oracle/oradata/payroll/tbs_4.dbf' -
>  TO '/disk1/oracle/oradata/payroll/tbs_x.dbf';

SQL> ALTER TABLESPACE tbs_4 ONLINE;

Oracle Database 11g: "Bad Header" en un "Archive" interrumpiendo recuperación media de un "Standby DB"

Este es el primer artículo en el cual participo y es publicado en el sitio de OTN  (Oracle Technology Network) en español.
Se trata de la narración de un caso práctico real y de la manera en que fué solucionado. El problema se produjo en un ambiente DataGuard productivo, el cual de un momento a otro dejo de aplicar logs. 

En el artículo se detalla cada uno de los pasos que se llevaron adelante para realizar el análisis y las acciones que finalmente se tomaron para darle solución al problema. Más allá de la información relacionada con el caso puntual, creo que sirve de ejemplo de como comenzar a llevar adelante un "thoubleshooting" en configuraciones de DR donde intervienen bases standby. 

Este artículo que fué escrito en conjunto con los  colegas Joel Perez  y Nassyam Basha,  y tal como les comentaba, publicado en el sitio de OTN (Oracle Technology Network) en español en Marzo de 2015.

Switcheando redologs (Opción ALL LOGFILE)

La sentencia SWITCH LOGFILE nos permite explicitamente forzar a que la base de datos comience a escribir en un nuevo grupo de archivos de redo log, por mas que,  el corriente aún no se haya completado. Al forzar un cambio de log (SWITCH LOGFILE) se lanza un proceso de "checkpoint" que nos devuelve inmediatamente el control una vez concluido, este tipo se checkpoint se denomina LOG SWITCH CHECKPOINT. 

Una opción "semi-documentada" que resulta bastante útlil en ambientes de RAC  (particularmente cuando se utiliza "dataguard") es utilizar "ALL LOGFILE" para realizar el cambio de grupo de redo en todos los threads de la base, de una vez y desde una unica instancia: