SQL Server: Los 10 secretos principales de un experto en SQL Server

Artículo
08/23/2016

Mantener un entorno SQL server es un trabajo potencialmente complejo. Las siguientes son las 10 formas principales de minimizar la complejidad y reducir el estrés.

Paul S. Randal

Muchas empresas han reducido sus departamentos de TI durante los últimos años. Muchos administradores de bases de datos (DBA) han terminado siendo responsables de grandes cantidades de bases de datos de SQL Server. Lo que es peor, con frecuencia no hay disponibles administradores reales. Una persona es etiquetada como el administrador de bases de datos involuntario o de hecho. En algunos casos, el administrador termina luchando contra los problemas cotidianos, pasando de una crisis a la siguiente. Este tipo de entorno es difícil, tóxico e insostenible. A nadie le agrada estar bajo estrés e interrupción constantes.

Una forma de salir de este tipo de situación consiste en invertir un poco de tiempo en simplificar el entorno de SQL Server para facilitar su comprensión y administración. De acuerdo con mis servicios de asesoramiento en SQL Server, estas son las 10 formas principales en que un administrador de bases de datos de SQL Server puede controlar su entorno y reducir la posibilidad general de que se produzcan crisis. Esta lista se presenta en un orden creciente aproximado de importancia.

10. Realizar un inventario

¿Cuántas veces le han solicitado restaurar los datos dañados de una base de datos que ni siquiera tenía idea que existía? Es fácil la expansión de bases de datos de SQL Server a través de una empresa. El equipo de administradores de bases de datos puede perder la pista de lo que hay allá fuera y con ello ocasionar instancias no administradas de SQL Server. Esto deriva en bases de datos que no tienen copia de seguridad, que no se revisan, que no están protegidas de forma correcta y que desaprovechan un host de otras tareas necesarias de administración.

Es fundamental contar con un inventario actualizado de las instancias y bases de datos que tiene en su empresa y bajo su control. Esta es la única forma en que puede administrarlas correctamente, consolidar donde sea necesario y evaluar correctamente el alcance de proyectos y actualizaciones y planificarlos. También le ayuda a establecer límites a sus responsabilidades al publicar una lista de instancias conocidas para las cuales usted acepta la responsabilidad, con el acuerdo de los diversos equipos de su organización. Puede definir directivas de soporte para instancias conocidas e insistir en que las nuevas instancias cumplan con sus pautas de configuración antes de admitirlas.

Existe una serie de herramientas que le permiten crear un inventario de SQL Server: desde herramientas sencillas como SQLPing3 y SQLRecon hasta Microsoft Assessment and Planning Toolkit y Quest Discovery Wizard.

9. Estandarizar configuraciones

Si el número de bases de datos e instancias de SQL de los cuales es responsable crece constantemente, sabrá que el número de configuraciones distintas crece de manera similar. Es extremadamente difícil trabajar de forma eficaz al pasar de una instancia a otra si constantemente debe recordar los detalles de configuración de las distintas instancias.

La solución es estandarizar la configuración al mayor grado posible en términos de letras de unidad, opciones de configuración del servidor, configuración de bases de datos, mantenimiento de bases de datos, configuración de seguridad, etc. SQL Server 2008 presentó la característica de Administración basada en directivas para ayudar a definir y aplicar directivas. Lara Rubbelke, especialista en tecnología de SQL Server de Microsoft, también produjo Enterprise Policy Management (EPM) Framework, el cual amplía fácilmente las capacidades a instancias de SQL Server 2005 y SQL Server 2000. Puede encontrar EPM Framework en CodePlex. En la figura 1 se presenta un informe de muestra de EPM Framework.

The Enterprise Policy Management Framework report

Figura 1 Informe de Enterprise Policy Management Framework

8. Comprender el subsistema de E/S

Hay varios factores relacionados con el subsistema de E/S que pueden afectar las instancias de SQL Server. Debe conocer estos factores y su posible impacto:

La capacidad del subsistema de E/S en cuanto a leer/escribir capacidad de proceso y espacio en disco. Debe hacer frente a las demandas máximas de carga de trabajo y seguir proporcionando espacio para el crecimiento del volumen de datos antes de tener que adquirir más capacidad. Al identificar cuellos de botella de E/S y al mover datos y/o registrar archivos en otras partes del subsistema de E/S, podrá equilibrar la carga de manera más uniforme.
Las capacidades de redundancia del subsistema de E/S en términos de nivel de RAID y si puede hacer cosas como copias de seguridad de reflejo dividido y cualquier forma de creación de reflejo/replicación (en el nivel del subsistema de E/S, no el nivel de SQL Server). Es importante que proteja sus datos y archivos de registro contra errores de unidad y otros posibles problemas. Esto suele tener ventajas y desventajas: RAID-10 ofrece mejor redundancia que RAID-5, pero es más caro. Lea las notas del producto “Diseño de almacenamiento físico en base de datos” para obtener más orientación.
El subsistema de E/S se configura correctamente en términos del tamaño de las bandas de RAID, tamaño de unidad/clúster de asignación NTFS y alineación de particiones. Para obtener más detalles, consulte este blog “¿Están configurados correctamente los desplazamientos de particiones de disco, el tamaño de las bandas de RAID y las unidades de asignación NTFS?”.

7. Crear un plan de mantenimiento personalizado

Cada vez que dicto clases de mantenimiento de bases de datos siempre comienzo diciendo: “No pueden simplemente poner una base de datos en producción y marcharse”. Con el transcurso del tiempo los índices se fragmentan, lo que produce una degradación del rendimiento. Las estadísticas se desactualizan, lo que genera malos planes de consultas y un rendimiento deficiente. Los subsistemas de E/S pueden dañarse, por eso siempre es necesario contar con copias de seguridad.

Puede abordar todos estos problemas si cuenta con un plan de mantenimiento completo que se adapte a sus bases de datos. Un plan personalizado es mucho mejor que un plan genérico que no satisface adecuadamente sus necesidades. Mi artículo de agosto de 2008 en TechNet Magazine, “Sugerencias principales para un mantenimiento eficaz de la base de datos de SQL Server”, le informará cómo construir un buen plan de mantenimiento. El mejor punto de partida para elaborar su propio plan de mantenimiento es el texto completo y gratuito de Ola Hallengren. Eso es lo que recomiendo a mis clientes.

6. Garantizar la seguridad del sistema

Invertir tiempo en descubrir proactivamente los problemas de seguridad es fundamental para prevenir incidentes y no tener que ocuparse de ellos después. Otro de mis artículos de TechNet Magazine, “Problemas y soluciones habituales de seguridad de SQL Server”, señala los 10 problemas de seguridad más comunes y cómo evitarlos. Además, no olvide llevar el control de la revisión de los sistemas a medida que descubre las vulnerabilidades.

5. Llegar a buenos términos con los desarrolladores

Uno de los mayores puntos de tensión en cualquier departamento de TI suele darse entre el equipo de administradores de bases de datos y el equipo de desarrollo. Lo dos grupos por lo general no entienden las prioridades e inquietudes del otro, desde fechas límite de desarrollo hasta decisiones de diseño de SQL Server. Es relativamente común que haya diferentes opiniones sobre problemas de comportamiento y rendimiento y las responsabilidades en torno a implementación y soporte.

Puede agilizar más su trabajo al relacionarse proactiva y productivamente con el equipo de desarrollo. La organización de sesiones educativas mutuas da buenos resultados, en especial cuando se realizan de manera no acusatoria. Lleve a cabo revisiones de diseño con alguien presente del equipo de administradores de bases de datos y realice pruebas de código de forma adecuada antes de llevar a producción, con la esperanza de evitar errores dañinos que puedan erosionar aún más las relaciones entre los equipos.

4. Desarrollar una estrategia completa de recuperación ante desastres

Independientemente de lo infalible que pueda ser su infraestructura, debe contar con un plan de contingencia para cuando se produzca algún desastre. No se pueden predecir daños, cortes del suministro de energía, incendios, pérdida accidental de datos ni muchos otros problemas potenciales. Necesitará un plan para encarar esos problemas y recuperarse de ellos.

Trabaje con la administración para definir contratos de licencia de software con tiempo de inactividad y pérdida de datos para sus bases de datos, planifique cómo recuperar datos desde diversos tipos de pérdida de los mismos y determine cómo las bases de datos y todas las instancias de SQL figuran en el plan de continuidad de negocios de su empresa. Analice la importancia relativa de todas las bases de datos e instancias de modo que pueda dar prioridad a la recuperación ante desastres.

También deberá implementar tecnologías que lo ayuden a saber cuándo se producen los problemas, como comprobaciones de página, comprobaciones de coherencia, alertas del Agente SQL y alertas de System Center Operations Manager. La infraestructura de recuperación ante desastres le permitirá proteger los datos con copias de seguridad, envío de registros, replicación y creación de reflejos de bases de datos; y posiblemente conmutar por error a un sistema redundante con creación de reflejos de bases de datos o clústeres de conmutación por error. Hay dos notas del producto de Microsoft que pueden ayudarlo con esto: “Alta disponibilidad con SQL Server 2008” y “Arquitecturas probadas de SQL Server para alta disponibilidad y recuperación ante desastres”.

