Tema: SQL Server 2014 para ITPros. 

Descripción del tema: En esta tema hablaremos de las nuevas ventajas que nos ofrece SQL Server 2014. 

Objetivo: Dar a conocer cómo funcionan las nuevas característica de SQL Server 2014 en el área de ITPro, lo que permitirá usar estas características para mejorar la disponibilidad de sus aplicación, tener un plan de recuperación rápido y efectivo y hacer decisiones informadas de porque ir a esta nueva versión de SQL Server. 

Presentador: Edinson Medina

Idioma: Español

[View:~/cfs-file.ashx/__key/communityserver-blogs-components-weblogfiles/00-00-00-89-31/SQL-2014-Session-for-ITPros.mp4:0:0]

Tema: SQL Server 2014 para Desarrolladores. 

Descripción del tema: En esta tema hablaremos de las nuevas ventajas que nos ofrece SQL Server 2014. 

Objetivo: Dar a conocer cómo funcionan las nuevas característica de SQL Server 2014 en el area de desarrollo, lo que permitirá usar estas características para mejorar el rendimiento de sus consultas y hacer decisiones informadas de porque ir a esta nueva versión de SQL Server.

Presentador: Edinson Medina

Idioma: Español

[View:~/cfs-file.ashx/__key/communityserver-blogs-components-weblogfiles/00-00-00-89-31/SQL-2014-for-Developers-Talk.mp4:0:0]

El mundo de los negocios es cada vez más demandante y requiere de profesionales con conocimientos sólidos sobre las tecnologías actuales y muy informados sobre las que están surgiendo.

Microsoft te invita este 17 de junio al "Microsoft Technical Day" en donde podrás seleccionar de entre 32 conferencias técnicas las que mayor interés tengan para ti o mayor impacto en el desarrollo de tu trabajo profesional.

Asiste el martes 17 de junio y convive con los 32 especialistas de Microsoft de diversas tecnologías, al tiempo que compartes, con 200 profesionales exitosos como tú, sus experiencias.

Si no deseas seguir recibiendo correos electrónicos personales o mensajes promocionales por favor notifícamelo de inmediato para tomar las acciones pertinentes.

Microsoft respeta tu privacidad. Revisa nuestra Declaración de Privacidad en línea.

Recientemente estaba en uno de mis clientes que tiene un Virtual Shop en Hyper-V 2012, y me pregunto: Estoy planificando la instalación de múltiples Instancias de SQL Server para algunas aplicaciones de administración en máquinas virtuales, como debo proveer la Alta Disponibilidad?

Esto es una Buena pregunta, tenemos varias opciones, pero rápidamente decidimos usar alguna forma de Cluster, entonces tenemos solo 2 opciones, Clusterizar la Máquinas Virtuales de Hyper-V o hacer un Guest Failover Cluster de SQL Server entre las máquinas virtuales.

La primera opciones es Buena para mitigar el downtime cuando el hardware falla, si uno de los Nodos de las Máquinas Virtuales de Hyper-V, las máquinas virtuales simplemente harán un failover a otro nodo, pero que pasaría cuando solo falle el servicio de SQL? Esto no iniciaría un failover, por lo menos no por defecto, supongo que se puede crear algún tipo de script que monitorea el servicio de SQL y luego disparar una falla a nivel de la VM, pero no suena muy adecuado. Ahora por el otro lado, en esta configuracion tenemos Live Migration que nos permite mover maquinas virtuales con 0 downtime.

La segunda opción, es una excelente, y tiene todos los beneficios de SQL Server Failover Cluster, simplemente se usan las 2 máquinas virtuales, y se crea un SQL Cluster entre las mismas, esto es llamado un SQL Guest Failover Cluster.

Una de las preguntas fue, puedo combinar las 2 opciones? y Si se podría, pero tengan en consideración lo siguiente:

• Puede que usen muchos más recursos de los necesarios
• En caso de la falla de un servidor físico, podrían perder la Alta Disponibilidad

Porque? Supongamos un escenario, Tenemos 2 nodos físicos donde creamos un Windows Cluster, y luego configuramos 2 Máquinas Virtuales como recursos del Windows Cluster (La primera opción), se configure que una de las máquinas virtuales se ejecute sobre el nodo1 y la otra máquina virtual se ejecute en la nodo2, ahora se crea un SQL Guest Failover Cluster entre las máquinas virtuales (La segunda opción). Que pasaría cuando el nodo1 falle (ejm: Falla de la tarjeta madre), las 2 máquinas virtuales se ejecutaran en el nodo2 consumiendo una gran cantidad de recursos, y adicionalmente no tendrán verdadera alta disponibilidad ya que tu carga de trabajo esta ejecutándose en un único servidor físico.

En conclusión, debería combinar las opciones?, depende en la disponibilidad de recursos que tengas, también que tan crítica es la carga de trabajo que ejecutas contra SQL Server. Sin embargo, lo que SIEMPRE debes hacer es usar las mejores prácticas de configuración para SQL Server en un ambiente Hyper-V.

Running SQL Server 2008 in Hyper-V Environment

