IBExpert Backup Error
 

Hola, nose donde colocar mi onsulta, espero que no haya problemas por haberla colocado aqui.

Tengo una plaicacion en delphi 2006 y firebird 2.0.
Utilizo IBExpert para administrar la base de datos. El IBExpert tiene un opcion de Services-Backup, anteriomente habia utilizado este opcion para hacer respaldos de mi base de datos.
Ahora bien, cuando quise utilizar esto nuevamente me arrojo un error....

"Arithmetic overflow or division by zero has occurred. arithmetic exception, numeric overflow, or string truncation.
gds_$receive failed."

Cuando ocurre esto: comienza realizando una serie de operaciones, y cuando llega a la parte donde esta guardando los registros (writing data for table ...)tira es error.

Que podra ser esto.... y como lo puedo solucionar?

Espero me pueda ayudar... otra cosa, el programa sigue funcionando sin problema, solo que no puedo hacer respanldos de mis datos... eso es todo.

Saludos

Intenta desde la linea de comandos y así vemos si es fallo de IB Expert o el fallo está en la BBDD, motor, etc.

sintaxis de gbak:
http://www.destructor.de/firebird/gbak.htm

Saludos

Gracias Lepe.

Utilize desde la linea de comandos y que me genere un registro (.log), en el cual me aparece el mismo error.

Esto da por conclusión que el problema no es de IBExpert.

COmo detecto que problema puede ser... como lo soluciono?

Saludos

Es posbile que tengas datos corruptos en tu base de datos o que hayas reducido el tamaño de algun campo varchar y que tengas registros previos con una longitud mayor al tamaño especificado.

Ya que utilizas IBExpert, vete por Services->Database Validation y pincha las opciones Validate database y Validate Database Full. Esta opcion te indicara si hay paginas de datos con problemas (bastante probable) y si hay paginas de indices con problema (estas quedan resueltas despues del restore porque el motor reconstruye los indices). Despues que mires el nivel de daño en la base de datos, desconecta cualquier conexion que haya hacia esa base de datos, haz una copia con copiar/pegar y luego con IBExpert entra nuevamente por database Validation y selecciona la opcion Mend.

Luego haces un backup/restore y nos coemtnas como te fue.

Si lo anterior no funciona trata de sacar los datos de todas las tablas por la opcion de Extract Metadata para identificar cual tabla es la del problema y tratar de recuperar los registros que estan buenos.

Tu aplicativo es posible que funcione porque ningun usuario ha recuperado datos de las paginas donde estan los registros con problema.

Hola, he tratado de hacer lo que me han recomendado.

- Desconecte todas las conexiones a la base de dato (y corri el IBExpert desde el servidor)
- Ingrese a la opcion Database validate full... lo corri y me mostro: Validation complete: no errors found (se demoro apenas una milesima de segundo)
- Luego corri con la opcion MEND (pero tuve que sacer la opcion de validate database, porque sino no funcionaba, me tira un error)
- Backup y sigue con el mismo error.

No se si hice todo bien...

Que podra ser??

Saludos

Si la base de datos no es muy grande comprimela y colocala en alguna parte para poderla revisar.

El asunto es que eso de reparar bases de datos a distancia es un poco dificil, no se que pienses.

Ya lo solucione.

Encontre la tabla que contenia los registros con problemas, vacie la tabla y a partir de un backup antiguo recupere gran parte de la informacion.

Espero que no me vuelva a suceder... Porque puede haber ocurrido esto?

Saludos

Los daños en bases de datos Interbase/Firebird obedecen a que el equipo o servidor donde se encuentra la base de datos se apaga sin que el servicio del motor de base de datos se haya detenido. Cuando se han presentado daños en bases de datos de mis clientes es porque se interrumpe el fluido electrico.

No siempre que se va la energia se dañan las bases de datos, existe un concepto en tecnologia que se llama 'operacion critica'. Una operacion critica es cuando se escribe en un dispositivo de almacenamiento secundario, por ejemplo un disco duro (almacenamiento primario es memoria RAM). Si la energia se suspende justo cuando se esta escribiendo fisicamente un registro en el disco duro, la pagina donde se esta grabando esa informacion queda incosistente, algo asi como que queda a medias. Firebird e Interbase al no reconocer los datos los considera como dañados.

Muchas veces esta situacion se descubre hasta el momento de hacer backups, ya que el servicio que hace el backup debe leer todas las paginas de la base de datos y es alli donde encuentra que hay problemas.

En muchas ocasiones la base de datos puede estar con daños y nos damos cuenta de ellos cuando algun usuario lee registros de alguna tabla con problema, y es donde nos llaman a decirnos que salio un error.

Otra consideracion, existen basicamente en una base de datos de firebird 2 tipos de paginas: las paginas de datos y las paginas de indices. Logicamente hay otras paginas donde se almacenan los metadatos (dominios, triggers y procedimientos almacenados). Otra cosita para almacenar informacion de campos BLOB, firebird los gurda separados de los datos normales de un registro.

Bueno, las paginas de indices si se dañan no presentarian problemas al hacer consultas, es posible que no encontremos ciertos registros si se hace uso de un indice que esta dañado, pero lo importante es que un daño en un indice no representa necesariamente que haya daños en registros de datos. Estos daños los resuelve un backup/restore ya que el backup simplemente 'copia' la defincion del indice y el restore reconstruye el indice.

Las paginas de datos son las que mas nos deben preocupar.

Firebird es un motor muy robusto, vengo trabajando con el (desde Interbase 4.0) y los daños que se me han presentado han sido muy eventuales y como les digo ha sido por falta de proteccion del servidor, por eso, la mejor recomendacion es que el servidor cuente con una UPS (unidad ininterrumpida de potencia), si se interrume el fluido electrico se cuenta con tiempo para apagar el servidor correctamente.

Hacer frecuentemente backup/restore porque existen otros riesgos: que se dañe el disco duro o se roben el servidor o un incendio, bueno tantas cosas que nuestra imaginacion pueda elaborar.

Sacar las copias de seguridad de las instalaciones de la empresa, no sea que haya un incendio: adios servidos y adios datos !!!

Sacar doble copia de seguridad o no les ha pasado que la copia no sirvio ?, hacer periodicamente pruebas de las copias de seguridad, etc. Bueno ya me meti en asuntos que competen a seguridad informatica.