Mantenimiento Parte 1/4


Hace tiempo hablamos de los índices y estadísticas, pero no se comentó el punto de los planes de mantenimiento, un error de mi parte. Como casi todo en la vida las bases de datos se deterioran con el uso, para aminorar el impacto de esto debemos de dar un mantenimiento a las mismas, las 3 fases del mantenimiento preventivo se dividen en, revisión de integridad, mantenimiento de índices y estadísticas y toma de copias de seguridad.

SQL Server maneja sus propios planes de mantenimiento, a mi gusto no son los mejores y prefiero usar los planes de Ola Hallengren que pueden obtener un su página, aunque cualquier plan es mejor que no tener ninguno, así que usen el de su preferencia. Como dice el dicho no hay que reinventar la rueda, estos scripts sirven para la versión 2005 a 2016.

Aquí daré una breve descripción que será cubierta a más detalle en los siguientes días. Las bases de datos deben de cumplir con el ACID (Atomicity, Consitency, Isolation, Durability).

Copia de seguridad (Backup)

Como se mencionó en las copias de seguridad, estos pueden ser o no saludables y en el ACID afecta el la consistencia y durabilidad, a esto nos referimos que internamente los archivos que componen la base de datos pudieron ser dañados por falta de voltaje, problemas de disco, error mismo del motor, sistema operativo, virus, antivirus, mal uso, etc. Y es posible que nosotros no seamos cocientes del daño sino hasta que consultemos o usemos esa parte de la información, o en un reinicio inesperado que corrompe la base (en estos casos la recomendación siempre es recuperar de una copia de seguridad).

Se pueden usar algunos métodos de recuperación que no afectaran la integridad y existen otros que pueden reparar removiendo la parte dañada pero no serán recomendados porque pueden causar inconsistencia en los datos y trabajar con datos erróneos puede resultar peor que trabajar sin datos. Este tipo de revisiones lo que nos garantiza es el correcto estado de la información.

Integridad

Como se menciono en las copias de seguridad, estos pueden ser o no saludables y en el ACID afecta el la consistencia y durabilidad, a esto nos referimos que internamente los archivos que componen la base de datos pudieron ser dañados por falta de voltaje, problemas de disco, error mismo del motor, sistema operativo, virus, antivirus, mal uso, etc. Y es posible que nosotros no seamos cocientes del daño sino hasta que consultemos o usemos esa parte de la información, o en un reinicio inesperado que corrompe la base (en estos casos la recomendación siempre es recuperar de una copia de seguridad).

Se pueden usar algunos métodos de recuperación que no afectaran la integridad y existen otros que pueden reparar removiendo la parte dañada pero no serán recomendados porque pueden causar inconsistencia en los datos y trabajar con datos erróneos puede resultar peor que trabajar sin datos. Este tipo de revisiones lo que nos garantiza es el correcto estado de la información.

Estadísticas e Indices

Las estadísticas y los índices son una parte base de lo que usa el estimador de cardinalidad para crear los planes de ejecución que hacen que la información almacenada sea útil, un mal plan puede afectar la atomicidad y la individualidad de los datos y crear deadlocks o locks así como lentitud generalizada, La falta de un índice puede hacer que hagamos un table scan, un índice mal cuidado puede provocar que hagamos un index scan en lugar de un index seek. Un mal índice que no tiene las estadísticas al día puede hacer que el estimador de cardinalidad decida hacer un index scan cuando ya pudiera usar un seek u talvez otro índice que sería mejor para esta consulta. En algunos casos como en tablas muy grandes (millones de registros) es posible que el proceso automático de actualización de estadísticas no se ejecute tan seguido como uno necesita.

Como podrían observar cada uno de estos puntos afecta el ACID en mayor o menor medida.

Comentarios

Entradas más populares de este blog

Mover indices no clustered a un nuevo filegroup