Optimización de SQL Server (SQL Server Tuning)

Para poner a punto SQL Server es necesario ajustar la configuración, opciones, y valores de setup
basadas en las observaciones de las características de trabajo del servidor. Típicamente estas
observaciones se hacen durante el periodo de trabajo mas critico de servidor para perfeccionar las
cargas de trabajo más pesadas. Las recomendaciones de afinación siguientes son aquéllas que
generalmente tienen el mayor impacto en el trabajo de Servidor. Sin embargo, la aplicación de estas
recomendaciones puede producir resultados diferentes que dependen del ambiente particular del
Servidor.

Memoria

La memoria de SQL Server esta dividida en dos espacios, el cache de procedimientos, y el cache de
datos. El Servidor SQL distribuye eficazmente la memoria entre el cache de procedimiento y el cache de
datos usando los parámetros de configuración del cache de procedimiento. La distribución de la
memoria restante entre procedimientos y datos, se encarga de mantener los objetos mas usados en sus
respectivos caches de memoria. Por consiguiente, los procedimientos almacenados mayormente usados
deben estar en el cache de procedimientos, mientras que la mayoría de índices y tablas usadas mas
frecuentemente deben estar en el cache de datos.

La mejor manera de determinar cómo es usada la memoria por el Servidor de SQL es ejecutar DBCC
MEMUSAGE. Esta sentencia indica la cantidad de memoria asignada al Servidor de SQL en el comienzo,
los 12 objetos más grandes en el cache de procedimientos, y los 20 objetos más grandes en el cache de
datos. Por consiguiente, las recomendaciones son basadas en el uso de estos datos que determinaran el
tamaño óptimo para los caches.

Optimizando el Cache de Datos

El cache de datos está compuesto de la memoria sobrante del Servidor de SQL una vez que los requisitos
del cache de procedimiento han sido satisfechos. Lo mejor es tener bastante espacio del cache para
contener la mayoría  los índices usados y un porcentaje respetable de las tablas mas accedidas
frecuentemente, reduciendo las entradas/salidas físicas. Usted también puede usar la sentencia DBCC
MEMUSAGE para ver los 20 objetos más grandes del cache de datos y puede determinar un tamaño
considerable para el cache de datos basado en los tamaños de estos objetos. Usted también puede
determinar el tamaño de las tablas e índices accedidas mas frecuentemente aplicando las fórmulas del
tamaño cedidas por Appendix A of Microsoft SQL Server Administrator's Companion. Habiendo
calculado estos tamaños, usted puede elegir asignar bastante memoria al Servidor de SQL y contener la
íntegramente los objetos de las bases de datos en el cache.

Optimizando el Cache de Procedimientos.

Al poner a punto el cache de procedimiento, lo mejor es determinar el tamaño óptimo para contener los
procedimientos almacenados  más activos. En realidad lo que se busca es prevenir las lecturas a
procedimientos almacenados en disco porque esto es muy costoso. Es más, si el cache de procedimiento
es bastante grande , los procedimientos no se descargaran del cache por los nuevos procedimientos
cargados en el. (Recuerde que el Servidor de SQL guardará una copia duplicada de cada procedimiento
que se accede por más de un usuario.) por defecto, el Servidor de SQL distribuye 30 por ciento de
memoria disponible al cache de procedimientos después que el kernel de SQL se ha asignado. La tarea
es determinar si este 30 por ciento es poco, suficiente, o demasiado basado en el tamaño de objetos del
cache de procedimientos. Es importante no disminuir el cache de procedimientos debajo de 5 por
ciento.

Usted puede determinar si el cache de procedimientos es bastante grande ejecutando los

