jump to navigation

msSQL – Mantenga su base de datos SQL desfragmentada con Diskeeper

Fuente: http://www.sql-server-performance.com/articles/dba/sql_fragmentation_diskeeper_p1.aspx

By : Howard Butler Sr. and Michael Materie
May 17, 2007

Todas las bases de datos SQL, con el correr del tiempo experimentan fragmentación interna de sus datos. Esto ocurre cuando los registros son removidos de una base de datos pero el espacio que ellos ocupaban sigue ahí luego de eliminado. Eventualmente este espacio es reutilizado, pero mientras que el mismo va siendo utilizado los datos se van tornando fragmentados, lo que puede llevar a operaciones de entrada/salida innecesarias, especialmente en casos de escaneo de tablas donde muchas páginas son leídas una detrás de la otra.

En SQL Server existen varios métodos para corregir la fragmentación interna. Uno de esos métodos es utilizar el comando DBCC REINDEX para reconstruir índices agrupados y no agrupados

Desafortunadamente, la fragmentación interna es solo una parte del problema de la fragmentación. Cuando DBCC REINDEX es ejecutado, este no hace nada contra la “fragmentación externa”. La fragmentación externa se refiere a la fragmentación de archivos en los discos del servidor, lo que puede causar tanto, y quizás mas problemas de entrada/salida como la fragmentación interna. Actividades de entrada/salida innecesarias, afectan el desempeño general de SQL Server.

Las bases de datos de SQL Server están formadas por grandes bases de datos y archivos de historial que tienen tamaño preasignado al momento de su creación. Si hay suficiente espacio contiguo en el disco cuando los ficheros originales son creados estos no serán fragmentados. Pero por el contrario si el espacio disponible no es contiguo, entonces esas bases de datos y archivos de historial serán fragmentados.

Inclusive si la base de datos original y el archivo de historial no están fragmentados cuando estos son creados por primera vez, estos muy probablemente se volverán fragmentados a medida que la base de datos crece. Por ejemplo si uno define la base de datos con un tamaño de 100MB y el archivo de historial a un tamaño de 10 MB, y los define para que estos puedan crecer en tamaño, puede ocurrir que la base de datos termine ocupando un tamaño de 5 gigas y el historial 100MB, en este caso hipotético la fragmentación externa se puede tornar muy grande. Cada vez que la base de datos o el archivo de historial crece, existe posibilidad de que ocurra fragmentación externa.

Para desfragmentar la fragmentación externa  se necesita una utilidad del sistema operativo, no una utilidad del SQL Server. Una de las aplicaciones mas populares para desfragmentar bases de datos SQL es una herramienta de la Diskeeper Corporation llamada Diskeeper. Esta herramienta estuvo en el mercado desde hace ya varios años, y muchos de ustedes seguramente ya están familiarizados con ella sobre todo en lo que refiere a archivos de Windows y servidores de impresión. Con lo que muchos administradores de bases de datos no están familiarizados es con el hecho de que esta herramienta es probablemente una de las mejores existentes para desfragmentar la fragmentación externa en sus servidores SQL.

Cuando una herramienta de fragmentación externa como Diskeeper corre, esta no reestructura los contenidos internos del fichero (como si hace DBCC REINDEX). Luego de que Diskeeper desfragmenta un fichero, el fichero desfragmentador será un duplicado bit a bit del original. Entonces, cualquier agujero dentro de la base de datos seguirá estando presente y se necesitara, cada intervalo de tiempos regulares, reconstruir los índices para combatir la fragmentación interna.

Existen dos tipos de fragmentación externa que un utilitario como Diskeeper soluciona: fragmentación de ficheros y fragmentación de espacio libre. La fragmentación de ficheros comprende a ficheros que no están completamente unidos, sino por el contrario están partidos en varias partes, la desfragmentación de espacio libre significa que el espacio libre en un disco esta repartido en varias partes en lugar de estar todo junto en un gran espacio vacío. La fragmentación de fichero causa problemas al acceder a datos guardados en disquetes de computadora, y la fragmentación de espacio libre puede causar problemas al crear nuevos ficheros o al extender los ya existentes.

Entonces cuando Diskeeper se ejecuta, actúa para defragmentar la base de datos y los ficheros de historial para que en lugar de estar compuestos de muchos pedazos, el fichero sea un segmento continuo. En adición a esto, Diskeeper desfragmenta el espacio libre para que cuando la base de datos o los ficheros de historial se expandan estos lo pueda hacer con poca o directamente sin fragmentación. Pero esto no dura para siempre. Eventualmente, la fragmentación se convierte en un problema, y la base de datos y los ficheros de historial deben ser desfragmentador nuevamente, Idealmente la desfragmentación debe ser realizada regularmente para prevenir que ocurra fragmentación innecesaria.

Ahora viene algo en lo cual seguramente no hayas pensado antes. ¿Cuál es el efecto que tiene la fragmentación al reconstruir los índices de SQL Server? En otras palabras, si no realizas la desfragmentación de ficheros, pero si realizas una desfragmentación interna de los índices y registros, ¿Existe alguna contra para esto?

