hola a todos, tenemos el siguiente problema: Buscamos las inscripciones que tiene un estudiante x (buscándolo por legajo), tiene inscripción en una comisión y. Pero si tiramos un listado de inscriptos a esa comisión y, este estudiante x no aparece.
Cuando intentamos restaurar un backup, se cortó cuando iba a crear la tabla sga_insc_cursadas. Controlamos la cantidad de registros del archivo sga_i0264.unl y la cantidad que figura en el sql de restauración, y tiene 25 registros de diferencia, es decir, nos faltarían 25 registros en el unl.
Hicimos el oncheck -cI y nos tiraba que había que borrar y recrear los índices de la tabla. Lo hicimos y corrimos las estadísticas. Luego, tiramos nuevamente el oncheck y ahora no nos dio error.
Hicimos nuevamente las consultas del estudiante x y la comisión y, y ahora si nos lo muestra.
Ahora, cuando hicimos un backup nuevamente, otra vez nos da diferentes los números y siempre 25 de diferencia… Que puede estar pasando??
Jackie:
Corrieron las estadísticas sobre la base?
Generalmente ese problema es por falta de correr las estadísticas y más si los índices estaban corruptos. Aparte hay varias formas de correr las estadísticas. Aparte de correr el script que provee el SIU yo correría un UPDATE STATISTICS HIGH sobre toda la base y otro sobre todas las tablas.
Saludos
Gustavo
Si, corrimos las estadísticas sbre todas las tablas, script que generamos con el script que nos da el SIU.
Vamos a probar esto que decís, y te cuento.
Gracias!
saludos
Jacqui
corrimos un UPDATE STATISTICS HIGH y en el backup de hoy temprano pasa lo mismo, en el dbexport figura esto:
{ unload file name = sga_i00264.unl number of rows = 376841 }
y el archivo sga_i00264.unl hay 376816 registros…25 menos…
porqué puede darse esto?
Prueben de borrar la Primary Key y volverla a generar, luego correr el update statistics high sobre esta tabla.
Probar de bajar los datos de la tabla a un archivo con onunload y comparar.
la primary key ya la borramos y la volvimos a generar, corrimos todas las estadísticas de todas las tablas, y también el general de toda la base. De hecho , el índice se solucionó, ya no tira errores el oncheck, pero el dbexport me sigue tirando la inconsistencia entra el número que pone y la cantidad de registros en el txt.
Lo del unload lo estamos viendo, pero como funciona el dbexport?? de donde saca ese numero que pone ahi?
Lo saca de las tablas del sistema. No sé bien cual, tendría que investigar o averiguar, probablemente el la columna nrows de la systables para esa tabla.
Si no lo hacés antes vos, mas tarde me fijo.
Saludos
Gustavo
si, el número coincide… ahora, me pregunto, perdimos datos? porque encima en este momento hay muchísimo movimiento de comisiones, asi que no puedo hacer ningún control, y al subir un backup en prueba(arreglándole ese numerito) sube bien, asi que no tengo forma de controlar nada…
Qué es lo que pudo haber pasado?
Los datos son los que tenés en el archivo UNL, a menos que haciendo un unload obtengas otros o haciendo un select a la tabla la cantidad de registros sea distinta.
Si haciendo un select a la tabla ves que tenés más que en el UNL, yo haría cuanto antes un unload y/o un traspaso a una tabla auxiliar idéntica. Y después vería si borrar todos y restaurarlos del unload o ver como recuperar los datos faltantes. El número del export y la systables se arregla de alguna manera, el faltante de datos de ninguna si no tenés de donde recuperarlos.
Saludos
Gustavo
mirá, si hacemos un select count() a la tabla, nos da que hay 367837, ahora si hacemos un select * y lo bajamos a una temporal, hay 367812. Si hacemos un select count(legajo) nos da 367812, si hacemos un select count(comision) nos da 367812…
ahora, el select count() de donde saca los datos?
No puedo determinar si me faltan datos aun…
Supongo que el select count (*) lo saca de la systables, no cuenta en realidad.
El select count(columna) si la columna no es parte de un indice es la unica que cuenta en realidad, y si le ponés un where con seguridad, ya que la unica manera de encotrar la cuenta de valores de una tabla que no están en un indice es hacer un scan sobre la tabla.
Por lo visto, perdieron algunos valores o nunca existieron. Es una tabla importante? Que tabla era?
Saludos.
Gustavo
Si, eso fue lo primero que pensamos. Pero ahora creemos que no, de hecho en este momento tenemos 3 valores distintos:
- lo que nos dá el select count(*) – 376828
- lo que nos dá el select count(columna de la pk) – 376803
- y lo que figura en systables – 376837
Nota: el valor de systables se actualiza al momento de correr el update statistics con un valor igual al resultado del select count(*)
Y si, la tabla es importante: SGA_INSC_CURSADAS.
Todo comenzó cuando nos reportaron que en una comisión no veian los inscriptos y si se veia la inscrición en la ficha del alumno. A partir de ahí, con ayuda de ustedes, detectamos y corregimos los índices corruptos y, ya por la aplicación los usuarios ven lo que no encontraban (o casi todo).
Debido a este incidente descubrimos que el backup daba un error al intertar ser restaurado y esto pasa desde hace unos pocos días. Existe la diferencia de cantidades entre lo que dice el script que tiene que haber y la cantidad de filas que efectivamente hay en el archivo de datos (siempre 25 de diferencia).
Dos cositas más: si hacemos un UNLOAD de la tabla o la pasamos a una Temporal y luego contamos los registros la cantidad coincide con el select count(columna) por lo que nos inclinamos a pensar que el problema está con el índice.
Saludos, Alberto.
Más allá del indice, importan los datos, el índice siempre se puede regenerar. Están todos los datos en el UNLOAD? O no? O no están seguros?
Yo supongo que cuando decís backup te referís a exports. Tienen exports viejos? Están todos corruptos y/o con la misma cantidad de registros? Tenés idea si los registros que te faltan son de los períodos lectivos vigentes o son de períodos viejos?
Yo no creo que sea tan crítico, 25 inscripciones a cursadas son relativamente fáciles de regenerar, si podés determinar de alguna manera cuales son. Obviamente que es laborioso. Ya tenían generadas las actas de cursado o no? Si estaban generadas, contrastando con las actas podés saber cuales te faltan … Y así se puede seguir pensando …
Saludos
Gustavo
Estamos rastreando eso, los backups que dan ese problema son relativamente pocos, menos de una semana, el tema es que esa tabla en estos días tiene movimiento, cambios de comisión, altas y bajas, de todas maneras dividiendo la tabla,que como habrás visto no es de las más chicas lo podemos chequear, estamos verificando días a día los cambios para estar seguro. Esta previsto regenerar los indices.
Saludos, Alberto.
Hola, medio raro lo de los count(*):
Nunca lo había visto, o no me había dado cuenta.
Piensen en esta opción:
- actualizar estadísticas con el script
- ejecutar revisión de estado de la tabla
oncheck -pt base_de_datos:sga_insc_cursadas
- si todo está en orden, tener a mano el catálogo sql de los objetos relacionados con la tabla, carpeta tablas, indices, fk, triggers
- bajar los datos
unload to sga_insc_cursadas.unl select * from sga_insc_cursadas;
- dropear la tabla
drop table sga_insc_cursadas;
- crear la tabla a partir del catálogo (sin la clave primaria)
load from sga_insc_cursadas.unl insert into sga_insc_cursadas;
- crear la clave primaria
- crear los demás objetos relacionados (fk, triggers, check constraints)
- actualizar estatísticas
La forma de cargar los datos con load podría llegar a dar long transaction…dependiendo de la configuración del motor.
Hay otra forma un poco mas compleja de lograrlo, pero mucho mas efectiva con el comando dbload.
Recuerden además que tienen las tablas de log por cualquier cosa de que un alumno diga que se inscribió y la inscripción no existe.
Es cierto lo último que dice Damian!! Me había olvidado. A partir de la tabla de log de auditoria puede reproducir los movimientos … Y al menos verificar si todos los registros insertados que no tienen una baja de esa inscripción estén en la tabla.
Y el método que propone para regenerarla parece adecuado. De todas maneras primero lo probaría en una base de pruebas … No es cuestión de jorobar con estos temas …
Saludos
Gustavo
Hola, ya borramos el índice, las FK y la PK y las volvimos a crear y la diferencia de 25 registros se mantiene.
Te adjunto el resultado de la ejecución del comando oncheck -pt … para ver si me podés orientar.
Saludos, Alberto.
oncheck-pt.txt (7.23 KB)
Hola, probaron descargar los datos y volver a crear la tabla, luego cargar los datos?
No, todavía no lo hicimos en producción, aunque si en prueba.
La verdad es que estamos casi seguros de que así se soluciona pero queremos saber que pudo haber pasado.
Saludos, Alberto.
Que resultado les dió en prueba? Pudieron recuperar todos los registros incluidos los 25v faltantes?
Saludos
Gustavo