Foros Club Delphi

Foros Club Delphi (https://www.clubdelphi.com/foros/index.php)
-   PostgreSQL (https://www.clubdelphi.com/foros/forumdisplay.php?f=42)
-   -   Postgresql pierde registros (https://www.clubdelphi.com/foros/showthread.php?t=70399)

quali 18-10-2010 23:37:32

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

Casimiro Notevi 19-10-2010 01:06:09

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.

quali 20-10-2010 00:12:41

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

Casimiro Notevi 20-10-2010 00:24:54

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.

quali 20-10-2010 00:43:10

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

movorack 20-10-2010 01:14:43

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.

quali 20-10-2010 13:58:04

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

Casimiro Notevi 20-10-2010 14:09:32

Cita:

Empezado por quali (Mensaje 379798)
[..] 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').

Eso no sólo es raro, es que lógicamente es 'casi' imposible.

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.

quali 20-10-2010 14:23:15

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 !!

Casimiro Notevi 20-10-2010 14:38:01

¿Y no haces backup todos los días?

quali 20-10-2010 15:22:49

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 !!!'

movorack 20-10-2010 15:40:04

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?

quali 20-10-2010 16:24:04

Eso es un buen dato.
El único problema es que no se donde están ambos logs.
Alguna pista?

Muchas gracias

Alejandro

Casimiro Notevi 20-10-2010 17:12:33

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" :)

movorack 20-10-2010 17:33:52

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

movorack 20-10-2010 17:34:42

Cita:

Empezado por Casimiro Notevi (Mensaje 379890)
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" :)

está buenisimo el articulo.

Al González 20-10-2010 18:12:35

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).

Casimiro Notevi 20-10-2010 18:24:53

Cita:

Empezado por Al González (Mensaje 379900)
[..] 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).

Sí, yo también me he extrañado en ese punto, me resulta imposible dejar un problema sin conocer por qué ocurre, aunque encuentre una solución "aparente", principalmente por dos motivos:
  1. Para evitar que ocurra en el futuro el mismo problema
  2. Porque de esa manera, si no sabes de donde viene, "estás vendido", no sabes si fallará o no fallará otra vez, y seguro que fallará, y además en el peor momento posible, leyes de Murphy, ya sabemos.
Soy de los que pierden mucho tiempo buscando el por qué a un problema, y eso me retrasa en mi trabajo, cierto, pero no puedo evitarlo, tengo que encontrar la respuesta, no descanso hasta que la encuentro.

Al González 20-10-2010 19:17:05

Cita:

Empezado por Casimiro Notevi (Mensaje 379901)
[...] Soy de los que pierden mucho tiempo buscando el por qué a un problema, y eso me retrasa en mi trabajo, cierto, pero no puedo evitarlo, tengo que encontrar la respuesta, no descanso hasta que la encuentro.

La importancia de tener a un programador bibliotecario (últimos párrafos) en cada equipo de trabajo. :)

Casimiro Notevi 20-10-2010 19:34:03

Cita:

Empezado por Al González (Mensaje 379906)
La importancia de tener a un programador bibliotecario (últimos párrafos) en cada equipo de trabajo. :)

Cierto, tal y como explicas es lo adecuado, los ejemplos de los médicos, que cada uno tiene su especialidad es muy aclaratoria, al igual que la de construcción de edificios, también.
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


La franja horaria es GMT +2. Ahora son las 15:47:32.

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