Si, puede existir, porque los ficheros están fragmentados, tardará mucho más tiempo a SQL Server y las entradas/salidas para reconstruir sus índices en ficheros fragmentados que lo que tardaría en ficheros contiguos. Esto significa que antes de realizar una desfragmentación interna deberías plantearte de realizar una desfragmentación de ficheros primero. De esta manera, reduces el tiempo que tardará en reconstruir tus índices, y también reducirás la carga de entrada/salida en tu Server durante al proceso de reconstrucción de índices.

Mientras que la fragmentación en la base de datos de SQL Server y el fichero de historial pueden tener una repercusión negativa en el rendimiento de SQL Server, no hay que olvidarse que también existen otros ficheros que el SQL Server accede, como los ejecutables del SQL Server, y si esta utilizando indexado de Full-Text, también tendríamos que incluir a los ficheros índices de Full-Text. Entonces no solo hay que desfragmentar la base de datos y los ficheros de historial, sino todos los ficheros localizados en tu SQL Server.

Todos los movimientos de ficheros en la desfragmentación mediante Diskeeper son manejados por el propio sistema operativo. De hecho, el código en el sistema operativo, el cual fue originalmente escrito en conjunto con la Diskeeper Corporation, da prioridad a la seguridad en al momento de decidir que puede ser defragmentado y que no. Las bases de datos de SQL (Por ejemplo: LDF, MDF) son perfectamente seguras para defragmentar. Dado que Diskeeper envía pedidos al sistema operativo (mediante una API) para mover archivos, si este toma contacto con un fichero que no puede ser movido en forma segura, este es simplemente salteado sin ningún tipo de error o problema.

Entonces, ¿Cómo uno sabe si los ficheros en su SQL Server están fragmentados? Afortunadamente, esto es fácil. Como parte de las funcionalidades de Diskeeper, uno puede correr un análisis de fragmentación para ver cuan fragmentados están nuestros ficheros de SQL Server. Como con la desfragmentación esto puede hacerse mientras el SQL esta corriendo.

Como puedes imaginar, es difícil recomendar un tiempo y marco determinado sobre el cual correr una desfragmentación de ficheros, ya que cada base de datos es diferente y la fragmentación ocurre en distintos grados. Diskeeper implementa una característica de desframentación dinámica “al vuelo” llamada InvisiTasking, esta garantiza que la desfragmentación opera en forma invisible, con cero impacto en los recursos de SQL Server y otras aplicaciones que estén corriendo. Y si, tú puedes también restringir los tiempos de ejecución de diskeeper si así lo deseas.


COMENTARIOS:

Andrade Darriba, Gonzalo-3701-0189
Fernández, Juan Gabriel-3101-3421
García, Manuel-3601-1518
Seguí, María Victoria-3701-0508
Suarez, Pablo-3501-2656
Sutz Kaelin, Guillermo-3701-1192

En este primer artículo apreciamos el tratamiento al cual debemos considerar someter nuestras bases de datos para solucionar los problemas denominados “Fragmentación Interna” y “Fragmentación Externa”. La primera se trata de los bits que van quedando intercalados en las tablas que componen las bases de datos los cuales corresponden a datos que han sido eliminados en las mismas, mientras que la segunda forma de fragmentación corresponde a las divisiones que se producen en los archivos contenedores de dichas tablas a medida que las mismas van incrementando su tamaño.

Ambos tipos de fragmentación perjudican el desempeño de la base de datos incrementando el tamaño de sus archivos y prolongando los tiempos en el cumplimiento de sus trabajos al producir tareas de entrada-salida innecesarias, es posible corregir los factores que producen este perjuicio de un modo simple y seguro, a saber:
– La fragmentación interna se soluciona mediante la utilización de una aplicación incluida en SQL Server (BDCC Reindex) con la cual logramos corregir los índices de la base de datos.
– Para solucionar la fragmentación externa no contamos con ninguna utilidad del SQL Server por lo que dependemos de que la misma sea solucionada desde el sistema operativo. Para esto existe un producto de Diskeeper Corporation. El Diskeeper se encarga de unir los fragmentos en los cuales esta dividido un archivo con lo cual logramos reparar el fraccionamiento externo de los archivos de la base de datos, esto lo hace de una forma segura pues ante la imposibilidad de reunir los fragmentos sin alterar el contenido del mismo (archivos inamovibles) Diskeeper decide no tocarlo evitando de este modo afectar su contenido en forma alguna.

No es indistinto el orden en que hagamos estos procedimientos, la defragmentación interna debe ser solucionada previo a la defragmentación externa, para lograr el mejor efecto en el procedimiento

Estas soluciones no son definitivas pues al continuar trabajando con la base de datos la misma es pasible de nuevas fragmentaciones tanto internas como externas por lo cual se debe periódicamente repetir ambos procedimientos para lograr mantener una base de datos trabajando con mayor efectividad.


 

A %d blogueros les gusta esto: