Microsoft Sql Server 2005 Ajuste del rendimiento Código: HOL-SQL13 Microsoft Sql Server 2005 Ajuste del rendimiento Ruben Alonso Cebrian ralonso@informatica64.com

Agenda Ajustes de rendimiento a nivel de servidor Sistemas de disco Memoria Actividad de entrada/salida Ajuste de SMP Ajustes de rendimiento a nivel físico Gestión de datos e indización Operaciones de Indexación en paralelo Optimización de espacio libre y gestión de páginas Ajustes de rendimiento a nivel lógico Particiones Vistas indizadas Ordenación de datos Dmv Reports

Agenda Herramientas de supervisión y diagnóstico de rendimiento Identificación de cuellos de botella Configuración de entorno de supervisión Monitorización del rendimiento Analizador Database Tuning Advisor Alta disponibilidad Arquitectura en Cluster Mirroring Database Log Shipping

Factores que afectan al Rendimiento Factores que afectan al rendimiento de Microsoft Sql Server 2005: Configuración de SQL Server 2005 Modelo físico de datos Modelo lógico de datos Instrucciones SQL

Ajuste del Rendimiento a Nivel de Servidor

Configuración de Microsoft Sql Server 2005 Objetivo: Mejora del rendimiento a través de las propiedades de configuración del servidor SQL Server 2005. Sistema gestor definido como "autoajustable", ya que ajusta dinámicamente su configuración en función de la actividad y el uso de los recursos Se pueden tomar decisiones que pueden mejorar enormemente el rendimiento a nivel de instalación y configuración: Sistemas de disco Memoria Actividad de E/S Ajuste de SMP

Sistemas de disco Cada base de datos en su propio subsistema de disco externo, siendo recomendable ejecutar todos los entornos en sistemas RAID Se obtiene: Mejora de rendimiento en operaciones de lectura y escritura de datos Tolerancia a errores Se evita: Posibles perdidas de datos producidas por error de hardware Tres niveles RAID: RAID 0 RAID 1 RAID 5

Sistemas de disco RAID 0: RAID 1: RAID 10: Divide los datos de manera uniforme entre las unidades físicas. Cada volumen distribuido se llama almacenamiento o conjunto de bandas. No protege contra errores de hardware, aunque puede mejorar enormemente el rendimiento de las operaciones de lectura y escritura. RAID 1: Denominado comúnmente reflejo de disco Escribe datos en dos unidades. Protege contra errores de hardware mediante la creación de dos duplicados exactos de los datos, uno en cada partición del conjunto de espejos. RAID 10: Es el más común en entornos de bases de datos Compuesto por una combinación de RAID 0 y 1. (conocido como RAID 10 o RAID 0/1).

Sistemas de disco RAID 5: Denominado comúnmente bandas de disco con paridad. Distribuye los datos de manera uniforme entre tres o más discos de la misma forma que RAID 0. Tolerancia a errores implementada mediante el cálculo de la información de recuperación acerca de los datos escritos en el disco. (Mediante paridad) Esta información de recuperación (paridad) se distribuye de forma equitativa entre todos los discos participantes, de manera que, si se produce un error en un disco, los datos se pueden reconstruir a partir de la información de paridad contenida en los demás miembros del conjunto de bandas. Protege contra errores en una unidad de disco, pero reduce el rendimiento de las operaciones de escritura

Sistemas de disco Para un rendimiento óptimo se recomienda que: Los siguientes archivos de Microsoft SQL Server se dividan en diferentes conjuntos de almacenamiento: Archivos de registro de transacciones Archivos tempdb Archivos de datos Archivos de índice Los archivos de registro de transacciones y tempdb se coloquen en RAID 0/1, en lugar de en RAID 5 debido a la disminución del rendimiento provocada por el aumento de la velocidad de las operaciones de E/S de escritura

Memoria Comportamiento: MEMORIA Por defecto, Microsoft SQL Server 2005 asigna toda la memoria física disponible en el servidor, pero deja al sistema operativo suficientes recursos para evitar una paginación excesiva Configurado para asignar y liberar memoria de forma automática y dinámica para cada de las áreas de memoria, según sea necesario para obtener un rendimiento óptimo Estructuras de datos de sistema Caché de registro Caché de procedimientos Contexto de conexión Caché de búfer de datos MEMORIA