procedimientos almacenados mas frecuentemente usados y ejecutando la sentencia DBCC MEMUSAGE;
esto mostrara los 12 procedimientos almacenados más grandes en el cache de procedimientos. Si usted
tiene más de 12 procedimientos almacenados, puede continuar ejecutando los demás procedimientos y
ejecutar cada vez la sentencia DBCC MEMUSAGE para ver si uno de los procedimientos previamente
ejecutados ha permanecido en el cache. Usted también puede ejecutar cada procedimiento almacenado
y obtener su tamaño de ejecución usando DBCC MEMUSAGE. Después de que usted ha ejecutado todos
los procedimientos que son llamados con mas frecuencia y ha obtenido sus tamaños, sume éstos valores
y obtenga el tamaño total necesario del cache para todos los procedimientos.

TEMPDB en RAM

Las consultas ejecutadas contra el Servidor de SQL que usan espacio de trabajo temporal como las
operaciones, GROUP BY, tablas temporales, uniones de tablas (JOIN), son beneficiadas si la tempdb se
encuentra en RAM. Sin embargo, para poner la tempdb en RAM, usted debe tener mas memoria
disponible que la asignada a Windows NT Server y SQL Server. Por consiguiente, si la tempdb esta
actualmente en 25 MB de tamaño, entonces la memoria total requerida para el sistema es: 16 MB para
el Windows NT más (XX) la memoria para SQL Server mas 25 MB para el tempdb.

Distintas formas de optimizar las consultas realizadas en SQL.

El lenguaje SQL es no procedimental, es decir, en las sentencias se indica que queremos conseguir y no
como lo tiene que hacer el interprete para conseguirlo. Esto es pura teoría, pues en la práctica a todos
los gestores de SQL hay que especificar sus propios truquitos para optimizar el rendimiento.

Por tanto, muchas veces no basta con especificar una sentencia SQL correcta, sino que además, hay que
indicarle como tiene que hacerlo si queremos que el tiempo de respuesta sea el mínimo. En este
apartado veremos como mejorar el tiempo de respuesta de nuestro interprete ante unas determinadas
situaciones:

Diseño de las tablas

 Normaliza las tablas, al menos hasta la tercera forma normal, para asegurar que no hay
duplicidad de datos y se aprovecha al máximo el almacenamiento en las tablas. Si hay que
desnormalizar alguna tabla piensa en la ocupación y en el rendimiento antes de proceder.
 Los primeros campos de cada tabla deben ser aquellos campos requeridos y dentro de los
requeridos primero se definen los de longitud fija y después los de longitud variable.
 Ajusta al máximo el tamaño de los campos para no desperdiciar espacio.
 Es muy habitual dejar un campo de texto para observaciones en las tablas. Si este campo se va
a utilizar con poca frecuencia o si se ha definido con gran tamaño, por si acaso, es mejor crear
una nueva tabla que contenga la clave primaria de la primera y el campo para observaciones.

Gestión y elección de los índices

Los índices son campos elegidos arbitrariamente por el constructor de la base de datos que permiten la
búsqueda a partir de dicho campo a una velocidad notablemente superior. Sin embargo, esta ventaja se
ve contrarrestada por el hecho de ocupar mucha más memoria (el doble más o menos) y de requerir
para su inserción y actualización un tiempo de proceso superior.

Evidentemente, no podemos indexar todos los campos de una tabla extensa ya que doblamos el tamaño
de la base de datos. Igualmente, tampoco sirve de mucho el indexar todos los campos en una tabla
pequeña ya que las selecciones pueden efectuarse rápidamente de todos modos.

Un caso en el que los índices pueden resultar muy útiles es cuando realizamos peticiones simultáneas
sobre varias tablas. En este caso, el proceso de selección puede acelerarse sensiblemente si indexamos
los campos que sirven de nexo entre las dos tablas.

Los índices pueden resultar contraproducentes si los introducimos sobre campos triviales a partir de los
cuales no se realiza ningún tipo de petición ya que, además del problema de memoria ya mencionado,
estamos ralentizando otras tareas de la base de datos como son la edición, inserción y borrado. Es por
ello que vale la pena pensárselo dos veces antes de indexar un campo que no sirve de criterio para
búsquedas o que es usado con muy poca frecuencia por razones de mantenimiento.

Campos a Seleccionar

 En la medida de lo posible hay que evitar que las sentencias SQL estén embebidas dentro del
código de la aplicación. Es mucho más eficaz usar vistas o procedimientos almacenados por que
el gestor los guarda compilados. Si se trata de una sentencia embebida el gestor debe
compilarla antes de ejecutarla.
 Seleccionar exclusivamente aquellos que se necesiten
 No utilizar nunca SELECT * por que el gestor debe leer primero la estructura de la tabla antes
de ejecutar la sentencia
 Si utilizas varias tablas en la consulta especifica siempre a que tabla pertenece cada campo, le
ahorras al gestor el tiempo de localizar a que tabla pertenece el campo. En lugar de SELECT
Nombre, Factura FROM Clientes, Facturacion WHERE IdCliente = IdClienteFacturado, usa:
SELECT Clientes.Nombre, Facturacion.Factura WHERE Clientes.IdCliente =
Facturacion.IdClienteFacturado.

Campos de Filtro

 Se procurará elegir en la cláusula WHERE aquellos campos que formen parte de la clave del
fichero por el cual interrogamos. Además se especificarán en el mismo orden en el que estén
definidos en la clave.
 Interrogar siempre por campos que sean clave.
 Si deseamos interrogar por campos pertenecientes a índices compuestos es mejor utilizar todos
los campos de todos los índices. Supongamos que tenemos un índice formado por el campo
NOMBRE y el campo APELLIDO y otro índice formado por el campo EDAD. La sentencia WHERE
NOMBRE='Juan' AND APELLIDO Like '%' AND EDAD = 20 sería más optima que WHERE NOMBRE
= 'Juan' AND EDAD = 20 por que el gestor, en este segundo caso, no puede usar el primer índice
y ambas sentencias son equivalentes por que la condición APELLIDO Like '%' devolvería todos
los registros.

Orden de las Tablas

Cuando se utilizan varias tablas dentro de la consulta hay que tener cuidado con el orden empleado en
la cláusula FROM. Si deseamos saber cuantos alumnos se matricularon en el año 1996 y escribimos:
FROM Alumnos, Matriculas WHERE Alumno.IdAlumno = Matriculas.IdAlumno AND Matriculas.Año =
1996 el gestor recorrerá todos los alumnos para buscar sus matriculas y devolver las correspondientes.
Si escribimos FROM Matriculas, Alumnos WHERE Matriculas.Año = 1996 AND Matriculas.IdAlumno =
Alumnos.IdAlumnos, el gestor filtra las matrículas y después selecciona los alumnos, de esta forma tiene
que recorrer menos registros.

Preguntas y respuestas acerca de SQL

Errores de E/S, creación de reflejos de la base de datos, etc.

Paul S. Randal

P He empezado a ejecutar comprobaciones de coherencia con regularidad en las bases de datos que
administro e, incluso, he agregado algunas alertas del Agente SQL para localizar los errores de E/S que
 se indican en las consultas de los usuarios. No sé si la lógica que he implementado en las
comprobaciones y las alertas funcionará, ya que mis bases de datos no tienen daños. ¿Cómo puedo
crear daños en una base de datos de prueba para asegurarme de que todo lo que he configurado
funciona correctamente? Además, ¿qué más puedo hacer para detectar los errores de E/S?
R En SQL Server® 2000, el truco para crear una base de datos dañada en la que realizar pruebas
consistía en eliminar manualmente una fila de la tabla sysindexes de una base de datos de prueba.
Pero con SQL Server 2005, dañar una tabla del sistema de esta manera es muy difícil. La mejor manera
de dañar una base de datos de prueba es usar un editor hexadecimal para alterar un archivo de datos
con la base de datos cerrada. Estos son los pasos que debe seguir:

 Cierre la base de datos para que los archivos de datos no estén bloqueados. (Tenga cuidado de
no separar la base de datos porque, si daña la página incorrecta, tal vez no pueda unirla de nuevo).
 Elija una parte del archivo de más de 100 páginas aproximadamente (por lo menos de 819.200
bytes) con intervalos de 8.192 bytes (límite de página). De esta forma puede evitar las páginas de
metadatos importantes y los mapas de bits de asignación, lo que le permite iniciar la base de datos y
ejecutar DBCC CHECKDB en ella.
 Escriba algunos bytes de ceros en la parte elegida del archivo. Al usar esta técnica la
introducción de algunos daños en el encabezado de la página está prácticamente garantizada.

Dicho esto, la forma más rápida de dañar una base de datos de prueba es usar una que ya esté creada.
Puede encontrar ejemplos de bases datos dañadas de SQL Server 2000 y SQL Server 2005 (con
explicaciones) en mi blog (en go.microsoft.com/fwlink/?LinkId=115151).
En cuanto a la segunda pregunta con respecto a lo que se debe hacer para detectar los errores de E/S:
debe habilitar las sumas de comprobación de las páginas. Esta característica se introdujo en SQL Server
2005 para proteger una página entera de la base de datos de los errores introducidos por el subsistema
de E/S.

Básicamente, al escribir una página en el disco, lo último que hace SQL Server es calcular una suma de
comprobación de los 8 KB de la página y marcarla en la página. Al leer una página del disco, si tiene una
suma de comprobación de página, se calculará de nuevo y se comparará con la que se almacena en la
página. Si no coinciden, significa que algún elemento ajeno a SQL Server dañó la página y se produce un
error 824. El error se muestra en la conexión que provocó la lectura de la página, además de registrarse
en el registro de error de SQL Server y en el registro de eventos de aplicación de Windows®.

Las sumas de comprobación de página están activadas de forma predeterminada en todas bases de
datos creadas en SQL Server 2005 y SQL Server 2008. Sin embargo, hay que habilitarlas manualmente en
las bases de datos actualizadas a partir de versiones anteriores de SQL Server. Para habilitar las sumas
de comprobación de página, use este código:

Copiar código

ALTER DATABASE mydb SET PAGE_VERIFY CHECKSUM;

Sugerencia: cambie el puerto predeterminado de SQL Server

De forma predeterminada, el puerto configurado de las instancias de SQL Server es el 1433. Una vez que
una instancia use este puerto, no podrá ocuparlo ninguna otra. Por lo tanto, si instala una segunda
instancia (con nombre) de escucha en la red mediante tcp, necesitará otro puerto. En algunos casos, el
administrador puede cambiar el puerto por razones de ofuscación (aunque esta forma de ofuscación es
secundaria y se puede interrumpir fácilmente mediante un escáner de puerto). Por supuesto, deberá
configurar el cliente para usar un puerto diferente. Existen tres enfoques típicos de hacerlo.

Primero, suponiendo que el administrador cambió el puerto de una instancia a 5555, puede especificar
simplemente el número de puerto de la instancia dentro del nombre del equipo al que desea conectar
mediante la sintaxis MiNombreDeServidor,5555. Si se vuelve a cambiar el puerto, los clientes deberán
cambiar sus connectionStrings de nuevo.

Otra opción es usar alias de SQL Server, que se configuran en el cliente. Además de especificar un
nombre de alias, debe indicar el nombre de servidor, el nombre de puerto y el protocolo. Una vez
configurado, el alias se puede usar como nombre de servidor para conectarse a la instancia de la base de
datos. La ventaja que aporta esta opción es que un administrador de dominio puede implementar los
cambios de configuración del servidor, ya que la configuración se almacena en el registro.

