Como montar un Oracle DataGuard con Phisical Standby en Oracle 10g

Como montar un Oracle DataGuard con Phisical Standby en Oracle 10g

Enviado por undomain el Mi, 27/08/2008 - 06:46.Durante los das de vacaciones (vacaciones de mis compaeros de trabajo, claro), me he dedicado, entre otras cosas, a montar un DataGuard en Oracle 10g con una Standby fsica en unas mquinas 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 preguntrselo al Maestro Google, que para eso sabe mucho y es el maesto.

Mi primera sorpresa es la poca informacin que encontr en cristiano... todo venia en el idioma de la Prfida Albin.Tambin es posible que yo no lo supiera buscar correctamente...

Puesto que me tocaba tragarme mi opinin sobre el idioma de los hijos de la Gran Bretaa, decid finalmente seguir "fil parranda" los pasos indicados por la documentacin original y oficial de Oracle.

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

A continuacin 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 trminos que utilizo durante toda la explicacin:PRIMARY: BDD PrimarySTANDBY: BDD Standby (StandBy fsica)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 creacin de las BDD ha sido mediante la instalacin por defecto, no se han modificado ni parmetros 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 informacin tiles 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 documentacin de Oracle.Tambin 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 estn las dos BDD creadas. La BDD StandBy tendra que ser una instalacin completamente limpia, ya que eliminaremos el fichero de configuracin, los DataFiles y los Control files.

Lo primero que tendramos que asegurarnos es que existe visibilidad entre la PRIMARY y la STANDBY. Para eso tenemos que configurar el TNSNAMES de cada servidor aadiendo la entrada que corresponda (es decir, aadir 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 configuracin (sobre la PRIMARY) mediante SPFILE. Esto nos permite asegurarnos que las modificaciones de los parmetros 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 mnimo que el parmetro 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 instruccin:SQL> CREATE SPFILE FROM PFILE;Despus, renombramos el PFILE (nos servir de backup por si algo sale mal) y reiniciaremos la PRIMARY:SQL> SHUTDOWN IMMEDIATESQL> STARTUPYa tenemos la PRIMARY arrancada con el SPFILE. Ahora, todas las modificaciones de parmetros 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 IMMEDIATESQL> STARTUP MOUNTSQL> 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 mximo 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 existentesSQL> SELECT * FROM V$LOGFILE;-- Tamao de cada uno de ellosSQL> SELECT BYTES/1024/1024 MB FROM V$LOG;...y creamos nuevos ficheros de standby del mismo tamao y con un nmero 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 tenamos arrancada):SQL> SHUTDOWN IMMEDIATECon 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 travs 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 tambin 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 cmodamente 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\ARCHVALID_FOR=(ALL_LOGFILES,ALL_ROLES)DB_UNIQUE_NAME=chicago'LOG_ARCHIVE_DEST_2='SERVICE=bostonVALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE)DB_UNIQUE_NAME=boston'LOG_ARCHIVE_DEST_STATE_1=ENABLELOG_ARCHIVE_DEST_STATE_2=ENABLELOG_ARCHIVE_MAX_PROCESSES=30log_archive_format='%t_%s_%r.dbf'STANDBY_FILE_MANAGEMENT=AUTOSTANDBY_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 varan en funcin de la configuracin previa de la BDD):

chicago.__db_cache_size=197132288chicago.__java_pool_size=4194304chicago.__large_pool_size=4194304chicago.__shared_pool_size=83886080chicago.__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\ARCHVALID_FOR=(ALL_LOGFILES,ALL_ROLES)DB_UNIQUE_NAME=chicago'*.LOG_ARCHIVE_DEST_2='SERVICE=bostonVALID_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 estn bien (si hay alguno mal, nos mostrar un error al arrancar).IMPORTANTE: TODAVIA NO INICIAREMOS LA STANDBY!!!!SQL> STARTUPYa 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 sern los siguientes:

