Está en la página 1de 26

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 del MetaLink(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 Primary
STANDBY: 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 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 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 IMMEDIATE
SQL> STARTUP
Ya 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 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 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 existentes
SQL> SELECT * FROM V$LOGFILE;
-- Tamao de cada uno de ellos
SQL> 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 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 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\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 varan en funcin de la configuracin 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\adu
mp'
*.background_dump_dest='C:\oracle\product\10.2.0\admin\chicag
o\bdump'
*.compatible='10.2.0.3.0'
*.control_files='C:\oracle\product\10.2.0\oradata\chicago\con
trol01.ctl','C:\oracle\product\10.2.0\oradata\chicago\control
02.ctl','C:\oracle\product\10.2.0\oradata\chicago\control03.c
tl'
*.core_dump_dest='C:\oracle\product\10.2.0\admin\chicago\cdum
p'
*.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\udum
p'
*.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> 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 sern 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\chica
go\','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\adum
p'
*.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\stdb
y.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\chi
cago\','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 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 ORCLA


SQL>
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 string

dg_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 configuration
Error: 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

Configuration
Name: DBSID_DG
Enabled: NO
Protection Mode: MaxPerformance
Databases:
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
Configuration
Name: DBSID_DG
Enabled: NO
Protection Mode: MaxPerformance
Databases:
ORCLA - Primary database
ORCLB - 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
Configuration
Name: DBSID_DG
Enabled: YES
Protection Mode: MaxPerformance
Databases:
ORCLA - Primary database
ORCLB - 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 Production
With 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 bytes
Fixed Size 1322520 bytes
Variable Size 400282088 bytes
Database Buffers 1174405120 bytes
Redo Buffers 1048576 bytes
Database 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 ORACLE

Please 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 ha

Enviado por Pedro (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?

responder

hehehehe.... dudo que en


Enviado 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 ;)

responder

En rete no, pero yo me fui

Enviado por Pedro (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 logs
En 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 :)

responder

Vaya por fin puedo escribir


Enviado por Dame 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)

responder

Una consulta el Hardware y

Enviado 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

responder

El SO si, el hardware no. Es


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

responder

Hola, 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\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'"
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.

responder

UO! Has encontrado una

Enviado por undomain el Mar, 17/02/2009 - 17:27.

UO!
Has encontrado una "pequea" errata:
CHICAGO es la Prymary
BOSTON es la StandBy
Muchas gracias por ver el dato.... ahora mismo lo arreglo :P
Perdon por el lapsus T_T

responder

Es correcto que en el fichero


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

responder

Si, es correcto. Si no se

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

responder

Gracias, entonces... por qu


Enviado 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?

responder

Recuerdo que me pas... y


Enviado 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\'

responder

Yo tambin creo que tiene que

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

responder

En principio, genero unos


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

responder

Por ahora todo bien, pero por

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

para arrancar la

responder

Enviado por undomain el Mi, 18/02/2009 - 16:59.

para arrancar la StandBy:


STARTUP MOUNT
ALTER 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 :)

responder

De momento no me va. El APP


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

responder

Yo lo he montado como prueba

Enviado 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).

responder

Hola. Buenos das. No crees

Enviado 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)'?

responder

No, es correcto as. Es la


Enviado 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 :P
Los ficheros INIT son exactamente iguales a los que estoy usando
(reemplazando los SID), salvo por algn tuning o ajuste para los
retardos.

responder

Hola, cuando dices de hacer

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

responder

Basicamente eso... aunque


Enviado 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

responder

Para evitar sorpresas

Enviado 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

responder

OK,entonces, copio todos los

Enviado 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 Log
Pero, y si tengo ficheros para tablespaces, los copio tambien?
Gracias.

responder

Eso son los DBF ;)


Enviado por undomain el Vie, 27/03/2009 - 12:04.

Eso son los DBF ;)

responder

Muy interesante tu

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

responder

Hola Loles, me alegro de que

Enviado 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 :(

responder

S, supongo que sera


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

responder

Te agradecera mucho que me

Enviado 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 :)

responder

Tengo problemas con tu

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

responder

Logre corregir el error, pero


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

responder

Creo que tendrias que

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

responder

Al ejecutar el comando SELECT

Enviado 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/09
2 11/07/09 11/07/09
3 11/07/09 11/07/09
3 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 YES
3 YES
eso esta bien????

responder

Si, es correcto. En la
Enviado 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).

responder

Hola, estoy teniendo

Enviado 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'

responder

A mi me da que es el espacio
Enviado 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
/archives
VALID_FOR=(ALL_LOGFILES,ALL_ROLES)
DB_UNIQUE_NAME=ARIZONA'
Espero que as funcione :)

responder

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

responder

Hola nuevamente, bueno, las 2


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

responder

Recuerda que la Standby no se

Enviado por undomain el Mar, 14/07/2009 - 15:58.

Recuerda que la Standby no se levanta con un startup, sino con:


STARTUP MOUNT
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE
DISCONNECT;
La has levantado as?

responder

Si Si, a la primary la
Enviado 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???

responder

Hombre, la verdad es que en

Enviado 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 :P
En 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.

responder

Hola, te cuento, clone la

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

responder

Pues es raro.... Mira en el


Enviado 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

responder

Hola!, bueno ahora esta

Enviado 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?

responder

En principio si... yo miraria


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

responder

Hola! Estoy creando un data

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

responder

Hola Mat, perdona que no te


Enviado 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!

responder

Saludos... En la parte de

Enviado por Cincocielos (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?

responder

Fijate bien que solo hay uno

Enviado 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 ;)

responder

Genio, muy bueno el


Enviado 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