copiar datafile desde base primaria a standby con ASM

Hace poco me encontré con un datafile en una standby que tenia problemas (standby 12c con ASM). En resumen este era el error que se ve en la standby:

Mon Feb 19 18:21:21 2018
Errors in file /oracle/app/oracle/diag/rdbms/sarchive/SARCHIVE1/trace/SARCHIVE1_pr00_12911036.trc:
ORA-00448: normal completion of background process
Mon Feb 19 18:21:21 2018
Errors in file /oracle/app/oracle/diag/rdbms/sarchive/SARCHIVE1/trace/SARCHIVE1_mrp0_4718782.trc:
ORA-00756: recovery detected a lost write of a data block
ORA-10567: Redo is inconsistent with data block (file# 652, block# 3, file offset is unknown bytes)
ORA-10564: tablespace APPS_TS_TX_IDX
ORA-01110: data file 652: '+ARCHIVE/SARCHIVE/DATAFILE/apps_ts_tx_idx.515.968523631'
ORA-10560: block type '0'
Mon Feb 19 18:21:21 2018

Ahora lo primero que se me ocurria era copia el datafile desde la primaria hacia la standby, pero como esta en ASM ambas bases de datos, hay que hacer un par de pasos adicionales. Estos pasos estan comentados en la siguiente nota:

How to Copy ASM datafile From Primary Database to Standby Database on ASM using RMAN (Doc ID 605234.1)


Bueno en resumen lo que hice fue obtener el nombre del archivo en la primary con el numero de datafile que tiene problemas en la standby (numero de datafile 652). Posteriormente usando rman en la primaria ejecute el siguiente comando:

RMAN> copy datafile '+ARCHIVE/ARCHIVE/DATAFILE/apps_ts_tx_idx.1304.968523459'  to '/gg/gg12c/respaldo/backup_file.dbf' ;

Starting backup at 19-FEB-18
using target database control file instead of recovery catalog
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=2 instance=ARCHIVE2 device type=DISK
channel ORA_DISK_1: starting datafile copy
input datafile file number=00652 name=+ARCHIVE/ARCHIVE/DATAFILE/apps_ts_tx_idx.1304.968523459
output file name=/gg/gg12c/respaldo/backup_file.dbf tag=TAG20180219T183516 RECID=5 STAMP=968524773
channel ORA_DISK_1: datafile copy complete, elapsed time: 00:04:25
Finished backup at 19-FEB-18

Aquello me generó el archivo: /gg/gg12c/respaldo/backup_file.dbf el cual debemos copiarlo a la standby:

scp /gg/gg12c/respaldo/backup_file.dbf t423:/gg/gg12c/respaldo/t423:/gg/gg12c/respaldo/             
oracle@t423's password:
backup_file.dbf                                                                  100%   29GB  24.7MB/s   20:16


Ahora nos ubicamos en la base de datos standby y procederemos a catalogar el nuevo archivo de backup:

rman target /

Recovery Manager: Release 12.1.0.2.0 - Production on Mon Feb 19 19:37:30 2018

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

connected to target database: ARCHIVE (DBID=4129028332, not open)

RMAN> Catalog datafilecopy '/gg/gg12c/respaldo/backup_file.dbf' ;

using target database control file instead of recovery catalog
cataloged datafile copy
datafile copy file name=/gg/gg12c/respaldo/backup_file.dbf RECID=8 STAMP=968528258


Ahora restauramos el datafile usando ese backup (sobre la standby):
RMAN> copy datafilecopy '/gg/gg12c/respaldo/backup_file.dbf'  to '+ARCHIVE';

Starting backup at 19-FEB-18
using channel ORA_DISK_1
channel ORA_DISK_1: starting datafile copy
input is copy of datafile 00652: /gg/gg12c/respaldo/backup_file.dbf

output file name=+ARCHIVE/SARCHIVE/DATAFILE/apps_ts_tx_idx.1308.968528345 tag=TAG20180219T183516 RECID=9 STAMP=968531536
channel ORA_DISK_1: datafile copy complete, elapsed time: 00:53:15
Finished backup at 19-FEB-18

Ahora desde la base de datos standby via sqlplus (cambiaremos el nombre del archivo ocupando el file_name antiguo:

SQL> Alter system set standby_file_management=manual scope=both sid='*' ;

System altered.

SQL> Alter database rename file '+ARCHIVE/SARCHIVE/DATAFILE/apps_ts_tx_idx.515.968523631' to

'+ARCHIVE/SARCHIVE/DATAFILE/apps_ts_tx_idx.1308.968528345' ;  2

Database altered.

SQL> Alter system set standby_file_management=auto scope=both sid='*' ;

System altered.

SQL> alter database recover managed standby database disconnect from session ;

Database altered.

Si por algun motivo se nos olvida poner de nuevo standby_file_management en auto la recuperacion de la standby se nos caera si es que desde la primary se crea un nuevo datafile mientras nosotros estabamos arreglando este problema. En el alert log de la base de datos aparecera que no se puede crear el siguiente archivo con un nombre similar a esto: UNNAMED00653

SI esto llegara a pasar hay que crear el archivo desde 0 usando lo siguiente (en ASM y con OMF activo)

alter database create datafile '/oracle/app/oracle/product/12.1.0/db_1/dbs/UNNAMED00653' as new;

Luego de esto dejar activo nuevamente el parametro:

Alter system set standby_file_management=auto scope=both sid='*' ;

Espero haya servido :)

PD: no olvidar eliminar el archivo original de backup tanto en la primaria como en la standby:

RMAN>  delete datafilecopy '/gg/gg12c/respaldo/backup_file.dbf' ;

using target database control file instead of recovery catalog
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=2 instance=ARCHIVE2 device type=DISK
List of Datafile Copies
=======================

Key     File S Completion Time Ckp SCN    Ckp Time
------- ---- - --------------- ---------- ---------------
5       652  A 19-FEB-18       51336108383 19-FEB-18
        Name: /gg/gg12c/respaldo/backup_file.dbf
        Tag: TAG20180219T183516


Do you really want to delete the above objects (enter YES or NO)? y
deleted datafile copy
datafile copy file name=/gg/gg12c/respaldo/backup_file.dbf RECID=5 STAMP=968524773
Deleted 1 objects


RMAN>

12cR1 impdp con dblink ocupando opcion DISABLE_APPEND_HINT no funciona (lo omite por un bug)

La fotografia es de mi querido y bello Sobrino Matteo :)

Hace poco por un requerimiento de un cliente en dónde se necesitaba ejecutar varios comandos impdp que inyectaban datos sobre la misma tabla, me di cuenta que la versión 12cR1 (12.1.0.2) no toma en cuenta el parámetro DATA_OPTIONS=DISABLE_APPEND_HINT, simplemente lo omite por un BUG que afecta a esta versión de base de datos. Recordar que se debe deshabilitar el hint APPEND que realizan los import por default, porque de otro modo no mepermitira realizar otras inyecciones de datos sobre la misma tabla. No olvidemos que el hint APPEND realiza un bloqueo completo sobre la tabla, dejando al resto de los procesos impdp en estado waiting enq-tm contention o similar)

Bueno como les decia esto se trata de un BUG que a continuación les mencionaré. En el ejemplo siguiente me di cuenta problema:

impdp "user1/sdqweq"  PARALLEL=4 directory=impdp logfile=proceso01.log  network_link=dblink1 TABLES=table2:part01  Query=user1.table2:\"where APPLICATION_ID=20004 and AE_HEADER_ID like \'1\%\'\"  INDEXES=NO CLUSTER=NO EXCLUDE=STATISTICS  DATA_OPTIONS=DISABLE_APPEND_HINT TABLE_EXISTS_ACTION=APPEND

Luego de ejecutado el impdp procedemos a revisar la base de datos y se puede apreciar que la sesión del import ejecuta el siguiente comando:

INSERT /*+ APPEND NESTED_TABLE_SET_REFS  */ INTO    "user1"."table2"  KUT$ ("......

Como se puede apreciar efectivamente utiliza el hint append a pesar que en el comando impdp anterior se pone explicitamente que no lo haga.

Todo esto es parte del siguiente bug:
BUG:25684960 - IMPDP DATA_OPTIONS=DISABLE_APPEND_HINT IS IGNORED WHEN USING NETWORK_LINK

Ese bug es mencionado en la nota de soporte:
DataPump Network_Link Import Ignores DISABLE_APPEND_HINT (Doc ID 2273873.1)

En la misma nota se explica que el bug es solucionado aplicando el parche:
Patch 25972261: MERGE REQUEST ON TOP OF 12.1.0.2.0 FOR BUGS 25139545 25684960

Luego de aplicado el parche en el motor de base de datos y posteriormente ejecutado nuevamente el comando de import, se puede ver que efectivamente ya no se vuelve a ocupar el hint append permitiendo que otras sesiones pueden ingresar o modificar datos en la misma tabla:

INSERT /*+ NESTED_TABLE_SET_REFS  */ INTO    "user1"."table2"  KUT$ ("......

Espero haya servido amigos saludos.

Error al ejecutar datapatch: "make_path" is not exported by the File::Path module (Doc ID 1904046.1)

Estimados,

 les dejo un Tips de un error que ocurre a menudo cuando se aplica datapatch. Cuando se va a aplicar un parche de base de datos (el paso de ejecutar el datapatch) es un error comun ver el siguiente mensaje (sobre todo en ambientes con bastantes ORACLE_HOME o más de alguna versión distinta del motor de base de datos):

laboratorio01[/oracle/app/oracle/product/12.1.0/db_1/OPatch] ./datapatch
"make_path" is not exported by the File::Path module
Can't continue after import errors at /oracle/app/oracle/product/12.1.0/db_1/sqlpatch/sqlpatch.pm line 166
BEGIN failed--compilation aborted at /oracle/app/oracle/product/12.1.0/db_1/sqlpatch/sqlpatch.pm line 166.
Compilation failed in require at /oracle/app/oracle/product/12.1.0/db_1/sqlpatch/sqlpatch.pl line 67.
BEGIN failed--compilation aborted at /oracle/app/oracle/product/12.1.0/db_1/sqlpatch/sqlpatch.pl line 67.


El anterior mensaje sucede cuando no estamos ejecutando correctamente el comando anterior con las variables de ambiente de acuerdo a la instalación que nos corresponde. En mi caso me pasaba que las siguientes variables de ambiente se encontraban apuntando a un ORACLE_HOME distinto. Por lo que se sugiere revisar que estas variables apunten correctamente al ORACLE_HOME sobre el cual existe la base de datos que parcharemos:
export PERL5LIB=/oracle/app/oracle/product/12.1.0/db_1/perl/lib
export PERLBIN=/oracle/app/oracle/product/12.1.0/db_1/perl/bin

Ver la siguiente nota como referencia:
datapatch -verbose fails with error "Perl lib version (5.10.0) doesn’t match executable version (v5.14.1) " (Doc ID 1904046.1)

Luego de declaradas las variables de ambiente PERL5LIB y PERLBIN como corresponde el datapatch funcionará sin problemas.