Juan Andres Mercado Oracle Blog – IT Buenos Aires

Troubleshooting daily on Oracle Systems, Linux & more !

Tag Archives: RMAN

Golden Gate || When we start REPLICAT with AFTERCSN or ATCSN

Start REPLICAT with AFTERCSN or ATCSN ?

Buenas Tardes Amigos, esta semana estuve en un cliente donde pude observar en sus instalaciones muchos issues o configuraciones no correctas.

No es culpa del cliente en ningun momento, solamente verifico que parte del equipo tenia muchos erroes de conceptos acerca de Golden Gate como de otros productos.

En parte de mis experiencias, esta semana tuvimos que recuperar varias replicaciones por caidas de plataformas con Golden Gate que no tenian monitoreo ni contaban con politicas de backup adecuadas.

En parte de la recuperacion de las replicas, una en particular debimos hacer nuevamente los Initial Load de tablas, ya que no se encontraban los trails necesarios para aplicar.

Por parte de uno de los DBA locales surgio el siguiente cuestionamiento:

Que debemos utilizar para la comenzar la replica ?? AFTERCSN o ATCSN ??

Y mi respuesta fue:

Cuando instanciamos una nueva base de datos TARGET, con datos provenientes de un SOURCE database, el proceso de REPLICAT debe coincidir y ser coherente con el methodo que elegimos para realizar el INITIAL LOAD.

Por ello:

  • AFTERCSN es utilizado para comenzar el REPLICAT (START REPLICAT) si la metodologia escogida para instanciar el target , fue datapump.
    El export es ejecutado, y debe ser consistente en un valor FLASHBACK_SCN.
    Debe ser pasado como parametro en el archivo de par file o en la sentencia de ejecucion.

Read more of this post

Oracle RAC 11gR2 | ORA-00245: control file backup operation failed

 ORA-00245: Conociendo como ocurre el error

Oracle RAC

Oracle RAC (Photo credit: Fenng(dbanotes))

Desde la version de bases de datos oracle 11gR2 la copia de seguridad del controlfile sucede sin tener que holdear las colas de actualizacion del controlfile.

Cuando tenemos una base en single mode o mejor dicho standalone, esta situacion no cambia para nada.

Ahora si nosotros estamos trabajando en RAC (y debido a la cambios que se realizaron para las versiones de bases de datos 11gR2) provocan que cualquier instancia del cluster pueda escribir en el controlfile de manera instantanea.

Es asi que este snapshot del controlfile debe estar disponible (visible) para todas las instancias.

Por que ocurre el error ?

El snapshot del controlfile debe ser accesible para todos los nodos de una base de datos en RAC y si el snapshot no esta, o hay un error en el dispositivo compartido ocurrira que al momento de la copia de seguridad que realiza el RMAN mostrara un error.

Estos siempre ocurriran cuando tomemos un backup usando sqlplus, tengamos configurado un backup del controlfile como AUTOBACKUP o no poseamos una ubicacion compartida.

Ahora veamos unos ejemplos de errores comunes.

Ejemplo 1:

En un ambiente RAC, el controlfile autobackup falla con el error ORA-0245

Autobackup of controlfile in RMAN is failing with error:
RMAN-571: ===========================================================
RMAN-569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-571: ===========================================================
RMAN-3009: failure of Control File and SPFILE Autobackup command on
ORA_DISK_1 channel at 10/27/2010 15:08:59
ORA-245: control file backup operation failed

Read more of this post

RMAN Querys | Monitoring backups status: COMPLETED, START_TIME, END_TIME & TIME TAKE

G RMAN

G RMAN (Photo credit: Joe Mud)

Hoy voy a compartirles un query que nos es de mucha utilidad cuando trabajamos con backups de RMAN y nos encontramos realizando reportes.

Podemos utilizarlo para conocer el tiempo que tardo cada backup segun una determinada fecha y segun el tipo de backup que tomamos.

