Hola, estamos en la versión 2.7 y hace 2 días empezamos a tener problemas con los backup. Si bien se realizan, el error aparece cuando tratamos de levantarlos. Les dejo el momento en que se quedan.
create table “dba”.aud_log_ingresos
(
log_ingreso serial not null ,
unidad_academica varchar(5) not null ,
identificacion varchar(20) not null ,
codigo_retorno smallint not null ,
mensaje_retorno varchar(255),
fecha_hora datetime year to second
default current year to second not null ,
interfaz smallint,
primary key (log_ingreso) constraint “dba”.aud_log_ingresos
) extent size 14780 next size 1478 lock mode row;
*** Import data is corrupted!
Estan realizando una importación de la base con el dbimport, no?
Si es asi, lo que pueden hacer es en el archivo con extension “sql” generado por el dbexport, comentar la linea donde importa los datos de esta tabla, en ese archivo vas a tener algo como lo siguiente:
{ TABLE "dba".aud_log_ingresos row size = 320 number of columns = 8 index size =
12 }
{ unload file name = aud_l00516.unl number of rows = 1685 }
create table "dba".aud_log_ingresos
(.....
Debes sacar de ese archivo la linea sigueinte que es la que indica al dbimport que importe los datos del archivo, en este caso el archivo aud_l000516.unl a la tabla aud_log_ingresos:
{ unload file name = aud_l00516.unl number of rows = 1685 }
Si es que el problema esta en los datos de este archivo.
No hay problema si no importas esos datos, ya que esta tabla solo se usa para registrar los ingresos al G3w2. Igualmente conservala por si en algun momento debes verificar el ingreso de algun usuario al sistema.
¿Realizan backup con el comando ontape ?
Porque el dbexport solo es una copia de la base al momento en que se realizó el mismo. No esta demas hacerlo cada cierto tiempo, pero lo mas importante es que tengan presente hacer el backup de la base de datos y de la instancia del motor con el comando ontape.
Realizamos un dbexport diario.
Ahora si levanto la base, el tema es que dato tira el error en esa tabla o sera la cantidad de registro, ya que tiene casi 900000 registros.
La cantidad de filas que esta indicada en el archivo sql corresponde con la cantidad de filas del archivo .unl ?
{ unload file name = aud_l00516.unl number of rows = 1685 }
Si no coinciden este puede ser un probable origen del error. A veces si no se corre el comando para actualizar las estadisticas de distribucion de los datos en las tablas (update statistics …), hace que en tablas como estas donde el volumen de registros crece períodicamente puede ser que quede desactualizado el dato de cantidad de filas que la tabla tiene con respecto al nro real de filas que tiene la tabla.
Otro problema puede ser que ese archivo este corrupto.
Recuerden cada tanto vaciar esa tabla previo backup…
Con respecto al backup, si solo realizan un dbexport diario, deberian considerar hacer un ontape -s y backupear los logs. El dbexport, sirve como backup pero tiene limitaciones, el ontape por otro lado permite tener una politica de backup mas completa ya que maximiza la cantidad de datos a recuperar en caso de una falla
No, ese fue un ejemplo que yo te envie de un dbexport que tengo aca de una base, en tu base seguramente el archivo .unl que corresponde a esa tabla se llame diferente. Vos debes buscar el archivo que esta mencionado en el archivo .sql que genero el dbexport en donde dice:
{ TABLE “dba”.aud_log_ingresos row size = 320 number of columns = 8 index size =
12 }
{ unload file name = aud_lxxxxx.unl number of rows = zzzz }
En mi experiencia las 2 causas más frecuentes de ese error es:
la diferencia entre la cantidad de lineas declaradas en el SQL del export y la cantidad real de líneas que tiene el archivo .unl correspondiente. En este caso, simplemente con colocar en el SQL la cantidad real de líneas del archivo.unl se supera el problema
algún carácter extraño y/o no compatible con la definición de alguna columna. Esto ya es más complicado y habría que ver cual es el caso.
Obviamente, todo lo que te comentaron Alejandro e Ignacio es completamente válido.