sábado, 18 de mayo de 2013

Como crear un Standby Fisico con RMAN Active Duplicate en 11.2.0.3

Este tema ha sido escrito por otros administradores de bases de datos, pero quería que estuviera disponible en español, y sobre todo porque en los sitios que he buscado de cómo se hizo esto, o bien no son muy claros los pasos que se hicieron y asume que ya sabes lo que estás haciendo, o en realidad ejecutan los pasos demasiado rápido sin dar alguna explicación.

Antes de continuar, sólo te quiero decir de que se trata de una entrada larga, y no digas que no te lo advertí :)

Así que para continuar y antes de entrar en cualquiera de los pasos en la creación de tu base de datos Standby Fisica, hay algunos términos que necesitas saber de antemano, que te ayudará a entender mejor el entorno y lo que DataGuard está haciendo, en lugar de copiar una serie de pasos. Estas son sólo las definiciones en la documentación de Oracle, pero te evitarás de ir a buscar por todas partes para entenderlas.

LOG_ARCHIVE_DEST_n .- Controla diferente aspectos de como los servicios de transporte de los Redo, transfiere los datos de redo de la base de datos primaria
a su destino de standby. Este parámetro tiene varios atributos que son necesarios para configurar tu ambiente de Dataguard, aquí nada mas voy a mencionar
los que son críticos para esto:

  • ASYNC (Default) .- Los datos generados de redo por transacción no tienen que haber sido recibidos en cada uno de los destinos habilitados antes de cometerse ésta.
    o
  • SYNC .-Los datos generados de redo por transacción tienen que haber sido recibidos en cada uno de los destinos habilitados antes de cometerse ésta.
  • AFFIRM y NOAFFIRM .- Controla si un destino de transporte de redo acusa de recibo los datos de redo antes o despues de escribir estos al standby redo log.
  • DB_UNIQUE_NAME .-  Especifica un nombre unico para la base de datos que va a recibir los datos de redo. Tienes que especificar este nombre, no hay un valor por default.
  • VALID_FOR .- Identifica cuando el servicio de transporte de redo puede transmitir datos de redo a los destinos, esto se basa en los siguiente factores:
    • redo_log_type .-Si los archivos de Online Redo Log, Standby Redo log o ambos este siendo archivados en la base de datos destinada.
    • database_role .-Si el rol de la base de datos es la Primaria o la base de datos en Stanby.

FAL_SERVER .- Especifica el servidor FAL (Fetch Archive Log) para un base de datos en Standby. Este valor es un nombre de servicio de Oracle Net.
FAL_CLIENT .- Especifica el nombre del cliente FAL (Fetch Archive Log) que es usado por el servicio FAL, que este es configurado a través del parametro FAL_SERVER para referir al cliente.Este valor es un nombre de servicio de Oracle Net.

LOG_ARCHIVE_CONFIG .- Este parámetro habilita o deshabilita el envió de redo los a destinos remotos y el recipiente de estos. Este parámetro tiene varios atributos, aquí te menciono el mas importante para este ejercicio:

  • DG_CONFIG .- Especifica hasta 30 nombres de bases de datos únicas (Definidas con el parámetro DB_UNIQUE_NAME) para todas las bases de datos en tu configuración de Data Guard.

Ufff , esto estuvo largo, y si te interesa saber mas, lo puedes encontrar en la documentación oficial de Oracle 11gR2 . Pero ahora que quitamos las definiciones de encima,  vamos a empezar con la configuracion de nuestra Base de Datos Standby Fisica.

Para este ejercicio tengo lo siguiente :

Primary : testgg1   Server : dlabvm13
Standby : testgg2   Server : dlabvm14
DB_NAME: testgg1

Lo primero que tienes que hacer, es encontrar la ubicación en donde tienes los Online Redo Logs, Datafiles que residen en la base de datos primaria y donde van a residir  estos en la base de datos Standby para que puedas establecer los parámetros LOG_FILE_NAME_CONVERT y DB_FILE_NAME_CONVERT correctamente. Asegúrate de que estos directorios y que tienes el espacio necesario para contener la base de datos primaria, si no tienes este espacio en el servidor de la Standby, entonces ¿cuál es el caso de continuar? :)

A continuación, asegúrate de que estás en modo archivelog y que force logging está activado en tu base de datos primaria.

Si tu base de datos no está en modo archivelog, haz lo siguiente:

SQL> shutdown immediate
Database closed.
Database dismounted.
ORACLE instance shut down.

SQL> startup mount
ORACLE instance started.

Total System Global Area 534462464 bytes
Fixed Size 2230072 bytes
Variable Size 163580104 bytes
Database Buffers 364904448 bytes
Redo Buffers 3747840 bytes
Database mounted.

SQL> alter database archivelog;

Database altered.

SQL> alter database open;

Database altered.

SQL> alter database force logging;

Database altered.

SQL> select log_mode,force_logging from v$database;

LOG_MODE FOR
------------ ---
ARCHIVELOG YES


Ahora que estamos en modo archivelog y establecida force logging para la base de datos primaria, asegúrate de que las entradas del  Listener/Tns están configurados correctamente y que puedes hacer un  tnsping ambos desde el servidor de la Primaria / Standby.

En esto si no voy a entrar a detalle pero puedes checar la entrada de Kamran en el blog de Pythian (Paso 2) para ver como se hace esto. Si tienes una pregunta de como se hace esto, no dudes en hacermela.

Pero el resultado en ambos servidores debe de ser algo similar a esto:


oracle@dlabvm13.dlab.pythian.com [testgg1] /home/oracle/bin
oracle $ tnsping testgg1

TNS Ping Utility for Linux: Version 11.2.0.3.0 - Production on 14-MAY-2013 09:44:34
Copyright (c) 1997, 2011, Oracle. All rights reserved.
Used parameter files:
/u01/app/oracle/product/11.2.0/dbhome_1/network/admin/sqlnet.ora

Used TNSNAMES adapter to resolve the alias

Attempting to contact (DESCRIPTION = (ADDRESS_LIST = (ADDRESS = (PROTOCOL = TCP)(HOST = dlabvm13.dlab.pythian.com)(PORT = 1521))) (CONNECT_DATA = (SERVER = DEDICATED) (SERVICE_NAME = testgg1)))

