Hola a todos,
les consulto, ya que desde hace un par de semanas, tengo un inconveniente. Semanalmente se realiza un dbexport de la BD Guarani de producción, y luego con este dbexport, se genera una BD de desarrollo mediante un dbimport…
Desde hace dos semanas, no puedo generar la BD de prueba, el dbimport en su ultima linea me indica este error:
{ unload file name = aud_l00629.unl number of rows = 1140655 }
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
);
*** Import data is corrupted!
0 - Unknown error message 0.
Si reviso el archivo de datos aud_l00629.unl no veo problemas “visibles” los datos son correctos, etc.
¿Que puedo revisar para ver este error?
Hola Marcela, por un lado fijate de vaciar cada tanto esa tabla (bajar los datos a un archivo con el comando onunload…) , porque por lo que se ve, tenes habilitado que se registren los ingresos al sistema por el guarani web, con lo cual es una tabla que crece mucho.
Si no te interesa los datos de esa tabla podes borrarlos sin hacer backup.
Podes verificar los indices y el espacio de datos de esa tabla con : oncheck -ciID nombre_base:nombre_tabla
Para borrarlo mas rapidamente podes usar el comando TRUNCATE:
Además de lo que te dijo Alejandro, podés hacer lo siguiente:
Ver que el archívo UNL tenga la cantidad de registros que dice tener (1.140.655) según el SQL del export
Es difícil encontrar algún dato corrupto en esa cantidad de registros, es difícil verlo, pero a veces hay caracteres especiales que al Informix no le “gustan” y producen esas cosas, fijate con un SQL sobre la tabla original que te muestra. Y fijate en los casos de caracteres especiales si en el archivo UNL están igual.
Podés alterar el SQL original del Export y ponerle que esa tabla tiene 0 registros y reemplazar el archivo UNL con uno vacío. Y luego tratar de levantar con un LOAD del archivo original, pero particionando el archivo para poder encontrar más facilmente en que registro está el problema.
Si se me ocurre alguna otra cosa luego, la escribo.
El oncheck no siempre repara OK la corrupcion que se genera en las tablas o indices. Como ultima prueba, yo pondria el informix en modo Quiescent, y correria el oncheck para intentar repararla, quizas en quiescent tengas mas suerte.
Si no la repara, la otra alternativa es crear la tabla desde cero (podrias crearla con otro nombre), con sus indices, pK, fk y cargarle los datos desde un .txt generado previamente o directamente con un insert into nueva_tabla select * from vieja_tabla. Recorda controlar la cantidad de registros y que esten TODOS los registros de la tabla nueva, ya que hay casos en que este problema te corta el barrido sequencial de la tabla corrupta, y no es posible obtener la totalidad de las filas. Todo esto depende de que tipo de corrupcion haya en las tabla. Si todo quedo OK en la tabla nueva, luego renombras las tablas.
Muchas gracias a todos, en consenso con la gente de alumnado, dejamos los últimos dos años de logs de accesos a 3W, guarde en un archivo todos los datos anteriores. Luego los borre de la BD de producción, verifique los “caracteres extraños” en el campo identificación, y eran mas que nada “tabs” como no eran muchos registros, estos fueron eliminados (ya que respondían al mensaje de Usuario no existe).
Mañana vuelvo a generar la BD de desarrollo en Base al nuevo Backup, y confirmo si todo anduvo OK.
Saludos.,