Material Administracion de Bases de Datos

Administración de Bases de Datos
Contenido
Tema I – Resolución de Problemas de Rendimiento en SQL Server .................. 3
Diagnostique los problemas ........................................................................................ 4
Causas comunes de problemas de desempeño ...................................................... 5
Qué métricas monitorear ............................................................................................. 5
Ajuste del rendimiento de la base de datos de SQL Server ................................. 9
Cómo hacer ajuste de rendimiento en SQL Server ................................................ 9
1. Medir el rendimiento del servidor SQL .............................................................. 10
2. Cómo optimizar consultas SQL ............................................................................ 10
3. Cómo hacer la optimización del rendimiento del índice ............................... 11
4. Ajustes de Performance Tune SQL Server ......................................................... 12
5. Ajuste el rendimiento del hardware ................................................................... 13
6. Construcción y prueba de carga de nuevos servidores SQL ......................... 13
SQL Server Profiler ....................................................................................................... 14
Monitor de rendimiento de Windows .................................................................... 16
El monitor de actividad de SQL Server ................................................................... 18
Recopilador de datos del SQL Server ...................................................................... 19
Vistas de administración dinámica (DMV) ............................................................. 21
Los eventos extendidos de SQL Server ................................................................... 22
Tema II - Diez consejos para la optimización del rendimiento de SQL Server
.......................................................................................................................................... 25
Consejo n.º 10. La metodología “Línea de base y evaluación comparativa”
le permite detectar problemas. ................................................................................ 25
Consejo n.º 9. Los contadores de rendimiento le proporcionan información
rápida y útil sobre las operaciones que actualmente están en ejecución. ..... 31
Consejo n.º 8. La modificación de la configuración del servidor puede
proporcionar un entorno más estable. ................................................................... 33
Consejo n.º 7. Encuentre instrucciones no autorizadas en la caché de plan . 35
Consejo n.º 6. SQL Profiler es su amigo.................................................................. 37
Consejo n.º 5. Configure SAN para el rendimiento de SQL Server. ................. 39
Ing. Rusbel Alcántara Rodríguez

Consejo n.º 4. Los cursores y otros T-SQL malos suelen volver para
atormentar a las aplicaciones. .................................................................................. 42
Consejo n.º 3. Maximice la reutilización del plan para una mejor caché de
SQL Server ...................................................................................................................... 44
Consejo n.º 2. Aprenda cómo leer la caché de búfer de SQL Server
y minimizar la hiperpaginación de caché............................................................... 47
Consejo n.º 1. Comprender cómo se utilizan los índices y encontrar índices
malos. .............................................................................................................................. 49
Tema III - Auditoria en SQL Server .......................................................................... 52
Creando una estrategia de auditoría exitosa para sus bases de datos SQL
Server .............................................................................................................................. 52
La importancia de la auditoría .................................................................................. 52
Estrategia de auditoría................................................................................................ 53
Qué auditar .................................................................................................................... 53
Auditando su implementación de auditoría.......................................................... 55
Auditoría selectiva ....................................................................................................... 55
Archivando información de auditoría ..................................................................... 56
Características de SQL Server disponibles para facilitar la auditoría de
seguridad........................................................................................................................ 56
Auditoría C2................................................................................................................... 56
Compatibilidad con Criterio Común........................................................................ 58
SQL Server Auditing .................................................................................................... 61
Seguimiento de SQL .................................................................................................... 62
Eventos Extendidos ...................................................................................................... 63
Captura de Datos Modificados ................................................................................. 65
| ......................................................................................................................................... 66
. Tema IV – SQL Server Tunning Advisor ................................................................ 67

Tema I – Resolución de Problemas de
Rendimiento en SQL Server
Monitorear el desempeño de SQL Server es una tarea compleja, ya que el
desempeño depende de muchos parámetros de hardware y software. Es
recomendado monitorear estos parámetros proactivamente para prevenir
cualquier degradación potencial del desempeño. De todos modos, este no
siempre es el caso. Si la degradación de desempeño ocurre, el primer paso hacia
la resolución es determinar el problema, encontrar la causa y resolver el
problema.
Los problemas severos de desempeño requieren acciones y resoluciones

rápidas. Problemas menos severos pueden tener una solución diferida. En
cualquier caso, los Administradores de Bases de Datos (DBAs) deberían tomar
acciones para prevenir estas situaciones en el futuro.
Eso no significa que cada ralentización de SQL Server es un problema de

desempeño. Algunas acciones específicas requieren muchos recursos y ponen
estrés en el servidor. Si estas acciones son ocasionales, no deberían ser
consideradas como una amenaza seria y pueden ser ignoradas. Correr su SQL
Server bajo estrés todo el tiempo debería ser analizado detalladamente. Es
bueno saber cómo se comporta el sistema cuando no hay problemas de
desempeño. Esto se puede obtener recolectando información de base acerca
del recurso que se está usando.
Para saber qué está pasando con su SQL Server, inicie con el monitoreo de bases
de datos, mire las métricas de desempeño durante el tiempo para crear líneas
de base y tendencias para la operación normal, aísle el proceso que está usando
muchos recursos. Luego usted podrá depurar y reparar los errores.

Diagnostique los problemas
Para iniciar la resolución de problemas, usted tiene que definir los síntomas
primero. Los síntomas más comunes de fallas en el desempeño de SQL Server
son CPU, memoria, red y cuellos de botella I/O, y consultas lentas.
Los cuellos de botella de CPU son causados por recursos de hardware

insuficientes. La resolución de problemas comienza identificando a los usuarios
de recursos de CPU más grandes. Picos ocasionales en el uso del procesador
pueden ser ignorados, pero si el procesador está contantemente bajo presión,
una investigación es necesaria. Añadir procesadores adicionales o usar uno más
poderoso puede no solucionar el problema, ya que procesadores mal diseñados
pueden usar todo el tiempo de CPU. La mejora de las consultas, el
mejoramiento de los planes de ejecución y la reconfiguración del sistema
pueden ayudar. Para evitar cuellos de botella, es recomendado tener un
servidor dedicado que sólo correrá SQL Server y remover todo el otro software
a otra máquina.
Los cuellos de botella de memoria pueden resultar en un tiempo de respuesta

largo para la aplicación, una ralentización general del sistema o incluso el
colapso de la aplicación. Es recomendado identificar cuando el sistema corre
con memoria insuficiente, qué aplicaciones usan la mayor parte de los recursos
de memoria, o si hay cuellos de botella para otros recursos del sistema. Revisar
y afinar consultas, reconfiguración de la memoria, y añadir más memoria física
puede ayudar.
Los cuellos de botella de red pueden no ser reconocidos inmediatamente, ya

que a primera vista pueden ser considerados como problemas de desempeño
de SQL causados por otros recursos. Por ejemplo, una demora de datos
enviados por la red puede parecer una respuesta lenta de SQL Server.
Los cuellos de botella I/O son causados por lecturas y escrituras excesivas de
páginas de la base de datos al disco. Un cuello de botella es manifestado a
través de tiempos de respuesta largos, ralentizaciones de la aplicación y
expiración de tareas. Si otras aplicaciones usan recursos de disco
excesivamente, puede que SQL Server no tenga suficientes recursos de disco
para su operación normal y tendría que esperar para poder leer y escribir al
disco.

Las consultas lentas pueden ser el resultado de índices perdidos, planes pobres
de ejecución, mal diseño de aplicación y esquema, etc.
Causas comunes de problemas de desempeño

Las causas para los problemas de desempeño pueden ser varias, pero las más
comunes son una base de datos pobremente diseñada, un sistema
incorrectamente configurado, espacio de disco insuficiente u otros recursos de
sistema, compilación y recompilación de consultas excesivas, y consultas o
procedimientos almacenados que tienen tiempos de ejecución largos debido a
un diseño inapropiado.
Los cuellos de botella de memoria son causados por limitaciones en la memoria

disponible y la presión de memoria causada por SQL Server, el sistema u otra
actividad de aplicación. Un indexado pobre requiere escaneos de tabla, lo cual,
en tablas grandes, significa que un gran número de filas es leído desde el disco
y manejado en memoria.
Los cuellos de botella de red son causados por una sobrecarga en un servidor o
la red, de modo que los datos no pueden fluir como se espera.
Los problemas de I/O pueden ser causados por hardware lento, mal diseño de
soluciones de almacenamiento, y la configuración. Aparte de los componentes
de hardware, como tipos de discos, tipos de arreglos de discos, y
configuraciones RAID que afectan el desempeño I/O, solicitudes innecesarias
hechas por la base de datos también afectan al tráfico I/O. Escaneos frecuentes
de índices, consultas ineficientes y estadísticas desactualizadas también
pueden causar sobrecargas I/O y cuellos de botella.
Qué métricas monitorear

Para comenzar a solucionar los problemas de desempeño más comunes de
CPU, monitoree % Processor Time. Este contador está disponible
en Performance Monitor. Si su valor es constantemente más alto que 80%, el
procesador está bajo presión.
Los contadores que indican las causas más comunes para la presión al
procesador son Batch Requests/sec, SQL Compilations/sec y SQL