OK (0 msec)

oracle@dlabvm13.dlab.pythian.com [testgg1] /home/oracle/bin
oracle $ tnsping testgg2
TNS Ping Utility for Linux: Version 11.2.0.3.0 - Production on 14-MAY-2013 09:44:40
Copyright (c) 1997, 2011, Oracle. All rights reserved.

Used parameter files:
/u01/app/oracle/product/11.2.0/dbhome_1/network/admin/sqlnet.ora

Used TNSNAMES adapter to resolve the alias

Attempting to contact (DESCRIPTION = (ADDRESS_LIST = (ADDRESS = (PROTOCOL = TCP)(HOST = dlabvm14.dlab.pythian.com)(PORT = 1521))) (CONNECT_DATA = (SERVER = DEDICATED) (SERVICE_NAME = testgg2)))

OK (10 msec)

A continuación, debes crear y replicar el archivo de contraseñas de la base de datos primaria que se encuentra en $ORACLE_HOME/dbs y cambiarle el nombre para que refleje el nombre de la Standby. El nombre del archivo de la contraseña de la Standby debe coincidir con el ORACLE_SID utilizado, no el DB_NAME.


oracle@dlabvm13.dlab.pythian.com [testgg1] /u01/app/oracle/product/11.2.0/dbhome_1/dbs
oracle $ orapwd file=orapwtestgg1 password=test entries=5

oracle@dlabvm13.dlab.pythian.com [testgg1] /u01/app/oracle/product/11.2.0/dbhome_1/dbs
oracle $ scp orapwtestgg1 dlabvm14:/u01/app/oracle/product/11.2.0/dbhome_1/dbs/orapwtestgg2

orapwtestgg1 100% 2048 2.0KB/s 00:00

Ahora que has creado el archivo de contraseñas, vamos a configurar el archivo de parámetros init para la base de datos Primaria, como se puede ver al final de este ejemplo, son los parámetros que explicamos y definimos al principio de esta entrada.

SQL> !cat dg.ora
*.audit_file_dest='/u01/app/oracle/oradata/dump/testgg1/adump'
*.audit_trail='db'
*.compatible='11.2.0'
*.control_files='/u01/app/oracle/oradata/testgg1/control/control01.ctl','/u01/app/oracle/oradata/testgg1/control/control02.ctl'
*.db_block_size=8192
*.db_cache_size=128M
*.db_domain=''
*.db_name='testgg1'
*.db_recovery_file_dest='/u01/app/oracle/fast_recovery_area'
*.db_recovery_file_dest_size=2G
*.db_unique_name='testgg1'
*.diagnostic_dest='/u01/app/oracle/oradata/dump/testgg1'
*.log_archive_dest_1='location=use_db_recovery_file_dest valid_for=(ALL_LOGFILES,ALL_ROLES) DB_UNIQUE_NAME=testgg1'
*.log_archive_dest_2='SERVICE=testgg2 ASYNC valid_for=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=testgg2'
*.log_archive_dest_state_1='enable'
*.log_archive_dest_state_2='enable'
*.open_cursors=300
*.pga_aggregate_target=128M
*.processes=150
*.remote_login_passwordfile='EXCLUSIVE'
*.sga_target=512M
testgg11.UNDO_TABLESPACE='UNDOTBS1'
FAL_SERVER=testgg2;
FAL_CLIENT=testgg1;
DB_FILE_NAME_CONVERT='/u01/app/oracle/oradata/testgg2/TESTGG2/datafile/','/u01/app/oracle/oradata/testgg1/TESTGG1/datafile/'
LOG_FILE_NAME_CONVERT='/u01/app/oracle/oradata/testgg2/TESTGG2/onlinelog/','/u01/app/oracle/oradata/testgg1/TESTGG1/onlinelog/'
LOG_ARCHIVE_CONFIG='DG_CONFIG=(testgg1,testgg2)'

Una de las cosas mas padres o cheveres acerca de este método, es que casi todo el trabajo que haré será en el servidor de base de datos Primaria,  lo único que tengo que hacer en el servidor de la base de datos Standby es crear las ubicaciones en donde van a residir mis archivos de diagnóstico / redo / datafiles / control files y verificar la conectividad entre el servidor Primario y el Standby y solamente arrancar la instancia de nuestra base de datos Standby, que es nuestro siguiente paso.

Lo que voy a hacer ahora es establecer el ORACLE_SID, ORACLE_HOME y ORACLE_BASE para la instancia Standby y abrirla con las mínimas  opciones posibles:


oracle@dlabvm14.dlab.pythian.com [testgg2] /home/oracle/bin
oracle $ export ORACLE_HOME="/u01/app/oracle/product/11.2.0/dbhome_1"

oracle@dlabvm14.dlab.pythian.com [testgg2] /home/oracle/bin
oracle $ export ORACLE_BASE=/u01/app/oracle

oracle@dlabvm14.dlab.pythian.com [testgg2] /home/oracle/bin
oracle $ export ORACLE_SID=testgg2

oracle@dlabvm14.dlab.pythian.com [testgg2] /home/oracle/bin
oracle $ cat dg.ora

DB_NAME=testgg1
DB_UNIQUE_NAME=testgg2
DB_BLOCK_SIZE=8192

oracle@dlabvm14.dlab.pythian.com [testgg2] /home/oracle/bin
oracle $ sqlplus
SQL*Plus: Release 11.2.0.3.0 Production on Tue May 14 09:53:30 2013
Copyright (c) 1982, 2011, Oracle.  All rights reserved.
Enter user-name: /as sysdba

Connected to an idle instance.

SQL> startup nomount pfile='/home/oracle/bin/dg.ora';
ORACLE instance started.
Total System Global Area  238034944 bytes
Fixed Size              2227136 bytes
Variable Size            180356160 bytes
Database Buffers        50331648 bytes
Redo Buffers              5120000 bytes

SQL> exit

Disconnected from Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - 64bit Production

With the Partitioning, OLAP, Data Mining and Real Application Testing options

