Buenos consejos para el mantenimiento eficaz de bases de datos.

Creado por Paul S. Randal. Viernes, 30 abril 2010 Varias veces por semana me piden consejo sobre cmo mantener de forma efectiva bases de datos de produccin. A veces estas preguntas provienen de administradores de bases de datos que estn implementando nuevas soluciones y necesitan ayuda para optimizar las prcticas de mantenimiento y as adaptarse a las caractersticas nuevas de sus bases de datos. Con mayor frecuencia, sin embargo, las preguntas me llegan de personas que no son administradores profesionales de bases de datos y a quienes, por alguna razn, les han asignado la propiedad y la responsabilidad de una base de datos. A estas personas me gusta llamarlas administradores de bases de datos involuntarios. El objetivo de este artculo es proporcionar una gua de buenas prcticas para el mantenimiento de bases de datos dirigida a todos los administradores de bases de datos involuntarios que hay por el mundo. Al igual que con la mayora de tareas y procedimientos en el mundo de las tecnologas de la informacin, no hay una solucin universal y fcil para el mantenimiento eficaz de bases de datos, aunque s hay una serie de reas clave que casi siempre necesitan abordarse. Mis cinco reas principales de inters (no por orden de importancia) son: Administracin de archivos de datos y archivos de registro Fragmentacin de ndices Estadsticas Deteccin de daos Copias de seguridad Una base de datos sin mantenimiento (o mal mantenida) puede desarrollar problemas en una o ms de estas reas, lo cual a largo plazo puede provocar un mal rendimiento de la aplicacin o incluso tiempos de inactividad y prdida de datos. En este artculo explicar la razn por la que estos problemas son importantes y mostrar unos mtodos sencillos para mitigar los problemas. Basar mis explicaciones en SQL Server 2005 y resaltar asimismo las principales diferencias que encontraremos en SQL Server 2000 y la siguiente versin de SQL Server 2008. Administracin de archivos de datos y archivos de registro La primera rea que siempre recomiendo comprobar a la hora de hacerse cargo de una base de datos es la configuracin de la administracin de archivos de datos y archivos de registro (de transacciones). Concretamente, debe comprobar lo siguiente: Que los archivos de datos y archivos de registro estn separados entre s adems de aislados de todo lo dems. Que el crecimiento automtico est configurado correctamente. Que la inicializacin instantnea de archivos est configurada. Que la auto-reduccin no est habilitada y la reduccin no forme parte de ningn plan de mantenimiento y en caso de ser necesario se reduzca slo los archivos de registro (logs) manualmente. Cuando los archivos de datos y de registro (que lo ideal sera que estuvieran en volmenes completamente separados) comparten el mismo volumen/tamao que cualquier otra aplicacin que crea o ampla archivos, existir la posibilidad de que los archivos se fragmenten. En los archivos de datos, la excesiva fragmentacin de archivos puede ser un factor que contribuya en cierta medida a realizar mal

Pag. 1/11

