Skip to main content

Gestionando los recursos de los servidores en SQL Server 2008

Contenidos

Introducción

A partir de la versión 2008 de SQL Server aparece una nueva característica denominada Resource Governor. Resource Governor permite administrar la carga de trabajo de SQL Server y recursos del servidor; con esta característica se persigue poder configurar SQL Server en escenarios de configuraciones mixtas, como por ejemplo un servidor de bases de datos que combina cargas transaccionales puras (OLTP) con cargas analíticas (BI), o un servidor analítico que requiere que los procesos de carga de datos no consuman excesivos recursos frente a las necesidades de Reporting tradicionales; en definitiva, poder gestionar diferentes tipologías de procesamiento para que se usen los recursos del servidor de la manera más concurrente posible sin causar cuellos de botella en dichos recursos. Para ello, como veremos a lo largo del artículo, el administrador de bases de datos podrá asignar prioridades y cuotas al uso de CPU y memoria, y configurar tiempos de respuesta y umbrales máximos de concurrencia de las conexiones. Esta característica está disponible a partir de la edición Enterprise porque se considera que la característica resuelve escenarios de configuraciones mixtas y complejas.

Este artículo está dirigido a profesionales IT (tecnologías de la información) y administradores de base de datos. En este artículo daremos una vuelta completa a lo que es Resource Governor y cómo un administrador de bases de datos puede sacar provecho de Resource Governor.

¿Qué es Resource Governor?

Resource Governor es un conjunto de tecnologías dentro del motor de base de datos que nos permite establecer controles sobre diversos componentes del servidor como CPU y/o memoria.  Además se pueden establecer estos controles de forma agregada, haciendo por ejemplo que la suma del uso de CPU de un conjunto de usuarios no supere cierto umbral previamente configurado. Para comprender mejor el concepto de Resource Governor podemos realizar la siguiente analogía con el policía que regula un atasco, el cual va decidiendo qué vehículos tienen prioridad para pasar en qué instantes de tiempo y en qué proporción. Imaginemos este atasco en dos avenidas que intersectan, tenemos coches que vienen de la avenida 1 y coches de la avenida 2. Ambos conjuntos de coches compiten por lo mismo, cruzar la avenida contraria. Imaginemos que la avenida 1 es una de las avenidas principales de la ciudad mientras que la avenida 2 es una avenida menor, al haber atasco tenemos a media ciudad paralizada por lo que una de nuestras prioridades es que la circulación de dicha avenida sea más fluida que la circulación de la avenida menor Al mismo tiempo tampoco podemos dejar parada la circulación de la avenida 2. Todas estas premisas debe tenerlas en cuenta el policía que regule el tráfico en ese momento para ser capaz de disolver el atasco y hacer que la circulación de ambas avenidas fluya de la mejor manera posible. Con Resource  governor podemos establecer configuraciones para obtener comportamientos similares al ejemplo del policía, podemos limitar la utilización de recursos como CPU y memoria para que no excedan de cierto umbral, e incluso cuantos vehículos permites pasar por segundo. Pero Resource governor es más que esto, no solamente podemos especificar umbrales máximos sino que también vamos a ser capaces de establecer umbrales mínimos. Esta flexibilidad nos hará capaces de tener cargas de trabajo balanceadas y nos aseguran que cada proceso o usuario tendrá los recursos necesarios en el momento necesario.

El Resource Governor está formado fundamentalmente por 3 componentes:

  • Grupo de Recursos (Resource Pools)
    Por definición se crean 2 grupos de recursos (interno y predeterminado) cuando instalamos nuestra instancia de SQL Server 2008 o superiores. Además de estos 2, Resource Governor también admite la creación de grupos definidos por el usuario.
  • Grupos de carga de trabajo (Workload groups)
    Al igual que los grupos de recursos, cuando instalamos SQL Server 2008 o versiones superiores también se crean dos grupos por definición (interno y predeterminado). Estos grupos de cargas de trabajos son asignados a su vez a sus grupos de recursos correspondientes. En este caso también cabe la posibilidad de que el usuario se cree sus propios grupos de carga de trabajo.
  • Función de clasificación (Classifier function)
    Función que hace de enrutador. Para cada solicitud entrante dicha función hace de enrutador y la clasifica en uno de los grupos de carga de trabajo. El usuario se puede crear su propia función e clasificación. De no hacerlo, existen reglas internas que clasifican las peticiones entrantes.