db_name='chicago'db_unique_name=bostoncontrol_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\ARCHVALID_FOR=(ALL_LOGFILES,ALL_ROLES)DB_UNIQUE_NAME=boston'LOG_ARCHIVE_DEST_2='SERVICE=chicago LGWR ASYNCVALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE)DB_UNIQUE_NAME=chicago'LOG_ARCHIVE_DEST_STATE_1=ENABLELOG_ARCHIVE_DEST_STATE_2=ENABLELOG_ARCHIVE_MAX_PROCESSES=30log_archive_format='%t_%s_%r.dbf'STANDBY_FILE_MANAGEMENT=AUTOSTANDBY_ARCHIVE_DEST='C:\oracle\product\10.2.0\ARCH'FAL_SERVER=chicagoFAL_CLIENT=bostonDB_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=197132288boston.__java_pool_size=4194304boston.__large_pool_size=4194304boston.__shared_pool_size=83886080boston.__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\ARCHVALID_FOR=(ALL_LOGFILES,ALL_ROLES)DB_UNIQUE_NAME=boston'*.LOG_ARCHIVE_DEST_2='SERVICE=chicago LGWR ASYNCVALID_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 MOUNTSQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT;Ya tenemos el DataGuard montado, pero como sabemos que realmente se estn 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 aplicacin no es instantnea, 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 verifcalo 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;Configurando el DGMGRL (DataGuard Manager):El dataguard manager o dgmgrl es una aplicacin propia de Oracle para facilitar la transicin de estados de primaria a standby y viceversa, en vez de utilizar por lnea de comando varias opciones.Desde el SQLPLUS lanzamos la sentencia para comprobar el nombre de la bbdd en la que estamos trabajando:SQL> show parameter db_unique_name;

NAME TYPE VALUE-------------------------- -------------------- -------------------------db_unique_name string ORCLASQL>

Luego activaremos el dgmgrl con el siguiente comando, siempre desde el SQLPLUS:

SQL> alter system set dg_broker_start=true scope=both;

Ahora comprobaremos la configuracin del dgmgrl:

SQL> show parameter dg

NAME TYPE VALUE-------------------------- -------------------- -------------------------dg_broker_config_file1 stringdg_broker_config_file2 string

dg_broker_start boolean TRUE

alter system set dg_broker_start = true;

Ahora lanzaremos el dgmgrl para configurarlo desde cero, desde el cmd lanzamos el comando dgmgrl:

C:\>dgmgrl

DGMGRL for Windows: Version 10.1.0.2.0 Production

Copyright (c) 2000, 2004, Oracle. All rights reserved.

Welcome to DGMGRL, type "help" for information.

Nos conectamos a la instancia:

DGMGRL> connect /Connected.

Comprobamos si existe configuracin:

DGMGRL> show configurationError: ORA-16532: Data Guard broker configuration does not exist.

unable to describe configuration

Si obtenemos el error anterior quiere decir que el archivo de configuracin no existe y debemos crearlo como se muestra a continuacin:

DGMGRL> create configuration 'DBSID_DG' AS> primary database is 'ORCLA'> connect identifier is ORCLA;Configuration "DBSID_DG" created with primary database "DBSID_dg2".

Comprobamos si ahora existe configuracin:

DGMGRL> show configuration

ConfigurationName: DBSID_DGEnabled: NOProtection Mode: MaxPerformanceDatabases:ORCLA - Primary database

Current status for "DBSID_DG":DISABLED

Ahora agregaremos la bbdd de standbyu:

DGMGRL> add database 'ORCLB' as> connect identifier is ORCLB> maintained as physical;Database "ORCLB" added.

Comprobamos si ahora existen los dos sid ORCLA y ORCLB:

DGMGRL> show configuration

ConfigurationName: DBSID_DGEnabled: NOProtection Mode: MaxPerformanceDatabases:ORCLA - Primary databaseORCLB - Physical standby database

Current status for "DBSID_DG":DISABLED

Como podemos comprobar podemos ver la configuracin pero todava no esta activa, por eso el estado DISABLED.

Activamos la configuracin:

DGMGRL> enable configuration;Enabled.

Comprobamos nuevamente si ya estn los dos sid ORCLA y ORCLB y si el estado ha cambiado de DISABLED a SUCCESS.

DGMGRL> show configuration

ConfigurationName: DBSID_DGEnabled: YESProtection Mode: MaxPerformanceDatabases:ORCLA - Primary databaseORCLB - Physical standby database

Current status for "DBSID_DG":SUCCESS

DGMGRL>

Eso quiere decir que ya podemos en cualquier momento hacer la transicin desde un nodo a otro.

Cambiando de Swithover/Failover en la bbdd de Standby:

Modo manual sin el dgmgrl:Lanzamos el SQLPLUS con los siguientes comandos:sqlplus / as sysdba

