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.
No comments:
Post a Comment