FTP | CCD | Buscar | Trucos | Trabajo | Foros |
|
Registrarse | FAQ | Miembros | Calendario | Guía de estilo | Temas de Hoy |
|
Herramientas | Buscar en Tema | Desplegado |
|
#1
|
|||
|
|||
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
__________________
Alejandro |
#2
|
||||
|
||||
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.
|
#3
|
|||
|
|||
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
__________________
Alejandro |
#4
|
||||
|
||||
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.
__________________
Buena caza y buen remar... http://mivaler.blogspot.com |
#5
|
|||
|
|||
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
__________________
Alejandro |
#6
|
||||
|
||||
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. |
#7
|
|||
|
|||
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 !!
__________________
Alejandro |
#8
|
||||
|
||||
¿Y no haces backup todos los días?
|
#9
|
|||
|
|||
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 !!!'
__________________
Alejandro |
#10
|
||||
|
||||
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?
__________________
Buena caza y buen remar... http://mivaler.blogspot.com |
#11
|
|||
|
|||
Eso es un buen dato.
El único problema es que no se donde están ambos logs. Alguna pista? Muchas gracias Alejandro
__________________
Alejandro |
#12
|
||||
|
||||
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. |
#13
|
||||
|
||||
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á. |
#14
|
|||
|
|||
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
__________________
Alejandro |
|
|
Temas Similares | ||||
Tema | Autor | Foro | Respuestas | Último mensaje |
Red Hat pierde 25% de ganancias en 4Q. | Epachsoft | Noticias | 1 | 06-04-2007 18:17:15 |
Interbases 6.6 Pierde registros? | tulio | Firebird e Interbase | 4 | 25-08-2006 22:18:25 |
pierde conexion | Luis Castillo | Conexión con bases de datos | 5 | 10-02-2006 22:00:08 |
la informacion de registros se pierde o borra? | bosamel | Conexión con bases de datos | 2 | 25-01-2005 02:07:31 |
...M$ pierde una.... | Jure | Noticias | 0 | 08-06-2004 01:15:24 |
|