SQL*Plus: Release 10.1.0.5.0 - Production on Fri Mar 9 16:41:19 2007

Copyright (c) 1982, 2005, Oracle. All rights reserved.

Connected to:Oracle Database 10g Enterprise Edition Release 10.1.0.5.0 - 64bit ProductionWith the Partitioning, OLAP and Data Mining options

SQL> SELECT SWITCHOVER_STATUS FROM V$DATABASE;

SWITCHOVER_STATUS------------------------------------------------------------TO STANDBY

SQL> ALTER DATABASE COMMIT TO SWITCHOVER TO PHYSICAL STANDBY;

Database altered.

SQL> shutdown immediate;ORA-01507: database not mounted

ORACLE instance shut down.SQL> startup mount;ORACLE instance started.

Total System Global Area 1577058304 bytesFixed Size 1322520 bytesVariable Size 400282088 bytesDatabase Buffers 1174405120 bytesRedo Buffers 1048576 bytesDatabase mounted.SQL>Ahora la base de datos primaria ha pasado a standby fisico. Esto se utiliza para poder seguir reparar la bbdd en caso de fallo o avera y delegar el control a la otra bbdd.Modo dgmgrl (dataguard):Para realizar la transicin de la bbdd de uno a otro debemos realizar la siguiente operacin, desde el DGMGRL lanzamos el comando switchover y lo apuntamos al nodo o sid que necesitemos alternar es decir que si ahora la bbdd primaria es la ORCLA y esta tiene problemas, debemos apuntar el comando switchover a la que tengamos libre o disponible que en este caso de ejemplo es la ORCLB.DGMGRL> switchover to "ORCLB";Performing switchover NOW. Please wait...Operation requires shutdown of instance "DBSID" on database "ORCLA".Shutting down instance "DBSID"...ORA-01017: invalid username/password; logon denied

You are no longer connected to ORACLEPlease connect again.Unable to shut down instance "DBSID".You must shut down instance "DBSID" manually.Operation requires shutdown of instance "DBSID" on database "ORCLA".You must shut down instance "DBSID" manually.Operation requires startup of instance "DBSID" on database "ORCLB".You must start instance "DBSID" manually.Operation requires startup of instance "DBSID" on database "ORCLA".You must start instance "DBSID" manually.Switchover succeeded. New primary is "ORCLB"DGMGRL>

Como podemos comprobar ya se ha efectuado la transicin y ahora ya tenemos conexin con la base de datos.

Si queremos volver a dejar como primaria la base de datos original despus de reparar el error debemos lanzar el comando switchover apuntando a la ORCLA nuevamente.Posibles errores:

Error ORA-16607 al lanzar el comando SHOW CONFIGURATION en el dgmgrl:

Debemos chequear que ambas bbdd esten utilizando el spfile creado, si no es as crearlo, otro error relacionado es que nos hemos olvidado de copiar el archivo de password que creamos al principio de este tutorial.

Error ORA-16608 al lanzar el SWITCHOVER en el dgmgrl:

Posiblemente sea por el mismo error anterior y su solucin, lo que pasa es que cambia el cdigo de error por que el comando es diferente.

Error ORA-16675 durante el SWITCHOVER en el dgmgrl:

Debemos asegurarnos de que la base de datos de standby esta montada y que esta en modo recovery, sino lo esta lanzamos un STARTUP MOUNT y luego ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT; , esperaremos un par de segundo s y volvemos a lanzar el comando switchover.Error ORA-12514 durante el SWITCHOVER en el dgmgrl:ORA-12514: TNS:listener does not currently know of service requested in connect, este error se debe a que el dgmgrl esta solicitando al listener un parmetro y este no lo tiene configurado o no es el mismo.Fin del documento.

Woa, nivelazo Moi. Me haEnviado porPedro(no verificado) el Mi, 27/08/2008 - 16:12.

Woa, nivelazo Moi.Me ha traido algunos recuerdos, esto es arquitectura activo-pasivo verdad? cuando te peta la primera tienes que hacer un comando para activar la standby recover from standby o algo asi verdad?

responderhehehehe.... dudo que enEnviado por undomain el Mi, 27/08/2008 - 16:29.

hehehehe.... dudo que en Rete/Auna/Ono te dejaran hacer cosas de estas :D

La verdad es que el tema de la restauracin todavia lo estoy "estudiando", pero en principio seria simplemente levanta la Standby de manera normal con un startup (antes tienes que cancelar el Recover managed), cuando resucite la Primary, restaurar los Archivers de la StandBy y reactivarle el Recover Managed.

Tengo en el tintero alguna ampliacin de este articulito con los impactos de rendimiento segn el metodo de replicacin de logs y la actualizacin en tiempo real.

P.D.: Muchas gracias por el comentario ;)

responderEn rete no, pero yo me fuiEnviado porPedro(no verificado) el Jue, 28/08/2008 - 19:33.

En rete no, pero yo me fui mucho antes que tu eh!!! XDDD, aunque en rete al final pude hacer mucho mas de lo que pensaba en un principio.

Creo recordar que debias tener mucho cuidado al poner en activo el stand by, ya que una vez que lo pones activo, ya no hay vuelta atras, tienes que regenerar el entorno para la proxima vez.

Sobre lo del rendimiento, creo que yo vi algunas incidencias a la hora de aplicar los logsEn GE usaban el entorno de standby con una base de datos de reporting montada y cuando hacia falta se bajaba reporting y se ponia activo el standby.

De nada hombre, a ver si vas publicando las pruebas que hagas :)

responderVaya por fin puedo escribirEnviado porDame argo(no verificado) el Lun, 01/09/2008 - 21:10.

Vaya por fin puedo escribir mensajes, el anterior formato no me dejaba xD pues nose, mola el diseo y... que frikie eres tio xD (espero la pizza)

responderUna consulta el Hardware yEnviado por Martin (no verificado) el Mi, 19/11/2008 - 22:45.

Una consulta el Hardware y version sistema operativo debe ser el mismo en cada nodo?Muchas gracias

responderEl SO si, el hardware no. EsEnviado por undomain el Jue, 20/11/2008 - 07:30.

El SO si, el hardware no.Es decir, los dos han de tener el mismo SO aunque difiera de versin (windows, unix, linux), pero el hardware no afecta para nada.Lo que no se es como puede afectar si en un nodo pones un AIX y en otro un SOLARIS o un HPUX. Lo mas recomendable es que sean exactamente la misma versin, si se puede.

responderHola, cuando dices :Enviado por monica (no verificado) el Mar, 17/02/2009 - 17:01.

Hola,cuando dices : "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\ARCHVALID_FOR=(ALL_LOGFILES,ALL_ROLES)DB_UNIQUE_NAME=chicago'LOG_ARCHIVE_DEST_2='SERVICE=bostonVALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE)DB_UNIQUE_NAME=boston'LOG_ARCHIVE_DEST_STATE_1=ENABLELOG_ARCHIVE_DEST_STATE_2=ENABLELOG_ARCHIVE_MAX_PROCESSES=30log_archive_format='%t_%s_%r.dbf'STANDBY_FILE_MANAGEMENT=AUTOSTANDBY_ARCHIVE_DEST='C:\oracle\product\10.2.0\ARCH'FAL_SERVER='boston'FAL_CLIENT='chicago'"Por qu te refieres a chicago ,que es la bd standby, si se supone que estas configurando el PFILE de la bd primary???

Muchas gracias de antemano.Un saludo.Mnica.

responderUO! Has encontrado unaEnviado por undomain el Mar, 17/02/2009 - 17:27.

UO!Has encontrado una "pequea" errata:CHICAGO es la PrymaryBOSTON es la StandBy

Muchas gracias por ver el dato.... ahora mismo lo arreglo :P

Perdon por el lapsus T_T

responderEs correcto que en el ficheroEnviado por monica (no verificado) el Mi, 18/02/2009 - 10:45.

Es correcto que en el fichero PFILE de la STANDBY tengamos estos parmetro as: *.db_name='chicago'*.db_unique_name='boston'?Gracias.Mnica.

responderSi, es correcto. Si no seEnviado por undomain el Mi, 18/02/2009 - 10:58.

Si, es correcto.Si no se pone as, tendrias errores a la hora de que la StandBy intente aplciar los redolog offline.

responderGracias, entonces... por quEnviado por monica (no verificado) el Mi, 18/02/2009 - 11:30.

Gracias, entonces... por qu cuando intento "startup mount" la standby, me sale este error: " ORA-01103: database name Boston in control file is not Chicago". Te pas a ti tambin?