Recompilations/sec. Estos contadores están disponibles en Performance
Monitor y en la vista sys.dm_os_performance_counters.
select * from sys.dm_os_performance_counters
where counter_name in ('Batch Requests/sec', 'SQL Compilations/sec' , 'SQL

Re-Compilations/sec')
Note que el tipo de contador para los tres contadores es 272696576 y que los
valores mostrados son acumulativos desde el último inicio de SQL Server, así
que tienen que ser calculados. Uno de los métodos es tomar dos muestras con
una demora de 10 segundos.
DECLARE @BatchRequests BIGINT;
SELECT @BatchRequests = cntr_value FROM

sys.dm_os_performance_counters WHERE counter_name =
'Batch Requests/sec';
WAITFOR DELAY '00:00:10';
SELECT (cntr_value - @BatchRequests) / 10 AS 'Batch

Requests/sec' FROM sys.dm_os_performance_counters WHERE
counter_name = 'Batch Requests/sec';
El valor de Batch Requests/sec depende del hardware usado, pero debería estar
debajo de 1000. El valor recomendado para SQL Compilations/sec es menos
que 10% de Batch Requests/sec y para SQL Re-Compilations/sec es menos que
10% de SQL Compilations/sec.
Para problemas de memoria, monitoree el contador de desempeño Memory

Available KB. Los valores normales deberían estar encima de 200 MB. Si el valor
del contador Memory Available KB es menos que 100MB por un largo tiempo,

es una indicación clara de insuficiente memoria en el servidor. Este contador
está disponible en Performance Monitor, y dos contadores adicionales y útiles
– Total Server Memory (KB) y Target Server Memory (KB) están disponibles vía
la vista sys.dm_os_performance_counters.
Otro contador a monitorear es Pages/sec, está disponible en Performance

Monitor. Muestra el ritmo al cual las páginas son escritas desde el disco a la
memoria RAM y leídas desde la RAM al disco. Los valores mayores a 50
muestran actividad intensiva de la memoria y posibles sobrecargas y presión de
memoria que puede llevar a la degradación del desempeño de SQL Server.
Checkpoint pages/sec y Lazy writes/sec indicant si páginas sucias son enviadas

al disco muy frecuentemente. Las páginas sucias son automáticamente
enviadas al disco en un punto de control. Si el espacio libre disponible en el
caché del búfer entre dos puntos de control es poco, una escritura física
ocurrirá para limpiar las páginas del búfer al disco y liberar la memoria. El valor
de lazy Writes/sec debería estar debajo de 20. Ambos contadores están
disponibles en Performance Monitor y la
vista sys.dm_os_performance_counters, pero como el tipo del contador es
272696576, los valores retornados por la vista deberían ser calculados.
Si el valor de Lazy Writes/sec está constantemente encima del umbral, revise el

valor de Page Life Expectancy. Los valores debajo de 300 segundos indican
presión a la memoria. El contador está disponible en Performance Monitor y la
vista sys.dm_os_performance_counters, no se necesita hacer cálculos
adicionales.
Buffer Cache Hit Ratio muestra la proporción de páginas de datos encontradas

y leídas desde la caché del búfer de SQL Server y todas las solicitudes de páginas
de datos. Si una página no existe en la caché del búfer, tiene que ser leída en el
disco, lo cual degrada el desempeño. El valor recomendado está encima de 90.
El contador está disponible en Performance Monitor y la
vista sys.dm_os_performance_counters.
Ya que el tipo del contador es 537003264, el valor retornado por la vista tiene
que ser calculado para obtener el valor actual. Para hacer eso, es necesario usar
también el valor de Buffer Cache Hit Ratio Base.

Buffer Cache Hit Ratio % = 100 * Buffer Cache Hit Ratio / Buffer Cache Hit Ratio
Base
= 100 * 1,797 / 1,975 = 90.98%
La resolución de problemas de red debería comenzar encontrando consultas,

funciones y procedimientos almacenados que tiene un tiempo lento de
respuesta. Si son ejecutados rápidamente, pero con una gran demora entre las
dos llamadas, puede ser una indicación de un problema de red. SQL Server
Profiler puede ser usado para determinar qué consultas, funciones y
procedimientos almacenados fueron ejecutados.
Para problemas de I/O, monitoree los contadores relacionados con el

disco: Average Disk Queue Length, Average Disk Sec/Read, Average Disk
Sec/Write, %Disk Time, Average Disk Reads/Sec, y Average Disk Writes/Sec.
Todos los contadores están disponibles en Performance Monitor.
Average Disk Queue Length muestra el número promedio de operaciones I/O

que están esperando a ser escritas a o leídas desde el disco y el número de
escrituras y lecturas procesadas actualmente. El valor recomendado es debajo
de 2 por disco individual, y valores más altos indican cuellos de botella de I/O.
Average Disk Sec/Read muestra el tiempo promedio en segundos necesarios

para leer los datos del disco. Los valores recomendados están dados por
categorías, donde debajo de 8 milisegundos es un desempeño excelente, y más
de 20 milisegundos es un problema serio de I/O.
Average Disk Sec/Write muestra el tiempo promedio en segundos necesario

para escribir datos al disco. El desempeño es excelente si el valor está debajo
de 1 milisegundo y malo si el valor del contador es más alto que 4 milisegundos.
Average Disk Reads/Sec y Average Disk Writes/Sec muestran el ritmo de

operaciones de lectura y escritura en el disco, respectivamente. Los valores
bajos indican un procesamiento I/O del disco lento, y se recomienda revisar el
uso del procesador y las consultas que usan mucho disco. Los valores normales
dependen de la especificación del disco y la configuración del servidor. Estos
contadores no tienen un umbral específico, así que es recomendado

monitorear estas métricas durante un tiempo y determinar las tendencias y
establecer una línea base.
El desempeño de SQL Server puede ser afectado por muchos factores. Cuando
se está resolviendo problemas, es necesario saber dónde empezar, para saber
los valores normales para los contadores de desempeño y para seleccionar una
herramienta que proveerá suficiente información para analizar y solucionar los
problemas.
Ajuste del rendimiento de la base de datos de

SQL Server
Cómo hacer ajuste de rendimiento en SQL

Server
Usted es un desarrollador, DBA o administrador de sistemas atascado con las

consultas de larga ejecución en SQL Server, y necesita realizar el ajuste de
rendimiento de SQL Server. Le enseñaremos la optimización de SQL en una
serie de tutoriales sencillos y gratuitos:
 Mida qué tan rápido va el servidor ahora.

 Rendimiento afinar las consultas.
 Rendimiento afinar los índices.
 Ajuste de rendimiento de la configuración de SQL Server.
 El rendimiento afina el hardware.
Finalmente, si tiene que comprar nuevos servidores, obtenga una lista de

verificación de configuración de mejores prácticas y haga una prueba de carga
antes de ponerlo en funcionamiento.

Vamos a entrar en los detalles de cada paso.
1. Medir el rendimiento del servidor

SQL
Cuando los usuarios se acercan a usted y le dicen que sus consultas son lentas,
no quiere simplemente tomar su palabra: quiere saber exactamente qué
consultas son lentas y por qué. Vamos a empezar por
 sp_BlitzFirst® : esta herramienta gratuita es como el velocímetro de SQL

Server. Le muestra qué tan rápido va SQL Server y qué tipos de espera le
impiden ir más rápido.
 Tutorial de SQL Server Perfmon : cómo configurar Perfmon, qué
contadores de SQL Server Perfmon rastrear y qué significan los
indicadores.
 Mire los servidores Brent Tune : en Microsoft Ignite 2015, tomó varias
cargas de trabajo de SQL Server, encontró el cuello de botella y luego
modificó varias configuraciones para soluciones rápidas.
Luego, antes de comenzar a cambiar las cosas, pregunte qué partes del servidor
puede cambiar. La Guía del administrador para la optimización de SQL Server le
brinda una lista de verificación simple de las partes que puede modificar,
cambiar o reemplazar por completo.
2. Cómo optimizar consultas SQL

Si tiene una aplicación interna y puede realizar la optimización de consultas,
aquí hay algunas maneras de encontrar las consultas de larga ejecución en SQL
Server, y luego cómo aumentar su rendimiento. Primero, debemos encontrar
qué consultas optimizar, y aquí están las herramientas de ajuste de rendimiento
de consultas que utilizo:
 Para encontrar sus consultas generales de larga duración, use el script

gratuito sp_BlitzCache . No tiene que instalar nada antes de tiempo, y
funciona en todas las versiones compatibles de SQL Server a partir de
2008. (Incluso funciona en la nube.)

 Para encontrar consultas de larga ejecución en este momento,
ejecute sp_BlitzWho . Muestra las consultas desde la más larga hasta la
más corta, y le brinda sus planes de ejecución.
Notarás que no dije que capturar las consultas de ejecución lenta con el
Analizador de SQL. El generador de perfiles no es un buen monitor de
rendimiento de SQL Server: en realidad hace que todas las consultas se
ejecuten más lentamente. Está mucho mejor usando el caché del plan como se
muestra arriba.
Una vez que haya encontrado las costosas consultas de SQL que necesita afinar,
estos son mis consejos de ajuste de rendimiento favoritos:
 Vea las consultas de Brent Tune : ¿se ha preguntado alguna vez cómo lo
hace alguien más? Mira por encima del hombro de Brent en este tutorial
gratuito de SQL Server.
 7 cosas que los desarrolladores deben saber sobre SQL , incluido el
motivo por el cual las funciones rara vez funcionan bien, por qué WITH
NOLOCK no significa que no haya bloqueo y más.
 Cómo medir las mejoras de rendimiento : Kendra explica cómo usar las
estadísticas de SSMS.
 Cómo leer los planes de ejecución de consultas y ajustarlos para que sean
más rápidos.
3. Cómo hacer la optimización del

rendimiento del índice
Si no se le permite optimizar las consultas SQL, pero aún necesita acelerarlas,
es posible que deba diseñar índices no agrupados e índices de cobertura. Esto
puede aumentar el rendimiento de una consulta SQL si desea hacer que las
estructuras de la base de datos sean más eficientes para que SQL Server
funcione menos, aquí están nuestros recursos:
 sp_BlitzIndex® : ejecútelo en su base de datos para obtener una prueba

de validez gratuita. Muestra los índices faltantes, los índices no utilizados,

los duplicados, los montones y más, y explica por qué están matando su
rendimiento.
 Recursos de indexación : nuestras publicaciones de blog y videos
favoritos sobre los índices de ajuste.
 Recomendaciones de libros de SQL Server : bueno, los libros no son
gratuitos, pero nuestras recomendaciones sí lo son. Seleccionamos los
mejores libros de ajuste para principiantes, avanzados y de rendimiento.
 Particionamiento de tablas : esta característica parece ser una excelente
manera de dividir mesas grandes, pero viene con algunos errores
importantes.
 Cómo ajustar los índices y hacer que las consultas de SQL Server sean
más rápidas.
4. Ajustes de Performance Tune SQL

Server
Sorprendentemente, muchas de las configuraciones predeterminadas de SQL
Server pueden llevar a un mal rendimiento. Vamos a hablar de lo que necesita
hacer:
 Ejecute sp_Blitz® en el servidor. Es un chequeo de salud gratuito que

detecta muchos cuellos de botella comunes en el rendimiento.
 Consulte nuestra Lista de verificación de la instalación de SQL Server :
algunos ajustes de configuración simples pueden hacer que aumente de
20 a 30% el rendimiento desde el principio sin gastar dinero extra.
 Revise la Lista de verificación de rendimiento deficiente : las 5 cosas de
Jeremiah que corrigen el rendimiento deficiente de SQL Server.
 Guía de Sysadmin para la memoria de SQL Server : ¿por qué no utiliza
sqlserver.exe mucha memoria? ¿Cómo puedes saber si necesita más?

5. Ajuste el rendimiento del hardware
A veces, lanzar hardware es la solución más rápida, fácil y barata.
 ¿Cuál es el servidor SQL más pequeño que debe construir? - Brent explica
por qué la memoria RAM de 96GB no es tan grande, especialmente
cuando lo comparas con los costos de licencias de SQL Server.
 Resultados de las pruebas de carga RAID de SSD: ¿Exactamente qué tan
rápido son las unidades SSD de consumo listas para usar, especialmente
cuando las coloca detrás de un controlador RAID?
 Almacenamiento compartido para SQL Server: hacemos muchos ajustes
de SAN y reunimos nuestros recursos favoritos.
 Prácticas recomendadas de virtualización: configuración de licencias,
capacidad de recuperación y rendimiento.
 Virtualización, SAN y hardware para SQL Server: una clase en línea de 7
horas que enseña cómo configurar y ajustarlos.
6. Construcción y prueba de carga de

nuevos servidores SQL
Cuando esté planeando el tamaño de un servidor para construir, comience con
el video de Brent de Microsoft TechEd 2012, Construyendo los servidores SQL
más rápidos. Explica los dos patrones de acceso comunes para las bases de
datos (OLTP y almacenamiento de datos) y le brinda recursos sobre qué
hardware elegir para cada uno.
Para los almacenes de datos, vaya a la página de inicio de Microsoft Fast Track ,
pero ANTES DE HACER CLIC, esta página tiene muchas cosas de mercadeo y
necesita saber lo que está buscando. Centrarse en las configuraciones de
referencia y guías de configuración. Hay algunos proveedores neutrales de
Microsoft, y luego hay guías específicas para proveedores de Dell, HP, IBM, etc.
Es posible que tenga que desplazarse hasta el final para ver las cosas específicas
del proveedor.
Una vez que se construye el servidor, aquí están nuestros recursos favoritos
para las pruebas de carga y la configuración:

 ¿Qué tan rápido es su almacenamiento? - Le muestro cómo usar la
herramienta gratuita CrystalDiskMark para realizar una prueba de carga
rápida en unidades de estado sólido y SAN.
 Cómo probar el rendimiento de SAN con SQLIO : SQLIO es
probablemente la herramienta con el peor nombre de la historia: no
tiene nada que ver con las bases de datos. Sin embargo, sigue siendo muy
útil para probar cuellos de botella.
SQL Server Profiler
El SQL Server Profiler es una herramienta de monitoreo que se puede utilizar

para poder crear y administrar seguimientos de SQL Server para poder
supervisar la actividad en las instancias de SQL Server. Estos archivos de rastreo
pueden ser analizados y reproducirse luego. El Profiler posee una interfaz
gráfica, que hace que sea más sencillo usarlo.
Además de las acciones para la auditoría que se producen en una instancia de

SQL Server, es útil para poder resolver problemas de rendimiento de SQL
Server, de tal forma que se pueda realizar un seguimiento del procedimiento
almacenado y también la ejecución de consultas mostrando los que ralentizan,
captar las instrucciones y los eventos que causaron la degradación del
rendimiento, que pueda reproducir un conjunto específico de eventos en otro
entorno para fines de prueba, etc.
Para iniciar el analizador del SQL Server:
1. Abrir: Inicio, todos los programas (Windows + C para Windows 8)

2. Seleccione el programa SQL Server Profiler
3. Abra SQL Server Management Studio

4. En el menú de herramientas, seleccione el SQL Server Profiler
5. Abra el símbolo del sistema

6. Escriba profiler
7. Presione Enter
Ahora, usted debe crear los rastros que recopilarán la información que necesita
para monitorear y poder resolver los problemas en el funcionamiento del SQL
Server
Para crear un nuevo rastreo:
1. En el SQL Server Profiler, abra archivo en el menú

2. Seleccione nuevo rastreo
3. Seleccione una instancia de SQL Server, modo de autenticación y
proporcione las credenciales
4. En la pestaña de selección de eventos haga clic en Mostrar todos los
eventos (Show all events)
5. Seleccione todos los eventos y las columnas de evento que desea
rastrear
6. Para poder capturar la información sobre eventos que son producidos en
una base de datos, por ejemplo, los archivos de datos y de registro crecen
de manera automática y los eventos de reducción automática, seleccione
estos tipos de eventos en el tipo de evento de base de datos

Para poder rastrear varios errores, como el límite de CPU excedido, seleccione
el siguiente evento en el tipo de Errores y Advertencias EVENT
1. En la pestaña General seleccione si es que desea guardar la traza en un

archivo o en una tabla
2. Haga clic en el botón Ejecutar (Run)
Se capturarán todos los eventos pertenecientes a los tipos de eventos que se

han seleccionado para realizar el seguimiento.
Aunque el SQL Server Profiler proporciona bastante información muy útil,

algunos Administradores de bases de datos evitan su uso en un servidor de
producción, debido a que puede agregar una sobrecarga significativa. Además,
si no se ha configurado la propiedad para realizar la colección de seguimiento
de SQL Server para recopilar solo la información que realmente necesita para
el análisis, existirá una gran cantidad de datos recopilados que puede que sean
difíciles de analizar.
Monitor de rendimiento de Windows

El Monitor de Rendimiento de Windows es una herramienta de monitoreo que
viene con el sistema operativo Windows. Permite realizar el seguimiento de
varios contadores de rendimiento y supervisa el desempeño general del
sistema y la aplicación. Los valores de los contadores se muestran en gráficos
en tiempo real y se pueden ser guardados en archivos de registro y utilizar para
su análisis posterior.

El Monitor de rendimiento de Windows ofrece una gran variedad de
contadores. El monitorear demasiados contadores afectará el rendimiento del
sistema y hará difícil el análisis, por lo cual es necesario determinar primero los
objetivos del monitoreo y luego escoger los valores de los contadores para
poder monitorear. Un grupo de valores máximos bien seleccionado provee la
suficiente información para conclusiones útiles, el diagnóstico rápido y
encontrar la razón del problema, por lo tanto, es una solución eficiente de los
problemas. La captura de muestras de valores de contadores colectados
demasiado pequeños o incorrectos no proporcionará suficiente información
para conclusiones útiles, podría ser engañosa e inducir conclusiones erróneas.
Cuando se trata de seleccionar los contadores, es necesario comprender qué

representan, cuáles son los valores aceptables, si existe un umbral o el valor
determinado en función de una línea de tendencia.
Para abrir el Monitor de rendimiento de Windows:
1. Abra el menú de Inicio, Ejecutar (Windows + R para Windows 8),

escriba perfmon, y presione Enter
2. Abra el Panel de control, Sistema y seguridad, Herramientas
administrativas y haga clic en Monitor de rendimiento
Para añadir un tope:
1. Seleccione Agregar contador en el menú contextual, o haga clic en el

icono Agregar en el menú
2. Seleccione la computadora que desea monitorear
3. 3. En la lista de contadores disponibles, seleccione el grupo de topes, por
ejemplo MSSQL$2012:Buffer Manager y luego Lazy writes/sec

El monitor de rendimiento de Windows mostrará información útil en gráficos

completos que se almacenan en tiempo real y se puede guardar los datos
históricos durante mucho tiempo, los cuales se pueden usar para análisis
posteriores. Sus desventajas son las que no puede brindar información
suficiente para poder realizar un análisis profundo ni mostrar una línea de
tendencia o un umbral en el gráfico.
El monitor de actividad de SQL Server

El monitor de actividad que incluye SQL Server es una característica que está
disponible en SQL Server Management Studio, útil para monitorear la actividad
de forma rápida y básica de SQL Server. Solo muestra información sobre los
procesos de SQL Server como su efecto en el rendimiento de SQL Server.
Muestra el % de tiempo del procesador, tareas que están en espera, I/O

(entradas y salidas) de base de datos y solicitudes por grupos/seg en el
panel Información general; la lista de procesos que actualmente están en
ejecución en la base de datos SQL en el panel Procesos; la información sobre

tiempo de espera de recursos en el panel espera de recursos; una lista de todas
las bases de datos en la instancia de SQL Server junto con la información sobre
los archivos de base de datos, sus rutas de acceso y los nombres en el panel
de archivo de datos I/O y la lista de consultas ejecutadas recientemente que
utilizan la mayoría de los recursos de memoria, disco y red en el panel
de consultas costosas recientes.
Para iniciar el monitor de actividad, haga clic con el botón derecho del ratón en
la instancia de SQL Server en el explorador de objetos y seleccione monitor de
actividad
El monitor de actividad no está hecho para mostrar datos para una

investigación en profundidad, almacenar registros históricos para análisis
posteriores, ni es posible supervisar parámetros adicionales.
Recopilador de datos del SQL Server

El Recopilador de datos del SQL Server es otra característica incluida dentro de
SQL Server Management Studio que se puede usar para la supervisión del
rendimiento de SQL Server y la solución de problemas. Está disponible en SQL
Server 2008 y versiones posteriores. El Recolector de datos puede recopilar
métricas de rendimiento de varias instancias del SQL Server y almacenarlas en
un repositorio único. Los datos son recopilados en función de la especificación

utilizada. Existen tres especificaciones integradas que brindan la recopilación
automática de las métricas de rendimiento que son más comunes: uso del
disco, estadísticas de consulta y actividad del servidor. Es posible crear
especificaciones de recopilador de datos personalizados, pero requiere
codificación. La recopilación de datos se puede realizar solamente si el SQL
Server se está ejecutando y el Administrador de datos de Almacenamiento de
datos está configurado.
Para abrir los informes de recopilación de datos
1. En el explorador de objetos de SQL Server Management Studio, expandir

la administración
2. Haga clic con el botón derecho en la opción de recopilación de datos y
seleccione informes
3. Seleccione cualquiera de los informes disponibles: historial de actividad
del servidor,
Historial de estadísticas de consulta
Resumen de uso de disco

Vistas de administración dinámica (DMV)

Además de las utilidades para la supervisión disponibles en Windows y SQL
Server Management Studio, las vistas de administración dinámica (DMV)
también pueden ser utilizadas para poder supervisar el rendimiento de SQL
Server y solucionar problemas. Estas vistas son: sys. DM _ exec_sessions, sys.
DM _ os_performance_counters, sys. DM _ os_memory_brokers, sys. DM _
os_memory_nodes, sys. DM _ exec_procedure_stats, sys. _ dm_os_sys_info,
sys. DM _ exec_requests, sys. DM _ exec_requests, y muchas otras más.

Presentaremos solamente algunas vistas de uso común para la supervisión del
rendimiento de SQL Server:
sys.dm_exec_sessions – devuelve una fila para cada sesión que se realiza en la

instancia de SQL Server consultada, junto con detalles como ser el nombre del
programa que inició la sesión, el estado de la sesión, el inicio de sesión de SQL
Server, varios contadores de tiempo y otros datos relacionados.
sys.dm_exec_requests – devuelve una fila para cada usuario y la solicitud del

sistema que se ejecuta en la instancia de SQL Server. Para encontrar las
solicitudes bloqueadas, busque las solicitudes en las que la situación del valor
de la columna de estado sea “suspendido”.
sys.dm_exec_query_stats – devuelve una fila para cada instrucción de consulta

en un plan de consulta que está almacenado en caché. Brinda también
información sobre el tiempo de procesador promedio, mínimo, máximo y total
del tiempo que ha sido utilizado por el plan, junto con otra información útil para
realizar el análisis de rendimiento.
sys.dm_os_performance_counters – devuelve una fila por cada contador de

rendimiento de SQL Server. Proporciona una manera rápida de averiguar los
valores actuales de contadores de rendimiento. No obstante, existen cinco
tipos de contadores y para asegurarse de que está interpretando
correctamente los valores devueltos, debe saber cómo calcular un valor para
cada tipo de contador. Es más fácil con el tipo de contador 65792, ya que no es
necesario ningún cálculo. Los tipos de contadores 1073874176, 537003264, y
272696576 requieren el cálculo adicional para proporcionar el valor actual de
la métrica.
Si los valores no se calculan de manera adecuada, pueden resultar confusos,

engañosos y llevar a conclusiones erróneas.
Los eventos extendidos de SQL Server

Los eventos extendidos de SQL Server permiten recolectar la información
necesaria para poder solucionar problemas de rendimiento de SQL Server.
Permiten también poder encontrar las consultas más costosas, causas de

bloqueo, interbloqueo y bloqueo, solución de problemas de uso excesivo del
procesador y más.
Para poder usar eventos extendidos de supervisión del rendimiento, determina

que eventos desea supervisar y crea una sesión con las opciones de SQL Server
Management Studio o T-SQL.
Para crear la sesión de ReadWriteActivity para capturar datos de eventos de

lecturas y escrituras de archivos completadas y escribirlas, desde el archivo de
caché del registro al archivo de registro físico:
CREATE EVENT SESSION ReadWriteActivity
ON SERVER
ADD EVENT sqlserver.file_read_completed,
ADD EVENT sqlserver.file_write_completed
ADD TARGET package0.asynchronous_file_target
(SET filename = 'c:\PerfLogs\ExtELog.xel', metadatafile =

'c:\PerfLogs\ExtELog.xem')
Una vez creada está sesión, para poder iniciarla:
1. Expandir el administrador en el Explorador de objetos

2. Expandir los eventos extendidos
3. Expandir sesiones
4. Encuentre la sesión del evento, haga clic derecho y seleccione Iniciar
Para poder ver los datos del evento en vivo junto con sus detalles,
seleccione Ver datos en vivo en el menú contextual del evento en el Explorador
de objetos.


Tema II - Diez consejos para la optimización
del rendimiento de SQL Server
La optimización de rendimiento de SQL Server puede ser todo un desafío. Se

ofrece una gran cantidad de información sobre cómo abordar los problemas de
rendimiento en general. Sin embargo, no hay mucha información detallada para
problemas específicos y aún menos información sobre cómo aplicar esos
conocimientos específicos en su propio entorno.
Consejo n.º 10. La metodología “Línea de

base y evaluación comparativa” le permite
detectar problemas.
Información general sobre el proceso de línea de base y evaluación comparativa

La Figura 1 muestra los pasos del proceso de línea de base. En las siguientes
secciones se explican los pasos clave del proceso.

Antes de comenzar a realizar cambios, obtenga un registro del rendimiento

actual del sistema. Cuando se trata de configurar y optimizar, la mayoría nos
vemos tentados a comenzar a cambiar todo de inmediato. ¿Nunca buscó su
auto por el mecánico y se preguntó si en realidad funciona peor que antes?
Le gustaría quejarse, pero no está seguro. También es probable que se pregunte
si el nuevo problema que cree observar se debe a algo que hizo el mecánico o
es algo que sucedió luego. Lamentablemente, el rendimiento de la base de
datos puede sufrir los mismos problemas. Después de leer este documento,
tendrá muchas ideas y deseará implementar la estrategia de línea de base y

evaluación comparativa de inmediato. El primer paso que debe dar no es el más
atractivo, pero sin dudas es el más importante: es el momento de determinar
en qué condiciones se encuentra el entorno en comparación con los criterios
que planea modificar. Determine sus objetivos. Antes de hacer nada en el
sistema, decida qué desea conseguir. ¿Hay aspectos de los SLA relacionados
con el rendimiento, el consumo de recursos o la capacidad que desea abordar?
¿Está abordando un problema actual en producción? ¿Ha habido quejas con
respecto al tiempo de los recursos? Establezca algunos objetivos claros. La
mayoría cuenta con muchas bases de datos e instancias de las que ocuparse.
Para maximizar el valor de sus esfuerzos, debe pensar cuidadosamente qué se
necesita para un sistema en particular con el fin de que tenga un buen
rendimiento y cumpla con las expectativas de los usuarios. Si realiza un análisis
y una optimización demasiado extensos, descubrirá que invierte una cantidad
desproporcionada de tiempo en sistemas de baja prioridad, lo que va en
detrimento de los sistemas de producción principales. Sea claro precisamente
en lo que desea obtener a través de sus esfuerzos de medición y optimización.
Priorícelos e, idealmente, obtenga el consenso y la inversión de un patrocinador
empresarial.
Establezca la norma. Una vez que detectó qué desea obtener, entonces debe
decidir cómo medirá el resultado. ¿Cuáles son los contadores de sistema
operativo, los contadores de SQL Server, las medidas de recursos y los otros
puntos de datos que le proporcionarán la visibilidad necesaria? Una vez que
tenga esa lista, debe establecer su línea de base o, en otras palabras, el
rendimiento típico del sistema en comparación con los criterios elegidos. Debe
recopilar suficientes datos durante un período lo suficientemente largo para
obtener una muestra representativa del rendimiento típico del sistema. Una
vez que tenga los datos, puede sacar un promedio de los valores durante el
período para establecer su primera línea de base. Después de realizar
modificaciones en el sistema, debe realizar una nueva evaluación comparativa
y compararla con la original para poder medir objetivamente el efecto de las
modificaciones.
No realice un seguimiento de los valores promedio únicamente, también debe

realizar un seguimiento de las desviaciones de la norma. Aun así, es importante
ser cuidadoso con los promedios. Por lo menos, calcule la desviación estándar
de cada contador para obtener una indicación de la variación en el tiempo.
Piense en el montañista al que se le informa que el diámetro promedio de la

soga es de 1 cm. El montañista salta con confianza hasta el otro lado. Pasa por
encima de varios metros de rocas filosas y sonríe con satisfacción. Luego se le
informa que la sección más gruesa de la soga es de 2 cm y la más delgada es de
0,1 cm. ¡Lo sentimos! Si no está familiarizado con la desviación estándar,
consulte un libro de estadísticas para principiantes. No necesita estudiar
demasiado, pero sí es útil conocer lo básico. El mensaje clave aquí es no estudiar
los promedios únicamente, sino también estudiar la desviación de la norma (la
media). Decida cuál debe ser la norma (esta información suele encontrarse en
los SLA). Su misión no es obtener el mejor rendimiento posible, sino cumplir
con sus objetivos de rendimiento de la mejor manera posible y luego limitar la
desviación de esos objetivos en la mayor medida posible. Cualquier otra cosa
que haga será tiempo y esfuerzo malgastados y quizás también resulte en la
utilización ineficiente de los recursos de la infraestructura.
¿Cuántos datos se necesitan para una línea de base? La cantidad de datos

necesaria para establecer una línea de base depende de cuánto varía la carga
en el tiempo. Consulte a los administradores de sistemas, los usuarios finales y
los administradores de aplicaciones. Generalmente tienen una idea acertada de
cuáles son los patrones de uso. Debe reunir la suficiente cantidad de datos para
cubrir los períodos promedio, pico y no pico. Es importante medir la cantidad
en la que varía la carga y con cuánta frecuencia. Se necesitan menos datos para
los sistemas con patrones predecibles. Mientras más variación haya, el intervalo
de medición será menor y deberá realizar más mediciones para obtener una
línea de base confiable. Para desarrollar un poco más la analogía del
montañista, mientras mayor sea la longitud de la soga que examina, más
chances tendrá de detectar las variaciones. La criticidad del sistema y el impacto
que tendría una falla de este también afectan la cantidad de investigación y la
confiabilidad de la muestra.
Almacenamiento de los datos Mientras más parámetros tenga en cuenta y

menor sea la frecuencia, mayor será el conjunto de datos recopilado. Quizás
parezca obvio, pero debe tener en cuenta la capacidad necesaria para
almacenar los datos de las mediciones. Una vez que cuente con algunos datos,
debería ser bastante sencillo extrapolar el crecimiento del repositorio en el
tiempo. Si realizará la supervisión durante un período extenso, considere el
agregado de datos históricos en intervalos con el fin de evitar un crecimiento

desmedido del repositorio. Por motivos de rendimiento, el repositorio de
medidas no debe alojarse en el mismo sitio que la base de datos que está
supervisando. Limite la cantidad de cambios que realiza en determinado
momento. Intente limitar la cantidad de modificaciones que realiza entre cada
evaluación comparativa. Ordene las modificaciones para probar una hipótesis
en particular. Esto le permitirá confirmar o descartar cada candidato para las
mejoras. Cuando se centre en una solución, comprenderá exactamente por qué
está analizando los cambios del comportamiento, y comprobará que, con
frecuencia, esto revela una serie adicional de potenciales opciones de
optimización. Análisis de los datos Una vez que realizó los cambios en el
sistema, querrá determinar si tuvieron el efecto deseado. Para ello, repita las
mediciones que tomó en la línea de base original en una escala de tiempo
representativa y similar.
Luego, puede comparar las dos líneas de base para:
• Determine si los cambios tuvieron el efecto deseado: Cuando modifica la

configuración, optimiza un índice o cambia el código SQL, la línea de base le
permite saber si el cambio tuvo el efecto deseado. Si recibe alguna queja
porque el rendimiento es más lento, puede saber con seguridad que la
instrucción es precisa desde el punto de vista de la base de datos. El error más
frecuente que cometen la mayoría de los DBA sin mucha experiencia es realizar
conclusiones precipitadas. A menudo verá que alguien salta de la felicidad
cuando nota un aumento instantáneo y notable en el rendimiento después de
hacer uno o más cambios. Lo implementa en producción y comienza a mandar
correos con información de la resolución del problema. Pero estos festejos
pueden ser cortos cuando los mismos problemas vuelven a surgir después de
un tiempo o se genera otro problema a partir de efectos secundarios no
conocidos. Con frecuencia el resultado es una situación menos deseable que la
original. Cuando piense que encontró la respuesta a un problema, póngala a
prueba y realice una evaluación comparativa con la línea de base. Esta es la
única manera confiable de saber si tuvo algún progreso.
Determine si un cambio tuvo algún efecto secundario no esperado: Una línea de

base también le permite ver objetivamente si un cambio afectó un contador o
una medición que no esperaba que afectara.

• Anticipe los problemas antes de que ocurran: Con una línea de base puede
establecer normas de rendimiento precisas contra las condiciones de carga
típicas. Esto le permite predecir si habrá problemas en el futuro y cuándo,
basado en la tendencia actual de consumo de recursos o las cargas de trabajo
proyectadas para los escenarios futuros. Por ejemplo, realiza una planificación
de capacidad: Puede predecir cuándo los sistemas se encontrarán con un cuello
de botella en la conexión de usuarios si extrapola el consumo de recursos típico
por usuario conectado.
• Solucione problemas de manera más eficaz: ¿Alguna vez estuvo varios días y
noches luchando con un problema de rendimiento en la base de datos y
descubrió que no estaba relacionado para nada con la base de datos? Al
establecer una línea de base es más sencillo eliminar la instancia de base de
datos y detectar la causa. Por ejemplo, suponga que el consumo de memoria
aumentó mucho repentinamente. Puede observar que la cantidad de
conexiones aumentó mucho y se encuentra muy por encima de la línea de base.
Consulta la situación con el administrador de aplicaciones y le confirma que se
implementó un nuevo módulo en eStore. No pasa demasiado tiempo hasta que
se descubre que el nuevo desarrollador con poca experiencia escribe código
que no libera las conexiones de base de datos como debería. Apuesto a que
puede pensar en más escenarios similares. Si se descartan las cosas que NO son
responsables de un problema, se puede ahorrar mucho tiempo, ya que se
despeja el panorama y se obtiene una vista más precisa de la causa del
problema. Hay muchos ejemplos en los que puede comparar los contadores del
sistema con los contadores de SQL Server para confirmar o descartar si la base
de datos es la causa de un problema. Una vez que se descartan los sospechosos
de siempre, puede comenzar a buscar las desviaciones significativas de la línea
de base, reunir los indicadores relacionados y comenzar a profundizar en la
causa raíz.
Repita el proceso de línea de base con tanta frecuencia como sea necesario. Una
buena optimización consiste en un proceso repetitivo y científico. Los consejos
que se ofrecen en este documento son un buen punto de partida, pero son solo
eso: un punto de partida. La optimización del rendimiento es un proceso
altamente personalizado y está determinado por el diseño, la composición y el
uso de cada sistema individual. La metodología de línea de base y evaluación
comparativa es la piedra angular de una optimización del rendimiento buena y
confiable. Proporciona el mapa, una referencia y las coordenadas que se

necesitan para descubrir qué necesitamos para llegar y cómo llegar, con el fin
de garantizar que no nos perdamos en el camino. Un enfoque estructurado nos
permite construir un rendimiento confiable y uniforme en la cartera de base de
datos.
Consejo n.º 9. Los contadores de

rendimiento le proporcionan información
rápida y útil sobre las operaciones que
actualmente están en ejecución.
Razones para supervisar los contadores de rendimiento

Una pregunta muy común con respecto a la optimización del rendimiento de
SQL Server es: “¿Qué contadores debo supervisar?”.
En lo que respecta a la administración de SQL Server, hay dos motivos

importantes para la supervisión de los contadores de rendimiento:
• Cada vez mayor eficiencia operativa

• Prevención de los cuellos de botella
Si bien coinciden en algunos puntos, estos dos motivos le permiten elegir con
facilidad puntos de datos para supervisar.
Supervisión de los contadores de rendimiento para mejorar la eficiencia

operativa La supervisión operativa
Comprueba el uso general de recursos. Ayuda a responder a preguntas como:

• El servidor que se está por ejecutar, ¿se quedará sin recursos como la CPU,
espacio en disco o memoria?
• Los archivos de datos, ¿pueden crecer?
• Los archivos de datos de tamaño fijo, ¿tienen suficiente espacio para los
datos?
También puede usar esos datos para determinar las tendencias. Un buen
ejemplo sería recopilar los tamaños de todos los archivos de datos para

determinar la tendencia de las tasas de crecimiento y poder predecir los
requisitos para los recursos en el futuro.
Para responder a las tres preguntas anteriores, debe observar los siguientes
contadores:
Supervisión de contadores de rendimiento para evitar cuellos de botella La

supervisión de cuellos de botella se enfoca más en los problemas relacionados
con el rendimiento. Los datos recopilados lo ayudan a responder a preguntas
como:
• ¿Hay un cuello de botella de la CPU?

• ¿Hay un cuello de botella de E/S?
• Los subsistemas más importantes de SQL Server, como la caché de búfer y la
caché de plan, ¿se encuentran en buen estado?
• ¿Hay contención en la base de datos?

Para responder a estas preguntas, observe los siguientes contadores:
Consejo n.º 8. La modificación de la

configuración del servidor puede
proporcionar un entorno más estable.
El cambio de la configuración dentro de un producto para obtener una mayor

estabilidad puede sonar contraintuitivo, pero en este caso realmente funciona.
Como un DBA, su trabajo consiste en garantizar un nivel de rendimiento
uniforme para los usuarios cuando solicitan datos de las aplicaciones. Si no se
modifica la configuración descrita en el resto de este documento, es posible
que se experimenten escenarios que provoquen la reducción del rendimiento
de los usuarios sin ninguna advertencia. Estas opciones pueden encontrarse
fácilmente en sys. configurations, que detalla las configuraciones disponibles al
nivel de los servidores, junto con información adicional. En el atributo
Is_Dynamic en sys.configurations se muestra si la instancia de SQL Server
deberá reiniciarse después de realizar una modificación en la configuración.
Para realizar el cambio, debería llamar el procedimiento sp_configure
almacenado con los parámetros relevantes.

La configuración de memoria mínima y máxima puede garantizar un nivel
determinado de rendimiento.
Suponga que tiene un clúster Activo/ Activo (o un solo host con varias
instancias). Podemos realizar algunas modificaciones en la configuración para
garantizar que podamos cumplir los SLA en el caso de una conmutación por
error en la que ambas instancias estén alojadas en la misma caja física.
En este caso, deberíamos cambiar la configuración de memoria mínima y

máxima para garantizar que el host físico tenga la cantidad de memoria
suficiente para encargarse de cada instancia sin realizar intentos constantes de
recortar de forma drástica el conjunto en funcionamiento de la otra instancia.
Se puede realizar una modificación similar en la configuración para usar
determinados procesadores con el fin de garantizar cierto nivel de rendimiento.
Es importante tener en cuenta que la configuración de la memoria máxima no

solo es adecuada para las instancias en un clúster sino también para las
instancias que comparten recursos con cualquier otra aplicación. Si el uso de la
memoria de SQL Server es muy alto, el sistema operativo podría recortar
notablemente la cantidad de memoria que puede usar con el fin de permitir
que el sistema operativo o las aplicaciones puedan funcionar.
 SQL Server 2008: En SQL Server 2008 R2 y las versiones anteriores, la

configuración de memoria mínima y máxima restringe solo la cantidad de
memoria que utiliza el bloque de búferes (más específicamente solo
ubicaciones simples de páginas de 8 KB). Esto significa que, si ejecuta
procesos fuera del bloque de búferes (como procedimientos extensos
almacenados, CLR u otros componentes como Servicios de integración,
Servicios de generación de informes o Servicios de análisis), necesita
reducir aún más este valor.
 SQL Server 2012: En SQL Server 2012 las cosas varían un poco, ya que hay
un administrador de memoria central. En este administrador de memoria
ahora se incorporan ubicaciones multipágina, como páginas de datos
grandes y planes en caché con un tamaño mayor que 8 KB. Este espacio
de memoria ahora incluye alguna funcionalidad de CLR.

Dos opciones de servidor que pueden colaborar con el rendimiento de manera
indirecta.
No hay opciones que colaboren directamente con el rendimiento, pero hay dos
opciones que pueden colaborar de manera indirecta.
 Compresión de copias de seguridad de manera predeterminada: Esta

opción establece que las copias de seguridad se compriman de manera
predeterminada. Si bien esto puede renovar ciclos de las CPU adicionales
durante la compresión, en general se usan menos ciclos de CPU en total
cuando se lo compara con una copia de seguridad sin comprimir, ya que
se escriben menos datos en el disco. Según su arquitectura de E/S, la
configuración de esta opción también podría permitir la reducción de la
contención de E/S.
 Es posible que la segunda opción se divulgue en un consejo futuro sobre
la caché de plan. Deberá esperar y ver si está incluida en esta lista.
Consejo n.º 7. Encuentre instrucciones no

autorizadas en la caché de plan
Una vez que identifica un cuello de botella, debe detectar la carga de trabajo
que causa ese cuello de botella. Esta es una tarea mucho más sencilla desde la
presentación de los Objetos de administración dinámica (DMO) en SQL Server
2005. Los usuarios de SQL Server 2000 y las versiones anteriores deberán
conformarse con Profiler o Trace (más información en el consejo n.º 6).
Diagnóstico de un cuello de botella de la CPU En SQL Server, si detectó un cuello

de botella de la CPU, lo primero que querrá es obtener los mayores
consumidores de la CPU del servidor. Esta es una consulta muy sencilla en
sys.dm_exec_ query_stats:

La parte realmente útil de esta consulta es la capacidad de usar cross apply

y sys.dm_ exec_sql_text para obtener la instrucción SQL con el fin de analizarla.
Diagnóstico de un cuello de botella de E/S Sucede algo similar con un cuello de

botella de E/S:

Consejo n.º 6. SQL Profiler es su amigo
Comprender SQL Server Profiler e Extended Events
SQL Server Profiler es una herramienta nativa incluida en SQL Server. Le permite
crear un archivo de seguimiento que captura los eventos que ocurren en SQL
Server. Estos seguimientos pueden ser invaluables a la hora de proporcionar
información sobre la carga de trabajo y las consultas por bajo rendimiento. En
este documento técnico no ahondaremos en detalles sobre cómo utilizar la
herramienta Profiler. Para obtener más información sobre el uso de SQL Server
Profiler, vea el tutorial en video en SQLServerPedia.
Si bien es cierto que SQL Server Profiler se marcó como obsoleto en SQL Server
2012 en favor de Extended Events, debe tenerse en cuenta que esto es solo
para el motor de la base de datos y no para los Servicios de análisis de SQL
Server. Profiler aún puede proporcionar una gran visibilidad de cómo funcionan
las aplicaciones en tiempo real en muchos entornos de SQL Server.
El uso de Extended Events está fuera del alcance de este documento técnico.
Para obtener una descripción detallada de Extended Events consulte el
documento técnico “Cómo utilizar Extended Events y Notificaciones de SQL
Server para resolver problemas de rendimiento de manera proactiva”. Basta
con mencionar que los Extended Events se presentaron en SQL Server 2008 y
se actualizaron en SQL Server 2012 para incluir más eventos y una muy
esperada interfaz de usuario.
Tenga en cuenta que para la ejecución de Profiler se requiere el permiso

ALTER TRACE.
Cómo utilizar SQL Profiler
Aquí se explica cómo construir el proceso de la recopilación de datos en

Performance Monitor (Perfmon) y relacionar la información del uso de recursos
con los datos en los eventos de SQL Server:
1. Abra Perfmon.

2. Si no tiene un conjunto Recopilador de datos ya configurado cree uno con la
opción avanzada y los contadores del consejo n.º 9 como guía. No ejecute el
conjunto del recopilador de datos todavía.
3. Abra Profiler.
4. Cree un nuevo seguimiento mediante la especificación de los detalles de la

instancia, los eventos y las columnas que desea supervisar, además del destino.
5. Inicie el seguimiento.
6. Vuelva a Perfmon para ejecutar el conjunto del recopilador de datos.
7. Deje ambas sesiones en ejecución hasta que se obtengan los datos

necesarios.
8. Detenga el seguimiento de Profiler. Guarde el seguimiento y luego ciérrelo.
9. Vuelva a Perfmon y detenga el conjunto de recopilación de datos.
10. Abra el archivo de seguimiento guardado recientemente en Profiler.
11. Haga clic en Archivo y luego Importar datos de rendimiento.
12. Navegue hasta el archivo de datos del Recopilador de datos y seleccione los
contadores de rendimiento relevantes.
Ahora podrá ver los contadores de rendimiento en conjunto con el archivo

de seguimiento de Profiler (consulte la Figura 2), que permitirá una resolución
mucho más rápida de los cuellos de botella.
Consejo adicional: En los pasos anteriores se usa la interfaz del cliente; para
ahorrar recursos, un seguimiento desde el servidor es más eficaz. Consulte
Libros en línea para obtener información sobre cómo comenzar y detener
seguimientos desde el servidor.

Consejo n.º 5. Configure SAN

para el rendimiento de SQL Server.
Las redes de área de almacenamiento (SAN) son geniales. Ofrecen la capacidad

de aprovisionar y administrar almacenamiento de manera simple. Las SAN se
pueden configurar para obtener un rendimiento veloz desde la perspectiva de
SQL Server, pero a menudo no se configuran de este modo. Las organizaciones
suelen implementar las SAN por motivos como la consolidación del
almacenamiento y la facilidad de la administración, no para el rendimiento.
Para empeorar las cosas, en general usted no tiene control directo sobre la
manera en que se realiza el aprovisionamiento en una SAN. Entonces, verá que
usualmente la SAN se configuró para un volumen lógico en el que tiene que
poner todos los archivos de datos.
Las mejores prácticas para la configuración de SAN para el rendimiento de E/S
Agrupar todos los archivos en un solo volumen suele no ser una buena idea si
busca el mejor rendimiento de E/S. Como mejores prácticas, querrá:
 Colocar los archivos de registro en su propio volumen, separados de los

archivos de datos. Casi con exclusividad, los archivos de registro son de
escritura secuencial y no de lectura (con las excepciones de los grupos

Creación de reflejo de la base de datos y Siempre disponible). Siempre
debe configurarlos para obtener un rendimiento de escritura veloz.
 Coloque tempdb en su propio volumen. SQL Server usa tempdb
internamente para una infinidad de propósitos, por lo que tenerlo en su
propio subsistema de E/S será de utilidad. Para optimizar aún más el
rendimiento, primero necesita algunas estadísticas.
 Considere la creación de varios archivos de datos y grupos de archivos en
VLDB con el fin de beneficiarse de las operaciones de E/S.
 Ubique las copias de seguridad en sus propias unidades por motivos de
redundancia y para reducir la contención de E/S con otros volúmenes
durante los períodos de mantenimiento.
Recopilación de datos
Por supuesto que hay contadores de disco de Windows que le proporcionan

una idea de lo que Windows cree que sucede. (No olvide configurar los valores
sin procesar en la configuración RAID). Los proveedores de SAN suelen
proporcionar sus propios datos de rendimiento.
SQL Server también proporciona información de E/S a nivel del archivo:
 Versiones anteriores a SQL 2005: Utilice la función fn_virtualfilestats.

 Versiones posteriores: Utilice la función de administración dinámica
sys.dm_io_virtual_file_stats.
Al usar esta función en el siguiente código puede:
 Derivar tasas de E/S para lecturas y escrituras

 Obtener el rendimiento de E/S
 Obtener el tiempo promedio por E/S
 Observar los tiempos de espera de E/S

Análisis de los datos
Preste especial atención al valor “LastReset” en la consulta; allí se muestra la

última vez que se inició el servicio SQL Server. Los datos de los Objetos de
administración dinámica no son persistentes, por lo que los datos utilizados
para la optimización deben validarse según la cantidad de tiempo de ejecución
del servicio. Si no, pueden realizarse conjeturas falsas.
Con estos números puede acotar rápidamente el espectro y ver los archivos
responsables del consumo del ancho de banda de E/S y hacerse preguntas como:
 ¿Esta E/S es necesaria? ¿Hay un índice que no estoy viendo?

 El responsable, ¿es una tabla o un índice del archivo? ¿Puedo poner este
índice o tabla en otro archivo en otro volumen?
Consejos para la optimización del hardware Si los archivos de base de datos se

colocan correctamente y todas las zonas activas de objeto se han identificado
y separado en diferentes volúmenes, entonces es hora de ver el hardware en
mayor detalle.
La optimización del hardware es un tema para especialistas que no está dentro

del alcance de este documento técnico. Sin embargo, hay algunos consejos y
mejores prácticas que puedo compartir para facilitar esto:

 No use la unidad de asignación predeterminada cuando cree volúmenes
para usar con SQL Server. SQL Server usa tamaños de 64 KB, por lo que
este valor debe ser el mínimo.
 Compruebe que las particiones estén correctamente alineadas. Jimmy
May escribió un excelente documento técnico sobre este tema. Las
particiones mal alineadas pueden reducir el rendimiento hasta en un
30 %.
 Realice una evaluación comparativa de la E/S de su sistema con una
herramienta como SQLIO. Puede ver un tutorial sobre cómo utilizar esta
herramienta.
Consejo n.º 4. Los cursores y otros T-SQL

malos suelen volver para atormentar a las
aplicaciones.
Un ejemplo de código malo
En un trabajo anterior descubrí lo que debe ser el peor código que vi en toda
mi carrera. El sistema se reemplazó hace mucho tiempo, pero este es un
resumen del proceso de la función:
1. Aceptar el valor del parámetro que se eliminará.

2. Aceptar la expresión del parámetro que se eliminará.
3. Encontrar la longitud de la expresión.
4. Cargar la expresión en una variable.
5. Recorrer cada carácter de la variable y comprobar si el carácter coincide
con uno de los valores que se eliminará. Si es así, actualizar la variable
para eliminarla.
6. Continuar con el próximo carácter hasta que la expresión se haya
comprobado en su totalidad.
Si se espantó, entonces está en buena compañía. Claro que estoy intentando

explicar el intento que alguien hizo para escribir una instrucción de
“REEMPLAZO” de T-SQL.

La peor parte es que esta función se utilizaba para actualizar direcciones como
parte de una rutina de correos y se utilizaba miles de veces por día.
La ejecución de un seguimiento de Profiler desde el servidor le permitirá ver la

carga de trabajo del servidor y elegir las partes del código que se ejecutan con
frecuencia (que es la manera en la que se descubrió esta “gema”).
Optimización de consultas mediante planes de consultas
El T-SQL malo también puede presentarse como consultas ineficientes que no

utilizan índices, mayormente porque el índice es incorrecto o no hay índice. Es
de vital importancia tener una buena comprensión de cómo optimizar las
consultas mediante planes de consultas.
Un debate detallado sobre la optimización de consultas mediante planes de

consulta no está dentro del alcance de este documento técnico. Sin embargo,
la manera más sencilla de empezar este proceso es convertir las operaciones
SCAN en operaciones SEEK. Las operaciones SCAN leen cada fila de una tabla o
del índice, por lo que en el caso de tablas grandes son muy costosas en términos
de E/S. En cambio, una operación SEEK usa el índice para ir directamente a la
fila deseada, para lo que, obviamente, se necesita un índice. Si encuentra
operaciones SCAN en su carga de trabajo, quizás no tenga índices.
Hay muchos buenos libros sobre este tema, incluidos:
• “Professional SQL Server Execution Plan Tuning” de Grant Fritchey.

• “Professional SQL Server 2012 Internals & Troubleshooting” de
Christian Bolton, Rob Farley, Glenn Berry, Justin Langford, Gavin
Payne, Amit Banerjee, Michael Anderson, James Boother y Steven
Wort.
• “T-SQL Fundamentals for Microsoft SQL Server 2012 and SQL
Azure” de Itzik Ben-Gan.

Consejo n.º 3. Maximice la reutilización del

plan para una mejor caché de SQL Server
Por qué es importante reutilizar planes de consultas
Antes de ejecutar una instrucción SQL, SQL Server debe crear un plan de
consulta primero. Esto define el método que empleará SQL Server para tomar
la instrucción lógica de la consulta e implementarla como una acción física
en los datos.
Crear un plan de consulta puede requerir un uso significativo de la CPU.

Entonces, SQL Server se ejecutará de manera más eficaz si puede reutilizar los
planes de consultas en vez de crear uno nuevo cada vez que se ejecuta una
instrucción SQL.
Evaluar si tiene una buena reutilización de planes
En el objeto de rendimiento SQL Statistics hay algunos buenos contadores de

rendimiento que le indicarán si cuenta con una buena reutilización de los
planes. Esta fórmula le indica la relación de lotes enviados a compilaciones:

Este número debe ser lo más pequeño posible. Una relación de 1:1 significa que
cada lote enviado se está compilando y no se reutilizan los planes.
(Batch Requests/sec – SQL Compilations/sec) / Batch Requests/sec
Abordar una mala reutilización de planes
No es sencillo detectar exactamente qué carga de trabajo es la responsable de

la mala reutilización de planes porque el problema suele residir en el código de
la aplicación cliente que envía las consultas. Entonces, debe ver el código de la
aplicación cliente que envía las consultas.
Para encontrar el código integrado en una aplicación de cliente, debe usar

Extended Events o Profiler. Al agregar el evento SQL:StmtRecompile en un
seguimiento podrá ver cuando haya un evento de recopilación. (También hay
un evento llamado SP:Recompile; este evento se incluye para la compatibilidad
hacia atrás desde que se modificó una compilación desde el nivel de
procedimiento al nivel de instrucción en SQL Server 2005).
Un problema común es que el código no utiliza instrucciones con parámetros

preparadas. Si se utilizan consultas con parámetros, no solo se mejora la
reutilización de planes y la carga de la compilación, sino que también se reduce
el riesgo de ataque por inyección de código SQL relacionado con el paso de
parámetros a través de una concatenación de cadenas. En la Figura 5 se
muestran dos ejemplos de código. Si bien son artificiales, muestran la diferencia
entre la generación de una instrucción a través de una concatenación de
cadenas y la utilización de instrucciones con parámetros preparadas.

SQL Server no puede reutilizar el plan del ejemplo “malo” de la Figura 5. Si el

parámetro hubiera sido un tipo de cadena, esta función podría utilizarse para
montar un ataque por inyección de código SQL. El ejemplo “bueno” no es
vulnerable a un ataque por inyección de código SQL porque se utiliza un
parámetro y SQL Server puede reutilizar el plan.
La configuración que faltaba del consejo n.º 8
Las personas con buena memoria recordarán que en el consejo n.º 8 (donde
hablamos sobre las modificaciones en la configuración) había un consejo más
para ofrecer. SQL Server 2008 presentó una configuración llamada
“Optimización para cargas de trabajo ad hoc”. Al configurarla, SQL Server
almacenará un plan parcial en lugar de un plan completo en la caché de plan.
Esto es especialmente útil para los entornos que utilizan código T-SQL
construido dinámicamente o Linq que puede ocasionar una no reutilización
del código.

La memoria asignada a la caché de plan se encuentra en el bloque de búferes.
Por lo tanto, una caché de plan muy llena reduce la cantidad de páginas de
datos que se pueden almacenar en la caché de búfer, entonces habrá más viajes
de ida y vuelta para buscar datos en el subsistema de E/S, lo que puede ser muy
costoso.
Consejo n.º 2. Aprenda cómo leer la caché

de búfer de SQL Server y minimizar la
hiperpaginación de caché.
Por qué es importante la caché de búfer
Tal como se mencionó anteriormente, la caché de búfer es una gran área de

memoria que utiliza SQL Server para reducir la necesidad de realizar E/S física.
Ninguna ejecución de consulta de SQL Server lee datos directamente del disco;
las páginas de base de datos se leen desde la caché de búfer. Si la página que
se busca no está en la caché de búfer, se pone en cola de espera una solicitud
de E/S física. Entonces la consulta espera y se busca la página en el disco.
Las modificaciones realizadas a los datos de una página desde una operación
ELIMINAR o ACTUALIZAR también se realizan en las páginas de la caché de
búfer. Luego, estas modificaciones se eliminan del disco. Todo este mecanismo
permite que SQL Server optimice la E/S física de muchas maneras:
 Se pueden leer y escribir varias páginas en una sola operación de E/S.

 Se puede implementar la lectura previa. SQL Server puede notar que para
algunos tipos de operaciones puede ser útil leer páginas secuenciales. Se
asume que después de leer la página solicitada se desea leer la página
siguiente.
Evaluación del estado de la caché de búfer Hay dos indicadores del estado de
la caché de búfer:
 MSSQL$Instance:Buffer Manager\Buffer cache hit ratio: Es la relación

entre las páginas encontradas en la caché y las páginas no encontradas
en la caché (las páginas que deben leerse desde el disco). Idealmente,

este número debe ser lo más pequeño posible. Es posible que tenga una
relación de aciertos alta y aun así experimente hiperpaginación de caché.
 MSSQL$Instance:Buffer Manager\Page Life Expectancy: Es la cantidad de
tiempo que SQL Server mantiene las páginas en la caché de búfer antes
de que se borren. Microsoft dice que una expectativa de vida de página
mayor de cinco minutos está bien. Si la expectativa de vida es menor,
puede ser un indicador de presión de memoria (no hay suficiente
memoria) o hiperpaginación de caché.
Hiperpaginación de caché
Durante un análisis de índices o de tablas grandes, cada página del análisis debe
pasar por la caché de búfer, lo que significa que posiblemente las páginas útiles
se borren para dar lugar a las páginas que quizás no se lean más de una vez.
Esto produce una E/S alta, ya que las páginas borradas deben leerse
nuevamente desde el disco. Esta hiperpaginación de caché suele ser un
indicador de que se están analizando tablas o índices grandes.
Para determinar qué tablas e índices ocupan más espacio en la caché de búfer,
puede examinar la vista de administración dinámica (DMV) sys.dm_os_ buffer_
descriptors (disponible a partir de SQL Server 2005). La consulta de ejemplo que
se encuentra a continuación muestra cómo acceder a la lista de tablas o índices
que consumen espacio en la caché de búfer en SQL Server: También puede usar
las DMV de índice para detectar qué tablas o índices tienen una gran cantidad
de E/S física.

Consejo n.º 1. Comprender cómo se
utilizan los índices y encontrar índices
malos.
SQL Server 2012 proporciona algunos datos muy útiles sobre los índices, que
puede buscar con los DMO implementados en SQL Server 2005.
Uso del DMO
sys.dm_db_index_operational_stats
El objeto sys.dm_db_index_operational_ stats contiene información sobre

la actividad de E/S, bloqueo, pestillo y método de acceso de bajo nivel actual
para cada índice. Use este MDF para responder a las siguientes preguntas:
 ¿Tengo un índice “activo”? ¿Tengo un índice en el que hay contención?

Las columnas row lock wait in ms/page lock wait in ms pueden indicarnos
si hubo esperas en este índice.
 ¿Tengo un índice que se está usando de manera no eficiente? ¿Qué
índices son cuellos de botella de E/S actualmente? La columna
page_io_latch_wait_ ms puede indicarnos si hubo esperas de E/S al
tiempo que lleva páginas de índice a la caché de búfer, lo que es un buen
indicador de que hay un patrón de acceso de análisis.
 ¿Qué tipo de patrones de acceso se usan? Las columnas
range_scan_count y singleton_ lookup_count pueden indicarnos qué
clase de patrones de acceso se utilizan en determinado índice.
En la Figura 6, se ilustra el resultado de una consulta que ordena los índices

según la espera PAGE_IO_ LATCH total. Esto es muy útil cuando intenta
determinar qué índices forman parte de los cuellos de botella de E/S.
Uso del DMO
sys.dm_db_index_usage_stats

El objeto sys.dm_db_index_usage_stats contiene contadores de diferentes
tipos de operaciones de índice y el momento en que se realizó cada operación
por última vez. Use esta DMV para responder a las siguientes preguntas:
• ¿Cómo utilizan los índices los usuarios? Las columnas user_ seeks,
user_scans, user_lookups pueden indicarle los tipos y el
significado de las operaciones de usuario en relación con los
índices.
• ¿Cuál es el costo de un índice? La columna user_ updates puede
indicarle el nivel de mantenimiento de un índice.
• ¿Cuándo se utilizó un índice por última vez? Las columnas last_*
le indican la última vez que se realizó una operación en un índice.

En la Figura 7, se ilustra el resultado de una consulta que ordena los índices

según la cantidad total de user_seeks. Si, en cambio, desea identificar los
índices que tuvieron una gran proporción de análisis, puede ordenarlos por la
columna user_scans. Ahora que tiene un nombre de índice, ¿no sería bueno si
pudiera descubrir qué instrucciones SQL utilizan ese índice? En SQL Server 2005
y en las versiones posteriores puede hacerlo.
Por supuesto que hay otras áreas en los índices, como estrategia de diseño,
consolidación y mantenimiento.

Tema III - Auditoria en SQL Server
Creando una estrategia de auditoría exitosa

para sus bases de datos SQL Server
El propósito de una auditoría de seguridad es identificar todos los ataques y las

actividades ilegales o maliciosas que pueden estar tomando lugar en su
servidor. Los criminales se han vuelto cada vez más inventivos y, como DBA,
usted puede no haber considerado o siquiera haber estado consciente de todas
las actividades que pueden poner sus datos en riesgo.
Para este fin, realizar un seguimiento de quién ha accedido, quién ha intentado

acceder y qué ha sido hecho por la gente con acceso se han vuelto actividades
cruciales en identificar y apuntar las vulnerabilidades en su estrategia de
seguridad.
La importancia de la auditoría
¿Por qué auditamos? La meta número uno debería ser asegurar que su política
de seguridad es suficiente para mantener la información de su negocio y de sus
clientes segura y que sus riesgos están siendo manejados.
El gobierno y otros entes reguladores de industrias específicas han prescrito

requerimientos que deben ser cumplidos para ser certificados o evadir multas
y otros castigos. Algunos de estos requerimientos son PCI, HIPAA, SOX, etc. En
algunos casos, las únicas regulaciones pueden ser aquellas impuestas por el
negocio en sí.
Si su SQL Server no está siendo auditado, usted se está exponiendo a una gran
cantidad de problemas potenciales. Los problemas más comunes son ataques
externos, actividades no sancionadas por usuarios autorizados y errores.

Tener la auditoría en orden permite un análisis forense después de que un
incidente ha sido identificado. Lo que le permitirá implementar contramedidas
adecuadas y responsabilizar a los empleados por sus acciones.
Estrategia de auditoría
Idear una estrategia de auditoría sólida está en el centro de cualquier esfuerzo
exitoso de auditoría. Es bastante tentador auditar simplemente todo, pero en
un ambiente del mundo real, esto no es viable y puede llevar a problemas
como:
 Una sobreabundancia de datos, lo que hará difícil identificar cualquier

problema.
 Grandes cantidades de espacio de almacenamiento requeridas.
 Afectar de manera adversa al desempeño.
Antes de implementar cualquier solución de auditoría, lo siguiente necesita ser

considerado:
1. ¿Qué es lo que legalmente usted requiere auditar?

2. ¿Por cuánto tiempo se requiere que mantenga los datos auditados
legalmente?
3. ¿Cuándo espacio de almacenamiento tiene?
4. ¿Cuál es el propósito de los datos auditados? ¿Es sólo para el
cumplimiento de normas, o alguien revisará activamente los datos
acumulados para identificar vulnerabilidades?
5. ¿Cuán crítico es que suceda la auditoría?
Qué auditar
Identificar qué se necesita auditar realmente es el desafío más grande al crear
una estrategia de auditoría. Entender los datos en sus bases de datos es
fundamental para el éxito de su estrategia de auditoría.
Desde una perspectiva lógica, los datos que necesitan ser protegidos, cuyos
accesos deberían ser auditados, caen generalmente en estas categorías:

 Datos que pueden ser usados para identificar a una persona, como un
número de pasaporte o un número de seguridad social.
 Datos que proveen información personal acerca de una persona, como
su cabello y color de ojos, o incluso algo simple como el tipo de películas
que le gusta ver.
 Datos que pueden ser considerados sensitivos. Esto básicamente se
refiere a información que puede afectar negativamente, o en algunos
casos favorablemente, a aquellos involucrados si cayera en malas manos.
Esto típicamente incluye información como le registro de salud de una
persona o información financiera perteneciente a una compañía o una
persona.
Desde una perspectiva de base de datos, estas son las acciones que deberían
ser consideradas para la auditoría:
 Inicios de sesión
 Configuración
 Configuración de la auditoría
 Modificación del esquema
 Modificaciones de datos
Hay un balance delicado entre auditar muy poco y auditar demasiado. Esto
depende grandemente en sus razones para auditar. Incluso si su primer
objetivo debería ser mantener los datos de sus clientes seguros, muchas
compañías toman esto sólo hasta seguir las medidas prescritas por las reglas de
cumplimiento para su industria específica.
Si usted mide la seguridad de sus datos por su habilidad de pasar su auditoría,

entonces de todos modos audite sólo lo que es prescrito, ya que esto es
exactamente para lo que son estos requerimientos. Cumplir con las
regulaciones de su industria para seguridad debería ya cubrir la mayor parte de
las vulnerabilidades.
Como una sugerencia de buena práctica, también audite sus auditorías para
asegurar que nadie ha modificado lo que está siendo auditado y que usted está
cubierto para todas las eventualidades.

Si usted intenta usar la información obtenida para fortificar su servidor,
asegúrese de que también audita los eventos exitosos, así como los fallidos. No
solamente le ayudará a determinar quién está abusando de sus privilegios, sino
que también le permitirá ver si los ataques fallidos pueden haver sido exitosos
después de múltiples intentos. Los ataques SQL son más comúnmente dirigidos
al usuario SA, así que si usted ve múltiples intentos de inicio de sesión fallidos
para el usuario SA y luego un inicio de sesión exitoso, es válido pensar que
alguien ha obtenido acceso no autorizado a su sistema.
Auditando su implementación de auditoría

No es una ocurrencia poco común para DBAs deshabilitar la auditoría si el
servidor súbitamente comienza a desempeñarse pobremente.
Cuando esto ocurre, los DBAs pueden olvidar rehabilitar todas las tareas que se
han deshabilitado temporalmente, y esto puede luego llevar a una
vulnerabilidad incrementada. Auditar su implementación de auditoría puede
ayudarle a evadir este problema. Idealmente, una notificación debería ser
enviada si cambios han sido hechos a la configuración de auditoría, ya sea como
un recordatorio para el DBA para que rehabilite la auditoría o al auditor para
hacerle saber que alguien ha modificado la implementación de auditoría.
Esto también resalta cualquier actividad no autorizada realizada por usuarios

autorizados que tenían premeditado deshabilitar la auditoría previamente a
realizar su actividad.
Auditoría selectiva
En algunos casos, puede ser necesario aplicar auditoría selectiva por usuario o
por objetos.
Por ejemplo, la compañía puede querer tener un registro de quién ve sus datos
de salarios o un empleado específico ha levantado algunas banderas rojas, y
todas sus actividades necesitan ser rastreadas para determinar su culpa o
inocencia.

Archivando información de auditoría
Dado el volumen potencial de información auditoría, se volverá necesario
archivar los datos. Tener un repositorio central para todos los datos auditados
también lo hará más fácil identificar tendencias y procesar la información.
Adicionalmente, mantener la información de auditoría archivada le permitirá

revisar auditorías pasadas de nuevo, a la luz de nuevas transgresiones que
puede que hayan sido descubiertas recientemente.
La separación de tareas para asegurar que sólo personal autorizado, lo que

excluye administradores de sistema, tiene acceso a la información de auditoría
también ayuda a prevenir la modificación de datos de la auditoría.
Características de SQL Server disponibles para

facilitar la auditoría de seguridad
SQL Server tiene muchas características para facilitar la auditoría. Dependiendo
de sus requerimientos de auditoría, una o una combinación de estas
características puede ser la mejor manera de alcanzar su meta.
Auditoría C2
SQL Server has offered C2 auditing since SQL Server 2000 in orSQL Server ha
ofrecido auditorías C2 desde SQL Server 2000 para ser clasificado dentro de los
criterios de auditoría C2 prescritos por el Departamento de Defensa.
Los eventos auditables incluyen la ejecución de procedimientos almacenados,

la creación o eliminación de objetos y actividades de inicio y cierre de sesión.
En el caso de la auditoría C2, no es posible elegir qué auditar. Básicamente
audita todo o nada.
Los datos de la auditoría C2 son grabados en un archivo de registro en el

directorio MSSQL\DATA. Cada archivo está limitado a 200MB y uno nuevo es
creado cada vez que ese límite es alcanzado, hasta que al directorio se le acaba
el espacio o la auditoría es deshabilitada.

Para habilitar la Auditoría C2, usted puede:
 Revisar la casilla Enable C2 audit tracing en la pestaña de seguridad del

diálogo de propiedades del servidor.
 Use el siguiente código T-SQL.
sp_configure 'show advanced options', 1;
GO
RECONFIGURE;
GO

sp_configure 'c2 audit mode', 1;
GO
RECONFIGURE;
GO
Un dato importante a notar acerca de la auditoría C2 es que cuando está

habilitada y el servidor, por alguna razón, no puede registrar un evento, el
servidor se apagará. Esto es para prevenir que tome lugar cualquier actividad
que no está siendo auditada.
Cuando esto pasa, sólo hay 2 soluciones al problema.
1. Usted necesita hacer algo de espacio en el servidor para que la auditoría

pueda continuar antes de reiniciar el servidor o
2. Usted necesita reiniciar SQL Server con la bandera –f para evitar la
auditoría.
La auditoría C2 será deprecada en una versión futura y será reemplazada con

Compatibilidad con Criterio Común.
Compatibilidad con Criterio Común

Compatibilidad con Criterio Común fue introducida en SQL Server 2005 SP1,
pero desafortunadamente está disponible sólo en las Ediciones Enterprise,
Development y Evaluation de SQL Server.
Compatibilidad con Criterio Común fue creada por un grupo de naciones para
lograr lo siguiente:
 Incrementar la disponibilidad de productos de IT con seguridad mejorada

 Ayudar a los usuarios a evaluar productos de IT
 Mejorar la confianza del consumidor en seguridad de productos de IT

Un cuerpo internacional que es reconocido por la Organización Internacional
de Estándares (ISO) es responsable de mantener la compatibilidad con criterio
común.
Cuando usted habilita las opciones de compatibilidad con criterio común esto
es lo que pasará:
 Tomará ligar la Protección de Información Residual. Esto significa que las

asignaciones de memoria serán rescritas con un patrón conocido de bits
antes de que puedan ser asignadas a un nuevo recurso.
 Los inicios de sesión serán auditados. Esto incluye inicios de sesión
exitosos y fallidos.
 Los DENYs a nivel de tabla tomarán precedencia sobre los GRANT a nivel
de columna.
Para habilitar la opción de compatibilidad con criterio común usted puede:
 Seleccionar la casilla Enable Common Criteria en la pestaña Security en

el diálogo Server Properties.

 Usar el siguiente script T-SQL:
sp_configure 'show advanced options', 1;
GO
RECONFIGURE;
GO
sp_configure 'common criteria compliance enabled',

1;
GO

RECONFIGURE
GO
SQL Server Auditing

SQL Server Auditing fue primeramente lanzado en SQL Server 2008 como una
característica sólo de la edición Enterprise. En SQL Server 2012, la auditoría a
nivel de servidor está también disponible ahora para los usuarios de la Edición
Standard.
La característica de auditoría fue diseñada para mejorar una plataforma de

auditoría de seguridad con un impacto mínimo en el desempeño, lo cual es fácil
de manejar y puede satisfacer todas las consultas de auditoría.
Para usar SQL Auditing, 3 componentes deben ser configurados:
 Auditoría de Servidor (requerido)

La Auditoría de Servidor reside en la base de datos master y es usado
para definir dónde se almacenará la información de auditoría, si la
auditoría debería ser síncrona o asíncrona, cómo deberían manejarse los
archivos, y qué pasa si un evento de auditoría no puede ser registrado.
Esto está disponible en todas las ediciones de SQL Server de 2012 en
adelante.
 Especificación de Auditoría de Servidor (opcional)
Aquí es donde los eventos a nivel de servidor pueden ser auditados. Para
crear una especificación de Auditoría de Servidor, Una Auditoría de
Servidor necesita ser creada primero. Una especificación de Auditoría
depende de la Auditoría de Servidor y sólo puede haber una
Especificación de Auditoría por Servidor por cada Auditoría de Servidor.
Las especificaciones de Auditoría de Servidor le permiten auditar cosas
como inicios de sesión exitosos hecho al servidor, acciones DBCC, etc.
Esto también está disponible en todas la Ediciones de SQL Server de 2012
en adelante..
 Especificación de Auditoría de la Base de Datos (opcional)
La especificación de auditoría de la Base de Datos también depende de
la auditoría del servidor. Permite una auditoría más granular dentro de la
base de datos, incluyendo acciones realizadas en objetos específicos
como qué usuario realizó un SELECT en una tabla específica. Múltiples

especificaciones de auditoría de base de datos pueden ser enlazadas a
una sola Auditoría de Servidor.
La información grabada en los registros de transacciones puede ser leída

usando la función fn_get_audit_file, como se indica a continuación.
SELECT * FROM
fn_get_audit_file('D:\Audits\*',default,default)
Seguimiento de SQL
Actualmente, Seguimiento de SQL es aún el método preferido para realizar
auditoría en SQL Server, ha estado presente desde SQL 2000 y la mayoría de los
DBAs están familiarizados con él, o al menos con usar Profiler..
Seguimiento de SQL usa un conjunto de procedimientos almacenados que

graban eventos que han sido identificados en la definición de seguimiento. Los
seguimiento son altamente configurables y pueden lograr una auditoría muy
granular.
SQL Server provee Profiler como una interfaz para Seguimiento de SQL, lo cual
hace fácil crear seguimientos y correrlos. Desafortunadamente, Profiler viene
con algunos costos de desempeño y como tal no es siempre una buena idea
correrlo contra su servidor de producción.
Si usted necesita correr seguimientos contra su servidor de producción, hágalo

usando sentencias Transact-SQL para manera y correr los seguimientos. Los
siguientes son los procedimientos que pueden ser usados para crear y leer
información de seguimiento:
 sp_trace_create
Este procedimiento es usado para crear una definición de seguimiento.
Las opciones de seguimiento como sustitución incremental de archivos y
apagado del servidor, y la localización de los archivos de seguimiento
puede también ser especificado aquí.
 sp_trace_setevent
Este procedimiento es usado para definir qué eventos de seguimiento
desearía capturar y qué columnas de cada evento se grabarán.

 sp_trace_setstatus
Dado que todos los seguimiento son creado en un estado parado, este
procedimiento requiere iniciar el seguimiento y luego pararlo de nuevo.
Puede también ser usado para recomer completamente el seguimiento.
Una cosa a notar acerca de los seguimientos es que no son persistentes. Si su

instancia es reiniciada, el seguimiento no será recreado automáticamente.
Seguimiento de SQL será deprecado en futuras versiones de SQL Server y será

reemplazado con Eventos Extendidos.
Eventos Extendidos
Eventos extendidos fueron introducidos en SQL 2008, es un marco de trabajo
de eventos altamente configurable, que ultimadamente reemplazará a
Seguimiento de SQL. En SQL 3008, los eventos disponibles en el motor de
eventos extendidos eran limitados, pero en SQL Server 2012 todos los eventos
que están disponibles en Seguimiento de SQL, lo están también ahora en
Eventos Extendidos.
El motor de eventos extendidos tiene una carga en el desempeño muy baja, lo

cual lo hace preferible a Seguimiento de SQL. El motor sólo maneja los paquetes
que contienen la información del evento, haciéndolo extremadamente flexible.
También es posible correlacionar la fecha entre aplicaciones, SQl Server y
Windows usando Eventos Extendidos.
SQL Server 2012 también introduce una interfaz de usuario para eventos
extendidos, lo cual lo hace mucho más fácil usar sin tener que entender la
arquitectura interna del marco de trabajo de Eventos Extendidos. El asistente
de eventos extendidos puede ser encontrado debajo del nodo de
administración de su servidor.

El asistente le guiará a través de la creación de una nueva sesión usando una

plantilla existente o le ayudará a crear la suya propia seleccionando los eventos
y campos de eventos que requiere.
Alternativamente, usted puede usar Transact-SQL para crear seguimientos. Los

siguientes son tres comandos principales para crear y manejar Sesiones de
Eventos Extendidos:
 CREATE EVENT SESSION

Este comando crea una sesión de evento y le permite especificar los
eventos, acciones y objetivos que deberían ser asociados a la sesión.
Usted puede ver los eventos disponibles, las acciones y objetivos
seleccionando sys.dm_xe_objects con los tipos de objeto de evento,
acción y objetivo respectivamente.
 ALTER EVENT SESSION
Este comando es usado para modificar la configuración de sesiones de
evento y para iniciar o parar la sesión de evento.

 DROP EVENT SESSION
Este comando es usado para prescindir de una sesión de evento cuando
ya no es requerida.
Captura de Datos Modificados

Captura de Datos Modificados fue introducida en SQL Server en 2008. Esta
característica disponible sólo en la edición Enterprise provee información
prácticamente en tiempo real, con poco impacto en el desempeño, acerca de
cambios DML lo cuales pueden ser usados para propósitos de auditoría.
Esta característica recolecta el registro de transacciones de SQL Server como

parte del proceso de sp_replcmds, para cambios a datos en las tablas para las
cuales fue habilitada. CDC depende de SQL Server Agent, el cual debe estar
corriendo todo el tiempo para asegurar que la captura de datos toma lugar. Dos
trabajos son creados cuando CDC es implementado, uno es usado para capturar
los datos y poblar las respectivas tablas, y por otro lado es usado para realizar
la limpieza.
La captura de datos modificados puede ser habilitada en su base de datos y

tablas específicas, sin tener que hacer ningún cambio a los objetos en sí
mismos.
Los siguientes comandos pueden ser usados para implementar CDC:
 sys.sp_cdc_enable_db
Este comando habilita CDC para usarse en una base de datos específica,
y es requerido antes de que cualquier tabla pueda ser habilitada para
CDC.
 sys.sp_cdc_enable_table
Este comando habilita CDC en una tabla específica. Esto crea una
instancia de captura asociada de la tabla, incluyendo una tabla de
cambios y funciones de consulta. Las primeras 5 columnas en la tabla
contienen Metadatos a ser usados por el proceso CDC y el resto de las
columnas están basadas en las columnas en la tabla fuente a ser
capturada.

|
Los desencadenadores pueden ser usados para inicios de sesión o cambios a
objetos y datos dentro de su base de datos.
Los desencadenadores DML se activan en respuesta a sentencias INSER,

UPDATE y DELETE, mientras que los desencadenadores DDL se activan en
respuesta a cambios hechos a la definición de los datos como CREATE, DROP,
ALTER, etc. Los desencadenadores de Inicio de Sesión se activan cada vez que
un usuario ingresa a SQL Server, lo cual puede ser usado para auditar accesos a
su servidor. Desafortunadamente, el desencadenador no se activa si el usuario
no está autenticado, y como tal sólo será útil auditando inicios de sesión
exitosos.
Para usar desencadenadores DML para auditar cambios de datos, los

desencadenadores necesitarán ser añadidos a cada tabla que desea auditar.
Esto puede ser incómodo y difícil de mantener. Las aplicaciones desarrolladas
en SQL Server a menudo hacen uso de desencadenadores DML para auditoría
interna.
De la misma manera, los desencadenadores DDL pueden ser implementados

para grabar cualquier cambio a los objetos de la base de datos. Los
desencadenadores DDL son creados a nivel de la base de datos o el servidor y
se activan cuando el evento específicamente configurado ocurre.
 Las siguientes Sentencias Transact-SQL pueden ser usadas para crear o

mantener desencadenadores DML o DDL CREATE TRIGGER
Esta sentencia puede ser usada para crear un desencadenador ya sea
DML, DDL o de Inicio de Sesión. Cuando se crea un desencadenador DDL,
especificar el alcance del desencadenador como ON ALL SERVER u ON
DATABASE es requerido.
 ENABLE/DISABLE TRIGGER
Los desencadenadores son habilitados por defecto cuando son creados.
Estos comandos le ayudan a deshabilitar un desencadenador sin
removerlo de la base de datos y luego rehabilitarlo más tarde. Usted
también puede deshabilitar desencadenadores DML usando el comando
ALTER TABLE.

. Tema IV – SQL Server Tunning Advisor
Database Engine Tuning Advisor proporciona una interfaz gráfica de usuario

(GUI) basada en la forma de ver las sesiones de ajuste y los informes de
recomendaciones de ajuste. Esta lección le muestra cómo iniciar la herramienta
y cómo configurar la pantalla. Al final de esta lección, conocerá las diferentes
maneras en que puede iniciar la herramienta y cómo configurar su pantalla para
soportar las tareas de ajuste que realiza con regularidad.
Prerrequisitos
Para completar este tutorial, necesita SQL Server Management Studio, acceso
a un servidor que ejecuta SQL Server y una base de datos AdventureWorks.
 Instale SQL Server Management Studio.

 Instale SQL Server 2017 Developer Edition.
 Descargar las bases de datos de muestra AdventureWorks2017.
Iniciar el Asistente de ajuste de base de datos
Para comenzar, abra la interfaz gráfica de usuario (GUI) del Asistente para la
optimización de motor de base de datos (DTA). En el primer uso, un miembro
de la función de servidor fijo sysadmin debe iniciar el Asistente
para la optimización de motor de base de datos para inicializar la
aplicación. Después de la inicialización, los miembros de la función de base de
datos fija db_owner pueden usar el Asistente para la optimización de motor de
base de datos para ajustar las bases de datos que poseen.
1. Inicie SQL Server Management Studio (SSMS). En el menú Inicio

de Windows , seleccione Todos los programas y busque SQL Server
Management Studio .
2. Una vez que se abre SSMS, seleccione el menú Herramientas y
seleccione Asesor de ajuste de base de datos .

3. El Asistente para la optimización de la base de datos se inicia y abre

el cuadro de diálogo Conectar al servidor . Verifique la configuración
predeterminada y luego seleccione Conectar para conectarse a su
servidor SQL.
De forma predeterminada, el Asistente para la optimización de motor de base

de datos abre la configuración en la siguiente ilustración:

Dos paneles principales se muestran en la GUI del Asistente para la optimización

de motor de base de datos cuando se abre por primera vez.
 El panel izquierdo contiene el Monitor de sesión, que enumera todas las

sesiones de ajuste que se han realizado en esta instancia de Microsoft
SQL Server. Cuando abre Database Engine Tuning Advisor, muestra una
nueva sesión en la parte superior del panel. Puede nombrar esta sesión
en el panel adyacente. Inicialmente, solo se enumera una sesión
predeterminada. Esta es la sesión predeterminada que crea
automáticamente el Asistente para la optimización de motor de base de
datos. Después de haber optimizado las bases de datos, todas las
sesiones de optimización de la instancia de SQL Server a la que está
conectado se enumeran debajo de la nueva sesión. Puede hacer clic con
el botón derecho en una sesión de ajuste para cambiarle el nombre,
cerrarla, eliminarla o clonarla. Si hace clic con el botón derecho en la lista,

puede ordenar las sesiones por nombre, estado o tiempo de creación, o
crear una nueva sesión. En la sección inferior de este panel, se muestran
los detalles de la sesión de ajuste seleccionada. Botón categorizado, o
puede mostrarlos en una lista alfabética usando
el botón Alfabético. También puede ocultar el Monitor de sesión
arrastrando el borde del panel derecho hacia el lado izquierdo de la
ventana. Para volver a verlo, arrastre el borde del panel hacia la
derecha. El Monitor de sesión le permite ver sesiones de ajuste
anteriores o usarlas para crear nuevas sesiones con definiciones
similares. También puede usar el Monitor de sesión para evaluar las
recomendaciones de ajuste. Para obtener más información.
 El panel derecho contiene las pestañas General y las Opciones de
ajuste. Aquí es donde puede definir su sesión de optimización del motor
de base de datos. En la pestaña General , escriba el nombre de su sesión
de ajuste, especifique el archivo de carga de trabajo o la tabla que desea
usar, y seleccione las bases de datos y las tablas que desea ajustar en esta
sesión. Una carga de trabajo es un conjunto de instrucciones Transact-
SQL que se ejecutan contra una base de datos o bases de datos que desea
ajustar. Database Engine Tuning Advisor utiliza archivos de seguimiento,
tablas de seguimiento, scripts Transact-SQL o archivos XML como
entrada de carga de trabajo cuando se ajustan las bases de datos. En
las opciones de ajuste En la pestaña, puede seleccionar las estructuras
físicas de diseño de la base de datos (índices o vistas indizadas) y la
estrategia de partición que desea que el Asesor de optimización de motor
de base de datos tenga en cuenta durante su análisis. En esta pestaña,
también puede especificar el tiempo máximo que tarda el Asistente para
la optimización de motor de base de datos en ajustar una carga de
trabajo. De forma predeterminada, Database Engine Tuning Advisor
ajustará una carga de trabajo durante una hora.

Material Administracion de Bases de Datos

Caricato da

Informazioni sul documento

Titolo originale

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

Material Administracion de Bases de Datos

Caricato da

Copyright:

Formati disponibili

Administración de Bases de Datos

Ing. Rusbel Alcántara Rodríguez

Ing. Rusbel Alcántara Rodríguez

Los problemas severos de desempeño requieren acciones y resoluciones

Eso no significa que cada ralentización de SQL Server es un problema de

Ing. Rusbel Alcántara Rodríguez

Los cuellos de botella de CPU son causados por recursos de hardware

Los cuellos de botella de memoria pueden resultar en un tiempo de respuesta

Los cuellos de botella de red pueden no ser reconocidos inmediatamente, ya

Ing. Rusbel Alcántara Rodríguez

Causas comunes de problemas de desempeño

Los cuellos de botella de memoria son causados por limitaciones en la memoria

Qué métricas monitorear

Ing. Rusbel Alcántara Rodríguez

select * from sys.dm_os_performance_counters

where counter_name in ('Batch Requests/sec', 'SQL Compilations/sec' , 'SQL

DECLARE @BatchRequests BIGINT;

SELECT @BatchRequests = cntr_value FROM

WAITFOR DELAY '00:00:10';

SELECT (cntr_value - @BatchRequests) / 10 AS 'Batch

Para problemas de memoria, monitoree el contador de desempeño Memory

Ing. Rusbel Alcántara Rodríguez

Otro contador a monitorear es Pages/sec, está disponible en Performance

Checkpoint pages/sec y Lazy writes/sec indicant si páginas sucias son enviadas

Si el valor de Lazy Writes/sec está constantemente encima del umbral, revise el

Buffer Cache Hit Ratio muestra la proporción de páginas de datos encontradas

Ing. Rusbel Alcántara Rodríguez

La resolución de problemas de red debería comenzar encontrando consultas,

Para problemas de I/O, monitoree los contadores relacionados con el

Average Disk Queue Length muestra el número promedio de operaciones I/O

Average Disk Sec/Read muestra el tiempo promedio en segundos necesarios

Average Disk Sec/Write muestra el tiempo promedio en segundos necesario

Average Disk Reads/Sec y Average Disk Writes/Sec muestran el ritmo de

Ing. Rusbel Alcántara Rodríguez

Ajuste del rendimiento de la base de datos de

Cómo hacer ajuste de rendimiento en SQL

Usted es un desarrollador, DBA o administrador de sistemas atascado con las

 Mida qué tan rápido va el servidor ahora.

Finalmente, si tiene que comprar nuevos servidores, obtenga una lista de

Ing. Rusbel Alcántara Rodríguez

1. Medir el rendimiento del servidor

 sp_BlitzFirst® : esta herramienta gratuita es como el velocímetro de SQL

2. Cómo optimizar consultas SQL

 Para encontrar sus consultas generales de larga duración, use el script

Ing. Rusbel Alcántara Rodríguez

3. Cómo hacer la optimización del

 sp_BlitzIndex® : ejecútelo en su base de datos para obtener una prueba

Ing. Rusbel Alcántara Rodríguez

4. Ajustes de Performance Tune SQL

 Ejecute sp_Blitz® en el servidor. Es un chequeo de salud gratuito que

Ing. Rusbel Alcántara Rodríguez

6. Construcción y prueba de carga de

Ing. Rusbel Alcántara Rodríguez

SQL Server Profiler

El SQL Server Profiler es una herramienta de monitoreo que se puede utilizar

Además de las acciones para la auditoría que se producen en una instancia de

Para iniciar el analizador del SQL Server:

1. Abrir: Inicio, todos los programas (Windows + C para Windows 8)

3. Abra SQL Server Management Studio

5. Abra el símbolo del sistema

Ing. Rusbel Alcántara Rodríguez

Para crear un nuevo rastreo:

1. En el SQL Server Profiler, abra archivo en el menú