La tercera opción de las instancias con nombre en las que el usuario sólo conoce el nombre de la
instancia y especifica el nombre con la estructura NombreDeEquipo\NombreDeInstancia dentro de
connectionString es usar el servicio Explorador de SQL Server. Esto ya se ha implementado en SQL
Server 2000 como parte de un servicio en ejecución. No obstante, en SQL Server 2005, se creó el servicio
Explorador de SQL Server como servicio independiente. Además del descubrimiento de instancias del
equipo, responde a las solicitudes entrantes del protocolo de datagramas de usuario (UDP) en el puerto
1434 con el número de puerto adecuado para la instancia solicitada, lo que permite la redirección del
cliente y la compatibilidad de una conexión transparente.

—Jens K. Suessmeyer, consultor de bases de datos en Microsoft

P Para eliminar la fragmentación de la base de datos, he configurado un plan de mantenimiento

nocturno que regenera todos los índices de la base de datos de producción que se ejecuta en SQL
Server 2005 Enterprise Edition con SP2. He observado que, de esta forma, la base de datos crece
demasiado, por eso, agregué un paso para reducir el espacio extra, ya que no hay mucho espacio en el
disco. Ahora parece que la regeneración no funciona. ¿Qué pasa?

R Se ha encontrado con un problema al que suelen enfrentarse muchos usuarios cuando intentan
configurar un plan de mantenimiento. Ha entrado en un ciclo de reducción y crecimiento.

Al regenerar un índice, se crea una nueva copia del índice antes de eliminar el índice existente. Este
procedimiento necesita espacio extra en los archivos de la base de datos (generalmente el mismo
espacio que use el índice actual). En SQL Server 2000, también se necesita el espacio extra para ordenar
las filas del índice (aproximadamente un 20 por ciento del tamaño del índice), pero ese requisito se ha
eliminado en la regeneración de un índice sencillo en SQL Server 2005.

A veces, los administradores desean quitar el espacio extra creado durante la regeneración del índice,
por lo que realizan una operación de reducción al plan de mantenimiento después de la regeneración.
Sin embargo, poca gente sabe que esta reducción provocará la fragmentación del índice debido a la
naturaleza de su algoritmo. Esto significa que el índice regenerado y desfragmentado recientemente se
fragmentará de inmediato, lo que anulará el efecto de regeneración en primer lugar.

