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

ContenidoHistorial 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..................................................................................28

Arquitectura de datos............................................................................................................................29

Estructura de tabla............................................................................................................................29

Particionamiento de tablas................................................................................................................30

Indización..........................................................................................................................................31

Índices de almacén de columnas optimizados en memoria xVelocity...............................................31

Estadísticas de base de datos............................................................................................................33

Compresión.......................................................................................................................................34

Administrar la fragmentación de datos.................................................................................................34

Fragmentación del sistema de archivos.............................................................................................34

Varios grupos de archivos..................................................................................................................37

Cargar datos..........................................................................................................................................37

Cargas incrementales........................................................................................................................37

Migración de datos............................................................................................................................40

Simulaciones y validación..........................................................................................................................42

Realizar la validación de línea base de FTDW........................................................................................43

Pruebas de línea base con SQLIO.......................................................................................................43

Realizar simulaciones de base de datos de Fast Track...........................................................................46

Calcular MCR.....................................................................................................................................47

Calcular BCR.......................................................................................................................................48

Arquitecturas publicadas de referencia de FTDW.....................................................................................51

Conclusión.................................................................................................................................................51

4

Apéndice....................................................................................................................................................53

Herramienta de ajuste de tamaño de FTDW.........................................................................................53

Validar una FTRA definida por el usuario...............................................................................................53

Prueba de E/S sintética......................................................................................................................53

Generar archivos de prueba con SQLIO.............................................................................................53

Prueba de cargas de trabajo..................................................................................................................56

Medir el valor MCR para el servidor (opcional).................................................................................56

Medir el valor BCR para la carga de trabajo.......................................................................................56

Factores que afectan a la tasa de consumo de las consultas.............................................................61

5

Historial de cambios de FTDWEn 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 Nota Ubicación

Nuevo en SQL Server 2012 4.0

Vínculos a otros documentos de prácticas recomendadas de SQL Server

Importante

Nuevo en SQL Server 2012 4.0 Simulaciones y validación Precaución

Nuevo en SQL Server 2012 4.0 Requisitos de memoria RAM

Nuevo en SQL Server 2012 4.0

Índices de almacén de columnas optimizados en memoria xVelocity

Índices de almacén de columnas

Nuevo en SQL Server 2012 4.0 Almacenamiento de estado

sólido Estado sólido

Nuevo en SQL Server 2012 4.0 Validación e índices de

almacén de columnas Validación

Nuevo en SQL Server 2012 4.0 Validación de E/S de línea base SQLIO

Tabla 1: historial de cambios

IntroducciónEn 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.

AudienciaLa 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 TrackLa 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 valorLos 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ísticaLas 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 trabajoLas 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 validadasTodas 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.

ResumenLa 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 datosLas 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 trabajoA 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 datosPuede 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 Afinidad de carga de trabajo:Almacenamiento de datos OLTP/ODS

Descripción del caso de uso

Principalmente lectura (90 %-10 %) Actualizaciones limitadas

normalmente a los requisitos de calidad de datos

Grandes cantidades de inserciones masivas

Simultaneidad de consulta global

Proporción equilibrada de lectura y actualización (60 %-40 %)

Rendimiento de consultas simultáneas caracterizado por las necesidades operativas

12

Atributo Afinidad de carga de trabajo:Almacenamiento de datos OLTP/ODS

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)

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 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

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

Arquitectura de datos

Uso importante de estructuras de tabla del montón

Tablas con particiones grandes con índices clúster que admiten recorridos de alcance limitado

Tablas de hechos muy grandes (por ejemplo, de centenares de gigabytes a varios terabytes)

Tamaños de datos muy grandes (por ejemplo, de centenares de terabytes a un petabyte)

Uso mínimo de estructuras de tabla del montón

Estructuras de tabla de índices clúster que admiten búsquedas de registros detallados (de 1 a pocas filas por solicitud)

Tablas de hechos menores (por ejemplo, menos de 100 GB)

Tamaños de datos relativamente pequeños (por ejemplo, algunos terabytes)

Optimización de base de datos

Uso mínimo de índices secundarios (descrito anteriormente como pocos índices)

La creación de particiones es frecuente

Uso intensivo de optimización de índices secundarios

Tabla 2: atributos de cargas de trabajo de almacenamiento de datos

13

Elegir una configuración de referencia de FTDWHay 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ásicaEn 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 clienteLas 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 trabajoEn 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ónEl 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 trabajoLos 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 datosEsto 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 publicadaUn 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 completaLas 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 procesoEl 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 trabajoEste proceso es el mismo que para la Opción 1: evaluación básica.

Seleccionar el hardware de evaluación de FTDWAntes 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:

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.

16

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-988F-22C3F94B08E0/Fast%20Track%20Core%20Calculator%20v1.2.xlsx.

Paso 2: establecer métricas de evaluaciónLas 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.

MCREsta 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.

