Durante los días de vacaciones (vacaciones de mis compañeros de trabajo, claro), me he dedicado, entre otras cosas, a montar un DataGuard en Oracle 10g con una Standby física en unas máquinas de taller que me han montado muy amablemente para esto.

Como todo buen padawan que se precie, cuando toca hacer algo que nunca has hecho, lo primero que se hace es preguntárselo al Maestro Google, que para eso sabe mucho y es el maesto.

Mi primera sorpresa es la poca información que encontré en cristiano... todo venia en el idioma de la Pérfida Albión.
También es posible que yo no lo supiera buscar correctamente...

Puesto que me tocaba tragarme mi opinión sobre el idioma de los hijos de la Gran Bretaña, decidí finalmente seguir "fil parranda" los pasos indicados por la documentación original y oficial de Oracle.

Utilizando el manual oficial de oracle dedicado a los DataGuard y guiado por una nota oficial del MetaLink (343424.1), conseguí montar con éxito, pero no sin esfuerzo, el correspondiente Dataguard.

A continuación indico paso a paso como lo he hecho...

La plataforma que he utilizado es la siguiente:

• Host VMWARE con Windows 2003 Standar Edition.
• Oracle 10.2.0.4 Enterprise Edition.
• Primary DB SID: CHICAGO
• Standby DB SID: BOSTON

NOTA: Todos los comandos indicados son ejecutados con el usuario SYS conectado como SYSDBA.

Antes de empezar, aclarar los términos que utilizo durante toda la explicación:
PRIMARY: BDD Primary
STANDBY: BDD Standby (StandBy física)
SPFILE: Fichero de inicio en binario (NO se puede modificar mediante un editor de texto). Su nombre suele ser SPFILE.ORA (P.E.: SPFILEboston.ORA)
PFILE: Fichero de inicio en texto (se ha de modificar mediante un editor de texto). Su nombre suele ser INIT.ORA (P.E.: INITboston.ORA)

La creación de las BDD ha sido mediante la instalación por defecto, no se han modificado ni parámetros ni rutas.
Estos pasos sirven tanto para crear un DataGuard con una BDD nueva como con una existente. En el caso de hacerlo sobre una BDD con información útil es muy importante que antes hagas una copia de seguridad de todos los objetos importantes (DataFile, SPFile/PFile, Logs, Arc, etc...).

A partir de aquí, los pasos son los que he seguido y no tienen porque ser exactamente iguales a la documentación de Oracle.
También es posible que algunos pasos sean repetitivos o se puedan hacer de una manera mas sencilla, pero estos son los pasos que he seguido y me ha funcionado perfectamente.

Partimos con que están las dos BDD creadas. La BDD StandBy tendría que ser una instalación completamente limpia, ya que eliminaremos el fichero de configuración, los DataFiles y los Control files.

Lo primero que tendríamos que asegurarnos es que existe visibilidad entre la PRIMARY y la STANDBY. Para eso tenemos que configurar el TNSNAMES de cada servidor añadiendo la entrada que corresponda (es decir, añadir la PRIMARY en el TNSNAMES de la STANDBY y viceversa).
Verifica que se ven mutuamente haciendo un TNSPING a las dos BDD desde cada uno de los servidores.

Personalmente, prefiero realizar la primera configuración (sobre la PRIMARY) mediante SPFILE. Esto nos permite asegurarnos que las modificaciones de los parámetros de inicio se ha hecho correctamente sin necesidad de reiniciar la BDD (aunque requiera reiniciar la BDD para que se apliquen las modificaciones), o como mínimo que el parámetro que hemos modificado es correcto.
En el caso de que la PRIMARY se inicie mediante PFILE, lo configuraremos temporalmente para que inicie mediante SPFILE.

Para crear el SPFILE lanzamos la siguiente instrucción:
SQL> CREATE SPFILE FROM PFILE;

Después, renombramos el PFILE (nos servirá de backup por si algo sale mal) y reiniciaremos la PRIMARY:
SQL> SHUTDOWN IMMEDIATE
SQL> STARTUP

Ya tenemos la PRIMARY arrancada con el SPFILE. Ahora, todas las modificaciones de parámetros se han de hacer mediante ALTER.