Memoria Parámetro Función Configuración manual mediante ejecución de código Transact/sql: sp_configure. sp_configure "show advanced options", 1 go Reconfigure sp_configure "min server memory", 32 go Parámetro Función max server memory: Cantidad máxima de memoria asignada por SQL min server memory: Cantidad mínima de memoria asignada por SQL min memory per query Cantidad mínima de memoria asignada por cada consulta index create memory Cantidad de memoria que utilizan las operaciones de ordenación durante la creación de índices

Memoria Dynamic AWE memory Posibilidades de expansión de la memoria más allá del espacio de memoria virtual configurado Windows Server 2003 Edition Maximum Physical Memory Standard 4 GB Enterprise 32 GB Datacenter 64 GB

Memoria Hot-add memory Si el hardware soporta esta funcionalidad , puede añadirse memoria al servidor sin reiniciar Configuración automática Enterprise y Datacenter edition con la opción awe enabled configurada y el modificador –h  

Actividad de E/S Intentar reducir en la medida de lo posible la actividad de E/S que se produce principalmente por: Operaciones de escritura en los registros de transacciones debido a la creación de registros Operaciones de lectura o escritura en los archivos de datos o de índice que se originan a partir de solicitudes que no se pueden satisfacer en la caché de datos En diversa actividad de disco como consecuencia del comportamiento del sistema SQL Server, por ejemplo, la ordenación de datos en el disco o la ejecución periódica de puntos de comprobación.

Actividad de E/S Para controlar el rendimiento de e/s Microsoft Sql Server dispone de los parámetros: Recovery interval (intervalo de recuperación) Número mínimo de minutos que SQL Server necesita para recuperar las bases de datos. Max async io (nº máx. de operaciones asincrónicas de E/S) Número máximo de solicitudes de E/S pendientes por archivo Recovery interval: Establecido en un minuto aproximadamente, mediante este parámetro se modifican los puntos de comprobación Ventaja : Reduce la actividad de E/S que se produce como resultado del vaciado de la caché Inconveniente: Aumento del tiempo de recuperación.

Actividad de E/S Max async io: Establecido a 32 solicitudes de E/S pendientes a un archivo como máximo. Mejora del rendimiento de E/S aprovechando las solicitudes de E/S asincrónicas que SQL Server envía a Windows 2000 y la controladora de disco Aceptable para controladoras de disco no muy sofisticadas Posibilidad de aumentar para controladoras de disco inteligentes, reduciendo el movimiento de los cabezales del disco. Modificación de los parámetros mediante el código transact-sql: sp_configure "max async IO", <valor> Go Reconfigure Go Para modificar la frecuencia de puntos de comprobación: sp_configure "recovery interval", <valor> Go Reconfigure go

Ajuste de SMP (Symmetric Multiprocessor Machine) Mejora del rendimiento mediante varias CPUS Tecnología de alta escalabilidad Microsoft Sql Server utiliza varios subprocesos para dividir las tareas entre las distintas CPU Cada uno de los subprocesos se ejecuta en una CPU independiente Ejemplo de rendimiento obtenido: Consultas en paralelo dividiendo determinadas consultas entre los subprocesos para recorrer las tablas Obtención de porcentaje de aciertos en la cache del 98% Para su configuración, se dispone de los siguientes parámetros: affinity mask max worker threads max degree of parallelism cost of threshold for parallelism

Ajuste de SMP (Symmetric Multiprocessor Machine) Affinity mask: Indica el número de CPU’s a utilizar. Un valor de 0 permite a Sql Server utilizar todas las disponibles. Max worker threads: Indica el número máximo de subprocesos (por defecto 0). Para un número mayor de subprocesos, Microsoft SQL Server 2005 utiliza el agrupamiento de los mismos si hay más de 255 conexiones simultáneas. Max degree of parallelism: determina el número máximo de subprocesos asignados a una consulta Cost of threshold for parallelism: determina el uso o no del proceso en paralelo comparándolo con los costes normales de la ejecución de una consulta sin ejecución en paralelo Parámetro Función Affinity mask Asociación entre un procesador y un subproceso Max worker threads Número máximo de subprocesos secundarios disponibles para SQL Server max degree of parallelism Número máximo de procesadores que se deben utilizar en la ejecución de planes en paralelo cost of threshold for parallelism El umbral para la creación y ejecución de planes en paralelo

