Aumento desproporcionado del tamaño de las bases de datos en FireBird

[insoft]

Estamos desarrollando nuestra aplicación con Delphi XE3 y FireBird 2.5.2. En nuestras bases de datos manejamos codificación ISO8859-1.

Hemos detectado que las bases de datos empiezan a aumentar su tamaño de manera exagerada y el acceso a las mismas se vuelve más lento. Cuando las conectamos a un gestos de base de datos como EMS SQL Manager obervamos que al tratar de abrirla se demora demasiado cargando los "Procedures". Al estar abierta y activa tratamos de abrir uno a uno los Procedures y hemos hallado que algunos de ellos no se pueden visuarlizar y generan un error de "Out of Memory" dando a entender que es demasiada la información de éste y que no puede ser mostrada.

Luego de analizar los procedures nos dimos cuenta que si en ellos se incluían vocales con tilde como á, é, í, ó, ú, Á, É, Í, Ó, Ú dentro de los comentarios, dichos caracteres serían reemplazados por otros como el caracter à y este a su vez se volvía a multiplicar miles de veces hasta hacer llegar la base de datos a tamaños de Gigas.

Solicitamos su colaboración para solucionar este problema que está incluso afectando la generación de las copias de seguridad (archivos FBK) y su posterior restauración (archivos FDB).

[ArturoGallegos]

tema fuera de lugar, por favor trata de colocar tus temas en el foro adecuado donde te podrán ayudar aquí no viene ni al caso, ya mismo reporto tu tema para que lo muevan.

No soy experto en base de datos pero de entrada tu respuesta es simple y lógica, si todo el alboroto es producido por los comentarios simplemente no los pongan u omitan el uso de caracteres especiales.

[gnzsoloyo]

Luego de analizar los procedures nos dimos cuenta que si en ellos se incluían vocales con tilde como á, é, í, ó, ú, Á, É, Í, Ó, Ú dentro de los comentarios, dichos caracteres serían reemplazados por otros como el caracter à y este a su vez se volvía a multiplicar miles de veces hasta hacer llegar la base de datos a tamaños de Gigas.

Esto que describes tiene todo el aspecto de un bug en la aplciación, por cuanto el uso de acentuaciones de cualquier tipo no tiene por qué afectar su almacenamiento, en tanto el caracter haya sido enviado por la aplicación con la collation esperada, de acuerdo a la usada por la base en su conexión.
Antes de echar la culpa a la base o los SP, deberías revisar la programación de la insercion de los datos, ya que el 99% de las veces este tipo de errores comienza allí.
En otras palabras: Si los datos se multiplican al entrar, no es problema en la base, es que los están entrando mal.

¿Con qué lenguaje están trabajando en la aplicación, y cómo han verificado si hay erroes en ella?

[insoft]

Gracias por sus respuestas.

Les cuento que el problema podría estar relacionado no en el uso que se hace de la base de datos desde Delphi sinó en procesos propios del motor de base de datos como lo son las copias de seguridad. No hemos podido detectar en que momento exacto se produce la multiplicación de estos caracteres. Lo que nos va marcando la aparición del problema es el tamaño de la base de datos que de un momento a otro comienza a crecer de manera indiscriminada.

[gnzsoloyo]

Lo que nos va marcando la aparición del problema es el tamaño de la base de datos que de un momento a otro comienza a crecer de manera indiscriminada.

Eso no es necesariamente un indicativo de que haya un problema en la base o en los stored procedures.
Es indica que hay inserciones de datos incorrectos. Su impacto en el backup puede ser nada más la consecuencia lógica del aumento del tamaño de datos.
Sigo pensando que estás intentnando culpar al síntoma (tamaño de las tablas), en lugar de culpar a la enfermedad (ingreso de datos corruptos).
¿Cómo verificaste que los datos estén llegando correctamente a los procesos? ¿Qué verificaciones ralizaste?
¿Qué comprobaciones hiciste en cuanto a los datos que entran al proceso, respecto a los que salen de él?
Explicalo con detalle.

[insoft]

Gracias nuevamente.

Le cuento que el crecimiento de la base de datos no se presenta propiamente en los datos de las tablas sino que el Procedure se llena de caracteres como los que le dije en reemplazo de las vocales con tilde. El caracter extraño se repite miles de veces hasta dañar el Procedure. Es decir hay daño en la MetaData por esta inserción de caracteres extraños. Otro usuario me respondió que simplemente no utilizara caracteres con tilde, obvio, pero la falla se presentará potencialmente con otros usuarios que ya tienen en su poder versiones de nuestras bases de datos que contienen estos caracteres.

A las bases de datos actuales ya se les removió esta clase de caracteres.

[gnzsoloyo]

A ver si entiendo bien, ¿esos caracteres están en el cuerpo del stored procedure, usados en las denominaciones de los identificadores de objetos (nombres de tablas, columnas, etc), y no en lo que son cadenas de texto?
Si ese es el caso, pareces tener un error de configuracion del servidor, porque entonces la tabla donde se almacena el cuerpo del código, no está soportando ese tipo de colllation, y eso está un poquitín más allá de lo que pudes solicionar así nomás.
Ese tipo de comportamiento lo he visto suceder en otros DBMS, aunque no genera en esos caoss una corrupción tan grande. Normalmente sólo alcanza a un caracter, ya que lo convierte en dos.
Como sea, es cierto que si usaron letras acentuadas en los nombres de los objetos, han metido la pata a lo grande, porque eso se considera una pésima práctica, por cuestiones de compatibilidad entre servidores. La mejor de todas las soluciones es modificar todas esas apariciones acentuadas, para eliminaras.
Lo siento, pero es muy posible que les convenga tomar el toro por las astas y resolverlo como un bug de producción.

[insoft]

Claro que ya vas entendiendo. El problema lo detectamos en los fragmentos que sirven como comentario dentro de los Procedures. No en nombres de objetos. Inclusive las descripciones de los objetos también las removimos por la misma causa. Observe por favor un fragmento del Procedure donde le muestro el caracter que se multiplica (sÃ-). El cual realmente debía ser una "i con tilde" para formar (sí-). De hecho otros caracteres se reemplazan por otras secuencias de caracteres raros.

Código FIREBIRD:

/*Primero se busca el dato con todos la informacion que entra por parametros*/  
  if ((IEmp<>0) OR (aIPerfil<>'N/A') OR (IUsuario<>'N/A') OR (IWS<>'N/A') OR (ITDSop<>0))  
  then begin  
    SELECT SVALUE  
    FROM abaconfigusuario  
    WHERE (IEmp=:IEmp) AND (IPerfil=:aIPerfil) AND (NUsr=:IUsuario) AND (IWS=:IWS) AND  
       (NTabla=:NTabla) AND (NSTabla=:NSTabla) AND (ITDSop=:ITDSop) AND  
       (NField=:NField)  
    INTO :SValue;  
  
/*Si fue dado el IWS y el valor no se ha encontrado, se busca con todos los datos igual pero  
  sin el IWS solamente. Con esto se da la posibilidad de tener una configuracion sin IWS pero  
  sÃ- con ITDSop. Antes, llegaba directo a los llamados recursivos y empezaba quitando el ITDSop  
  por lo que nunca encontraba una configuracion en ese caso.*/  
    if ((IWS<>'N/A') and (SValue IS NULL)) then begin  
       SELECT SVALUE  
       FROM abaconfigusuario  
       WHERE (IEmp=:IEmp) AND (IPerfil=:aIPerfil) AND (NUsr=:IUsuario) AND (IWS='N/A') AND  
          (NTabla=:NTabla) AND (NSTabla=:NSTabla) AND (ITDSop=:ITDSop) AND  
          (NField=:NField)  
       INTO :SValue;  
         
       if (NOT SValue IS NULL) then IWS='N/A';  
    end  
  end