Vamos a ver cómo sería el proceso de una manera más ilustrativa. A continuación se muestra un esquema de la arquitectura de Resource Governor.

Figura 1. Arquitectura Resource Governor

En la figura anterior tenemos en la parte superior lo que serían los distintos tipos de peticiones o sesiones entrantes que podemos tener en un momento dado. En este caso tendríamos  una petición de una conexión dedicada de Administrador (DAC), una petición que a priori no sabemos clasificar y otras tres de los usuarios A1, A2 y B. El siguiente paso una vez nos entran las peticiones de las distintas conexiones o sesiones es clasificarlas,  y es aquí donde entra la función de clasificación de la que hemos hablado antes. Una vez dicha función clasifica las peticiones acto seguido las redirige a sus respectivos grupos de carga de trabajo. Siguiendo con este ejemplo vemos que cada una de las peticiones se dirige a un grupo. En este caso, como teníamos una petición que la función no sabe clasificar, lo que se hace es dirigirla al grupo de carga predeterminado creado en la instalación. El resto que sí se pueden clasificar se redirigen cada uno a su grupo de carga que a su vez está asociado a un grupo de recursos. Al finalizar este proceso, cada sesión queda clasificada de modo que el Resource Governor ya sabe que restricciones aplicar en los recursos correspondientes.

Nota: En el caso peculiar de las conexiones dedicadas al administrador (DAC) vemos que se salta el paso de clasificación. Esto es así porque las peticiones de este tipo de conexiones suelen ser administrativas y además se recomienda que no produzcan excesiva carga en el servidor, puesto que normalmente cuando utilicemos este tipo de conexión será porque tenemos algún problema. De modo que para estas peticiones la clasificación se hace directamente y se hace al grupo interno de carga que a su vez está asociado con el grupo de recursos internos.

Grupo de recursos del servidor

Un grupo de recursos de servidor o grupo, representa los recursos físicos del servidor. Se puede pensar en un grupo como en una instancia virtual de SQL Server dentro de la propia instancia nativa, al igual que ocurre por ejemplo con las máquinas virtuales de HyperV, que son máquinas virtuales con recursos limitados dentro de un Windows Server 2008 o 2008R2 nativo.

Un grupo de recursos está formado principalmente por dos recursos que son CPU y Memoria. Para cada uno de estos recursos podremos asignarles un umbral mínimo y/o un umbral máximo. Para ello tenemos las siguientes opciones a la hora de crear un grupo de recursos:

  • MIN o MAX para la CPU
    • MIN_CPU_PERCENT
    • MAX_CPU_PERCENT
  • MIN o MAX para la memoria
    • MIN_MEMORY_PERCENT
    • MAX_MEMORY_PERCENT

La suma de los valores MIN de todos los grupos no puede superar el 100 por cien de los recursos del servidor. El valor MAX se puede establecer dentro del rango comprendido entre MIN y el 100 por cien, inclusive.

Para más información acerca de los grupos de recursos consultar el siguiente enlace: http://msdn.microsoft.com/es-es/library/bb934084.aspx

Grupo de carga de trabajo

El grupo de carga de trabajo sirve como contenedor para las solicitudes de sesiones que sean iguales de acuerdo con los criterios establecidos en la función de clasificación. Estos grupos permiten la supervisión del consumo de recursos y la aplicación de una directiva uniforme a todas las solicitudes del grupo. Un grupo de carga de trabajo define las directivas para sus miembros.