las consultas (especialmente aquellas que recorren grandes cantidades de datos). En los archivos de registro, la fragmentacin puede tener mucho mayor efecto en el rendimiento, especialmente si la funcin de crecimiento automtico est activada para aumentar el tamao de los archivos con una cantidad muy pequea cada vez que es necesario. Los archivos de registro se dividen internamente en secciones llamadas archivos de registro virtuales (VLF). Cuanto mayor sea la fragmentacin del archivo de registro (empleo el singular aqu porque no supone ninguna ventaja tener mltiples archivos de registro, debera haber solamente uno por cada base de datos), mayor nmero de archivos VLF habr. Cuando un archivo de registro tiene ms de, pongamos, 200 archivos de registro virtuales, el rendimiento se puede ver afectado de forma negativa cuando efecta operaciones relacionadas con el registro, tales como la lectura de registros (para las rplicas o reversiones transaccionales, por ejemplo), las copias de seguridad de registros e incluso los desencadenadores en SQL Server 2000 (la implementacin de desencadenadores se ha cambiado en SQL Server 2005 al marco del control de versiones de filas en lugar del registro de transacciones). El procedimiento recomendado con respecto al tamao de los archivos de datos y de registro es crearlos con un tamao inicial adecuado. En el tamao inicial de los archivos de datos se debe tener en cuenta que existe la posibilidad de que a corto plazo se agreguen datos adicionales a la base de datos. Por ejemplo, si el tamao inicial de los datos es 50 GB, pero se sabe que en los seis meses siguientes se agregarn otros 50 GB de datos, tiene ms sentido crear directamente un archivo de datos de 100 GB que tener que aumentarlo varias veces para alcanzar ese tamao. Por desgracia, esto se complica un poco ms para los archivos de registro y tendr que considerar factores como el tamao de las transacciones (las transacciones de larga ejecucin no pueden eliminarse del registro hasta que se hayan completado) y la frecuencia de copias de seguridad del registro (ya que esto es lo que elimina la parte inactiva del registro). Para ms informacin, consulte el mensaje 8 Steps to Better Transaction Log Throughput escrito por mi esposa, Kimberly Tipp, en el blog SQLskills.COM. Una vez definidos, los tamaos de archivo deben controlarse a varias horas del da y aumentarse manualmente de forma proactiva en un momento adecuado del da. La opcin de crecimiento automtico debe dejarse activada como medida preventiva para as permitir que los archivos puedan crecer si ocurrieran eventos anmalos. La lgica en contra de dejar la administracin de archivos enteramente en manos del crecimiento automtico es que el crecimiento automtico de pequeas cantidades provoca la fragmentacin de archivos y puede convertirse en un proceso largo y lento que atasque la carga de trabajo de la aplicacin en tiempos imprevisibles. El tamao del crecimiento automtico debe establecerse en un valor especfico en lugar de en un porcentaje, para de este modo enlazar el tiempo y el espacio necesario para llevar a cabo el crecimiento automtico, si fuera necesario. Imaginemos, por ejemplo, que quiere definir un archivo de datos de 100 GB para que tenga un tamao fijo de crecimiento automtico de 5 GB en lugar de, digamos, el 10 por ciento. Esto significa que siempre crecer 5 GB independientemente de lo grande que acabe siendo el archivo, en vez de incrementar siempre una cantidad determinada (10 GB, 11 GB, 12 GB, etc.) cada vez que el archivo aumente de tamao. Cada vez que se aumente un registro de transacciones (ya sea manualmente o a travs de crecimiento automtico) ste se inicializar a cero. Los archivos de datos tienen el mismo comportamiento predeterminado en SQL Server 2000, pero si empieza con SQL Server 2005 puede habilitar la inicializacin instantnea de archivos, con lo que se omite la inicializacin a cero de los archivos y se consigue, por tanto, que el crecimiento y el crecimiento automtico sean prcticamente instantneos. Al contrario de lo que muchos creen, esta caracterstica est disponible en todas las ediciones de SQL Server. Para ms informacin, introduzca inicializacin instantnea de archivos en el ndice de los Libros en pantalla de SQL Server 2005 o SQL Server 2008. Por ltimo, debe tener cuidado de que la funcin de reduccin no est habilitada en ningn caso. Esta funcin puede usarse para reducir el tamao de un archivo de datos o de registro, si bien es un proceso muy intrusivo que consume muchos recursos y que causa grandes cantidades de fragmentacin de

Pag. 2/11

exploracin lgica en archivos de datos (para obtener ms detalles, consulte ms abajo) y conlleva un bajo rendimiento. He cambiado la entrada en los Libros en pantalla de SQL Server 2005 por reducir para aadir una advertencia al respecto. No obstante, la reduccin manual de archivos de datos y de registro individuales puede ser aceptable en circunstancias especiales. La reduccin automtica es el peor atacante ya que se inicia cada 30 minutos en segundo plano y trata de reducir las bases de datos que tienen la opcin de reduccin automtica activada. Es un proceso algo impredecible en el que slo se reducen las bases de datos con ms del 25 por ciento de espacio libre. La reduccin automtica usa muchos recursos y provoca una fragmentacin que disminuye el rendimiento, por eso no es una buena estrategia en ningn caso. Debe desactivar siempre la reduccin automtica con el siguiente cdigo:

ALTER DATABASE MyDatabase SET AUTO_SHRINK OFF;

Tener un plan peridico de mantenimiento que contemple un comando manual de reduccin de la base de datos es una idea casi igual de mala. Si cree que su base de datos crece continuamente despus de que el plan de mantenimiento la haya reducido, eso se debe a que la base de datos necesita ese espacio para ejecutarse. Lo mejor que puede hacer es permitir que la base de datos crezca hasta alcanzar un tamao estable y evitar ejecutar la reduccin. Puede encontrar ms informacin sobre las desventajas de utilizar la reduccin adems de comentarios acerca de los nuevos algoritmos de SQL Server 2005 en mi antiguo blog de MSDN en blogs.msdn.com/sqlserverstorageengine/archive/tags/Shrink/default.aspx. Fragmentacin de ndices Aparte de la fragmentacin a nivel de sistema de archivos y dentro del archivo de registro, tambin es posible hacer fragmentaciones dentro de los archivos de datos, en las estructuras que almacenan los datos de tabla e ndice. Hay dos tipos bsicos de fragmentacin que puede ocurrir dentro de un archivo de datos: Fragmentacin dentro de pginas individuales de datos e ndices (a veces denominada fragmentacin interna) Fragmentacin dentro de las estructuras de ndice o tabla formadas por pginas (denominada fragmentacin de exploracin lgica y fragmentacin de exploracin de extensin) La fragmentacin interna es aquella en la que hay mucho espacio vaco en una pgina. Como se muestra en la figura 1, cada pgina de una base de datos tiene un tamao de 8 KB y un encabezado de 96 bytes; por tanto, una pgina puede almacenar unos 8.096 bytes de datos de tabla o ndice (hallar informacin interna especfica de tablas e ndices para estructuras de datos y de filas en la categora Inside the Storage Engine de mi blog, sqlskills.com/blogs/Paul). Puede llegar a generarse espacio en blanco si cada registro de tabla o de ndice ocupa ms de la mitad del tamao de una pgina, ya que slo se puede almacenar un registro por pgina. Esto puede ser muy difcil o imposible de corregir dado que requerira cambios en el esquema de la tabla o del ndice, por ejemplo cambiar una clave de ndice para que no cause la insercin aleatoria de puntos como hace un GUID.

Pag. 3/11

Figura 1 Estructura de la pgina de una base de datos

Con mayor frecuencia, la fragmentacin interna es el resultado de la modificacin de datos, como inserciones, actualizaciones y eliminaciones, operaciones estas que pueden dejar espacios en blanco en una pgina. La mala administracin del factor de relleno tambin puede llegar a contribuir a la fragmentacin; consulte los Libros en pantalla para obtener ms informacin al respecto. Dependiendo del esquema de tabla/ndice y las caractersticas de la aplicacin, es posible que este espacio en blanco, una vez creado, nunca se pueda volver a usar y adems puede provocar el crecimiento incesante de cantidades de espacio no utilizado en la base de datos. Imagnese, por ejemplo, una tabla de 100 millones de filas con un tamao medio de registro de 400 bytes. Con el tiempo, el modelo de modificacin de datos de la aplicacin deja en cada pgina un promedio de 2.800 bytes de espacio libre. El espacio total necesario para la tabla ronda los 59 GB, calculado teniendo en cuenta que 8.096-2.800/400 = 13 registros por 8 KB por pgina, y despus dividiendo 100 millones entre 13 para de esta forma obtener el nmero de pginas. Si no se ha malgastado el espacio, deberan caber 20 registros por pgina, reduciendo as el espacio total necesario a 38 GB. Esto supone un ahorro enorme! Por tanto, el espacio malgastado en pginas de datos o de ndices provoca que se necesiten ms pginas para albergar la misma cantidad de datos. Esto no slo ocupa ms espacio en el disco, sino que adems significa que las consultas tienen que emitir ms E/S para leer la misma cantidad de datos. Y todas estas pginas adicionales ocupan ms espacio en la memoria cach de datos, consumiendo as ms memoria del servidor. La fragmentacin de exploracin lgica es causada por una operacin denominada divisin de pgina. Esto ocurre cuando se quiere insertar un registro en una pgina especfica del ndice (con arreglo a la definicin de la clave de ndice) y no hay suficiente espacio en la pgina para albergar los datos que se desean insertar. Se divide la pgina por la mitad y se mueve aproximadamente el 50 por ciento de los registros a una pgina nueva. Generalmente, esta pgina nueva no es fsicamente contigua a la pgina

