viernes, 14 de junio de 2013

Oracle Data Guard 11g Enterprise edition



Desarrollo

La práctica consta de dos bases de datos: una primaria y una secundaria que servirá de respaldo en caso de fallar la primaria, en ese ese caso la base de datos secundaria lleva un backup de todos los datos y se pueden acceder a ellos pero en modo protegido o de lectura.
Requisitos:
·         2 computadoras con características similares (una se utilizara como primaria y la otra como bases de datos secundaria).
·         Un cable UTP cruzado.
·         Sistema operativo OpenSUSE en su versión 12.3 (32 bits).
·         Oracle Enterprise 11g R2 (32 bits), es necesario utilizar la versión Enterprise ya que en las demás versiones no cuenta con las herramientas necesarias para configurar un Data guard.
·         La máquina primaria debe tener instalada una base de datos y la maquina secundaria únicamente el software de Oracle (sin base de datos).


Lo primero que debe hacerse es que cada computadora tenga una dirección IP del mismo rango para tener conectividad entre las dos computadoras, en este caso se utilizan las siguientes:
Maquina primaria: 192.168.15.100/24
Línea de comando: ifconfig eth0 192.168.15.100/24 up
Maquina secundaria: 192.168.15.101/24
            Línea de comando: ifconfig eth0 192.168.15.101/24 up
Los nombres de host quedan de la siguiente manera:
Base de Datos Primaria: dga1
Base de Datos Stanby: dga2
Una vez comprobada la conectividad se procede a configurar las bases de datos.





BASE DE DATOS PRIMARIA
Configuración del Listener
En esta explicación estamos utilizando el puerto 7438 y el archivo listener.ora queda de la siguiente manera:



Verificar que la base de datos esta en modo archivelog:
SQL>SELECT log_mode FROM v$database;
LOG_MODE
------------
NOARCHIVELOG
SQL>
Si en dado caso no se encuentra en dicho modo, se establece de la siguiente manera:
SQL>SHUTDOWN IMMEDIATE;
SQL>STARTUP MOUNT;
SQL>ALTER DATABASE ARCHIVELOG;
SQL>ALTER DATABASE OPEN
 
Activamos FORCE LOGGING con el siguiente comando:
SQL>ALTER DATABASE FORCE LOGGING;

Inicialización de parámetros:
Verificar que los parámetros DB_NAME y DB_UNIQUE_NAME sean iguales, en este caso DB11G en la base de datos primaria.
DB_NAME especifica un identificador de base de datos de hasta 8 caracteres. Este parámetro debe ser especificado y debe corresponder con el nombre especificado en la sentencia CREATE DATABASE.