3. Realizar y probar copias de seguridad en forma regular

Independientemente de lo buena que sea su planificación de alta disponibilidad y recuperación ante desastres, no podrá evitar realizar copias de seguridad de las bases de datos en forma regular. Si su base de datos se destruye o queda dañada de manera fatal, es posible que su único recurso sea restaurar a partir del último conjunto de copias de seguridad; por lo tanto, si no tiene copias de seguridad, su empresa podría sufrir graves consecuencias. No sólo debe realizar copias de seguridad, sino que también debe practicar regularmente la restauración de ellas para saber que funcionarán cuando se necesiten.

Puede encontrar más información en dos artículos que escribí para TechNet Magazine en 2009: “Descripción general de las copias de seguridad de SQL Server” y “SQL Server: Recuperación ante desastres mediante copias de seguridad”.

2. Supervisar y mantener el rendimiento

La optimización del rendimiento ocupa la mayor parte del tiempo de un administrador de bases de datos, pero hay muchas formas de simplificar el proceso:

Establezca una línea de referencia de rendimiento para que pueda ver si éste realmente ha cambiado.
Desglose el sistema en primitivas que pueda medir de manera aislada sin la incertidumbre de factores externos.
Utilice la metodología de esperas y colas para identificar rápidamente los problemas de rendimiento.
Supervise el rendimiento con primitivas del sistema, contadores de rendimiento y estadísticas de espera. Así sabrá cuándo comienza a degradarse el rendimiento. Utilice la característica Recopilador de datos de rendimiento de SQL Server 2008 y el Panel de información de rendimiento para SQL Server 2005.
Establezca un plan de mantenimiento.
Planifique y ejecute con cuidado su estrategia de indización con herramientas como Asistente para la optimización de motor de base de datos, o DTA, Vistas de administración dinámicas (DMV) de índices que faltan y DMV de uso de índices.

1. Saber dónde encontrar información

Con una lista de tareas pendientes sin fin, es vital que sepa cuándo concluir y buscar ayuda. Debe conocer sus limitaciones y aceptar que no puede saber todo acerca de SQL Server. La idea no es golpearse la cabeza contra la pared y desperdiciar tiempo preciado cuando hay alguien que puede ayudarlo con su tarea o problema.

Su fuente principal de información acerca de SQL Server son los Libros en línea sobre SQL Server, los cuales puede descargar e instalar de forma local o buscar en línea en MSDN. Los libros en línea sobre SQL Server son excelentes para buscar sintaxis, pero si tiene alguna pregunta más complicada o si intenta solucionar un problema, lo mejor es publicar una pregunta en algún foro en línea. Existen muchos foros sobre SQL Server en MSDN y sitios comunitarios populares como SQL Server Central.

Otra forma rápida de encontrar ayuda es publicar en la comunidad de SQL Server en Twitter. Publique su pregunta con la etiqueta hash #sqlhelp, la cual es supervisada por muchos expertos de SQL (incluido yo).

Asista a una conferencia específica sobre SQL Server, como la Conferencia anual de la comunidad PASS, la bianual SQL Server Connections o la más frecuente SQL Saturdays. Siga algunos de los diversos blogs que tienen los expertos de SQL Server en la comunidad. Puede obtener una buena idea de qué blogs están activos y vale la pena seguir en las clasificaciones de blogs mantenidas por mi colega en MPV Thomas LaRock.

Es posible que se encuentre sobrecargado con trabajo, pero si logra hacer algún esfuerzo adicional para analizar estas sugerencias, debería descubrir que le brindan enormes beneficios. Sus sistemas se ejecutarán sin complicaciones, estará mejor organizado, tendrá más tranquilidad y será un administrador de bases de datos más competente.

Paul Randal

Paul S. Randal es director administrativo de SQLskills.com, director regional de Microsoft y MVP de SQL Server. Trabajó en el equipo de Motor de almacenamiento de SQL Server en Microsoft desde 1999 a 2007. Paul escribió DBCC CHECKDB/reparación para SQL Server 2005 y era responsable del Motor principal de almacenamiento durante el desarrollo de SQL Server 2008. Randal es experto en recuperación ante desastres, alta disponibilidad y mantenimiento de bases de datos, y es moderador habitual en conferencias en todo el mundo. Mantiene un blog en SQLskills.com/blogs/paul y puede encontrarlo en Twitter en Twitter.com/PaulRandal.