Running SQL Server with Hyper-V Dynamic Memory - Best Practices and Considerations

Consolidating Databases Using Virtualization Planning Guide

Espero que les haya gustado el contenido, me pueden seguir en twitter @SQLDixitox y en facebook https://www.facebook.com/SQLbyEdinsonMedina

Tema: SQL Server Sysprep. 

Descripción del tema: En este tea tocaremos los pasos que debemos seguir para crear una imagen de SQL Server y Windows Server. 

Objetivo: Dar a conocer cómo funcionan la caracteristica de sysprep en SQL Server y como la podemos usar para automatizar a creacion de maquinas con una Instancia de SQL Server.  

Presentador: Edinson Medina

Idioma: Ingles

[View:~/cfs-file.ashx/__key/communityserver-blogs-components-weblogfiles/00-00-00-89-31/SQL-Sysprep.mp4:0:0]

SQLSysprep.rar

Aplicando AlwaysOn Availability Groups en escenarios reales.pptx

Me mostraron lo que el cliente quería lograr, ellos necesitaban calcular algunas métricas incluyendo errores de muestra utilizando el método “Conglomerados Últimos” para calcular el error en la muestra a posteriores para muestras estratificadas. Éste método fue creado por un investigador español y fue publicado en España. Pueden encontrar la referencia aquí, http://dialnet.unirioja.es/descarga/articulo/250808.pdf

Tratar de entender el método y las fórmulas que se usan es difícil, afortunadamente el cliente ya tenía una implementación elegante de dichas fórmulas en el Script MDX usando la sentencia SCOPE y en solo unas líneas implementaron la parte más compleja de las fórmulas. Por lo tanto me enfoqué en el tema de performance en lugar de la implementación de las fórmulas.

Después de un par de horas encontré que la fórmula estaba usando calculas cell by cell en logar de cálculos por bloque, la causa era un operador (el operador “^”) y después de un pequeño cambio (multiplicar la métrica por si misma) el query mejoró de aproximadamente 30 segundos a 1 segundo.

Puedes encontrar el detalle acerca de operadores que soportan cálculos basados en bloque en el documento “Identifying and Resolving MDX Query Performance Bottlenecks in SQL Server 2005 Analysis Services” encontrado en http://www.microsoft.com/en-us/download/details.aspx?id=661, también puedes encontrar algunas recomendaciones para mejorar performance de queries en http://msdn.microsoft.com/en-us/library/bb934106.aspx

El enfoque de éste blog es en cómo podemos detectar los casos en donde el problema es cálculos Cell by Cell.

Tenemos 2 herramientas que usaremos para éste propósito, una es el SQL Server Profiler y la otra es el Performance Monitor, el orden recomendado es identificar primero que el problema está en el Formula Engine y después confirmar con el Performance Monitor que la causa de que el Formula Engine esté lento son cálculos Cell By Cell.

Aquí está la metodología recomendada, esto no es nuevo, pero no he encontrado una buena referencia que cubra éstos pasos.

Paso 1. Identificar si el cuello de botella está en el Formula Engine.

Utilizar el profiler para capturar la ejecución de tu query, es más fácil si haces esto en un ambiente aislado pero si no es posible, puedes filtrar los eventos en tu query por el ConnectionId o alguna otra columna que identifique todos los eventos de tu query.

Necesitas sumar la duración de cada evento QuerySubcube y restar ese total de la duración mostrada en el evento QueryEnd. En éste ejemplo puedes ver que la mayoría de los subcubos tomó 0 ms, algunos tomaron 16ms y otro que no se ve en la imagen tomó alrededor de 110 ms. El total del query fue 3,953 ms, eso significa que Analysis Services utilizó 142 en el Storage Engine y la diferencia de 3811 se utilizó en el Formula Engine.

En conclusión, en el caso anterior tenemos un cuello de botella en el Formula Engine Bottleneck, revisemos si en éste caso es causado por cálculos cell by cell.

El procedimiento anterior puede no escalar tan bien cuando tienes cientos de subcubos o muchos queries utilizando cálculos Cell by Cell en el mismo trace, en esos casos el siguiente procedimiento puede ser más apropiado:

1. Guarda el profiler a una table de SQL Server.
2. Ejecutar el siguiente Query de T-SQL para obtener los queries de mayor duración
   SELECT ROWNUMBER, EVENTCLASS, EVENTSUBCLASS, TEXTDATA, DURATION, CONNECTIONID FROM <TABLE_NAME> WHERE EVENTCLASS=10
3. Ejecutar el siguiente Query de T-SQL para obtener el inicio y finalización del query en el trace.
   SELECT TOP 2 ROWNUMBER, EVENTCLASS, EVENTSUBCLASS, TEXTDATA, DURATION, CONNECTIONID FROM <TABLE_NAME> WHERE EVENTCLASS IN (9,10) AND CONNECTIONID=<TARGET_CONNECTIONID> AND ROWNUMBER <= <ROWNUMBER_OF_TARGET_QUERY> ORDER BY ROWNUMBER DESC