Las directivas que se pueden especificar al crear un grupo de carga de trabajo son:

  • IMPORTANCE {LOW, MEDIUM, HIGH}
    Especifica la importancia del grupo de trabajo. Debido a que cada grupo de carga de trabajo pertenece a un grupo de recursos, dicho valor influirá entre grupos de carga de trabajo dentro del mismo grupo de recursos, nunca influirá entre grupos de carga que pertenezcan a diferentes grupos de recursos. El valor por definición es MEDIUM.
  • REQUEST_MAX_MEMORY_GRANT_PERCENT {0, 100}
    Representa la cantidad máxima de memoria que una única solicitud puede tomar de un grupo de carga para la ejecución de una consulta. Este porcentaje es relativo al que marca la propiedad MAX_MEMORY_PERCENT del grupo de recursos al que pertenece el grupo de carga. Por definición se establece 25.
  • REQUEST_MAX_CPU_TIME_SEC {0, nº positive}
    Especifica la cantidad máxima de CPU  (en segundos) que puede usar una solicitud dentro de este grupo de carga. El Resource Governor no impedirá que una solicitud continúe si se supera el tiempo máximo establecido, pero sí que se generará un evento. EL valor predeterminado es 0, lo que significa que no hay límite.
  • REQUEST_MEMORY_GRANT_TIMEOUT_SEC {0, nº positive}
    Específica el tiempo máximo (en segundos) que una consulta puede esperar hasta que esté disponible la concesión de memoria (memoria del buffer de trabajo). El valor predeterminado es 0. Esto significa que SQL Server internamente realiza unos cálculos  basado en el costo de la consulta para determinar el tiempo máximo de espera.
  • MAX_DOP {0, 64}
    Especifica el grado máximo de paralelismo para las solicitudes que requieran de paralelismo.  EL valor predeterminado es 0, lo que significa que utiliza la configuración global a nivel de servidor. Si especificamos otro valor lo que ocurre es que si una solicitud pertenece a este grupo se sobrescribe la opción max_dop a la que marca el grupo de carga de trabajo.
  • GROUP_MAX_REQUESTS {0, nº positivo}
    Especifica el número máximo de solicitudes simultáneas que pueden ejecutarse en el grupo de carga de trabajo. El valor predeterminado es 0, lo que significa que no hay límite de solicitudes.

Función de clasificación

Resource Governor permite clasificar las sesiones entrantes. Esta clasificación se basa en un conjunto de criterios definidos por el usuario y plasmados en una función definida por el mismo. En la lógica de la función se debe representar la forma en la que se clasifican las distintas sesiones. Esta lógica permite al Resource Governor clasificar las sesiones en los distintos grupos de carga de trabajo existentes.

La función que define el usuario tiene las siguientes características y comportamientos:

  • La UDF se evalúa para cada nueva sesión, incluso cuando la agrupación de conexiones esté habilitada.
  • Para que la clasificación tome efecto debemos actualizar el Resource Governor mediante el comando ALTTER RESOURCE GOVERNOR.
  • La UDF proporciona el contexto del grupo de cargas de trabajo para la sesión. Una vez determinada la pertenencia a un grupo u a otro, dicha sesión se enlaza a un grupo de carga de trabajo.
  • Si la UDF nos devuelve NULL, predeterminado o el nombre de un grupo que no existe, la sesión recibe el contexto y por lo tanto se enlaza con el grupo de cargas de trabajo predeterminado. Si la UDF falla también se enlaza la sesión con el grupo predeterminado.
  • La UDF se define en el ámbito de la base de datos master.
  • Solo puede haber una única función clasificadora activa. Podemos definir tantas como deseemos pero el Resource Governor puede utilizar solamente una de ellas.
  • Si no existe ninguna función de clasificación, toda sesión entrante será enlazada con el grupo de carga de trabajo predeterminado.

Puesta en marcha (GUI y T-SQL)