responderRecuerdo que me pas... yEnviado por undomain el Mi, 18/02/2009 - 11:35.

Recuerdo que me pas... y creo que fu algo de los CTL. Los has copiado de la Primary a la StandBy manteniendo los existentes de la StandBy?Revisalos... y tambien la parte de los pfile que hace la conversin de nombres y rutas: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\'

responderYo tambin creo que tiene queEnviado por monica (no verificado) el Mi, 18/02/2009 - 13:11.

Yo tambin creo que tiene que ver con los CTL. S, los he copiado de la Standby a la Primary, pero no mantenindolos, ya que se sobreescriben. Entonces, cules debera usar en la standby? Los que he copiado de la primary?Muchas gracias.

responderEn principio, genero unosEnviado por undomain el Mi, 18/02/2009 - 13:52.

En principio, genero unos nuevo CTLs con nombre distinto para que los use la StandBy. De esta manera te evitas sobreescribir. Es decir, no hay que eliminar los CTLs originales de la StandBy.

responderPor ahora todo bien, pero porEnviado por monica (no verificado) el Mi, 18/02/2009 - 16:35.

Por ahora todo bien, pero por ltimo: la standbye tiene que ser arrancada en modo mount o en modo open para que todo empiece a funcionar?Muchas gracias por tu ayuda.Me est siendo de gran utilidad.

responderpara arrancar laEnviado por undomain el Mi, 18/02/2009 - 16:59.

para arrancar la StandBy:

STARTUP MOUNTALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT;

por cierto... esto es la configuracin basica. Una vez que te funciona, lo mejor es un pequeo tunning. Si aades MAX_CONNECTIONS=5 a la cadena del LOG_ARCHIVE_DEST_2 en las dos bases de datos notaras muuuucha mejora en el rendimiento :)

responderDe momento no me va. El APPEnviado por monica (no verificado) el Mi, 18/02/2009 - 17:05.

De momento no me va. El APP se me queda a NO todo el rato, pero a ver si maana lo hago funcionar.Por cierto, tu Data Guard es para el trabajo o lo has hecho por probarlo?. Yo lo estoy probando generndome dentro de la misma maquina 2 bases de datos.Crees que puede haber algun problema por eso?Bueno, que pases una buena tarde :)Mo.

responderYo lo he montado como pruebaEnviado por undomain el Mi, 18/02/2009 - 17:09.

Yo lo he montado como prueba pero como parte de trabajo. Ahora mismo, sigo trasteando con el despues de unos problemas de red.

El que sean las dos BDD en la misma maquina puede que de algn error. Mira los puertos de los listeners y verifica que se ven entre ellos (que cada uno tenga las 2 BDD en el tnsnames). Revisa tambien las rutas, que no tengas algn lio con ellas.

Si tienes maquina de sobras, te recomendaria que utilizaras el VM-WARE para crearte una pequea red. Puedes poner una BDD en la maquina fisica y la otra en una maquina virtual (o las dos en maquinas virtuales si tienes suficiente maquina y espacio).

responderHola. Buenos das. No creesEnviado por monica (no verificado) el Jue, 19/02/2009 - 10:01.

Hola.Buenos das.No crees que en el INIT.ora de la standby *.LOG_ARCHIVE_CONFIG='DG_CONFIG=(chicago,boston)' est mal y deberia ser *.LOG_ARCHIVE_CONFIG='DG_CONFIG=(boston,chicago)'?

responderNo, es correcto as. Es laEnviado por undomain el Jue, 19/02/2009 - 10:28.

No, es correcto as. Es la configuracin que proporciona Oracle y la que estoy usando en la mia :PLos ficheros INIT son exactamente iguales a los que estoy usando (reemplazando los SID), salvo por algn tuning o ajuste para los retardos.

responderHola, cuando dices de hacerEnviado por Alicia (no verificado) el Vie, 27/03/2009 - 11:14.

Hola,cuando dices de hacer el backup, qu ficheros ests copiando exactamente? Todos los que se encuentran dentro de Oradata?Muchas gracias.Un saludo.

responderBasicamente eso... aunqueEnviado por undomain el Vie, 27/03/2009 - 11:24.

Basicamente eso... aunque depende de como lo tengas repartido.Lo que hay que hacer baclup y preplicar a la StandBy son:- Los DataBase File- Los Control File- Los Redo Online Log

