34 replies to this topic

[agag4]

Buen día compañeros, se me ha presentado un problema grave en el trabajo, usamos firebird 1.5 desde hace 5 años, en una de las sucursales donde se maneja más información y más clientes conectados se ha dañado la BD 3 veces en lo que va del 2010,ya le hemos cambiado de No-Break, 3 Servidores ( cpu ), Disco duro, memoria ram, el sistema operativo que usamos en el servidor en lo que va estos 3 ultimos meses es win7 ultimate, se lo añadimos para probarlo pero aun sigue el problema, anteriormente habiamos usado el Win2003 server SP2 R2, la BD mide casi 3 gigas, será que hay que sacar información de tal forma que quede de 1giga la BD ??

Gracias por sus sugerencias.

[Kipow]

mmm yo tengo varias bases asi con Windows 2003 server y con Windows XP incluso tengo varias (bueno mis clientes) y todo bien sin ningun problema, no sera problema de suministro electrico (apagones).?

[TiammatMX]

¡¡Úchales!!, pues te toca hacerle un BUEN mantenimiento a ésa base de datos..., y tal vez, darle un aumento de tamaño, por aquéllo del "no te entumas"..., tal vez al siguiente dígito de la serie.

Seguramente, por ahí tienes perdidas algunas transacciones, así que como paso número cero será confirmarlas o darles roll-back por medio de tu administrador, y de ahí, respaldar, tal vez recortar, y seguir trabajando. Y si puedes alojarla en un servidor que no consuma tantos recursos, sería mejor...

Por cierto, ¿revisaste si tiene fragmentación el disco duro?

[fredycc]

Veo que hasta sistema operativo han cambiado para verificar si ese es el problema y bueno mi primera pregunta es, que les impide cambiar firebird a la versión 2.5 o 2.1 en todo caso?, en tu caso primeramente monitorearía la base datos, tal vez algún detalle en la programación y transacciones te esten dejando sin recursos en tu servidor, algún reporte o consulta muy demandante puede tirar el servidor de forma repentina y causando el problema.

Saludos

[Delphius]

Hola,
No sabría decirte cual es el problema. Pero el tamaño estoy seguro que no lo es. Hay historias de bases de datos muchísimas más grandes que esos "escasos" 3 GB y funcionan de manera óptima.
El límite teórico de una DB de Firebird está en el orden del TB así que es muy pero muy poco probable que sea cosa de tamaño.

El problema está en otro lado. Ahora bien, deberías puntualizar mucho más cuando dices que se te ha dañado la base de datos, es muy poco común que la base de datos se corrompa. Pero es que por el tipo de explicación que das pareciera ser que no es que la DB esté corrupta sino que el servidor se cae, falla, consume recursos y/o se relantiza.

Una primera aproximación es verificar la cantidad de transacciones abiertas, transacciones limbo, etc.
Examina el archivo .log de FB y determina si hay algo allí.

Sin una descripción bien precisa de tu caso no podremos ofrecerte demasiada ayuda. Nos describes que probaron y cambiaron muchas cosas pero en específico sobre los síntomas no has descripto nada... Si estuvíeramos en una famosa serie de TV diría que trataron a la db como un enfermo sobre lupus, diarreas, gingivitis, fractura de cráneo, y sífilis... pensando que se trata de todo eso en vez de analizar los síntomas. ¿Se va haciendo más lento el acceso? ¿Llega un momento en que las consultas tardan minutos o no se pueden establecer conexiones? ¿Se desconecta cada vez? Uff... podríamos seguir.

Saludos,

[agag4]

Les adjunto el unico y el último error que salio, los otros errores lamentablemente no los guarde, eran diferentes a este error, dicho error sale al "Hacer Conexión a la BD", ya sea por mi aplicación ó por el ibexpert. Aparentemente pudiera ser problema del disco duro, voy a reemplazar este servidor por otro nuevo, con otro disco duro, haciendo un poco de historia, desde que comence a implementar el sistema desde Mayo del 2006 hasta Mayo del 2010 no se me habia presentado ningun problema acerca de la BD, yo pense que era por los casi 3gigas pero yo sabía que eso no era obstaculo para Firebird que no le hacia cosquillas el tamaño de la BD.

Attached Files

•  2075_7357bca488302c8ef4014c29023c524c865db734.jpg   126.91KB   35 downloads

[Delphius]

Hola,
Por el texto del mensaje de error, se da a entender que se trata de un problema del disco duro y no específicamente de la base de datos.

Al menos eso está dando a entender cuando se dice "Error de Redundancia Cíclica": que no se puede tener acceso a ese/os sector/es del disco duro.

Saludos,

[agag4]

Gracias Delphius....

[Marc]

Sí, la verdad es que este no es el típico error de corrupción de la base de datos en Firebird, parece más un error del sistema de archivos de windows.

Aún así, asegúrate de tener instalada la última versión de Firebird 1.5, la versión 1.5.06. Y como te han comentado, yo también estudiaría si puedes pasar a Firebird 2.5, instalando una copia de la base de datos con ese servidor, y probando la aplicación para asegurarme de que no haya incompatibilidades, en cuyo caso hay que corregirlas en el programa (normalmente estas pocas incompatibilidades son debidas a que cada versión de Firebird se ajusta más al estándar SQL, lo cual provoca que consultas que antes funcionaban, dejan de funcionar en la nueva versión, aunque siempre son muy sencillas de corregir).

Como comenta Delphius, si siguen los problemas habrá que hacerle un seguimiento a la base de datos, es decir, monitorizar el consumo de memoria RAM, consumo de CPU, el tiempo que permanecen abiertas las transacciones, etc. ...

Finalmente, aunque Firebird precisa de muy poco mantenimiento, nunca está de más hacer un poco. Básicamente todo el mantenimiento se reduce a hacer un Backup/Restore cada cierto tiempo, para reconstruir la base de datos. NOTA: Normalmente es recomendable hacer el Restore en una archivo distinto al original, para que en caso de tener una copia corrupta aún mantengas el archivo original. Solo cuando has comprobado que la base de datos restaurada está en buen estado, deberías sustituir la antigua por la nueva.

Saludos.

[agag4]

No me he cambiado a firebird 2.0 porque no me deja la base de datos que tengo, ya lo he intentado más de 1 vez, lo que me pasa es que tengo trigger's donde uso el before y el afterpost, el afterpost ya no lo acepta en la version 2.0, no he probado con cambiar los triger's que tengo al beforepost para que ya no haya broncas.

[Marc]

No me he cambiado a firebird 2.0 porque no me deja la base de datos que tengo, ya lo he intentado más de 1 vez, lo que me pasa es que tengo trigger's donde uso el before y el afterpost, el afterpost ya no lo acepta en la version 2.0, no he probado con cambiar los triger's que tengo al beforepost para que ya no haya broncas.

Firebird 2.0 (y 2.1 y 2.5) aceptan perfectamente triggers AfterPost. Si nos muestras alguno de estos triggers y nos dices cual es el error que te salta al intentar crearlos en FB 2.x, con mucho gusto te ayudaremos a corregirlo (como te comenté, cada versión de Firebird es más estricto con el cumplimiento de los estándares SQL).

Saludos.

[Delphius]

Hola,
Dada la situación considero que es más oportuno que se vea el disco y se examine si hay errores. Espero que tengas un backup por las dudas. No interesa si es F1.5, 2.0, 2.1, 2.5, 3 o 1000... eso no solucionará el CRC.

Primero el disco, luego ver que otros problemas hay con la base de datos como ser el tema de las transacciones, de conexión, triggers, etc.

Saludos,

[agag4]

Voy hacer de nuevo la prueba de cambiarme a la version 2.0 y les muestro el error que me sale en un trigger...., corrigenme si estoy mal, para cambiar de version de 1.5 a la 2.5, tengo que hacer backup de la 1.5 y el restore lo hago con la 2.5 es correcto ??

[Marc]

Voy hacer de nuevo la prueba de cambiarme a la version 2.0 y les muestro el error que me sale en un trigger...., corrigenme si estoy mal, para cambiar de version de 1.5 a la 2.5, tengo que hacer backup de la 1.5 y el restore lo hago con la 2.5 es correcto ??

