Download Guía de referencia de Fast Track Data Warehouse para

Guía de referencia de Fast Track Data Warehouse para SQL Server 2012
Artículo técnico de SQL Server
Autores: Eric Kraemer, Mike Bassett, Eric Lemoine, Dave Withers
Revisores técnicos: Claude Lorenson, Susan Price, Ralph Kemperdick, Henk van der Valk,
Alexi Khalyako, Oliver Chiu
Fecha de publicación: marzo de 2012
Se aplica a: SQL Server 2012
Resumen: en este documento se define un modelo de configuración de referencia
(denominado Fast Track Data Warehouse) que usa un enfoque de recursos equilibrados
para implementar una arquitectura de sistema de base de datos de SQL Server basada en
multiproceso simétrico (SMP) con rendimiento y escalabilidad probados para cargas de trabajo
de almacenamiento de datos. El objetivo de una arquitectura de referencia Fast Track Data
Warehouse es lograr un equilibrio de recursos eficiente entre la capacidad de procesamiento
de datos de SQL Server y el rendimiento de hardware de los componentes.
Copyright
Este documento se proporciona "tal cual". La información y los puntos de vista que se proporcionan en
este documento, incluidas las direcciones URL y otras referencias a sitios web de Internet, pueden sufrir
modificaciones sin previo aviso. Usted acepta el riesgo de utilizarlo.
En este documento no se proporciona ningún derecho legal sobre ninguna propiedad intelectual de
ningún producto de Microsoft. Puede copiar y utilizar este documento para su propia referencia.
© 2012 Microsoft. Todos los derechos reservados.
2
Contenido
Historial de cambios de FTDW ...................................................................................................................... 6
Introducción .................................................................................................................................................. 6
Audiencia .................................................................................................................................................. 6
Fast Track Data Warehouse .......................................................................................................................... 6
Fast Track .................................................................................................................................................. 7
Propuesta de valor .................................................................................................................................... 7
Metodología .................................................................................................................................................. 7
Arquitectura de componentes holística ................................................................................................... 7
Enfoque optimizado de carga de trabajo.................................................................................................. 8
Configuraciones de referencia de SQL Server Fast Track validadas ......................................................... 9
Resumen ................................................................................................................................................... 9
Carga de trabajo de FTDW ............................................................................................................................ 9
Patrones de cargas de trabajo de almacenamiento de datos .................................................................. 9
Evaluación de las cargas de trabajo ........................................................................................................ 10
Atributos cualitativos de cargas de trabajo de almacenamiento de datos ............................................ 12
Elegir una configuración de referencia de FTDW ....................................................................................... 14
Opción 1: evaluación básica .................................................................................................................... 14
Paso 1: evaluar el caso de uso del cliente ............................................................................................... 14
Paso 2: elegir una arquitectura de referencia de FTDW publicada .................................................... 15
Opción 2: evaluación completa............................................................................................................... 16
Información general acerca del proceso............................................................................................. 16
Paso 1: evaluar el caso de uso del cliente ........................................................................................... 16
Paso 2: establecer métricas de evaluación ......................................................................................... 17
Paso 3: elegir una arquitectura de referencia de Fast Track Data Warehouse .................................. 18
Opción 3: arquitecturas de referencia definidas por el usuario ............................................................. 18
Paso 1: definir la carga de trabajo ...................................................................................................... 18
Paso 2: establecer simulaciones de la arquitectura de componentes ............................................... 18
Resumen de la elección de una FTRA ..................................................................................................... 19
3
Configuración estándar de FTDW ............................................................................................................... 20
Arquitectura de los componentes de hardware ..................................................................................... 20
Requisitos y configuración de componentes ...................................................................................... 20
Configuración de la aplicación ................................................................................................................ 22
Windows Server 2008 R2 .................................................................................................................... 22
SQL Server 2012 Enterprise ................................................................................................................ 23
Sistema de almacenamiento ............................................................................................................... 24
Prácticas recomendadas de SQL Server para FTDW ................................................................................... 29
Arquitectura de datos ............................................................................................................................. 29
Estructura de tabla .............................................................................................................................. 29
Particionamiento de tablas ................................................................................................................. 31
Indización ............................................................................................................................................ 32
Índices de almacén de columnas optimizados en memoria xVelocity ............................................... 32
Estadísticas de base de datos ............................................................................................................. 34
Compresión ......................................................................................................................................... 35
Administrar la fragmentación de datos .................................................................................................. 35
Fragmentación del sistema de archivos.............................................................................................. 35
Varios grupos de archivos ................................................................................................................... 38
Cargar datos ............................................................................................................................................ 38
Cargas incrementales .......................................................................................................................... 38
Migración de datos ............................................................................................................................. 41
Simulaciones y validación ........................................................................................................................... 43
Realizar la validación de línea base de FTDW ......................................................................................... 44
Pruebas de línea base con SQLIO ........................................................................................................ 44
Realizar simulaciones de base de datos de Fast Track ........................................................................... 47
Calcular MCR ....................................................................................................................................... 48
Calcular BCR ........................................................................................................................................ 49
Arquitecturas publicadas de referencia de FTDW ...................................................................................... 52
Conclusión ................................................................................................................................................... 52
4
Apéndice ..................................................................................................................................................... 54
Herramienta de ajuste de tamaño de FTDW .......................................................................................... 54
Validar una FTRA definida por el usuario................................................................................................ 54
Prueba de E/S sintética ....................................................................................................................... 54
Generar archivos de prueba con SQLIO .............................................................................................. 54
Prueba de cargas de trabajo ................................................................................................................... 57
Medir el valor MCR para el servidor (opcional) .................................................................................. 57
Medir el valor BCR para la carga de trabajo ....................................................................................... 57
Factores que afectan a la tasa de consumo de las consultas ............................................................. 62
5
Historial de cambios de FTDW
En la tabla siguiente se proporciona una lista de los cambios o las actualizaciones importantes
realizados en las distintas versiones de la Guía de referencia de Fast Track Data Warehouse.
Descripción
Versión
Nuevo en SQL
Server 2012
4.0
Nuevo en SQL
Server 2012
Nuevo en SQL
Server 2012
Nuevo en SQL
Server 2012
Nota
Vínculos a otros documentos
de prácticas recomendadas de
SQL Server
Ubicación
4.0
Simulaciones y validación
Precaución
4.0
Requisitos de memoria
RAM
4.0
Nuevo en SQL
4.0
Server 2012
Nuevo en SQL
4.0
Server 2012
Nuevo en SQL
4.0
Server 2012
Tabla 1: historial de cambios
Índices de almacén de
columnas optimizados en
memoria xVelocity
Almacenamiento de estado
sólido
Validación e índices de
almacén de columnas
Validación de E/S de línea base
Importante
Índices de almacén de
columnas
Estado sólido
Validación
SQLIO
Introducción
En este documento se definen la arquitectura de componentes y la metodología empleadas
para el programa Fast Track Data Warehouse (FTDW) de SQL Server. El resultado de este
enfoque es la validación de una arquitectura mínima del sistema de base de datos de Microsoft
SQL Server, incluido el software y el hardware, necesaria para lograr y mantener una línea
base de rendimiento inmediato para muchas cargas de trabajo de almacenamiento de datos.
Audiencia
La audiencia objetivo de este documento abarca planeadores de TI, arquitectos, DBA y usuarios
de Business Intelligence (BI) interesados en elegir arquitecturas del sistema probadas estándar
para cargas de trabajo de SQL Server conformes a FTDW.
Fast Track Data Warehouse
La iniciativa Fast Track Data Warehous de SQL Server proporciona una metodología básica
y ejemplos concretos para la implementación de una configuración equilibrada de hardware
y base de datos para una carga de trabajo de almacenamiento de datos. Para obtener más
información, vea la sección Carga de trabajo de FTDW de este documento.
6
El equilibrio es una medida de los componentes clave del sistema de una instalación de SQL
Server: almacenamiento, servidor, red de almacenamiento, base de datos y sistema operativo.
Cada uno de estos componentes tiene una configuración optimizada. El objetivo es lograr un
equilibrio eficiente inmediato entre la capacidad de procesamiento de datos de SQL Server
y los recursos de los componentes de hardware. Idealmente, la configuración debe incluir el
hardware del sistema mínimo para satisfacer los requisitos de almacenamiento y rendimiento
para una carga de trabajo de almacenamiento de datos.
Fast Track
La marca SQL Server Fast Track identifica una configuración de hardware de componentes
conforme a los principios de la arquitectura de referencia FTDW (FTRA). Cada FTRA está
definida por una carga de trabajo y un conjunto básico de prácticas recomendadas de
configuración, validación y base de datos. A continuación se enumeran los principios clave del
programa Fast Track:



Simulaciones específicas de la carga de trabajo. El diseño y la configuración del sistema
se basan en cargas de trabajo de consulta simultáneas reales.
Especificaciones detalladas y validadas de los componentes de hardware.
Equilibrio de la arquitectura de componentes entre la capacidad de base de datos y los
recursos de hardware principales.
Propuesta de valor
Los principios siguientes constituyen la base de la propuesta de valor de FTDW:



Equilibrio predeterminado entre los componentes clave del sistema. Esto reduce el
riesgo de derrochar recursos de CPU o de almacenamiento que nunca se percibirán en
el nivel de aplicación.
Rendimiento predecible inmediato. Las configuraciones de Fast Track ya coinciden
con las capacidades de la aplicación de SQL Server para un servidor y una carga de
trabajo seleccionados.
Centrado en la carga de trabajo. En lugar de tratarse de un método único para la
configuración de bases de datos, el enfoque de FTDW se alinea específicamente con
un caso de uso de almacenamiento de datos.
Metodología
Arquitectura de componentes holística
Las arquitecturas de referencia de FTDW de SQL Server proporcionan un marco práctico para
equilibrar las complejas relaciones existentes entre los componentes clave de la arquitectura
del sistema de base de datos. La arquitectura de componentes, que se denomina
genéricamente pila, se muestra en la ilustración 1.
7
Ilustración 1: arquitectura de componentes de base de datos Fast Track de ejemplo
Cada componente de la pila es un eslabón de una cadena de operaciones necesarias para
procesar datos en SQL Server. La evaluación de la pila como un sistema integrado hace
posible una simulación que establece el ancho de banda real para cada componente. Esto
garantiza que los componentes individuales proporcionen suficiente rendimiento para las
capacidades de la aplicación de SQL Server para la pila prescrita.
Enfoque optimizado de carga de trabajo
Las diferentes cargas de trabajo de una aplicación de base de datos pueden necesitar
arquitecturas de componentes muy distintas para alcanzar un equilibrio óptimo de los recursos.
Un ejemplo clásico de esto puede ser el contraste entre las cargas de trabajo de procesamiento
de transacciones en línea (OLTP) con solicitudes pequeñas basadas en búsquedas y el
almacenamiento de datos analíticos con solicitudes grandes y muchos recorridos. Los casos de
uso de OLTP están muy indizados para admitir la recuperación con baja latencia de un número
reducido de filas de conjuntos de datos que suelen tener poco volumen de datos históricos.
Estos tipos de operaciones de base de datos inducen un movimiento significativo de los
cabezales de disco y generan los clásicos patrones aleatorios de recorrido de E/S. Los casos
de uso analíticos, como el almacenamiento de datos, pueden implicar solicitudes de datos
mucho mayores y beneficiarse en gran medida del mayor rendimiento total potencial de los
exámenes de disco secuenciales.
8
Para estos casos de uso opuestos, las implicaciones de una pila de componentes equilibrada
son significativas. Los intervalos de exploración aleatoria de E/S por disco promedio de las
unidades de disco SAS modernas pueden ser 10 veces más lentos en comparación con los
intervalos de exploración secuencial para el mismo hardware. Con las cargas de trabajo de
Fast Track Data Warehouse se pone énfasis en conseguir intervalos de exploración de E/S
coherentemente elevados (medidos en MB/s) en lugar del enfoque más tradicional de las
operaciones por segundo (medidas en IOPS).
Para afrontar el desafío que suponen las cargas de trabajo muy diferentes se deben definir
claramente los atributos de las cargas de trabajo cliente. Las cargas de trabajo de SQL Server
Fast Track constan de una lista cualitativa de atributos que definen de forma única un caso de
uso común de la aplicación de base de datos. Además, cada carga de trabajo se representa
mediante medidas cuantitativas entre las que se incluyen consultas de simulación estándar.
Se usan simulaciones específicas de la carga de trabajo para validar la configuración de la base
de datos, las prácticas recomendadas y las recomendaciones de hardware de componentes.
Configuraciones de referencia de SQL Server Fast Track validadas
Todas las arquitecturas de referencia de Fast Track publicadas se validan como conformes al
conjunto de principios y las instrucciones que se proporcionan en esta guía de referencia.
En secciones posteriores de este documento se incluyen ejemplos de este proceso.
Resumen
La especificación FTDW de SQL Server descrita en esta guía de referencia está centrada en
las cargas de trabajo y el equilibrio de los componentes. Este enfoque confirma que el
aprovisionamiento único puede resultar ineficiente y costoso para muchos casos de uso de
base de datos. Los requisitos empresariales cada vez más complejos unidos a volúmenes de
datos que cambian rápidamente exigen un enfoque más realista. Al presentar una combinación
de arquitecturas preceptivas de referencia, simulación de componentes de hardware y
software, y cargas de trabajo claramente dirigidas, este documento proporciona un enfoque
práctico para lograr arquitecturas de componentes equilibradas.
Carga de trabajo de FTDW
Patrones de cargas de trabajo de almacenamiento de datos
Las preguntas que se suelen realizar a los almacenamientos de datos necesitan acceso
a grandes volúmenes de datos. Los almacenamientos de datos necesitan admitir una amplia
variedad de consultas de una audiencia extensa (por ejemplo: finanzas, marketing, operaciones
y equipos de investigación).
9
Para superar las limitaciones de los sistemas de almacenamiento de datos tradicionales, las
organizaciones han recurrido a emplear técnicas de optimización RDBMS tradicionales como
la generación de índices, el agregado previo de datos y la restricción del acceso a los niveles
inferiores de datos. Las sobrecargas de mantenimiento asociadas a estos métodos pueden
abrumar a menudo incluso a las ventanas de lotes generosas. A medida que un almacenamiento
de datos se vuelve más maduro y crece la audiencia, cada vez resulta más desafiante admitir
estas optimizaciones específicas del caso de uso, especialmente en el caso de datos o de
correcciones de datos a última hora.
Una solución frecuente para este desafío consiste en agregar simplemente unidades; no es
raro ver centenares de discos para un almacenamiento de datos relativamente pequeño en un
intento por superar las limitaciones de rendimiento de E/S de asignar una infraestructura de E/S
basada en búsquedas a una carga de trabajo basada en recorridos. Esto se suele ver en grandes
entornos de red de área de almacenamiento (SAN) compartidos que están optimizados
tradicionalmente para las búsquedas. Muchos patrones y técnicas de referencia de E/S de
almacenamiento que fomentan el acceso aleatorio de E/S introducen latencia de disco
y reducen el rendimiento total del subsistema de almacenamiento para una carga de trabajo
de almacenamiento de datos que realiza muchos recorridos.
Fast Track Data Warehouse es una forma diferente de optimizar cargas de trabajo de
almacenamiento de datos. Al alinear los archivos de base de datos y la configuración con un
acceso eficiente de examen disco (en lugar de búsqueda), el rendimiento que se consigue en
los discos individuales puede ser muy superior. El aumento resultante del rendimiento por disco
reduce el número de discos necesarios para generar suficiente rendimiento de E/S como para
satisfacer la capacidad de SQL Server para procesar los datos de una carga de trabajo concreta.
Además, puede evitar algunas técnicas de optimización basadas en índices empleadas para
mejorar las búsquedas en disco.
Evaluación de las cargas de trabajo
A la hora de analizar las cargas de trabajo para sistemas basados en FTDW es importante
tener en cuenta su adecuación a las prácticas y las configuraciones del sistema descritas en
este documento. Los requisitos de almacenamiento de datos pueden variar según el cliente
y ciertos requisitos, como la replicación de bases de datos, quizás no sean adecuados para
todos los sistemas diseñados según FTDW. A continuación se enumeran los criterios iniciales
clave para este tipo de evaluación de cargas de trabajo.
Muchos recorridos
Las consultas de una carga de trabajo de almacenamiento de datos suelen recorrer un gran
número de filas. Por esta razón, el rendimiento de examen de disco se convierte en una
prioridad cada vez mayor, a diferencia de lo que ocurre con las cargas de trabajo transaccionales
que ponen el acento en el tiempo de búsqueda en disco. La arquitectura de referencia de
FTDW optimiza el hardware y los componentes de software de la base de datos, siendo el
rendimiento de examen del disco su prioridad clave. Esto puede dar como resultado lecturas
secuenciales de disco más eficientes y un aumento correlacionado en el rendimiento de E/S
de disco por unidad.
10
No volátil
Una vez escritos los datos, no suelen cambiar. Las operaciones DML, como la actualización de
SQL, que mueven páginas asociadas a la misma tabla de base de datos y hacen que no sean
contiguas deben administrarse con sumo cuidado. Las cargas de trabajo que presentan con
frecuencia esa volatilidad no suelen ser idóneas para FTDW. Cuando se produce volatilidad,
se recomienda realizar un mantenimiento periódico para reducir al mínimo la fragmentación.
Pocos índices
Al agregar índices no clúster se suele agregar rendimiento en las búsquedas de uno o pocos
registros. Si se aplican índices no clúster a tablas en las que se van a recuperar un gran número
de filas, el aumento resultante de las operaciones aleatorias de búsqueda en disco puede reducir
el rendimiento global del sistema. El mantenimiento de índices puede agregar también una
sobrecarga de administración de datos significativa, lo que puede poner en riesgo el contrato
de nivel de servicio (SLA) y la posibilidad de cumplir las ventanas de carga de base de datos.
Por el contrario, los intervalos de exploración secuencial pueden ser mucho mayores (10 veces
o más) que las frecuencias de acceso aleatorio. Un sistema que reduce al mínimo el uso de
búsquedas aleatorias, induciendo índices secundarios, suele tener unas velocidades de E/S
promedio sostenidas mucho mayores. Esto significa un uso más eficiente de los recursos de
E/S de almacenamiento y un rendimiento más predecible para las consultas grandes de tipo
recorrido.
La metodología de FTDW prescribe técnicas de optimización de base de datos que se alinean
con las características de la carga de trabajo de destino. El índice clúster y la creación de
particiones por rangos son ejemplos de estructuras de datos que admiten E/S de disco eficiente
basada en examen, y se recomienda su uso como las herramientas principales para la optimización
basada en la arquitectura de datos para los entornos de FTDW.
Particiones alineadas
Una rasgo común de las cargas de trabajo de FTDW es la capacidad de aprovechar la creación
de particiones de SQL Server. Las particiones pueden simplificar la administración del ciclo de
vida de los datos y ayudar a minimizar la fragmentación con el tiempo. Además, los patrones de
consulta para exámenes grandes pueden aprovechar la partición por rangos y reducir
considerablemente el tamaño de los recorridos de tabla sin sacrificar la fragmentación o el
rendimiento de E/S de disco.
11
Consideraciones adicionales
Se deben tener en cuenta las consideraciones adicionales siguientes durante la evaluación de
una carga de trabajo de base de datos:



La implementación y la administración de una estrategia de optimización de base de
datos con pocos índices es un requisito fundamental para las cargas de trabajo de FTDW.
Se da por supuesto que se mantendrá una fragmentación mínima de los datos dentro
del almacenamiento de datos. Esto implica lo siguiente:
o El tipo de fragmentación más preocupante se puede medir en términos de
tamaño del fragmento. Un fragmento representa asignaciones contiguas de
páginas de base de datos de 8K.
o La ampliación del servidor agregando almacenamiento requiere volver a rellenar
todas las tablas sensibles para el rendimiento de manera coherente con las
instrucciones proporcionadas en este documento.
o La implementación de estructuras de datos volátiles, como tablas con una actividad
normal de actualización de nivel de fila, puede necesitar mantenimiento frecuente
(como desfragmentación o regeneración de los índices) para reducir la fragmentación.
o La carga de tablas de índices clúster con lotes de identificadores de clave del
clúster que se superponen a rangos existentes es un origen frecuente de
fragmentación. Todo esto se debe supervisar y administrar cuidadosamente de
acuerdo con las prácticas recomendadas incluidas en esta guía de referencia.
El almacenamiento de datos puede significar muchas cosas para audiencias distintas.
Deberá extremar la precaución al evaluar los requisitos de los clientes con los atributos
de cargas de trabajo de FTDW.
Atributos cualitativos de cargas de trabajo de almacenamiento de datos
Puede definir la carga de trabajo de FTDW mediante las propiedades de las siguientes áreas
temáticas relacionadas con las operaciones de base de datos:




Requisitos de usuario y patrón de acceso
Modelo de datos
Arquitectura de datos
Optimización de base de datos
En la tabla siguiente se resumen los atributos de carga de trabajo de almacenamiento de datos y se
ofrece una comparación con una carga de trabajo OLTP o de almacén de datos operativo (ODS).
Atributo
Descripción del
caso de uso
12
Afinidad de carga de trabajo:
Almacenamiento de datos
 Principalmente lectura (90 %-10 %)
 Actualizaciones limitadas
normalmente a los requisitos de
calidad de datos
 Grandes cantidades de
inserciones masivas
OLTP/ODS
 Proporción equilibrada de lectura
y actualización (60 %-40 %)
 Rendimiento de consultas
simultáneas caracterizado por
las necesidades operativas
Atributo
Modelo de datos
Afinidad de carga de trabajo:
Almacenamiento de datos
 Simultaneidad de consulta global
de media a baja; solicitud
máxima de consultas
simultáneas de 10-30
 Rendimiento de consultas
simultáneas caracterizado por las
necesidades de análisis e informes
 Recorridos y/o agregaciones de
largo alcance
 Consultas complejas (filtro,
combinación, agrupación,
agregación)

OLTP/ODS
 Inserciones y actualizaciones
específicas
 Alto rendimiento de
transacciones (por ejemplo,
varias decenas de K/s)
 Simultaneidad de usuario global
de media a alta; solicitud
máxima de consultas simultáneas
de 50-100 o más
 Transacciones normalmente
muy cortas (por ejemplo,
búsquedas mínimas de filas
discretas)
 Modelo de datos operativo muy
normalizado
 Desnormalización frecuente
como ayuda para la toma de
decisiones; búsquedas
discretas de latencia baja y alta
simultaneidad
 Retención de datos históricos
limitada
 Modelos de datos
desnormalizados extraídos de
otros sistemas de origen como
apoyo a la toma de decisiones
de eventos operativos
Modelo de almacenamiento de
datos centralizado muy
normalizado
 La desnormalización como apoyo
a los requisitos de informes suele
provenir de aplicaciones de BI
como SQL Server Analysis Services
 Estructuras de datos
dimensionales hospedadas en la
base de datos con grandes
cantidades de solicitudes
analíticas y simultaneidad
relativamente baja
 Los recorridos de largo alcance
son frecuentes
 Casos de uso analíticos ad-hoc
Arquitectura de
 Uso importante de estructuras de  Uso mínimo de estructuras de
datos
tabla del montón
tabla del montón
 Tablas con particiones grandes
 Estructuras de tabla de índices
con índices clúster que admiten
clúster que admiten búsquedas
recorridos de alcance limitado
de registros detallados
(de 1 a pocas filas por solicitud)
 Tablas de hechos muy grandes
 Tablas de hechos menores (por
(por ejemplo, de centenares de
gigabytes a varios terabytes)
ejemplo, menos de 100 GB)
 Tamaños de datos muy grandes
 Tamaños de datos
(por ejemplo, de centenares de
relativamente pequeños
terabytes a un petabyte)
(por ejemplo, algunos terabytes)
Optimización de
 Uso mínimo de índices
 Uso intensivo de optimización
base de datos
secundarios (descrito
de índices secundarios
anteriormente como pocos índices)
 La creación de particiones es
frecuente
Tabla 2: atributos de cargas de trabajo de almacenamiento de datos
13
Elegir una configuración de referencia de FTDW
Hay tres enfoques generales para usar la metodología de FTDW descrita en este documento.
Los dos primeros son específicos del uso de arquitecturas de referencia publicadas conformes
a Fast Track para el almacenamiento de datos. Estos enfoques permiten la selección de sistemas
prediseñados publicados como parte del programa FTDW. El tercer enfoque trata la metodología
básica de Fast Track como guía para la creación de un sistema de almacenamiento de datos
definido por el usuario. Para este último enfoque es necesario generar perfiles de cargas de
trabajo detallados y realizar simulaciones del sistema antes de la compra o la implementación.
Requiere conocimientos técnicos profundos en las áreas de configuración de almacenamiento
y servidores empresariales, y de la optimización de bases de datos de SQL Server.
Opción 1: evaluación básica
En este escenario, el cliente ya ha elegido una configuración de referencia de FTDW o dispone de
métodos alternativos para determinar los requisitos de servidor y de CPU. Si emplea esta opción, no
es necesario realizar una evaluación completa de la plataforma (es decir, una prueba de concepto).
Paso 1: evaluar el caso de uso del cliente
Las configuraciones de referencia de Fast Track Data Warehouse no son configuraciones
únicas de software y hardware. En su lugar, se configuran específicamente para las características
de una carga de trabajo de almacenamiento de datos. El primer paso para elegir una configuración
consiste en identificar estas características; empiece por examinar las áreas clave de los requisitos
del cliente y sus patrones de uso.
Carga de trabajo
Las definiciones de carga de trabajo de FTDW proporcionan dos puntos clave para la evaluación
de casos de uso. El primero es un conjunto de principios básicos que definen los elementos clave
de la carga de trabajo respecto al rendimiento de SQL Server. Estos principios se deben medir
minuciosamente para un caso de uso determinado porque la existencia de conflictos puede indicar
que una carga de trabajo de destino no es adecuada para una arquitectura de referencia de FTDW.
El segundo componente de una carga de trabajo es una descripción general del caso de uso
previsto. Esto proporciona una descripción general útil del caso de uso y constituye un punto de
partida razonable para evaluar la idoneidad de la carga de trabajo.
Evaluación de las cargas de trabajo
En la lista siguiente se describe un proceso básico para la evaluación de cargas de trabajo de
cliente. Se trata de una evaluación cualitativa y debe considerarse una indicación:
1. Defina los requisitos de la carga de trabajo de destino. Compare y contraste con los
atributos de carga de trabajo de FTDW. Para obtener más información, vea la sección
Carga de trabajo de FTDW de este documento.
2. Evalúe las prácticas recomendadas de FTDW. Se deben evaluar las prácticas
relacionadas con la administración de bases de datos y la optimización de la arquitectura
de datos y del sistema para el caso de uso y el entorno operativo de destino.
14
Tomar una decisión
El objetivo de esta evaluación de cargas de trabajo es asegurarse de que se puede tomar una
decisión totalmente informada cuando se elige una arquitectura de referencia de FTDW
validada. En realidad, la mayoría de los escenarios de almacenamiento de datos representan
una combinación de atributos conformes y en conflicto con respecto a la carga de trabajo de
FTDW. Aquí se enumeran los atributos de carga de trabajo de alta prioridad con una fuerte
afinidad para las configuraciones de referencia de Fast Track; se deben evaluar cuidadosamente
los casos de uso de cliente principales que entran en conflicto directamente con cualquiera de
estos atributos porque pueden invalidar la metodología para el caso de uso.
Carga de trabajo
Los siguientes atributos de carga de trabajo tienen alta prioridad:



Las cargas de trabajo críticas presentan patrones de acceso a datos con muchos
recorridos (es decir, los que pueden beneficiarse de la colocación secuencial de datos).
En general, las solicitudes de consulta individuales implican la lectura de decenas de
miles a millones (o más) de filas.
Alta capacidad de datos y baja simultaneidad con respecto a las cargas de trabajo
OLTP comunes.
Baja volatilidad de los datos. Las actividades DML frecuentes de actualización y eliminación
se deben restringir a un pequeño porcentaje del almacenamiento de datos total.
Administración de bases de datos
Esto incluye prácticas de administración de bases de datos, arquitectura de datos (modelo de
datos y estructura de tablas) e integración de datos:



Arquitectura de datos con particiones y pocos índices.
Administración cuidadosa de la fragmentación de la base de datos mediante estrategias
adecuadas de carga y ETL, y mantenimiento periódico.
Requisitos predecibles de crecimiento de los datos. Los sistemas FTDW están
preparados para una capacidad totalmente equilibrada. La ampliación del
almacenamiento requiere la migración de datos.
Paso 2: elegir una arquitectura de referencia de FTDW publicada
Un cliente puede tener en mente un servidor al realizar una evaluación simple basada en el
presupuesto o la experiencia. O bien, el cliente puede tener previamente una idea de la
capacidad de carga de trabajo o de un sistema existente en el que basar el análisis de los
requisitos de ancho de banda. En cualquier caso, no realice una evaluación completa de la
plataforma en una evaluación básica de FTDW. En su lugar, debe seleccionar una
configuración de FTDW conforme que satisfaga los requisitos estimados del cliente.
15
Opción 2: evaluación completa
Las arquitecturas de referencia conformes a Fast Track proporcionen configuraciones de
componentes de hardware acordes con las cargas de trabajo definidas por el cliente. La
metodología siguiente permite un enfoque optimizado para elegir una arquitectura de componentes
de base de datos que garantice el mejor equilibrio entre los requisitos, el rendimiento y la
escalabilidad de los casos de uso. En este enfoque se da por supuesto que se tienen
conocimientos profundos de la arquitectura del sistema de base de datos y la implementación
de almacenamiento de datos. En este proceso suelen participar asociados de Fast Track
y recursos técnicos de ventas de Microsoft.
Información general acerca del proceso
El flujo de proceso siguiente resume el proceso de selección de la evaluación completa de FTDW:
1. Evaluar los atributos de carga de trabajo de Fast Track según el escenario de uso
de destino.
2. Identificar los requisitos de servidor y/o de ancho de banda para el caso de uso del
cliente. Se debe elegir una configuración de referencia de FTDW publicada antes de
comenzar una evaluación.
3. Identificar una consulta que sea representativa del requisito de carga de trabajo del
cliente.
4. Calcular la Tasa de consumo de simulación (BCR) de SQL Server para la consulta.
5. Calcular la Capacidad de datos de usuario (UDC) necesaria.
6. Comparar las tasas de BCR y UDC con la Tasa máxima de consumo de CPU (MCR)
y las tasas de Capacidad publicadas de las arquitecturas de referencia de Fast Track
conformes.
A continuación se describen en detalle los puntos individuales del flujo de proceso de
evaluación completa.
Paso 1: evaluar el caso de uso del cliente
Evaluación de las cargas de trabajo
Este proceso es el mismo que para la Opción 1: evaluación básica.
Seleccionar el hardware de evaluación de FTDW
Antes de iniciar una evaluación completa del sistema, debe elegir e implementar una
configuración de referencia de FTDW publicada para las pruebas. Puede elegir entre varios
métodos para identificar una configuración de referencia adecuada. A continuación se indican
los enfoques comunes:



16
Presupuesto. El cliente elige adquirir el sistema con mayor capacidad y/o el sistema con
mayor rendimiento según el presupuesto disponible.
Rendimiento. El cliente elige adquirir el sistema con mayor rendimiento disponible.
Análisis interno. La decisión se basa en el análisis de las cargas de trabajo que el
cliente ha ejecutado en el hardware existente.

Análisis ad hoc. La Herramienta de ajuste de tamaño de FTDW proporciona un método
básico para calcular los requisitos del sistema de FTDW basándose en supuestos
básicos sobre la carga de trabajo de la base de datos de destino. Esta herramienta de
hoja de cálculo se puede descargar desde
http://download.microsoft.com/download/D/F/A/DFAAD98F-0F1B-4F8B-988F22C3F94B08E0/Fast%20Track%20Core%20Calculator%20v1.2.xlsx.
Paso 2: establecer métricas de evaluación
Las tres métricas siguientes son importantes para una evaluación completa de FTDW
y componen los criterios de decisión clave para la evaluación de hardware:
 Tasa máxima de consumo de núcleos de CPU (MCR)
 Tasa de consumo de simulación (BCR)
 Capacidad de datos de usuario (UDC) necesaria
