Technological recipes that I've held to prepare some solutions DBA environment. (by Felipe Donoso Bastias)

21 Apr 2016

Oracle: Error en RMAN ORA-19563 al respaldar un archivelog






Hace poco obtuve un error de este tipo en un respaldo de archivelog de un cliente:


current log archived
released channel: t1
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of backup command at 04/20/2016 15:17:29
ORA-19563:  header validation failed for file

Lo anterior era lo que mostraba el log de respaldo. Sumado a esto tuve el problema que dicho respaldo se gatillaba desde un servidor pivote que via tnsnames se conectaba a la base de destino. Tampoco tenia posiblidad de revisar el alert log de la base de datos ni tampoco el trace. El servicio terminal service del servidor de base de datos tenía problemas (era un f**king windows) y el área de archivelog ya se estaba llenando por lo que había que resolver esto rápidamente.

Ahora como no tenemos acceso al servidor para revisar los logs como mencioné  anteriormente, he vuelto a ejecutar el respaldo rman desde este server de pivote, usando la opción de rman llamada TRACE con el fin de obtener en este server de pivote el log de la falla, y ahí apareció la causa de mi problemática:
(la opción  TRACE es un parámetro que se añade al invocar el comando rman de la siguiente forma: rman user/pass@destino catalog .....  debug trace='destino_del_archivo_de_trace.trc' )

[Extracto de log de trace de rman una vez terminado el respaldo fallido]
aqui el extracto del trace donde esta el error:
 +2710  DBGMISC:         EXIT
 +2711  DBGMISC:         Exiting krmkgconf [15:44:23.618]
 +2712  DBGMISC:         copies = 1
 +2713  DBGMISC:        EXITED krmkgdconf [15:44:23.618] elapsed time [00:00:00:00.000]
 +2714  DBGMISC:        krmsod2s: time is: 6/12/2015 11:6:15 = returning: 897735975
 +2715
 +2716  DBGSQL:         EXEC SQL AT CHANNEL begin :rc := sys . dbms_backup_restore . validateArchivedLog ( recid => :recid , stamp => :stamp , fname => :fname , thread => :thread , sequence => :se
q , resetlogs_change => :rstscn , first_change => :lowscn , blksize => :blksize , signal => :sigerr , terminal => :terminal ) ; end ; [15:44:23.618]
 +2717  DBGSQL:            sqlcode=0 [15:44:23.638]
 +2718  DBGSQL:               :b1 = 5
 +2719  DBGSQL:               :b2 = 1818
 +2720  DBGSQL:               :b3 = 909522066
 +2721  DBGSQL:               :b4 = "F:\ORACLE\ARCHIVE\FRGT\ARC01820_0897735975.001"
 +2722  DBGSQL:               :b5 = 1
 +2723  DBGSQL:               :b6 = 1820
 +2724  DBGSQL:               :b7 = 50948083361
 +2725  DBGSQL:               :b8 = 50974453830
 +2726  DBGSQL:               :b9 = 512
 +2727  DBGSQL:               :b10 = 0
 +2728  DBGSQL:               :b11 = 0
 +2729  DBGMISC:        krmsod2s: time is: 6/12/2015 11:6:15 = returning: 897735975
 +2730
 +2731  DBGSQL:         EXEC SQL AT CHANNEL begin :rc := sys . dbms_backup_restore . validateArchivedLog ( recid => :recid , stamp => :stamp , fname => :fname , thread => :thread , sequence => :se
q , resetlogs_change => :rstscn , first_change => :lowscn , blksize => :blksize , signal => :sigerr , terminal => :terminal ) ; end ; [15:44:23.640]
 +2732  DBGSQL:            sqlcode=-19563 [15:44:23.645]


(Tomar nota que la parte dónde dice returning: 897735975  , dicho número se refiere al identificador del archivo trace, por lo que si buscan en la carpeta dónde se encuentra el alert log algún trace con dicho número les aparecerá el error RMAN también, pero como no tengo acceso al sistema operativo windows no puedo mostrar aquello)


Como se puede apreciar en el log, RMAN invoca antes de respaldar los archivelogs el package de base de datos sys.dbms_backup_restore.validateArchivedLog. Se podrán dar cuenta que al momento de validar el header de la secuencia 1820 con el nombre de archivelog "F:\ORACLE\ARCHIVE\FRGT\ARC01820_0897735975.001" dicha validación de ese archive devuelve el codigo de error  ORA-19563 (ver linea  dónde esta el extracto de log sqlcode=-19563). En conclusión como dice el error ese archivelog quedó con un header inválidado. Ahora, revisando en la base de datos la fecha de generación de, archivelog, esta coincide con que al segundo posterior la base de datos fue bajada abruptamente. Eso se debió a que la máquina fue apagada sin bajar el motor de la  base de datos. Por otra parte busqué en metalink como arreglar esto y existe un workaround en la nota  [Backup Of Archivelogs Getting Error ORA-19563 (Doc ID 1589870.1)] la cual dice que hay que cambiar el nombre a ese archive, junto con el correspondiente crosscheck archivelog.

Pero yo desde RMAN hice lo siguiente que es mejor desde mi punto de vista. Es así:  dejamos la secuencia no disponible (queda así hasta que alguien vuelva a habilitarla) con el siguiente comando:
change archivelog from logseq = 1820 until logseq =1820 unavailable;

Luego ejecuté el backup de archive usando el comando skip inaccesible para no respaldar ese archive que recién modificamos, ejemplo:

  backup
      format 'log_%t_%sp%p'
      (archivelog all  skip inaccessible  delete input);


Finalmente se ejecuta el script de respaldo archive (el que se siempre se ha ejecutado por crontab desde este server pivote de linux,  tal cual está y ya no da problemas.

Fue una solución rápida y simple. Luego al revisar el archive me percaté que el tamaño en KB del archivelog era 0. No hubo manera de arreglar dicho archivelog. Supongo que se debió a que cuando se apagó la máquina el archivelog aún no terminaba de generarse, o debe ser otra causa. Sin acceso al SO no puedo identificar aquello.

Espero que haya sido útil.


Saludos.
felipower.

Share:

0 Comments:

Copyright © DBA TIPS | Powered by Blogger
Design by SimpleWpThemes | Blogger Theme by NewBloggerThemes.com | Free Blogger Templates