Ajuste del Rendimiento a Nivel Físico

Modelo físico de datos de la base de datos Objetivo: Ganancia de rendimiento mediante un buen diseño del almacenamiento físico para los objetos de la base de datos Implementado mediante grupos de archivos para distribuir los datos de tablas o índices entre los discos Relleno proporcional para aquellos grupos de archivos con más de un fichero Para un correcto modelo físico se deben tener en cuenta los siguientes factores: Número de grupos de archivos que se deben crear. Número de archivos de datos que se deben crear. Número de archivos de datos por cada grupo de archivos. En qué conjunto de almacenamiento (o disco) debe colocarse cada archivo de datos En qué grupo de archivos debe colocarse cada objeto de base de datos (como una tabla o índice)

Modelo físico de datos de la base de datos Recomendaciones para un alto rendimiento: Utilizar diversos grupos de archivos para colocar objetos en discos físicos específicos. Crear uno o varios grupos de archivos secundarios para archivos adicionales y configurar uno de ellos como predeterminado. Utilizar el grupo de archivos principal para contener sólo las tablas del sistema. Utilizar grupos de archivos para distribuir los datos entre tantos discos como sea posible. Si en la aplicación hay una zona a la que se tiene acceso con mucha frecuencia, considerar la posibilidad de colocarla en un disco aparte. Separar los datos que se recorren de forma secuencial de aquéllos a los que se tiene acceso de forma directa (mediante un índice). Separar los índices no agrupados de los datos de las tablas..

Modelo físico de datos de la base de datos Para agregar un grupo de archivos y un archivo adicional a una base de datos de aplicación existente, utilice el comando ALTER DATABASE. Ejemplo: creación de un segundo grupo de archivos para la base de datos Adventureworks: alter database Adventureworks add file group secundario A continuación procedemos a la adición de un archivo de datos al nuevo grupo de archivos Alter database Adventureworks add file ( name = 'nombreDeArchivoLogico', filename = 'c:\Archivos de programa\Microsoft SQL Server\MSSQL\ DATA\nombreDeArchivoFisico.NDF', SIZE= tamañoRequerido ) to file group secundario Por ultimo, podríamos crear un objeto y asociarlo a un grupo específico: Create table Pruebas on secundario

Demo: Gestión de nuevos grupos de archivos

Gestión de datos e Indización Dos métodos de acceso a los datos: Recorrido secuencial de toda la tabla Uso de índices para búsqueda directa de datos Dos estrategias de índices diferentes: Índices Agrupados Índices No agrupados Creación de índices planeada con mucho cuidado El exceso de índices puede producir: 1º- Que el optimizador emplee demasiado tiempo en la creación y evaluación de los posibles planes de ejecución 2º- Disminución del rendimiento de escritura

Gestión de datos e Indización Índice Agrupado: Mejoran el rendimiento al almacenar los datos de la tabla junto con datos de nivel de hoja del índice. Esto significa que cuando SQL Server 2005 lee la entrada de un nodo de hoja de índice agrupado, lee al mismo tiempo la fila de datos de la tabla. Sólo puede haber un índice agrupado por tabla El índice agrupado no se puede separar en diferentes grupos de archivos de los datos de la tabla. Índice No agrupado: Sólo se almacena un identificador único (identificador de fila) en el nivel de hoja. En consecuencia, con los índices no agrupados es preciso realizar operaciones de E/S adicionales para recuperar los datos de la tabla.