Correcto.

Si tienes problemas. Haz una extracción del metadata de tu base de datos, con IB-Expert, en Fiberird 1.5. Y después ejecuta ese script en Firebird 2.5 para recrear los mismos objetos. Con los errores que te salgan sabremos lo que hay que corregir. Una vez rehecha la base de datos, solo quedará copiar los datos de FB 1.5 a FB 2.5 con una herramienta de DataPump, como el IBDataPump.

Saludos.

[Delphius]

Disculpen si soy pesadito pero sigo pensando que el tema de versión es lo de menos aquí. Si hay un problema de lectura del disco dará lo mismo que sea la 2.0 o la versión mega hiper server 5000... el error de disco seguirá.

Deberías examinar el disco, luego ver el tema de transacciones y demás. El tema de la versión es, con todo respecto, el menor de los males a los que te puedes enfrentar.

Saludos,

[Sergio]

Los 3 Gigas de tamaño NO son el problema, mis clientes manejan ficheros del orden de 20 gigas, y no tienen ningun problema (tenemos varios con estos tamaños), ademas, estos clientes han ido pasando por FireBird 1.5, 2.1 y ultimamanete por la 2.5 sin mas que hacer un backup-restore tras cambiar FireBird, no fue necesario cambios en los metadata, excepto para la V2.5 que no admite eñes ni acentos ni en los comentarios de los triggers!

Como comentas que has probado a cambiar de todo (maquina, disco, memoria...) yo solo veo un culpable: Tu aplicacion. Seguramente abres una transaccion y la mantienes toda la sesion en uso o cosas de este estilo.

Si esto ocurre, todo lo que se modifica por esa transaccion queda en el limbo durante toda la sesion de uso, y eso hace que cualquier cuelgue en la maquina cliente te deje la base de datos con un monton de transacciones huerfanas, versiones diferentes de un record, etc... la aplicacion ira cada vez mas lenta, y FireBird mas inestable.

Si llegas a saturar la meoria de FireBird o del servidor, todo se te vuelve muy intestable y el servicio puede interrumpirse sin acabar correctamente, lo que te puede dejar el fichero, aparte de abarrotado de cosas "a medio", a medio actualizar en disco, y por eso tendrias el tipo de error que envias.

Es cierto que este error tambien se debe a errores en sectores del disco, un disco poco fiable te va a generar estas cosas, pero tambien un cuelgue del windows que hace de servidor o del servicio FireBird lo puede hacer.

Te recomiendo que pruebes con dos utilidades interesantes, ambas disponibles en http://www.ib-aid.com/downloads/

Por un lado, FBScanner te dira si te estas olvidando transacciones, y por otro, IBFirstAid diagnostician te analiza la base de datos rota.

[Marc]

Como comentas que has probado a cambiar de todo (maquina, disco, memoria...) yo solo veo un culpable: Tu aplicacion. Seguramente abres una transaccion y la mantienes toda la sesion en uso o cosas de este estilo.

Sí, esta es de largo la mayor fuente de problemas que siempre he visto en Firebird, las transacciones que se dejan abiertas.

Por un lado, FBScanner te dira si te estas olvidando transacciones, y por otro, IBFirstAid diagnostician te analiza la base de datos rota.

Gracias, no conocía el FBScanner. Al utilizar masivamente ClientDatasets, que me permiten trabajar con los datos sin necesidad de tener una transacción abierta, todas mis transacciones solo duran unas milésimas de segundo (el tiempo que necesita el ClientDataset para cargar los datos de la base de datos, o para modificarla), nunca he tenido estos problemas. Pero siempre va bien conocer estas utilidades.

Saludos.

[Delphius]

Siempre me dije que debería probar los productos que ofrece IBSurgeon, creo que ya es hora.

Antes de hacer la descarga de las herramientas gratuitas, quisiera preguntarte Sergio si no habrá problemas con la versión 1.5.3 ¿o es que es para versiones superiores?

Saludos,

[Sergio]

