Documenti di Didattica
Documenti di Professioni
Documenti di Cultura
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
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
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.
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
responder
responder
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
responder
responder
responder
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???
responder
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
responder
Si, es correcto. Si no se
Si, es correcto.
Si no se pone as, tendrias errores a la hora de que la StandBy intente
aplciar los redolog offline.
responder
responder
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 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 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 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
responder
responder
responder
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
responder
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
responder
responder
responder
responder
Muy interesante tu
responder
responder
responder
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
responder
responder
responder
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
responder
A mi me da que es el espacio
Enviado por undomain el Lun, 13/07/2009 - 22:23.
responder
Muchas Gracias!, era eso, ahora sigo con la instalacion, cualquier cosa te
consulto....gracias nuevamente....
responder
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.
responder
responder
Si Si, a la primary la
Enviado por Pablo (no verificado) el Mar, 14/07/2009 - 17:16.
responder
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
responder
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
responder
responder
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
responder
Saludos... En la parte de
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
responder
responder