Gestión de datos e Indización ¡¡ Ojo !!: La desventaja de un índice agrupado cuando cohabitan en una tabla un índice agrupado y uno no agrupado. Comportamiento Interno: El índice no agrupado no apunta directamente a la fila de la tabla, sino que utiliza los valores del índice agrupado como punteros a las filas de la tabla. En consecuencia, las operaciones de lectura que recorren un índice no agrupado tienen que descender primero por el árbol B del índice no agrupado. Tras encontrar el valor en el nivel de hoja, tienen que descender por el árbol B del índice agrupado. Además, la actualización de las columnas con índices agrupados provoca movimientos de filas, porque las filas actualizadas deben colocarse según el orden del índice agrupado.

Gestión de datos e Indización Cuando crear Índices Agrupados: Consultas que requieren resultados ordenados o resultados intermedios ordenados, por ejemplo, las operaciones de combinación. Consultas que recuperan uno o varios intervalos estables. Estas consultas suelen contener el predicado BETWEEN en la cláusula WHERE Cuando crear Índices No agrupados: En columnas para las consultas que están restringidas en el predicado WHERE y tengan una selectividad alta.

Gestión de datos e Indización

Optimización de espacio libre y gestión de páginas Datos almacenados en dos tipos de objetos de base de datos: tablas e índices. Las tablas almacenan los datos en estructuras de memoria secuenciales ordenadas o sin ordenar. La estructura sin ordenar se llama tabla de montón y la estructura ordenada se denomina tabla agrupada. Diferencia principal entre ambas estructuras: Las filas de las tablas de montón se almacenan en secuencia aleatoria, mientras que las filas de las tablas agrupadas se ordenan según las columnas del índice agrupado. Consecuencia: la colocación de una nueva fila en una tabla agrupada se calcula durante la operación de inserción mediante el valor de índice y la fila se almacena en la página correspondiente. Si la tabla y sus índices crecen en el futuro, existe el riesgo de que las páginas se dividan y se reequilibre el árbol B.

Optimización de espacio libre y gestión de páginas La división de páginas puede influir desfavorablemente en el rendimiento de E/S. Para controlar la división de páginas en Microsoft Sql Server existen dos parámetros: Parámetro Función Fillfactor: Porcentaje que indica cuanto debe llenar SQL Server el nivel de hoja de cada página de índices. Sirve para especificar un “espacio” vacío que se debe dejar en cada página que se destinará a nuevas actualizaciones e inserciones. Pad_index: Especifica el espacio que se debe dejar libre en cada página (nodo) en los niveles intermedios del índice (siempre al menos una fila libre del tamaño máximo que puede almacenar un índice)

Optimización de espacio libre y gestión de páginas Configuración manual mediante ejecución de código CREATE TABLE(….) [WITH FILLFACTOR = valor] [ON grupoArchivos] Los índices no agrupados se crean con la siguiente instrucción T-SQL: CREATE [UNIQUE] INDEX nombreIndice ON nombreTabla (nombreColumna,..) [PAD_INDEX] [WITH FILLFACTOR = valor] [ON grupoArchivos] Los índices agrupados se crean con la siguiente instrucción T-SQL: CREATE [UNIQUE] CLUSTERED INDEX nombreIndice ON nombreTabla (nombreColumna,..) [PAD_INDEX] [WITH FILLFACTOR = valor] [ON grupoArchivos]

Ajuste del Rendimiento a Nivel Lógico

Nivel Lógico Objetivo: Mejora del rendimiento a través de una buena estructuración de los datos de forma lógica mediante tablas y relaciones. Gran repercusión en el rendimiento a través de: Particiones Vistas indizadas Instrucciones Sql Ordenación de datos

Particiones Permite a una tabla extenderse en varios grupos físicos de archivos Resultados Aumento del rendimiento en entornos multiprocesador con 8 o más procesadores, ejecución en paralelo. Facilidad de manejo de grandes tablas Transparente a la aplicación La fila es la unidad de particionado

Particiones Método para dividir los datos de las tablas y de los índices Dos tipos de particiones: - Verticales: Debidas al proceso de normalización - Horizontales: Proceso de división de un gran número de filas en varias tablas llamadas particiones teniendo todas las tablas (particiones) la misma estructura Particiones horizontales utilizadas para: 1º- Distribuir los datos entre grupos de archivos físicos diferentes en una misma base de datos, con lo que se reduce la competición por los recursos. 2º- Distribuir los datos entre varios servidores, con lo que se escala la base de datos para mejorar la simultaneidad.

Vistas Indizadas Definición: Vista creada a partir de una vista normal mediante la aplicación de un índice agrupado único para la vista. A continuación, el conjunto de datos especificado se almacena como una agrupación o una estructura de memoria ordenada. Después de crear el índice agrupado, se pueden aplicar otros índices no agrupados en el almacenamiento. Uso de vistas indizadas en: 1º- Aplicaciones que realizan muchas operaciones de lectura. 2º- En el caso de que las instrucciones SELECT recuperen un conjunto de resultados que sea un agregado, lo que incluye la realización de sumas u otros cálculos en una o varias tablas diferentes.

Vistas Indizadas No se recomienda su uso en: 1º- Aplicaciones que realizan muchas operaciones de escritura o actualizaciones. 2º- Consultas que no incluyan agregaciones ni combinaciones Proceso de creación de vistas indizadas: 1º- Creación de una vista con la opción SCHEMABINDING. Esta opción no permite cambios en el esquema de ninguno de los objetos subyacentes que participan en la vista materializada. No se puede crear un índice en una vista sin utilizar esta opción. 2º- Creación de un índice agrupado único en la vista. La vista se materializa en este punto. 3º- Si se desea, creación de otros índices no agrupados en la vista.

Vistas Indizadas El optimizador utiliza una vista indizada si: 1º- Encuentra una coincidencia entre las columnas indizadas de la vista y los elementos de la consulta como: - Predicados de condiciones de búsqueda en la clausula where. - Operaciones de combinación - Funciones de agregado 2º- El costo estimado de utilización del índice es el más bajo de los mecanismos de acceso realizados por el optimizador.

Instrucciones SQL Ejemplo: * Subconsulta sin correlación select od.ord_id, od.ord_it_name, od.amount from orders od where cust_id NOT IN (select cust_id from revenue) * Subconsulta con correlación select od.ord_id, od.ord_it_name, od.amount from orders od where NOT EXISTS (select rv.cust_id from orders od, revenue rv where od.cust_id = rv.cust_id) * Combinación externa SELECT od.ord_id, od.ord_it_name, od.amount from orders od LEFT OUTER JOIN revenue rv ON od.cust_id = rv.cust_id WHERE rv.cust_id is NULL Ganancia de rendimiento mediante una correcta codificación de instrucciones t-sql Dos formas de proceder: Acceso a base de datos orientado a registros Acceso a base de datos orientado a conjuntos T-sql no Ortogonal Se puede obtener el mismo conjunto de registros de diferentes formas:

Instrucciones SQL Recuperar sólo la información necesario y nunca datos de más de la cuenta Agregar, quitar o modificar índices Utilizar siempre que se puedan Procedimientos almacenados en vez de consultas Analizar el plan de ejecución de los procesos Argumentos de búsqueda: partes del query que acotan las búsquedas (los índices deberían estar armados para ayudarnos en esto !). =, >, <, >=, <=, BETWEEN, LIKE, IN Los operadores lógicos AND y OR agrupan argumentos de búsqueda. No se consideran argumentos de búsqueda: - Comparaciones entre columnas: Total > Presupuesto - Cálculos: Subtotal * 1.7

Instrucciones SQL Búsqueda de JOINs en la consulta Microsoft recomienda no utilizar la cláusula WHERE; si, en cambio, usar ON. SELECT Apellido, Nombre FROM Clientes, Cuentas WHERE Clientes.Cliente_ID = Cuentas.Cliente_ID AND Cuentas.Nivel = ‘VIP’ T-SQL SELECT Apellido, Nombre FROM Clientes INNER JOIN Cuentas ON Clientes.Cliente_ID = Cuentas.Cliente_ID WHERE Cuentas.Nivel = ‘VIP’ ANSI

Instrucciones SQL Utilizar Procedimientos almacenados siempre que se pueda El código ya esta chequeado, normalizado y optimizado Usar sp_recompile si el código del SP se modifica Emplear los triggers con cautela (tanto INSTEAD OF como AFTER) Evitar el uso de cursores Usar OLE DB para acceder a datos (evitar ODBC si se puede) Si se testea su validez, utilizar hints para indicar mandatos al optimizador