Una vez hemos definido los conceptos necesarios para entender bien lo que es Resource Governor y cómo trabaja vamos a pasar ahora a ponerlo en marcha. Para ello vamos a ver paso a paso como activarlo, crear grupos de recursos, grupos de carga de trabajo, funciones clasificadoras y algún ejemplo de funcionamiento. Todas estas operaciones serán reflejadas tanto por Transact SQL como por SQL Server Management Studio y su interfaz de usuario.

Escenario

Para realizar las demostraciones de como activar y utilizar nuestro Resource Governor vamos a definir antes un posible escenario de ejemplo donde poder demostrar el funcionamiento de esta característica.

Supongamos que en nuestros sistemas tenemos dos grupos de usuarios. Un grupo de usuarios realiza operaciones sencillas y relativamente ágiles en términos de recursos y otro grupo de usuarios que realiza operaciones más pesadas y que requieren de recursos para resolverse en los tiempos deseados. Estos tipos de acciones los vamos a clasificar diciendo que las más pesadas son también las más críticas de nuestro sistema, pensemos por ejemplo en consultas de negocio donde tenemos que agregar información de diversas formas y realizar muchos cálculos, mientras que las ágiles no serán nada críticas. Vamos a dividir a estos usuarios en dos inicios de sesión:

  • ConsultasNormales
  • ConsultasCriticas

Lo que vamos a hacer con Resource Governor es tratar que las operaciones críticas dispongan siempre del mínimo de recursos necesario para ejecutarse y resolverse en los tiempos normales.

Pre configuración

Antes de empezar a activar y configurar el Resource Governor, vamos a  realizar una configuración previa sobre nuestro servidor de test. Vamos a configurar la propiedad affinity mask a 1 para que SQL Server no distribuya la carga entre los diferentes cores. Así se verá más claramente el efecto del Resource Governor.

Para ello ejecutamos el siguiente código.

 -- Activo las opciones avanzadas 
sp_configure 'show advanced', 1
GO
RECONFIGURE
GO
-- Modifico affinity mask para el uso de un único core
sp_configure 'affinity mask', 1
GO
RECONFIGURE
GO

El siguiente paso para preparar nuestro escenario es crear los inicios de sesión y los usuarios de la Base de datos que realizaran las consultas, en este caso usamos la base de datos Northwind y el código seria el siguiente:

 -- creo los inicios de sesión 
create login ConsultasNormales
with password='p4$$w0rd',check_policy=off
go
create login ConsultasCriticas
with password='p4$$w0rd',check_policy=off
go
use Northwind
go
--creo usuario de consultas normales
create user userNormales from login ConsultasNormales
go
--permiso propietario
sp_addrolemember 'db_owner','userNormales'
go
--creo usuario consultas críticas
create user userCriticas from login ConsultasCriticas
go
--permiso propietario
sp_addrolemember 'db_owner','userCriticas'
go

Ahora ya sí tenemos el entorno listo para ver los efectos de Resource Governor.

Grupos de recursos y Grupos de carga de trabajo

En este apartado vamos a definir la estructura de nuestro Resource Governor, es decir, que vamos a definir los grupos de recursos y los grupos de carga de trabajo que sean necesarios. Para este escenario en concreto vamos a definir dos grupos de recursos y un grupo de carga de trabajo por cada grupo de recurso. A continuación se muestra cómo quedaría la estructura.

Figura 2. Workloads y Resource pools

Vamos a ver ahora como se crearían estos grupos  tanto en T-SQL como utilizando el GUI de SQL Server Management Studio.

SQL Server Management Studio

Lo primero que debemos hacer es activar el Resource Governor si no está activado todavía. Por defecto, Resource Governor está deshabilitado al instalar SQL Server 2008 R2, y podemos verlo como se muestra a continuación.

Figura 3. Resource Governor en SSMS

Nota: Observar que el icono de Resource Governor aparece con una flecha roja señalando hacia abajo. Esto denota que la característica no está Activada.

Para activarlo basta con darle al botón derecho y pinchar en enable.