Pag. 4/11

previa, por eso se dice que est fragmentada. La fragmentacin de exploracin de extensin tiene un concepto similar. La fragmentacin dentro de estructuras de tabla/ndice afecta a la capacidad de SQL Server para hacer exploraciones eficaces, ya sea de una tabla/un ndice enteros o limitados por una clusula WHERE (como SELECT * FROM MyTable WHERE Column1 > 100 AND Column1 < 4000). La figura 2 muestra las pginas de ndice recin creadas con un factor de relleno del 100 por ciento y ninguna fragmentacin (las pginas estn llenas y el orden fsico de las pginas coincide con el orden lgico). La figura 3 muestra la fragmentacin que se puede producir tras inserciones, actualizaciones, eliminaciones aleatorias.

Figura 2. Pginas de ndice recin creadas sin fragmentacin; pginas llenas al 100%

Figura 3. Pginas de ndice con fragmentacin interna y fragmentacin de exploracin lgica tras inserciones, actualizaciones y eliminaciones aleatorias
A veces se pueden prevenir fragmentaciones cambiando el esquema de tabla/ndice pero, como mencion anteriormente, puede resultar una tarea muy difcil o imposible. Si la prevencin no es una opcin, existen otras maneras de eliminar la fragmentacin una vez que se ha producido; en particular, mediante la regeneracin o reorganizacin de un ndice. Regenerar un ndice implica crear una nueva copia del ndice, bien compactado y tan contiguo como sea posible, y despus eliminar el antiguo ndice fragmentado. Puesto que SQL Server crea una copia nueva del ndice antes de eliminar la antigua, se necesitar tanto espacio libre en los archivos de datos como el aproximadamente equivalente al tamao del ndice. En SQL Server 2000, la regeneracin de un ndice siempre era una operacin sin conexin. En SQL Server 2005 Enterprise Edition, sin embargo, la regeneracin de ndices puede realizarse en lnea, con unas pocas restricciones. La reorganizacin, por otro lado, usa un algoritmo local para compactar y desfragmentar el ndice; requiere solamente 8 KB de espacio adicional para ejecutarse y siempre se ejecuta en lnea. De hecho, en SQL Server 2000 escrib especficamente el cdigo de reorganizacin del ndice como una alternativa en lnea y eficiente en espacio para regenerar ndices. En SQL Server 2005, los comandos para investigar son ALTER INDEX REBUILD, para regenerar ndices, y ALTER INDEX REORGANIZE, para reorganizarlos. Esta sintaxis reemplaza los comandos de SQL Server 2000 DBCC DBREINDEX y DBCC INDEXDEFRAG, respectivamente.

Pag. 5/11

Hay muchas similitudes entre estos mtodos, como la cantidad de registros de transacciones generados, la cantidad de espacio libre necesario en la base de datos y si el proceso es interrumpible sin causar prdidas de trabajo. Encontrar un artculo tcnico que aborda estas similitudes, entre otras cosas, en microsoft.com/technet/prodtechnol/sql/2000/maintain/ss2kidbp.mspx. Aunque este documento se basa en SQL Server 2000, los conceptos se aplican igualmente a versiones posteriores. Algunas personas sencillamente prefieren volver a generar o reorganizar los ndices cada noche o cada semana (usando una opcin de plan de mantenimiento, por ejemplo) en lugar de averiguar qu ndices estn fragmentados y si se sacar algn beneficio de eliminar la fragmentacin. Aunque esta puede ser una buena solucin para un administrador de bases de datos involuntario que desea poner algo en su sitio con el mnimo esfuerzo, tenga en cuenta que puede ser una mala eleccin para bases de datos o sistemas ms grandes, donde escasean los recursos. Un enfoque ms sofisticado implica usar la DMV (vista de administracin dinmica) sys.dm_db_index_physical_stats (o DBCC SHOWCONTIG en SQL Server 2000) para determinar peridicamente qu ndices se fragmentan y despus decidir si y cmo operar en ellos. El artculo tcnico tambin analiza el uso de estas elecciones ms sistemticas. Asimismo puede consultar cdigo de ejemplo para hacer este filtrado en el ejemplo D de la entrada de los Libros en pantalla para la DMV sys.dm_db_index_physical_stats en SQL Server 2005 (msdn.microsoft.com/library/ms188917) o el ejemplo E de la entrada de los Libros en pantalla para el comando DBCC SHOWCONTIG en SQL Server 2000 y versiones posteriores (en msdn.microsoft.com/library/aa258803). Sea cual sea el mtodo que utilice, es altamente recomendable investigar y corregir la fragmentacin con regularidad. El procesador de consultas es la parte de SQL Server que decide cmo se debe ejecutar una consulta, concretamente qu tablas e ndices se usarn y qu operaciones se llevarn a cabo para obtener resultados; lo que se conoce como plan de consulta. Algunas de las entradas ms importantes en este proceso de toma de decisiones son las estadsticas, que describen la distribucin de valores de datos entre columnas dentro de una tabla o un ndice. Obviamente, las estadsticas deben ser exactas y recientes para que le resulten tiles al procesador de consultas, si no se provocar un mal rendimiento del plan de consulta. Las estadsticas se generan leyendo los datos de las tablas o ndices y determinando la distribucin de datos entre las columnas pertinentes. Las estadsticas se pueden crear recorriendo todos los valores de datos de una columna en concreto (recorrido completo), aunque tambin se pueden basar en un porcentaje de datos definido por el usuario (recorrido de muestra). Si la distribucin de valores en una columna est bien compensada, entonces bastar con un recorrido de muestra, lo que resultar ms rpido que crear y actualizar las estadsticas con un recorrido completo. Tenga en cuenta que es posible crear y mantener estadsticas automticamente estableciendo las opciones de base de datos AUTO_CREATE_STATISTICS y AUTO_UPDATE_STATISTICS en ON, como se muestra en la figura 4. Estas opciones estn activadas de forma predeterminada, pero si acaba de heredar una base de datos se recomienda comprobarlo para asegurarse. Cuando las estadsticas se quedan desfasadas es posible actualizarlas manualmente con la instruccin UPDATE STATISTICS en conjuntos especficos de estadsticas. Tambin se puede usar el procedimiento almacenado sp_updatestats, que actualiza todas las estadsticas desfasadas (en SQL Server 2000, sp_updatestats actualiza todas las estadsticas, independientemente de su antigedad).

Pag. 6/11

Figura 4 Cambios en la configuracin de la base de datos a travs de SQL Server Management Studio
Si desea actualizar las estadsticas en el marco de su plan peridico de mantenimiento, hay un truco que debera considerar. Tanto UPDATE STATISTICS como sp_updatestats se vuelven de manera predeterminada al nivel de muestreo anteriormente especificado (si existe), que puede ser menos que un recorrido completo. El ndice regenera automticamente estadsticas de actualizacin con un recorrido completo. Si actualiza estadsticas manualmente tras una regeneracin de ndice, es posible que acabe con estadsticas menos precisas. Esto puede ocurrir si el recorrido de muestra de la actualizacin manual sobrescribe el recorrido completo provocado por la regeneracin de ndice. Por otro lado, al reorganizar ndices no se actualizan las estadsticas. Repito, hay muchas personas que tienen un plan de mantenimiento que actualiza todas las estadsticas en algn momento antes o despus de regenerar todos los ndices (y sin saberlo acaban teniendo unas estadsticas probablemente menos precisas). Si sencillamente opta por regenerar todos los ndices cada cierto tiempo, de esta forma tambin se ocupar de las estadsticas. Si decide tomar una va ms compleja con eliminacin de fragmentacin, tambin debe hacerlo para el mantenimiento de las estadsticas. Sugiero que haga lo siguiente: Analice los ndices y determine cmo y en cules va a aplicar la eliminacin de fragmentacin. Actualice las estadsticas de todos los ndices no regenerados. Actualice las estadsticas de todas las columnas no indizadas.