Ordenaciones de datos Ganancia de rendimiento a través de una correcta ordenación de los datos Filas ordenadas y procesadas de forma estricta mediante la cláusula ORDER BY. DISTINCT y UNION requieren un orden para quitar los valores duplicados. Si no se especifica un orden, las filas se seleccionan según su colocación física en el disco y la estrategia de acceso elegida en el motor de consultas, por lo que entrará en juego si existen o no índices agrupados o no agrupados. Los índices de cobertura no requieren ordenamiento (Create Index xxx on Tabla(campo1, campo2, campo3, campon)

DMV Reports Utilice las vistas de gestión dinámicas (Dynamic Management Views) para explorar y optimizar SQL Server 2005. Con DMV accederá a las partes internas del motor de SQL Server y conociendo como utilizar e interpretar la información que ofrece y que es clave para entender y gestionar su entorno SQL Server 2005

Herramientas de supervisión y diagnóstico de rendimiento

Identificación de cuellos de botella Proceso por el cual se identifican las funciones o instrucciones importantes que son responsables del exceso de carga. Recogida y análisis de información identificando los factores que puedan intervenir en el cuello de botella. Determinadas preguntas pueden ayudar en el proceso de identificación: 1º- ¿Cuáles son las tareas más frecuentes (llamadas de usuarios finales, llamadas de interfaz, llamadas del sistema, etcétera)? 2º- ¿Cuáles son las funciones críticas con respecto al tiempo transcurrido (por ejemplo, la selección de datos en diferentes tablas que rellenan un cuadro de diálogo para el usuario final)? 3º-¿Cuáles son las funciones más importantes (tarea principal de la aplicación)? 4º-¿Cuáles son las funciones que consumen más recursos (funciones que son muy complejas con respecto al algoritmo implementado)?

Identificación de cuellos de botella El rendimiento global de un sistema se puede definir por el tiempo transcurrido en un caso de uso determinado o un caso de prueba Seguimiento del rendimiento global y supervisión del sistema mediante tres herramientas: 1º- Monitor de rendimiento de SQL 2º- Analizador SQL 3º- SQL Management Studio

Monitor de Rendimiento Utilizado para medir la actividad de la CPU, la actividad de E/S y el uso de la memoria. Identificación de cuellos de botella mediante contadores predefinidos: Contador % de tiempo de usuario del objeto Procesador (Uso de CPU) Si permanece de forma continua en un nivel igual o superior al 80 por ciento, existe un cuello de botella en la CPU. Algunas razones posibles del cuello de botella son: Número y tipo de instrucciones SQL Número y tipo de operaciones de combinación Número de operaciones de ordenación

Monitor de Rendimiento Contadores a controlar y supervisar: 1º -Contador para la supervisión de la actividad en disco: Contador de transferencias de disco por segundo del objeto Disco físico. 2º- Contador para controlar la caché de datos (aspecto más importante de SQL Server 2000). El contador predefinido que se indica a continuación está reservado para medir el porcentaje de páginas de datos que se encuentran en la caché de datos, en lugar de leerse del disco: Contador Proporción de aciertos de caché del búfer del objeto Administrador de búfer. Se recomienda que la proporción de aciertos de caché sea superior al 95 por ciento.

Monitor de Rendimiento

Analizador Utilizado para buscar instrucciones SQL críticas y medir los efectos de las intervenciones de ajuste. Con esta herramienta puede supervisar el tiempo que tarda en ejecutarse una instrucción SQL. Centre su atención en las columnas de duración, lecturas, escrituras y CPU para encontrar las instrucciones SQL críticas.

Database Tuning Advisor

Database Tuning Advisor

Database Tuning Advisor Alta disponibilidad

Plataforma de BBDD 64-bit Escalabilidad Optimizado para Windows Server 2003 Soporte para AMD Opteron & Intel Itanium with Beta 2 Intel EM64T soportado en Beta 3 Excelente rendimiento Direccionamiento de memoria a gran escala (hasta 32TB) Memoria virtual prácticamente ilimitada (hasta 8 TB) Menos operaciones de E/S al utilizar pools de memoria más grandes Compatibilidad de código T-SQL con SQL Server 2000 Soporte para cluster de hasta 8 nodos El mismo formato en disco que con la versión de 32 bits, para facilitar la migración Soporte de 64bit para el motor relacional y BI Se constituye en alternativa a soluciones UNIX de alto coste Administración Ahorro de costes Microsoft ha anunciado que dará soporte a AMD Opteron con arquitectura Direct Connect Architecture en Microsoft SQL Server 2005, la nueva generación del producto insignia de base de datos. Esta funcionalidad mejorada proporciona a los clientes y partners una plataforma de alto rendimiento para sistemas de 32 y 64 bits simultáneamente, lo que supone una enorme flexibilidad técnica y de negocio a la hora de resolver sus problemas particulares, con una solución que se adapta a sus necesidades. Además, ofrece a los clientes una alternativa con un coste muy competitivo a las soluciones basadas en UNIX mediante características de 64 bits que posibilitan una gran escalabilidad y un bajo coste de propiedad. Al introducir la arquitectura Extended System de AMD en SQL Server 2005, Microsoft aporta una nueva oferta complementando al soporte actual de sistemas de alto rendimiento de 64 bits de Intel en SQL Server 2000. La plataforma de base de datos más escalable, para aplicaciones de negocio intensivas en memoria y donde el rendimiento es el factor crítico

Ediciones de 64 bits Hasta 4 CPUs Máximo número de CPUs que soporte el S.O. La máxima memoria que el S.O. de 64bit soporte Completo Mirroring de la DB con Disaster Recovery Snapshot de DB Fast Redo Restauración de ficheros, páginas e indexación Online Backups en espejo Operaciones de Indexación en paralelo Vista de índices avanzada Hasta 4 CPUs La máxima memoria que el S.O. de 64bit soporte Mirror de DB local Cluster de failover de 2 nodos Soporte de vista de índices básica Guía de planes personalizados

Arquitectura en Cluster Windows 2003 y SQL Server 2005 admiten el modelo de clúster sin elementos compartidos, lo que significa que cada nodo del clúster es un equipo independiente con sus propios recursos y sistema operativo. Necesario un array de discos SCSI con raiz 5 o raiz 10 Cada nodo administra sus propios recursos y proporciona servicios de datos sin compartir. En el caso de producirse un error en un nodo, los discos y servicios que se ejecutan en él se pueden conmutar (o reiniciar) en un nodo que esté en funcionamiento, pero sólo un nodo administra un conjunto determinado de discos y servicios en cada momento.

Configuración de conmutación tras error Dos configuraciones posibles: 1ª- Configuración de conmutación tras error (activo-pasivo) con una sola instancia 2ª- Configuración de conmutación tras error (activo-activo) con varias instancias Configuración de conmutación tras error con una sola instancia El clúster ejecuta una sola instancia de SQL Server. Si se produce un error en el servidor principal, el otro servidor del clúster puede ejecutar la misma instancia. De este modo, ambos servidores comparten una base de datos maestra y el conjunto de bases de datos de usuario. Configuración de conmutación tras error con varias instancias Cada uno de los dos nodos activos tiene su propia instancia de SQL Server. Cada instancia de SQL Server es una instalación diferente con todos los servicios y se puede administrar, actualizar y detener de forma independiente.

Failover Clustering Microsoft Cluster Services Hot Standby – Automatic failover Construido sobre Microsoft Cluster Services (MSCS) Múltiples nodos proporcionan disponibilidad, transparente al cliente Detección y failover automáticos Soporta múltiples escenarios: Activo/Activo, N+1, N+I Instance Failover – la instancia entera funciona como una unidad Copia única de las bases de datos de la instancia Disponible desde SQL Server 7.0 Failover Cluster Un clúster de conmutación por error es una solución de alta disponibilidad que explota Microsoft Windows Clustering Services para crear servidores virtuales resistentes a errores que permiten una rápida conmutación por de errores en servidores de bases de datos. En la versión SQL Server 2005 SQL, Server Analysis Services, Notification Services y la réplica para SQL Server también cuentan con clústeres de conmutación por error. La cantidad máxima de nodos de clústeres ha aumentado a ocho. Los clústeres de conmutación por error del SQL Server constituyen ahora una solución completa para servidores resistentes a errores. Disponibilidad Reflejo de base de datos Clústeres de conmutación por error Conmutación por error automática Sí Sí Redirección transparente para clientes Sí, redireccionar directamente Sí, volver a conectar al mmismo IP Impacto sobre la productividad general Poco o ningún impacto Ningún impacto No se pierde el trabajo realizado Sí Sí Requiere hardware certificado No Sí Brinda información redundante Sí No Failover clustering is a high-availability solution that exploits Microsoft Windows Clustering Services to create fault-tolerant virtual servers that provide fast failover in the event of a database server failure. In SQL Server 2005, support for failover clustering has been extended to SQL Server Analysis Services, Notification Services, and SQL Server replication. The maximum number of cluster nodes has been increased to eight. SQL Server failover clustering is now a complete fault-tolerant server solution. A failover cluster is a combination of one or more nodes (servers) with two or more shared disks, known as a resource group. The combination of a resource group, along with its network name, and an internet protocol (IP) address that makes up the clustered application or server, is referred to as a virtual server. A SQL Server virtual server appears on the network as if it were a single computer, but has functionality that provides failover from one node to another if the current node becomes unavailable. A failover cluster appears as a normal application or server, but it has additional functionality that increases its availability. Both the server cluster itself and the SQL Server instance installed on a cluster server can be considered virtual servers. Support for multiple instances of SQL Server 2005 differs in the failover clustering scenario: you can create multiple virtual servers in a cluster, but each virtual server can have only one instance of SQL Server installed.

Failover Clustering Microsoft Cluster Services Mejorado en SQL Server 2005 Más nodos Coincide con los límites del sistema operativo Configuración desatendida Participan todos los servicios de SQL Server Database Engine, SQL Server Agent, Analysis Services, Full-Text Search, etc. Failover Cluster

Array de discos compartido Arquitectura en Cluster LAN LAN SQL 2005 Virtual Server - MSCS SQL 2005 Virtual Server - MSCS Nodo A Nodo B Heartbeat Array de discos compartido

Arquitectura en Cluster Características Server Virtual Se le asigna un nombre Se le asigna una IP Para el cliente, es indistinto y transparente el nodo que le brinda servicio Pros del Clustering Reduce al mínimo los tiempos de un server caído Tiene respuesta automática ante la caída de un nodo No se necesita renombrar los servidores La recuperación es rápida: tan pronto se arregle el server Contras del Clustering Costo mayor que un Stand by server Precisa más tiempo en la instalación Requiere un mantenimiento mayor Requiere administradores de red y DBA’s con más experiencia

Database Mirroring SQL Server 2005 incluye un nuevo soporte para volúmenes de backup espejados, aumentando la disponibilidad de las copias de seguridad de SQL Server. La posibilidad de replicar el backup permite resolver posibles problemas de corrupción del medio físico de copia.

Log Shipping Microsoft SQL Server 2005 amplía las posibilidades de duplicación de logs (“log shipping”) proporcionando la opción de mirroring. Se puede usar esta funcionalidad para garantizar la disponibilidad de los sistemas SQL mediante la configuración de un servidor en espera para su activación automática en caso de fallo (failover). Integrantes del log shipping: 1 Servidor de producción (Primario) 1 ó más servidores receptores (Secundarios) 1 Servidor de monitorización (Monitor)

Log Shipping Standby Server Producción Monitor Backup Restore de Log Copia de Log de Log

Próximas Acciones 17/09/2005. HOL – Windows Server 2003. IPSec 18/09/2005. Evento – Windows Update Services 20/10/2005. Contramedidas Hacker. 21/10/2005: Gira Seguridad Technet.

Boletín quincenal TechNews

Contactos Informática 64 Profesor http://www.informatica64.com i64@informatica64.com +34 91 665 99 98 Profesor ralonso@informatica64.com