BCRBCR 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 usuarioSe 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 WarehouseUna 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/fast-track.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 usuarioEste 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 trabajoEs 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 componentesLo 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 sistemaEl 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 FTRAEn la tabla siguiente se resumen las tres opciones de selección de una FTRA.

Opción Ventajas InconvenientesEvaluación básica 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

Posibilidad de almacenamiento excesivo o de menos capacidad de CPU de la especificada

Evaluación completa Arquitectura de referencia predefinida adaptada a la carga de trabajo esperada

Posible ahorro de costos en hardware

Mayor confianza en la solución

La evaluación conlleva esfuerzo y tiempo (de semanas a meses)

Necesita información detallada de la carga de trabajo de destino

Arquitectura de referencia definida por el usuario

Posibilidad de reutilizar hardware existente

Posibilidad de incorporar el hardware más reciente

Sistema muy optimizado para su caso de uso

El proceso dura varios meses

Necesita muchos conocimientos de la infraestructura

Necesita muchos conocimientos de SQL Server

Tabla 3: comparación de las distintas opciones de evaluación

19

Configuración estándar de FTDW

Arquitectura de los componentes de hardwareLas 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 servidorRAM 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 memoria máxima proporcionados no son límites estrictos, sino que representan valores promedio para sistemas validados correctamente.

20

Tamaño del servidor Memoria mínima Memoria máxima1 socket 64 GB 128 GB2 sockets 128 GB 256 GB4 sockets 256 GB 512 GB8 sockets 512 GB 768 GBTabla 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 fibraHBA – 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 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.

21

AlmacenamientoDisco 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 R2A 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 está instalado como un rol Servidor de aplicaciones para asegurar la correcta instalación y los valores predeterminados de .NET Framework.

22

SQL Server 2012 Enterprise

Opciones de inicioSe 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 SQLEn 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 recursosLas cargas de trabajo de almacenamiento de datos suelen incluir consultas complejas que funcionan sobre grandes volúmenes de datos. Estas consultas pueden consumir mucha memoria y pueden volcarse a un disco si se limita la memoria. Este comportamiento tiene

23

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 almacenamientoAdministrar 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 almacenamientoLa 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:

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.

24

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 almacenamientoPara 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 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

25

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.

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.

26

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)

Asignación mínima de registro recomendadaEspacio disponible reflejado en GB

<= 96 <=10 300 GB X 1 volumen

<= 128 >10 <=40

300 GB X 2 volúmeneso bien600 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ólidoLas 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.

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

27

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ólidoSe 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.

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 FTDWLas 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

28

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 tablaEl 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ónLas 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:

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 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.

29

Tablas de índices clústerEn 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 tablasEl 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).

30

IndizaciónTenga 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 xVelocitySQL 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 recomendadasLos 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 normalizadosLos 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:

Use sugerencias de nivel de consulta para impedir que se use el procesamiento de índices de almacén de columnas.

31

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 dimensionalesSiga 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 columnasLas 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.

32

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 xVelocityLas 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-performance-tuning.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-index-faq.aspx).

Estadísticas de base de datosLa 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 recomendadasSe recomienda seguir estas prácticas recomendadas para las estadísticas de base de datos:

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

33

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ónLas 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 datosLa 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.

34

Fragmentación de extensiónDentro 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;

35

En la tabla siguiente se proporciona una regla general para interpretar los valores de tamaño promedio de fragmento.

Tamaño promedio de fragmento Estado Acción>400 Ideal 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

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 índicesUn í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.

36

Varios grupos de archivosSe 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 datosLa 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 incrementalesEn 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.

37

Proceso de carga de tablas de montónLas 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ústerExisten dos enfoques generales para cargar tablas de índices clúster con una fragmentación de tabla mínima.

Opción 1Use 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 2Cree una tabla de ensayo que coincida con la estructura (incluidas las particiones) de la tabla de destino:

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.

38

Opción 3Esta 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:

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.

39

Migración de datosAbarca 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ónSiga las instrucciones proporcionadas anteriormente para el procesamiento de carga incremental.

Proceso de carga de índices clústerExisten varios enfoques generales para cargar tablas de índices clúster con una fragmentación de tabla mínima.

Opción 1Use 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 2Realice 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 3Use 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 4Use 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.

40

2. Cree un grupo de archivos de ensayo.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.

41

Simulaciones y validaciónEsta 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 baseEl 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 TrackEl 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 xVelocitySQL 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.

42

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 FTDWLa 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 SQLIOEl 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.

43

Paso 1: validar el ancho de banda de E/SEl 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/volumenEsta 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.

44

Paso 3: validar el ancho de banda agregadoEn 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.

45

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

ResumenLas 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 TrackEsta 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:

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.

46

Calcular MCRPara 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 / 10247. 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.

47

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 BCRPara 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.

48

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

49

Esto le da un intervalo para BCR. Si se emplean varias consultas, use un promedio ponderado para determinar el valor de BCR.

Resultados de BCREn 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

50

Interpretar el valor de BCRSi 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 FTDWTodos 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/fast-track.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ónSQL 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.