Pag. 7/11

Para obtener ms informacin sobre estadsticas, consulte el artculo tcnico Estadsticas usadas por el optimizador de consultas en Microsoft SQL Server 2005 (microsoft.com/technet/prodtechnol/sql/2005/qrystats.mspx).

Deteccin de daos Hasta el momento he hablado del mantenimiento relacionado con el rendimiento. Ahora voy a cambiar de tercio y tratar la deteccin y mitigacin de daos. Es muy improbable que la base de datos que est administrando contenga informacin completamente intil que no le interese a nadie, entonces cmo puede hacer para asegurarse de que no se daen los datos y que stos se puedan recuperar en caso de desastre? Los detalles acerca de cmo crear una estrategia de recuperacin en caso de desastre y de alta disponibilidad quedan fuera del mbito de este artculo, si bien hay unas cuantas cosas que puede ir haciendo para empezar. La gran mayora de los daos son causados por el hardware. Por qu lo escribo entre comillas? Bueno, en realidad el hardware se emplea aqu como forma abreviada para algo en el subsistema de E/S dentro de SQL Server. El subsistema de E/S est formado por elementos tales como el sistema operativo, los controladores del sistema de archivos, los controladores de dispositivos, los controladores RAID, los cables, las redes y las propias unidades de disco reales. Son muchos sitios donde pueden (y suelen) surgir problemas. Uno de los problemas ms comunes se produce cuando falla el suministro elctrico y una unidad de disco est en pleno proceso de escritura de una pgina en la base de datos. Si la unidad de disco no consigue completar el proceso de escritura antes de quedarse sin electricidad (o las operaciones de escritura se copian en cach y no hay suficiente batera de reserva para vaciar la memoria cach de la unidad), el resultado podra ser una imagen de pgina incompleta en el disco. Esto puede suceder porque una pgina de base de datos de 8 KB est compuesta por 16 sectores contiguos de disco de 512 bytes. Una escritura incompleta podra escribir algunos de los sectores de la pgina nueva pero dejar algunos de los sectores de la imagen de la pgina anterior sin escribir. Esta situacin se conoce como pgina rasgada. Cmo se detecta esto cuando sucede? SQL Server tiene un mecanismo para detectar esta situacin. Consiste en almacenar un par de bits de cada sector de la pgina y escribir un patrn especfico en su lugar (esto sucede poco antes de que se escriba la pgina en el disco). Si el patrn no es el mismo cuando la pgina se vuelve a leer, SQL Server sabr que la pgina se ha rasgado y generar un error. En SQL Server 2005 y versiones posteriores se incluye un mecanismo ms completo llamado sumas de comprobacin de pgina que puede detectar cualquier dao en una pgina. Consiste en escribir una suma de comprobacin de una pgina completa en la pgina justo antes de de escribirla en el disco y despus probarla cuando la pgina se vuelva a leer, igual que para detectar pginas rasgadas. Tras habilitar las sumas de comprobacin de pgina, habr que leer una pgina en el grupo de bferes, cambiarla de alguna manera y luego escribirla al disco otra vez antes de que una suma de comprobacin de pgina la proteja. Por tanto, se recomienda tener las sumas de comprobacin de pgina activadas para SQL Server 2005 en adelante, con la deteccin de pginas rasgadas habilitada para SQL Server 2000. Para habilitar sumas de comprobacin de pgina puede usar:

ALTER DATABASE MyDatabase SET PAGE_VERIFY CHECKSUM;

Para habilitar la deteccin de pginas rasgadas en SQL Server 2000 puede usar:

ALTER DATABASE MyDatabase SET TORN_PAGE_DETECTION ON;

