RMAN : Corriendo un respaldo incremental y el error ORA-19764

El otro día estaba corriendo un respaldo de una base de datos que recientemente acababa ser clonada de otra base de datos. Y me aparece el siguiente error:

DBGRPC:        EXITED krmqgns with status 1
DBGRPC:        krmxpoq - returning rpc_number: 77 with status: FINISHED16 for channel CH10
DBGRPC:        krmxr - channel CH10 calling peicnt
DBGRPC:        krmxrpc - channel CH10 kpurpc2 err=19583 db=target proc=SYS.DBMS_BACKUP_RESTORE.BACKUPPIECECREATE excl: 187
DBGRPC:        krmxrpc - caloing krmxtrim: with message of length 187: @@@ORA-19583: conversation terminated due to error
DBGRPC:        ORA-19764: database id 8573487567 does not match database id 3024984012 in control file
DBGRPC:        ORA-06512: at "SYS.DBMS_BACKUP_RESTORE", line 1381

Y lo primero que hice fue verificar precisamente que el DBID de la base de datos fuera el correcto, ya que si haces una clonacion sin RMAN, el DBID se mantiene de la base de datos de origen y en el catalogo se crean conflictos, el cual no fue el caso.

TESTDB21 >select dbid,name from v$database;

      DBID NAME
---------- --------
3024984012 TESTDB2

La verdad me quebré un poco la cabeza, ya que la información que tenia el diccionario de datos, apuntaba a que el DBID era el correcto (3024984012) . Como tenia un poco el tiempo encima , no tuve mas tiempo para investigar el porque, ya que en el archivo trace que genere con RMAN, no aparece que esta información erronea viene del archivo de cambios de bloques (block change tracking file).

TESTDB21 >select FHDBI,FHDBN from X$KRCFH
  2  /

     FHDBI FHDBN
---------- --------
8573487567 TESTDB2

Una vez que vi que era este archivo era el que estaba causando la falla, lo único que hice fue recrearlo y con esto se resolvió mi problema.

TESTDB21 >alter database disable block change tracking;

Database altered.

TESTDB21 >select FHDBI,FHDBN from X$KRCFH;

no rows selected

TESTDB21 >alter database enable block change tracking using FILE '/copy01/TESTDB2/oracle/TESTDB2/ctf/TESTDB2.ctf';

Database altered.

TESTDB21 >select FHDBI,FHDBN from X$KRCFH;

     FHDBI FHDBN
---------- --------
3024984012 TESTDB2

Espero que te sirva este tip si te llegas a enfrentar a este problema, de igual manera te anexo un enlace de un muy buen articulo de Alex Gorbachev del grupo Pythian describiendo el archivo BCT, te puede ayudar como me ayudo a mi :)

Oracle 10G Block Change Tracking Inside Out (INGLES)

Unix : arg list too long cuando tratas de borrar una lista de archivos

Este tip es un poco mas para mi, para tenerlo en un lugar que se que es fácil de encontrar, esto lo digo ya que puedes encontrar mucha información al respecto en Internet.

Pero si te sirve, pues que mejor :)

Cuando tratas de borrar en Unix  todos los archivos de auditoría de una base de datos que acabas de decomisar, y te topas con el siguiente error

oracle@servidor1.oracleenespanol.blogspot.com [TESTDB1] /mount/dba01/oracle/TESTDB/audit
oracle $ rm ./*.aud
ksh: /usr/xpg4/bin/rm: arg list too long

Lo que tienes que hacer es pasarle los archivos como argumento para evitar el error y de esta manera no tendrás este error. Nada mas asegurate que estas en el directorio correcto y cuidar mucho los espacios, no vayas a borrar algo que no quieres.

oracle@servidor1.oracleenespanol.blogspot.com [TESTDB1] /home/oracle
oracle $ cd /mount/dba01/oracle/TESTDB/audit

oracle@servidor1.oracleenespanol.blogspot.com [TESTDB1] /mount/dba01/oracle/TESTDB/audit
oracle $ find ./ -name "*.aud" -type f | xargs rm

RMAN : Como Borrar una base de datos

En un ambiente en donde tienes que estar refrescando base de datos seguido, una de las mejores maneras y mas seguras de borrar los archivos pertenecientes a la base de datos que vas a refrescar es con el comando DROP DATABASE.

Si estas en un ambiente de RAC, lo primero que tienes que hacer es cambiar el parámetro de cluster_database a FALSO y una vez que lo hayas hecho, apaga la base de datos.

oracle@servidor1.oracleenespanol.blogspot.com [TESTDB1] /home/oracle
oracle $ sqlplus

SQL*Plus: Release 11.2.0.3.0 Production on Wed Jul 11 22:30:21 2012

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 Real Application Clusters, Automatic Storage Management, OLAP,
Data Mining and Real Application Testing options

TESTDB1 >alter system set cluster_database=FALSE scope=spfile;

System altered.

TESTDB1 >exit
Disconnected from Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - 64bit Production
With the Real Application Clusters, Automatic Storage Management, OLAP,
Data Mining and Real Application Testing options

oracle@servidor1.oracleenespanol.blogspot.com [TESTDB1] /home/oracle
oracle $ srvctl stop database -d TESTDB

oracle@servidor1.oracleenespanol.blogspot.com [TESTDB1] /home/oracle
oracle $ srvctl status database -d TESTDB
Instance TESTDB1 is not running on node servidor1
Instance TESTDB2 is not running on node servidor2

Ya que cerraste la base de datos,asegurate de que tienes las variables de ambiente correctas y  vamos a abrirla en modo MOUNT y de ahí a habilitar una sesión restringida.

oracle@servidor1.oracleenespanol.blogspot.com [TESTDB1] /home/oracle
oracle $ . $HOME/TESTDB

oracle@servidor1.oracleenespanol.blogspot.com [TESTDB1] /home/oracle
oracle $ rman target /

Recovery Manager: Release 11.2.0.3.0 - Production on Wed Jul 11 22:36:08 2012

Copyright (c) 1982, 2011, Oracle and/or its affiliates.  All rights reserved.

connected to target database (not started)

RMAN> startup mount;

Oracle instance started
database mounted

Total System Global Area    2622255104 bytes

Fixed Size                     2231232 bytes
Variable Size                637535296 bytes
Database Buffers            1962934272 bytes
Redo Buffers                  19554304 bytes

RMAN> SQL 'ALTER SYSTEM ENABLE RESTRICTED SESSION';

using target database control file instead of recovery catalog
sql statement: ALTER SYSTEM ENABLE RESTRICTED SESSION

Ya lo unico que nos queda por hacer es tirar la base de datos, a mi no me gusta hacerlo con NOPROMPT, ya que es la ultima oportunidad que vas a tener para asegurarte de que estas borrando la base de datos correcta, pero ahora si en gustos se rompen generos.

RMAN> DROP DATABASE INCLUDING BACKUPS;

database name is "TESTDB" and DBID is 1743232258

Do you really want to drop all backups and the database (enter YES or NO)?YES


allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=62 device type=DISK
allocated channel: ORA_DISK_2
channel ORA_DISK_2: SID=82 device type=DISK

List of Backup Pieces
BP Key  BS Key  Pc# Cp# Status      Device Type Piece Name
------- ------- --- --- ----------- ----------- ----------
1       1       1   1   AVAILABLE   DISK        /copy01/TESTDB/full/TESTDB_HOT_07012012_1_3_788480833
2       2       1   1   AVAILABLE   DISK        /copy01/TESTDB/full/TESTDB_HOT_07012012_1_4_788480833
3       3       1   1   AVAILABLE   DISK        /copy01/TESTDB/full/TESTDB_HOT_07012012_1_5_788480834
4       4       1   1   AVAILABLE   DISK        /copy01/TESTDB/full/TESTDB_HOT_07012012_1_2_788480832
5       5       1   1   AVAILABLE   DISK        /copy01/TESTDB/full/TESTDB_HOT_07012012_1_6_788480835
6       6       1   1   AVAILABLE   DISK        /copy01/TESTDB/full/TESTDB_HOT_07012012_1_7_788480837
7       7       1   1   AVAILABLE   DISK        /copy01/TESTDB/full/TESTDB_HOT_07012012_1_8_788480838
8       8       1   1   AVAILABLE   DISK        /copy01/TESTDB/full/TESTDB_HOT_07012012_1_9_788480839
9       9       1   1   AVAILABLE   DISK        /copy01/TESTDB/full/TESTDB_HOT_07012012_1_1_788480832
10      10      1   1   AVAILABLE   DISK        /copy01/TESTDB/full/TESTDB_HOT_07012012_1_10_788480839
11      11      1   1   AVAILABLE   DISK        /copy01/TESTDB/control/TESTDB_07_01_2012_788480872.ctl
12      12      1   1   AVAILABLE   DISK        /copy01/TESTDB/control/c-1743232258-20120701-00
13      13      1   1   AVAILABLE   DISK        /copy01/TESTDB/arch/TESTDB_ARCH_07012012_1_16_788480924
14      14      1   1   AVAILABLE   DISK        /copy01/TESTDB/arch/TESTDB_ARCH_07012012_1_17_788480924
15      15      1   1   AVAILABLE   DISK        /copy01/TESTDB/arch/TESTDB_ARCH_07012012_1_18_788480926
16      16      1   1   AVAILABLE   DISK        /copy01/TESTDB/arch/TESTDB_ARCH_07012012_1_15_788480923
17      17      1   1   AVAILABLE   DISK        /copy01/TESTDB/arch/TESTDB_ARCH_07012012_1_13_788480923
18      18      1   1   AVAILABLE   DISK        /copy01/TESTDB/arch/TESTDB_ARCH_07012012_1_14_788480923
19      19      1   1   AVAILABLE   DISK        /copy01/TESTDB/control/c-1743232258-20120701-01
deleted backup piece
backup piece handle=/copy01/TESTDB/full/TESTDB_HOT_07012012_1_3_788480833 RECID=1 STAMP=788480834
deleted backup piece
backup piece handle=/copy01/TESTDB/full/TESTDB_HOT_07012012_1_4_788480833 RECID=2 STAMP=788480834
deleted backup piece
backup piece handle=/copy01/TESTDB/full/TESTDB_HOT_07012012_1_5_788480834 RECID=3 STAMP=788480836
deleted backup piece
backup piece handle=/copy01/TESTDB/full/TESTDB_HOT_07012012_1_2_788480832 RECID=4 STAMP=788480833
deleted backup piece
backup piece handle=/copy01/TESTDB/full/TESTDB_HOT_07012012_1_6_788480835 RECID=5 STAMP=788480838
deleted backup piece
backup piece handle=/copy01/TESTDB/full/TESTDB_HOT_07012012_1_7_788480837 RECID=6 STAMP=788480838
deleted backup piece
backup piece handle=/copy01/TESTDB/full/TESTDB_HOT_07012012_1_8_788480838 RECID=7 STAMP=788480839
deleted backup piece
backup piece handle=/copy01/TESTDB/full/TESTDB_HOT_07012012_1_9_788480839 RECID=8 STAMP=788480839
deleted backup piece
backup piece handle=/copy01/TESTDB/full/TESTDB_HOT_07012012_1_1_788480832 RECID=9 STAMP=788480832
deleted backup piece
backup piece handle=/copy01/TESTDB/full/TESTDB_HOT_07012012_1_10_788480839 RECID=10 STAMP=788480840
deleted backup piece
backup piece handle=/copy01/TESTDB/control/TESTDB_07_01_2012_788480872.ctl RECID=11 STAMP=788480875
deleted backup piece
backup piece handle=/copy01/TESTDB/control/c-1743232258-20120701-00 RECID=12 STAMP=788480881
deleted backup piece
backup piece handle=/copy01/TESTDB/arch/TESTDB_ARCH_07012012_1_16_788480924 RECID=13 STAMP=788480924
deleted backup piece
backup piece handle=/copy01/TESTDB/arch/TESTDB_ARCH_07012012_1_17_788480924 RECID=14 STAMP=788480924
deleted backup piece
backup piece handle=/copy01/TESTDB/arch/TESTDB_ARCH_07012012_1_18_788480926 RECID=15 STAMP=788480926
deleted backup piece
backup piece handle=/copy01/TESTDB/arch/TESTDB_ARCH_07012012_1_15_788480923 RECID=16 STAMP=788480924
deleted backup piece
backup piece handle=/copy01/TESTDB/arch/TESTDB_ARCH_07012012_1_13_788480923 RECID=17 STAMP=788480923
deleted backup piece
backup piece handle=/copy01/TESTDB/arch/TESTDB_ARCH_07012012_1_14_788480923 RECID=18 STAMP=788480923
deleted backup piece
backup piece handle=/copy01/TESTDB/control/c-1743232258-20120701-01 RECID=19 STAMP=788480947
Deleted 19 objects


released channel: ORA_DISK_1
released channel: ORA_DISK_2
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=62 device type=DISK
allocated channel: ORA_DISK_2
channel ORA_DISK_2: SID=82 device type=DISK
specification does not match any datafile copy in the repository
specification does not match any control file copy in the repository
specification does not match any control file copy in the repository
List of Archived Log Copies for database with db_unique_name TESTDB
=====================================================================

Key     Thrd Seq     S Low Time
------- ---- ------- - ---------
14      2    4       A 11-JUL-12
        Name: +ARCH/TESTDB/archivelog/TESTDB_4_2_788478082.dbf

deleted archived log
archived log file name=+ARCH/TESTDB/archivelog/TESTDB_4_2_788478082.dbf RECID=14 STAMP=788481092
Deleted 1 objects


database name is "TESTDB" and DBID is 1743232258
database dropped

Un Tip cuando te topas el Error ORA-00600: [2662] cuando haces flashback database

Aquí un tip rápido para cuando te topas con el error ORA-00600: [2662], este error significa que el SCN de un bloque tiene un numero mayor al del SCN de la base de datos , esto puede significar que existe una corrupción física en tu base de datos , aquí no te voy a decir como solventarlo, ya que es mas bien para un SR con Oracle dependiendo del caso y versión de RDBMS que tienes.

Pero algo que te puede ayudar a ver donde estas teniendo el error es lo siguiente, cuando te aparece el error, el quinto argumento te puede dar esta información

ORA-00600: internal error code, arguments: [2662], [2910], [829087674], [2910], [829528307], [1451708231], [], [], [], [], [], []

Si en el error tienes el quinto argumento, ya que hay casos en el que no lo vas a tener, puedes usar la siguiente función para localizar el datafile al que se esta refiriendo

TESTDB> select dbms_utility.data_block_address_file(1451708231) "fileno",dbms_utility.data_block_address_block(1451708231) from dual ;

fileno     DBMS_UTILITY.DATA_BLOCK_ADDRESS_BLOCK(1451708231)
---------- -------------------------------------------
138              3

Con este puedes identificar que archivo es el que te esta causando el problema

TESTDB> Select name ,file#,ts# from v$datafile where rfile#=138 ;

Y con la utileria dbverify puedes identificar si es que realmente esta corrupto o no

dbv file=<NOMBRE_DEL_DATAFILE_OBTENIDO_ARRIBA> blocksize=<db_block_size>

Como te decía al principio, lo que te recomiendo es abrir un SR con Oracle y poder llegar al fondo del problema, pero esto te da armas para poder localizar donde esta el error.

Misc: Concatenar un Rango de Celdas en Excel en una sola celda

Se que esto no tiene mucho que ver con base de datos, pero es un tip que quiero mantener a la mano y que me ha ayudado para resolver rápidamente un problema de concatenar muchas celdas y no meterme en muchos embrollos.

Vamos a decir que quieres concatenar en una celda el rango de A1 a A5 separados por una coma

• Posicionate en la celda B1.
• Teclea =TRANSPOSE(A1:A5)&", " en la barra de formulas
• Aprieta la tecla F9.
• Borra los brackets que se pusieron al principio y al final.
• Teclea =Concatenate( al principio de la barra de formulas
• Teclea ) al final de la barra de formulas
• Aprieta Enter

Un buen truco para poder mandar un comando en sqlplus via nohup y poder irte a dormir

Uno de las grandes desventajas que tenemos como DBAs es que mucho de nuestro trabajo son a deshoras, y de igual manera requieren de scripts que toman a veces dos o tres horas en correr, asi que si son las dos de la mañana, tres horas de poder dormir a nadie le caen nada mal, especialmente si lo unico que tienes que es estar monitoreando y asegurandote que un script corra bien.

Asi que una manera para que te puedas ir a dormir y nada mas despertarte es si llega a fallar el script

Lo primero que ahi que hacer, y esto es importante que en el ambiente que lo hagas, tengas el permiso para poder hacerlo, es poner el password en un archivo de texto y con permisos 400

oracle@servidor1.oracleenespanol.blogspot.com [TESTDB1] /mount/dba01/oracle/TESTDB/scripts
oracle $ ls -ltr passfile.txt
-r-------- 1 oracle oinstall 13 Jun  30 20:58 passfile.txt


oracle@servidor1.oracleenespanol.blogspot.com [TESTDB1] /mount/dba01/oracle/TESTDB/scripts
oracle $ cat passfile.txt
hr:12345

En un script de shell de unix vas a poner lo que esta abajo

. ${HOME}/bin/TESTDB
HR_PASS=`cat  /mount/dba01/oracle/DBATEST/admin/passfile.txt | grep hr | cut -d: -f2`
LOG_DIR=${SID_HOME}/audit
sqlplus /nolog <<EOF > ${LOG_DIR}/test.log
connect hr/${HR_PASS}
select sysdate from dual;
exit
EOF

oracle_error=`cat ${LOG_DIR}/test.log | grep "ORA-" | wc -l`
if [ ${oracle_error} -gt 0 ]; then
     echo "###############################################################"
     echo "## ERROR ====> Unable to get the Date"
     cat ${LOG_DIR}/test.log | grep ORA- | awk '{print "##", $0}'
     echo "###############################################################"
     mailx -s "Error in Getting the Time" rene.antunez@blogspot.com < ${LOG_DIR}/test.log
     exit 1
fi

Ya una vez que tengas tu shell script, ya nada mas lo tienes que mandar en modo nohup y te puedes ir a dormir o comer en lo que corre tu script, si llega a fallar, te llegaria un correo con el error y donde es que fallo. De igual manera, puedes cambiar el select por un script de sql.

oracle@servidor1.oracleenespanol.blogspot.com [TESTDB1] /mount/dba01/oracle/TESTDB/scripts
oracle $ nohup ./test.sh &

Como Flashback Drop me salvo mucho trabajo

Peoplesoft tiene una peculiaridad que no me gusto mucho, una de las maneras que tienen para modificar la estructura de una tabla es que crea una tabla con un nombre temporal,  de ahí hace un insert into de un select , y de aquí lo que hace es tira la tabla original y renombra la tabla temporal al nombre de la tabla original.

Antes de hacer todo esto es altamente recomendable tener un buen respaldo de tu base de datos, si es una tabla pequeña , con un export puede bastar, pero si es una tabla bastante grande un export puede ser tardado y un poco latoso.

El otro día tuve que estar al pendiente de unos cambios hechos de esta manera, como eran pocas tablas con un tamaño relativamente chico de 10 millones de entradas cada una , así que me asegure que el respaldo de la base de datos fuera consistente y también para mi salud mental, tome un export, aunque me tome un poco de espacio y tiempo, quería que cualquier cosa poder recuperar rápido y sin tener que recuperar toda la base de datos, cabe decir que eran catálogos, así que el equipo funcional y yo sabíamos que los datos no iban a cambiar mientras los exportabamos.

Antes de empezar , me asegure que el recyclebin estuviera prendido

TESTDB> show parameter recyclebin

NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
recyclebin                           string      on

Al correr uno de los scripts, la Ley de Murphy entro en accion, este trono a la mitad por que uno de los cambios estructurales que se estaba haciendo era pasar un campo a que tuviera la restricción de NOT NULL, pero el script continua aunque haya fallado ahí, así que tiro la tabla original , y renombro la tabla con nombre temporal al que tenia la original, quedandos con una tabla vacía, como se ve abajo :

TESTDB> create table temporal(id number,name varchar2(30) not null);
Table created.

TESTDB> insert into temporal (id,name) select id,name from test;

insert into temporal (id,name) select id,name from test
                                              *
ERROR at line 1:
ORA-01400: cannot insert NULL into ("RENE"."TEMPORAL"."NAME")

TESTDB> drop table TEST;

Table dropped.

TESTDB> rename TEMPORAL to TEST;

Table renamed.

TESTDB> select count(1) from TEST;

 
 COUNT(1)

----------
       
  0

En lugar de ponerme a restaurar la tabla del respaldo que habia tomado antes de empezar, lo unico que tuve que hacer es identificar en el recyclebin la tabla que habia tirado, tirar la tabla que se habia renombrado de TEMPORAL a TEST en el script anterior, ya que esta era la  tabla sin datos y de ahi hacer un flashback before drop para que TEST volviera a tener los datos antes del comando DROP

TESTDB>  SELECT object_name,original_name,droptime  
2  FROM recyclebin;

OBJECT_NAME                    ORIGINAL_NAME                    DROPTIME
------------------------------ -------------------------------- -------------------
BIN$wtQeQ7eoQJ7gQAAAAAAbEQ==$0 TEST_IDX                         2012-06-19:06:27:01
BIN$wtQeQ7epQJ7gQAAAAAAbEQ==$0 TEST                             2012-06-19:06:27:01


TESTDB> drop table TEST;

Table dropped.

TESTDB> FLASHBACK TABLE "BIN$wtQeQ7epQJ7gQAAAAAAbEQ==$0" TO BEFORE DROP;

Flashback complete.

TESTDB> select count(1) from TEST;

  COUNT(1)
----------
         3

En versiones anteriores a 11.2.0.2 si mal no recuerdo, todavia si existia un indice de la tabla , tambien tenias que sacarlo del recyclebin, y es tan facil como renombrar al indice, en 11.2.0.2, los indices se recuperan con el flashback.

Esta tecnica es muy buena para cuando haz hecho un drop de una tabla y rapidamente necesitas recuperarla, espero te ayude como a mi lo ha hecho en ciertas ocasiones.