6 respuestas en este tema

[ematrix]

Hola Amigos:

un caso de mi base de datos

root@jaguar:/webdatos# ls -ls
total 276648
138324 -rwxrwxrwx 1 root root 141500416 Feb 12 21:41 SGAALUMNO.FDB

el tamaño del archivo es de 141 MB, por mantenimiento borre los registros de ciertas tablas que son Fotos; y el tamaño

del archivo no cambio

en si se borraron los registros.  Sin problemas


pero

la pregunta es: ¿Por que no adelgazo el tamaño de mi Archivo SGAALUMNO.FDB.?

o requiere una instruccion adicional.

Espero me ayuden.

Gracias Amigos

[Delphius]

Hola ematrix,
Te explico.
Firebird, y como muchos otros motores de base de datos, no elimina los datos de una plumada así de simple como eliminar x cantidad de registros de algunas tablas para ganar espacio.
Los motores se valen de una cantidad arbitraria de memoria física (en el/los propio/s archivo/s) de la base de datos a modo de recolector de basura. Esto con varios fines:
1) Poder efectuar una operación de vuelta atrás, o mejor llamado RollBack.
2) Agilizar operaciones de traspaso de datos
3) Reutilizar este espacio para información nueva.

Para un correcto mantenimiento de la base de datos se debe proceder a efectuar un Backup/Restore. Esto te garantizará de que ese espacio basura se recicle y elimine. En la documentación oficial sobre el utilitario gbak encontrarás el material necesario y bien detallado para proceder con el Backup y el Restore.

Saludos,

[ematrix]

Gracias Amigo

Delphius:

Por la informacion técnica de filesystem de Base de datos Firebird.

y la recomendacion que haces.

Saludos

[ematrix]

Corroborado con la herramienta

gbak

se realiza el mantenimiento

11212 -rw-r--r-- 1 root root  11463168 Feb 13 18:02 SGAALUMNO.FBK

138324 -rwxrwxrwx 1 root root 141500416 Feb 13 18:02 SGAALUMNO_1.FDB*

compare los dos archivo

y si se compacto como debe ser.

Una Pregunta Delphius:

tuve problemas para Restaurar

use la opcion

./opt/firebird/bin/gbak  -FIX_FSS_M WIN1251 -r -v

esto por que mi base de datos  esta en CODE WIN1251

derivado al encontrar un error en la restauracion

gbak:restoring stored procedure PRUEBA
gbak: ERROR:Malformed string
gbak:Invalid metadata detected. Use -FIX_FSS_METADATA option.
gbak:Exiting before completion due to errors

ahora cada vez para conectarme me pide hacerlo con el CODE WIN1251

como lo restablezco a NONE

Saludos.

Gracias

[Sergio]

En FB2.0 o 2.1, no estoy seguro, los metadata pasaron a tener su propio charset, y el efecto era que si en tu base de datos tenias algún acento o similar en cualquier punto de los metadatos (incluidos lineas de comentario en procedures, todo todo todo) al recuperar la copia de seguridad daba un error y tenias que hacer unas cosillas para repararlo, y creo que ese parámetro que le metes -FIX_FSS_METADA va por esa razón.

A mi no me funciono ese parámetro, no conseguía que recuperase, así que volqué los metadatos a un fichero con gbak (http://www.firebirdfaq.org/faq73/) les quite los acentos con un editor y cree una nueva BD con los metadatos "limpios", luego bombee todo el fichero original con IBPump (http://www.hcsoft.ne...cer&hoja=ibpump).

[Delphius]

Hola ematrix,
Disculpame, estos días estoy muy falto de tiempo para responder.

No puedo decir mucho sobre tu problema, yo aún uso Firebird 1.5 en Windows, y si bien dispongo de 2.5 en Lubuntu aún no he podido dedicarle tiempo para utilizarla de forma masiva y hacer pruebas más completas sobre sus posibilidades... entre ellas el uso de UTF-8 y UNICODE.
Lamentablemente tengo cosas más urgentes en Windows y no estoy en la posibilidad de irme a la versión superior debido a compatibilidad con mis herramientas.

El parámetro que comentas, -FIX_FSS_METADATA, justamente fue un añadido en la nueva versión de Firebird; 2.5. Y está pensado para solucionar el problema de conflicto de caracteres debido a la incompatibilidad del nuevo diseño de charset para soportar UTF y UNICODE adecuadamente cuando se dio el paso de 2.1 a 2.5.

Tengo entendido que además de dicho parámetro, está su análogo -FIX_FSS_DATA; y yo recomendaría emplearlos en forma conjunta a ambos. Podría jugar un rato en Lubuntu y probar con alguna base de pruebas sobre el caso.
Hasta donde llegan mis conocimientos del tema justamente, como es de esperar, cuando se define un conjunto de caracteres es lógico por tanto que se indique en la cadena de conexión (o en su defecto, al momento de conectarse... si empleamos algún utilitario como IBExperts por ejemplo) cual ha de utilizarse.
Es decir, que si tu definiste un charset/collation en particular al momento de crear tu base de datos por tanto debes respetar dicho charset/collation al momento de conectar.
Si no es tu caso y tenías en NONE y ahora de forma automática se te ha cambiado existe la posibilidad de que sea algún bug.

No recuerdo de donde, pero había leído que había ciertos reportes de que no siempre ese parámetro funciona adecuadamente. Quizá justo por allí viene el problema.

De todas formas si no me falla la memoria, para restablecer el charset/collation a NONE basta con emplear la cláusula:

ALTER CHARACTER SET <charset_name>
SET DEFAULT COLLATION <collation_name>

EDITO:
Haciendo más memoria, recuerdo que ese parámetro se ha añadido justo para migración de 2.0 y 2.1 a 2.5. Por tanto no debiera tener sentido tener cada vez que se hiciera un backup/restore indicarle el juego FIX_FSS. Sólo en la primera vez, al momento de hacer la primera restauración de una base de datos pre 2.5 al nuevo 2.5. De allí en adelante el procedimiento es habitual.

Si en verdad estabas utilizando NONE, lo que hace que Firebird acepte el contenido como viene, entonces al momento de pasar el valor al parámetro deberías justo de indicarle NONE:
-FIX_FSS_METADATA NONE.
Aunque estoy en duda de si aceptaría NONE o si es que ya desde 2.5 es una obligación indicar explícitamente el charset real que estamos utilizando.

Saludos,

[ematrix]

Delphius:

Genial la explicacion

una de las cosas que he hecho

es que cometo muchos errores

y aqui se aprende mucho. Saludos Amigos

le agradezco de antemano a todos por su participacion

Espero devolver con algo