51

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.

52

Apéndice

Herramienta de ajuste de tamaño de FTDWLa 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/solutions-technologies/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éticaSQLIO 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 SQLIOCuando 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.

53

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

54

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.

Ilustración 10: ancho de banda agregado en varios tamaños de bloque

55

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 trabajoLa 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.

Crear la base de datosA 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.

56

CREATE DATABASE FT_Demo ON PRIMARY Filegroup FT_Demo( NAME = N 'FT_Demo_.mdf' , FILENAME = N'C:\FT\PRI\SE1-SP1-DG1-v1' , SIZE = 100MB , FILEGROWTH = 0 ),( NAME = N 'FT_Demo_v1.ndf' , FILENAME = N'C:\FT\PRI\SE1-SP1-DG1-v1' , SIZE = 417GB , FILEGROWTH = 0 ),( NAME = N 'FT_Demo_v2.ndf' , FILENAME = N'C:\FT\PRI\SE1-SP1-DG2-v2' , SIZE = 417GB , FILEGROWTH = 0 ),( NAME = N 'FT_Demo_v3.ndf' , FILENAME = N'C:\FT\PRI\SE1-SP2-DG3-v3' , SIZE = 417GB , FILEGROWTH = 0 ),( NAME = N 'FT_Demo_v4.ndf' , FILENAME = N'C:\FT\PRI\SE1-SP2-DG4-v4' , SIZE = 417GB , FILEGROWTH = 0 ), ( NAME = N 'FT_Demo_v6.ndf' , FILENAME = N'C:\FT\PRI\SE2-SP1-DG6-v6' , SIZE = 417GB , FILEGROWTH = 0 ),( NAME = N 'FT_Demo_v7.ndf' , FILENAME = N'C:\FT\PRI\SE2-SP1-DG7-v7' , SIZE = 417GB , FILEGROWTH = 0 ),( NAME = N 'FT_Demo_v8.ndf' , FILENAME = N'C:\FT\PRI\SE2-SP2-DG8-v8' , SIZE = 417GB , FILEGROWTH = 0 ),( NAME = N 'FT_Demo_v9.ndf' , FILENAME = N'C:\FT\PRI\SE2-SP2-DG9-v9' , SIZE = 417GB , FILEGROWTH = 0 ), ( NAME = N 'FT_Demo_v11.ndf' , FILENAME = N'C:\FT\PRI\SE3-SP1-DG11-v11' , SIZE = 417GB , FILEGROWTH = 0 ),( NAME = N 'FT_Demo_v12.ndf' , FILENAME = N'C:\FT\PRI\SE3-SP1-DG12-v12' , SIZE = 417GB , FILEGROWTH = 0 ),( NAME = N 'FT_Demo_v13.ndf' , FILENAME = N'C:\FT\PRI\SE3-SP2-DG13-v13' , SIZE = 417GB , FILEGROWTH = 0 ),( NAME = N 'FT_Demo_v14.ndf' , FILENAME = N'C:\FT\PRI\SE3-SP2-DG14-v14' , SIZE = 417GB , FILEGROWTH = 0 ),

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 ONGO

ALTER DATABASE FT_Demo SET AUTO_UPDATE_STATISTICS ONGO

ALTER DATABASE FT_Demo SET AUTO_UPDATE_STATISTICS_ASYNC ON GO

ALTER DATABASE FT_Demo SET RECOVERY SIMPLE GO

sp_configure 'show advanced options', 1go

reconfigure with overridego

********Asegurarse de que todas las tablas están en nuestro grupo de archivos, no en el grupo de archivos principal****/ALTER DATABASE FT_DemoMODIFY FILEGROUP FT_DemoDEFAULTGO

57

Crear las tablas de pruebaA 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_DemoGO

CREATE CLUSTERED INDEX cidx_lineitem ON lineitem(l_shipdate ASC)WITH( SORT_IN_TEMPDB = ON , DATA_COMPRESSION = PAGE )ON FT_DemoGO

Cargar datos para la medida de BCRComo 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.

58

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 BCRUse 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 BCR por núcleo(Página comprimida) con MAXDOP 4

Simple 201 MB/sPromedio 83 MB/sCompleja 56 MB/sTabla 7: ejemplos de simulaciones

Simple

SELECT sum(l_extendedprice * l_discount) as revenueFROM lineitemWHERE l_discount between 0.04 - 0.01 and 0.04 + 0.01 and l_quantity < 25OPTION (maxdop 4)

59

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_orderFROM lineitemWHERE l_shipdate <= dateadd(dd, -90, '1998-12-01')GROUP BY l_returnflag, l_linestatusORDER BY l_returnflag, l_linestatusOPTION (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_revenueFROM lineitem, partWHERE l_partkey = p_partkey and l_shipdate >= '1995-09-01' and l_shipdate < dateadd(mm, 1, '1995-09-01')OPTION (maxdop 4)

60

Factores que afectan a la tasa de consumo de las consultasNo 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:

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.

61