Inicio > Seguridad > Como abrir una base de datos “standby” física para lectura o lectura/escritura

Como abrir una base de datos “standby” física para lectura o lectura/escritura

En este articulo intentare explicar como podemos sacar provecho “extra” de las BBDD standby físicas. Estas BBDD pueden ser usadas, además de para “Disater Recovery”,  para:

  • Copias de seguridad
  • Reporting
  • Recuperación ante errores humanos en las productivas
  • Banco de pruebas (nuevas aplicaciones, modificaciones en las existentes..)

Todo ello sin “romper” 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.

Primero una pequeña introducción a las BBDD standby físicas (quien quiera puede saltar directamente a “Manos a la obra”):

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 “swtichover” (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 y standby disponen de una serie de procesos y herramientas (Data Guard) que 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 interface grafica (Grid Control y Database Control) y de línea de comandos (dgmgrl).

Manos a la obra:

Apertura en solo lectura

Supongamos que alguien, por error, ha eliminado/modificado algún objeto/s de la BBDD (usuarios, tablas, datos, código…) 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… como nos puede ayudar una standby en todo esto?

Lo primero que necesitamos es tener una standby y que esta no este “al día”, esto es, que la standby aplique los cambios con un cierto retardo. 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 tiempo (minutos, horas) a aplicarlos a los ficheros de datos, entretanto quedan en los ficheros de redo de la BBDD standby.

Si aplicamos los cambios de manera retardada, 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'

Podemos modificar el parámetro desde las herramientas graficas o mediante línea de comandos con la sentencia:

DGMGRL> EDIT DATABASE 'sbtest' SET PROPERTY 'DelayMins'=180;

Por tanto 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).

Partimos de una BBDD standby controlada con Data Guard en MAXPERFORMANCE, para abrirla en modo solo lectura solo tenemos que ejecutar en la línea de comandos (o mediante la opción correspondiente de consola):

[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 en lectura/escritura

Imaginemos otro caso, 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 prerrequisito 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.

Ya disponemos de área de FRA, los 10Gb son el límite de espacio que le imponemos, no implica que el sistema de ficheros (o el storage ASM) en que la tenemos ubicada tenga justo esa capacidad).

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.

Creamos 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

NOTA IMPORTANTE: No se pueden deshacer cambios en los ficheros de datos (resizes, drops), de control o de inicialización. Tampoco se pueden deshacer operaciones en NOLOGGING (los bloques quedan marcados como corruptos) en consecuencia, una vez abramos la BBDD standby deberemos evitar este tipo de operaciones.

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

Comprovamos 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

NOTA: En este caso dejamos de enviar redo, de manera que en caso de desastre en el site productivo durante el tiempo que duren estas pruebas la BBDD standby quedaría a nivel de cambios en el punto en que hemos parado el envío de redo.

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

Ya podemos empezar con las pruebas, tenemos una copia exacta del productivo totalmente funciona.

NOTA IMPORTANTE: Ojo con las interacciones de la BBDD con el exterior (tablas externas, dblinks, etc) que no se ven resguardadas pro el Flashback y pueden afectar a productivos remotos.

Creo una tabla (por hacer algo…)

SQL> create table test (nombre varchar2(10));

Tabla creada.

SQL> insert into test values ('a');

1 fila creada.

SQL> commit;

Confirmación terminada.

Revertimos 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.

La 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.

Finalmente si hemos cambiado el modo de protección lo volvemos a dejar como estaba:

DGMGRL> EDIT CONFIGURATION SET PROTECTION MODE AS MAXAVAILABILITY;
Succeeded.

Y ya disponemos nuevamente de la standby operativa.

NOTA: La versión 11gR2 ha aportado grandes mejoras a estas funcionalidades, como por ejemplo, reparación automática de bloques corruptos enviando las copias buenas desde la standby, realizar selects en la standby al mismo tiempo que se aplica el redo (y asegurando una determinada “frescura” de los datos)… pero de todo eso ya hablaremos en otro post.

  1. Aún no hay comentarios.
  1. enero 3, 2011 en 13:07

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s

A %d blogueros les gusta esto: