Archivos CDX enormes con respecto a sus DBF

[Daniel Del Giudice]

Hola amigos,

les pasó que encuentran archivos CDX desproporcionadamente grandes respecto a sus DBF, y luego de un reindex vuelven a un tamaño lógico. Ya me va ocurriendo dos o tres veces en distintos clientes y son todos los archivos del sistema, no sólo uno o dos archivos, lo cual lo hace más raro todavía. Consulté en Internet y no vi nada. ¿Alguna idea de que puede ser o cómo se puede evitar?

Saludos,

Daniel

[hans4maxi_gmail]

Generando indices durante la ejecución?... SORT?...

---
Este mensaje no contiene virus ni malware porque la protección de avast! Antivirus está activa.
http://www.avast.com

[Carlos Miguel FARIAS]

Lo que ocurre es normal, se debe a que los indices de fox son arboles B+, donde el indice está por un lado (archivos CDX, IDX) y los datos en un archivo plano (binario directo, de registros de longitud fija).

Un arbol B+, esta compuesto por nodos (registros) que contienen claves y punteros, las claves, son los valores que corresponden a algún valor en los datos, y los punteros, apuntan a otros nodos del arbol B+ o a los registros en el archivo plano.

Los nodos son de un tamaño fijo (no recuerdo si 512 o 1024 bytes) donde una buena porción se utiliza para almacenar repeticiones de claves y punteros.

En un nodo entran EPK / (LK+4) = Claves como maximo, donde EPK es espacio para claves (un 90+% del nodo), y LK es longitud de clave (8 bytes fijos si son claves numéricas).

Las claves dentro de cada nodo, están ordenadas por valor.

Cuando se van agregando registros (y claves) el nodo se va llenando, cuando se termina de llenar, una nueva clave produce un fraccionamiento del nodo, convirtiéndose en tres nodos, donde en uno queda dos claves (desde/hasta) y puntero a los otros dos nodos, en estos dos últimos se almacenan la mitad de las claves que estaban en el nodo de origen.

No se (creo que no) que el nodo que se fracciona se reutilice.

De esa manera, el árbol se va expandiendo a medida que se agregan claves, en general, todo nodo está lleno hasta la mitad, como mínimo, y en promedio, en un 75%.

Cuando se borran claves, los nodos se unifican solo si dos nodos adyacentes (en valores de claves) están usados por la mitad (es raro, pero puede darse).

Como pueden ver, este proceso hace que se vayan creando muchos nodos, y posiblemente haya muchos nodos descartados (los que se llenaron y se "split"earon).

Si la carga de nuevas claves es aleatoria (que no implica desorden), evidentemente la cantidad de nodos cargados a la mitad es enorme. Y de ahi que los indices crezcan notoriamente.

Generalmente, las claves primarias, que se generan aproximadamente en forma consecutiva, no están "desparramadas", pero las claves de los indices auxiliares, si se cargan en forma desordenada y son los que mas desperdicio en nodos tienen.

Por eso, es necesario periódicamente re-indexar todos los indices, o puede resultar mejor, borrarlos todos y recrearlos (puede llegar a ser más rápido y dejar los indices más eficientes).

Saludos: Miguel, La Pampa (RA)

[Luis la Romana]

En índices compuestos CDX es normal el crecimiento a tal punto que podría superar el tamaño del DBF, eso se da más en archivos de transacciones que en catálogos.
Aun ejecutando el pack los CDX no bajan.
Yo sencillamente los elimino estando fuera del sistema, luego al entrar la aplicación debe verificar que estén para crearlos o no.

Siempre he tenido una duda, cómo funcionan los índices en SQL, ¿tienden a crecer también?

[Carlos Miguel FARIAS]

Que SQL, en realidad deberías decir SGBD o DBMS, PostgreSQL, mysql, SQLServer? En general todos usan arboles ya sea tipo B (para los indices cluster) o B+ para los otros. En general, ninguno usa archivos planos para los datos (como vfp), porque los registros pueden tener longitud fija y no fija como VFP.

Muchos SGBD permiten regular la carga inicial y promedio de los nodos del indice, por eso, si sabes que las claves son siempre de tipo creciente (caso de un autoincremental), podes elevar el factor de carga inicial, porque normalmente, al agregarse las claves nuevas al final, no se producen tantos splits de nodos, en cambio si la carga es muy aleatoria, conviene poner que la carga inicial sea baja, de manera tal que no se tengan que producir tantos splits al momento de agregar claves.

Además esos sistemas en general tienen sistemas de garbage collection automáticos que no implican atención por parte del usuario.

Saludos: Miguel, La Pampa (RA)

[Daniel Del Giudice]

Bueno MIguel, una explicación impresionante. Gracias. A vos también Luis. Lo raro es que esto lo he visto en el 1% de mis clientes, y cuando veo el problema es en todos los archivos del sistema no en uno o dos. Uno podría pensar que algunos cdx pueden aumentar mucho y otros no tanto, pero cuando detectamos el problema todos estan muy "inflados". Sin embargo, un simple reindex lo soluciona.

Por ejemplo:

Antes del reindex

clientes.dbf = 2770 kb

clientes.cdx = 25194 kb

Después del reindex

clientes.dbf = 2770 kb

clientes.cdx = 169 kb

Saludos,

Daniel Del Giudice

 

[Carlos Miguel FARIAS]

Lo mismo (archivos inflados) te va a pasar con los campos memo.

Estos trabajan con cadenas de caracteres y bloques de tamaño fijo.

Cuando se reemplaza el contenido de un campo memo, todo el contenido se guarda a continuación del último pedazo y el segmento sin usar que asi, marcado sin uso, pero no se reutiliza.

Consecuencia, si el texto memo se modifica y tiene contenidos significativos, el archivo crece desmesuradamente y se arregla con un PACK o PACK MEMO.

Saludos: Miguel, La Pampa (RA)