responderPara evitar sorpresasEnviado por ungato (no verificado) el Mi, 10/06/2009 - 07:49.

Para evitar sorpresas desagradables, siempre que hagas un backup en fo, tienes que hacer bakcup de los archivos listados en las siguientes vistas: v$datafile, v$controlfile y v$logfile

Salu2

responderOK,entonces, copio todos losEnviado por Alicia (no verificado) el Vie, 27/03/2009 - 11:39.

OK,entonces, copio todos los files:*.DBF ->DataBase File,*.CTL->Control File ,*.LOG -> Redo Online LogPero, y si tengo ficheros para tablespaces, los copio tambien?

Gracias.

responderEso son los DBF ;)Enviado por undomain el Vie, 27/03/2009 - 12:04.

Eso son los DBF ;)

responderMuy interesante tuEnviado por Loles (no verificado) el Mi, 27/05/2009 - 09:20.

Muy interesante tu artculo... en breve probar a montar un Data Guard usando para ello dos mquinas virtuales sobre la misma mquina fsica.

Quera preguntarte un par de cosas: qu ocurre si la primary cae? es decir... si hubiera algn problema con esa mquina, de disco, de corrupcin de ficheros o lo que sea que provocara una cada de la base de datos se "conectan" solos los usuarios a la standbye de forma transparente para seguir trabajando? No s si habrs probado esto. Supongo que sera lo lgico, que en caso de caida de la primary actuara la standbye en su lugar y para restaurar la situacin inicial, una vez resueltos los problemas en la primary, para las dos bases de datos, hacer una copia de seguridad de la standbye en la primary y arrancarlas de nuevo.

La otra pregunta es: existe alguna forma de hacer el cambio de una por otra de forma controlada, algo as como un swich de base de datos? Por ejemplo... el sistema de rplica puede estar funcionando perfectamente pero en un momento dado podemos necesitar hacer alguna actualizacin de hardware en el equipo que contiene la primary (por ejemplo aadir mdulos de memoria)... existe una forma de decirle al sistema de replicacin que los usuarios deben conectarse a la standbye?

Gracias de antemano.

responderHola Loles, me alegro de queEnviado por undomain el Mi, 27/05/2009 - 09:35.

Hola Loles, me alegro de que te guste el post...

En la configuracin de aqui no hay nada sobre el FailSafe... es decir, si peta la primary, tendrias que levantar manualmente la StandBy como una BDD normal.Si que hay un proceso para configurar esto de manera automatica, pero esa parte no he podido probarla todavia... (ahora estoy sin mis maquinas virtuales).

Lamento no poder ayudarte en este caso :(

responderS, supongo que seraEnviado por Loles (no verificado) el Mi, 27/05/2009 - 09:56.

S, supongo que sera levantar manualmente la Standby y hacer algn cambio en la configuracin de los clientes para que accedan a esta base de datos o mejor an, cambiar directamente la IP de la Standbye por la de la Primary si las dos bases de datos tienen el mismo SID.

Despus de montar el Data Guard tendr que investigar la manera automtica de efectuar el cambio de base de datos... ya te contar.

Gracias igualmente.

responderTe agradecera mucho que meEnviado por undomain el Mi, 10/06/2009 - 08:18.

Te agradecera mucho que me contaras como te ha ido, yo ahora mismo no puedo ponerme con esto para ver como hacerlo :P

De todas maneras, segn como sea la aplicacin, tal vez sea suficiente con modificar el TNSNAMES del servidor en lugar de modificar todas las estaciones de trabajo.Si usas un servidor de nombres, lo tienes todava ms fcil...

Muchas gracias y suerte :)

responderTengo problemas con tuEnviado por scrapper (no verificado) el Lun, 06/07/2009 - 02:41.

Tengo problemas con tu tutorial, sigo todos los pasos y me da problemas al modificar el pfile y hacer que arranque, el error que me sale es el siguiente: ORA-00401: the value for parameter compatible is not supported by this release

tengo que usar tu version de oracle? ya que yo uso la 10.2.0.1.0

Te agradeceria mucho que me ayudes.

responderLogre corregir el error, peroEnviado por scrapper (no verificado) el Lun, 06/07/2009 - 03:39.

Logre corregir el error, pero no me sale la verificacion que haces al final....

como haces esto: En principio, genero unos nuevo CTLs con nombre distinto para que los use la StandBy. De esta manera te evitas sobreescribir.