Hola Delphius, por aqui hemos utilizado las herramientas de diagnostico y repartacion con varias versiones, incluida la 1.5, y funcionan con todas ellas, piensa que las utilidades de reparacion no usan fbclient.dll, entran directamente a la estructura del fichero y lo analizan, y dado que la herramienta es veterana, tiene código para leer y entender todo tipo de bases de datos FireBird o Interbase. incluso si son ilegibles desde fbclient.

Nosotros solo hemos usado IBFirstAid diagnostician (la utilidad gratuita) y tambien tenemos licenia -y hemos usado alguna que otra vez- de la de pago (que repara cosas que las herramientas de FireBird no pueden). Las herramientas de monitoreo no nos han hecho falta, tenemos las transacciones muy controladas por la herencia visual (cada ficha crea y destruye la suya).

Conocemos personalmente (por unas conferencias) al "jefe", y tambien hemos enviado a algunos clientes con casos dificiles directamente a ellos, y la verdad, un servicio 10: Se conectan a tu maquina (o entorno vistual), se pasan las horas que hagan faltan, y solo si logran recuperar tus datos te cobran.

Marc: Si usas unos componentes cuyas transacciones son "de usar y tirar", creo que te pierdes muchas de las ventajas de FireBird. Nosotros usamos componentes "directos" (FreeIB y ese tipo) y a cambio tenemos el control de concurrencia de FireBird, que es de lo mejorcito que tiene: Tu abres una ficha, sin definir si es para ver o editar, y todos los demas pueden tambien hacerlo a la misma vez, y si al final sales grabando, FireBird (la transaccion) se encarga de dejarte solo si la version actual en disco sigue siendo la misma que tu leiste (y mientras tanto, tiene todas las verisones "activas" en memoria). Esto lo pierdes ¿no?

[Marc]

Hola Sergio.

Marc: Si usas unos componentes cuyas transacciones son "de usar y tirar", creo que te pierdes muchas de las ventajas de FireBird. Nosotros usamos componentes "directos" (FreeIB y ese tipo) y a cambio tenemos el control de concurrencia de FireBird, que es de lo mejorcito que tiene: Tu abres una ficha, sin definir si es para ver o editar, y todos los demas pueden tambien hacerlo a la misma vez, y si al final sales grabando, FireBird (la transaccion) se encarga de dejarte solo si la version actual en disco sigue siendo la misma que tu leiste (y mientras tanto, tiene todas las verisones "activas" en memoria). Esto lo pierdes ¿no?

Sí, eso lo pierdo de gestionarlo a través de Firebird, pero con los ClientDatasets de Delphi consigo el mismo resultado con mucha menos carga para el Servidor.

Puedo abrir la misma ficha en varios clientes : se lanza una minitransacción en dbExpress, se leen los datos, se pasan al ClientDataset y se cierra la transacción.

Ahora tengo varios equipos visualizando/editando los mismos datos.

Todos pueden modificar, pero el primero que graba es el que tiene éxito : se inicia otra minitransacción, se actualizan los datos en disco y se cierra la transacción.

Cualquier otro que intente grabar posteriormente esos datos, se va a encontrar con que el ClientDataset detectará que los datos en disco no son los mismos que él leyo y copió en memoria, y en lugar de actualizar los datos lanzará una excepción de Conflicto de Actualización (donde puedes mostrar una pantalla de Conciliación, mostrando la versión original del campo, tus cambios, la nueva versión en la base de datos de esos campos y escoger los que quieres que queden definitivamente).

Esto se controla mediante la propiedad UpdateMode del Provider del ClientDataset. Con upWhereAll todos los campos del ClientDataset tienen que tener aún el mismo valor, con upWhereChanged vas a poder grabar el ClientDataset si solo los campos que estás modificando mantienen el valor original, y con upWhereKeyOnly indicas que no te quieres preocupar por eso y que quieres grabar siempre los datos (independientemente de que otro haya hecho cambios mientras tú los editabas).

Ciertamente la arquitectura multi-generacional de Firebird permite una concurrencia óptima. Pero con los ClientDatasets también también se obtiene una buena concurrencia, y además es independiente de la Base de Datos. La verdad es que estoy mucho más tranquilo sin mantener transacciones abiertas en Firebird.

Saludos.