miércoles, 20 de mayo de 2009

Como configurar una arquitectura de alta disponibilidad con Oracle Standard Edition (SE)

Hace un tiempo un cliente me pidio armar una arquitectura de alta disponibilidad de forma tal de que la base de datos productiva tuviera un "espejo" y que, por ejemplo, ante un fallo de hardware severo del nodo principal pudiera activarse
el nodo de respaldo con la base "espejo" y que esto no dejara mas de unos pocos minutos al sistema corporativo sin base de datos.
El cliente habia comprado un nuevo servidor, similar al equipo que alojaba la base productiva. Ante el pedido, lo primero que se me ocurrio era armarles un esquema con una base stand-by, ahora llamado DATA GUARD. El problema fue que el cliente tenia su base de datos con Oracle 10g Standard Edition. Oracle SE no tiene el feature de DATA GUARD y por lo tanto la mejor opción que encontré fue implementar un esquema stand-by manual, manejado con scripting y cron. Este esquema no provee la robustez de un DATA GUARD pero se acerca bastante. Como voy a explicar mas adelante, con este modelo de no podemos asegurar que no se pierda lo que se persistio los ultimos minutos, pero dado que el negocio podía contemplar esta perdida se decidió implementar la arquitectura que propuse. A continuación voy a explicar paso a paso, llamaré NODO1 al nodo principal y activo y NODO2 al nodo secundario o stand-by que esta en modalidad pasiva.

1. Instalar el motor de base de datos en el NODO 2. Asegurarse que el S.O sea el mismo que el instalado en el NODO 1, debe tener el mismo nivel de parches, misma arquitectura (32 ó 64 bits) y la base debe tener la misma versión y nivel de parches
que la base productiva.

2. La base de producción (NODO1) deberá estar en modo archiving (esto para mi es excluyente para cualquier base productiva asi que lo
tomo como algo obvio). Copiar con RMAN los datafiles de la siguiente manera:

$rman target / no catalog

RMAN>report schema; <-- Para ver los datafiles que necesitamos copiar.

Una vez que tengo el listado de los datafiles de la base de datos se van copiando uno por uno a un directorio de backups,
por ejemplo para copiar el datafile system01.dbf:

RMAN>copy datafile '/u01/oradata/ROP102/system01.dbf' to '/u01/bkp/ROP102/system01.dbf';

3. Crear el control file standby desde la base de datos primaria (NODO1)

SQLPLUS> ALTER DATABASE CREATE STANDBY CONTROLFILE AS '/u01/bkp/ROP102/control_stdy.ctl';

4. Copiar los datafiles respaldados con el comando copy de rman (paso 2), el control file standby creado en el paso 3
y el archivo de parametros de la base productiva al NODO 2, por ejemplo para pasar los datafiles:

$scp /u01/bkp/ROP102/*.dbf nodo2:/u01/oradata/ROP102/.

Si tenemos distinta estructura de directorios donde van los datafiles entre el NODO1 y el NODO2 tenemos que editar el archivo
de parametros y agregar el siguiente parametro:

DB_FILE_NAME_CONVERT='/u01/oradata/ROP102','u02/oradata/ROP102'

5. Ahora ya tenemos todos los archivos que necesitamos para levantar la base standy en el NODO2.

Se levanta la base en modo nomount usando el archivo de parametros copiado:

SQLPLUS>startup nomount pfile=/u01/app/oracle/products/10.2.0.1/db_1/dbs/iniROP102.ora

Se monta la base en modalidad standby:

SQLPLUS>alter database mount standby database;

6. Una vez que tenemos la base montada en standby solo resta realizar recover de la base en modo AUTO para poner los
datafiles en modo consistente.

SQLPLUS>recover standby database;
AUTO

7. Para chequear que nuestra base standby esta ok, podemos abrirla en modo read only:

SQLPLUS>alter database open read only;


Scripting necesario para la configuración inicial

En NODO 1 - Base de Datos Primaria

El siguiente script se encarga de transferir al nodo standby (NODO 2) las novedades, es decir los
archivelogs que se hayan generado desde la ultima transferencia.

-- move_stdby.sh
rsync -t -e ssh -Pazv /u01/oradata/ROP102/arch/ oracle@dbprod2:/u01/oradata/ROP102/arch/

Para purgar los archivos que ya no se necesiten usamos:

-- purge_arch_nodo1.sh
find /u01/oradata/ROP102/arch/*.arc -mtime +2 -exec rm {} \;

Una posible programación de los scripts del nodo 1 podria ser:

0,30 * * * * /home/oracle/move_stdby.sh <-- Se mueven del nodo 1 al nodo 2 cada 30'
0 7 * * * /home/oracle/purge_arch.sh <-- Se borran los archives todos los dias a las 7am


En NODO 2 - Base de Datos StandBy


Para aplicar los nuevos archives tranferidos:

-- apply_redo_stdby.sh
export ORACLE_SID=ROP102
export ORACLE_HOME=/u01/app/oracle/product/10.2.0
$ORACLE_HOME/bin/sqlplus -s "/ as sysdba" << EOF
recover standby database;
AUTO
exit
EOF

Para levantar la base en modo standby y preparada para aplicar archives:

-- manual_stdby.sh
sqlplus -s "/ as sysdba" << EOF
shutdown immediate;
startup nomount pfile=/u01/app/oracle/product/10.2.0/dbs/initROP102_stdby.ora
alter database mount standby database;
exit
EOF

Para levantar la base en modo solo lectura

-- readonly_stdby.sh
sqlplus -s "/ as sysdba" << EOF
alter database open read only;
exit
EOF

Para purgar los archives copiados al nodo standby

-- purge_arch_nodo2.sh

find /u01/oradata/ROP102/arch/*.arc -mtime +6 -exec rm {} \;
[oracle@dbprod2 ~]$

Una posible programación de los scripts del nodo 1 podria ser:

0,30 * * * * /home/oracle/apply_redo_stdby.sh <-- Se aplican los cambios a la base standby cada 30'
0 7 * * * /home/oracle/purge_arch.sh <-- Se borran los archives todos los dias a las 7am


La base standby esta continuamente aplicando archives, eso se puede chequear en el alert. Cuando la base standby esta en modo solo lectura no puede aplicar nuevos archives. En ciertas ocasiones resulta util tener la base standby en modo read only para realizar reportes y así evitar sobrecargar la base primaria.


Como hacer el switchover en el caso de que falle la base de datos primaria

Si la base primaria falla y no puede recomponerse (por ejemplo por un problema serio de HW) hay que activar la base standby. Para que pueda cumplir el rol de base primaria tendremos que levantarla en modo read write y hacer los siguiente:

1. Aplicar todos los archives que que aun no se hayan aplicado y que hayan pasado al nodo 2.

2. Hacer backup to trace del control file con la base standby en modo read only.

SQLPLUS> alter database backup controlfile to trace as '/u01/oradata/ROP102/control.txt'

3. Levantar la base standby en modo nomount y crear el control file usando en script del control file creado en el paso 2.

SQLPLUS> startup nomount pfile=/u01/app/oracle/product/10.2.0/dbs/initROP102_stdby.ora

Editar el archivo control.txt y dejar solo la ultima sentencia de creación del controlfile. Comentar todas las otras lineas

SQLPLUS>@/u01/oradata/ROP102/control.txt

4. Montar la base usando el nuevo controlfile

Editar el archivo de parametros y cambiar el nombre del controlfile para que se referencie el controlfile recien creado

SQLPLUS>startup mount pfile=/u01/app/oracle/product/10.2.0/dbs/initROP102_stdby.ora

5. Abrir la base en modo resetlogs

SQLPLUS>alter database open resetlogs;

Una vez realizado el paso 5 tenemos la base standby en modalidad read-write y totalmente operativa. Obviamente esta configuración requiere de scripting y de una tarea manual para levantar la base standby en caso de falla. Lo ideal seria tener DATA GUARD que asegura 0 perdida de información y automatización de los procesos de switchover. De todas formas, la arquitectura descripta es bastante adeacuada si no se pretende gastar mucho dinero en licencias y si la posible perdida de algunos minutos de información no afecta al negocio sensiblemente.

53 comentarios:

  1. Hola Pablo, muy interesante tu artículo, yo estoy trabajando con una base de datos Oracle 10gR2 SE y dentro de muy poco tiempo me va a llegar un servidor más que deseo utilizar como respaldo para la base de datos ante cualquier eventualidad, así que posiblemente estaré probando esta solución jeje...

    Saludos.

    ResponderEliminar
  2. Bien, cualquier cosa que necesites o cualquier duda me avisas y te ayudo. Yo tengo implementada esta solucion en 2 clientes desde hace 3 años y funciona muy bien.

    ResponderEliminar
  3. Hola Pablo, he leído este artículo hace un par de meses, realmente me pareció muy interesante y muy bien explicado.

    Por suerte ya tengo el apoyo de mi jefe para realizar pruebas con respecto a este tema. Por eso quisiera saber si el ambiente se podría simular en 2 servidores virtualizados con 2 GB cada uno para reducir costos ya que sería sólo para realizar pruebas y luego configurarlo correctamente en un cliente.

    Desde ya muchas gracias.

    ResponderEliminar
  4. Si, se puede perfectamente testear sobre servidores virtualizados, es mas, yo diria que es ideal probar instalaciones, configuraciones, testear nuevos features, etc usando virtualizacion porque tenes la vuelta atras rapida.

    ResponderEliminar
  5. Hola amigo tengo una duda, es estrictamente necesario que los servidores a nivel de sistema operativo sean identicos, para aplicar dataguard sobre una version Oracle9i, o tan solo con ser identicas las versiones de oracle basta.

    Muchisimas gracias.....

    ResponderEliminar
  6. Hola Pablo, lei esta nota y me gusto mucho la verdad, aunque tengo una duda. Tengo entendido que cuando en la base primaria se crean tablespaces, datafiles, o se modifica el tamaño de datafiles, estos cambios no son "escritos" en los archived logs. Entonces es necesario un script para que estos cambios se vean reflejados en la bd standby. Alguna idea? Particularmente yo estoy buscando ese script y no lo encuentro...

    ResponderEliminar
  7. Hola Damian, la modificación de tamaño de un datafile se realiza automaticamente en la base espejo. En el caso de agregar un tablespace o datafile yo no encontré otra opción que recrear la base stand-by.

    ResponderEliminar
  8. Este comentario ha sido eliminado por el autor.

    ResponderEliminar
  9. hola Pablo. Muy buena tu publicacion, todo lo nombrado estubo claro hasta el punto (Una posible programación de los scripts del nodo 1 podria ser: Una posible programación de los scripts del nodo 1 podria ser:
    0,30 * * * * /home/oracle/move_stdby.sh <-- Se mueven del nodo 1 al nodo 2 cada 30'
    0 7 * * * /home/oracle/purge_arch.sh <-- Se borran los archives todos los dias a las 7am
    ) , si no es mucha molestia me podrias indicar, como se realiza esa programacion y en donde se debe poner. Soy bernardo quinteros de ecuador, y estoy ingresando al mundo de oracle. gracias de antemano

    ResponderEliminar
  10. Hola Bernardo, eso generalmente se programa usando CRON en linux/Unix y usando "Tareas Programadas" si usas un SO de la familia Windows. El ejemplo que hice esta basado en un sistema operativo Linux y la programación es lo que tiene definido el crontab. Te recomiendo que busques en la web sobre el utilitario cron ya que hay mucho info.

    ResponderEliminar
  11. Hola Pablo, yo tengo un ambiente con 3 servidores dos con HPUX y otro Linux y versiones Enterprice de Oracle identicos en los 3, seria posible hacer una replicacion en linea de mi servidor productivo HP/UX a Linux?
    pues durante el dia se generan muchos reportes pesados que degradan el servidor productivo, he tratado se implementar los Streams pero se degrado mucho mas el servidor productivo ¿alguna solucion?

    ResponderEliminar
  12. La solución que dí yo es para ediciones Standard. Vos tenes Enterprise Edition. No me aclaraste la versión de base de datos que estas usando, recien a partir de versiones 11g podes tener distintos SO, arquitectura de cpus, etc, en los nodos primario y standby. Creo que lo mejor para tu caso seria evaluar usar DATA GUARD de forma tal de correr tus reportes sobre el nodo stand by (Linux) y asi sacarle carga al nodo primario (HPUX). Te recomiendo que leas el manual oficial: "Data Guard Concepts and Administration".

    ResponderEliminar
  13. Hola Pablo, gracias por tus sugerencia, mi versión de oracle es 10.2.0.3.0 en los 3 servidores, según tu sugerencia ¿podría tener mi servidor linux en línea con el de producción para correr los reportes si aplico el Data Guard?

    ResponderEliminar
  14. Si, claro, tendrias la instancia stand by levantada para lectura lo cual te permite hacer reportes.

    ResponderEliminar
  15. Hola Pablo,

    Uff, pasó tanto tiempo desde que te escribí, pero ahora he vuelto a merodear por este artículo ya que me ha llegado el nuevo servidor que voy a utilizar de standby.

    Te comento que tuve un inconveniente al utilizar RMAN, que no funcionaba, pero que simplemente se debía a que estaba tratando de ejecutar la aplicación rman de Linux (PolyglotMan, rman) y no RMAN de Oracle, algo que deben tener en cuenta los novatos como yo.

    Por otro lado una pequeña consulta, en el punto 4: "Copiar los datafiles respaldados con el comando copy de rman" supongo que los datafiles a copiar al servidor standby son los que se encuentran en el directorio /u01/bkp/ROP102/ y no los que se encuentran en el directorio /u01/oradata/ROP102/*.dbf como se muestra en la linea del ejemplo o me equivoco?

    Saludos

    ResponderEliminar
  16. Hola. Los archivos a copiar son los datafiles solamente. En mi caso uso extension .dbf, que es la extensión mas común para los datafiles. El control file lo creas a mano como se muestra en la nota y los logfiles se crean solos.

    ResponderEliminar
  17. Hola, pero los .dbf a copiar al NODO2 son los del directorio oradata "/u01/oradata/ROP102/" o del directorio "/u01/bkp/ROP102/" que tiene los datafiles creados en el punto 2 con el comando copy de RMAN?

    Por otro lado, supongo que los tempfiles también tienen que ser copiados, por el momento no logro copiar los tempfiles con el RMAN copy, seguiré investigando..

    Saludos

    ResponderEliminar
  18. Hola, si es correcto, los datafiles a copiar son las copias creadas por RMAN que estan en u01/bkp/ROP102/, gracias por el aporte, ya lo voy a corregir.

    ResponderEliminar
  19. Hola Pablo, quisiera consultarte 2 temas ya que tengo muy poca experiencia sobre los siguientes temas:

    1)- Los tempfiles .dbf ¿tienen que ser creados manualmente en el NODO2? o también pueden ser copiados? la pregunta surge
    porque al tratar de crear una copia de este tipo de archivos con RMAN con el comando "copy tempfile" genera un error y según
    veo la palabra "tempfile" no es una opción disponible para el comando, ¿o simplemente se puede copiar al NODO2 el tempfile utilizado por la BD sin previa copia con RMAN (lease /u01/oradata/ROP102/temp01.dbf)?

    2)- ¿Cual es la configuración más adecuada en el Enterprise Manager para generar los archive logs? Actualmente estoy probando
    con una base de datos de prueba 10gR2 y los archive logs generados tienen un tamaño muy grande y no se generan dentro de un periodo
    de tiempo exacto (por ejemplo cada 5 minutos), sinó que van generando archive logs diarios nada más. Traté de setear el
    parámetro FAST_START_MTTR_TARGET con un valor distinto de cero pero me genera un error, te paso unas capturas:
    http://labitacoradegabriel.wordpress.com/files/2009/12/flash_recovery_area.jpg
    http://labitacoradegabriel.wordpress.com/files/2009/12/fast_start_mttr_target.jpg
    http://labitacoradegabriel.wordpress.com/files/2009/12/archivelog.jpg

    Desde ya gracias por tu tiempo, cualquier sugerencia va a venir bien jeje.
    Saludos.

    ResponderEliminar
  20. Los tempfiles directamente copialos, no uses RMAN. Los archive logs se van generando de acuerdo a la actividad, si queres forzar a que se generen usa: ALTER SYSTEM switch logfile;

    ResponderEliminar
  21. Hola Pablo, estoy probando con la generación de archive logs, actualmente los archive logs se generan con un tamaño similir al tamaño de los redologs que tengo que es aproximadamente de 50 Mb., incluso habiendo aplicado la sentencia ALTER SYSTEM switch logfile;

    Existe alguna forma de crear archivelogs más pequeños que esos 50 Mb.? Falta setear algún parámetro más?

    Aprovecho este comentario para agradecerte y desearte felices fiestas, vale un trago hip!!

    ResponderEliminar
  22. Hola, bueno, quería aclarar unas cuantas cosas que ya entendí del caso:

    1)- Comprendí como funciona el archiving de los redologs al mover una tabla bastante grande a otro tablespace, cada vez que se llena un redolog se cambia al siguiente redolog del grupo de redologs, dándole el tiempo necesario al anterior a archivar en disco su contenido.

    2)- Con la sentencia "ALTER SYSTEM SWITCH LOGFILE;" se obliga a que este salto al siguiente redolog se realize antes de que el actual se haya llenado.

    3)- Tuve que desactivar el modo archivin de la base de datos luego de que la misma se haya bloqueado durante el traslado de la tabla auditoría de unos 6 Gb. aproximadamente a otro tablespace a causa de que existe un quota máxima de archive log.

    Este último punto me hizo pasar un mal rato, pero para solucionar el tema solo fue necesario levantar la base de datos en modo mount, desactivar el archive log con el comando "ALTER DATABASE NOARCHIVELOG;" y volverla a levantar en modo normal.

    Saludos.

    ResponderEliminar
  23. Este comentario ha sido eliminado por el autor.

    ResponderEliminar
  24. Hola Pablo, nuevamente vuelvo a escribir en este maravilloso artículo, porque después de casi 2 meses junto con mis compañeros de oficina pudimos lograr simular este ambiente esquivando todos los obstáculos que se nos presentaron.

    Para colaborar con este artículo me gustaría contar la manera por la cual solucionamos el problema de la replicación de la creación de un datafile en la base primaria, (no quiere decir que sea la mejor, pero funciona bien).


    Si se crea un datafile en la base primaria se debe realizar lo siguiente:

    1) Poner el tablespace en modo offline

    SQL> ALTER TABLESPACE nombre_tablespace OFFLINE;

    2) Se debe copiar el datafile a la ubicación correspondiente en la base secundaria:

    $scp /u01/app/oracle/oradata/nombre_instancia/nombre_datafile.dbf oracle@nodo2:/u01/oradata/nombre_instancia/

    3) Chequear el nombre del datafile en la base secundaria

    -- Esta consulta debería mostrar el nombre del datafile creado como UNNAMEDxxxxx

    select name from v$datafile;

    4) En la base secundaria realizar lo siguiente

    alter system set standby_file_management='manual';

    5) Renombrar el datafile

    alter database create datafile '/u01/app/oracle/oradata/nombre_instancia/UNNAMEDxxxxx' as '/u01/app/oracle/oradata/nombre_instancia/nombre_datafile.dbf'

    6) En la base secundaria

    alter system set standby_file_management='auto';
    recover managed standby database disconnect;

    7) Reiniciar la base secundaria

    Eso es todo, si encuentro otras cosas productivas vuelvo a escribir.

    Pablo, si te parece esta solución la podrías agregar al artículo así no te queda desordenado el blog, con muchas cosas en los comentarios.

    Muchas gracias.

    ResponderEliminar
  25. Funciona, con oracle RAC?? Es decir, que nuestra primary BD sea un RAC y la standby, no lo sea??

    ResponderEliminar
  26. Nunca lo provee con RAC y SE, pero estimo que si se puede.

    ResponderEliminar
  27. Hola, alguien ha profundizado más en el tema de agregar algún datafile? Es estrictamente necesario poner en offline el tablespace de la base de datos primaria?

    Actualmente tenemos cada usuario con un tablespace, si lo pongo en offline, lo dejo sin conexión

    ResponderEliminar
  28. Sería posible hacerlo entre sistemas operativos de distinta arquitectura? Es decir, entre un Suse Linux sobre IBM PowerPC y entre un Suse Linux sobre intel??

    ResponderEliminar
  29. Yo las veces que tuve que agregar un datafile en la base primaria tuve que reconstruir toda la replica ya que el nuevo datafile no se creaba automáticamente en el equipo standby.

    ResponderEliminar
  30. La verdad que no he probado con distintas arquitecturas con los mismos SO's. Yo creo que podria funcionar, será cuestión de que pruebes. Luego, por favor comentanos los resultados.

    ResponderEliminar
  31. He encontrado diversa info en la web y he probado, el agregar un tablespace nuevo, junto con su correspondiente datafile y parece que funciona sin necesidad de recrear la base de datos entera (Estoy probando con maquinas virtuales, en SLES 10 y con oracle 10gR2).

    El procedimiento es este:
    ----
    a) SQL>select name from v$datafile where name like '%UNNAMED%';
    b) SQL> alter database create datafile '/home/oracle/product/ora101/dbs/UNNAMED00005'
    as '/oradata/dummy/test01.dbf';
    Where /oradata/dummy is location for datafiles in standby.
    Now you can restart the recovery process.
    -----

    Sin embargo, no puedo probar las distintas arquitecturas con el mismo sistema operativo, ya que eso lo tengo en producción y no puedo reproducirlo en desarrollo.
    ¿ Alguien podría hacerlo ?

    ResponderEliminar
  32. Es ciero Roberto, creando el datafile como comentas te evitas tener que recrear la base standby ya que asi se copia el el datafile de la base primaria, se pasa a la base standdy y luego se sincroniza con los archives. Gracias por tu aporte!.

    ResponderEliminar
  33. Hola Pablo,

    es posible utilizar este método entre distintas versiones de Oracle funcionando bajo los mismos SO y Hardware?

    Por ejemplo, si tengo Oracle 10g en un servidor (base primaria), y Oracle 11g en otro (base standby) de características exactamente iguales al primero.

    ResponderEliminar
  34. No, tendrias que tener la misma version en ambas bases.

    ResponderEliminar
  35. Pable, En la copia desde la base de datos de producción a la standby en el (punto 2)se copian datafile y redo log ? o solo datafile?

    ResponderEliminar
  36. Pablo, gracias por contestar mis consultas, adicionalmente quiero hacerte dos consultas mas:
    1.- Que consideraciones deben tener los archivos init.xxx de las base primaria como secundaria(standby) referente a los parametros referente a la ubicacion de los archive log, yo tengo seteado de la siguiente manera:

    log_archive_dest_1 = location=/archlog REOPEN=5
    standby_archive_dest = /archlog

    2.- Al crear ALTER DATABASE CREATE STANDBY CONTROLFILE AS '/u01/bkp/ROP102/control_stdy.ctl';
    en el archivo alert.log de la base de datos primaria se genera las siguientes intrucciones que indican ejecutar en el nodo Standby.
    Use the following SQL commands on the standby database to create
    standby redo logfiles that match the primary database:
    ALTER DATABASE ADD STANDBY LOGFILE 'srl1.f' SIZE 52428800;
    ALTER DATABASE ADD STANDBY LOGFILE 'srl2.f' SIZE 52428800;
    ALTER DATABASE ADD STANDBY LOGFILE 'srl3.f' SIZE 52428800;
    ALTER DATABASE ADD STANDBY LOGFILE 'srl4.f' SIZE 52428800;

    Esto hay que ejecutar si o si en la base de datos standby ?

    ResponderEliminar
  37. Añado algo a la creacion de un nuevo datafile a la base standby: Yo lo que hago es sacar un backup del nuevo datafile y recuperarlo en standby, antes de recuperarlo aplico los archivelogs, y luego hago el alter database rename file... funciona perfectamente.

    Para evitarme todos esos pasos, simplemente en la base standby pongo el parametro standby_file_management=AUTO y listo... cada vez q cree un nuevo datafile en produccion, este se crea automaticamente en standby sin hacer nada mas... solo asegurate de tener los mismos directorios en ambas bases.

    Ahora una pregunta: alguien sabe si el parametro standby_file_management es exclusivo para la Enterprise Edition ??? porque ese parametro se usa con Dataguard y se supone q este articulo es para quienes no tenemos Enterprise edition.

    ResponderEliminar
  38. La verdad que no lo he probado aún. Lo que sí hice fue testear si se puede cambiar el parametro de MANUAL a AUTO en una base STANDARD y lo permite, asi que ese seria un primer paso. Lo que te recomiendo para que te quites la duda es crear un datafile, podria crear un tablespace con un datafile y ver si con el parametro seteado en AUTO se te copia en la Stand-by. Luego eliminas el tablespace y el datafile.

    ResponderEliminar
  39. Hola Pablo buen dia, en este momento tenemos oracle 10 G standard edition, tenemos en el site 1, dos servidores en rac conectados a una areglo de discos externo, estamos mirando las posibles soluciones para la replica de datos en nuestro site 2 en tiempo real, y nos recomiendan utilizar la aplicacion de oracle goldengate porque se puede implementar en standard edition y no debo realizar la inversion para migrar a enterprise para utilizar dataguard, la pregunta es, que tan confiable es esta aplicacion si la comparamos con dataguard en costo beneficio?

    ResponderEliminar
  40. Hi there Pablo
    Very nice tutorial for doing 'manual DataGuard' on SE. Thanks a lot for it. I have a question though:
    I don't understand how to go back to standby mode on the node2 database after, let's say, the nod1 problems were solved and it is again "the production node". Do I have to repeat all the creation steps or there's something I missed during the swithover steps?
    Thanks again.

    ResponderEliminar
  41. Once you've started the primary database on node2 you'll need to build the standby database on node1, obviously when the problem on that node is already fixed and you're able to fully operate on that node. At this point, you wil have the same architecture but with the nodes swapped. In order to go back to the initial situation (primary->node1;standy->node2), you should repeat the very same steps explained on this article. I guess that it would only be considered if the nodes´s hardware are different (node1's HW more powerful than node2's HW), which is sometimes possible.

    ResponderEliminar
  42. Pablo

    muy bueno tu documento, cuando dices que solo copiemos los datafiles, pero al hacer el switchover que pasa con los redo log files? o cuando y como se deben crear??

    ResponderEliminar
  43. Hola Pablo,

    Lo primero agradecerte el artículo. Estoy comenzando a estudiar y trabajar con Oracle, y tus publicaciones me están siendo de gran ayuda.

    Ahora, me surge una duda al seguir tus pasos: cuando indicas qué en el nodo2 se debe instalar el motor de la BD, ¿te refieres a no crear previamente ninguna base de datos? Si es así, ¿cómo realizo el comando "startup nomount ..." sin que me de el error "TNS:protocol adapter error"? Espero que puedas ayudarme con este problema de principiante.

    Un saludo y muchas gracias.

    Jose M

    ResponderEliminar
  44. Jose, En el nodo 2 solo instalas el motor, incluso podrias copiarlo del nodo 1, tal cual copias un directorio común. Luego pasas los datafiles y armas el control file como es explica en el documento y listo. Seguó los pasos tal cual estan y te tiene que funcionar.

    ResponderEliminar
  45. Muchas gracias por la ayuda Pablo. Tras entender un poco más de cómo funciona Oracle, he podido seguir tus pasos sin problemas.

    De nuevo, gracias por el magnífico tutorial.

    Un saludo

    Jose M

    ResponderEliminar
  46. Pablo, muchas gracias por el documento y la ayuda. Pregunta: puede hacerse esto con una base primaria en Oracle 11g1 en Windows 2003 Server SP2 y una standby con Oracle 11g2 en Red Hat Linux? es lo que hay en mi entorno y obviamente es dificil de cambiarlo...desde ya muchas gracias

    ResponderEliminar
  47. Hola Pablo muy buen articulo,
    Una de mis dudas es que una vez que el Standby pasa a modo read-write empezaría a registrar transacciones..
    Como haria para replicar estas transacciones
    al servidor primario cuando éste vuelva a entrar
    en funcionamiento
    Gracias.

    ResponderEliminar
  48. Tendrias que armar la replica nuevamente del otro lado.

    ResponderEliminar
  49. Eso significa que se tiene que armar nuevamente produccion?. Pasar toda la data y luego armar el servidor de stand by?.......

    ResponderEliminar
  50. Hola Pablo, me parece muy bueno tu articulo, estoy tratando de replicarlo con 2 maquinas virtuales, sin embargo me surgen algunas dudas las cuales ojala y pudieras ayudarme a despejar.

    La primera es en relacion al startup nomount del punto 5, mi duda es, tengo que llevarme el pfile del nodo1 al nodo2? Esto fue lo que hice y mi base se puso en modo nomunt correctamente, sin embargo, al hacerle el alter database mount standby database, me genera un error, ya que no encuentra mis controlfiles.

    Lo que hice y no se si es correcto, es modificar mi pfile y decirle que use el controlfile standby que genere, una vez hecho esto mi base subio en modo mount correctamente.

    Mi otra duda es, para hacer el recover standby database es necesario solo el archive log generado en el NODO1 o es necesario tambien transferir los archivos de backup y autobackup que se generan en el NODO1.

    De antemano gracias

    ResponderEliminar
  51. hola;
    realicé el proceso (excepto que primero puse los tablespace en modo backup (alter tablespace XXXX begin backup); copié los datafile (*.dbf) con scp al nodo de standby; exceptuando en temporal) y resulta que al ejecutar el comando "recover standby database" me dice que no encuentra el archive con secuencia 1_xxxxxx_xxxxx.dbf resulta que en el servidor de producción todavía no se ha generado ese archivo y si miro "archive log list" las secuencias de archivado entre las dos bd no son iguales, por ejemplo en producción va en secuencia 55 pero en standby va en 54 y pide el archivo 55 siendo que este no ha sido generado en el servidor de producción (esto como para copiarlo con rsync); por que me pasa esto? agradezco la ayuda prestada de antemano.

    ResponderEliminar
  52. Hola, cada vez que se aplica los archive se debe volver a ejecutar manual_stdby.sh?
    Por que si no ejecuto ese script ya no aplica más con_stdby.sh

    ResponderEliminar