Estos pasos se encuentran en el manual de oracle online que se puede buscar en su web o atravez de esta direccion:
http://download.oracle.com/docs/cd/B19306_01/server.102/b14239/toc.htm
Requisitos:
2 maquinas virtuales montadas con VirtualBOX o VMWARE con Windows 2003 Standar Edition. (aunque si tienen la enterprise es mejor por el cluster).
Oracle 10.2.0.4 Enterprise Edition.
La SID primaria será: BOSTON
La SID en Standby será: CHICAGO
Atencion: Todos los comandos que se muestran aqui son con privilegios SYSDBA.
Explicaciones y significados:
SPFILE: Fichero de inicio en binario (NO se puede modificar mediante un editor de texto). Su nombre suele ser SPFILE.ORA (P.E.: SPFILEboston.ORA)
PFILE: Fichero de inicio en texto (se ha de modificar mediante un editor de texto). Su nombre suele ser INIT.ORA (P.E.: INITboston.ORA)
La creación de las BDD se efectua mediante la instalación por defecto, no es necesario modificar los parámetros ni rutas.
Estos pasos sirven tanto para crear un DataGuard con una BDD nueva como con una existente. En el caso de hacerlo sobre una BDD con información útil es muy importante que antes hagas una copia de seguridad de todos los objetos importantes (DataFile, SPFile/PFile, Logs, Arc, etc...).
Partiremo con que están las dos BDD creadas. La BDD StandBy tendría que ser una instalación completamente limpia, ya que eliminaremos el fichero de configuración, los DataFiles y los Control files.
Lo primero que tendríamos que asegurarnos es que existe visibilidad entre la PRIMARY y la STANDBY.
Para eso tenemos que configurar el TNSNAMES de cada servidor añadiendo la entrada que corresponda (es decir, añadir la PRIMARY en el TNSNAMES de la STANDBY y viceversa).
Verifica que se ven mutuamente haciendo un TNSPING a las dos BDD desde cada uno de los servidores.
Personalmente, prefiero realizar la primera configuración (sobre la PRIMARY) mediante SPFILE. Esto nos permite asegurarnos que las modificaciones de los parámetros de inicio se ha hecho correctamente sin necesidad de reiniciar la BDD (aunque requiera reiniciar la BDD para que se apliquen las modificaciones), o como mínimo que el parámetro que hemos modificado es correcto.
En el caso de que la PRIMARY se inicie mediante PFILE, lo configuraremos temporalmente para que inicie mediante SPFILE.
Para crear el SPFILE lanzamos la siguiente instrucción:
SQL> CREATE SPFILE FROM PFILE;
Después, renombramos el PFILE (nos servirá de backup por si algo sale mal) y reiniciaremos la PRIMARY:
SQL> SHUTDOWN IMMEDIATE
SQL> STARTUP
Ya tenemos la PRIMARY arrancada con el SPFILE. Ahora, todas las modificaciones de parámetros se han de hacer mediante ALTER.
Para empezar, necesitamos que la PRIMARY tenga activado el modo ARCHIVELOG. Para ello, lanzamos los siguientes comandos:
SQL> ALTER SYSTEM SET LOG_ARCHIVE_DEST_1 = 'LOCATION=C:\oracle\product\10.2.0\ARCH' SCOPE=SPFILE;
SQL> ALTER SYSTEM SET LOG_ARCHIVE_FORMAT='%t_%s_%r.dbf' SCOPE=SPFILE;
SQL> SHUTDOWN IMMEDIATE
SQL> STARTUP MOUNT
SQL> ALTER DATABASE ARCHIVELOG;
SQL> ALTER DATABASE OPEN;
Es recomendable que tener activado el modo FORCE LOGGING. No es imprescindible, pero si recomendado, al menos que esté el máximo tiempo posible activado.
Para ello, lanzamos el siguiente comando:
SQL> ALTER DATABASE FORCE LOGGING;
Ahora tenemos que crear en la PRIMARY los redolog que usará la STANDBY. Para ello, identificamos primero los que hay con los siguientes comandos...
-- Redolog existentes
SQL> SELECT * FROM V$LOGFILE;
-- Tamaño de cada uno de ellos
SQL> SELECT BYTES/1024/1024 MB FROM V$LOG;
...y creamos nuevos ficheros de standby del mismo tamaño y con un número de grupo secuencial (por defecto, Oracle crea 3 ficheros de 50MB) :
SQL> ALTER DATABASE ADD STANDBY LOGFILE GROUP 4 ('c:\oracle\product\10.2.0
\oradata\chicago\redosb01.log') SIZE 50M;
SQL> ALTER DATABASE ADD STANDBY LOGFILE GROUP 5 ('c:\oracle\product\10.2.0\oradata\chicago\redosb02.log') SIZE 50M;
SQL> ALTER DATABASE ADD STANDBY LOGFILE GROUP 6 ('c:\oracle\product\10.2.0\oradata\chicago\redosb03.log') SIZE 50M;
Ya tenemos la PRIMARY pre-configurada.
Para continuar, tenemos que para la PRIMARY (y la STANDBY, si la teníamos arrancada):
SQL> SHUTDOWN IMMEDIATE
Con las dos BD paradas hacemos un backup de los DataFiles, Redolog Online y Standby logs de la PRIMARY y los restauramos sobre la STANDBY.
Oracle recomienda utilizar el RMAN, pero yo he realizado una copia normal y corriente de los ficheros a través de la red.
IMPORTANTE: NO INICIAREMOS NINGUNA BDD. ¡ESPECIALMENTE LA STANDBY!
Ahora, desde la PRIMARY generaremos un fichero de control para la STANDBY con la siguiente secuencia de comandos:
SQL> STARTUP MOUNT;
SQL> ALTER DATABASE CREATE STANDBY CONTROLFILE AS 'c:\stdby.ctl';
SQL> ALTER DATABASE OPEN;
Copiamos este fichero de control en el servidor de la STANDBY (en nuestro caso: C:\oracle\product\10.2.0\oradata\boston).
Copiamos también el fichero de password de la PRIMARY en la STANDBY en la misma ruta donde se encuentra en la PRIMARY (en nuestro caso: C:\oracle\product\10.2.0\db_1
\database\PWDchicago.ora).
Ahora generamos un PFILE con todas las modificaciones que hemos hecho en la PRIMARY con el siguiente comando (este fichero lo podremos modificar posteriormente mas cómodamente que el SPFILE):
SQL> CREATE PFILE FROM SPFILE;
Una vez que tenemos el PFILE, renombraremos el SPFILE para que no lo use en el arranque y lo guardaremos como backup.
Modificaremos los siguientes campos del PFILE (si hay alguno que no existe, lo creamos):
db_name='chicago'
db_unique_name='chicago'
LOG_ARCHIVE_CONFIG='DG_CONFIG=(chicago,boston)'
LOG_ARCHIVE_DEST_1='LOCATION=C:\oracle\product\10.2.0\ARCH
VALID_FOR=(ALL_LOGFILES,ALL_ROLES)
DB_UNIQUE_NAME=chicago'
LOG_ARCHIVE_DEST_2='SERVICE=boston
VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE)
DB_UNIQUE_NAME=boston'
LOG_ARCHIVE_DEST_STATE_1=ENABLE
LOG_ARCHIVE_DEST_STATE_2=ENABLE
LOG_ARCHIVE_MAX_PROCESSES=30
log_archive_format='%t_%s_%r.dbf'
STANDBY_FILE_MANAGEMENT=AUTO
STANDBY_ARCHIVE_DEST='C:\oracle\product\10.2.0\ARCH'
FAL_SERVER='boston'
FAL_CLIENT='chicago'
El PFILE quedará de la siguiente manera (la cantidad de campos y sus valores varían en función de la configuración previa de la BDD):
chicago.__db_cache_size=197132288
chicago.__java_pool_size=4194304
chicago.__large_pool_size=4194304
chicago.__shared_pool_size=83886080
chicago.__streams_pool_size=0
*.audit_file_dest='C:\oracle\product\10.2.0\admin\chicago\adump'
*.background_dump_dest='C:\oracle\product\10.2.0\admin\chicago\bdump'
*.compatible='10.2.0.3.0'
*.control_files='C:\oracle\product\10.2.0\oradata\chicago\control01.ctl','C:\oracle\product\10.2.0\oradata\chicago\control02.ctl','C:\oracle\product\10.2.0\oradata\chicago\control03.ctl'
*.core_dump_dest='C:\oracle\product\10.2.0\admin\chicago\cdump'
*.db_block_size=8192
*.db_domain=''
*.db_file_multiblock_read_count=16
*.db_name='chicago'
*.db_unique_name='chicago'
*.dispatchers='(PROTOCOL=TCP) (SERVICE=chicagoXDB)'
*.job_queue_processes=10
*.LOG_ARCHIVE_CONFIG='DG_CONFIG=(chicago,boston)'
*.LOG_ARCHIVE_DEST_1='LOCATION=C:\oracle\product\10.2.0\ARCH
VALID_FOR=(ALL_LOGFILES,ALL_ROLES)
DB_UNIQUE_NAME=chicago'
*.LOG_ARCHIVE_DEST_2='SERVICE=boston
VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE)
DB_UNIQUE_NAME=boston'
*.LOG_ARCHIVE_DEST_STATE_1=ENABLE
*.LOG_ARCHIVE_DEST_STATE_2=ENABLE
*.log_archive_format='%t_%s_%r.dbf'
*.LOG_ARCHIVE_MAX_PROCESSES=30
*.STANDBY_FILE_MANAGEMENT=AUTO
*.STANDBY_ARCHIVE_DEST='C:\oracle\product\10.2.0\ARCH'
*.open_cursors=300
*.pga_aggregate_target=96468992
*.processes=150
*.remote_login_passwordfile='EXCLUSIVE'
*.sga_target=290455552
*.undo_management='AUTO'
*.undo_tablespace='UNDOTBS1'
*.user_dump_dest='C:\oracle\product\10.2.0\admin\chicago\udump'
*.FAL_SERVER='boston'
*.FAL_CLIENT='chicago'
Ese mismo fichero lo usaremos para la STANDBY. La idea es copiar el fichero PFILE a la STANDBY y posteriormente modificar los campos necesarios.
Ahora iniciamos la PRIMARY confirmando que todos los datos están bien (si hay alguno mal, nos mostrará un error al arrancar).
IMPORTANTE: TODAVIA NO INICIAREMOS LA STANDBY!!!!
SQL> STARTUP
Ya tenemos la PRIMARY completamente configurada y preparada. Ha llegado la hora de dedicarnos a la STANBY.
Partiendo del PFILE de la PRIMARY, modificamos (o creamos desde el principio) el PFILE de la STANDBY modificando los datos correspondientes. En este caso, los datos serán los siguientes:
db_name='chicago'
db_unique_name=boston
control_files='C:\oracle\product\10.2.0\oradata\boston\stdby.ctl'
LOG_ARCHIVE_CONFIG='DG_CONFIG=(chicago,boston)'
LOG_ARCHIVE_DEST_1='LOCATION=C:\oracle\product\10.2.0\ARCH
VALID_FOR=(ALL_LOGFILES,ALL_ROLES)
DB_UNIQUE_NAME=boston'
LOG_ARCHIVE_DEST_2='SERVICE=chicago LGWR ASYNC
VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE)
DB_UNIQUE_NAME=chicago'
LOG_ARCHIVE_DEST_STATE_1=ENABLE
LOG_ARCHIVE_DEST_STATE_2=ENABLE
LOG_ARCHIVE_MAX_PROCESSES=30
log_archive_format='%t_%s_%r.dbf'
STANDBY_FILE_MANAGEMENT=AUTO
STANDBY_ARCHIVE_DEST='C:\oracle\product\10.2.0\ARCH'
FAL_SERVER=chicago
FAL_CLIENT=boston
DB_FILE_NAME_CONVERT='chicago','boston'
LOG_FILE_NAME_CONVERT='C:\oracle\product\10.2.0\oradata\chicago\','C:\oracle\product\10.2.0\oradata\boston\'
IMPORTANTE: SI PARTES DEL PFILE DE LA PRIMARY RECIERDA MODIFICAR EL NOMBRE DE LA BDD EN TODAS LAS LINEAS O NO FUNCIONARÁ CORRECTAMENTE.
El fichero PFILE de la STANDBY quedará de la siguiente manera:
boston.__db_cache_size=197132288
boston.__java_pool_size=4194304
boston.__large_pool_size=4194304
boston.__shared_pool_size=83886080
boston.__streams_pool_size=0
*.audit_file_dest='C:\oracle\product\10.2.0\admin\boston\adump'
*.background_dump_dest='C:\oracle\product\10.2.0\admin\boston\bdump'
*.compatible='10.2.0.3.0'
*.control_files='C:\oracle\product\10.2.0\oradata\boston\stdby.ctl'
*.core_dump_dest='C:\oracle\product\10.2.0\admin\boston\cdump'
*.db_block_size=8192
*.db_domain=''
*.db_file_multiblock_read_count=16
*.db_name='chicago'
*.db_unique_name='boston'
*.dispatchers='(PROTOCOL=TCP) (SERVICE=bostonXDB)'
*.job_queue_processes=10
*.LOG_ARCHIVE_CONFIG='DG_CONFIG=(chicago,boston)'
*.LOG_ARCHIVE_DEST_1='LOCATION=C:\oracle\product\10.2.0\ARCH
VALID_FOR=(ALL_LOGFILES,ALL_ROLES)
DB_UNIQUE_NAME=boston'
*.LOG_ARCHIVE_DEST_2='SERVICE=chicago LGWR ASYNC
VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE)
DB_UNIQUE_NAME=chicago'
*.LOG_ARCHIVE_DEST_STATE_1=ENABLE
*.LOG_ARCHIVE_DEST_STATE_2=ENABLE
*.log_archive_format='%t_%s_%r.dbf'
*.LOG_ARCHIVE_MAX_PROCESSES=30
*.STANDBY_FILE_MANAGEMENT=AUTO
*.STANDBY_ARCHIVE_DEST='C:\oracle\product\10.2.0\ARCH'
*.open_cursors=300
*.pga_aggregate_target=96468992
*.processes=150
*.remote_login_passwordfile='EXCLUSIVE'
*.sga_target=290455552
*.undo_management='AUTO'
*.undo_tablespace='UNDOTBS1'
*.user_dump_dest='C:\oracle\product\10.2.0\admin\boston\udump'
*.FAL_SERVER='chicago'
*.FAL_CLIENT='boston'
*.DB_FILE_NAME_CONVERT='chicago','boston'
*.LOG_FILE_NAME_CONVERT='C:\oracle\product\10.2.0\oradata\chicago\','C:\oracle\product\10.2.0\oradata\boston\'
Es hora de iniciar la STANDBY. Para ello, utilizaremos los siguientes comandos:
SQL> STARTUP MOUNT
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT;
Ya tenemos el DataGuard montado, pero ¿como sabemos que realmente se están replicando los logs?
Pues bien, para verificar la transferencia de los LOGS, seguiremos los siguientes pasos:
1.- Listamos los LOGS existentes en la STANDBY:
SQL> SELECT SEQUENCE#, FIRST_TIME, NEXT_TIME FROM V$ARCHIVED_LOG ORDER BY SEQUENCE#;
2.- Forzamos el cambio de LOG en la PRIMARY:
SQL> ALTER SYSTEM SWITCH LOGFILE;
3.- Verificamos que se han replicado y aplicado los LOGS en la STANDBY (la columna
APP tiene que mostrar YES):
SQL> SELECT SEQUENCE#,APPLIED FROM V$ARCHIVED_LOG ORDER BY SEQUENCE#;
Si aparecen la misma cantidad de registros en la PRIMARY que en la STANDBY, y la columna APP tiene YES en todos los registros, significa que nuestro DataGuard esta completamente operativo.
Has de tener en cuenta que la transferencia de los LOGS y su aplicación no es instantánea, depende la velocidad de red y de disco (si los LOG son muy grandes). Si no te salen los logs, o te salen con la columna APP a NO, tomate antes unos minutos de descanso y luego verifícalo de nuevo.
En el caso de que no se transfieran los LOGS o no se apliquen, revisa todos los valores de los PFILE.
Por último, si queremos que nuestras BDD inicien con SPFILE solo tenemos que lanzar el siguiente comando en cada una de ellas:
SQL> CREATE SPFILE FROM PFILE;
Mas informacion aqui:
http://www.undomain.es/node/163
0 comentarios:
Publicar un comentario