Ahora vamos a volver al servidor de la base de datos Primaria, donde lo siguiente que voy a hacer es agregar los Standby Redo Logs, en mi caso he creado dos con el mismo tamaño que los Online Redo Logs que tengo en la Primaria.


SQL> select instance_name,host_name from v$instance;

INSTANCE_NAME HOST_NAME
---------------- ----------------------------------------------------------------
testgg1 dlabvm13.dlab.pythian.com

SQL> select name from v$database;

NAME
---------
TESTGG1

SQL> select GROUP#,THREAD#,MEMBERS,BYTES FROM V$LOG;

GROUP# THREAD# MEMBERS BYTES
---------- ---------- ---------- ----------
1 1 1 104857600
2 1 1 104857600

SQL> ALTER DATABASE ADD STANDBY LOGFILE SIZE 104857600;

Database altered.

SQL> ALTER DATABASE ADD STANDBY LOGFILE SIZE 104857600;

Database altered.

SQL> SELECT GROUP#, BYTES FROM V$STANDBY_LOG;

GROUP# BYTES
---------- ----------
 3 104857600
 4 104857600

Una vez que he creado los Standby Redo Logs en mi base de datos Primaria, creo los siguientes comandos de RMAN y también los cambios que se van a hacer en spfile de la Standby en este bloque de RMAN.

oracle@dlabvm13.dlab.pythian.com [testgg1] /home/oracle/bin
oracle $ cat duplicate.rmn

run {
allocate channel prmy1 type disk;
allocate channel prmy2 type disk;
allocate channel prmy3 type disk;
allocate channel prmy4 type disk;
allocate auxiliary channel stby type disk;
duplicate target database for standby from active database
spfile
 parameter_value_convert 'testgg1','testgg2'
 set db_unique_name='testgg2'
 set db_file_name_convert='/u01/app/oracle/oradata/testgg1/TESTGG1/datafile/','/u01/app/oracle/oradata/testgg2/TESTGG2/datafile/'
 set log_file_name_convert='/u01/app/oracle/oradata/testgg1/TESTGG1/onlinelog/','/u01/app/oracle/oradata/testgg2/TESTGG2/onlinelog/'
 set control_files='/u01/app/oracle/oradata/testgg2/control/control01.ctl','/u01/app/oracle/oradata/testgg2/control/control02.ctl'
 set log_archive_max_processes='10'
 set fal_client='testgg2'
 set fal_server='testgg1'
 set standby_file_management='AUTO'
 set log_archive_config='dg_config=(testgg1,testgg2)'
 set log_archive_dest_2='service=testgg1 ASYNC valid_for=(ONLINE_LOGFILE,PRIMARY_ROLE) db_unique_name=testgg1'
;
}

Ahora que  he creado el archivo de comandos de RMAN, sólo necesito ejecutar este comando en la base de datos target, que es la base de datos Primaria, que se conectara a la Standby que en este caso es la auxiliary.


oracle@dlabvm13.dlab.pythian.com [testgg1] /home/oracle/bin
oracle $ rman target sys/test@testgg1 auxiliary sys/test@testgg2

Recovery Manager: Release 11.2.0.3.0 - Production on Thu May 16 08:42:46 2013
Copyright (c) 1982, 2011, Oracle and/or its affiliates. All rights reserved.

connected to target database: TESTGG1 (DBID=839852638)
connected to auxiliary database: TESTGG1 (not mounted)

RMAN> @duplicate.rmn

RMAN>
RMAN> run {
2> allocate channel prmy1 type disk;
3> allocate channel prmy2 type disk;
4> allocate channel prmy3 type disk;
5> allocate channel prmy4 type disk;
6> allocate auxiliary channel stby type disk;
7> duplicate target database for standby from active database
8> spfile
9> parameter_value_convert 'testgg1','testgg2'
10> set db_unique_name='testgg2'
11> set db_file_name_convert='/u01/app/oracle/oradata/testgg1/TESTGG1/datafile/','/u01/app/oracle/oradata/testgg2/TESTGG2/datafile/'
12> set log_file_name_convert='/u01/app/oracle/oradata/testgg1/TESTGG1/onlinelog/','/u01/app/oracle/oradata/testgg2/TESTGG2/onlinelog/'
13> set control_files='/u01/app/oracle/oradata/testgg2/control/control01.ctl','/u01/app/oracle/oradata/testgg2/control/control02.ctl'
14> set log_archive_max_processes='10'
15> set fal_client='testgg2'
16> set fal_server='testgg1'
17> set standby_file_management='AUTO'
18> set log_archive_config='dg_config=(testgg1,testgg2)'
19> set log_archive_dest_2='service=testgg1 ASYNC valid_for=(ONLINE_LOGFILE,PRIMARY_ROLE) db_unique_name=testgg1'
20> ;
21> }
using target database control file instead of recovery catalog
allocated channel: prmy1
channel prmy1: SID=32 device type=DISK

allocated channel: prmy2
channel prmy2: SID=33 device type=DISK

allocated channel: prmy3
channel prmy3: SID=34 device type=DISK

allocated channel: prmy4
channel prmy4: SID=35 device type=DISK

allocated channel: stby
channel stby: SID=19 device type=DISK

Starting Duplicate Db at 16-MAY-13

contents of Memory Script:
{
 backup as copy reuse
 targetfile '/u01/app/oracle/product/11.2.0/dbhome_1/dbs/orapwtestgg1' auxiliary format
 '/u01/app/oracle/product/11.2.0/dbhome_1/dbs/orapwtestgg2' targetfile
 '/u01/app/oracle/product/11.2.0/dbhome_1/dbs/spfiletestgg1.ora' auxiliary format
 '/u01/app/oracle/product/11.2.0/dbhome_1/dbs/spfiletestgg2.ora' ;
 sql clone "alter system set spfile= ''/u01/app/oracle/product/11.2.0/dbhome_1/dbs/spfiletestgg2.ora''";
}
executing Memory Script

Starting backup at 16-MAY-13
Finished backup at 16-MAY-13

sql statement: alter system set spfile= ''/u01/app/oracle/product/11.2.0/dbhome_1/dbs/spfiletestgg2.ora''