4. Ejecutar el siguiente query de T-SQL para determinar la cantidad de tiempo que se gastó en el Storage Engine y en el Fórmula Engine.
   SELECT SUM(DURATION) FROM <TABLE_NAME> WHERE EVENTCLASS=11 AND CONNECTIONID=<TARGET_CONNECTIONID> AND ROWNUMBER BETWEEN <QUERY_BEGIN_ROWNUMBER> AND <QUERY_END_ROWNUMBER>

Paso 2. Identificar si el problema es causado por cálculos Cell by Cell

Puedes utilizar el Performance Monitor para identificar si el problema son cálculos Cell By Cell. Para ser exitoso en ésta tarea es mucho mejor que ejecutes el query en un ambiente aislado porque tenemos un contador con el total de cálculos de celdas para toda la instancia y no hay forma de separarlo por query en el Performance Monitor. La imagen de abajo muestra cómo se ve el ejemplo nuestro.

En la imagen puedes ver que el contador usado es “MSOLAP&InstanceName:MDX \ Total Cells Calculated” y el valor inicial es 0 y el valor después de ejecutar el query es superior a 1 millón.

Los resultados anteriores fueron después de reiniciar la instancia y una sola ejecución del query generó más de un millón de celdas calculadas. Si ésta es la primera vez que haces esto no sabes si 1 millón es muy alto o es bajo. Puedo asegurarte que para éste query es un número bastante alto.

Paso 3. Modificar tu query

Modificar el query utilizando las recomendaciones en los links mencionados anteriormente hasta que dejes de ver el gran incremento en número de celdas calculadas para tu query.

En éste caso particular el Script MDX estaba usando algunas expresiones del tipo:

Measures.Measure1 ^ 2

Cambiamos la formula a algo como:

Measures.Measure1 * Measures.Measure1

Después de que la formula fue cambiada obtuvimos los siguientes resultados.

Puedes ver que el total del query es 156 ms, considerando que el Storage Engine debió usar el mismo tiempo, 132 ms, significa que el Formula Engine tomó aproximadamente 24 ms.

En el Performance Monitor podemos ver que el total de celdas calculadas fue 41. El query fue ejecutado después de que se reinició la instancia.

Comentarios Finales

Esto es solo el procedimiento básico para encontrar si los cálculos cell by cell están causando problemas en tu ambiente. Las modificaciones al query para evitar cálculos cell by cell puede ser fácil algunas veces, como en éste caso real, o muy difícil en otros escenarios.

Espero esto sea útil para que puedan empezar a solucionar sus propios casos.

Este error no permite seguir con el procedimiento de añadir un nodo a la Instancia de SQL en el Cluster, hay un par de motivos por el cual este error puede aparecer:

• El primer motivo es que existan pruebas fallidas en el reporte de Validación del Cluster, para resolver este problema ejecute el Wizard de Validación del Cluster y en el reporte se muestre que no existe ninguna prueba fallida o con estatus de error (pruebas en estado de warning no representan un problema).
• También existe un problema donde por diferentes circunstancias el proceso de validación puede fallar, y cuando esto ocurre se deberá hacer una revisión manual para asegurar que la configuración del hardware es correcta y luego intentar el workaround mencionado en el siguiente artículo, http://support.microsoft.com/kb/953748
• Sin embargo existe otro motivo que no es muy conocido, para que SQL Server pueda hacer la verificación del cluster debe poder localizar los reportes de validación de todos los nodos del cluster a través del FQDN (nombreservidor.nombrededominio), se deberá verificar que al hacer ping entre los servidores la IP se resuelve al FQDN, en caso que no sea así deberán revisar el DNS y el host file.
• Otra razón también puede ser que el Windows Firewall este bloqueando el acceso en caso de estar activo.

En este caso se revisó la primera y segunda posible causa, sin embargo el error todavía seguía apareciendo.

Por tanto se revisó la tercera causa y se pudo observar que las respuestas de la resolución de nombre devolvían el nombre NETBIOS y no el nombre FQDN, luego de resolver este problema, se reintento el proceso de añadir nodo a la Instancia de SQL en el cluster de forma satisfactoria.

Tema: Power Pivot y Power View – Personal BI. 

Descripción del tema: En ésta sesión se presentarán las funcionalidades y escenarios en los que éstas dos (2) componentes de Office y SQL encajan en una solución de BI y brindan al usuario final la libertad de explotar la información disponible en la empresa de una manera más eficiente. 

Objetivo: Dar a conocer cómo funcionan Power Pivot y Power View, que nuevas funcionalidades se esperan y como pueden empezar a utilizarlos.  

Presentador: Rubén González 

IT Experts_RubenGonzalez_PersonalBI.pptx

Tema: Optimización de aplicaciones de bases de datos OLTP. 

Descripción del tema: En esta sesión hablaremos de algunas de las Mejores Practicas en diferentes niveles de SQL Server para obtener un buen rendimiento en SQL Server.

Objetivo: Dar a conocer algunas de la mejores practicas para un buen rendimiento para bases de datos OLTP.  

Presentador: Edinson Medina

Optimización de aplicaciones de bases de datos OLTP.pptx