Figura 4. Activando RG con SSMS

Una vez lo activemos veremos que el icono anterior ha cambiado y ya estaremos en calidad de empezar a crear nuestros grupos.

Figura 5. RG activo

De modo que lo primero que haremos ahora será crearnos los grupos de recursos. Como habíamos establecido anteriormente para este escenario serán dos grupos. Para crear un grupo de recursos pinchamos botón derecho sobre Resource Governor y seleccionaremos la opción de menú New Resource Pool.

Figura 6. Nuevo resource pool

A continuación aparecerá un formulario donde podremos crear nuestros grupos de recursos.

Figura 7. Formulario config. RG

Como podemos observar en el formulario,  por definición aparecen los dos grupos que ya hay predefinidos (default e internal). Además de esto se han creado los dos nuevos para la demostración. En este formulario se puede observar cómo podemos configurar todo el Resource Governor, ya que nos permite elegir la función de clasificación, crear y configurar los grupos de recursos y por cada grupo de recursos crear y configurar grupos de cargas de trabajo. En este caso nos centramos en los grupos de recursos. Se han creado dos grupos y no se ha configurado nada especial, se ha dejado por defecto.

A continuación creamos los grupos de trabajo de carga, que si recordamos también eran dos. Cada uno iba a asociado a su grupo de recursos correspondientes. Para ello desde el mismo formulario lo que hacemos es seleccionar el grupo de recursos que queramos y crearle su grupo de carga de trabajo. De modo que en primer lugar seleccionaremos el grupo de recursos GrupoRecursosNormales y le crearemos el grupo de trabajo GrupoNormales.

Figura 8. Grupo de carga Normales.

Como ilustra la figura 8, se ha creado el grupo de carga de trabajo con las opciones por defecto también. Ahora repetimos lo mismo para el segundo grupo.

Figura 9.Grupo de carga Críticas.

Ya tenemos los dos grupos de recursos y sus correspondientes grupos de carga de trabajo asociados. Todos ellos creados con las opciones por definición, es decir que todavía no se aplica nada especial a ninguno de ellos.

Por último ya solo nos queda definir la función de clasificación. Para definir esta función es necesario utilizar T-SQL puesto que no existe interfaz gráfica que nos permita dicha creación. De modo que esta función la veremos en el siguiente apartado.

T-SQL

En esta sección vamos a ver cómo podemos realizar las mismas acciones que en el apartado anterior pero todo vía lenguaje T-SQL. De modo que vamos a ir por partes. Empezaremos con la activación y los grupos de recursos, seguiremos con la creación de los grupos de carga de trabajo y terminaremos con la función clasificadora.

Activación y grupos de recursos

En el siguiente script vamos a ver como se activa el Resource Governor y como creamos los dos grupos de recursos necesarios para esta demostración.

--contexto de base de datos maestra
use master
go
--activamos el Resource Governor
alter Resource Governor reconfigure
go--creamos los gruposd e recursos (opcioens por defecto)
create resource pool GrupoRecursosNormal
go
create resource pool GrupoRecursosCriticas
go

Grupos de carga de trabajo

El código T-SQL para la creación de los dos grupos de carga de trabajo seria el siguiente:

--creamos grupod e carga de trabajo
create workload group GrupoNormal
usingGrupoRecursosNormal
go
create workload group GrupoCriticas
usingGrupoRecursosCriticas
go

Función de clasificación

Como hemos comentado en el apartado anterior, tenemos que la función de clasificación solamente se puede crear mediante T-SQL. Vamos a ver como sería el código para la función. En esta función clasificaremos los dos inicios de sesión que habíamos definido en nuestro escenario de pruebas que eran consultasNormales y consultasCriticas.

-- Creamos la función de clasificación

if(object_id('dbo.funcion_Clasificacion_v1','fn') is not null)
    drop function dbo.funcion_Clasificacion_v1