contents of Memory Script:
{
 sql clone "alter system set audit_file_dest =
 ''/u01/app/oracle/oradata/dump/testgg2/adump'' comment=
 '''' scope=spfile";
 sql clone "alter system set diagnostic_dest =
 ''/u01/app/oracle/oradata/dump/testgg2'' comment=
 '''' scope=spfile";
 sql clone "alter system set log_archive_dest_1 =
 ''location=use_db_recovery_file_dest valid_for=(ALL_LOGFILES,ALL_ROLES) DB_UNIQUE_NAME=testgg2'' comment=
 '''' scope=spfile";
 sql clone "alter system set db_unique_name =
 ''testgg2'' comment=
 '''' scope=spfile";
 sql clone "alter system set db_file_name_convert =
 ''/u01/app/oracle/oradata/testgg1/TESTGG1/datafile/'', ''/u01/app/oracle/oradata/testgg2/TESTGG2/datafile/'' comment=
 '''' scope=spfile";
 sql clone "alter system set log_file_name_convert =
 ''/u01/app/oracle/oradata/testgg1/TESTGG1/onlinelog/'', ''/u01/app/oracle/oradata/testgg2/TESTGG2/onlinelog/'' comment=
 '''' scope=spfile";
 sql clone "alter system set control_files =
 ''/u01/app/oracle/oradata/testgg2/control/control01.ctl'', ''/u01/app/oracle/oradata/testgg2/control/control02.ctl'' comment=
 '''' scope=spfile";
 sql clone "alter system set log_archive_max_processes =
 10 comment=
 '''' scope=spfile";
 sql clone "alter system set fal_client =
 ''testgg2'' comment=
 '''' scope=spfile";
 sql clone "alter system set fal_server =
 ''testgg1'' comment=
 '''' scope=spfile";
 sql clone "alter system set standby_file_management =
 ''AUTO'' comment=
 '''' scope=spfile";
 sql clone "alter system set log_archive_config =
 ''dg_config=(testgg1,testgg2)'' comment=
 '''' scope=spfile";
 sql clone "alter system set log_archive_dest_2 =
 ''service=testgg1 ASYNC valid_for=(ONLINE_LOGFILE,PRIMARY_ROLE) db_unique_name=testgg1'' comment=
 '''' scope=spfile";
 shutdown clone immediate;
 startup clone nomount;
}
executing Memory Script

sql statement: alter system set audit_file_dest = ''/u01/app/oracle/oradata/dump/testgg2/adump'' comment= '''' scope=spfile

sql statement: alter system set diagnostic_dest = ''/u01/app/oracle/oradata/dump/testgg2'' comment= '''' scope=spfile

sql statement: alter system set log_archive_dest_1 = ''location=use_db_recovery_file_dest valid_for=(ALL_LOGFILES,ALL_ROLES) DB_UNIQUE_NAME=testgg2'' comment= '''' scope=spfile

sql statement: alter system set db_unique_name = ''testgg2'' comment= '''' scope=spfile

sql statement: alter system set db_file_name_convert = ''/u01/app/oracle/oradata/testgg1/TESTGG1/datafile/'', ''/u01/app/oracle/oradata/testgg2/TESTGG2/datafile/'' comment= '''' scope=spfile

sql statement: alter system set log_file_name_convert = ''/u01/app/oracle/oradata/testgg1/TESTGG1/onlinelog/'', ''/u01/app/oracle/oradata/testgg2/TESTGG2/onlinelog/'' comment= '''' scope=spfile

sql statement: alter system set control_files = ''/u01/app/oracle/oradata/testgg2/control/control01.ctl'', ''/u01/app/oracle/oradata/testgg2/control/control02.ctl'' comment= '''' scope=spfile

sql statement: alter system set log_archive_max_processes = 10 comment= '''' scope=spfile

sql statement: alter system set fal_client = ''testgg2'' comment= '''' scope=spfile

sql statement: alter system set fal_server = ''testgg1'' comment= '''' scope=spfile

sql statement: alter system set standby_file_management = ''AUTO'' comment= '''' scope=spfile

sql statement: alter system set log_archive_config = ''dg_config=(testgg1,testgg2)'' comment= '''' scope=spfile

sql statement: alter system set log_archive_dest_2 = ''service=testgg1 ASYNC valid_for=(ONLINE_LOGFILE,PRIMARY_ROLE) db_unique_name=testgg1'' comment= '''' scope=spfile

Oracle instance shut down

connected to auxiliary database (not started)
Oracle instance started

Total System Global Area 534462464 bytes

Fixed Size 2230072 bytes
Variable Size 163580104 bytes
Database Buffers 364904448 bytes
Redo Buffers 3747840 bytes
allocated channel: stby
channel stby: SID=18 device type=DISK

contents of Memory Script:
{
 backup as copy current controlfile for standby auxiliary format '/u01/app/oracle/oradata/testgg2/control/control01.ctl';
 restore clone controlfile to '/u01/app/oracle/oradata/testgg2/control/control02.ctl' from
 '/u01/app/oracle/oradata/testgg2/control/control01.ctl';
}
executing Memory Script

Starting backup at 16-MAY-13
channel prmy1: starting datafile copy
copying standby control file
output file name=/u01/app/oracle/product/11.2.0/dbhome_1/dbs/snapcf_testgg1.f tag=TAG20130516T084319 RECID=7 STAMP=815561001
channel prmy1: datafile copy complete, elapsed time: 00:00:07
Finished backup at 16-MAY-13

Starting restore at 16-MAY-13

channel stby: copied control file copy
Finished restore at 16-MAY-13

contents of Memory Script:
{
 sql clone 'alter database mount standby database';
}
executing Memory Script

sql statement: alter database mount standby database

contents of Memory Script:
{
 set newname for tempfile 1 to
 "/u01/app/oracle/oradata/testgg2/TESTGG2/datafile/o1_mf_temp_8qbok7fk_.tmp";
 switch clone tempfile all;
 set newname for datafile 1 to
 "/u01/app/oracle/oradata/testgg2/TESTGG2/datafile/o1_mf_system_8ocl7bho_.dbf";
 set newname for datafile 2 to
 "/u01/app/oracle/oradata/testgg2/TESTGG2/datafile/o1_mf_sysaux_8ocl7k6n_.dbf";
 set newname for datafile 3 to
 "/u01/app/oracle/oradata/testgg2/TESTGG2/datafile/o1_mf_sys_undo_8ocl7q6c_.dbf";
 set newname for datafile 4 to
 "/u01/app/oracle/oradata/testgg2/TESTGG2/datafile/o1_mf_users_8qbolh3g_.dbf";
 backup as copy reuse
 datafile 1 auxiliary format
 "/u01/app/oracle/oradata/testgg2/TESTGG2/datafile/o1_mf_system_8ocl7bho_.dbf" datafile
 2 auxiliary format
 "/u01/app/oracle/oradata/testgg2/TESTGG2/datafile/o1_mf_sysaux_8ocl7k6n_.dbf" datafile
 3 auxiliary format
 "/u01/app/oracle/oradata/testgg2/TESTGG2/datafile/o1_mf_sys_undo_8ocl7q6c_.dbf" datafile
 4 auxiliary format
 "/u01/app/oracle/oradata/testgg2/TESTGG2/datafile/o1_mf_users_8qbolh3g_.dbf" ;
 sql 'alter system archive log current';
}
executing Memory Script

executing command: SET NEWNAME

renamed tempfile 1 to /u01/app/oracle/oradata/testgg2/TESTGG2/datafile/o1_mf_temp_8qbok7fk_.tmp in control file

executing command: SET NEWNAME

executing command: SET NEWNAME

executing command: SET NEWNAME

executing command: SET NEWNAME

Starting backup at 16-MAY-13
channel prmy1: starting datafile copy
input datafile file number=00001 name=/u01/app/oracle/oradata/testgg1/TESTGG1/datafile/o1_mf_system_8ocl7bho_.dbf
channel prmy2: starting datafile copy
input datafile file number=00002 name=/u01/app/oracle/oradata/testgg1/TESTGG1/datafile/o1_mf_sysaux_8ocl7k6n_.dbf
channel prmy3: starting datafile copy
input datafile file number=00003 name=/u01/app/oracle/oradata/testgg1/TESTGG1/datafile/o1_mf_sys_undo_8ocl7q6c_.dbf
channel prmy4: starting datafile copy
input datafile file number=00004 name=/u01/app/oracle/oradata/testgg1/TESTGG1/datafile/o1_mf_users_8qbolh3g_.dbf
output file name=/u01/app/oracle/oradata/testgg2/TESTGG2/datafile/o1_mf_sys_undo_8ocl7q6c_.dbf tag=TAG20130516T084335
channel prmy3: datafile copy complete, elapsed time: 00:00:45
output file name=/u01/app/oracle/oradata/testgg2/TESTGG2/datafile/o1_mf_users_8qbolh3g_.dbf tag=TAG20130516T084335
channel prmy4: datafile copy complete, elapsed time: 00:00:55
output file name=/u01/app/oracle/oradata/testgg2/TESTGG2/datafile/o1_mf_system_8ocl7bho_.dbf tag=TAG20130516T084335
channel prmy1: datafile copy complete, elapsed time: 00:01:05
output file name=/u01/app/oracle/oradata/testgg2/TESTGG2/datafile/o1_mf_sysaux_8ocl7k6n_.dbf tag=TAG20130516T084335
channel prmy2: datafile copy complete, elapsed time: 00:01:05
Finished backup at 16-MAY-13

sql statement: alter system archive log current

contents of Memory Script:
{
 switch clone datafile all;
}
executing Memory Script

datafile 1 switched to datafile copy
input datafile copy RECID=7 STAMP=815561103 file name=/u01/app/oracle/oradata/testgg2/TESTGG2/datafile/o1_mf_system_8ocl7bho_.dbf
datafile 2 switched to datafile copy
input datafile copy RECID=8 STAMP=815561104 file name=/u01/app/oracle/oradata/testgg2/TESTGG2/datafile/o1_mf_sysaux_8ocl7k6n_.dbf
datafile 3 switched to datafile copy
input datafile copy RECID=9 STAMP=815561104 file name=/u01/app/oracle/oradata/testgg2/TESTGG2/datafile/o1_mf_sys_undo_8ocl7q6c_.dbf
datafile 4 switched to datafile copy
input datafile copy RECID=10 STAMP=815561104 file name=/u01/app/oracle/oradata/testgg2/TESTGG2/datafile/o1_mf_users_8qbolh3g_.dbf
Finished Duplicate Db at 16-MAY-13
released channel: prmy1
released channel: prmy2
released channel: prmy3
released channel: prmy4
released channel: stby

RMAN> **end-of-file**

RMAN> exit

Como puedes ver, es pan comido, ahora sólo inicio el proceso de recuperación de la base de datos Standby, en mi caso he usado la opción de Active Dataguard para que te pueda demostrar que realmente funciona, pero ten cuidado que es un Opción Licenciable.


SQL> alter database open;

Database altered.

SQL> alter database recover managed standby database disconnect;

Database altered.

SQL> select protection_mode,protection_level,database_role,name from v$database;

PROTECTION_MODE PROTECTION_LEVEL DATABASE_ROLE NAME
-------------------- -------------------- ---------------- ---------
MAXIMUM PERFORMANCE MAXIMUM PERFORMANCE PHYSICAL STANDBY TESTGG1

SQL> select instance_name,host_name from v$instance;

INSTANCE_NAME HOST_NAME
---------------- ----------------------------------------------------------------
testgg2 dlabvm14.dlab.pythian.com

SQL> select * from sender.test;
select * from sender.test
 *
ERROR at line 1:
ORA-00942: table or view does not exist


Ahora me regreso a la base de datos Primaria, y creo una tabla llamada test en el esquema sender, y como se puede ver arriba, esta tabla no existe en la base de datos Standby.


SQL> select instance_name,host_name from v$instance;

INSTANCE_NAME HOST_NAME
---------------- ----------------------------------------------------------------
testgg1 dlabvm13.dlab.pythian.com

SQL> select protection_mode,protection_level,database_role,name from v$database;

PROTECTION_MODE PROTECTION_LEVEL DATABASE_ROLE NAME
-------------------- -------------------- ---------------- ---------
MAXIMUM PERFORMANCE MAXIMUM PERFORMANCE PRIMARY TESTGG1

SQL> create table sender.test(id number);

Table created.

SQL> insert into sender.test values(1);

1 row created.

SQL> commit;

Commit complete.

SQL> alter system switch logfile;

System altered.

De nuevo me regreso a la base de datos Standby y podemos ver que tenemos nuestra tabla test que acabamos de crear en la primaria.


SQL> select protection_mode,protection_level,database_role,name from v$database;

PROTECTION_MODE PROTECTION_LEVEL DATABASE_ROLE NAME
-------------------- -------------------- ---------------- ---------
MAXIMUM PERFORMANCE MAXIMUM PERFORMANCE PHYSICAL STANDBY TESTGG1

SQL> select instance_name,host_name from v$instance;

INSTANCE_NAME HOST_NAME
---------------- ----------------------------------------------------------------
testgg2 dlabvm14.dlab.pythian.com

SQL> select * from sender.test;

ID
----------
 1

Ahora bien, hay varias manera de ver si esto funciona o no, puedes utilizar el siguiente query para ver cual fue el último archivo recibido/se aplico en la base de datos Standby.


SQL> SELECT 'Last Applied : ' Logs,
TO_CHAR(next_time,'DD-MON-YY:HH24:MI:SS') TIME,thread#,sequence#
FROM v$archived_log
WHERE sequence# =
(SELECT MAX(sequence#) FROM v$archived_log WHERE applied='YES'
)
UNION
SELECT 'Last Received : ' Logs,
TO_CHAR(next_time,'DD-MON-YY:HH24:MI:SS') TIME,thread#,sequence#
FROM v$archived_log
WHERE sequence# =
(SELECT MAX(sequence#) FROM v$archived_log );

LOGS TIME THREAD# SEQUENCE#
---------------- ------------------ ---------- ----------
Last Applied : 16-MAY-13:11:42:52 1 65
Last Received : 16-MAY-13:11:42:52 1 65

Mientras que en la base de datos Primaria, se puede comprobar cuál es la secuencia actual y cuál es la secuencia en espera de ser aplicada.


SQL> SELECT
 (SELECT name FROM V$DATABASE
 ) name,
 (SELECT MAX (sequence#) FROM v$archived_log WHERE dest_id = 1
 ) Current_primary_seq,
 (SELECT MAX (sequence#)
 FROM v$archived_log
 WHERE TRUNC(next_time) > SYSDATE - 1
 AND dest_id = 2
 ) max_stby,
 (SELECT NVL (
 (SELECT MAX (sequence#) - MIN (sequence#)
 FROM v$archived_log
 WHERE TRUNC(next_time) > SYSDATE - 1
 AND dest_id = 2
 AND applied = 'NO'
 ), 0)
 FROM DUAL
 ) "To be applied",
 (
 (SELECT MAX (sequence#) FROM v$archived_log WHERE dest_id = 1
 ) -
 (SELECT MAX (sequence#) FROM v$archived_log WHERE dest_id = 2
 )) "To be Shipped"
FROM DUAL;

NAME CURRENT_PRIMARY_SEQ MAX_STBY To be applied To be Shipped
--------- ------------------- ---------- ------------- -------------
TESTGG1 65 65 0 0

Espero que esta pequeña guía te pueda ayudar cuando estés tratando de construir una base de datos Standby Fisica con RMAN Active Duplicate, y como siempre,  prueba todo lo ,que he dicho o se ha mencionado,  antes de ejecutarlo en un entorno de producción y sobre todo para que puedas entender lo que está sucediendo .


lunes, 22 de abril de 2013

El estado no documentado "M" de un respaldo en RMAN

No es raro que Oracle le haga falta detalles a su documentación , y esto es sólo otro caso de esta enfermedad.

Tenemos una base de datos en la que tenemos dos copias del mismo backup set, uno lo tenemos en el FRA, la otra en un disco externo, que de vez en cuando la copia se elimina de este segundo disco. Pero, ¿qué sucede después de hacer un crosscheck y una de las 2 copias  no se encuentra? El del FRA está disponible y el que está en el disco externo ha expirado, como vas a ver esto cuando hagas un LIST en RMAN?

En cuanto a la documentación de 11.2 para el comando LIST, sólo dice que el estado de un respaldo puede estar AVAILABLE, UNAVAILABLE, o EXPIRED, pero como puedes ver a continuación, este no es el caso de nuestra base de datos :)


RMAN> list backup summary;
 
using target database control file instead of recovery catalog
 
List of Backups
===============
Key     TY LV S Device Type Completion Time #Pieces #Copies Compressed Tag
------- -- -- - ----------- --------------- ------- ------- ---------- ---
1986    B  F  A DISK        17-APR-13       1       2       NO         *
1987    B  F  M DISK        17-APR-13       1       2       NO         *
1988    B  F  A DISK        17-APR-13       1       2       NO         *
1989    B  F  A DISK        19-APR-13       1       1       NO         TAG000661
1990    B  A  A DISK        19-APR-13       1       1       YES        BUP_ARCH_FRA

La primera vez que vi esto, se me hizo curioso en cuanto a lo que significa el sentido del status M (y es al día de hoy  que todavía no sé el significado exacto, pero tengo mis suposiciones). Si hago un trace de mi comando LIST BACKUP SUMMARY, puedo ver exactamente lo que yo sabía que estaba ocurriendo:


pythian@oracleenespanol.local /home/pythian/working/antunez
pythian $ rman target / debug trace rman.trc
Recovery Manager: Release 11.2.0.3.0 - Production on Fri Apr 19 16:02:56 2013
 
Copyright (c) 1982, 2011, Oracle and/or its affiliates.  All rights reserved.
 
RMAN-06005: connected to target database: TESTDB (DBID=1834739652)
 
RMAN> list backup summary;

Este es un pequeño resultado del trace que hice :


DBGMISC: 339 BS (datafile) key=1987 recid=1987 stamp=812962808 setstamp=812962807 setcount=2021
DBGMISC: level=1 level_i=-1 piececount=1 keepopts=0, site_key=0 [16:03:27.544]
DBGMISC: site_key=0 [16:03:27.544]
DBGMISC: chid=NIL parm=NIL [16:03:27.544]
DBGMISC: flags= [16:03:27.544]
DBGMISC: valid backup set list is [16:03:27.544]
DBGMISC: 1 VBS copy#=1 tag=BACKUP_CONTROLFILE_FRA deviceType=DISK status=A
DBGMISC: 1 BPIECEX key=3502 recid=3502 stamp=812962808
DBGMISC: bskey=1987 set_stamp=812962807 set_count=2021 site_key=0
DBGMISC: pieceno=1 handle=+FRA/test/backupset/2013_04_17/ncnnf0_backup_controlfile_fra_0.297.812962809
DBGMISC: device=DISK krmkch { count=0 found=FALSE }
DBGMISC: 2 VBS copy#=2 tag=BACKUP_OF_BACKUPSET deviceType=DISK status=X
DBGMISC: 1 BPIECEX key=3538 recid=3538 stamp=813024283
DBGMISC: bskey=1987 set_stamp=812962807 set_count=2021 site_key=0
DBGMISC: pieceno=1 handle=/backupdisk/TEST_bck/db_bckset_backup_TEST2_04-18-2013_v5o79kvn_1_2.rman
DBGMISC: device=DISK krmkch { count=0 found=FALSE }
DBGMISC: restore target list is [16:03:27.545]
DBGMISC: 1 ACT type=full fromSCN=0 toSCN=307822519 fno=0
DBGMISC: CURCF

Como puedes ver arriba, una copia ha expirado y la otra está disponible, también cuando el resultado del comando LIST tiene un asterisco "*",  se debe a que cada copia tiene un TAG diferente,  para la etiqueta del backupset con clave 1987.

Ambas conductas son perfectamente normales, pero no vas a encontrar esto en cualquier lugar de la documentación de Oracle, por lo que la próxima vez que veas esto en tu comando LIST, conocerás el significado exacto de este estado. ¿Has visto esto antes en tus listados de RMAN?

P.D. Para mí significa Múltiple o Mixta.

viernes, 12 de abril de 2013

Mi Primera Conferencia en Collaborate de IOUG


Una de las razones principales por las que he estado un poco inactivo en mi blog, ha sido por que en el último mes y medio he cambiado de trabajo, cambie de países y di una conferencia en Collaborate de IOUG en Denver, así que sólo quería compartir este vinculo para cualquier persona que no tuvo la oportunidad de asistir a este impresionante encuentro mentes en Oracle.

Mi presentación se orientó hacia usuarios principiantes o intermedios de la utilidad RMAN de Oracle, aquí esta mi papel técnico basado en esta presentación, espero que te sea útil, como les fue a las personas que me se acercaron de la presentación. Lo unico es que se encuentra en ingles, ya que la presentación fue en ingles, pero si requieres ayuda, no dudes en decirme.

How to Survive a Disaster with RMAN

miércoles, 13 de marzo de 2013

Mis primeros dias en Pythian

Una de las cosas que siempre me ha sorprendido es la forma en que todas nuestras decisiones, grandes o pequeñas, tienen un impacto en nuestra vida. A veces no se nota que estas fueron un parteaguas en nuestra vida, pero a veces estas decisiones son tan claras como el agua.

Para mí, un simple DBA de Oracle, una de estas decisiones de vida era tener una charla con un gran amigo del gran potencial que tienen las redes sociales y la razón de por qué tengo que abrir una cuenta de Twitter. Esto me llevó a seguir Yury Velikanov, quien tuiteó una conversación sobre cómo compartir tu blog con Oracle para poder asistir a Oracle Open World 2012 (OOW) como blogger.

Así que hice exactamente eso y mi propuesta fue aceptada. Esto me dio la oportunidad de llegar a San Francisco. Durante esos días en el OOW, tuve la oportunidad de escuchar al fundador de Pythian,  Paul Vallée  en una platica de Ted. Después de esos 15 minutos y una charla en el evento de "bloggeros" con Greg Leger, tuve la inquietud a unirme a esta compañía de la que me acababa de enterar que existia en este viaje.

Ahora bien, esto no iba a ser un camino facil, en realidad iba a ser un arduo proceso de contratación y entrevistas. Esto es debido al hecho de que Pythian esta compuesto de los mejores talentos de todo el mundo, y se esfuerza por tenerlos.

Brincando 6 meses al 04 de Marzo del 2013, mi primer día en Pythian, y qué semana ha sido, llena desde los primeros minutos con los entrenamientos en el modo de vida de un "Pythianense". Y todo lo que puedo decir al respecto es que, se ha cumplido y se ha superado todo lo que me había imaginado que iba a ser.

Y aquí están algunas razones de por qué:
  • Quiero saber si el primer día que llegaste a tu nuevo trabajo, te sentaste con el CEO de la empresa y tuvise una conversación de una hora con él, para ver la misión y visión de la organización y la ruta que está tomando.
  • El dueño de la empresa te animó para iniciar a "bloggear" y comenzar a subir tu nivel de juego.
  • Tienes la oportunidad de estar , hablar y sentarte alrededor de la mesa y compartir ideas  con las personas que están consideradas como el mejor 5% en todo el mundo en la materia que te encuentras.
  • Ves que se esfuerzan para evitar en todos sus empleados, la famosa frase de Stephen King de El Resplandor "Mucho trabajo y poca diversión hacen de Jack un tipo aburrido".
  • Empiezas a creer el punto de vista Pythian de que "la calidad de nuestro trabajo es esencial para el éxito de nuestros clientes y la calidad de nuestro servicio es esencial para nuestro éxito", y con esto, es importante saber que se trata de un esfuerzo de equipo, no es un héroe independiente. De ahí que la empresa haga todo lo posible desde el principio, para que te sientas como parte de esta familia en crecimiento.
Así que para el Viernes, yo ya llevaba el lema "Love your data" (Ama a tus datos) en la camisa, compartiendo donas en la oficina de Ottawa y muy emocionado de estar aquí para dar lo mejor de mi, ser una parte esencial de esta organización y ser exitoso en el proceso.


Y ahora todo lo que puedo decir después de que la primera semana se ha ido, y mirando hacia atrás en todos los sacrificios y las elecciones que he hecho para estar aquí en Pythian (que yo no voy a entrar en detalles en este post, eso es para platicar cara a cara con un café si quieres oír la historia), es que tengo muchas ganas de que llegue la semana dos, tres, cuatro, y el resto por venir ...

domingo, 27 de enero de 2013

Error ORA-39127 cuando estoy haciendo un Export con Datapump

Esta entrada realmente la estoy creando para tener yo un acceso mas rapido, sin tener que pasar por MOS, en nuestro ambiente tuvimos una situacion en donde en nuestra base de datos se instalaron todos los componentes de Oracle, como OLAP y Oracle Text, como no era necesario tenerlos, se tomo la decision de removerlos, pero cuando estabamos corriendo un export , esta fallando con el siguiente error:

ORA-39127: unexpected error from call to "SYS"."DBMS_CUBE_EXP"."SCHEMA_INFO_EXP"
ORA-44002: invalid object name
ORA-06512: at "SYS.DBMS_ASSERT", line 316
ORA-06512: at "SYS.DBMS_METADATA", line 9409

Primero verificamos que ya no existen componentes de OLAP en la base de datos, en este caso, nada mas tenemos RAC y los catalogos necesarios

TESTDB1 >DBA_REGISTRY CONTENTS (VIEW DOES NOT EXISIT IN VERSIONS < 9.2.0)
TESTDB1 >================================================================
TESTDB1 >COMP_ID              COMP_NAME                                VERSION    STATUS
-------------------- ---------------------------------------- ---------- ---------------
CATALOG              Oracle Database Catalog Views            11.2.0.3.0 VALID
CATPROC              Oracle Database Packages and Types       11.2.0.3.0 VALID
RAC                  Oracle Real Application Clusters         11.2.0.3.0 VALID

Y con este query vemos que queda todavia existe informacion en el diccionario de datos refiriendose a OLAP

TESTDB1 >SELECT * FROM SYS.EXPPKGACT$ WHERE PACKAGE = 'DBMS_CUBE_EXP';

PACKAGE                        SCHEMA                              CLASS     LEVEL#
------------------------------ ------------------------------ ---------- ----------
DBMS_CUBE_EXP                  SYS                                     2       1050
DBMS_CUBE_EXP                  SYS                                     4       1050
DBMS_CUBE_EXP                  SYS                                     6       1050

La manera de resolverlo es crear primero un respaldo de la tabla SYS.EXPPKGACT$, por si algo llegara a salir mal, esto lo haces como el usuario SYS

oracle $ sqlplus

SQL*Plus: Release 11.2.0.3.0 Production on Mon Jan 27 02:46:38 2013

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

Enter user-name: /as sysdba

Connected to:
Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - 64bit Production
With the Partitioning, Real Application Clusters, Automatic Storage Management, OLAP,
Data Mining and Real Application Testing options

TESTDB1 >CREATE TABLE SYS.EXPPKGACT$_BACKUP AS SELECT * FROM SYS.EXPPKGACT$;

Table created.

Una vez que hayas creado el respaldo de la tabla, vas a borrar los datos, con el siguiente delete

TESTDB1 >DELETE FROM SYS.EXPPKGACT$ WHERE PACKAGE = 'DBMS_CUBE_EXP' AND SCHEMA= 'SYS';

3 rows deleted.

TESTDB1 >commit;

Commit complete.

Y ahora si vas a poder realizar tu respaldo con exito, esto lo puedes encontrar en el documento de MOS 1328829.1


Starting "SYSTEM"."DATAPMP__USERS":  system/******** dumpfile=node_TESTDB_users_%U.dmp logfile=node_TESTDB_users.log parfile=/mount/dba01/oracle/recover/export_dp_users.par
Processing object type SCHEMA_EXPORT/USER
Processing object type SCHEMA_EXPORT/SYSTEM_GRANT
Processing object type SCHEMA_EXPORT/ROLE_GRANT
Processing object type SCHEMA_EXPORT/DEFAULT_ROLE
Processing object type SCHEMA_EXPORT/PRE_SCHEMA/PROCACT_SCHEMA
Processing object type SCHEMA_EXPORT/SYNONYM/SYNONYM
Processing object type SCHEMA_EXPORT/DB_LINK
Processing object type SCHEMA_EXPORT/SEQUENCE/SEQUENCE
Processing object type SCHEMA_EXPORT/SEQUENCE/GRANT/OWNER_GRANT/OBJECT_GRANT
Processing object type SCHEMA_EXPORT/PACKAGE/PACKAGE_SPEC
Processing object type SCHEMA_EXPORT/PACKAGE/GRANT/OWNER_GRANT/OBJECT_GRANT
Processing object type SCHEMA_EXPORT/FUNCTION/FUNCTION
Processing object type SCHEMA_EXPORT/FUNCTION/GRANT/OWNER_GRANT/OBJECT_GRANT
Processing object type SCHEMA_EXPORT/PROCEDURE/PROCEDURE
Processing object type SCHEMA_EXPORT/PROCEDURE/GRANT/OWNER_GRANT/OBJECT_GRANT
Processing object type SCHEMA_EXPORT/PACKAGE/COMPILE_PACKAGE/PACKAGE_SPEC/ALTER_PACKAGE_SPEC
Processing object type SCHEMA_EXPORT/FUNCTION/ALTER_FUNCTION
Processing object type SCHEMA_EXPORT/PROCEDURE/ALTER_PROCEDURE
Processing object type SCHEMA_EXPORT/VIEW/VIEW
Processing object type SCHEMA_EXPORT/VIEW/GRANT/OWNER_GRANT/OBJECT_GRANT
Processing object type SCHEMA_EXPORT/PACKAGE/PACKAGE_BODY
Processing object type SCHEMA_EXPORT/EVENT/TRIGGER
Processing object type SCHEMA_EXPORT/POST_SCHEMA/PROCOBJ
ORA-39165: Schema TEST01 was not found.
Master table "SYSTEM"."DATAPMP_USERS" successfully loaded/unloaded