Para empezar, necesitamos que la PRIMARY tenga activado el modo ARCHIVELOG. Para ello, lanzamos los siguientes comandos:
SQL> ALTER SYSTEM SET LOG_ARCHIVE_DEST_1 = 'LOCATION=C:\oracle\product\10.2.0\ARCH' SCOPE=SPFILE;
SQL> ALTER SYSTEM SET LOG_ARCHIVE_FORMAT='%t_%s_%r.dbf' SCOPE=SPFILE;
SQL> SHUTDOWN IMMEDIATE
SQL> STARTUP MOUNT
SQL> ALTER DATABASE ARCHIVELOG;
SQL> ALTER DATABASE OPEN;

Es recomendable que tener activado el modo FORCE LOGGING. No es imprescindible, pero si recomendado, al menos que esté el máximo tiempo posible activado.
Para ello, lanzamos el siguiente comando:
SQL> ALTER DATABASE FORCE LOGGING;

Ahora tenemos que crear en la PRIMARY los redolog que usará la STANDBY. Para ello, identificamos primero los que hay con los siguientes comandos...
-- Redolog existentes
SQL> SELECT * FROM V$LOGFILE;
-- Tamaño de cada uno de ellos
SQL> SELECT BYTES/1024/1024 MB FROM V$LOG;

...y creamos nuevos ficheros de standby del mismo tamaño y con un número de grupo secuencial (por defecto, Oracle crea 3 ficheros de 50MB) :
SQL> ALTER DATABASE ADD STANDBY LOGFILE GROUP 4 ('c:\oracle\product\10.2.0\oradata\chicago\redosb01.log') SIZE 50M;
SQL> ALTER DATABASE ADD STANDBY LOGFILE GROUP 5 ('c:\oracle\product\10.2.0\oradata\chicago\redosb02.log') SIZE 50M;
SQL> ALTER DATABASE ADD STANDBY LOGFILE GROUP 6 ('c:\oracle\product\10.2.0\oradata\chicago\redosb03.log') SIZE 50M;

Ya tenemos la PRIMARY pre-configurada.

Para continuar, tenemos que para la PRIMARY (y la STANDBY, si la teníamos arrancada):
SQL> SHUTDOWN IMMEDIATE

Con las dos BD paradas hacemos un backup de los DataFiles, Redolog Online y Standby logs de la PRIMARY y los restauramos sobre la STANDBY.
Oracle recomienda utilizar el RMAN, pero yo he realizado una copia normal y corriente de los ficheros a través de la red.
IMPORTANTE: NO INICIAREMOS NINGUNA BDD. ¡ESPECIALMENTE LA STANDBY!

Ahora, desde la PRIMARY generaremos un fichero de control para la STANDBY con la siguiente secuencia de comandos:
SQL> STARTUP MOUNT;
SQL> ALTER DATABASE CREATE STANDBY CONTROLFILE AS 'c:\stdby.ctl';
SQL> ALTER DATABASE OPEN;

Copiamos este fichero de control en el servidor de la STANDBY (en nuestro caso: C:\oracle\product\10.2.0\oradata\boston).

Copiamos también el fichero de password de la PRIMARY en la STANDBY en la misma ruta donde se encuentra en la PRIMARY (en nuestro caso: C:\oracle\product\10.2.0\db_1\database\PWDchicago.ora).

Ahora generamos un PFILE con todas las modificaciones que hemos hecho en la PRIMARY con el siguiente comando (este fichero lo podremos modificar posteriormente mas cómodamente que el SPFILE):
SQL> CREATE PFILE FROM SPFILE;

Una vez que tenemos el PFILE, renombraremos el SPFILE para que no lo use en el arranque y lo guardaremos como backup.
Modificaremos los siguientes campos del PFILE (si hay alguno que no existe, lo creamos):

db_name='chicago'
db_unique_name='chicago'
LOG_ARCHIVE_CONFIG='DG_CONFIG=(chicago,boston)'
LOG_ARCHIVE_DEST_1='LOCATION=C:\oracle\product\10.2.0\ARCH
VALID_FOR=(ALL_LOGFILES,ALL_ROLES)
DB_UNIQUE_NAME=chicago'
LOG_ARCHIVE_DEST_2='SERVICE=boston
VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE)
DB_UNIQUE_NAME=boston'
LOG_ARCHIVE_DEST_STATE_1=ENABLE
LOG_ARCHIVE_DEST_STATE_2=ENABLE
LOG_ARCHIVE_MAX_PROCESSES=30
log_archive_format='%t_%s_%r.dbf'
STANDBY_FILE_MANAGEMENT=AUTO
STANDBY_ARCHIVE_DEST='C:\oracle\product\10.2.0\ARCH'
FAL_SERVER='boston'
FAL_CLIENT='chicago'