DB_UNIQUE_NAME especifica un nombre único global para la base de datos. De cada base de datos DB_UNIQUE_NAME debe ser único dentro de la empresa. El valor de DB_UNIQUE_NAME puede ser de hasta 30 caracteres y distingue entre mayúsculas y minúsculas. Los siguientes caracteres son válidos en un nombre de base de datos: caracteres alfanuméricos, guion bajo (_), signo de número (#) y el signo de dólar ($).


El DB_NAME de la base de datos secundaria deberá ser el mismo (DB11G) de la primaria, pero deben tener diferente valor de DB_UNIQUE_NAME. Los valores DB_UNIQUE_NAME de ambas bases serán utilizadas en el DG_CONFIG configurando el parámetro LOG_ARCHIVE_CONFIG. Para esta configuración la base secundaria será configurada con el valor “DB11G_STBY”.
SQL>ALTER SYSTEM SET LOG_ARCHIVE_CONFIG='DG_CONFIG=(DB11G,DB11G_STBY)';
LOG_ARCHIVE_CONFIG: este parámetro habilita o deshabilita el envío de redo logs a destinos remotos y el recipiente de estos. Este parámetro tiene varios atributos pero el que utilizaremos será el siguiente:
DG_CONFIG especifica hasta 30 nombres de bases de datos únicas (Definidas con el parámetro 
DB_UNIQUE_NAME) 
para todas las bases de datos en tu configuración de Data Guard.
Se establece los destinos de los archivos remotos. En este caso se utiliza flash recovery área para la ubicación local.


SQL>ALTER SYSTEM SET LOG_ARCHIVE_DEST_2='SERVICE=db11g_stby NOAFFIRM ASYNC VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=DB11G_STBY';
SQL>ALTER SYSTEM SET LOG_ARCHIVE_DEST_STATE_2=ENABLE;

LOG_ARCHIVE_DEST_n controla diferente aspectos de como los servicios de transporte de los Redo
 transfiere los datos de redo de la base de datos primaria a su destino de standby. 
Este parámetro tiene varios atributos que son necesarios para configurar tu ambiente de Dataguard:

1-  ASYNC (Default): Los datos generados de redo por transacción no tienen que haber sido recibidos en cada 
uno de los destinos habilitados antes de cometerse ésta.
2-  SYNC: Los datos generados de redo por transacción tienen que haber sido recibidos en cada uno de los 
destinos habilitados antes de cometerse ésta.
3-  AFFIRM y NOAFFIRM: Controla si un destino de transporte de redo acusa de recibo los datos de redo 
antes o después de escribir estos al standby redo log.
4-  DB_UNIQUE_NAME:  Especifica un nombre único para la base de datos que va a recibir los datos de 
redo. Tienes que especificar este nombre, no hay un valor por default.
-  VALID_FOR .- Identifica cuando el servicio de transporte de redo puede transmitir datos de redo a los 
destinos, esto se basa en los siguiente factores:
 
.-    redo_log_type: Si los archivos de Online Redo Log, Standby Redo log o ambos este siendo archivados
 en la base de datos destinada.
            .- database_role: Si el rol de la base de datos es la Primaria o la base de datos en Stanby. 


Los parámetros LOG_ARCHIVE_FORMAT y LOG_ARCHIVE_MAX_PROCESSES deben configurarse con los valores apropiados, así como el REMOTE_LOGIN_PASSWORDFILE debe establecerse en modo exclusive.


SQL>ALTER SYSTEM SET LOG_ARCHIVE_FORMAT='%t_%s_%r.arc' SCOPE=SPFILE;
SQL>ALTER SYSTEM SET LOG_ARCHIVE_MAX_PROCESSES=30;
SQL>ALTER SYSTEM SET REMOTE_LOGIN_PASSWORDFILE=EXCLUSIVE          SCOPE=SPFILE;

Adicionalmente a la configuración previa es recomendable estar seguro de que la base de datos primaria esta lista para cambiar de rol y convertirse en una secundaria.
SQL>ALTER SYSTEM SET FAL_SERVER=DB11G_STBY;
SQL>ALTER SYSTEM SET DB_FILE_NAME_CONVERT='DB11G_STBY','DB11G' SCOPE=SPFILE;
SQL>ALTER SYSTEM SET LOG_FILE_NAME_CONVERT='/u01/app/oracle/flash_recovery _area/DB11G_STBY','/u01/app/oracle/flash_recovery _area/DB11G'  SCOPE=SPFILE;
SQL>ALTER SYSTEM SET STANDBY_FILE_MANAGEMENT=AUTO;

Recordar que se debe reiniciar para que algunos parámetros tengan efecto.

Configuración del servicio
Las siguientes configuraciones son necesarias tanto en la base primaria y secundaria en el siguiente archivo: "$ORACLE_HOME/network/admin/tnsnames.ora", esto se puede configurar con la ayuda de la herramienta Network Configuration (netca) o manualmente. A continuación se muestran las entradas para este ejercicio:


Respaldo de la base de datos primaria
Para un backup de la base de datos basado en duplicado, o en restaurado manual debe hacerse lo siguiente:
$ rman target=/
 
RMAN> BACKUP DATABASE PLUS ARCHIVELOG;
 
Crear un Controlfile y PFILE para la base de datos secundaria:
Crear control file para la base de datos secundaria usando el siguiente comando:
SQL>ALTER DATABASE CREATE STANDBY CONTROLFILE AS '/tmp/db11g_stby.ctl';
Crear el archivo de parámetros (PFILE) para la secundaria:
SQL>CREATE PFILE='/tmp/initDB11G_stby.ora' FROM SPFILE;
Una vez creado el archivo de parámetros, se procede a configurar las siguientes entradas:
*.db_unique_name='DB11G_STBY'
*.fal_server='DB11G'
*.log_archive_dest_2='SERVICE=db11g ASYNC VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE)
 DB_UNIQUE_NAME=DB11G'
 
FAL_SERVER especifica el servidor FAL (Fetch Archive Log) para un base de datos en Standby. Este valor es un
 nombre de servicio de Oracle Net.
Se deben crear los standby redo logs de la siguiente manera:

SQL>ALTER DATABASE ADD STANDBY LOGFILE ('/u01/app/oracle/oradata/DB11G/standby_redo01.log') SIZE 52428800;
SQL>ALTER DATABASE ADD STANDBY LOGFILE ('/u01/app/oracle/oradata/DB11G/standby_redo02.log') SIZE 52428800;
SQL>ALTER DATABASE ADD STANDBY LOGFILE ('/u01/app/oracle/oradata/DB11G/standby_redo03.log') SIZE 52428800;
SQL>ALTER DATABASE ADD STANDBY LOGFILE ('/u01/app/oracle/oradata/DB11G/standby_redo04.log') SIZE 52428800;




CONFIGURACIÓN MANUAL DE LA BASE SECUNDARIA
Verificar la configuración de listener.ora y tnsnames.ora, deberán contener la siguiente configuración:
Listener.ora



Tnsnames.ora

 


Crear los siguientes directorios que son necesarios:
$ mkdir -p /u01/app/oracle/oradata/DB11G
$ mkdir -p /u01/app/oracle/flash_recovery_area/DB11G
$ mkdir -p /u01/app/oracle/admin/DB11G/adump

Se copian los siguientes archivos de configuración  de la base de datos primaria hacia la secundaria.
#Control File
$ scp oracle@dga1:/tmp/db11g_stby.ctl /u01/app/oracle/oradata/DB11G/control01.ctl
$ cp /u01/app/oracle/oradata/DB11G/control01.ctl /u01/app/oracle/flash_recovery_area/DB11G/control02.ctl
 
#Archivo de parametros
$ scp oracle@dga1:/tmp/initDB11G_stby.ora /tmp/initDB11G_stby.ora
#Archivo de contraseña.
$ scp oracle@dga1: /u01/app/oracle/product/11.2.0/db_1/dbs/orapwDB11G /u01/app/oracle/product/11.2.0/db_1/dbs
Es recomendable desactivar el firewall o añadir una regla de permitir escuchar por el puerto 22, ya que SCP usa ese puerto para el copiado seguro (Secure CoPy).
Iniciar listener
Asegurarse de que el listener de la base de datos secundaria es iniciado.
$ lsnrctl start
Restaurar copia de seguridad
Crear el SPFILE a partir del PFILE
$ export ORACLE_SID=DB11G
$ sqlplus / as sysdba
 
SQL> CREATE SPFILE FROM PFILE='/tmp/initDB11G_stby.ora';

Restaurar los archivos de copia de seguridad.
$ export ORACLE_SID=DB11G
$ rman target=/
 
RMAN> STARTUP MOUNT;
RMAN> RESTORE DATABASE;

Verificar que el db_name  y db_unique_name esten de la siguiente manera:



Crear los Redo Logs


Crear los online redo logs para la base secundaria

SQL>ALTER SYSTEM SET STANDBY_FILE_MANAGEMENT=MANUAL;
SQL>ALTER DATABASE ADD LOGFILE ('/u01/app/oracle/oradata/DB11G/online_redo01.log') SIZE 52428800;
SQL>ALTER DATABASE ADD LOGFILE ('/u01/app/oracle/oradata/DB11G/online_redo02.log') SIZE 52428800;
SQL>ALTER DATABASE ADD LOGFILE ('/u01/app/oracle/oradata/DB11G/online_redo03.log') SIZE 52428800;
SQL>ALTER SYSTEM SET STANDBY_FILE_MANAGEMENT=AUTO;
Después de crear los online redo logs, se deben crear los standby redo logs

SQL>ALTER DATABASE ADD STANDBY LOGFILE ('/u01/app/oracle/oradata/DB11G/standby_redo01.log') SIZE 52428800;
SQL>ALTER DATABASE ADD STANDBY LOGFILE ('/u01/app/oracle/oradata/DB11G/standby_redo02.log') SIZE 52428800;
SQL>ALTER DATABASE ADD STANDBY LOGFILE ('/u01/app/oracle/oradata/DB11G/standby_redo03.log') SIZE 52428800;
SQL>ALTER DATABASE ADD STANDBY LOGFILE ('/u01/app/oracle/oradata/DB11G/standby_redo04.log') SIZE 52428800;
Una vez completado esto, podemos empezar el proceso de aplicación.

Inicie el proceso de aplicación en el servidor secundario

SQL>ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT FROM SESSION;

Si se necesita cancelar el proceso de aplicación, se debe ejecutar el siguiente comando:

SQL>ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;

Si se prefiere, se puede establecer un retardo entre la llegada de los redo log archivados y el aplicado en el servidor de reserva con los siguientes comandos.

SQL>ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;
SQL>ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DELAY 30 DISCONNECT FROM SESSION;
 
SQL>ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;
SQL>ALTER DATABASE RECOVER MANAGED STANDBY DATABASE NODELAY DISCONNECT FROM SESSION;
 

Prueba de registros de transporte

En el servidor principal, consultar las últimas novedades de redo log archivados y forzar un cambio de registro.

SQL>ALTER SESSION SET nls_date_format='DD-MON-YYYY HH24:MI:SS';
 
SQL>SELECT sequence#, first_time, next_time FROM   v$archived_log ORDER BY sequence#;
 
SQL>ALTER SYSTEM SWITCH LOGFILE;
 
Compruebe el nuevo redo log archivados ha llegado al servidor en espera y se han aplicado.

SQL>ALTER SESSION SET nls_date_format='DD-MON-YYYY HH24:MI:SS';
 
SQL>SELECT sequence#, first_time, next_time, applied FROM   v$archived_log ORDER BY sequence#;




Modo de protección

Cada vez que configuramos un Data Guard (StandBy mas envío de archives automáticos) siempre vamos a quedar enmarcados en unos de estos tipos de disponibilidad de la StandBy :


MAXIMA PROTECCION (MAXIMUM PROTECTION)
MAXIMA DISPONIBILIDAD (MAXIMUM AVAILABILITY)
MAXIMA PERFORMANCE (MAXIMUM PERFORMANCE)

Con los 3 modos siempre estamos protegiendo los datos, pero la gran diferencia está en cómo actúa la base de datos primaria cuando la StandBy tiene problemas.

MAXIMA PROTECCION (MAXIMUM PROTECTION)

Este modo garantiza que no hay perdida de datos si la base de datos primaria falla

Con este nivel de protección cada redo data -vector de redo generado en la primaria- debe ser aplicado por lo menos en una StandBy , en los on line redo logs y además en los redo de stanby de esa Standby sólo allí se produce el commit.
Si por ABC motivo el redo data no es escrito en una StandBy , la base de datos primaria se viene abajo (shutdown), si existen 2 StandBy en máxima protección , basta que los redo data sean escritos en 1 de ellas, para que la base de datos productiva siga arriba.


MAXIMA DISPONIBILIDAD (MAXIMUM AVAILABILITY)

 Este modo de protección no afecta la base de datos y proporciona un alto nivel de protección de los datos, tal cual en el modo de máxima protección, las transacciones no se comitean hasta que el redo data sea aplicado en los redologs de la base de datos standby , por lo menos en una de ellas (si existe más de una)
Si no se puede escribir el redo data, en por lo menos una StandBy , la base de datos primaria no se cae.

MAXIMA PERFORMANCE (MAXIMUM PERFORMANCE)

Este modo de protección ofrece la mayor seguridad en la base de datos sin perder nada en la performance de la base de datos primaria, acá las transacciones de la base de datos primaria se les generá commit sólo cuando la transacción llega a los redo locales.
Este modo se debiese usar cuando la red hacía la StandBy no es lo suficientemente óptima y se producen delays al momento de traspasar paquetes a través de TCP.
De forma predeterminada, con la creación de una base de datos en espera, la base de datos primaria está en modo de rendimiento máximo.

SQL>SELECT protection_mode FROM v$database;
 
PROTECTION_MODE
--------------------
MAXIMUM PERFORMANCE
 
SQL>





El modo se puede cambiar el uso de los siguientes comandos. Tenga en cuenta las alteraciones en los atributos de transporte redo.

·         Disponibilidad máxima.
 
SQL>ALTER SYSTEM SET LOG_ARCHIVE_DEST_2='SERVICE=db11g_stby AFFIRM SYNC VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=DB11G_STBY';
SQL>ALTER DATABASE SET STANDBY DATABASE TO MAXIMIZE AVAILABILITY;
 
·         Máximo rendimiento.
 
SQL>ALTER SYSTEM SET LOG_ARCHIVE_DEST_2='SERVICE=db11g_stby NOAFFIRM ASYNC VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=DB11G_STBY';
SQL>ALTER DATABASE SET STANDBY DATABASE TO MAXIMIZE PERFORMANCE;
 
·         Máxima protección.
 
SQL>ALTER SYSTEM SET LOG_ARCHIVE_DEST_2='SERVICE=db11g_stby AFFIRM SYNC VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=DB11G_STBY';
SQL>SHUTDOWN IMMEDIATE;
SQL>STARTUP MOUNT;
SQL>ALTER DATABASE SET STANDBY DATABASE TO MAXIMIZE PROTECTION;
SQL>ALTER DATABASE OPEN;

Base de datos de conmutación (SWITHOVER) (primaria y secundaria)

Una base de datos puede estar en uno de dos modos mutuamente excluyentes (primaria o en espera). Estas funciones se pueden modificar en tiempo de ejecución sin pérdida de datos o restablecimiento de registros redo. Este proceso se conoce como conmutación (switchover) y puede llevarse a cabo mediante las siguientes declaraciones
 
·         Convertir base de datos primaria a secundaria.
 
SQL>CONNECT / AS SYSDBA
SQL>ALTER DATABASE COMMIT TO SWITCHOVER TO STANDBY;
 
SQL>SHUTDOWN IMMEDIATE;
 
SQL>STARTUP NOMOUNT;
SQL>ALTER DATABASE MOUNT STANDBY DATABASE;
SQL>ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT FROM SESSION;
 
·         Convertir la base de datos standby original a primaria.
 
SQL>CONNECT / AS SYSDBA
SQL>ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY;

SQL>SHUTDOWN IMMEDIATE;

SQL>STARTUP;
 

Failover

Si la base de datos principal no está disponible la base de datos standby se puede activar como base de datos primaria con las siguientes sentencias.

SQL>ALTER DATABASE RECOVER MANAGED STANDBY DATABASE FINISH;
SQL>ALTER DATABASE ACTIVATE STANDBY DATABASE;

Dado que la base de datos standby es ahora la base de datos principal  debe estar respaldada inmediatamente.

La base de datos primaria original, ahora se puede configurar como un modo de espera. Si Flashback base de datos se habilita en la base de datos primaria, a continuación, esto se puede hacer con relativa facilidad (que se muestra aquí). De lo contrario, todo el proceso de instalación se deben seguir, pero esta vez utilizando el servidor principal original como el modo de espera.

Base de datos standby de solo lectura (Read-Only Standby)

Una vez que se ha configurado una base de datos standby, se puede abrir en modo de sólo lectura para permitir el acceso de consulta. Esto se utiliza a menudo para descargar información del servidor standby para conseguir más recursos en el servidor principal. Cuando se abre en modo de sólo lectura, el envío de archive log continúa, pero la recuperación gestionada se detiene, por lo que la base de datos standby se convierte cada vez más obsoleta hasta que se reanude la recuperación gestionada (managed recovery).
Para cambiar la base de datos a solo lectura haga lo siguiente:

SQL>SHUTDOWN IMMEDIATE;
SQL>STARTUP MOUNT;
SQL>ALTER DATABASE OPEN READ ONLY;


Para reanudar la recuperación gestionada (managed recovery) haga lo siguiente:

SQL>SHUTDOWN IMMEDIATE;
SQL>STARTUP MOUNT;
SQL>ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT FROM SESSION;              

En 11g, Oracle introdujo la característica Active Data Guard. Esto permite que la base de datos en espera de ser abierto en modo de sólo lectura, pero aún se aplica la información de los redo. Esto significa que una base de datos stanby puede estar disponible para la consulta, y aun así estar al día o actualizada. Hay implicaciones de licencia para esta función, pero los siguientes comandos muestran cómo Active Data Guard se puede activar:
SQL>SHUTDOWN IMMEDIATE;
SQL>STARTUP MOUNT;
SQL>ALTER DATABASE OPEN READ ONLY;
SQL>ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT FROM SESSION;


Referencias:

·        Oracle 2010, Oracle® Database SQL Language Reference 11g, obtenida el 1 de mayo de 2013, de http://docs.oracle.com/cd/B28359_01/server.111/b28286/statements_6016.htm


·                       Oracle 2009, Documento técnico de Oracle: Oracle Data Guard 11g versión 2, obtenida el 1 de
mayo de 2013, de http://www.oracle.com/technetwork/es/database/enterprise-edition/documentation/tutorial-oracle-data-guard-11gr2-1707492-esa.pdf

·        Oracle 2012, Oracle® Data Guard Concepts and Administration 11g Release 2 (11.2), obtenida el 4 de mayo de 2013, de http://docs.oracle.com/cd/E11882_01/server.112/e17022/create_ps.htm

      Contactos:
                     Carlos Lisandro Martínez Sandoval           
                          lisandro_916@hotmail.es
                     Samuel Armando Menéndez Sandoval
                               smenendez_91@hotmail.com
                     Erick Gerardo Sarmiento Valenzuela
                               esarmiento45@hotmail.com
                     Isidro Antonio Flores Martínez
                               isidro.antonio@hotmail.com





Enlace al video en youtube: http://www.youtube.com/watch?v=w3mUBLEvK9w




 



Publicado por Unknown en 17:23
Etiquetas:

No hay comentarios:

Publicar un comentario

Suscribirse a: Enviar comentarios (Atom)