Pag. 8/11

Con estos mecanismos puede detectar que una pgina contiene errores, pero solamente al leerla. Cmo forzar fcilmente que se lean todas las pginas asignadas? El mejor mtodo para hacer esto (y para encontrar cualquier otra clase de error) es usar el comando DBCC CHECKDB. A pesar de las opciones especificadas, este comando siempre leer todas las pginas de la base de datos, causando por tanto que se verifiquen todas las sumas de comprobacin de pgina o detecciones de pginas rasgadas. Tambin debe activar alertas para saber en qu momento los usuarios se encuentran con errores durante la ejecucin de consultas. Puede recibir notificaciones de todos los problemas descritos arriba usando una alerta para errores de gravedad 24 (figura 5).

Figura 5 Configuracin de una alerta para los errores de gravedad 24

Tambin es una buena costumbre ejecutar regularmente DBCC CHECKDB en las bases de datos con el objetivo de comprobar su integridad. Hay muchas variantes de este comando y tantas otras preguntas acerca de la frecuencia con que debe ejecutarse. Por desgracia, no hay artculos tcnicos que traten este tema. Sin embargo, como DBCC CHECKDB es la parte principal de cdigo que escrib para SQL Server 2005, he tratado este asunto extensamente en mi blog. Consulte la categora CHECKDB From Every Angle de mi blog (sqlskills.com/blogs/paul), donde encontrar numerosos artculos sobre comprobaciones de coherencia, prcticas recomendadas y consejos prcticos. Para administradores de bases de datos involuntarios, la regla general es ejecutar un DBCC CHECKDB tan a menudo como se hagan copias de seguridad completas de la base de datos (ms adelante hallar ms informacin al respecto). Recomiendo ejecutar el siguiente comando:

DBCC CHECKDB ('MyDatabase') WITH NO_INFOMSGS, ALL_ERRORMSGS;

Si este comando da resultados, DBCC habr hallado daos en la base de datos. La pregunta siguiente ser qu hacer si DBCC CHECKDB encuentra errores. Aqu es donde entran en juego las copias de seguridad. Cuando ocurre un dao u otro desastre, la manera ms efectiva de recuperar datos es restaurando la base de datos a partir de copias de seguridad. Ahora bien, con esto se da por supuesto que hay copias de seguridad y que stas no estn daadas. Pasa con demasiada frecuencia que las personas que desean saber cmo conseguir que una base de datos daada vuelva a funcionar, no disponen de copias de seguridad. La respuesta fcil es que, sencillamente, no puede, no sin experimentar algn tipo de prdida de datos que podra hacer estragos en su lgica empresarial e integridad de sus datos relacionales.

Pag. 9/11