El PFILE quedará de la siguiente manera (la cantidad de campos y sus valores varían en función de la configuración previa de la BDD):

chicago.__db_cache_size=197132288
chicago.__java_pool_size=4194304
chicago.__large_pool_size=4194304
chicago.__shared_pool_size=83886080
chicago.__streams_pool_size=0
*.audit_file_dest='C:\oracle\product\10.2.0\admin\chicago\adump'
*.background_dump_dest='C:\oracle\product\10.2.0\admin\chicago\bdump'
*.compatible='10.2.0.3.0'
*.control_files='C:\oracle\product\10.2.0\oradata\chicago\control01.ctl','C:\oracle\product\10.2.0\oradata\chicago\control02.ctl','C:\oracle\product\10.2.0\oradata\chicago\control03.ctl'
*.core_dump_dest='C:\oracle\product\10.2.0\admin\chicago\cdump'
*.db_block_size=8192
*.db_domain=''
*.db_file_multiblock_read_count=16
*.db_name='chicago'
*.db_unique_name='chicago'
*.dispatchers='(PROTOCOL=TCP) (SERVICE=chicagoXDB)'
*.job_queue_processes=10
*.LOG_ARCHIVE_CONFIG='DG_CONFIG=(chicago,boston)'
*.LOG_ARCHIVE_DEST_1='LOCATION=C:\oracle\product\10.2.0\ARCH
VALID_FOR=(ALL_LOGFILES,ALL_ROLES)
DB_UNIQUE_NAME=chicago'
*.LOG_ARCHIVE_DEST_2='SERVICE=boston
VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE)
DB_UNIQUE_NAME=boston'
*.LOG_ARCHIVE_DEST_STATE_1=ENABLE
*.LOG_ARCHIVE_DEST_STATE_2=ENABLE
*.log_archive_format='%t_%s_%r.dbf'
*.LOG_ARCHIVE_MAX_PROCESSES=30
*.STANDBY_FILE_MANAGEMENT=AUTO
*.STANDBY_ARCHIVE_DEST='C:\oracle\product\10.2.0\ARCH'
*.open_cursors=300
*.pga_aggregate_target=96468992
*.processes=150
*.remote_login_passwordfile='EXCLUSIVE'
*.sga_target=290455552
*.undo_management='AUTO'
*.undo_tablespace='UNDOTBS1'
*.user_dump_dest='C:\oracle\product\10.2.0\admin\chicago\udump'
*.FAL_SERVER='boston'
*.FAL_CLIENT='chicago'


Ese mismo fichero lo usaremos para la STANDBY. La idea es copiar el fichero PFILE a la STANDBY y posteriormente modificar los campos necesarios.

Ahora iniciamos la PRIMARY confirmando que todos los datos están bien (si hay alguno mal, nos mostrará un error al arrancar).
IMPORTANTE: TODAVIA NO INICIAREMOS LA STANDBY!!!!
SQL> STARTUP

Ya tenemos la PRIMARY completamente configurada y preparada. Ha llegado la hora de dedicarnos a la STANBY.

Partiendo del PFILE de la PRIMARY, modificamos (o creamos desde el principio) el PFILE de la STANDBY modificando los datos correspondientes. En este caso, los datos serán los siguientes:

db_name='chicago'
db_unique_name=boston
control_files='C:\oracle\product\10.2.0\oradata\boston\stdby.ctl'
LOG_ARCHIVE_CONFIG='DG_CONFIG=(chicago,boston)'
LOG_ARCHIVE_DEST_1='LOCATION=C:\oracle\product\10.2.0\ARCH
VALID_FOR=(ALL_LOGFILES,ALL_ROLES)
DB_UNIQUE_NAME=boston'
LOG_ARCHIVE_DEST_2='SERVICE=chicago LGWR ASYNC
VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE)
DB_UNIQUE_NAME=chicago'
LOG_ARCHIVE_DEST_STATE_1=ENABLE
LOG_ARCHIVE_DEST_STATE_2=ENABLE
LOG_ARCHIVE_MAX_PROCESSES=30
log_archive_format='%t_%s_%r.dbf'
STANDBY_FILE_MANAGEMENT=AUTO
STANDBY_ARCHIVE_DEST='C:\oracle\product\10.2.0\ARCH'
FAL_SERVER=chicago
FAL_CLIENT=boston
DB_FILE_NAME_CONVERT='chicago','boston'
LOG_FILE_NAME_CONVERT='C:\oracle\product\10.2.0\oradata\chicago\','C:\oracle\product\10.2.0\oradata\boston\'


IMPORTANTE: SI PARTES DEL PFILE DE LA PRIMARY RECIERDA MODIFICAR EL NOMBRE DE LA BDD EN TODAS LAS LINEAS O NO FUNCIONARÁ CORRECTAMENTE.

El fichero PFILE de la STANDBY quedará de la siguiente manera:

boston.__db_cache_size=197132288
boston.__java_pool_size=4194304
boston.__large_pool_size=4194304
boston.__shared_pool_size=83886080
boston.__streams_pool_size=0
*.audit_file_dest='C:\oracle\product\10.2.0\admin\boston\adump'
*.background_dump_dest='C:\oracle\product\10.2.0\admin\boston\bdump'
*.compatible='10.2.0.3.0'
*.control_files='C:\oracle\product\10.2.0\oradata\boston\stdby.ctl'
*.core_dump_dest='C:\oracle\product\10.2.0\admin\boston\cdump'
*.db_block_size=8192
*.db_domain=''
*.db_file_multiblock_read_count=16
*.db_name='chicago'
*.db_unique_name='boston'
*.dispatchers='(PROTOCOL=TCP) (SERVICE=bostonXDB)'
*.job_queue_processes=10
*.LOG_ARCHIVE_CONFIG='DG_CONFIG=(chicago,boston)'
*.LOG_ARCHIVE_DEST_1='LOCATION=C:\oracle\product\10.2.0\ARCH
VALID_FOR=(ALL_LOGFILES,ALL_ROLES)
DB_UNIQUE_NAME=boston'
*.LOG_ARCHIVE_DEST_2='SERVICE=chicago LGWR ASYNC
VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE)
DB_UNIQUE_NAME=chicago'
*.LOG_ARCHIVE_DEST_STATE_1=ENABLE
*.LOG_ARCHIVE_DEST_STATE_2=ENABLE
*.log_archive_format='%t_%s_%r.dbf'
*.LOG_ARCHIVE_MAX_PROCESSES=30
*.STANDBY_FILE_MANAGEMENT=AUTO
*.STANDBY_ARCHIVE_DEST='C:\oracle\product\10.2.0\ARCH'
*.open_cursors=300
*.pga_aggregate_target=96468992
*.processes=150
*.remote_login_passwordfile='EXCLUSIVE'
*.sga_target=290455552
*.undo_management='AUTO'
*.undo_tablespace='UNDOTBS1'
*.user_dump_dest='C:\oracle\product\10.2.0\admin\boston\udump'
*.FAL_SERVER='chicago'
*.FAL_CLIENT='boston'
*.DB_FILE_NAME_CONVERT='chicago','boston'
*.LOG_FILE_NAME_CONVERT='C:\oracle\product\10.2.0\oradata\chicago\','C:\oracle\product\10.2.0\oradata\boston\'


Es hora de iniciar la STANDBY. Para ello, utilizaremos los siguientes comandos:
SQL> STARTUP MOUNT
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT;

Ya tenemos el DataGuard montado, pero ¿como sabemos que realmente se están replicando los logs?
Pues bien, para verificar la transferencia de los LOGS, seguiremos los siguientes pasos:

1.- Listamos los LOGS existentes en la STANDBY:
SQL> SELECT SEQUENCE#, FIRST_TIME, NEXT_TIME FROM V$ARCHIVED_LOG ORDER BY SEQUENCE#;

2.- Forzamos el cambio de LOG en la PRIMARY:
SQL> ALTER SYSTEM SWITCH LOGFILE;

3.- Verificamos que se han replicado y aplicado los LOGS en la STANDBY (la columna APP tiene que mostrar YES):
SQL> SELECT SEQUENCE#,APPLIED FROM V$ARCHIVED_LOG ORDER BY SEQUENCE#;

Si aparecen la misma cantidad de registros en la PRIMARY que en la STANDBY, y la columna APP tiene YES en todos los registros, significa que nuestro DataGuard esta completamente operativo.
Has de tener en cuenta que la transferencia de los LOGS y su aplicación no es instantánea, depende la velocidad de red y de disco (si los LOG son muy grandes). Si no te salen los logs, o te salen con la columna APP a NO, tomate antes unos minutos de descanso y luego verifícalo de nuevo.

En el caso de que no se transfieran los LOGS o no se apliquen, revisa todos los valores de los PFILE.

Por último, si queremos que nuestras BDD inicien con SPFILE solo tenemos que lanzar el siguiente comando en cada una de ellas:
SQL> CREATE SPFILE FROM PFILE;