Postgresql pierde registros
Hola.
Tengo una aplicación en delphi7 que conecta a una bd postgres utilizando Zeos. La aplicación funciona perfectamente desde hace varios años. Excepto por que cada tanto pierde registros. El sistema se utiliza para la emisión de comprobantes de acceso a un parque. Cada comprobante emitido actualiza varias tablas. Pasan meses en los que el sistema funciona sin problemas. Pero cada tanto, al arrancar una jornada, se perdieron cientos de registros (de todas las tablas) emitidos en una jornada anterior. Como si almacenara los registros en un chaché. Y cada tanto pierde el caché. Alguien tuvo alguna experiencia similar alguna vez? Desde ya muchas gracias por cualquier comentario Alejandro |
No puedo darte una solución porque desconozco por completo tu programa y el entorno donde está instalado, pero lo que sí es seguro al 100% es que postgresql no pierde registros.
|
No puse código de la aplicación por que el problema no está limitado a una parte.
Lo que puede servir como dato es que la base de datos tiene un servidor dedicado corriendo windows XP, todas las estaciones de trabajo también corren en winxp. Todas las inserciones de registros se hacen con transacciones explícitas. Se abre una transacción, se inserta, se cierra la transacción. Y todo parece funcionar bien, de hecho, cada vez que se emite un ticket, se obtiene su número a partir del número de ticket anterior. Y la correlatividad va perfecta. Solo que cada tanto (a veces pasan meses), es como que el sistema 'retrocede' a un estado anterior. No hay un patrón de tiempor ('vuelve al día anterior'), tampoco de cantidad de registros ('pierde 100 registros'). Están descativados los cachés de disco de windows. Pero la sensación que dá es esa. Como que los datos se fueran almacenando en un caché, y por algun problema (electrico?) cada tanto se borrara ese caché antes de grabar los registros en forma definitiva en el disco. Si alquien opina que esto es muy raro, estoy totalmente de acuerdo !!!!! Saludos Alejandro |
Creo que en windows existe algo de recuperar sistema a un estado anterior cuando ha ocurrido algún problema, puede que, como dices, pueda ocurrir algún corte de electricidad y al reiniciarse el windows decida recuperar el sistema a un estado anterior. No sé, es por dar alguna idea.
|
No creo que sea eso, entiendo que tenés que eso restaura las instalaciones de programas y configuraciones que hayas hecho al sistema operativo, no restaura datos.
De todas formas voy a verificarlo. Muchas gracias !!! Alejandro |
y pq un WinXP como servidor?
no haz pensado en un linux? además que el rendimiento de PostgreSQL e linux es muchisimo mejor. por lo de la perdida de registros... si que es raro. nunca me ha pasado y creo que eso está mas ligada a alguna caracteristica o procedimiento que el usuario del XP está haciendo que a algún bug del mismo PostgreSQL. |
Tiene como servidor un Xp por que inicialmente eran dos pc, una actuando como servidor no dedicado. Más adelante se agregaron puestos y un equipo quedó como servidor dedicado.
Y es cierto, el Postgres anda muy bien, tengo varias aplicaciones funcionando perfectamente, aún en entornos similares (servidor en xp). Pero trato de usar la lógica para determinar que puede estar pasando. No se me ocurre nada del lado de la aplicación, lo único que se me ocurre es que haya algún caché (del sistema operativo o la base de datos) que se pierde por algún motivo. Saludos Alejandro |
Cita:
Una vez me encontré con un caso parecido, cada mes o cada varios meses se perdían datos inexplicablemente, después de mucho buscar, por fin, encontramos el culpable, era un usuario el que los borraba por ciertas discrepancias con la empresa. |
Lo pensé como una posibilidad, pero no hay gente con la capacidad para hacerlo en el lugar. Además, si borran datos, lo hacen con una coherencia impresionante. La emisión de un comprobante actualiza 5 tablas. Y los datos desaparecen consistentemente de las cinco !!
|
¿Y no haces backup todos los días?
|
Si, al final del día se hacen backups. Pero a veces pierde los datos desde la mitad del día, o sea, no resuelvo restaurando un backup. Y para peor, esto está instalado en otra ciudad, no tienen gente capacitada para restaurar un backup, no están conectados a internet. En fin..
De alguna manera siempre se resuelve, pero la idea es evitar el problema, no resolverlo. Como les decía antes, no creo que haya nadie que borre datos, ya que no saben sacar un backup (se hacen automáticos), menos aún restaurarlos. Es como decía un profesor mío en la facultad: 'Si no existieran los usuarios, el desarrollo de software sería perfecto !!!' |
ya miraste en los logs de postgres y de windows a ver que sucede en el momento en que se pierden los registros? o estos también están perdidos?
|
Eso es un buen dato.
El único problema es que no se donde están ambos logs. Alguna pista? Muchas gracias Alejandro |
En windows, no sé, la verdad, puedes mirar las instrucciones o hacer una búsqueda.
Por cierto, a modo de 'casi' broma, justo acaba de salir una noticia en meneame.net que enlaza a este sitio y se titula "10 Consejos para la resolución de problemas técnicos inexplicables" :) |
En windows: en el icono de "mi pc" en xp o el de Equipo en Vista o 7 con el derecho del mouse presionas administrar. Esto abbrirá la consola de administración de Microsoft
en el listado de la columna izquierda verás una opción llamada Visor de Sucesos (XP) o visor de eventos (Vista, 7). Aquí puedes ver la ayuda del sitio de microsoft. Los logs de Postgres se pueden ver en la carpeta pg_log en el directorio de datos (data) XP : C:\Archivos de Programa\Postgres\x.x\data\pg_log Vista,7: C:\Program files\Postgres\x.x\data\pg_log |
Cita:
|
Aunque dices que las transacciones son explícitas, puede que algo ocurra y se quede la transacción pendiente de ser cometida, no obstante pareciendo que sí se ha confirmado. Luego, algo ocurre con el servidor y éste cancela esa transacción (desapareciendo información de la base de datos), ya sea por llegar a un tiempo límite de espera o por alguna operación que muy probablemente no se realiza a diario (respaldos, por ejemplo).
Ante esto, quizá convenga revisar cómo estás manejando las transacciones. La recomendación es nunca abrirlas y cerrarlas explícitamente desde el lado cliente, sino dejar esa tarea al servidor (de aplicaciones o de base de datos). No espero que lo anterior sea de mucha ayuda, pero en algo puede servir. :) Casi, el artículo que enlazas es muy interesante. Suelo hacer todo lo que ahí se sugiere, pero confieso que a veces fallo en el punto 5 (mi apetito por las causas). |
Cita:
|
Cita:
|
Cita:
Tal vez, la informática necesite todavía unos cuantos años para madurar, ya que aún es una "ciencia" joven. Vamos a tener que montar una empresa entre algunos compañeros de aquí :) Eso sí, tendríamos que buscar también expertos en marketing... porque en caso contrario... ¡¡¡ nos morimos de hambre !!!, o como decimos por aquí: "nos comemos los mocos" :D |
Cita:
Casi y yo ya lo intentamos solos, cada quien por su cuenta y en un momento determinado. ¿Algún compañero bueno para la mercadotecnia que se nos una en esta nueva empresa? También necesitamos otros especialistas. :) |
Hace falta como mínimo un experto en marketing y alguien para hacer nuestra web, y una buena idea ¿existe el puesto de "ideólogo"?, estaría bien :)
|
Cita:
que versión de PostgreSQL tienes instalada ? Yo, una vez conocida la versión y comprobado que no hay ningún bug existente sobre ella, haría lo siguiente. Escoge una de esas tablas "misteriosas" y pon unos cuantos triggers (en cada fila), más o menos tal que así: 1.- Antes de grabar. 2.- Despues de grabar. 3.- Antes de borrar. 4.- Despues de borrar. Y, en cada uno de ellos (puede ser el mismo para todos los 'estados'), guarda en una nueva tabla de log, toda la información de fecha, hora, comentario tuyo adicional, que se borra, desde donde, PK de la fila (para su posterior localización), etc.... Eso no lo va a arreglar, pero te va a dar una buena pista de qué sucede, si alguna vez se grabó y cuando se borró. Saludos. |
Como comenté antes, a veces nos podemos llevar sorpresas. El año pasado tuvimos unas quejas muy graves de un cliente que sufría pérdidas de datos aleatorios en documentos de un tipo determinado (pedidos para producción en una fábrica), las pruebas que hicimos fueron muy rigurosas, dedicándole muchas horas, días y semanas de trabajo para encontrar el problema, pero seguían perdiéndose esos datos, además era la única empresa donde tenían ese problema.
Finalmente me decidí por crear un trigger cuando se borraba un registro de la tabla y lo que hacía simplemente era almacenar en otra tabla los datos de ese registro borrado, además del usuario, puesto de trabajo, etc. No dijimos nada a nadie de ese cambio, el resultado fue que encontramos a un usuario descontento que los borraba. La empresa le acusó y él respondió que sería un fallo del programa. El gerente de la empresa volvió a la carga contra nosotros, así que hicimos un "select * from tbRegistrosBorradosLog order by fecha, hora", y le entregamos el listado al gerente. Puso cara de incredulidad, nos pidió disculpas, pagó lo que nos debía, y no sé lo que haría con el trabajador, pero seguro que nos odiará. |
Me encantaría que el problema fuera algún empleado!!!
Pero el sistema no permite borrar registros, solo anularlos. Habría que borrar desde la base de datos. Si hubiera una persona con conocimientos suficientes para acceder a la Bd y borrar registros, debería además conocer muy bien la estructura de la bd y la funcionalidad de la aplicación, ya que los registros se eliminan consistemente. De todas formas, me sirve un montón todo lo que están posteando, ya que me va permitir analizar que está pasando. Les comento que voy a averiguando Muchas gracias Alejandro |
La franja horaria es GMT +2. Ahora son las 08:13:09. |
Powered by vBulletin® Version 3.6.8
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
Traducción al castellano por el equipo de moderadores del Club Delphi