go
create function dbo.funcion_Clasificacion_v1()
returns sysname with schemabinding
begin
    declare @val sysname
    set @val='Default'; --default group
   
   
if ('ConsultasNormales'=suser_name())
        set @val='GrupoNormal'; --grupo normales
    else if ('ConsultasCriticas'=suser_name())
        set @val='GrupoCriticas'; --grupo críticas
   
   
return @val;
end
--asociamos al funcion de clasificación al Resource Governor
alter Resource Governor
with (classifier_function=dbo.funcion_Clasificacion_v1)
go
--actualizamos el Resource Governor
alter Resource Governor reconfigure
go

Con todas las configuraciones vistas hasta ahora ya tendríamos listo el Resource Governor para nuestro escenario inicial.

Fase de pruebas

Hasta ahora lo que tenemos es el Resource Governor activado y configurado con las propiedades por defecto de los distintos componentes. En esta sección veremos cómo se comportan los procesos de los distintos grupos y veremos también como cambiar las configuraciones para cumplir el objetivo final, que es que las operaciones críticas dispongan siempre de los recursos necesarios para resolver las consultas.

Ejecutando cargas de trabajo

Para simular cargas de trabajo vamos a utilizar el siguientes script:

--script de simulación de carga de CPU
set nocount on
declare @i int
declare @s varchar(100)
 
set @i = 100000000
--bucle
while @i > 0
begin
       select @s = @@version;
       set @i = @i - 1;
end

Monitor de Rendimiento

Para medir el uso de CPU de los distintos procesos usaremos los contadores de rendimiento del performance monitor

  • SQL Server:WorkloadGroup Stats Object -> CPU usage % -> GrupoNormal
  • SQL Server:WorkloadGroup Stats Object -> CPU usage % -> GrupoCriticas
  • SQL Server:Resource Pool Stats Object -> CPU usage % -> GrupoRecursosNormal
  • SQL Server:Resource Pool Stats Object -> CPU usage % -> GrupoRecursosCriticas

Pruebas

Tal y como está el escenario montado, el Resource Governor aplica la clasificación pero no aplica ninguna prioridad puesto que nos e ha configurado para ello. De modo que si ahora mismo ejecutamos nuestro código para utilizar en exceso el recurso de CPU iniciando dos sesiones una con cada usuario. De este modo veremos como compiten por el recurso y cómo se comporta SQL Server. Vamos a ver qué pasa cuando lanzamos la consulta con la sesión "SesionNormales".

Figura 10. Contadores CPU grupo de recursos

Figura 11. Contadores Grupos de carga de trabajo.

Como vemos el % de utilización de CPU en ambos gráficos está al 50%. Esto es así debido a que la máquina de pruebas tiene dos procesadores. Lo que está pasando es que hay un procesador al 100% pero el monitor de rendimiento muestra el 50% porque todavía tiene otro libre.

Figura 12. CPU al 100%

Vamos a ver ahora que pasa cuando abrimos una sesión nueva y lanzamos el script de carga con la sesión "SesionCriticas".

Figura 13. Contadores grupo de carga de trabajo compitiendo.

Figura 14. Contadores de grupo de recursos. Compitiendo por CPU

En este caso vemos como al competir los dos grupos por el mismo recurso, Resource Governor reparte el recurso por igual. Cada proceso pasa a tener el 50% de la CPU aproximadamente, lo que en el monitor de rendimiento se corresponde con un 25% aproximadamente cada proceso. Esto es así porque no se ha especificado ninguna configuración específica de los recursos.

Asignando prioridades

Si recordamos el objetivo de este escenario, era el de hacer que las consultas clasificadas como consultas críticas dispusieran siempre de recursos suficientes para su ejecución. En este caso vamos a estimar que una consulta crítica necesita al menos del 70% de CPU cuando se esté ejecutando para poder completarse en el tiempo esperado. Para ello vamos a utilizar Resource Governor y ver cómo podemos hacer para obtener dichos resultados.

