El mantenimiento de un entorno de SQL Server es una tarea compleja. Aquí están las 10 mejores formas para optimizar su administración.
Muchas empresas han reducido sus departamentos de TIC en los últimos años. Muchos administradores de bases de datos (DBA) han acabado con la responsabilidad de gestionar un gran número de bases de datos SQL Server. Peor aún, a menudo no hay un DBA real. Alguien está etiquetado como el DBA a tiempo parcial. En algunos casos, el DBA termina de bombero, extinguiendo fuegos, pasando de una crisis a otra. Este tipo de ambiente es difícil e insostenible. A nadie le gusta estar bajo un estrés constante.
Una forma de salir de este tipo de situación es invertir un poco de tiempo en racionalizar el entorno SQL Server para que sea más fácil de comprender y manejar. Aquí están las 10 mejores maneras para que un DBA de SQL Server tome el control y reduzca el potencial global de las crisis que se produzcan. La lista está ordenada en tareas de menor a mayor importancia.
Hacer un inventario
¿Cuántas veces se le ha pedido restaurar los datos en una base de datos dañada que no tenía ni idea de que existiera? Es fácil que las bases de datos de SQL Server se expandan cualquier empresa. El equipo de DBA puede perder la pista de lo que hay. Esto se traduce en bases de datos que no reciben mantenimiento o de las cuales no se realizan copias de seguridad.
Es fundamental contar con un inventario actualizado de las instancias y bases de datos que tiene la empresa o/y está bajo el control del DBA. Esta es la única forma de gestionarlas adecuadamente. También ayuda a establecer límites a sus responsabilidades mediante la publicación de una lista de objetos conocidos para los que el DBA acepta la responsabilidad de su gestión. De este modo se puede renegociar si se asume la inclusión de una nueva base de datos bajo la responsabilidad del DBA.
Configuraciones Estandard
Normalmente el número de bases de datos e instancias de SQL de las que el DBA es responsable están creciendo constantemente, del mismo modo el número de configuraciones diferentes crece de forma similar. Es difícil trabajar eficientemente si hay que estar pasando constantemente de una instancia a otra y hay que recordar constantemente los detalles de configuración para cada instancia.
La solución es la estandarización de la configuración en la mayor medida posible, es decir estandarizar tanto las opciones de configuración del servidor como la configuración de las bases de datos, su mantenimiento, las configuraciones de seguridad y así sucesivamente. SQL Server 2008 introdujo la característica de administración basada en directivas para ayudar a definir y hacer cumplir dichas políticas.
Entender el subsistema de E / S
Hay varios factores relacionados con el subsistema de E / S que pueden afectar a las instancias de SQL Server. Es necesario ser consciente de estos y su impacto potencial:
La capacidad del subsistema de E / S en términos de lectura rendimiento / escritura y espacio en disco. Es necesario que este subsistema sea capaz de hacer frente a los picos de demanda de carga de trabajo y todavía proporcionar espacio suficiente para el volumen de datos y ser capaz de crecer antes de tener que comprar más capacidad. La identificación de los cuellos de botella de E / S y del movimiento de datos o archivos de registro nos permitirá reequilibrar estas cargas de trabajo.
Las capacidades de redundancia del subsistema de E / S en términos de nivel de RAID permite hacer cosas como copias de seguridad y cualquier forma de replicación (a nivel de subsistema de E / S, no a nivel de SQL Server). Es importante proteger los datos y archivos de registro de fallos de la unidad y otros problemas potenciales. Esto es a menudo requiere un RAID-10 que ofrece mejor redundancia que un RAID-5, pero es más caro.
Enlaces relacionados.
Crear un plan personalizado de mantenimiento
No se puede poner una base de datos en producción y olvidarse. Los índices se fragmentan con el tiempo, lo que conduce a una degradación del rendimiento. Con el tiempo conduce a malos planes de consulta y bajo rendimiento. Los subsistemas E/S pueden corromperse.
Es posible hacer frente a todos estos problemas con un plan de mantenimiento integral adaptado a las bases de datos. Un plan personalizado es mucho mejor que un plan genérico que no aborde adecuadamente las necesidades específicas de las bases de datos.
Aquí se explica cómo hacerlo.
Garantizar la seguridad del sistema
Una buena inversión de tiempo es tratar de descubrir de forma proactiva los problemas de seguridad esenciales para prevenir incidentes y no tener que lidiar con ellos más tarde.
Tener buenas relaciones con los desarrolladores
Uno de los principales puntos de tensión en cualquier departamento de TI es a menudo entre el equipo de base de datos y el equipo de desarrollo. Los dos grupos por lo general no entienden las prioridades y preocupaciones del otro grupo. Opiniones diferentes acerca de los problemas de conducta, de rendimiento y responsabilidades durante todo el despliegue y puesta en producción son relativamente comunes.
La participación proactiva y productiva con el equipo de desarrollo. La organización de las sesiones de educación mutuos funciona bien, especialmente cuando se hace de una manera no acusatoria. Llevar a cabo las revisiones de diseño con alguien del equipo de DBA presente y el código de prueba de manera adecuada antes de que genere errores perjudiciales de producción evitará erosionar aún más las relaciones entre los equipos. Es conveniente replicar bases de datos idénticas para desarrollo, pre-producción y producción.
Desarrollar una estrategia integral de recuperación de desastres
Por muy robusto que sea nuestro sistema es necesario disponer de un plan de contingencia en caso de desastre. No se pueden predecir fallos, apagones, incendios, pérdida accidental de datos o una serie de problemas potenciales. Es necesario un plan para hacer frente y recuperarse de estos problemas.
Se deben definir los acuerdos de licencia de software de pérdida de datos en cuanto a tiempo de inactividad para las bases de datos, planificar cómo recuperar datos para diferentes tipos de pérdida de datos. Calcular la importancia relativa de todas las bases de datos e instancias para que se pueda priorizar la recuperación de desastres.
También conviene implementar tecnologías para ayudarle a saber cuándo se producen problemas, controles de consistencia, alertas del Agente SQL y alertas del System Center Operations Manager. Una infraestructura de recuperación de desastres ayudará a proteger los datos con copias de seguridad, el trasvase de registros, la replicación y la replicación de bases de datos; y, potencialmente, la conmutación a un sistema redundante con la creación de bases de datos reflejo.
Hacer y probar copias de seguridad regularmente
No importa lo buena que sea la planificación del plan de recuperación de desastres, no se puede evitar hacer regularmente copias de seguridad de las bases de datos. Si la base de datos es destruida o dañada fatalmente, el único recurso puede ser el restablecimiento del último conjunto de copias de seguridad, por lo que si no se dispone de ninguna copia de seguridad la empresa podría sufrir grandes consecuencias. No sólo es necesario realizar copias de seguridad, también es necesario para practicar regularmente la restauración de ellas para estar preparado cuando sea necesario.
Controlar y mantener el rendimiento
El control del rendimiento ocupa la mayor parte del tiempo de un DBA, pero hay un montón de maneras de hacer más eficiente el proceso:
-Establecer una línea base de rendimiento para que pueda ver si el rendimiento ha cambiado realmente.
-Aislar sistema para poder medirlo de forma aislada sin la incertidumbre de factores externos.
-Monitorizar las esperas y colas para detectar rápidamente problemas de rendimiento.
-Supervisar el rendimiento con contadores de rendimiento que lo comparen con el rendimiento inicial y realizar estadísticas. De esta manera sabremos cuando comienza a degradarse el rendimiento. Se puede utilizar la función de recopilador de datos de rendimiento de SQL Server.
- Establecer un plan de mantenimiento.
- Planificar cuidadosamente y ejecutar una estrategia de indexación con herramientas como el optimizador de motor de base de datos, o DTA, el índice de administración dinámica (DMV) y el uso de índices DMV.
Saber dónde encontrar información
Es muy importante saber cuándo buscar ayuda. Es necesario conocer las limitaciones de cada uno y aceptar que no se puede saber todo acerca de SQL Server.
SQL Server Books Online, que se puede descargar e instalar de forma local o buscar a través de internet en MSDN.
Hay un montón de foros de SQL Server en MSDN y sitios de la comunidad populares como SQL Server central.
Otra forma rápida de encontrar ayuda es aprovechar la comunidad de SQL Server en Twitter. Se puede publicar una pregunta con el hashtag #sqlhelp.
Seguir algunos de los muchos blogs a cargo de la comunidad de expertos de SQL Server.
No hay comentarios:
Publicar un comentario