Está claro que podemos hacer este tipo de maniobras si no tenemos Oracle Golden Gate, ¿Y quien no lo tiene a estas alturas?
Aparte de ser usadas para sofocar un desastre, podemos sacarle otras posibilidades:
Aparte de ser usadas para sofocar un desastre, podemos sacarle otras posibilidades:
- Origen de información de nuestras herramientas de elaboración de informes.
- Laboratorio de pruebas (ante nuevas aplicaciones, modificaciones en las existentes.)
- Recuperación ante errores "humanos" en los entornos de producción.
- Copias de seguridad.
Todo ello sin que perdamos la funcionalidad de la BBDD standby y en la mayoría de casos sin perder la protección que esta nos brinda en ningún momento. Hoy nos centraremos en los dos últimos casos, recuperación ante errores y pruebas.
En caso que la ubicación física en la que tenemos los servidores principales se vea inutilizada por inundaciones, incendios, averías, cortes de comunicaciones o otros tipos de desastres se realiza un “failover” a la ubicación remota, empezando a trabajar en esta en un tiempo mínimo (unos pocos minutos). El problema es que normalmente se tarda mucho más en decidir pasar a la ubicación de respaldo que en la operación misma (si bien se puede automatizar, la mayoría de gente la tiene en modo manual).
También se usan en caso de querer realizar mantenimientos en la ubicación principal, en este caso realizaremos un “switchover” (un fallback controlado), con el que aseguramos no perder ningún dato y que nos permite volver a la ubicación principal fácilmente (mediante otro “switchover”).
El conjunto de BBDD principal / standby disponen de una serie de procesos y herramientas:
Como se puede comprobar la complejidad y el tiempo necesario para realizar la operación son mínimos y las ventajas que nos aporta muchas (en mi opinión).
Ahora tenemos otro caso, para imaginar, una nueva aplicación entrará en producción o queremos modificar una de las existentes con cambios importantes que afectan múltiples esquemas. Las pruebas en test o desarrollo, no son posibles/fiables (por no interferir en los equipos de desarrollo o por ser estos entornos sensiblemente más pequeños que el productivo) en consecuencia nos vemos en la obligación de montar un entorno nuevo para estas pruebas.
Una vez más la BBDD standby nos puede ayudar, en este caso la abriremos en modo lectura/escritura, realizaremos modificaciones y pruebas pertinentes y finalmente descartaremos las modificaciones y la devolveremos a su estado inicial. La BBDD “test” es la principal mientras que la “sbtest” es la standby.
El primer requisito para realizar estas acciones es tener la Flash Recovery Area (FRA) configurada en la BBDD standby, en caso de no disponer de esta, la configuramos:
En caso de estar en modo de protección MAXAVAILABILITY pasamos a MAXPERFORMANCE:
Necesitaremos crear un punto de recuperación:
Paramos el broker en la standby:
Y finalmente abrimos la BBDD
SQL> ALTER DATABASE OPEN; Base de datos modificada. SQL> select status from v$instance; STATUS ------------ OPEN
Al finalizar nuestras pruebas, deshacemos los cambios, cerramos la BBDD, la abrimos en mount y realizamos el Flashback:
Activamos nuevamente el broker de Data Guard en la standby
Introducción
Las BBDD standby son replicas de nuestros productivos bit a bit, copias exactas que se mantienen normalmente en ubicaciones remotas y que inicialmente se destinan a protección ante desastres.En caso que la ubicación física en la que tenemos los servidores principales se vea inutilizada por inundaciones, incendios, averías, cortes de comunicaciones o otros tipos de desastres se realiza un “failover” a la ubicación remota, empezando a trabajar en esta en un tiempo mínimo (unos pocos minutos). El problema es que normalmente se tarda mucho más en decidir pasar a la ubicación de respaldo que en la operación misma (si bien se puede automatizar, la mayoría de gente la tiene en modo manual).
También se usan en caso de querer realizar mantenimientos en la ubicación principal, en este caso realizaremos un “switchover” (un fallback controlado), con el que aseguramos no perder ningún dato y que nos permite volver a la ubicación principal fácilmente (mediante otro “switchover”).
El conjunto de BBDD principal / standby disponen de una serie de procesos y herramientas:
- Data Guard: gestionan el estado de la replicación, la configuración, los cambios de rol (switchover/failover) y facilitan su gestión y control.
- Estos procesos y herramientas disponen de una interfaz gráfica (Database Control y/o Grid Control) y de línea de comandos (DGMGRL).
Hands on!
- Apertura solo lectura
Supongamos que alguien, el cuñado del director de la compañía, ha eliminado/modificado algún objeto/s de la BBDD (código PLSQL, datos, tablas, una vista, ...) y nos planteamos restaurar una copia de seguridad de la BBDD para recuperar estos objetos, esto pueden ser horas de trabajo, de cintas ocupadas, de disponibilidad de servidores… y sobre todo saber que el zarpas nos ha arruinado la tarde y hay Champions, ¿Como nos puede ayudar una "standby"? ¿Veremos el partido o mataremos al "zarpas"?
Necesitaremos es tener una standby y que esta no este “al día”, esto es, que la standby aplique los cambios con un cierto retraso (no tanto como el del cuñado del director, claro). Esto implica que los cambios en la principal se envían inmediatamente a la standby, pero esta no los aplica en el momento de su llegada, espera un margen de tiempo a aplicarlos, estos ficheros quedan en el esacio de redo de la BBDD standby.
Si aplicamos los cambios de esta manera, la standby nos sigue dando seguridad (los cambios se han enviado al site remoto) y nos brinda la posibilidad de abrirla y ver una imagen de la principal de “hace un cierto tiempo”.
El parámetro de la configuración de Data Guard a modificar para conseguir un retardo en la aplicación del redo es el “DelayMins”, en este caso lo tenemos a 180 minutos:
DGMGRL> show database verbose sbtest;
Database
Name: sbtest
Role: PHYSICAL STANDBY
Enabled: YES
Intended State: ONLINE
Instance(s):
sbrsocial
Properties:
InitialConnectIdentifier = 'sbtest'
ObserverConnectIdentifier = ''
LogXptMode = 'SYNC'
Dependency = ''
DelayMins = '180'
Binding = 'OPTIONAL'
MaxFailure = '0'
MaxConnections = '1'
ReopenSecs = '300'
NetTimeout = '180'
LogShipping = 'ON'
PreferredApplyInstance = ''
ApplyInstanceTimeout = '0'
ApplyParallel = 'AUTO'
StandbyFileManagement = 'AUTO'
Modificamos el parámetro desde las herramientas graficas o mediante línea de comandos con la sentencia:
DGMGRL> EDIT DATABASE 'sbtest' SET PROPERTY 'DelayMins'=180;
Si las modificaciones erróneas no han llegado a aplicarse a los ficheros de la standby, solo tenemos que abrirla y recuperar la información perdida (mediante un DBLink desde la principal por ejemplo).
Al tener una base de datos standby controlada con Data Guard en MAXPERFORMANCE, para abrirla en modo solo lectura solo tenemos que ejecutar en la línea de comandos:
[SRVTEST_BD1_ORACLE: oracle@srvtest dbs]$ dgmgrl DGMGRL for Linux: Version 10.2.0.4.0 - 64bit Production Copyright (c) 2000, 2005, Oracle. All rights reserved. Welcome to DGMGRL, type "help" for information. DGMGRL> connect / Connected. DGMGRL> EDIT DATABASE sbtest SET STATE='READ-ONLY'; Succeeded.
Con esto ya tenemos la BBDD standby abierta, podemos realizar consultas en ella y lo más importante, no se deja de enviar redo de la principal a la standby con lo que mantenemos la protección.
Una vez recuperados los datos necesarios volvemos al estado anterior (BBDD montada y aplicando cambios con el retardo programado)
[SRVtest_BD1_ORACLE: oracle@srvtest dbs]$ dgmgrl DGMGRL for Linux: Version 10.2.0.4.0 - 64bit Production Copyright (c) 2000, 2005, Oracle. All rights reserved. Welcome to DGMGRL, type "help" for information. DGMGRL> connect / Connected. DGMGRL> edit database sbtest set state='ONLINE'; Succeeded.
- Apertura lectura/escritura
Una vez más la BBDD standby nos puede ayudar, en este caso la abriremos en modo lectura/escritura, realizaremos modificaciones y pruebas pertinentes y finalmente descartaremos las modificaciones y la devolveremos a su estado inicial. La BBDD “test” es la principal mientras que la “sbtest” es la standby.
El primer requisito para realizar estas acciones es tener la Flash Recovery Area (FRA) configurada en la BBDD standby, en caso de no disponer de esta, la configuramos:
[oracle@srvtest source]$ mkdir /soft/oracle/oradata/sbtest/flash_recovery_area SQL> show parameter recovery NAME TYPE VALUE ------------------------------------ ----------- ------------------------------ db_recovery_file_dest string db_recovery_file_dest_size big integer 0 recovery_parallelism integer 0 SQL> alter system set db_recovery_file_dest_size=10G scope=both; Sistema modificado. SQL> alter system set db_recovery_file_dest='/soft/oracle/oradata/sbtest/flash_recovery_area' scope=both; Sistema modificado.
En caso de estar en modo de protección MAXAVAILABILITY pasamos a MAXPERFORMANCE:
[SRVTEST_BD1_ORACLE: oracle@srvtest dbs]$ dgmgrl DGMGRL for Linux: Version 10.2.0.4.0 - 64bit Production Copyright (c) 2000, 2005, Oracle. All rights reserved. Welcome to DGMGRL, type "help" for information. DGMGRL> connect / Connected. DGMGRL> EDIT CONFIGURATION SET PROTECTION MODE AS MAXPERFORMANCE; Succeeded.Paramos el aplicado del redo en la standby:
DGMGRL> edit database sbtest set state='APPLY-OFF';. Succeeded.
Necesitaremos crear un punto de recuperación:
- A partir de este momento la BBDD standby guardará todos los cambios en un fichero creado a tal propósito en la FRA (el Flashback log), usará este “log de cambios” para deshacerlos una vez terminadas las pruebas.
SQL> CREATE RESTORE POINT Standby_flashback_testing GUARANTEE FLASHBACK DATABASE; Punto de restauración creado. SQL> select NAME,SCN,TIME from v$restore_point; NAME -------------------------------------------------------------------------------- SCN ---------- TIME --------------------------------------------------------------------------- STANDBY_FLASHBACK_TESTING 8151200819 11/03/10 12:37:53,000000000Paramos el envío de archivado a la BBDD standby. Forzamos el envió del último log online y paramos el transporte. Es importante comprobar que este archivado que hemos enviado ha quedado archivado en la standby.
[SRVTEST_BD1_ORACLE: oracle@srvtest dbs]$ sqlplus /nolog SQL*Plus: Release 10.2.0.4.0 - Production on Thu Mar 11 12:32:47 2010 Copyright (c) 1982, 2007, Oracle. All Rights Reserved. SQL> connect / as sysdba Connected. SQL> alter system archive log current; System altered. SQL> exit Disconnected from Oracle Database 10g Enterprise Edition Release 10.2.0.4.0 - 64bit Production With the Partitioning, Real Application Clusters, OLAP, Data Mining and Real Application Testing optionsComprobamos que el redo log se ha archivado en la BBDD standby:
-rw-r----- 1 oracle oinstall 2548224 Mar 15 11:45 arch1_69_709240912.dbf -rw-r----- 1 oracle oinstall 28160 Mar 15 11:47 arch1_70_709240912.dbf [oracle@sbtest dbs]$Paramos el transporte de redo:
[SRVTEST_BD1_ORACLE: oracle@srvtest dbs]$ dgmgrl / DGMGRL for Linux: Version 10.2.0.4.0 - 64bit Production Copyright (c) 2000, 2005, Oracle. All rights reserved. Welcome to DGMGRL, type "help" for information. Connected. DGMGRL> EDIT DATABASE test SET STATE=Log-Transport-Off; Succeeded. DGMGRL> exit
Paramos el broker en la standby:
SQL> show parameter dg NAME TYPE VALUE ------------------------------------ ----------- ------------------------------ dg_broker_config_file1 string /soft/oracle/dbtest/dbs/d r1sbtest.dat dg_broker_config_file2 string /soft/oracle/dbtest/dbs/d r2sbtest.dat dg_broker_start boolean TRUE SQL> alter system set dg_broker_start=false; Sistema modificadoCambiamos el modo del fichero de control de STANDBY a CURRENT
[oracle@srvtest flashback]$ sqlplus /nolog SQL*Plus: Release 10.2.0.4.0 - Production on Jue Mar 11 12:40:16 2010 Copyright (c) 1982, 2007, Oracle. All Rights Reserved. SQL> connect / as sysdba Conectado. SQL> select CONTROLFILE_TYPE from v$database; CONTROL ------- STANDBY SQL> ALTER DATABASE ACTIVATE STANDBY DATABASE; Base de datos modificada. SQL> select CONTROLFILE_TYPE from v$database; CONTROL ------- CURRENT
Y finalmente abrimos la BBDD
SQL> ALTER DATABASE OPEN; Base de datos modificada. SQL> select status from v$instance; STATUS ------------ OPEN
Al finalizar nuestras pruebas, deshacemos los cambios, cerramos la BBDD, la abrimos en mount y realizamos el Flashback:
SQL> shutdown immediate Base de datos cerrada. Base de datos desmontada. Instancia ORACLE cerrada. SQL> startup mount Instancia ORACLE iniciada. Total System Global Area 1610612736 bytes Fixed Size 2084296 bytes Variable Size 419430968 bytes Database Buffers 1174405120 bytes Redo Buffers 14692352 bytes Base de datos montada. SQL> FLASHBACK DATABASE TO RESTORE POINT Standby_flashback_testing ; Flashback terminado.Reconvertimos a STANDBY:
SQL> select controlfile_type from v$database; CONTROL ------- BACKUP SQL> ALTER DATABASE CONVERT TO PHYSICAL STANDBY; Base de datos modificada.
Activamos nuevamente el broker de Data Guard en la standby
SQL> alter system set dg_broker_start=true; Sistema modificado. SQL> shutdown immediate; ORA-01507: base de datos sin montar Instancia ORACLE cerrada. SQL> startup mount Instancia ORACLE iniciada. Total System Global Area 1610612736 bytes Fixed Size 2084296 bytes Variable Size 419430968 bytes Database Buffers 1174405120 bytes Redo Buffers 14692352 bytes Base de datos montada.Reactivamos el trasporte y aplicado de redo
[SRVTEST_BD1_ORACLE: oracle@srvtest dbs]$ dgmgrl / DGMGRL for Linux: Version 10.2.0.4.0 - 64bit Production Copyright (c) 2000, 2005, Oracle. All rights reserved. Welcome to DGMGRL, type "help" for information. Connected. DGMGRL> EDIT DATABASE sbtest SET STATE=online; Succeeded. DGMGRL> EDIT DATABASE test SET STATE=online; Succeeded.Y para acabar, si hemos cambiado el modo de protección lo volvemos a dejar como estaba:
DGMGRL> EDIT CONFIGURATION SET PROTECTION MODE AS MAXAVAILABILITY; Succeeded.
