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.
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!
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.
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).
- Apertura lectura/escritura
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:
[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,000000000
Paramos 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 options
Comprobamos 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 modificado
Cambiamos 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.