Para obtener más información acerca del cálculo de estas métricas, vea la sección
Simulaciones y validación de este documento.
MCR
Esta métrica mide la tasa máxima de procesamiento de datos de SQL Server para una consulta
y un conjunto de datos estándar para una combinación específica de servidor y CPU. Se trata
de una tasa por núcleo y se mide como un examen basado en consulta desde la memoria
caché. MCR es el punto de partida inicial para el diseño de sistemas Fast Track. Representa un
máximo estimado del ancho de banda de E/S necesario para el servidor, la CPU y la carga de
trabajo. MCR es útil como guía de diseño inicial porque solo necesita un almacenamiento local
y un esquema de la base de datos mínimos para calcular el rendimiento potencial de una CPU
determinada. Es importante resaltar que MCR se emplea como punto de partida para el diseño
de sistemas, no es una medida del rendimiento del sistema.
BCR
BCR se mide mediante una serie de consultas que se consideran definitivas de la carga de
trabajo de FTDW. BCR se calcula en términos de ancho de banda total de lectura del disco
y de la memoria caché, en lugar de la memoria caché únicamente como ocurre con el cálculo
de MCR. BCR puede permitir la optimización de la infraestructura para un caso concreto de uso
de cliente al realizar las medidas sobre una serie de consultas que coinciden con los patrones
de carga de trabajo del cliente. O bien, en el caso de una FTRA validada de un asociado, se emplea
una serie de consultas de simulación que aseguran que los sistemas están diseñados para cargas
de trabajo elevadas. En resumen, BCR es una medida real del procesamiento de datos mediante
varias consultas en cargas de trabajo simultáneas con volúmenes significativos de datos.
Capacidad de datos de usuario
Se trata de la capacidad prevista para la base de datos de SQL Server. La capacidad de datos
de usuario de Fast Track tiene en cuenta la compresión de base de datos posterior a la carga
y representa una estimación de la cantidad de archivos de datos de usuario o de flujos sin
comprimir que se pueden cargar en el sistema Fast Track. La proporción de compresión
estándar empleada para FTDW es 3,5:1.
17
Tenga en cuenta que cualquier ampliación del almacenamiento más allá de la implementación
inicial puede hacer necesaria una migración de datos que seccione de manera eficiente los
datos existentes en las nuevas ubicaciones de archivo de base de datos. Por esta razón, es
importante tener en cuenta el crecimiento esperado de la base de datos y la duración prevista
del sistema a la hora de elegir una arquitectura de referencia adecuada.
Paso 3: elegir una arquitectura de referencia de Fast Track Data Warehouse
Una vez realizados los cálculos, se puede comparar BCR con las tasas publicadas de MCR
y de capacidad proporcionadas por los asociados de Fast Track para cada FTRA publicada.
Para obtener más información acerca de nuestros asociados, vea Fast Track Data Warehousing
(http://www.microsoft.com/sqlserver/en/us/solutions-technologies/data-warehousing/fasttrack.aspx).
Puede emplear la métrica BCR como punto de referencia común para evaluar los resultados de
la prueba/evaluación del sistema con las configuraciones publicadas. A partir de los datos de BCR,
el cliente puede elegir la opción de Fast Track más acorde con los resultados de las pruebas.
Opción 3: arquitecturas de referencia definidas por el usuario
Este enfoque aprovecha la metodología de FTDW para adaptar un sistema a una carga de
trabajo o un conjunto de hardware determinado. Para usar este enfoque es preciso entender
perfectamente tanto SQL Server como los componentes de hardware que se ejecutan en él.
Los siguientes pasos describen el método general para desarrollar una arquitectura de
referencia definida por el usuario conforme a los principios de FTDW.
Paso 1: definir la carga de trabajo
Es fundamental entender el caso de uso de la base de datos de destino para las configuraciones
de FTDW y esto es igualmente aplicable a cualquier aplicación personalizada de las instrucciones
proporcionadas en este documento. Las instrucciones para las FTRA, en concreto en lo que
respecta a las cargas de trabajo, se pueden usar como modelo de referencia para incorporar
la evaluación de la carga de trabajo al diseño de la arquitectura de componentes.
Paso 2: establecer simulaciones de la arquitectura de componentes
Lo siguiente proporciona un marco básico para desarrollar una arquitectura de referencia para
una carga de trabajo predefinida:
1. Establecer la Tasa máxima de consumo de núcleos de CPU (MCR) para el servidor y la
CPU elegidos. Use el método descrito en la sección Simulaciones y validación de este
documento para calcular MCR. También puede emplear las tasas de MCR publicadas
para las configuraciones de FTDW. Normalmente, las CPU de la misma familia tienen
tasas similares de consumo de núcleos de CPU para la base de datos de SQL Server.
2. Usar el valor de MCR para calcular los requisitos de almacenamiento y de red de
almacenamiento, y para crear un diseño de sistema inicial.
3. Obtener un sistema de prueba basado en el diseño de sistema inicial. Será idealmente
toda la configuración especificada.
18
4. Establecer una Tasa de consumo de simulación (BCR). Según la evaluación de la carga
de trabajo, identifique una consulta o bien, en el caso ideal, un conjunto de consultas
representativas. Siga las prácticas descritas en la sección Medir BCR para la carga de
trabajo de este documento.
5. Ajustar el diseño del sistema según los resultados.
6. Establecer la configuración final de servidor y almacenamiento.
Paso 3: validación del sistema
El objetivo de la simulación del sistema debe ser la validación de la configuración y el
rendimiento de la configuración de componentes de hardware identificada en el paso 2. Para
obtener más información sobre este proceso, vea la sección Validar una FTRA definida por el
usuario de este documento. Para validar el sistema, siga estos pasos:
1. Evalúe el rendimiento de los componentes con los requisitos de rendimiento establecidos.
Así se garantiza que el rendimiento del sistema real cumple las expectativas.
2. Valide el rendimiento del sistema volviendo a crear la configuración final y ejecutando
simulaciones finales. Como regla general, el valor final de BCR debe alcanzar el 80 por
ciento o más del valor de MCR del sistema.
Resumen de la elección de una FTRA
En la tabla siguiente se resumen las tres opciones de selección de una FTRA.
Opción
Evaluación básica
Evaluación completa
Arquitectura de referencia
definida por el usuario
Ventajas
 Configuración y adquisición
del sistema muy rápidas
(de días a semanas)
 Costo mínimo de diseño
y evaluation
 Menores requisitos de
conocimientos de la
infraestructura
 Arquitectura de referencia
predefinida adaptada a la
carga de trabajo esperada
 Posible ahorro de costos
en hardware
 Mayor confianza en la
solución
 Posibilidad de reutilizar
hardware existente
 Posibilidad de incorporar
el hardware más reciente
 Sistema muy optimizado
para su caso de uso
Tabla 3: comparación de las distintas opciones de evaluación
19
Inconvenientes
 Posibilidad de
almacenamiento excesivo
o de menos capacidad de
CPU de la especificada





La evaluación conlleva
esfuerzo y tiempo
(de semanas a meses)
Necesita información
detallada de la carga
de trabajo de destino
El proceso dura varios
meses
Necesita muchos
conocimientos de la
infraestructura
Necesita muchos
conocimientos de
SQL Server
Configuración estándar de FTDW
Arquitectura de los componentes de hardware
Las arquitecturas de referencia de FTDW actuales se basan en configuraciones de
almacenamiento dedicado. Entre las opciones publicadas actualmente se incluyen SAN
conmutado, SAN de conexión directa, SAS de conexión directa, SAS-RBOD e iSCSI. El
rendimiento de E/S de disco se consigue gracias al uso de contenedores de almacenamiento y
procesadores dedicados independientes. Cada proveedor de Fast Track publica detalles y
configuraciones adicionales. En la ilustración 2 se muestran las unidades de creación de nivel
de componente que conforman una arquitectura de referencia de FTDW basada en
almacenamiento SAN.
Ilustración 2: configuración de almacenamiento de ejemplo para un servidor con 2 sockets
y 12 núcleos
Requisitos y configuración de componentes
Memoria del servidor
RAM total: la asignación de RAM para las FTRA se basa en resultados de simulación con el
objetivo de equilibrar el rendimiento lógico máximo (total de páginas leídas del disco y el búfer
con el tiempo) con el uso de la CPU. En la tabla 4 se muestran las asignaciones de memoria
recomendadas para las arquitecturas de referencia de SQL Server 2012. Los valores de
20
memoria máxima proporcionados no son límites estrictos, sino que representan valores
promedio para sistemas validados correctamente.
Tamaño del servidor
Memoria mínima
Memoria máxima
1 socket
64 GB
128 GB
2 sockets
128 GB
256 GB
4 sockets
256 GB
512 GB
8 sockets
512 GB
768 GB
Tabla 4: asignaciones de memoria recomendadas para SQL Server 2012
También es importante tener en cuenta lo siguiente a la hora de evaluar los requisitos de
memoria del sistema:




Consulta de caché: las cargas de trabajo que atienden un porcentaje elevado de
consultas de caché pueden beneficiarse si se aumentan las asignaciones de RAM
a medida que la carga de trabajo crece.
Combinaciones hash y ordenaciones: las consultas que emplean combinaciones
hash a gran escala o que realizan operaciones de ordenación a gran escala se
beneficiarán de la presencia de grandes cantidades de memoria física. Con menos
memoria, estas operaciones se vuelcan en el disco y usan mucho tempdb, lo que
introduce un patrón aleatorio de E/S en las unidades de datos del servidor.
Cargas: las inserciones masivas también pueden introducir operaciones de ordenación
que usan tempdb si no se pueden procesar en la memoria disponible.
Índice de almacén de columnas optimizados en memoria xVelocity: las cargas de
trabajo que favorecen en gran medida los planes de consulta de índices de almacén de
columnas se ejecutan de manera más eficiente con bloques de memoria situados en el
extremo superior de los intervalos que se muestran en la tabla 4.
SAN de canal de fibra
HBA – SAN: todos los componentes de red de HBA y SAN varían en cierta medida según la
marca y el modelo. Además, el rendimiento del contenedor de almacenamiento puede ser
sensible a la configuración de SAN y a las capacidades de bus PCIe. Esta recomendación es
una regla general y es coherente con las pruebas realizadas durante el desarrollo de la
configuración de referencia de FTDW.
Si se emplea la división en zonas, en las zonas solo deben existir puertos que se usen para
Fast Track. La topología y la configuración de red de FC detalladas se documentan en la Guía
de configuración técnica proporcionada por cada asociado de Fast Track y son específicas de
cada FTRA publicada.
E/S de múltiples rutas (MPIO): se debe configurar MPIO. Cada volumen hospedado en
matrices de almacenamiento dedicadas debe tener al menos una ruta de acceso activa.
Round-robin con subconjunto es la directiva predeterminada que se emplea para las
configuraciones de Fast Track, pero apenas se usa para las arquitecturas de referencia de los
asociados, ya que los equipos de ingeniería del asociado de FTDW identifican configuraciones
21
más óptimas. Los DSM y/o los documentos específicos de los asociados suelen prescribir
valores diferentes y se deben revisar antes de la configuración.
Almacenamiento
Disco local: una matriz RAID1 de 2 discos es la asignación mínima para la instalación de
Windows Server y SQL Server. Se debe asignar suficiente espacio en disco para los requisitos
de RAM virtual y paginación. En general, el espacio de disco disponible debe ser 250 GB o 1,5
veces la RAM del sistema, lo que sea mayor. La configuración de disco restante depende del
caso de uso y de la preferencia del cliente.
Sistema de archivos lógico: se prefiere el montaje de LUN en rutas de carpeta de punto de
montaje en Windows, en lugar de letras de unidad, debido al número de volúmenes presentes
en muchos sistemas Fast Track.
También puede ser útil entender qué asignación de unidad del sistema operativo Windows
representa cada LUN (volumen), grupo de discos RAID y punto de montaje de Windows Server
en los contenedores de almacenamiento. Puede adoptar un esquema de nomenclatura para los
puntos de montaje y los volúmenes al montar LUN en carpetas de Windows. Para obtener más
información acerca de los esquemas de nomenclatura de dispositivos, vea la Guía de
configuración técnica proporcionada por cada asociado de Fast Track.
Puede emplear herramientas específicas del proveedor para lograr el esquema de nomenclatura
de volumen recomendado. Si no existe ninguna herramienta adecuada, puede hacer que haya
un disco a disposición de Windows cada vez de las matrices de almacenamiento mientras
asigna nombres de unidad para garantizar una correcta topología físico a lógico.
Sistema de archivos físico: para obtener más información, incluidas instrucciones detalladas,
vea la sección Configuración de la aplicación de este documento.
Configuración de los contenedores de almacenamiento: todas las configuraciones de los
contenedores conservan sus valores predeterminados a menos que se indique lo contrario en
la documentación técnica del asociado de Fast Track. Las especificaciones de FTDW para la
configuración del sistema de archivos requieren contenedores de almacenamiento que
permitan la configuración específica de agrupaciones de RAID y asignaciones de LUN.
Es preciso tener esto en cuenta si se sustituye hardware de configuración de referencia
de FTDW o se evalúa hardware personalizado.
Configuración de la aplicación
Windows Server 2008 R2
A menos que se indique lo contrario, se debe usar la configuración predeterminada para el
sistema operativo Windows Server 2008 R2 Enterprise. Asegúrese de que se han aplicado el
Service Pack más reciente y todas las actualizaciones críticas. La característica E/S de múltiples
rutas es necesaria para muchas arquitecturas de referencia. Para obtener más información
sobre la configuración detallada de MPIO, vea la Guía de configuración técnica del asociado de
Fast Track para la arquitectura de referencia dada. Confirme que Windows Server 2008 R2
22
está instalado como un rol Servidor de aplicaciones para asegurar la correcta instalación y los
valores predeterminados de .NET Framework.
SQL Server 2012 Enterprise
Opciones de inicio
Se debe agregar -E a las opciones de inicio. Esto aumenta el número de extensiones contiguas
de cada archivo que se asignan a una tabla de base de datos a medida que crece. De esta
forma se mejora el acceso secuencial al disco. Para obtener más información sobre esta
opción, vea el Artículo 329526 de Microsoft Knowledge Base
(http://support.microsoft.com/kb/329526). Es importante asegurarse de que la opción -E ha
surtido efecto en el inicio de la base de datos. La opción distingue mayúsculas de minúsculas y
el formato. Un espacio en blanco antes
o después de la opción puede impedir la inicialización.
También se debe agregar -T1117 a las opciones de inicio. Esta marca de seguimiento asegura
un crecimiento uniforme de todos los archivos de un grupo de archivos en caso de que se
habilite el crecimiento automático. La recomendación estándar de FTDW para el crecimiento
del archivo de base de datos es la asignación previa en lugar de usar el crecimiento automático
(con la excepción de tempdb). Para obtener más información, vea la sección Detalles de
configuración del almacenamiento de este documento.
Habilite la opción Bloquear páginas en memoria. Para obtener más información,
vea Habilitar la opción de bloqueo de páginas en memoria (Windows)
(http://go.microsoft.com/fwlink/?LinkId=141863).
-T834 se debe evaluar caso a caso. Esta marca de seguimiento puede mejorar las tasas de
rendimiento de muchas cargas de trabajo de almacenamiento de datos. Esta marca habilita
asignaciones de páginas grandes en memoria para el grupo de búferes de SQL Server. Para
obtener más información sobre esta y otras marcas de seguimiento, vea el Artículo 920093 de
Microsoft Knowledge Base (http://support.microsoft.com/kb/920093).
Nota: actualmente, SQL Server 2012 no admite el uso de–T834 si se usan índices de almacén
de columnas en la base de datos. Si piensa usar índices de almacén de columnas, no emplee
esta marca de seguimiento.
Memoria máxima de SQL
En SQL Server 2012 no se debe asignar más del 92 por ciento de la RAM total del servidor
a SQL Server. Si otras aplicaciones van a compartir el servidor, se debe ajustar en consecuencia
la cantidad de RAM que queda disponible para el sistema operativo. Este valor se controla
mediante la opción max server memory. Para obtener más información acerca de la configuración
de memoria para las arquitecturas de referencia validadas, vea la documentación del asociado
de FTDW.
Regulador de recursos
Las cargas de trabajo de almacenamiento de datos suelen incluir consultas complejas que
funcionan sobre grandes volúmenes de datos. Estas consultas pueden consumir mucha
23
memoria y pueden volcarse a un disco si se limita la memoria. Este comportamiento tiene
implicaciones concretas en lo que respecta a la administración de recursos. Puede usar la
tecnología Regulador de recursos de SQL Server 2012 para administrar el uso de los recursos.
En la configuración predeterminada de SQL Server, el Regulador de recursos proporciona un
máximo del 25 por ciento de los recursos de memoria de SQL Server a cada sesión. Esto significa
que, en el peor de los casos, tres consultas suficientemente grandes como para consumir al menos
el 25 por ciento de la memoria disponible bloquearán cualquier otra consulta que haga un uso
intensivo de la memoria. En este estado, cualquier consulta adicional cuya ejecución necesite
una concesión grande de memoria se pondrá en cola hasta que haya recursos disponibles.
Puede usar el Regulador de recursos para reducir la memoria máxima usada por consulta.
Sin embargo, como consecuencia, las consultas simultáneas que de otra forma consumirían
grandes cantidades de memoria usan en su lugar tempdb, lo que introduce más E/S aleatoria
y puede reducir el rendimiento global. Si bien puede ser beneficioso para muchas cargas de
trabajo de almacenamiento de datos el restringir la cantidad de recursos del sistema disponibles
para una sesión individual, se mide mejor mediante el análisis de las cargas de trabajo de
consultas simultáneas. Para obtener más información sobre cómo usar el Regulador de
recursos, vea Regulador de recursos (http://msdn.microsoft.com/es-es/library/bb933866.aspx).
También se deben examinar las instrucciones y las prácticas específicas del proveedor para
soluciones Fast Track. En concreto, las soluciones mayores de Fast Track de 4 y 8 sockets
pueden emplear una configuración específica del Regulador de recursos para lograr un
rendimiento óptimo.
En resumen, existe un equilibrio entre la reducción de restricciones que proporcionan mayor
rendimiento para las consultas individuales y unas restricciones más estrictas que garanticen
el número de consultas que se pueden ejecutar simultáneamente.
Para obtener más información sobre las prácticas recomendadas y los escenarios comunes
del Regulador de recursos, vea las notas del producto Usar el Regulador de recursos
(http://msdn.microsoft.com/es-es/library/ee151608.aspx).
Sistema de almacenamiento
Administrar la fragmentación es fundamental para el rendimiento del sistema con el tiempo para
las arquitecturas de referencia de FTDW que colocan el almacenamiento de base de datos
principal en unidades de disco duro (HDD). Por ello, se especifica una configuración detallada
del almacenamiento y el sistema de archivos.
Componentes del sistema de almacenamiento
La ilustración 3 proporciona una vista que combina tres niveles principales de configuración de
almacenamiento para la pila integrada de base de datos. Debe considerarse un caso de
referencia, ya que la topología específica varía en gran medida según el asociado de Fast
Track. La pila típica de la base de datos contiene los elementos siguientes:
24



Matriz de discos físicos: RAID 1+0 de 4 ejes es el enfoque estándar representado en la
ilustración 3. También se han usado RAID 5 y RAID 6 en algunas arquitecturas de
referencia de asociados para SQL Server 2008 R2 y SQL Server 2012.
Asignación de volúmenes del sistema operativo (LUN)
Bases de datos: usuario, temporal del sistema, registro del sistema
Ilustración 3: arquitectura completa de almacenamiento de ejemplo para un sistema FTDW
basado en tres contenedores de almacenamiento con un LUN (volumen) por grupo de discos
Detalles de configuración del almacenamiento
Para cada contenedor de almacenamiento, haga lo siguiente.
1. Cree grupos de cuatro discos cada uno, mediante RAID 1+0 (RAID 10). El número
exacto de grupos de discos por contenedor de almacenamiento puede variar en función
del proveedor. Para obtener más información, vea la documentación específica del
proveedor. En general, el número es (2) grupos de discos RAID10 y (1) grupo de discos
RAID1 para contenedores con factor de forma grande (LFF) y (5) grupos de discos
25
RAID10 para contenedores con factor de forma pequeño (SFF).
Los volúmenes totales usados como ubicaciones de grupos de archivos para los datos
principales no deben superar los 32. Si el número total de LUN del sistema de
almacenamiento supera este umbral, se pueden usar grupos de discos mayores para
reducir el número de LUN manteniendo un rendimiento similar de E/S. Por ejemplo,
use un grupo de 8 discos RAID 10 con 1 LUN en lugar un grupo de 4 discos RAID 10
con 1 LUN. En el caso de grupos de discos mayores se reducen el rendimiento y la
eficiencia. Esto varía según la tecnología de almacenamiento empleada.
2. Dedique todos los grupos de discos salvo uno a los datos de usuario principales (PRI).
Las ubicaciones de los datos de usuario principales son sinónimas de las ubicaciones
de grupos de archivos de la base de datos de SQL Server.
Todas las FTRA requieren uno o dos LUN por grupo de discos de PRI. Consulte las
instrucciones específicas del proveedor correspondientes a la arquitectura de referencia
elegida. Estos LUN se emplean para almacenar los archivos de base de datos de SQL
Server (archivos .mdf y .ndf).
3. Asegúrese de que la asignación del procesador de almacenamiento principal para cada
volumen de disco asignado a los datos principales dentro de un contenedor de
almacenamiento esté equilibrada de manera uniforme. Por ejemplo, un contenedor de
almacenamiento con cuatro volúmenes de disco asignados para los datos principales
tendrá dos volúmenes asignados al procesador de almacenamiento "A" y dos asignados
al procesador de almacenamiento "B".
4. Cree un LUN en el grupo de discos restante para hospedar los registros de
transacciones de la base de datos. En algunas configuraciones mayores de Fast Track,
las asignaciones de registros se limitan exclusivamente a los primeros contenedores de
almacenamiento del sistema. En este caso se usan los grupos de discos adicionales
para el almacenamiento provisional que no sean bases de datos o se dejan sin rellenar
para reducir el costo.
Para cada base de datos, haga lo siguiente:
1. Cree al menos un grupo de archivos que contenga un archivo de datos por LUN de PRI.
Asegúrese de que todos los archivos tengan el mismo tamaño. Si piensa usar varios
grupos de archivos dentro de una única base de datos para segregar objetos (por
ejemplo, una base de datos de ensayo para admitir carga), asegúrese de incluir todos
los LUN de PRI como ubicaciones para cada grupo de archivos.
2. Al crear los archivos de cada grupo de archivos, asígnelos previamente a su mayor tamaño
previsto, con un tamaño suficientemente grande como para contener los objetos
previstos.
3. Deshabilite la opción de crecimiento automático para los archivos de datos y aumente
manualmente el tamaño de todos los archivos de datos cuando se esté acercando al
límite de tamaño actual.
4. Para obtener más información acerca de las recomendaciones para bases de datos de
usuario y grupos de archivos, vea la sección Administrar la fragmentación de datos de
este documento.
26
En el caso de tempdb, haga lo siguiente:
1. Preasigne el espacio y agregue después un único archivo de datos por LUN. Asegúrese
de que todos los archivos tengan el mismo tamaño.
2. Asigne los archivos de registro temporales en uno de los LUN dedicados a archivos de
registro.
3. Habilite el crecimiento automático; en general, el uso de un incremento de crecimiento
grande es adecuado para las cargas de trabajo de almacenamiento de datos. Un valor
equivalente al 10 por ciento del tamaño de archivo inicial es un punto de partida
razonable.
4. Siga las prácticas recomendadas estándar de SQL Server para las consideraciones de
tamaño de la base de datos y tempdb. Quizás sea necesaria una mayor asignación de
espacio durante la fase de migración o durante la carga inicial de los datos del
almacenamiento. Para obtener más información, vea Planeamiento de capacidad para
tempdb (http://msdn.microsoft.com/es-es/library/ms345368.aspx) en los Libros en
pantalla de SQL Server.
Para el registro de transacciones, haga lo siguiente:
1. Cree un único archivo de registro de transacciones por cada base de datos en uno de
los LUN asignados al espacio de registro de transacciones. Reparta los archivos de
registro de diferentes bases de datos entre los LUN disponibles o use varios archivos de
registro para el crecimiento del registro según sea necesario.
2. Habilite la opción de crecimiento automático para los archivos de registro.
3. Asegúrese de que la capacidad de registro es adecuada para los requisitos proporcionados
en la tabla 5. Se acepta alguna variación, según las características de diseño de sistemas
concretos.
RAM del sistema (GB)
Capacidad valorada de FT
(terabytes)
<= 96
<=10
<= 128
>10
<=40
Asignación mínima de
registro recomendada
Espacio disponible
reflejado en GB
300 GB X 1 volumen
300 GB X 2 volúmenes
o bien
600 GB X 1 volumen
Tabla 5: recomendaciones de asignación de registro
Consulte las prácticas recomendadas existentes para la asignación y la administración de
registros de transacciones de SQL Server.
Almacenamiento de estado sólido
Las arquitecturas de referencia de FTDW que utilizan almacenamiento de estado sólido para
los datos principales (PRI) presentan muchas ventajas, incluida una administración
simplificada, menores costos operativos y un mantenimiento predecible.
27
Administración simplificada: el almacenamiento de estado sólido no requiere la
administración de la fragmentación. Se debe seguir usando la opción de inicio –E de SQL
Server, pero no se necesita ninguna otra optimización o administración de la asignación de
páginas. Esta simplificación hace que la administración a largo plazo de los entornos de FTDW
sea mucho más sencilla. Además, se pueden usar grupos de discos mayores y un menor
número de volúmenes/LUN sin que ello afecte negativamente al rendimiento. Este cambio
simplifica la creación y el mantenimiento de grupos de archivos.
Resistencia de E/S: el almacenamiento de estado sólido tiene una degradación del rendimiento
mínima en condiciones de alta simultaneidad o fragmentación de páginas. Además, una carga
de trabajo mixta de lectura aleatoria (búsqueda) no afecta negativamente a los patrones de E/S
de solicitudes grandes (recorrido).
Mantenimiento predecible: muchas opciones de almacenamiento de estado sólido proporcionan
supervisión basada en software de la duración de escritura con una frecuencia menor de errores
físicos difíciles de predecir.
Menores costos operativos: si bien el precio de venta es mayor, el almacenamiento de
estado sólido proporciona un equilibrio más eficiente entre el rendimiento de E/S y la capacidad
por unidad. Una tasa eficiente de E/S de cargas de trabajo de FTDW para HDD SAS de 300
GB y 10k da de promedio 50 MB. El SSD Enterprise MLC consigue entre 150 y 200 MB en una
capacidad de 600 GB. Además, el almacenamiento de estado sólido consume mucha menos
potencia, genera menos calor y suele admitir soluciones de mayor densidad.
Configuración del almacenamiento de estado sólido
Se pueden realizarse los ajustes siguientes en las instrucciones estándar de configuración del
almacenamiento de FTDW si se emplea almacenamiento de estado sólido para los volúmenes
de PRI.




28
Si se necesita creación de reflejo, se puede usar RAID1+0 o RAID5. RAID5 proporciona
la mejor capacidad sin ninguna penalización de rendimiento para cargas de trabajo de
FTDW en estado sólido.
El número de LUN y de volúmenes se pueden reducir hasta solo un volumen de PRI por
unidad de almacenamiento. En algunos casos es útil que el número de volúmenes de
PRI sea un múltiplo del número de núcleos de la CPU. El número mínimo de volúmenes
de PRI es dos.
El registro de transacciones se puede colocar también en el almacenamiento de estado
sólido, pero las cargas de trabajo de FTDW no suelen estar enlazadas a registros. Es
posible reducir costos si se coloca el registro en un HDD tradicional. Lo mismo sucede
con el almacenamiento local para la instalación de Windows Server y SQL Server.
Se pueden pasar por alto las recomendaciones sobre la administración de la fragmentación
de páginas y la carga paralela de índices clúster, ya que la fragmentación de la base de
datos lógica no afecta al rendimiento de E/S del almacenamiento de estado sólido.
Prácticas recomendadas de SQL Server para FTDW
Las prácticas para las cargas de trabajo de Fast Track se validan y documentan en dos casos.
El primero de ellos se produce si una práctica de Fast Track difiere sustancialmente de las prácticas
recomendadas establecidas de SQL Server. El segundo caso ocurre en aquellos escenarios donde
no existen prácticas o no son fácilmente accesibles. Las prácticas proporcionadas aquí no pretenden
ser completas, ya que existe mucha documentación para la implementación de bases de datos
de SQL Server. Muchos temas relacionados con una implementación de FTDW se deben
consultar en la documentación técnica y las prácticas recomendadas existentes de SQL Server.
Importante: esta guía contiene varios vínculos a documentación creada para SQL Server 2008
R2. Creemos que la mayoría de estas instrucciones siguen siendo válidas para SQL Server 2012.
Debe buscar las versiones actualizadas de estos documentos en cuanto estén disponibles. Las
versiones futuras de esta guía de referencia actualizarán los vínculos a medida que estén disponibles.
Arquitectura de datos
Estructura de tabla
El tipo de tabla que se emplea para almacenar datos en la base de datos tiene un efecto
significativo sobre el rendimiento del acceso secuencial. Es muy importante diseñar el esquema
físico teniendo esto en cuenta para permitir que los planes de consulta induzcan E/S secuencial
en la medida de los posible.
La elección de un tipo de tabla desciende al modo en que se obtendrá acceso a los datos de la
tabla la mayoría de las veces. Se puede usar la siguiente información como ayuda para determinar
qué tipo de tabla es preciso considerar según los detalles de los datos que se van a almacenar.
Tablas de montón
Las tablas de montón proporcionan E/S secuencial limpia para los recorridos de tabla y suelen
reducir la sobrecarga en relación con la fragmentación de las tablas. Intrínsecamente no
permiten recorridos basados en intervalos (acceso directo) optimizados como ocurre en las
tablas de índices clúster. En una situación de recorrido de intervalos, una tabla de montón
recorre toda la tabla (o la partición por rangos adecuada, si se aplica la creación de
particiones).
El recorrido de tablas de montón alcanza el rendimiento máximo a los 32 archivos, por lo que el
uso de montones para tablas de hechos grandes en sistemas con números elevados de LUN
(más de 32) o de núcleos (más de 16) puede requerir el uso del Regulador de recursos, restricciones
de DOP o cambios en la asignación de archivos de base de datos estándar de Fast Track.
Es mejor usar tablas de montón en los casos siguientes:


29
La mayoría de las consultas con prioridad alta en la referencia de tabla contienen
predicados que hacen referencia a diversas columnas dispares o no tienen ningún
predicado de columna.
Las consultas realizan normalmente recorridos grandes en lugar de recorridos de rango
limitado, como las tablas empleadas exclusivamente para rellenar cubos de Analysis

30
Services. (En esos casos, se debe dividir en particiones la tabla de montón con la
misma granularidad que el cubo de Analysis Services que se va a rellenar).
Los requisitos de la carga de trabajo de consulta se cumplen sin la sobrecarga
incremental de la administración de índices o el rendimiento de carga; las tablas de
montón se cargan más deprisa.
Tablas de índices clúster
En el entorno de almacenamiento de datos, un índice clúster es más eficiente cuando la clave
es una columna calificada por rango (como una fecha) que se usa con frecuencia en las
restricciones de la carga de trabajo de consulta pertinente. En esta situación, el índice se puede
usar para restringir considerablemente y optimizar los datos que se van a buscar.
Es mejor usar tablas de índices clúster si:

La tabla contiene columnas calificadas por rango que se emplean en las restricciones
de consulta para la mayoría de los escenarios de carga de trabajo de consultas de alta
prioridad en la tabla. En las configuraciones de FTDW, la columna de fecha con
particiones de un índice clúster debe ser también la clave de índice clúster.
Nota: en algunos casos puede ser conveniente elegir una clave de índice clúster que no
sea la columna de partición de fecha para una tabla de índices clúster. Sin embargo, es
probable que esto provoque fragmentación a menos que se carguen particiones completas,
ya que los datos nuevos que se superponen a intervalos existentes de clave de índice
clúster crean divisiones de página.

Las consultas de la tabla realizan normalmente búsquedas específicas o restringidas
a un intervalo, no recorridos de tablas completas o grandes recorridos de varios intervalos.
Particionamiento de tablas
El particionamiento de tablas puede ser una herramienta importante para administrar la
fragmentación en bases de datos de FTDW. Por ejemplo, se puede usar el particionamiento
para actualizar o eliminar bloques grandes de datos de usuario basados en intervalos de una
tabla sin dirigirse a otras partes de la tabla. En cambio, la eliminación fila a fila de un índice
clúster puede provocar una fragmentación de extensión importante. Un escenario habitual es
volver a crear particiones nuevas después de que envejezcan y la frecuencia de las operaciones
DML para el intervalo de datos disminuya. La partición es ahora estable con respecto a las
operaciones DML y tiene una fragmentación de extensión mínima.
Además, las tablas grandes que se emplean principalmente para rellenar cubos de SQL Server
Analysis Services se pueden crear como tablas de montón con particiones, estando el particionamiento
de las tablas alineado con el particionamiento de los cubos. Cuando se obtiene acceso, solo se
recorren las particiones pertinentes de la tabla grande. (Las particiones que admiten el modo
ROLAP de Analysis Services se pueden estructurar mejor como índices clúster).
Para obtener más información sobre el particionamiento de tablas, vea las notas del producto
Estrategias de tablas e índices con particiones con SQL Server 2008
(http://msdn.microsoft.com/es-es/library/dd578580(v=SQL.100).aspx).
31
Indización
Tenga en cuenta lo siguiente para la creación de índices de FTDW:




Use un índice clúster para intervalos de fechas o restricciones comunes.
Use un índice de almacén de columnas siempre que sea posible. En la próxima sección
se describen las prácticas recomendadas para trabajar con índices de almacén de
columnas en entornos de FTDW.
Reserve la indización no clúster para situaciones en las que se necesite búsqueda
específica y el particionamiento de tablas no proporcione suficiente rendimiento. Si es
posible, emplee un índice de almacén de columnas como alternativa al índice no clúster.
Los índices de cobertura no clúster pueden ser útiles para algunas cargas de trabajo de
almacenamiento de datos. Se deben evaluar caso a caso y comparar con el índice de
almacén de columnas.
Índices de almacén de columnas optimizados en memoria xVelocity
SQL Server 2012 incluye una nueva característica de aceleración de consultas de
almacenamiento de datos basada en tecnología de columnas: los índices de almacén de
columnas. Estos nuevos índices, en combinación con las características mejoradas de
procesamiento de consultas, mejoran el rendimiento de las consultas de almacenamiento de
datos en una amplia gama de consultas analíticas.
Los índices de almacén de columnas optimizados en memoria xVelocity son almacenes de columnas
"puros" (no híbridos) porque almacenan todos los datos de las columnas incluidas en páginas
diferentes. Los índices de almacén de columnas mejoran el rendimiento del recorrido de E/S
y las frecuencias de acierto del búfer, y son idóneos para la metodología de diseño de FTDW.
Prácticas recomendadas
Los objetos de índice de almacén de columnas residen junto a las tablas y se crean de manera
similar a los índices no clúster. Esto implica que se necesita capacidad de memoria
incremental. No es necesario crear índices de almacén de columnas en grupos de archivos
diferentes
a menos que se espere que el índice realice cambios frecuentes en la tabla de destino.
El mantenimiento de índices de almacén de columnas en grupos de archivos diferentes puede
ayudarle a administrar la fragmentación de páginas con el tiempo en entornos muy volátiles.
Crear índices de almacén de columnas para modelos de datos normalizados
Los modelos de datos normales (es decir, 3NF) desencadenan a menudo combinaciones entre
dos o más tablas grandes (de hechos). Estos tipos de combinaciones no son ideales actualmente
para el procesamiento de índices de almacén de columnas y pueden presentar disminuciones
de rendimiento con respecto a los planes de consulta con índices que no son de almacén de
columnas. Los enfoques siguientes pueden ayudarle a evitar este problema con los modelos
de datos normales:


32
Use sugerencias de nivel de consulta para impedir que se use el procesamiento de
índices de almacén de columnas.
Use OPTION(IGNORE_NONCLUSTERED_COLUMNSTORE_INDEX).


Vuelva a escribir las consultas. Para obtener más información, vea los recursos
enumerados en la sección Prácticas recomendadas generales de los índices de
almacén de columnas de este documento.
Procure omitir las claves de combinación comunes de una tabla que participa en las
combinaciones de SQL que muestran disminuciones de rendimiento con respecto a los
planes de consulta con índices que no son de almacén de columnas. La omisión de la
clave de combinación del índice de almacén de columnas de una tabla puede hacer que
no se use el índice de almacén de columnas para las consultas que se combinan en la
columna omitida. Este enfoque puede ser útil en entornos donde no pueden aplicarse
opciones de nivel de consulta. Tenga en cuenta que la omisión de una columna del
índice de almacén de columnas no garantiza un plan de consulta mejor y puede afectar
a otras consultas en las que el índice de almacén de columnas proporcionaría mejor
rendimiento. Si decide usar esta opción, la selección de una columna de la menor de las
tablas implicadas puede reducir el impacto de rendimiento en otras consultas. Tenga en
cuenta que las claves principales declaradas (DDL) se deben incluir en el índice de
almacén de columnas, lo que puede restringir las columnas de combinación disponibles.
Aunque omita una columna de clave principal de la definición de un índice de almacén
de columnas, todas las columnas de clave principal se agregan automáticamente al
índice de almacén de columnas cuando se crea.
Si bien los modelos de datos normales no están optimizados perfectamente para los índices de
almacén de columnas en la versión actual, es importante destacar que las simulaciones de FTDW
se basan en una versión modificada de TPC-H, que es un modelo normalizado. Se siguieron
midiendo mejoras importantes para las cargas de trabajo simultáneas que combinaban planes de
consulta con índices de almacén de columnas y de otro tipo, incluido el rendimiento valorado de
FTDW que casi duplicó el rendimiento global de las cargas de trabajo en algunos casos.
Crear índices de almacén de columnas para modelos de datos dimensionales
Siga las prácticas recomendadas de índices de almacén de columnas estándar para los modelos
dimensionales como los esquemas de estrella. Esto se puede considerar un escenario del mejor
caso para el procesamiento de índices de almacén de columnas.
Administración de memoria para los índices de almacén de columnas
Las FTRA validadas para SQL Server 2012 tienen normalmente más RAM total del sistema que
las configuraciones similares para SQL Server 2008 R2. La razón principal es que las cargas
de trabajo mejoradas con índices de almacén de columnas se ejecutan de manera más
eficiente con bloques de memoria mayores. Siempre se debe usar el Regulador de recursos
para establecer la cantidad máxima de memoria por sesión para los entornos de FTDW en los
que piensa aprovechar los índices de almacén de columnas. En las FTRA validadas se
documentan las configuraciones del Regulador de recursos empleadas para lograr un
rendimiento clasificado por FT y estos valores se pueden considerar un punto de partida para
las cargas de trabajo de cliente. Idealmente, la configuración se evaluará y optimizará
específicamente para una carga de trabajo de cliente después de la instalación del sistema.
33
El comando SQL siguiente configura el Regulador de recursos de SQL Server según estas
recomendaciones. En este caso, la cantidad máxima de memoria por sesión se establece en el
19 por ciento.
ALTER RESOURCE GOVERNOR RECONFIGURE;
ALTER WORKLOAD GROUP [default] WITH(request_max_memory_grant_percent=19);
Prácticas recomendadas generales de los índices de almacén de columnas optimizados
en memoria xVelocity
Las instrucciones de referencia de FTDW solo abarcan prácticas únicas de Fast Track.
Para obtener más información acerca de los índices de almacén de columnas, vea la
Guía de optimización de los índices de almacén de columnas de SQL Server 2012
(http://social.technet.microsoft.com/wiki/contents/articles/sql-server-columnstore-performancetuning.aspx) y P+F sobre los índices de almacén de columnas de SQL Server 2012
(http://social.technet.microsoft.com/wiki/contents/articles/sql-server-columnstore-indexfaq.aspx).
Estadísticas de base de datos
La decisión de cuándo ejecutar estadísticas y su frecuencia de actualización no depende de
ningún factor único. La ventana de mantenimiento disponible y la falta total de rendimiento del
sistema suelen ser las dos razones principales por las que se abordan los problemas de las
estadísticas de base de datos.
Para obtener más información, vea Estadísticas usadas por el optimizador de consultas en
Microsoft SQL Server 2008 (http://msdn.microsoft.com/es-es/library/dd535534.aspx).
Prácticas recomendadas
Se recomienda seguir estas prácticas recomendadas para las estadísticas de base de datos:




34
Use las opciones AUTO CREATE y AUTO UPDATE (sincrónicas o asincrónicas) para
las estadísticas (el valor predeterminado del sistema en SQL Server). El uso de esta
técnica reduce al mínimo la necesidad de ejecutar estadísticas manualmente.
Si debe recopilar estadísticas manualmente, se deben recopilar idealmente para todas
las columnas de una tabla. Si no es posible ejecutar estadísticas para todas las
columnas, debe recopilar al menos estadísticas de todas las columnas que se usan en
la cláusula WHERE o HAVING y en las claves de combinación. La creación de índices
genera estadísticas sobre la clave de índice, por lo que no tiene que hacerlo explícitamente.
Las estadísticas compuestas (de varias columnas) son fundamentales en muchos
escenarios de combinación. Las combinaciones de dimensión de hechos que implican
claves de combinación compuestas pueden producir planes de optimización de bucle
anidado poco óptimos en ausencia de estadísticas compuestas. Las estadísticas
automáticas no crearán, actualizarán ni reemplazarán estadísticas compuestas.
Las estadísticas que incluyen un valor de clave que aumenta (como una fecha en una
tabla de hechos) deben actualizarse manualmente después de cada operación de carga
incremental. En todos los demás casos, se pueden actualizar las estadísticas con menor
frecuencia. Si determina que la opción AUTO_UPDATE_STATISTICS no es suficiente
en su caso, ejecute estadísticas según una programación.
Compresión
Las configuraciones de FTDW están diseñadas con la compresión de página habilitada.
Se recomienda usar la compresión de página en todas las tablas de hechos. La compresión
de tablas de dimensiones pequeñas (es decir, las que tienen menos de un millón de filas)
es opcional. En el caso de tablas de dimensiones mayores suele ser beneficioso usar la
compresión de página. En cualquier caso, la compresión de tablas de dimensiones se debe
evaluar para cada caso de uso. La compresión de fila es una opción adicional que proporciona
tasas de compresión razonables para ciertos tipos de datos.
La compresión de página de SQL Server reduce los datos de tablas, índices y particiones. Esto
reduce la cantidad de espacio físico necesario para almacenar las tablas de usuario, lo que permite
que quepan más datos en el grupo de búferes (memoria) de SQL Server. Una ventaja de esto es
la reducción del número de solicitudes de E/S que se atienden desde el almacenamiento físico.
La cantidad de compresión real que se puede observar varía según los datos que se están
almacenando y la frecuencia de campos de datos duplicados dentro de los datos. Si los datos
son muy aleatorios, las ventajas de la compresión son muy limitadas. Incluso en las mejores
condiciones, el uso de la compresión aumenta la demanda de la CPU para comprimir
y descomprimir los datos, pero también reduce los requisitos de espacio en disco físico y en la
mayoría de los casos mejora el tiempo de respuesta de las consultas al atender las solicitudes
de E/S desde el búfer de memoria. Generalmente, la compresión de página tiene una razón de
compresión (tamaño original frente al tamaño comprimido) de entre 2 y 7:1, siendo 3:1 una estimación
conservadora típica. Los resultados variarán en función de las características de los datos.
Administrar la fragmentación de datos
La fragmentación puede producirse en varios niveles y es necesario controlarlos todos para
mantener la E/S secuencial. Un objetivo clave de un FTDW es mantener los datos lo más
ordenados secuencialmente como sea posible al tiempo que se limita la fragmentación
subyacente. Si se permite que se produzca la fragmentación, el rendimiento general del
sistema se resiente.
Es necesario realizar una desfragmentación periódica, pero las siguientes instrucciones pueden
ayudarle a minimizar el número de procesos de desfragmentación, que llevan mucho tiempo.
Fragmentación del sistema de archivos
Los bloques de disco por archivo de base de datos deben ser contiguos en el disco físico
dentro del sistema de archivos NTFS. Se puede impedir la fragmentación en este nivel si se
preasigna a los archivos su tamaño máximo esperado en el momento de su creación.
Se deben evitar herramientas de desfragmentación del sistema de archivos NTFS. Estas
herramientas están diseñadas para funcionar en el nivel del sistema operativo y no son
conscientes de las estructuras de archivos de datos internas de SQL Server.
35
Fragmentación de extensión
Dentro de SQL Server, todas las páginas de un archivo, independientemente de la asociación
de tabla, pueden intercalarse hasta el tamaño de extensión (2M) o hasta el nivel de página
(8K). Esto se debe normalmente a operaciones DML simultáneas, actualizaciones excesivas de
nivel de fila o eliminaciones excesivas de nivel de fila.
La reescritura total de la tabla o las tablas en cuestión es la única forma de garantizar la
asignación de páginas óptima dentro de un archivo. No existe ningún método alternativo para
resolver este tipo de fragmentación de base de datos. Por esta razón, es importante seguir las
instrucciones para la configuración de SQL Server y las prácticas recomendadas para cargar
datos y administrar DML.
La consulta siguiente proporciona información fundamental para evaluar la fragmentación
lógica de una tabla de FTDW. La métrica con mayor prioridad es Average Fragment Size
(tamaño promedio de fragmento). Este valor proporciona un entero que representa el número
promedio de páginas de SQL Server que se agrupan en extensiones contiguas.
SELECT db_name(ps.database_id) as database_name
,object_name(ps.object_id) as table_name
,ps.index_id
,i.name
,cast (ps.avg_fragmentation_in_percent as int) as [Logical Fragmentation]
,cast (ps.avg_page_space_used_in_percent as int) as [Avg Page Space Used]
,cast (ps.avg_fragment_size_in_pages as int) as [Avg Fragment Size In Pages]
,ps.fragment_count as [Fragment Count]
,ps.page_count
,(ps.page_count * 8)/1024/1024 as [Size in GB]
FROM sys.dm_db_index_physical_stats (DB_ID() --NULL = All Databases
, OBJECT_ID('$(TABLENAME)')
,1
, NULL
, 'SAMPLED') AS ps
--DETAILED, SAMPLED, NULL = LIMITED
INNER JOIN sys.indexes AS i
on (ps.object_id = i.object_id AND ps.index_id = i.index_id)
WHERE ps.database_id = db_id()
and ps.index_level = 0;
36
En la tabla siguiente se proporciona una regla general para interpretar los valores de tamaño
promedio de fragmento.
Tamaño promedio de fragmento
>400
Acción
Es un valor ideal y puede ser difícil de
mantener para algunas estructuras de datos.
300-399
Verde
La tabla proporcionará un buen rendimiento
de E/S y no requiere el mantenimiento de la
fragmentación lógica.
150-299
Amarillo
Es más probable que la fragmentación
lógica afecte a la eficacia de E/S. Se
recomienda realizar mantenimiento para
mejorar el número de fragmentos.
10-149
Rojo
Fragmentación lógica importante. Las
solicitudes grandes de E/S en esta estructura
producirán un movimiento significativo de los
cabezales de disco y reducirán la eficacia de
E/S global del sistema.
<10
Rojo
Estos valores tan pequeños del tamaño
promedio de fragmento suelen indicar que la
opción de inicio –E de SQL Server no se ha
establecido o no se ha reconocido en el inicio.
Tabla 6: valores del tamaño promedio de fragmento
Estado
Ideal
Por último, es importante destacar que los resultados del tamaño promedio de fragmento no se
deben evaluar para tablas o particiones menores de 500 MB. Las estructuras de datos pequeñas
no tienen suficientes páginas en total para lograr cantidades de fragmento muy eficientes. Además,
estas estructuras de datos menores suelen representar solicitudes de datos relativamente
pequeñas y tienen un impacto limitado sobre la eficiencia de E/S global del sistema. Se suelen
conseguir mejores resultados cuando solo se administran las tablas mayores a las que se
obtiene acceso con más frecuencia en un entorno de almacenamiento de datos.
Fragmentación de índices
Un índice puede tener un orden físico (página) y lógico (índice) diferente.
No use el comando ALTER INDEX REORGANIZE para resolver este tipo de fragmentación
porque su uso puede invalidar las ventajas de las asignaciones grandes. La regeneración de un
índice o el uso de INSERT... SELECT para insertar datos en una nueva copia del índice (lo que
evita una reordenación) puede resolver este problema. Todos los procesos ALTER INDEX
REBUILD deben especificar SORT_IN_TEMPDB=TRUE para evitar la fragmentación del grupo
de archivos de destino. Un valor MAXDOP de 1 es ideal pero puede producir velocidades de
carga muy lentas. En algunos casos, es posible establecer los valores de MAXDOP hasta en 8.
Para obtener más información, vea la sección Cargar datos de este documento.
37
Varios grupos de archivos
Se pueden crear grupos de archivos diferentes para minimizar la fragmentación lógica en casos
de uso de datos volátiles como los siguientes:




Tablas o índices que se quitan y se vuelven a crear con frecuencia (dejando huecos en
el diseño de almacenamiento que otros objetos rellenan).
Índices para los que no hay otra opción que admitir una fragmentación elevada debido
a las divisiones de página, como ocurre cuando se cargan con frecuencia datos
incrementales que se superponen principalmente al intervalo existente de clave de
índice clúster.
Tablas menores (como tablas de dimensiones) que se cargan en incrementos
relativamente pequeños, que se pueden colocar en un grupo de archivos volátil para
evitar que esas filas se intercalen con tablas grandes de transacciones o de hechos.
Bases de datos provisionales desde las que se insertan datos en la tabla de destino final.
Otras tablas se pueden colocar en un grupo de archivos no volátil. Además, las tablas de
hechos muy grandes también se pueden colocar en grupos de archivos diferentes.
Cargar datos
La arquitectura de componentes de Fast Track está equilibrada para los intervalos de
exploración promedio más elevados que se obtienen con el acceso a disco secuencial.
Para mantener estos intervalos de exploración, se debe extremar la precaución para garantizar
un diseño contiguo de los datos dentro del sistema de archivos de SQL Server.
Esta sección está dividida en los dos métodos siguientes: carga incremental y migración de datos.
Estas instrucciones son específicas, pero no exclusivas, del almacenamiento de datos Fast Track.
Para obtener más información sobre la carga masiva de SQL Server, vea Guía de rendimiento
de la carga de datos (http://msdn.microsoft.com/es-es/library/dd425070.aspx).
Otro recurso útil es la Guía de prácticas recomendadas de carga de datos de Fast Track 3.0.
Esta presentación de Microsoft PowerPoint se encuentra en el Portal de Fast Track DW de SQL
Server (http://msdn.microsoft.com/es-es/library/dd425070.aspx). Aunque este documento se
basaba inicialmente en SQL Server 2008 R2, sigue siendo aplicable a SQL Server 2012.
Cargas incrementales
En esta sección se abordan los escenarios comunes de carga diaria de un entorno de
almacenamiento de datos. Esta sección incluye escenarios de carga con uno o varios de los
atributos siguientes:



Tamaño reducido con respecto a la memoria del sistema disponible
Las operaciones de ordenación de carga son adecuadas para la memoria disponible
Tamaño reducido con respecto a las filas totales del objeto de carga de destino
Se deben tener en cuenta las directrices siguientes cuando cargue tablas de montón y tablas
de índices clúster.
38
Proceso de carga de tablas de montón
Las inserciones masivas de tablas de montón se pueden implementar como un proceso en
serie o en paralelo. Use estas sugerencias:


Para ejecutar el movimiento de datos en la tabla de montón de destino, use BULK
INSERT con la opción TABLOCK. Si la tabla permanente final tiene particiones, use la
opción BATCHSIZE, ya que la carga en una tabla con particiones produce una
ordenación en tempdb.
Para mejorar el rendimiento del tiempo de carga cuando se importan conjuntos de datos
grandes, ejecute simultáneamente varias operaciones de inserción masiva para usar
paralelismo en el proceso masivo.
Proceso de carga de índices clúster
Existen dos enfoques generales para cargar tablas de índices clúster con una fragmentación de
tabla mínima.
Opción 1
Use BULK INSERT para cargar los datos directamente en la tabla de destino. Para obtener el
máximo rendimiento, todo el conjunto de datos que se va a cargar debe caber en una
ordenación en memoria. Todos los datos cargados deben controlarse mediante una única
operación de confirmación con un valor de BATCHSIZE de 0. Este valor impide que los datos
de varios lotes se intercalen y generen divisiones de página. Si emplea esta opción, la carga
debe realizarse como un solo subproceso.
Opción 2
Cree una tabla de ensayo que coincida con la estructura (incluidas las particiones) de la tabla
de destino:


39
Realice una inserción masiva serie o multiproceso en la tabla de ensayo vacía de
índices clúster usando valores de tamaño de lote moderados distintos de cero para
evitar que las ordenaciones se desborden en tempdb. El máximo rendimiento se
consigue con cierto nivel de paralelismo. El objetivo de este paso es el rendimiento; por
tanto, las divisiones de página y la fragmentación lógica provocadas por las inserciones
paralelas y/o simultáneas no suponen ningún problema.
Inserte desde la tabla de ensayo en la tabla de índices clúster de destino mediante una
única instrucción INSERT...SELECT con un valor MAXDOP de 1. MAXDOP 1 asegura
una fragmentación de extensión mínima pero a menudo a costa del rendimiento. Se
pueden usar valores de MAXDOP de hasta 8 para aumentar el rendimiento de la carga,
pero esto aumentará la fragmentación de extensión a medida que el paralelismo
aumente. El equilibrio eficiente de esta contrapartida se evalúa mejor caso a caso.
Opción 3
Esta opción requiere el uso de dos grupos de archivos y dos o más tablas. El enfoque necesita
una tabla de índices clúster con particiones y es más adecuado para las tablas que experimentan
niveles elevados de fragmentación lógica en las particiones más actuales con poca o ninguna
actividad de cambios en las particiones más antiguas. El objetivo global es poner las particiones
volátiles en un grupo de archivos dedicado y envejecer o "mover" esas particiones al grupo de
archivos estático cuando dejen de recibir registros nuevos o cambios a los registros existentes:





40
Cree dos grupos de archivos, según las instrucciones de FTDW. Uno se destinará a las
particiones volátiles y el otro a las particiones estáticas. Una partición volátil es aquella
en la que más del 10 por ciento de las filas cambiará con el tiempo. Una partición
estática es aquella que no es volátil.
Cree la tabla principal con particiones de índices clúster en el grupo de archivos
estático.
Cree una tabla coherente con uno de los dos enfoques generales siguientes:
o Una única tabla de montón con una restricción que refleje el esquema de
partición de la tabla principal. Esta restricción debe representar el intervalo volátil
del conjunto de datos principal y puede abarcar uno o varios intervalos de
partición del esquema de la tabla principal. Esto es más útil si el rendimiento de
carga inicial es el principal criterio de decisión porque las cargas en un montón
suelen ser más eficientes que las cargas en un índice clúster.
o Una única tabla de índices clúster con un esquema de partición que sea
coherente con la partición de la tabla principal. Esto permite realizar inserciones
directas con un bajo grado de paralelismo (DOP) en la tabla principal a medida
que las particiones volátiles envejecen. Una vez envejecidas mediante inserción
en la tabla principal, se quitan las particiones y se agregan nuevos intervalos.
Genere una vista que una ambas tablas. Esto presenta la combinación de las dos tablas
como un único objeto desde la perspectiva del usuario.
Una vez que los intervalos de datos volátiles se conviertan en estáticos desde una
perspectiva de cambios de datos, use un proceso adecuado de envejecimiento como el
cambio de particiones:
o Si se usa una tabla de montón con restricción, mueva los datos por intervalo de
partición al grupo de archivos estático mediante la inserción en la tabla de ensayo.
Use CREATE INDEX y el cambio de partición para mover los datos a la tabla
principal. Para obtener más información sobre este tipo de operación para las
configuraciones de FTDW, vea la sección Migración de datos de este
documento.
o Si se usa un índice clúster con particiones, use un DOP que sea menor o igual
que 8. Después, realice una operación INSERT restringida por intervalo de
partición directamente en la tabla principal. Quizás tenga que establecer el DOP
en un valor tan bajo como 1 para evitar la fragmentación, según la simultaneidad
global del sistema.
Migración de datos
Abarca escenarios de carga grande única o poco frecuente en un entorno de almacenamiento
de datos. Estas situaciones pueden producirse durante la migración de la plataforma o mientras
se cargan datos de prueba para la simulación del sistema. Este tema incluye escenarios de
carga con uno o varios de los atributos siguientes:


Operaciones de carga que superan la memoria del sistema disponible
Operaciones de carga de gran volumen y alta simultaneidad que crean presión sobre la
memoria disponible
Proceso de carga de tablas de montón
Siga las instrucciones proporcionadas anteriormente para el procesamiento de carga incremental.
Proceso de carga de índices clúster
Existen varios enfoques generales para cargar tablas de índices clúster con una fragmentación
de tabla mínima.
Opción 1
Use BULK INSERT para cargar los datos directamente en una tabla de destino de índices
clúster. Las operaciones de ordenación y el tamaño de confirmación completo deben caber en
la memoria para obtener el máximo rendimiento. Debe tener cuidado para asegurarse de que
los distintos lotes de datos que se carguen no tengan intervalos de clave de índice que se
superpongan.
Opción 2
Realice una inserción masiva serie o multiproceso en una tabla vacía de ensayo de índices
clúster con una estructura idéntica. Use un tamaño de lote moderado distinto de cero para
mantener las ordenaciones en memoria. Después, inserte datos en una tabla vacía de índices
clúster mediante una sola instrucción INSERT...SELECT con un valor MAXDOP de 1.
Opción 3
Use inserciones masivas multiproceso en una partición de una tabla de ensayo de montón
usando valores de tamaño de lote moderados distintos de cero para mantener las ordenaciones
en memoria. A continuación, use instrucciones INSERT…SELECT serie o paralelo que
abarquen cada intervalo de particiones para insertar datos en la tabla de índices clúster.
Opción 4
Use operaciones de cambio de partición en un proceso de varios pasos que suele proporcionar
los mejores resultados para operaciones grandes de carga. Este método agrega más
complejidad al proceso general y está diseñado para mostrar un enfoque óptimo para el
rendimiento de carga sin formato. El objetivo principal de este enfoque consiste en habilitar la
actividad de escritura en paralelo en todas las fases de la inserción en la operación de índice
clúster sin introducir fragmentación lógica. Esto se consigue almacenando provisionalmente la
tabla en varios grupos de archivos antes de insertar los datos en la tabla de destino final.
1. Identifique el esquema de partición para la tabla de índice clúster de destino final.
2. Cree un grupo de archivos de ensayo.
41
3. Cree una tabla de ensayo "base" de montón sin comprimir y sin particiones en el grupo
de archivos de ensayo.
4. Inserte datos de forma masiva mediante TABLOCK WITH en la tabla de ensayo base.
Varias operaciones de copia masiva en paralelo son el enfoque más eficiente si es
posible usar varios archivos de origen. El número de operaciones de carga en paralelo
para obtener el máximo rendimiento depende de los recursos del servidor (CPU
y memoria) y de los datos que se vayan a cargar.
5. Identifique el número de grupos de archivos principales que se van a admitir. Este
número debe ser un múltiplo del número total de particiones de la tabla de destino. El
número también representa el número total de operaciones INSERT y CREATE INDEX
que se van a ejecutar simultáneamente en pasos posteriores. Por ejemplo, para una
tabla con 24 particiones y un servidor con ocho núcleos, sería indicada una base de
datos con ocho grupos de archivos principales. Esta configuración permite la ejecución
de ocho inserciones en paralelo en los pasos siguientes, una para cada uno de los ocho
grupos de archivos principales y núcleo de CPU. En este caso, cada grupo de archivos
contendría el valor de tres intervalos de partición de datos.
6. Cree el número de grupos de archivos principales que se haya determinado
anteriormente.
7. Cree una tabla de montón de ensayo en cada grupo de archivos principal para cada
intervalo de partición, sin compresión. Cree una restricción en la tabla de ensayo que
coincida con el intervalo de partición correspondiente de la tabla de destino. Usando el
ejemplo proporcionado anteriormente, habría tres tablas de ensayo por cada grupo de
archivos principal creado en este paso.
8. Cree la tabla de índices clúster con particiones de destino con compresión de página.
Esta tabla se debe repartir entre todos los grupos de archivos principales. Las particiones
deben alinearse con los intervalos de restricción de la tabla de ensayo de montón.
9. Ejecute una instrucción INSERT o SELECT desde la tabla de ensayo base en las tablas
de grupo de archivos de ensayo para cada grupo de archivos principal. Esto debe
hacerse en paralelo. Asegúrese de que el predicado de la instrucción INSERT
o SELECT coincide con los intervalos de partición correspondientes. Nunca ejecute más
de una instrucción INSERT o SELECT por grupo de archivos simultáneamente.
10. Ejecute un comando CREATE CLUSTERED INDEX con compresión de página por
grupo de archivos para las tablas de ensayo recién rellenadas. Se puede hacer en
paralelo pero nunca con un DOP mayor que 8. Nunca ejecute más de una creación de
índice por grupo de archivos simultáneamente. Asegúrese de usar la opción
SORT_IN_TEMPDB siempre que realice una operación CREATE INDEX para evitar la
fragmentación de los grupos de archivos principales. El número óptimo de operaciones
simultáneas de creación de índice dependerá del tamaño del servidor, la memoria y los
propios datos. En general, procure un uso elevado de la CPU en todos los núcleos sin
suscripción excesiva (el 85-90 por ciento de utilización global).
11. Ejecute operaciones serie de cambio de partición de las tablas de ensayo a la tabla de
destino. Esto se puede hacer al finalizar cada operación CREATE INDEX de ensayo.
42
Simulaciones y validación
Esta sección proporciona una descripción básica de los procesos empleados para diseñar y
calificar las arquitecturas de referencia de FTDW de SQL Server. El objetivo de proporcionar
esta información es sustentar las arquitecturas de referencia definidas por el usuario o
personalizadas basadas en la metodología de FTDW. Para realizar simulaciones, solucionar
problemas o comprobar las arquitecturas de referencia de asociados publicadas y ya validadas,
póngase en contacto con el asociado de publicación (H-P, Dell, EMC, IBM, Cisco, etc.).
El proceso para la validación de FTDW se puede dividir en las dos categorías que se describen aquí.
Validación de hardware de línea base
El objetivo de la validación de hardware es establecer métricas de rendimiento reales, no
calificadas, de los componentes de hardware clave de la arquitectura de referencia de Fast
Track. Este proceso determina las características de rendimiento reales de línea base de los
componentes de hardware clave en la pila de la base de datos.
Validación de la base de datos de Fast Track
El establecimiento de características de rendimiento de SQL Server, en función de una carga
de trabajo de FTDW, permite la comparación con los supuestos de rendimiento proporcionados
por el proceso de evaluación de hardware de línea base. En general, la métrica de rendimiento
de carga de trabajo de la base de datos debe reflejar al menos el 80 por ciento de las tasas de
línea base para las arquitecturas de referencia validadas de Fast Track. Las métricas de
rendimiento calculadas en este proceso son la base de los valores de rendimiento de FTDW
publicados y se basan en cargas de trabajo de consulta SQL simultáneas ejecutadas con la
herramienta de simulación Reference Point de Fast Track.
Reference Point es una herramienta de software de Microsoft distribuida a los asociados de
hardware de Fast Track y es la única infraestructura a través de la cual Microsoft puede validar
y aprobar una arquitectura de referencia oficial de Fast Track. La herramienta crea una
instancia de un esquema de la base de datos de referencia y controla varias cargas de trabajo
de consulta simultáneas diseñadas para identificar cuellos y establecer medidas clave del
rendimiento del sistema.
Validación de Fast Track con índices de almacén de columnas optimizados en memoria xVelocity
SQL Server 2012 implementa la tecnología de índice de almacén de columnas como opción de
índices no clúster para las tablas ya existentes. Las consultas individuales pueden usar o no
planes de optimización de índices de almacén de columnas en función de la estructura de la
consulta. Esto significa que no se puede predecir la combinación de planes de consulta de fila
tradicionales y de columnas nuevos para un entorno FTDW en un momento dado.
Por estos motivos, el diseño y la validación del sistema de FTDW para SQL Server 2012 se
basa en simulaciones de índices que no son de almacén de columnas. Los sistemas FTDW
están diseñados para funcionar eficazmente en caso de que no se alcance ninguna optimización
de columnas en ningún período de tiempo dado. Se suelen conseguir mejoras significativas de
rendimiento cuando los planes de consulta de índices de almacén de columnas están activos
y este rendimiento se puede considerar incremental respecto al diseño del sistema básico.
43
Las arquitecturas de referencia de Fast Track para SQL Server 2012 validadas por los asociados
publican una tasa de rendimiento lógico adicional para las simulaciones mejoradas de índices
de almacén de columnas y estas cifras se pueden emplear para calcular aproximadamente el
impacto positivo en el rendimiento de las consultas que los clientes pueden esperar en una
carga de trabajo de consulta simultánea. Estas cifras se basan en las mismas simulaciones
y el mismo esquema de FTDW usados para todas las validaciones del sistema.
Realizar la validación de línea base de FTDW
La validación de línea base se realiza en el nivel de sistema operativo con una herramienta
como SQLIO. La prueba de aplicaciones de SQL Server no se realiza en esta fase y todas las
pruebas son escenarios sintéticos de mejor caso. El objetivo es garantizar que la configuración
del hardware y del sistema operativo sea precisa y consiga los resultados esperados según las
simulaciones de diseño y de desarrollo.
Se puede usar Monitor de rendimiento y confiabilidad de Windows Server (también conocido
como perfmon) para hacer un seguimiento, registrar y notificar el rendimiento de E/S. Se puede
usar una herramienta como SQLIO para probar el ancho de banda de E/S. Para obtener más
información acerca de SQLIO, incluidas instrucciones y ubicaciones de descarga, vea las notas
del producto de SQLCAT Prácticas recomendadas de E/S antes de la implementación
(http://sqlcat.com/sqlcat/b/whitepapers/archive/2007/11/21/predeployment-i-o-best-practices.aspx).
Se usan los componentes y procesos de validación siguientes para generar simulaciones de
hardware de línea base.
Pruebas de línea base con SQLIO
El uso de SQLIO se describe con más detalle en el artículo de prácticas recomendadas.
Las pruebas de lectura tienen normalmente el formato siguiente:
sqlio –kR –fSequential -s30 -o120 -b512 d:\iobw.tst –t1
En este caso, R indica una prueba de lectura, 30 es la duración de la prueba en segundos,
120 es el número de solicitudes pendientes emitidas, 512 es el tamaño de bloque en kilobytes
de las solicitudes realizadas, d:\iobw.tst es la ubicación del archivo de prueba y 1 es el número
de subprocesos.
Para probar escenarios de ancho de banda agregado, se deben emitir varias pruebas SQLIO
en paralelo. Se debe usar una única instancia de SQLIO para cada punto de montaje de datos
principal (volumen de disco). La paralelización de las instancias de SQLIO se puede lograr
mediante Windows PowerShell u otros métodos de scripting. En el caso de arquitecturas de
referencia de FTDW validadas por los asociados, quizás el asociado disponga de scripts de
validación de E/S de línea base.
El artículo de prácticas recomendadas previas a la implementación también explica cómo
realizar un seguimiento de las pruebas con el Monitor de rendimiento y confiabilidad de Windows
Server. El registro y el almacenamiento de los resultados de estas pruebas le aportará una línea
base para el análisis de rendimiento y la resolución de problemas en el futuro.
44
Paso 1: validar el ancho de banda de E/S
El primer paso para validar una configuración de FTDW consiste en determinar el rendimiento
agregado máximo que se puede observar entre la red de E/S de almacenamiento y el servidor.
Esto implica quitar el disco como cuello de botella y centrarse en los componentes que no son
de disco (es decir, los HBA, la infraestructura de conmutador y las controladoras de matriz).
Use los pasos siguientes para realizar esta tarea con SQLIO:
1. Genere un pequeño archivo de datos en cada LUN que se usará para los archivos de
base de datos. El tamaño de estos archivos debe permitir que todos los archivos de
datos quepan en la memoria caché de lectura de las controladoras de matriz (por
ejemplo, 50 MB por archivo).
2. Use SQLIO para emitir lecturas secuenciales en el archivo de forma simultánea usando
tamaños de E/S de bloque grandes (512K) y al menos dos subprocesos de lectura por
archivo. Asegúrese de calcular las lecturas pendientes agregadas. Por ejemplo,
2 subprocesos de lectura con 50 solicitudes pendientes darían un total de
100 solicitudes pendientes en el LUN de destino.
3. Empiece con un valor relativamente bajo para las operaciones de E/S pendientes (-o)
y repita las pruebas aumentando este valor hasta que no haya ninguna mejora en el
rendimiento agregado.
El objetivo de esta prueba es alcanzar un rendimiento agregado que sea razonable en comparación
con los límites teóricos de los componentes de la ruta de acceso entre el servidor y el almacenamiento.
Esta prueba valida el ancho de banda entre el servidor y los procesadores de almacenamiento
SAN; es decir, las rutas de acceso de canal de fibra de múltiples rutas.
Paso 2: validar el ancho de banda de LUN/volumen
Esta prueba es similar a la anterior. Sin embargo, se emplea un archivo mayor para quitar
posibles beneficios de la memoria caché de matriz de la memoria caché de la controladora.
Estos archivos de prueba deben ser suficientemente grandes para simular el tamaño del
archivo de base de datos de destino por volumen, por ejemplo 25 GB por volumen. Se deben
usar parámetros similares para SQLIO como se describe en el paso 1.
Se deben emitir lecturas secuenciales de bloques grandes (512 KB) en los archivos de prueba
de cada volumen. Se recomienda usar un único subproceso por archivo con una profundidad
de solicitudes pendientes de entre 4 y 16 (empiece con un valor pequeño y vaya aumentándolo
hasta que se alcance el máximo rendimiento). En primer lugar, pruebe cada volumen individualmente
y pruebe después los dos simultáneamente. El rendimiento del grupo de discos varía según el
proveedor y la configuración de almacenamiento, pero siempre se puede hacer una comparación
con las tasas de lectura de un solo HDD. Por ejemplo, un grupo de 4 discos RAID1+0 podría
alcanzar una tasa de lectura máxima de casi cuatro veces la tasa de lectura de un solo HDD
para este tipo de patrón básico de lectura. El rendimiento de RAID 1 o 1+0 puede variar en
función del producto de almacenamiento, ya que la tecnología de algunos proveedores permiten
la "lectura reflejada", que permite atender las operaciones de E/S desde ambos lados del par
reflejado cuando se reciben solicitudes contiguas.
45
Paso 3: validar el ancho de banda agregado
En esta prueba, se deben ejecutar lecturas secuenciales en todos los volúmenes de datos
disponibles de forma simultánea en los mismos archivos usados en el paso 2. SQLIO se debe
ejecutar usando dos subprocesos por archivo de prueba, con un tamaño de E/S de 512K y un
número óptimo de E/S pendientes según determine la prueba anterior.
Los resultados de esta prueba muestran el rendimiento agregado máximo que se puede
conseguir al leer datos de los discos físicos.
Los datos se leen del archivo de datos grande, como en la prueba anterior, en cada volumen
simultáneamente.
El rendimiento agregado del disco debe estar entre el 80 y el 90 por ciento del ancho de banda
agregado de E/S de almacenamiento para los sistemas FTDW equilibrados.
Valoraciones de los componentes
En el diagrama siguiente se muestran los resultados de simulaciones sintéticas que son coherentes
con los valores que se obtienen en arquitecturas de referencia de Fast Track similares.
46
Ilustración 4: ejemplo de simulación sintética que obtuvo el ancho de banda para un servidor
de 2 sockets con 12 núcleos, con 3 tarjetas HBA de 8Gbps de puerto doble, con 12 volúmenes
de datos principales de 4 discos RAID1+0
Resumen
Las simulaciones de hardware de línea base validan la capacidad de ancho de banda real para
los principales componentes de hardware de la pila de la base de datos. Para ello se ejecuta
una serie de pruebas sintéticas del caso mejor mediante una herramienta como SQLIO.
Realizar simulaciones de base de datos de Fast Track
Esta fase de la evaluación de FTRA mide el rendimiento de SQL Server para la carga de
trabajo de FTDW según dos métricas principales. La primera, Tasa máxima de consumo de
CPU (MCR), es una medida del rendimiento máximo de procesamiento de E/S. La segunda,
Tasa de consumo de simulación (BCR), es una medida del rendimiento real de procesamiento
de E/S para una consulta o una carga de trabajo basada en consultas.
¿Qué es MCR?
El cálculo de MCR proporciona un valor de rendimiento de E/S por núcleo en MB o GB por
segundo. Este valor se mide ejecutando una consulta predefinida no optimizada de solo lectura
desde la memoria caché del búfer y midiendo el tiempo que se tarda en ejecutar con la cantidad
de datos en MB o GB. Puesto que MCR se ejecuta desde la memoria caché, representa el intervalo
de exploración no optimizado máximo que se puede conseguir con SQL Server para el sistema
que se está evaluando. Por esta razón, MCR proporciona una tasa máxima de la línea base para
el diseño inicial. No está pensada para indicar los resultados promedio o previstos para una carga
de trabajo real. Las arquitecturas de FTDW validadas tendrán resultados agregados de rendimiento
de E/S de línea base que sean al menos el 100 por cien del valor de MCR calculado en el servidor.
Otra manera de explicar esto es que MCR representa la mejor velocidad de procesamiento
posible de SQL Server para una carga de trabajo razonable del caso peor.
MCR se puede usar también como marco de referencia a la hora de comparar otras
arquitecturas de referencia de FTDW publicadas y validadas para SQL Server 2012.
En resumen:




47
MCR no es una medida definitiva de los resultados reales para una carga de trabajo de
cliente.
MCR proporciona una línea base de velocidad máxima de procesamiento de datos para
SQL Server y una única consulta asociada a la carga de trabajo de Fast Track.
MCR es específica de una CPU y un servidor. En general, las valoraciones para una
CPU dada no varían mucho según el servidor y la arquitectura de la placa base, pero el
valor final de MCR se debe determinar mediante pruebas reales.
La tasa de rendimiento de MCR se puede usar como valor comparativo con
arquitecturas de referencia de FTDW existentes ya publicadas. Esto puede ayudar
a elegir el hardware antes de realizar las pruebas de componentes y de aplicaciones.
Calcular MCR
Para establecer una tasa de consumo de CPU de línea base para la aplicación de SQL Server
se ejecuta una consulta SQL estándar definida para el programa FTDW. Esta consulta está
diseñada de forma que sea una representación relativamente sencilla de una consulta típica
para el tipo de carga de trabajo (en este caso, almacenamiento de datos) y se ejecuta desde la
memoria caché del búfer. El valor resultante es específico de la CPU y el servidor en los que se
está ejecutando la consulta. Use el método siguiente para calcular MCR:
1. Cree un conjunto de datos de referencia basado en la tabla lineitem de TPC-H o un
conjunto de datos similar. El tamaño de la tabla debe permitir su almacenamiento entero
en memoria caché en el grupo de búferes de SQL Server y mantener un tiempo de
ejecución mínimo de un segundo para la consulta proporcionada aquí.
2. Para FTDW se emplea la consulta siguiente: SELECT sum([campo entero]) FROM
[tabla] WHERE [restringir al volumen de datos adecuado] GROUP BY [col].
3. El entorno debe:
o Asegurarse de que la configuración del Regulador de recursos tiene los valores
predeterminados.
o Asegurarse de que la consulta se está ejecutando desde la memoria caché del
búfer. La primera ejecución de la consulta debe colocar las páginas en el búfer
y las ejecuciones posteriores deben leer solo del búfer. Compruebe que no se
realizan lecturas físicas en el resultado de estadísticas de la consulta.
o Establecer STATISTICS IO y STATISTICS TIME en ON para generar los
resultados.
4. Ejecute varias veces la consulta, con MAXDOP = 4.
5. Registre el número de lecturas lógicas y el tiempo de CPU del resultado de las
estadísticas para cada ejecución de la consulta.
6. Calcule el valor MCR en MB/s mediante esta fórmula:
( [Lecturas lógicas] / [Tiempo de CPU en segundos] ) * 8 kB / 1024
7. Se debe obtener un intervalo de valores coherente (+/- 5 %) en un mínimo de cinco
ejecuciones de la consulta. Unos valores atípicos significativos (+/- 20 % o más) pueden
indicar problemas de configuración. El promedio de al menos 5 resultados calculados es
el valor MCR de FTDW.
Según el cálculo de MCR, se puede elaborar un diagrama de rendimiento de la arquitectura de
componentes. De cara a la evaluación del valor MCR del sistema, el rendimiento de componentes
se basa en el ancho de banda calificado por el proveedor. Este diagrama puede resultar útil
para el diseño, la selección y el análisis de cuellos de botella del sistema. En la ilustración 5 se
muestra un ejemplo de esto.
48
Ilustración 5: ejemplo de Tasa máxima de consumo de CPU (MCR) y ancho de banda de
componentes calificado para un servidor de 2 sockets y 12 núcleos basado en las CPU Intel
Westmere
Para obtener más información sobre cómo medir MCR, vea Prueba de cargas de trabajo en el
apéndice.
Calcular BCR
Para establecer una tasa de consumo de CPU de simulación para la aplicación de SQL Server
se ejecutan un conjunto de consultas SQL de línea base, bajo un nivel adecuado de simultaneidad,
que son específicas de la carga de trabajo de almacenamiento de datos. El número de consultas
y el nivel de simultaneidad empleados dependen completamente del caso de uso esperado. La
carga de trabajo de consultas se debe atender desde el disco, no desde el grupo de búferes de
SQL Server como ocurre con MCR. El valor resultante es específico de la CPU, el servidor y la
carga de trabajo con los que se está ejecutando. La sección Prueba de cargas de trabajo del
apéndice proporciona un ejemplo más detallado de la creación de una simulación de cargas de
trabajo de BCR.
49
Use el método siguiente para calcular BCR:
1. Cree un conjunto de datos de referencia que contenga al menos una tabla. La tabla
debe tener un tamaño suficientemente grande para que no se almacene completamente
en la memoria caché del grupo de búferes de SQL Server o en la memoria caché de
matriz de SAN. En ausencia de datos de cliente, se puede usar un conjunto de datos
sintético. Es importante intentar calcular aproximadamente las características esperadas
de los datos para el caso de uso de destino.
2. El formato básico de la consulta para FTDW es el siguiente: SELECT sum([campo entero])
FROM [tabla] WHERE [restringir al volumen de datos adecuado] GROUP BY [col].
Se puede usar como punto de partida para el diseño de cargas de trabajo de consulta si
no hay disponibles consultas del cliente. TPC-H es otra simulación de consulta que se
emplea con frecuencia y que se puede usar como conjunto de consultas de referencia.
3. En el caso de una simulación de cliente de FTDW, lo ideal es elegir siempre consultas
que sean representativas de la carga de trabajo de destino. Las consultas se deben
programar en varias sesiones simultáneas que sean representativas de la actividad
histórica o prevista máxima para el entorno del cliente. Se pueden tener en cuenta los
criterios siguientes a la hora de seleccionar la consulta:
 Los requisitos promedio de cargas de trabajo de destino están representados.
Esto puede implicar aumentar o reducir la complejidad del formato básico de la
consulta, agregar combinaciones y/o descartar más o menos datos mediante
proyección y restricción.
 La consulta no debe provocar escrituras de datos en tempdb a menos que esta
característica sea una parte esencial de la carga de trabajo de destino.
 La consulta debe devolver el número mínimo de filas. Se puede emplear la opción
SET ROWCOUNT para administrar esto. Se debe usar un valor de ROWCOUNT
mayor que 100 (105 es el estándar para las simulaciones de Fast Track). También
es posible emplear agregación para reducir los registros devueltos de recorridos
sin restricción grandes.
4. El entorno debe:
 Asegurarse de que la configuración del Regulador de recursos está establecida
en los valores predeterminados.
 Asegurarse de que se borran las memorias caché antes de ejecutar la consulta,
mediante DBCC dropcleanbuffers.
 Establecer STATISTICS IO y STATISTICS TIME en ON para generar los
resultados.
5. Ejecute varias veces la consulta o la carga de trabajo, comenzando con MAXDOP 8.
Cada vez que ejecute la consulta, aumente el valor de MAXDOP de la consulta,
borrando las memorias caché entre cada ejecución.
 Registre el número de lecturas lógicas y el tiempo de CPU del resultado de las
estadísticas.
 Calcule el valor BCR en MB/s mediante esta fórmula:
( [Lecturas lógicas] / [Tiempo de CPU en segundos] ) * 8 kB / 1024
50

Esto le da un intervalo para BCR. Si se emplean varias consultas, use un
promedio ponderado para determinar el valor de BCR.
Resultados de BCR
En la ilustración 6 se muestran los resultados de simulaciones basadas en cargas de trabajo de
SQL Server que son coherentes con los valores que se obtienen en arquitecturas de referencia
de Fast Track Data Warehouse similares.
Ilustración 6: ejemplo de simulación sintética que obtuvo el ancho de banda para un servidor
de 2 sockets con 12 núcleos, con 3 tarjetas HBA de 8 Gbps de puerto doble, con 12 LUN de
datos principales de 4 discos RAID1+0
51
Interpretar el valor de BCR
Si su valor de BCR para la consulta promedio es mucho menor que el valor de MCR estándar
establecido para la FTRA, es probable que esté limitado por la CPU. Como respuesta, puede
que piense en reducir el rendimiento de almacenamiento, por ejemplo reduciendo el número de
matrices, introduciendo más discos por matriz o aumentando el tamaño de los discos; estos
pasos pueden ayudar a reducir el costo de la infraestructura de almacenamiento hasta un nivel
equilibrado. Puede que piense también en usar un servidor con más sockets o CPU de mayor
rendimiento que puedan aprovechar el excedente de rendimiento de E/S de almacenamiento.
En cualquier caso, el objetivo es equilibrar la capacidad de procesamiento de la base de datos
con el rendimiento de E/S de almacenamiento.
Por tanto, si el valor de BCR es mayor que el de MCR, quizás necesite más rendimiento de E/S
para procesar una carga de trabajo de consultas de forma equilibrada.
Arquitecturas publicadas de referencia de FTDW
Todos los asociados que participan en Fast Track Data Warehouse disponen de especificaciones
detalladas de la arquitectura de referencia de hardware. Para obtener más información,
incluidos vínculos a todos los asociados, vea Fast Track Data Warehousing
(http://www.microsoft.com/sqlserver/en/us/solutions-technologies/data-warehousing/fasttrack.aspx).
La capacidad de FTDW se evaluó según la cantidad estimada de archivos de datos de usuario
no comprimidos que se pueden cargar en la base de datos. Esto se denomina Capacidad de
datos de usuario (UDC). Este cálculo presupone que la compresión de página está habilitada
para todas las tablas y que se reflejarán todos los volúmenes de datos. Se emplea un factor
promedio de compresión de 3,5:1. Además, se realiza una asignación de hasta el 30 por ciento
de la capacidad no comprimida a tempdb antes de calcular la UDC. Tenga en cuenta que para
configuraciones mayores con más capacidad total esta proporción se reduce hasta el 20 por ciento.
Para obtener más información sobre el ajuste de tamaño de tempdb, vea Planeamiento de
capacidad para tempdb (http://msdn.microsoft.com/es-es/library/ms345368.aspx).
Conclusión
SQL Server Fast Track Data Warehouse ofrece una plantilla y herramientas para hacer realidad
un almacenamiento de datos, desde el diseño hasta la implementación. En este documento se
describe la metodología, las opciones de configuración, las prácticas recomendadas, las
configuraciones de referencia, y las técnicas de simulación y validación para Fast Track Data
Warehouse.
52
Para obtener más información:
Sitio web de SQL Server
Sitio web de SQL Server Fast Track
SQL Server TechCenter
Recursos en línea de SQL Server
Las 10 mejores prácticas recomendadas para generar un almacenamiento de datos relacional
a gran escala (equipo SQLCAT)
Habilitar la opción de bloqueo de páginas en memoria (Windows)
Optimizar opciones de SQL Server 2005 y SQL Server 2008 para cargas de trabajo de alto
rendimiento
Configurar SQL Server para que use NUMA de software
Inicialización de archivos de base de datos
Ver o cambiar el modelo de recuperación de una base de datos (SQL Server Management
Studio)
Supervisar el uso de la memoria
Solucionar problemas de red de área de almacenamiento (SAN)
Instalar y configurar MPIO
Notas del producto Conceptos básicos de E/S de SQL Server 2000
Compresión de datos: estrategia, planeamiento de capacidad y prácticas recomendadas
¿Le sirvió de ayuda este documento? Envíenos sus comentarios. Díganos, en una escala del
1 (poco útil) al 5 (excelente), cómo calificaría este documento y por qué lo valora con esta
puntuación. Por ejemplo:

¿Lo valora alto debido a que tiene buenos ejemplos, capturas de pantalla excelentes,
una redacción comprensible u otra razón?
 ¿Lo valora bajo debido a que sus ejemplos son escasos, las capturas de pantalla son
borrosas o su redacción es poco clara?
Esta información nos ayudará a mejorar la calidad de las notas del producto que publicamos.
Enviar comentarios.
53
Apéndice
Herramienta de ajuste de tamaño de FTDW
La Herramienta de ajuste de tamaño de FTDW es una calculadora en forma de hoja de cálculo
que le ayuda en el proceso para calcular un requisito de carga de trabajo de cliente en términos
de rendimiento de FTDW. Puede usar esta herramienta si no dispone de una plataforma de pruebas
o como punto de partida para evaluar los requisitos del cliente. La herramienta se encuentra en
Fast Track Data Warehousing (http://www.microsoft.com/sqlserver/en/us/solutionstechnologies/data-warehousing/fast-track.aspx). Además, algunos proveedores asociados han
generado sus propias herramientas de ajuste de tamaño de Fast Track. Se pueden encontrar
en los sitios web de los asociados.
Validar una FTRA definida por el usuario
Prueba de E/S sintética
SQLIO es una herramienta que se puede descargar desde el sitio web de Microsoft que le
permite probar el subsistema de E/S independientemente de SQL Server.
Generar archivos de prueba con SQLIO
Cuando se ejecuta SQLIO, crea un archivo de prueba adecuado, si ese archivo no está ya
presente. Para generar un archivo de un tamaño concreto, use el parámetro –F. Por ejemplo,
use un archivo de parámetros (param.txt) que contenga lo siguiente:
C:\stor\pri\1\iobw.tst 1 0x0 50
La primera ejecución de SQLIO con el parámetro –F genera un archivo de 50 MB:
Eq sqlio -kW -s60 -fsequential -o1 -b64 -LS -Fparam.txt
Este proceso puede tardar bastante tiempo en el caso de archivos grandes. Cree un archivo
en cada disco de datos en el que vaya a hospedar datos de SQL Server y archivos tempdb.
Para ello, agregue más líneas al archivo de parámetros, que creará los archivos necesarios
uno a uno. Para crear archivos en paralelo, cree varios archivos de parámetros y ejecute varias
sesiones de SQLIO simultáneamente.
Validar el ancho de banda de almacenamiento (desde la memoria caché)
El uso de un archivo de prueba pequeño con una duración de lectura de varios minutos
garantiza que el archivo resida completamente en la memoria caché de matriz. La ilustración
7 muestra el contador Disco lógico > Bytes leídos/s para los discos de un sistema Fast Track
de ejemplo con diversas cifras de solicitudes pendientes y tamaños de bloque. Se deben ejecutar
pruebas al menos durante unos minutos para garantizar un rendimiento coherente. La ilustración
muestra que el rendimiento óptimo requiere una cola de solicitudes pendientes de al menos
cuatro solicitudes por archivo. Cada disco individual debe contribuir al ancho de banda total.
54
Ilustración 7: contador Disco lógico > Bytes leídos/s
Validar el ancho de banda de LUN/volumen (desde disco)
Estas pruebas garantizan que todos los volúmenes de disco presentados por las matrices de
disco en Windows son capaces de contribuir al ancho de banda agregado total, leyendo cada
volumen de uno en uno. Puede ver que algunos de los LUN parecen ser ligeramente más
rápidos que otros. Esto no es algo raro, pero se deben examinar las diferencias superiores al
15 por ciento.
Ilustración 8: validar el ancho de banda del par LUN\volumen y RAID
55
Ejecute pruebas simultáneas en uno o más volúmenes que compartan el mismo grupo de
discos. En la ilustración siguiente se muestra el resultado de las pruebas en 8 grupos de
discos.
Ilustración 9: probar LUN que comparten grupos de discos
Validar el ancho de banda agregado (desde disco)
La prueba siguiente muestra el efecto de intensificar el rendimiento de E/S, agregando un
volumen adicional a la prueba a intervalos periódicos. A medida que se ejecuta cada prueba
para un intervalo establecido, se observa un escalón hacia abajo. Debe observar un patrón
similar. El ancho de banda agregado máximo desde disco debe acercarse al 80 o al 90 por
ciento del ancho de banda conseguido desde la memoria caché en el primer paso. El gráfico
muestra la prueba en varios tamaños de bloque de 512K y de 64K.
56
Ilustración 10: ancho de banda agregado en varios tamaños de bloque
Prueba de cargas de trabajo
Medir el valor MCR para el servidor (opcional)
El objetivo de MCR es calcular el rendimiento máximo de un solo núcleo de CPU, que ejecuta
SQL Server, cuando no hay problemas de cuello de botella de E/S. MCR se evalúa por núcleo.
Si eligió calcular esto para su propio servidor, aquí se ofrecen detalles adicionales en los que
se describe la metodología para calcular el valor MCR:
1. Cree un conjunto de datos de referencia basado en la tabla lineitem de TPC-H o un
conjunto de datos similar. El tamaño de la tabla debe permitir su almacenamiento
completo en memoria caché en el grupo de búferes de SQL Server y mantener un
tiempo de ejecución mínimo de 2 segundos para la consulta proporcionada aquí.
2. Para FTDW se emplea la consulta siguiente: SELECT sum([campo entero]) FROM
[tabla] WHERE [restringir al volumen de datos adecuado] GROUP BY [col].
3. El entorno debe:
 Asegurarse de que el Regulador de recursos está establecido en los valores
predeterminados.
 Asegurarse de que la consulta se está ejecutando desde la memoria caché del
búfer. La primera ejecución de la consulta debe colocar las páginas en el búfer
y las ejecuciones posteriores deben leer solo del búfer. Compruebe que no se
realizan lecturas físicas en el resultado de estadísticas de la consulta.
 Establecer STATISTICS IO y STATISTICS TIME en ON para generar los
resultados.
4. Ejecute varias veces la consulta, con MAXDOP = 4.
 Registre el número de lecturas lógicas y el tiempo de CPU del resultado de las
estadísticas para cada ejecución de la consulta.
 Calcule el valor MCR en MB/s mediante esta fórmula:
( [Lecturas lógicas] / [Tiempo de CPU en segundos] ) * 8 kB / 1024
 Se debe obtener un intervalo de valores coherente (+/- 5 %) en un mínimo de
cinco ejecuciones de la consulta. Unos valores atípicos significativos (+/- 20 %
o más) pueden indicar problemas de configuración. El promedio de al menos
5 resultados calculados es el valor MCR de FTDW.
Medir el valor BCR para la carga de trabajo
La medida de BCR es similar a la medida de MCR, excepto en que los datos se atienden desde
el disco, no desde la memoria caché. La consulta y el conjunto de datos para BCR son
representativos de la carga de trabajo de almacenamiento de datos de destino.
Un enfoque para averiguar el valor de BCR consiste tomar una consulta simple, una consulta
promedio y una consulta compleja de la carga de trabajo. Las consultas complejas deben ser
las que impongan más demandas a la CPU. La consulta simple debe ser equivalente a la de
MCR y debe realizar una carga de trabajo similar, de modo que sea comparable con MCR.
57
Crear la base de datos
A continuación se muestra un ejemplo de una instrucción CREATE DATABASE para un
sistema FTDW de 8 núcleos con 16 LUN de datos.
CREATE DATABASE FT_Demo ON
( NAME = N 'FT_Demo_.mdf' ,
FILEGROWTH = 0 ),
( NAME = N 'FT_Demo_v1.ndf'
FILEGROWTH = 0 ),
( NAME = N 'FT_Demo_v2.ndf'
FILEGROWTH = 0 ),
( NAME = N 'FT_Demo_v3.ndf'
FILEGROWTH = 0 ),
( NAME = N 'FT_Demo_v4.ndf'
FILEGROWTH = 0 ),
( NAME = N
FILEGROWTH
( NAME = N
FILEGROWTH
( NAME = N
FILEGROWTH
( NAME = N
FILEGROWTH
(
,
(
,
(
,
(
,
'FT_Demo_v6.ndf'
= 0 ),
'FT_Demo_v7.ndf'
= 0 ),
'FT_Demo_v8.ndf'
= 0 ),
'FT_Demo_v9.ndf'
= 0 ),
PRIMARY Filegroup FT_Demo
FILENAME = N'C:\FT\PRI\SE1-SP1-DG1-v1' , SIZE = 100MB ,
, FILENAME = N'C:\FT\PRI\SE1-SP1-DG1-v1' , SIZE = 417GB ,
, FILENAME = N'C:\FT\PRI\SE1-SP1-DG2-v2' , SIZE = 417GB ,
, FILENAME = N'C:\FT\PRI\SE1-SP2-DG3-v3' , SIZE = 417GB ,
, FILENAME = N'C:\FT\PRI\SE1-SP2-DG4-v4' , SIZE = 417GB ,
, FILENAME = N'C:\FT\PRI\SE2-SP1-DG6-v6' , SIZE = 417GB ,
, FILENAME = N'C:\FT\PRI\SE2-SP1-DG7-v7' , SIZE = 417GB ,
, FILENAME = N'C:\FT\PRI\SE2-SP2-DG8-v8' , SIZE = 417GB ,
, FILENAME = N'C:\FT\PRI\SE2-SP2-DG9-v9' , SIZE = 417GB ,
NAME = N 'FT_Demo_v11.ndf'
FILEGROWTH = 0 ),
NAME = N 'FT_Demo_v12.ndf'
FILEGROWTH = 0 ),
NAME = N 'FT_Demo_v13.ndf'
FILEGROWTH = 0 ),
NAME = N 'FT_Demo_v14.ndf'
FILEGROWTH = 0 ),
, FILENAME = N'C:\FT\PRI\SE3-SP1-DG11-v11' , SIZE = 417GB
, FILENAME = N'C:\FT\PRI\SE3-SP1-DG12-v12' , SIZE = 417GB
, FILENAME = N'C:\FT\PRI\SE3-SP2-DG13-v13' , SIZE = 417GB
, FILENAME = N'C:\FT\PRI\SE3-SP2-DG14-v14' , SIZE = 417GB
LOG ON
( NAME = N 'FT_LOG_v5.ldf' , FILENAME = N 'C:\FT\LOG\SE1-SP2-DG5-v5' , SIZE = 100GB ,
MAXSIZE = 500GB , FILEGROWTH = 50 )
GO
/*****************Configurar los valores recomendados***********************/
ALTER DATABASE FT_Demo SET AUTO_CREATE_STATISTICS ON
GO
ALTER DATABASE
GO
FT_Demo
SET AUTO_UPDATE_STATISTICS ON
ALTER DATABASE
GO
FT_Demo
SET AUTO_UPDATE_STATISTICS_ASYNC ON
ALTER DATABASE
GO
FT_Demo
SET RECOVERY SIMPLE
sp_configure 'show advanced options', 1
go
reconfigure with override
go
58
********Asegurarse de que todas las tablas están en nuestro grupo de archivos, no en
el grupo de archivos principal****/
ALTER DATABASE FT_Demo
MODIFY FILEGROUP FT_Demo
DEFAULT
GO
Crear las tablas de prueba
A continuación se muestra una instrucción CREATE TABLE de ejemplo.
CREATE TABLE lineitem
( l_orderkey
bigint not null,
l_partkey
integer not null,
l_suppkey
integer not null,
l_linenumber
integer not null,
l_quantity
float not null,
l_extendedprice float not null,
l_discount
float not null,
l_tax
float not null,
l_returnflag
char(1) not null,
l_linestatus
char(1) not null,
l_shipdate
datetime not null,
l_commitdate
datetime not null,
l_receiptdate
datetime not null,
l_shipinstruct char(25) not null,
l_shipmode
char(10) not null,
l_comment
varchar(132) not null
)
ON FT_Demo
GO
CREATE CLUSTERED INDEX cidx_lineitem
ON lineitem(l_shipdate ASC)
WITH( SORT_IN_TEMPDB = ON
, DATA_COMPRESSION = PAGE
)
ON FT_Demo
GO
Cargar datos para la medida de BCR
Como se ha descrito anteriormente en este documento, los sistemas Fast Track Data Warehouse
son sensibles a la fragmentación de los archivos de base de datos. Emplee una de las técnicas
descritas en este documento para cargar datos. Durante las pruebas de FTDW, se usó el método
de carga de índices clúster descrito como la opción 2. Con la herramienta datagen de TPC-H,
se generaron los datos de la tabla lineitem hasta un tamaño de 70 GB, usando opciones -s100,
generando el archivo en 8 partes, y usando las opciones –S y –C.
Se estableció la marca de seguimiento 610 durante todas las operaciones de carga para usar el
registro mínimo en la medida de lo posible.
59
Mediante BULK INSERT, estos datos se insertaron en paralelo en una única tabla de ensayo de
índices clúster, usando el registro mínimo; elegimos un tamaño de bloque que no inundara la
memoria disponible y que reduciría el volcado en el disco. La deshabilitación de los bloqueos
de página y la extensión de bloqueo en la tabla de ensayo mejoró el rendimiento durante esta fase.
Se realizó una inserción final en una tabla de destino idéntica, con MAXDOP 1 (mediante la
sugerencia TABLOCK) y evitando una ordenación.
Ejecutar consultas para la medida de BCR
Use la herramienta SQL Server Profiler para registrar información pertinente para las simulaciones
de consulta. Se debe configurar SQL Server Profiler para que registre las lecturas lógicas, la CPU,
la duración, el nombre de la base de datos, el nombre de esquema, la instrucción SQL y los
planes de consulta reales. También se pueden usar los parámetros de sesión de estadísticas
set statistics io on y set statistics io on.
A continuación se muestran algunas consultas de ejemplo (basadas en consultas de la
simulación de TPC-H) y el valor de BCR conseguido en los sistemas de referencia. Tenga en
cuenta que este ejemplo no es indicativo del rendimiento que se obtendrá en cualquier sistema
dado. Los valores de BCR son únicos según el sistema, el tamaño del esquema, los tipos de
datos, la estructura de la consulta y las estadísticas, por citar tan solo algunas de las muchas
variables posibles.
Complejidad de la consulta
Simple
Promedio
Compleja
Tabla 7: ejemplos de simulaciones
BCR por núcleo
(Página comprimida) con MAXDOP 4
201 MB/s
83 MB/s
56 MB/s
Simple
SELECT
sum(l_extendedprice * l_discount) as revenue
FROM
lineitem
WHERE
l_discount between 0.04 - 0.01 and 0.04 + 0.01 and
l_quantity < 25
OPTION (maxdop 4)
60
Promedio
SELECT
l_returnflag,
l_linestatus,
sum(l_quantity) as sum_qty,
sum(l_extendedprice) as sum_base_price,
sum(l_extendedprice*(1-l_discount)) as sum_disc_price,
sum(l_extendedprice*(1-l_discount)*(1+l_tax)) as sum_charge,
avg(l_quantity) as avg_qty,
avg(l_extendedprice) as avg_price,
avg(l_discount) as avg_disc,
count_big(*) as count_order
FROM
lineitem
WHERE
l_shipdate <= dateadd(dd, -90, '1998-12-01')
GROUP BY
l_returnflag,
l_linestatus
ORDER BY
l_returnflag,
l_linestatus
OPTION (maxdop 4)
Compleja
SELECT
100.00 * sum(case
when p_type like 'PROMO%'
then l_extendedprice*(1-l_discount)
else 0
end) / sum(l_extendedprice * (1 - l_discount)) as
promo_revenue
FROM
lineitem,
part
WHERE
l_partkey = p_partkey
and l_shipdate >= '1995-09-01'
and l_shipdate < dateadd(mm, 1, '1995-09-01')
OPTION (maxdop 4)
61
Factores que afectan a la tasa de consumo de las consultas
No todas las consultas alcanzarán la Tasa máxima de consumo de CPU (MCR) o la Tasa de
consumo de simulación (BCR). Hay muchos factores que pueden afectar a la tasa de consumo
de una consulta. Las consultas más simples que la carga de trabajo usadas para generar la
tasa de consumo tendrán tasas de consumo mayores y las cargas de trabajo más complejas
tendrán tasas de consumo menores. Hay muchos factores que pueden afectar a esta
complejidad y a la tasa de consumo, por ejemplo:





62
Complejidad de la consulta: cuanta más CPU emplee la consulta, por ejemplo en
términos de cálculos y número de agregaciones, menor será la tasa de consumo.
Complejidad de ordenación: las ordenaciones derivadas de operaciones explícitas
order by o group by generarán más carga de trabajo de CPU y reducirán la tasa de
consumo. Las escrituras adicionales en tempdb que se producen porque esas
consultas se desbordan en el disco afectan negativamente a la tasa de consumo.
Complejidad del plan de consulta: cuanto más complejo sea un plan de consulta,
y cuantos más pasos y más operadores haya, menor será la tasa de consumo de CPU,
ya que cada unidad de datos se procesa a través de una canalización de operaciones
más larga.
Compresión: la compresión reducirá la tasa de consumo de datos en términos reales,
ya que la tasa de consumo se mide por definición para las consultas que están limitadas
por CPU y la descompresión consume ciclos de CPU. Sin embargo, las mayores
ventajas de rendimiento suelen compensar la sobrecarga adicional de CPU que supone
la compresión, a menos que la carga de trabajo haga un uso intensivo de la CPU. A la
hora de comparar las tasas de consumo para los datos comprimidos y sin comprimir,
hay que tener en cuenta el factor de compresión. Otra forma de verlo es pensar en la
tasa de consumo en términos de filas por segundo.
Uso de datos: descartar datos durante los recorridos (por ejemplo, mediante proyección
y selección de consultas) es un proceso muy eficiente. Las consultas que usan todos los
datos de una tabla tienen menores tasas de consumo, ya que se procesan más datos por
rendimiento de datos unitarios.