Ya que el archivo de la base de datos volverá a aumentar la próxima vez que se regenere el índice, es
preferible que la base de datos tenga espacio extra y evitar que se ejecute la reducción. (Además, el
continuo crecimiento y reducción de los archivos de la base de datos causará la fragmentación de los
archivos a nivel de sistema operativo, lo que puede provocar un rendimiento insuficiente al igual que la
fragmentación del índice.

Por último, debería plantearse la posibilidad de reducir la frecuencia con que regenera los índices.
Incluso puede tratar de usar un método alternativo, como el antiguo DBCC INDEXDEFRAG que escribí
para SQL Server 2000 o la nueva sintaxis ALTER INDEX REORGANIZE en SQL Server 2005 y SQL Server
2008.

Hay unas notas técnicas de gran utilidad en las que se trata la fragmentación de índices y ofrece
orientación acerca de cuándo eliminar la fragmentación (en go.microsoft.com/fwlink/?LinkId=115154).
Aunque este texto se escribió para SQL Server 2000, los conceptos son los mismos.
 P Hemos estado evaluando la estrategia de recuperación de desastres en mi organización y creo que
la creación de reflejos de bases de datos es el procedimiento correcto en nuestra situación. El servidor
que intento proteger tiene muchas bases de datos no relacionadas (resultado de un proyecto previo
de consolidación de servidores) y quiero usar la creación de reflejos de bases de datos para todas. Mi
pregunta es la siguiente: ¿cuántas bases de datos se pueden reflejar antes de que se reduzca el
rendimiento?

R La respuesta a esta pregunta es muy típica: depende. Las directrices publicadas aconsejan no
reflejar más de 10 bases de datos por instancia, pero depende de cada usuario. Hay que tener en
cuenta los siguientes factores para la instalación del hardware:

 ¿De cuánta memoria disponen las instancias principal y reflejada? (Lo idea sería que dispongan
de la misma.)
 ¿Cuánta capacidad de procesamiento tienen las instancias principal y reflejada? (También
debería ser la misma.)
 ¿Cuánto ancho de banda tiene el subsistema de E/S de la instancia reflejada? (Debería tener
tanto como el de la principal.)
 ¿Cuántos registros de transacciones genera la carga de trabajo en cada base de datos?
 ¿Cuánto ancho de banda de red está disponible entre las instancias principal y la reflejada?

Los últimos dos factores son los más importantes. Si el ancho de banda de red disponible entre las dos
instancias no es suficiente para encargarse la velocidad de generación de registros de transacciones
combinados por segundo de todas las bases de datos reflejadas, el rendimiento disminuirá en las bases
de datos principales. SQL Server 2008 ayuda a mejorar una parte de esta carga mediante la compresión
de secuencias de registro.
El siguiente aspecto más importante a tener en cuenta en la creación de reflejos es la memoria y los
requisitos de los subprocesos. Todas las bases de datos reflejadas ocupan un subproceso además de
memoria. Si un servidor de baja potencia tiene una muchas bases de datos reflejadas, esto puede
suponer una carga excesiva para el servidor al combinarlas con la carga de trabajo habitual.

Además, debe tener en cuenta cómo llevará a cabo la creación de reflejos de bases de datos. En el modo
sincrónico, las transacciones de la base de datos principal no se pueden confirmar hasta que todos los
registros de transacciones se hayan copiado en el registro de transacciones de la base de datos
reflejada. Por lo tanto, cualquier retraso causado por una red sobrecargada podría provocar un
problema de rendimiento de la carga de trabajo de la principal.

En el modo asincrónico, las transacciones se pueden confirmar en la principal sin tener que esperar,
aunque un retraso de la red podría aumentar el número de registros de transacciones en espera de
envío. Esto puede causar problemas relacionados con el tamaño del registro de transacciones. O, lo que
es peor, los registros de transacciones que no se hayan enviado se perderán en caso de error. Por lo
tanto, cuantos más registros de transacciones queden sin enviar, mayor será la probabilidad de perder
datos en una situación de recuperación.

Las situaciones pueden ser muy diferentes y he detectado algunos ejemplos interesantes en entornos de
producción reales. Por ejemplo, advertí un entorno con 150 bases de datos con una actividad muy
pequeña y sin sincronización. Las 150 bases de datos se reflejaron sin problemas.

Por el contrario, también pude ver una configuración que solamente tenía tres bases de datos muy
cargadas sin una conexión de red buena. En esa situación, apenas se pudo reflejar una base de datos
antes de que la falta de ancho de banda de la red degradara la carga de trabajo.

La clave del éxito es, en primer lugar, realizar el cálculo de generación de registros. Si parece que el
ancho de banda de red disponible puede ser compatible con el número de las bases de datos que desea
reflejar, no debería haber ningún problema. Pruebe su configuración antes de ponerlo en ejecución y
asegúrese de incluir todas operaciones que podrían generar un registro de transacciones (especialmente
todo el mantenimiento de bases de datos que pueda realizar).
Paul S. Randal es el director general de SQLskills.com y uno de los profesionales más valorados (MVP)
de SQL Server. Trabajó en el equipo del motor de almacenamiento de SQL Server de Microsoft de 1999 a
2007. Paul escribió las directrices de reparación de DBCC CHECKDB para SQL Server 2005 y fue
responsable del motor de almacenamiento del núcleo durante el desarrollo de SQL Server 2008. Es
experto en recuperación de desastres, en alta disponibilidad y en el mantenimiento de bases de datos,
además de moderador habitual en congresos. Además, es autor de un blog: SQLskills.com/blogs/paul.

© 2008 Microsoft Corporation and CMP Media, LLC. Reservados todos los derechos. Queda prohibida la
reproducción parcial o total sin previa autorización.