responderCreo que tendrias queEnviado por undomain el Lun, 06/07/2009 - 08:03.

Creo que tendrias que reemplazar los CTL (previa copia).Piensa que los CTL son los que controlan o tienen informacion sobre los DBF, y si estos los reemplazas, salvo que sean exactamente iguales (cosa muy dificil) esos CTL no funcionarn bien.

Yo de ti reemplazaria los CTL de la STandBy por copias de la Primary, ademas del CTL propio que se crea para la StandBy.

Espero que te sea de ayuda....

responderAl ejecutar el comando SELECTEnviado por Tequila_Burp (no verificado) el Sb, 11/07/2009 - 08:14.

Al ejecutar el comando

SELECT SEQUENCE#, FIRST_TIME, NEXT_TIME FROM V$ARCHIVED_LOG ORDER BY SEQUENCE#;

en la primary, me aparece

SEQUENCE# FIRST_TI NEXT_TIM---------- -------- --------2 11/07/09 11/07/092 11/07/09 11/07/093 11/07/09 11/07/093 11/07/09 11/07/09

y en la standby el comando

SELECT SEQUENCE#,APPLIED FROM V$ARCHIVED_LOG ORDER BY SEQUENCE#;

SEQUENCE# APP---------- ---2 YES3 YES

eso esta bien????

responderSi, es correcto. En laEnviado por undomain el Sb, 11/07/2009 - 11:51.

Si, es correcto.

En la StansBy solo vers los archivers aplicados sobre si mismo, pero en la Primary vers tanto los propios como los de la StandBy.

Esto ademas sirve para controlar si los archivers se han replicado correctamente en todas la BDD conectandote solamente a una (la Primary).

responderHola, estoy teniendoEnviado por Pablo (no verificado) el Lun, 13/07/2009 - 21:20.

Hola, estoy teniendo problemas al querer levantar la primary con el nuevo pfile modificado.

startup pfile='$ORACLE_HOME/dbs/initARIZONA.ora'ORA-16024: parameter LOG_ARCHIVE_DEST_1 cannot be parsed

Te detallo como tengo el parametro en el pfile:LOG_ARCHIVE_DEST_1='LOCATION=/u02/app/oracle/oradata/ARIZONA/archives VALID_FOR=(ALL_LOGFILES,ALL_ROLES)DB_UNIQUE_NAME=ARIZONA'

responderA mi me da que es el espacioEnviado por undomain el Lun, 13/07/2009 - 22:23.

A mi me da que es el espacio que no hay entre separando el DB_UNIQUE_NAME del resto de la linea.Por si las moscas, yo lo pondria con saltos de linea. De la siguiente manera:

LOG_ARCHIVE_DEST_1='LOCATION=/u02/app/oracle/oradata/ARIZONA/archivesVALID_FOR=(ALL_LOGFILES,ALL_ROLES)DB_UNIQUE_NAME=ARIZONA'

Espero que as funcione :)

responderMuchas Gracias!, era eso,Enviado por Pablo (no verificado) el Mar, 14/07/2009 - 13:59.

Muchas Gracias!, era eso, ahora sigo con la instalacion, cualquier cosa te consulto....gracias nuevamente....

responderHola nuevamente, bueno, las 2Enviado por Pablo (no verificado) el Mar, 14/07/2009 - 15:52.

Hola nuevamente, bueno, las 2 bases las puedo levantar OK, tanto la primary como la standby, el tema es que no esta aplicando los redo ya que al hacer el select en la vista V$ARCHIVED_LOG no me trae ninguna fila.Las 2 instancias estan en el mismo sistema operativo, ya configure el tnsnames para las 2 instancias...chequee linea por linea los pfiles de las 2 bases....no se si me estoy comiendo algun paso.....

responderRecuerda que la Standby no seEnviado por undomain el Mar, 14/07/2009 - 15:58.

Recuerda que la Standby no se levanta con un startup, sino con:STARTUP MOUNTALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT;

La has levantado as?

responderSi Si, a la primary laEnviado por Pablo (no verificado) el Mar, 14/07/2009 - 17:16.