En este escenario, para otorgarle a las consultas clasificadas como críticas el 70% de CPU debemos modificar el grupo de recursos. Para ello basta con ejecutar el siguiente código t-SQL:

 /*
Establecemos un minimo y maximo de 70% de CPU
al grupo de recursos para consultas criticas
*/
alter resource poolGrupoRecursosCriticas
with (max_cpu_percent=70,min_cpu_percent=70)
go
--aplicamos cambios
alter Resource Governor reconfigure
go

Nota: Estos cambios también se pueden realizar mediante la interfaz de usuario con el SQL Server Management Studio.

Si volvemos a probar el lanzamiento de las cargas igual que en el ejemplo anterior tenemos que al lanzar la carga con la sesión de consultas normales obtenemos los siguientes resultados:

Figura 15. Contadores gurupo de recursos.

Figura 16. Contadores grupo de carga de trabajo.

Como vemos al lanzar las consultas clasificadas como normales, Resource Governor sigue dando el 100% de CPU al proceso de consultas normales. Esto es así porque en este momento no hay competencia por el recurso. El recurso está disponible y solamente lo está pidiendo un proceso que ejecuta consultas "normales", por lo cual el Resource Governor le da todo lo que necesite. Ahora veremos como en el momento compita por el recurso un proceso que lance consultas clasificadas como "críticas" hace el recorte de recursos y da prioridad según lo establecido a las consultas "críticas".

Lanzamos script de carga con sesión ConsultasCriticas. El resultado obtenido es el siguiente:

Figura 17. Contadores grupo recursos compitiendo dos procesos.

Figura 18. Contadores  grupos de carga de trabajo compitiendo.

Como se muestra en las figuras 17 y 18, tras aplicar la política del 70% de CPU para este tipo de consultas vemos que en el momento que compiten estos dos grupos, automáticamente las clasificadas como críticas hacen más uso de la CPU que las clasificadas como normales. Por lo que el Resource Governor está discriminando acorde a las políticas especificadas que le hemos dado y ya podemos asegurarnos que este tipo de consultas siempre tendrán los recursos necesarios.

Autores

Enrique Puig Nouselles es miembro de SolidQ en el departamento de Motor Relacional. MCITP de SQL Server, realiza labores de Data Platform Engineer. Esta especializado en sistemas OLTP y durante los últimos años su foco principal ha sido la solución de problemas de rendimiento, escalabilidad y migraciones. Ha participado como speaker en eventos de lanzamiento de Microsoft España (Microsoft SQL Server 2008R2) y en la serie de webcasts de novedades de SQL Server 2008 R2. También ha impartido diversas charlas con en el grupo de usuarios de Microsoft GuseNET, es miembro del nuevo grupo SQL PASS Spain y ha colaborado con el magazine dotNETManía. Asimismo, lleva su blog personal ( http://blogs.solidq.com/EnriquePuigNouselles) y  "El rincón del DBA" con colegas de SolidQ ( http://blogs.solidq.com/elrincondeldba).

Technical Rviewers

Eladio Rincón: MVP de SQL Server desde 2003, es el Director Informático de Tecnologías de Bases de Datos en España. Desde 2004 es parte del equipo de SolidQ encargado de proyectos de consultoría, de soporte así como de gestión y es formador de la tecnología SQL Server en países tales como España, Brasil, Reino Unido, EE.UU., Emiratos Árabes Unidos, Costa Rica, México, Perú, China y Corea. Eladio colabora con Microsoft en diferentes eventos tecnológicos como MSDays, TechNet o MSDN, tanto en la red como fuera de ella. Asimismo, lleva su blog personal (http://msmvps.com/blogs/eladio_rincon), y "El Rincón del DBA" ( http://blogs.solidq.com/elrincondeldba) con colegas de SolidQ.

Microsoft está realizando una encuesta en línea para comprender su opinión del sitio web de. Si decide participar, se le presentará la encuesta en línea cuando abandone el sitio web de.

¿Desea participar?