As que aqu tenemos un ejemplo muy claro de por qu realizar copias de seguridad con regularidad. Si bien es cierto que las implicaciones de usar copias de seguridad y restaurar quedan fuera del mbito de este artculo, me permiten ofrecerle una ayuda rpida sobre cmo establecer una estrategia de copias de seguridad. En primer lugar debe efectuar con regularidad copias de seguridad completas de la base de datos. De este modo crear una nica versin puntual de lo que podr restaurar ms adelante. Para realizar una copia de seguridad completa de la base de datos use el comando BACKUP DATABASE. Consulte ejemplos en los Libros en pantalla. Para mayor proteccin, puede usar la opcin WITH CHECKSUM, que comprueba las sumas de comprobacin de pgina (si existen) de las pginas que se estn leyendo y calcula una suma de comprobacin de toda la copia de seguridad. Debe seleccionar una frecuencia que refleje cuntos datos o trabajo podra estar dispuesto a perder su negocio. Por ejemplo, realizar una copia de seguridad completa de la base de datos una vez al da significa que se podra perder hasta el valor de los datos de un da en caso de desastre. Si slo usa copias de seguridad completas de la base de datos, debera estar en el modelo de recuperacin SIMPLE (denominado comnmente modo de recuperacin) para as evitar complicaciones relacionadas con la administracin del crecimiento del registro de transacciones. En segundo lugar, conserve siempre las copias de seguridad durante unos cuantos das para el caso de que alguna de ellas estuviera daada (una copia de seguridad de hace unos das siempre es mejor que ninguna copia de seguridad). Tambin debe comprobar la integridad de sus copias de seguridad, para ello use el comando RESTORE WITH VERIFYONLY (una vez ms, consulte los Libros en pantalla). Si utiliz la opcin WITH CHECKSUM cuando se cre la copia de seguridad, ejecutar el comando de verificacin comprobar que la suma de comprobacin de la copia de seguridad todava es vlida y revisar todas las sumas de comprobacin de las pginas contenidas en la copia de seguridad. En tercer lugar, si realizar cada da una copia de seguridad completa de la base de datos no es suficiente para cumplir con la prdida mxima de datos/trabajo que admite su negocio, se recomienda investigar las copias de seguridad diferenciales de la base de datos. Una copia de seguridad diferencial de la base de datos se basa en una copia de seguridad completa de la base de datos y contiene un registro de todos los cambios producidos desde la ltima copia de seguridad completa de la base de datos (un error que se comete a menudo es creer que las copias de seguridad diferenciales son incrementales, y no lo son). Un ejemplo de estrategia podra ser efectuar una copia de seguridad diaria completa de la base de datos con una copia de seguridad diferencial de la base de datos cada cuatro horas. Las copias de seguridad diferenciales ofrecen una nica opcin extra de recuperacin a un momento dado. Si slo usa copias de seguridad completas y diferenciales de la base de datos, debe seguir usando el modelo de recuperacin simple. Para finalizar, lo ltimo en recuperacin son las copias de seguridad de registros. stas slo estn disponibles en los modelos de recuperacin FULL (o BULK_LOGGED) y proporcionan una copia de seguridad de todos los registros generados desde la ltima copia de seguridad de registros. Mantener un conjunto de copias de seguridad de registros con copias de seguridad completas de la base de datos (y quizs copias diferenciales de la base de datos) proporciona un nmero ilimitado de versiones a un momento dado para recuperar, incluida una recuperacin actualizada. Debe tenerse en cuenta que el registro de transacciones continuar creciendo a no ser que se libere efectuando una copia de seguridad de registros. Un ejemplo para este caso sera realizar una copia de seguridad completa de la base de datos cada da, una copia de seguridad diferencial de la base de datos cada cuatro horas y una copia de seguridad de registros cada media hora. Optar por una estrategia de copias de seguridad y configurarla puede ser una tarea complicada. Como mnimo, debe realizar una copia de seguridad peridica completa de la base de datos para asegurarse de que tiene por lo menos una copia a un momento dado desde la que recuperar informacin. Como puede ver, para garantizar que su base de datos permanezca en buen estado y disponible hay unas cuantas tareas que tiene que realizar. He aqu mi lista de comprobacin final para un administrador de base de datos involuntario que se hace cargo de una base de datos:

Pag. 10/11

Elimine la fragmentacin excesiva del archivo de registro de transacciones. Establezca el crecimiento automtico correctamente. Desactive las operaciones de reduccin programadas. Active la inicializacin instantnea de archivos. Implemente un proceso peridico para detectar y eliminar la fragmentacin de ndices. Establezca AUTO_CREATE_STATISTICS y AUTO_UPDATE_STATISTICS en ON e implemente un proceso peridico para actualizar estadsticas. Active la opcin de sumas de comprobacin de pgina (o, como mnimo, la deteccin de pginas rasgadas en SQL Server 2000). Disponga de un proceso peridico para ejecutar DBCC CHECKDB. Implemente un proceso peridico para efectuar copias de seguridad completas de la base de datos, adems de copias de seguridad diferenciales y copias de seguridad de registros para la recuperacin a un momento dado. En este artculo he usado comandos de T-SQL, pero tambin se pueden hacer muchas cosas desde Management Studio. Espero haberle dado algunos consejos tiles para el mantenimiento efectivo de bases de datos. Si tiene comentarios o preguntas, escrbame a paul@sqlskills.com.

Pag. 11/11