Si Si, a la primary la levante normalmente, a la standby la levante en modo mount y le hice el alter DATABASE....no se si el problema estara en que se encuentran las 2 bases en la misma VM...ahora estoy probando...de levantar una VM en mi notebook....pero no se si sera eso...Ya que estoy te hago una consulta: cuando vos decis"Partimos con que estn las dos BDD creadas. La BDD StandBy tendra que ser una instalacin completamente limpia, ya que eliminaremos el fichero de configuracin, los DataFiles y los Control files".te referis a que la base de datos standby, es una creacion estandard?? o yo puedo clonarla de la primary y despues usarla como standby???

responderHombre, la verdad es que enEnviado por undomain el Mar, 14/07/2009 - 18:31.

Hombre, la verdad es que en una misma mquina virtual no lo he probado...Si que puede ser eso, en ese caso no te puedo ayudar porque no se por donde puede fallar :PEn principio, con modificar las rutas y nombres lo suficiente para ajustarlo de una instalacin a otra tendra que ser suficiente.

Con la frase esa me refiero a que las dos BDD son instalaciones desde cero.De todas formas, lo imprtate es que las dos BDD sean exactamente iguales, as que si de StandBy usas un clon de la Primary no hay problema.

Por cierto, el DataGuard solo funciona con instalaciones Enterprise.

responderHola, te cuento, clone laEnviado por Pablo (no verificado) el Vie, 17/07/2009 - 17:38.

Hola, te cuento, clone la base primary en mi notebook, ambos SO son Suse Linux 10.1. Sigo sin poder hacer funcionar la replicacion, no me esta generando los archives log en el host de la standby.....ya configure los tnsnames y se ven cada una de las bases.....los archivos estan tal cual vos lo explicaste....pero no tengo forma, las 2 bases son Oracle enterprise 10.2.0.4...no se que puedo estar configurando mal.....la base Standby levanta con el archivo de control stdby.ctl .... pero no me aplica los switch de la primary en la standby.....lo hice paso a paso...y no hay forma....lo peor es que no me genera ningun error.....

responderPues es raro.... Mira en elEnviado por undomain el Vie, 17/07/2009 - 21:35.

Pues es raro....

Mira en el Alert de la Primary. Si no sale nada es que hay algo en el fichero de configuracin que no esta bien.Sin mas info no te puedo decir mas :P

responderHola!, bueno ahora estaEnviado por Pablo (no verificado) el Mi, 22/07/2009 - 17:18.

Hola!, bueno ahora esta funcionando, solo que me esta dejando la columna APP en "NO"....el problema ahi esta en los pfiles?

responderEn principio si... yo mirariaEnviado por undomain el Mi, 22/07/2009 - 17:19.

En principio si... yo miraria en el alert, a ver si te da alguna pista de que le esta pasando.

responderHola! Estoy creando un dataEnviado por Mat (no verificado) el Jue, 04/03/2010 - 17:00.

Hola!

Estoy creando un data guard y segui tus pasos, pero al intentar levantar la base de datos standby con el ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT me marca error:ORA-01665: control file is not a standby control file.Me pueden ayudar?Gracias.Saludos.

responderHola Mat, perdona que no teEnviado por undomain el Mar, 09/03/2010 - 08:42.

Hola Mat, perdona que no te respondiera antes.

El error que te sale es porque no tienes el CTL correcto en la standby.

Recuerda que antes de copiar los CTL de la primary a la standby se ha de crear uno especifico en la primary para que la standby funcione correctamente.

Revisa los pasos, porque me parece que te has saltado uno.

Ya me diras si te ha funcionado.

Salud!

responderSaludos... En la parte deEnviado porCincocielos(no verificado) el Jue, 18/03/2010 - 23:05.

Saludos...

En la parte de parametros para las bases en el init declaras varios DB_UNIQUE_NAME, eso es correcto? o para que se declaran varios?

responderFijate bien que solo hay unoEnviado por undomain el Vie, 19/03/2010 - 09:14.

Fijate bien que solo hay uno declarado.El otro forma parte del valor asignado al parametro LOG_ARCHIVE_DEST_2.Es decir:DB_UNIQUE_NAME='chicago'LOG_ARCHIVE_DEST_2='[...] DB_UNIQUE_NAME=boston'

Esto suele pasar con las comillas y los saltos de linea ;)

responderGenio, muy bueno elEnviado por Kinder (no verificado) el Mar, 06/07/2010 - 14:36.

Genio, muy bueno el posteo.Consulta, la base Standby (secundaria), puede usarse como base de consulta?Saludos

responder