Los mismos podrián ser DB FULL , ARCHIVELOG , INCREMENTAL , etc.

También conocer el tipo de STATUS con el que finalizo.

Ya sea COMPLETED o FAILED.

El query en cuenstion es :

set serveroutput on
set linesize 150
set pagesize 300
col time_taken_display for a9

select session_key,
input_type,
status,
to_char(start_time,'yyyy-mm-dd hh24:mi') start_time,
to_char(end_time,'yyyy-mm-dd hh24:mi') end_time,
time_taken_display
from v$rman_backup_job_details
order by session_key desc;

El query esta formado a partir de la vista v$rman_backup_job_details, siendo la misma muy útil Read more of this post

ORA-27054: NFS file system where the file is created or resides is not mounted with correct options

Unix filesystem

Image via Wikipedia

Utilizo con frecuencia un filesystem compartido NFS entre varios equipos para convertir el pasaje de archivos de un servidor a otro de la manera mas rápida posible.

Cuando trabajo con RMAN nunca tuve inconvenientes, pero al momento de importa o exportar un schema, tablas , etc me encuentro con el siguiente error:

Connected to: Oracle Database 10g Enterprise Edition Release 10.2.0.4.0 - 64bit Production
With the Partitioning, Real Application Clusters, OLAP, Data Mining
and Real Application Testing options
ORA-39001: invalid argument value
ORA-39000: bad dump file specification
ORA-31640: unable to open dump file "/tsm/prod/apps/day/EXP_DAPRO.dmp" for read
ORA-27054: NFS file system where the file is created or resides is not mounted with correct options
Additional information: 3

Buscando en varios lugares encontre de las mas variadas soluciones, que van desde utilizar un filesystem local no NFS (Como hago con un archivo de 30G o más ??) hasta colocar parametros inexistentes. 😀 Read more of this post

RMAN-03014: implicit resync of recovery catalog failed

RMAN-20020: database incarnation not set

file under Holy Fuck

Image by emdot via Flickr

Estaba realizando pruebas de RMAN para retornar en un punto en el tiempo por medio de arch’s.

Cuando finalizaba la ejecucion del ciclo de pruebas tomaba un backup de los archives.
Luego de ello rompia la base, hacia el restore y comenzaba el recovery hacia un determinado punto en el tiempo.

Pero cuando estaba terminando un ciclo ocurrio un problema a la hora de tomar el backup de los arch’s.

El problema traia como consecuencia , no poder tomar el backup de los archives.

$ rman target / catalog=rman@catrman

RMAN> run 
  {
   allocate channel oem_backup_disk1 type disk ;
   allocate channel oem_backup_disk2 type disk ;
   allocate channel oem_backup_disk3 type disk ;
   allocate channel oem_backup_disk4 type disk ;
 2> 3> 4> 5> } 

allocated channel: oem_backup_disk1
channel oem_backup_disk1: sid=646 devtype=DISK

allocated channel: oem_backup_disk2
channel oem_backup_disk2: sid=651 devtype=DISK

allocated channel: oem_backup_disk3
channel oem_backup_disk3: sid=654 devtype=DISK

allocated channel: oem_backup_disk4
channel oem_backup_disk4: sid=642 devtype=DISK
released channel: oem_backup_disk1
released channel: oem_backup_disk2
released channel: oem_backup_disk3
released channel: oem_backup_disk4

RMAN> backup as COMPRESSED BACKUPSET tag '$TAG' archivelog all format '/tsm/t2/t2p/diario/%T_%d_ARC_PRE_DBID%I_s%s_p%p_arc';

Starting backup at 17-MAY-11
current log archived
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of backup command at 05/17/2011 15:03:58
RMAN-03014: implicit resync of recovery catalog failed
RMAN-06004: ORACLE error from recovery catalog database: RMAN-20020: database incarnation not set
Que podria estar ocurriendo ?

Cuando terminas de realizar un recover de una base , Read more of this post

%d bloggers like this: