Duración: 50 min.
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
Tema: SQL Server 2014 para Desarrolladores.
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.
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.
Recuerdo los viejos días cuando no era un fanático de colocar a SQL Server en Máquinas Virtuales, pero hoy en día gracias a Hyper-V 2012 (y VMWARE), muchos de los cuellos de botella en recursos que existían en las máquinas virtuales han desparecido. Sin embargo aunque ha mejorado en gran medida no es para todas las cargas de trabajo.
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:
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
Duración: 30 min.
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.
Idioma: Ingles
En esta sesión hablaremos de la nueva caracteristica de SQL Server 2012, AlwaysON Availability Group y como usarlo en un ambientes de Alta Disponibilidad y Recuperacion de Desastres.
Format: wmvDuration:
Hace algunas semanas me pidieron apoyo con un problema de desempeño en algunas consultas MDX.
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:
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.
En uno de mis clientes regulares, están iniciando la migración hacia SQL Server 2012, al momento de la Instalación de una Instancia de SQL Server 2012 sobre un Windows Cluster de Windows Server 2008R2, se presentó el siguiente error durante el proceso de añadir un nodo a la Instancia de SQL.
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:
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.
Duración: 1hr.
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
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.
Ya que en este punto tenemos claros los conceptos de Windows Aware Updating (CAU), en esta segunda parte revisaremos como podemos utilizar el plug-in Window.HotfixPlugin para instalar actualizaciones LDR, actualizaciones acumulativas y Service Packs, así como las opciones que provee para tener un mayor control del proceso. NOTA: CAU puede sólo puede ser utilizado a partir del Service Pack 1 de SQL Server 2012.
Como ejemplo instalaremos el Service Pack 1 de SQL Server 2012 en los nodos Win20121 y Win20122. (Este proceso es similar para cualquier acumulativa Update y Service Pack), utilizando la herramienta gráfica ya que permite una visualización más sencilla del proceso. Se usó un Clúster Windows Server 2012 de tres nodos con dos instancias SQL Server 2012 RTM que sólo ejecutan en los nodos win20121 y Win20122, y ejecutamos el modo self-updating.
Para evitar que el post sea muy largo se omiten capturas de pantalla para mostrar las versiones iniciales y finales de SQL, así como la configuración del Cluster. La idea principal es ver el proceso de CAU.
Ya que la actualización será instalada en dos de los tres nodos del clúster, utilizamos la siguiente estructura de directorios:
\\WIN-0M99J4ILA2E\UpdatesDemo\Root5
DefaultHotfixConfig.xml
\<nodo 2 name>
\SQL2012SP1
\<SQLServer2012SP1Package>.exe
\<nodo 4 name>
Así mismo, el archivo de configuración le agregué la siguiente sección en rojo.
<root>
<DefaultRules>
…
</DefaultRules>
<FolderRules>
<Folder name="SQL2012SP1">
<Template path="$update$" parameters="/ACTION=PATCH /allinstances
/QUIET /IAcceptSQLServerLicenseTerms"/>
<ExitConditions>
<Success>
<ExitCode code="0"/>
</Success>
<Success_RebootRequired>
<ExitCode code="3010"/>
</Success_RebootRequired>
<NotApplicable>
<ExitCode code="-2068578302"/> <!-- ERROR_PATCH_TARGET_NOT_FOUND -->
</NotApplicable>
<AlreadyInstalled>
<ExitCode code="-2068643838"/> <!-- ERROR_PATCH_ALREADY_APPLIED -->
</ AlreadyInstalled >
</ExitConditions>
</Folder>
</FolderRules>
</root>
Como se describió en la primera parte del post, iniciamos la herramienta de Cluster-Aware updating.
Y hacemos click en “Configure cluster self-updating options”.
Hacemos click en Next.
Habilitamos el modo self-updating, y hacemos click en siguiente.
Luego configuramos la frecuencia de ejecución automática. Esto es útil especialmente con el plug-in Microsoft.WindowsUpdatePlugin para la instalación de actualizaciones de seguridad. El plug-in Microsoft.HotfixPlugin, al ser utilizado para la instalación de actualizaciones de no seguridad, requiere la configuración de la estructura de directorios y la descarga de instaladores por lo cual puede resultar más práctico su ejecución manual y supervisada, aunque una programación podría ser útil en algunos casos tales como la actualización de ambientes no productivos.
Configuramos aspectos de la ejecución tales como:
Tiempo máximo de ejecución en minutos (StopAfter), tras el cual se detiene todo el proceso de actualización.
Tiempo de advertencia en minutos (WarmAfter), tras el cual se genera un mensaje de advertencia, el cual pueder ser utilizdao, por ejemplo, para advertir que la ventana de mantenimiento definida para la actividad está cercano.
El orden en el que los nodos deben actualizados (NodeOrder,)
El plug-in a utilizar (CaaPluginName), en este caso Microsoft.HotfixPlugin
Parámetros adicionales requeridos por el plug-in Microsoft.HotfixPlugin
Otros valores, los cuales pueden ser consultados en http://technet.microsoft.com/en-us/library/jj134224.aspx
Establecemos las opciones para el Microsoft.HotfixPlugin tales como la raíz del fileshare que contiene la estructura de directorios y las actualizaciones a instalar.
NOTA: Para mayor información de las opciones de Microsoft.HotfixPlugin ver http://technet.microsoft.com/en-us/library/jj134213.aspx
Podemos ver un resumen de las opciones configuradas (que podemos utilizar en la opción descrita en la primera parte del post para pre visualizar las actualizaciones que serán instaladas durante la ejecución) y al hacer click en “Apply” finalizaremos la configuración de CAU.
Hacemos click en Close.
Una vez configurado el CAU, podemos iniciar la ejecución haciendo click en “Apply updates to this cluster”, lo que iniciará el wizard de ejecución.
Aquí podemos visualizar el comando PowerShell que puede ser utilizado para iniciar la actualización. Así mismo podemos visualizar las actualizaciones que serán instaladas haciendo click en “Preview the updates that will be applied to the cluster nodes”.
Antes de iniciar, y para validar que el Service Pack sólo será instalado en los nodos especificados en la estructura de directorio hacemos click en “Preview the updates that will be applied to the cluster nodes”.
Se observa que el Service Pack 1 será instalado sólo en los nodos Win20121 y Win120122, tal y como se estableció en la estructura de directorios. Para salir hacemos click en Close.
Para iniciar el proceso de actualización hacemos click en “Update”.
Una vez iniciado el proceso hacemos click en Close.
Lo que permite ver el avance del proceso hasta que este finalice.
Los failover de servicios no se registran en esta ventana, sin embargo, se realizan luego de colocar cada nodo en modo de mantenimiento. Al finalizar el proceso, las instancias se encuentran en el nodo original.
Debemos tomar en cuenta que este proceso es diferente a lo recomendado en el documento SQL Server failover cluster rolling patch and service pack process disponible en http://support.microsoft.com/kb/958734, en cuanto a que la mitad de los nodos que se actualizan no se eliminan como posibles dueño de los recursos de SQL Server, así como el momento en que se hace el failover de las instancias a los nodos actualizados. Este es una funcionalidad que nos puede ayudar a facilitar el proceso y configurando correctamente las opciones del plug-in Microsoft.HotfixPlugin podemos tener un comportamiento similar en varios aspectos al recomendado en este documento, por lo que los invito a probarlo y encontrar la configuración que mejor se adapte a sus necesidades.
Existen algunas consideraciones a tomar en cuenta cuando usamos CAU en ambientes Always On con Grupos de Disponibilidad, así como diferentes escenarios de actualización, por lo que recomiendo leer el documento Patching SQL Server Failover Cluster Instances with Cluster-Aware Updating (CAU) disponible en http://www.youtube.com/watch?v=XhVbLgf3rqE
Espero que los dos post de esta serie les hayan ayudado a entender cómo podemos utilizar esta nueva funcionalidad de Windows Server 2012 para facilitarnos un poco la vida.
Otras lecturas recomendadas:
Cluster-Aware Updating Overview
http://technet.microsoft.com/en-us/library/hh831694.aspx
Requirements and Best Practices for Cluster-Aware Updating
http://technet.microsoft.com/en-us/library/jj134234.aspx
Windows Server 2012 incorpora una nueva funcionalidad llamada Windows-Aware Updating (CAU) que permite la orquestación automática de la instalación de actualizaciones para el sistema operativo y otras aplicaciones que ejecuten sobre los nodos de un Clúster. Esta funcionalidad está muy bien integrada con aplicaciones como Hyper-V, sin embargo, puede ser utilizado para actualizar cualquier aplicación Microsoft e incluso aplicaciones de terceros.
Está funcionalidad, que sólo puede ser utilizada en clúster Windows Server 2012, facilita la tareas de actualización de ambientes, especialmente al tomar en cuenta que es posible crear clúster de hasta 64 nodos, ya que Windows se encarga de coordinar (orquestar) todas las acciones relacionadas con la actualización, tales como el failover de los servicios, la instalación de actualizaciones y reinicio de nodos. Esto permite al administrador concentrase exclusivamente en monitorear el proceso de actualización y de esa forma poder actualizar varios ambientes simultáneamente haciendo un uso más eficiente de su tiempo.
Una vez configurado, CAU funciona de la siguiente manera:
Existen dos modos para la ejecución del proceso: desde una máquina (Windows 8 o Windows Server 2012) diferente a los nodos del clúster (remote updating mode) o desde uno de los nodos del clúster (self-updating mode).
Nota: para habilitar esta herramienta en Windows 8 es necesario descargar Remote Server Administration Tools (RSAT) for Windows 8 desde http://www.microsoft.com/en-us/download/details.aspx?id=28972
Independientemente del modo utilizado, podemos especificar el plug-in que permitirá definir el origen de las actualizaciones a instalar:
Microsoft.WindowsUpdatePlugin
Este plug-in instala por defecto las actualizaciones GDR de seguridad importantes y criticas directamente desde Windows Update, Microsoft Update,y las actualizaciones aprobadas desde el servidor Windows Server Update Services (WSUS), aunque es posible instalar actualizaciones GDR adicionales configurando parámetros adicionales del plug-in.
Microsoft.HotfixPlugin
Este plug-in instala actualizaciones LDR (antiguamente QFE) desde una carpeta en un file share SMB, y puede ser configurado para instalar actualizaciones no Microsoft, tales como actualizaciones de firmware o de BIOS.
En ambos modos e independientemente del plug-in a utilizar, CAU puede ser invocado usando una herramienta gráfica o a través de comandos PowerShell (http://technet.microsoft.com/en-us/library/hh847221.aspx)
NOTA: Para esta explicación utilizaré la herramienta gráfica que permite una visualización más sencilla del proceso. Para este ejemplo usaremos un Clúster Windows Server 2012 de tres nodos y ejecutaremos el modo self-updating.
Para iniciar la herramienta gráfica, hacemos click derecho sobre el nombre del clúster -> More Actions -> Cluster-Aware updating, tal y como se observa en la siguiente imagen.
Para visualizar las actualizaciones que serán instaladas en cada uno de los nodos, podemos hacer click sobre “Preview updates for this cluster”, seleccionar el plug-in deseado y hacer click sobre “Generate Preview update list”. En el siguiente ejemplo, se utilizó plug-in Microsoft.WindowsUpdatePlugin para obtener la lista de actualizaciones no instaladas desde Windows Update.
En este caso, no es posible seleccionar cuales actualizaciones se desea instalar, ni en cuales nodos. Si se desea aplicar actualizaciones sobre nodos puntuales o sobre instancias específicas, es necesario utilizar el Microsoft.HotfixPlugin.
Para utilizar Microsoft.HotfixPlugin, la primera acción a ejecutar es crear una estructura de directorios que indicará cuales actualizaciones serán instaladas en cada nodo. Para esto se crea un fileshare con la siguiente estructura
\\<networkshare>\hotfixroot
\CAUHotfix_All
Update1.msu
Update2.msi
Update3.msp
\<nodo 1 name>
Update4.exe
Update 5
….
\<nodo x name>
UpdateY.exe
donde:
NOTA: el archivo DefaultHotfixConfig.xml puede ser copiado desde la ruta C:\Windows\System32\WindowsPowerShell\v1.0\Modules\ClusterAwareUpdating desde cualquiera de los nodos. Este archivo, sin modificaciones, permite la instalación de la mayoría de las actualizaciones no SQL Server. Para mayor información ver http://technet.microsoft.com/en-us/library/jj134213.aspx
Cuando estamos instalando actualizaciones para SQL Server, es necesario definir una estructura diferente y modificar el archivo de configuración, con el objetivo de especificar los parámetros de ejecución, tales como la instancia sobre la que se instalará la actualización. Supongamos que deseamos instalar el Service Pack en una o todas las instancias y en todos los nodos la estructura debe ser similar a la siguiente:
Si quisiéramos instalar el Service Pack en una instancia que ejecuta sólo sobre los nodos 2 y 4 del clúster, la estructura sería similar a la siguiente
Donde SQL2012SP1 es el nombre de la regla que será utilizada para definir los parámetros de ejecución de la actualización y es definida por el usuario.
NOTA: El directorio \CAUHotfix_All puede existir y estar vacío, pero en este caso se elimina para evitar instalar por error alguna actualización en todos los nodos.
En ambos casos, se debe modificar el archivo DefaultHotfixConfig.xml para agregar la regla (la sección en rojo del ejemplo) que permite especificar los parámetros de ejecución del paquete de actualización. Adicionalmente permite especificar las condiciones de éxito de instalación de la actualización.
<Template path="$update$" parameters="/ACTION=PATCH <INSTANCIA A ACTUALIZAR>
Donde <INSTANCIA A ACTUALIZAR> puede:
NOTA: los parámetros a especificar corresponden a los parámetros de instalación de SQL Server desde el command prompt (http://msdn.microsoft.com/en-us/library/ms144259.aspx)
En cuanto a las condiciones de éxito para el CAU, existen sólo cuatro para SQL Server:
En algunos escenarios se omiten los últimos dos códigos del archivo de configuración con el objetivo de determinar ejecuciones no válidas resultado de una estructura de directorios errada, la configuración incorrecta del nombre de la(s) instancia(s) a actualizar o el intento de instalar una actualización que no aplica al ambiente, ya que la ejecución de CAU retorna un estado fallido para los nodos configurados incorrectamente.
NOTA: Cuando la estructura de directorios especifica nombres de nodos y/o se especifiquen instancias en el archivo de configuración, se debe tener especial cuidado para evitar que alguna instancia quede sin actualizar en alguno de los nodos sobre el que ella pueda ejecutar, ya que un failover a dicho nodo generará un downgrade de la instancia.
Una vez creada la estructura de directorios, y para validar que CAU instalará las actualizaciones deseadas en los nodos indicados, podemos hacer click sobre “Preview updates for this cluster”, seleccionar el plug-in Microsoft.Hotfix, establecer los parámetros del plug-in (lo cual se describe en la segunda parte de post) y hacer click sobre “Generate Preview update list”. Veremos el ejemplo particular de dos actualizaciones de Windows con la siguiente estructura de directorios:
\\WIN-0M99J4ILA2E\UpdatesDemo\Root3
\windows8-RT-KB2792100-x64.msu
\Win20121>
\windows8-RT-KB2737084-x64.msu
\Win20122
\Win20123
Se observa que windows8-RT-KB2792100-x64.msu será instalado en todos los nodos, mientras que windows8-RT-KB2737084-x64.msu sólo será instalado en Win20121 y win20122 de acuerdo a lo especificado en la estructura de directorios.
En la segunda parte del post (Windows Aware updating y SQL Server (Parte II) – Paso a Paso) se explicará cómo configurar y ejecutar CAU para instalar un Service Pack de SQL Server 2012.
A partir de SQL Server 2008 se introdujo el concepto de utilizar Service SID cuando se instala en Windows 2008 o posterior.
El concepto de Service SID (o virtual account) permite que ya no necesitemos un grupo local o de dominio (en el caso de clusters) para asignar los permisos que requiere la instancia para poder trabajar correctamente. En su lugar, los permisos se le asignan al Service SID.
Solo para que quede más claro, el concepto de Service SID no es creado por SQL Server, sino por Windows Server 2008 o posterior y SQL 2008 o posterior puede tomar ventaja de ésta característica.
Lo interesante viene a la hora de configurar permisos o derechos como “Lock Pages In Memory” o “Perform Volume Maintenance Tasks”, históricamente le asignábamos éstos privilegios a la cuenta de servicio de SQL Server, pero ahora que existen los Service SID, ¿A quién se lo debo asignar?. Similarmente, si necesito hacer un Backup a un network share, ¿A quién le doy permisos sobre el share para que SQL Server pueda escribir el backup?
La misma pregunta aplica para cualquier otro privilegio que antes se le necesitaba dar a la cuenta de servicio.
La respuesta es que se le puede dar el privilegio o permiso a cualquiera de los 2 y SQL va a funcionar correctamente. Sin embargo, debido a que el Service SID solo vive dentro del equipo donde se instaló la instancia, para asignarle permisos fuera de ese equipo se puede hacer a través del computer account, la cual se llama “DomainName\ComputerName$”.
En resumen los privilegios del servicio de SQL son la unión de lo que tenga el Service SID más lo que tenga la cuenta de servicio.
Si bien, es posible dar el privilegio a ambas cuentas, la cuenta con la que corre el servicio y la cuenta Service SID, ¿Cuál debiéramos usar?, debido a que la que cuenta de servicio puede cambiar, el best practice es asignarle el privilegio al Service SID siempre que sea posible.
Para que el concepto de Service SID quede más claro para quienes no tengan experiencia con ellos, observen las siguientes imágenes. La cuenta “NT Service\MSSQLServer” es el Service SID. El nombre del service SID va a incluir la instancia como parte del nombre como en el ejemplo “NT Service\MSSQL$Denali”. En las imágenes se muestra como agregar el Service SID al privilegio Lock Pages In Memory y a los permisos de un folder.
El uso de Service SID se extendió aún más en SQL Server 2012 y también existen los Managed Service Account, pero esos son tema para otro post.
Referencias
http://support.microsoft.com/kb/2620201/en-us
http://msdn.microsoft.com/en-us/library/ms143504.aspx#MSA
http://blogs.technet.com/b/sqlpfeil/archive/2012/02/16/sql-amp-sids-why-we-need-it-and-what-the-hell-it-is.aspx
Aca les dejo una simple lista de chequeos para el momento de Instalar un SQL Server 2008R2 en un Windows Failover Cluster 2008R2
COLUMN STORE INDEXES (ÍNDICES ALMACENADOS POR COLUMNAS)
Hace unos días visite un cliente en Puerto Rico que tenía problemas de rendimiento en una aplicación transaccional y entre las opciones que quería considerar era el uso de índices almacenados por columnas. Este tipo de índice es una de las nuevas funcionalidades que tiene SQL 2012 pero como veremos a continuación sus características lo hacen idóneo para ciertos escenarios no para todos. Las versiones de SQL 2012 donde está disponible la funcionalidad de índices almacenados por columnas son: SQL Server 2012 Enterprise, Evaluation, y Developer.
Los índices tradicionales son almacenados por filas en vez de columnas. Esta forma de almacenamiento es extremadamente eficiente cuando se requiere acceder una fila o un rango compuesto de un grupo pequeño de filas. Sin embargo cuando se solicitan todas las filas o un rango grande, este método se vuelve ineficiente.
Los índices almacenados por columnas permiten presentar un rango amplio de filas a través del almacenamiento de los datos organizados por columnas. Cuando se crea un índice almacenado por columnas típicamente se incluyen todas las columnas de la tabla. Esto asegura que todas las columnas se beneficiaran de la mejora en rendimiento.
En un índice almacenado por columnas, en vez de almacenar juntas todas las columnas de un registro, cada columna es almacenada de forma separada con todas las demás filas en el índice. El beneficio de este tipo de índice consiste en que solo las columnas y las filas requeridas para contestar una consulta serán leídas. En escenarios de Datawarehouse, a menudo se utiliza menos de un 15% de las columnas de un índice para obtener el resultado de una consulta.
Hay dos restricciones principales a considerar cuando se trabaja con índices almacenados por columnas. En primer lugar un índice almacenado por columna es de solo lectura. Una vez se ha creado, no se pueden realizar modificaciones a los datos en la tabla. Es decir las operaciones: INSERT, UPDATE y DELETE no están permitidas. Por esta razón a menudo se utiliza el particionamiento de tablas para reducir la cantidad de datos que necesitan ser almacenados en un índice almacenado por columnas y para permitir el reconstruir un índice cuando se insertan nuevos datos a la tabla. Debido a esta restricción, los índices almacenados por columnas son idóneos en situaciones donde los datos no cambian con frecuencia como es el caso de los datawarehouse. La segunda restricción limita a uno el número de índices almacenados por columnas que pueden existir en una tabla. Esta restricción no se considera un problema ya que se acostumbra a incluir todas las columnas de la tabla en el índice almacenado por columnas.
Otra limitación está relacionada con el tiempo que toma la creación de un índice en comparación con un índice nonclustered. El tiempo promedio podría ser de dos a tres veces más. Sin embargo, a pesar de las restricciones antes mencionadas, los índices almacenados por columnas pueden proveer un valor significativo en términos de rendimiento si se considera que el índice solo cargará las columnas que sean requeridas por la consulta. Además de la mejora en compresión que se puede obtener por contar con data similar en la misma página.
Los siguientes tipos de datos no pueden ser utilizados en índices almacenados por columnas: binary, varbinary, ntext, text, image, nvarchar(max), varchar(max), uniqueidentifier, rowversion, sql_variant, decimal (mayor de 18 dígitos), datetimeoffset, xml, y tipos basados en CLR. Además el número de columnas está limitado a 1,024. Finalmente por la naturaleza del índice no puede ser UNIQUE, CLUSTERED, contener columnas incluidas o tener definido un orden (ascendente o descendente).
Los índices almacenados por columnas utilizan su propia tecnología de compresión por lo cual no se pueden combinar con la opción de compresión a nivel de fila o página. Tampoco pueden ser utilizados en esquemas de replicación, change tracking o Change data capture, filestream. Estas tecnologías trabajan en escenarios de lectura/escritura lo cual no es compatible con la naturaleza de solo lectura de los índices almacenados por columnas.
Como crear un índice almacenado por columnas
La creación de un índice almacenado por columnas puede ser realizada a través de T-SQL o utilizando SQL Server Management Studio.
T-SQL
CREATE NONCLUSTERED COLUMNSTORE INDEX <ColumnStoreIndexName> ON <Table> (col1, col2, col3);
<ColumnStoreIndexName> ON
<Table> (col1, col2, col3);
-- Create the columnstore index
CREATE NONCLUSTERED COLUMNSTORE INDEX [csindx_FactResellerSalesPtnd]
ON [FactResellerSalesPtnd]
(
[ProductKey], [OrderDateKey], [DueDateKey], [ShipDateKey], [CustomerKey], [EmployeeKey],
[PromotionKey], [CurrencyKey], [SalesTerritoryKey], [SalesOrderNumber], [SalesOrderLineNumber],
[RevisionNumber], [OrderQuantity], [UnitPrice], [ExtendedAmount], [UnitPriceDiscountPct],
[DiscountAmount], [ProductStandardCost], [TotalProductCost], [SalesAmount], [TaxAmt], [Freight],
[CarrierTrackingNumber], [CustomerPONumber], [OrderDate], [DueDate], [ShipDate]
);
Management Studio
Índices almacenados por columnas con tablas particionadas
Crearemos una tabla particionada llamada FactResellerSalesPtnd utilizando el siguiente código de MSDN (http://msdn.microsoft.com/en-us/library/gg492088.aspx).
Paso #1: Crear la tabla FactResellerSalesPtnd (Versión particionada de la tabla: FactResellerSales)
USE AdventureWorksDW2012;
GO
CREATE PARTITION FUNCTION [ByOrderDateMonthPF](int) AS RANGE RIGHT
FOR VALUES (
20050701, 20050801, 20050901, 20051001, 20051101, 20051201,
20060101, 20060201, 20060301, 20060401, 20060501, 20060601,
20060701, 20060801, 20060901, 20061001, 20061101, 20061201,
20070101, 20070201, 20070301, 20070401, 20070501, 20070601,
20070701, 20070801, 20070901, 20071001, 20071101, 20071201,
20080101, 20080201, 20080301, 20080401, 20080501, 20080601,
20080701, 20080801, 20080901, 20081001, 20081101, 20081201
)
CREATE PARTITION SCHEME [ByOrderDateMonthRange]
AS PARTITION [ByOrderDateMonthPF]
ALL TO ([PRIMARY])
-- Create a partitioned version of the FactResellerSales table
CREATE TABLE [dbo].[FactResellerSalesPtnd](
[ProductKey] [int] NOT NULL,
[OrderDateKey] [int] NOT NULL,
[DueDateKey] [int] NOT NULL,
[ShipDateKey] [int] NOT NULL,
[CustomerKey] [int] NOT NULL,
[EmployeeKey] [int] NOT NULL,
[PromotionKey] [int] NOT NULL,
[CurrencyKey] [int] NOT NULL,
[SalesTerritoryKey] [int] NOT NULL,
[SalesOrderNumber] [nvarchar](20) NOT NULL,
[SalesOrderLineNumber] [tinyint] NOT NULL,
[RevisionNumber] [tinyint] NULL,
[OrderQuantity] [smallint] NULL,
[UnitPrice] [money] NULL,
[ExtendedAmount] [money] NULL,
[UnitPriceDiscountPct] [float] NULL,
[DiscountAmount] [float] NULL,
[ProductStandardCost] [money] NULL,
[TotalProductCost] [money] NULL,
[SalesAmount] [money] NULL,
[TaxAmt] [money] NULL,
[Freight] [money] NULL,
[CarrierTrackingNumber] [nvarchar](25) NULL,
[CustomerPONumber] [nvarchar](25) NULL,
OrderDate [datetime] NULL,
DueDate [datetime] NULL,
ShipDate [datetime] NULL
) ON ByOrderDateMonthRange(OrderDateKey);
-- Using simple or bulk logged recovery mode, and then the TABLOCK
-- hint on the target table of the INSERT…SELECT is a best practice
-- because it causes minimal logging and is therefore much faster.
ALTER DATABASE AdventureWorksDW2012 SET RECOVERY SIMPLE;
-- Copy the data from the FactResellerSales into the new table
INSERT INTO dbo.FactResellerSalesPtnd WITH(TABLOCK)
SELECT * FROM dbo.FactResellerSales;
[ProductKey],
[OrderDateKey],
[DueDateKey],
[ShipDateKey],
[CustomerKey],
[EmployeeKey],
[PromotionKey],
[CurrencyKey],
[SalesTerritoryKey],
[SalesOrderNumber],
[SalesOrderLineNumber],
[RevisionNumber],
[OrderQuantity],
[UnitPrice],
[ExtendedAmount],
[UnitPriceDiscountPct],
[DiscountAmount],
[ProductStandardCost],
[TotalProductCost],
[SalesAmount],
[TaxAmt],
[Freight],
[CarrierTrackingNumber],
[CustomerPONumber],
[OrderDate],
[DueDate],
[ShipDate]
Paso #2: Vamos a correr una consulta y confirmaremos que se utilizó el índice almacenado por columnas.
SELECT SalesTerritoryKey, SUM(ExtendedAmount) AS SalesByTerritory
FROM FactResellerSalesPtnd
GROUP BY SalesTerritoryKey;
Beneficios en términos de rendimiento de los índices almacenados por columnas
Costo
FROM FactResellerSales
-- Índice almacenado por columnas
SELECT SalesTerritoryKey, SUM (ExtendedAmount) AS SalesByTerritory
El costo relativo de la segunda consulta (utilizando un índice almacenado por columnas) es de 16% en comparación con el costo relativo de la primera consulta que es de 84% y utiliza un índice regular.
Actividad de disco
Al correr las consultas con STATISTICS IO ON (Muestra información relacionada con la cantidad de actividad de disco generada por las instrucciones Transact-SQL) se observa una mejora en rendimiento en la segunda consulta relacionada principalmente con las lecturas lógicas y read-ahead.
DBCC DROPCLEANBUFFERS
DBCC FREEPROCCACHE
SET STATISTICS IO ON
SET STATISTICS IO OFF
(10 row(s) affected)
Table 'FactResellerSales'. Scan count 1, logical reads 2982, physical reads 2, read-ahead reads 2972, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
Table 'FactResellerSalesPtnd'. Scan count 1, logical reads 599, physical reads 4, read-ahead reads 235, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
Tiempo
Al correr las consultas con STATISTICS TIME ON (Muestra el número de milisegundos necesarios para analizar, compilar y ejecutar cada instrucción) se observa una reducción de tiempo en la segunda consulta relacionada con el tiempo transcurrido y tiempo de CPU.
SET STATISTICS TIME ON
SET STATISTICS TIME OFF
SQL Server Execution Times:
CPU time = 46 ms, elapsed time = 109 ms.
CPU time = 32 ms, elapsed time = 85 ms.
Conclusión
Expertos coinciden que la mejora en rendimiento obtenida al utilizar índices almacenados en columnas fluctúa entre un 10% a un 100%. Sin embargo como hemos mencionado en este artículo las aplicaciones que se benefician más son las relacionadas con altos volúmenes de lectura y no en sistemas altamente transaccionales. Los esquemas de estrella y copo de nieve usualmente forman parte de los datawarehouse y datamarts donde la velocidad de la extracción de los datos es más importante que la eficiencia en la manipulación de los datos. La tecnología de índices almacenados en columnas puede detectar y agilizar las consultas dirigidas a estos esquemas por lo cual son los escenarios típicos idóneos para su aplicación.
En este post hablamos de un punto muy importante que es como recuperar el acceso como sysadmin a un servidor se ninguna de los logins pertenece al rol de sysadmin y el sa esta deshabilitado.
Primero, Bajen todos los servicios de SQL, incluyendo el SQL Engine, Analisys Services, Reporting Services, Integration Services, Full Text Search o cualquier otro que pueda hacer una sesión a SQL. También es bueno deshabilitar el TCP/IP protocol en caso que alguna aplicación se esté conectando a SQL server remotamente y haga sesión.
Ahora agreguen el switch –m (se debe agregar “;-m” sin espacios, ni las comillas) en los parámetros de inicio de SQL, esto hará iniciar el Servicio de SQL Server en modo single-user y solo podrá accederlo un solo usuario (es por esto que deben para cualquier servicio que haga sesión a SQL) y además debe tener privilegios de administrador en la maquina Windows
Luego de esto deberán ingresar a SQL usando sqlcmd en modo trusted podrán entrar a SQL Server, recuerden que deben estar logueados con una cuenta que sea miembro de los Administradores locales del Servidor
sqlcmd –E –S NombreServidor\NombreInstancia
Luego de entrar a sqlcmd podrá ejecutar cualquier comando que desee, ya que entrar acon el contexto de un sysadmin, para colocar a alguno login en el server rol de sysadmin podrán usar el stored procedures sp_addsrvrolemember: EXEC sp_addsrvrolemember 'NombreLogin', ‘sysadmin’; GO
Ya con esto tendrá un Login con privilegios de sysadmin, ahora ya puede bajar el servicio de SQL, remover el swith –m (esto remueve el modo single-user) e iniciar SQL Server, podrá usar el login al que se le otorgo los derechos de sysadmin y hacer los cambios que requieran.
Hola!!
Una de las nuevas características de SQL Server 2012 son las Contained Databases , gracias a esta característica podemos parcialmente aislar algunos objetos que por su naturaleza residen en la instancia de bases de datos como lo son los “logins”, si bien en términos de migración y consolidación esta es una gran ventaja, permítanme comentarles algunos aspectos a considerar a nivel de seguridad.
Se debe tener en consideración que si algún usuario en la contained database tiene el permiso de ALTER ANY USER, tendrá la capacidad de modificar los permisos de los usuarios y dar permisos de conexión a cualquier persona sin conocimiento del Administrador de SQL, usuarios que pertenezca a los roles de bases de datos “db_owner” y “security_admin” obtendrán automáticamente dicho permiso, dando como resultado un hueco de seguridad, por esto tenemos que ser muy cuidadosos con dar estos permisos a usuarios no administradores de SQL.
Otro escenario que debemos considerar es que cuando nos conectamos a un contained database y en esa misma instancia se encuentra alguna base de datos con la cuenta “guest” habilitada, una vez que el usuario se ha podido conectar a la contained database, también tendrá la capacidad de acceder a esa base de datos, esto en conjunto que el escenario anterior donde una usuario con el permiso de ALTER ANY USER pude dar acceso a cualquier persona para conectarse al servidor, se convierta en un gran problema de seguridad. Es por ello que debemos minimizar el uso de este permiso y constantemente auditar el acceso y uso del permiso ALTER ANY USER en las bases de datos.
Ahora platiquemos de otro escenario, ¿Que sucedería si creamos un usuario en nuestra base de datos de contenido, con el mismo nombre de un login existente en nuestra instancia? Si accedemos a la base por medio de este login y a su vez al momento de conectarnos especificamos la Contained Database como catálogo inicial, lo que obtendríamos sería una negación del servicio para este login, ya que el contexto de seguridad evalúa usuario y contraseña sobre la Contained Database en lugar de el entrono de logins de SQL.
Para finalizar y tomando en cuenta mis dos recomendaciones anteriores, les expongo lo siguiente. ¿Cual es el impacto de darle “attach” a una base de datos de contenido en una nueva instancia? , al attachar una Contained Database estaremos abriendo una puerta de conexión a los usuarios con password de la Contained Database attchada. ¿Cómo podemos evitar el riesgo de acceso a usuarios no autorizados a esta instancia? usando la opción de RESTRICTED_USER, ya que esta previene la autenticación para usuarios con passwords de la Contained databases.
Todas estas consideraciones son fácilmente manejables teniendo una adecuada delegación de control de acceso y mejores prácticas de seguridad.
Espero les sean de utilidad estos puntos y para mayor información de este y tros escenarios pueden consultar en TechNet:
http://technet.microsoft.com/en-us/library/ff929055
Una nueva característica en SQL Server 2012 son los modelos tabulares de Analysis Services, y después de toparme con algunas sorpresas al preparar una demo para un evento reciente decidí terminar unas pruebas y comparar el performance de los modelos tabulares vs los modelos multidimensionales.
Antes que nada, ¿Qué es Analysis Services Tabular Mode?. SQL Server incluye no solo el motor relacional sino que también incluye un motor analítico. Antes de SQL Server 2012, había solo una clase de base de datos analítica en SQL Server (las bases de datos multidimensional o simplemente cubos). En SQL Server 2012 tenemos una nueva clase de base de datos analítica, Analysis Services en modo tabular, el objetivo es similar a las bases de datos multidimensionales, ser capaz de responder preguntas complejas acerca de la información (queries) tan rápido como sea posible, sin embargo, la arquitectura y lenguaje usados varían. En bases de datos tabulares el lenguaje utilizado es DAX en lugar de MDX y la arquitectura de modo tabular está basada en tener toda la información comprimida en memoria organizada en modo tabular a diferencia de las base de datos multidimensionales que organizan la información en registros y utilizan agregaciones para mejorar el performance de los queries. El modo Tabular no requiere índices ni agregaciones gracias a ésta nueva arquitectura. Para más detalles del modo tabular pueden leer la presentación relacionada con el tema que pueden encontrar en http://blogs.technet.com/b/sql_pfe_latam/archive/2012/06/27/1-176-simposio-latinoamericano-de-sql-server.aspx
En éste escenario, los datos usados son aleatorios y el equipo es un Workstation con 16Gb de RAM (no precisamente un High End Server), sin embargo sirve para ilustrar que hay que tener cuidado antes de escoger tabular mode sin hacer las pruebas de concepto apropiadas.
Tabular mode tiene algunas ventajas sobre modelos multidimensionales pero también tiene algunas desventajas.
Tres de las ventajas más grandes de los modelos tabulares son:
- Son más fáciles y rápidos de crear
- Si ya tienes proyectos en PowerPivot es muy fácil evolucionarlos a TabularMode
- Puedes usar PowerView para consumir éstos modelos
Dentro de las desventajas se encuentran los resultados de las pruebas que hice y que muestro a continuación.
El escenario consiste de una base de datos de 16.4 GB con una tabla de hechos con 100 millones de registros que tiene menos de 10 columnas. El comparativo al cargar ésta información tanto a Tabular Mode como a multidimensional se muestra a continuación:
Característica
Tabular
Multidimensional
Procesamiento
Más de 9 horas
20 minutos
Consumo de memoria
11 GB
1 GB
Tamaño aprox. BD
4.5 GB
8.4 GB
Query 1
88 ms
94 ms
Query 2
334 ms
62 ms
Query 3
5033 ms
920 ms
Los resultados anteriores no significa que no deben usar Tabular Mode, pero si que deben hacer una evaluación antes de tomar una decisión, dependiendo del conjunto de datos, de la cantidad de dimensiones, de la complejidad de las métricas, etc, los resultados van a beneficiar más a un modelo que al otro.
Aquí muestro los print screens que reflejan los datos anteriores.
Tamaño base de datos relacional (no se usó compresión)
Tamaño de base de datos modo Tabular
Tamaño de Base de datos en modo multidimensional
Queries en modo tabular
Queries en modo multidimensional
Estimados miembros de la Comunidad PFE LATAM y Comunidad SQL, el pasado Viernes 22 de Junio del 2012 se llevó a cabo el Primer Simposio Latinoamericano de SQL Server en el Auditorio de Microsoft México.
La agenda de este evento fue creada por diversos autores como: desarrolladores y It Pros, en este evento contamos con speakers como:
Microsoft PFE Database (Premier Field Engineer)
Leads SQLPASS México
Microsoft TAM (Technical Account Manager)
Microsoft Solution Sales
La iniciativa del Simposio Latinoamericano de SQL Server fue un esfuerzo organizado gracias a la colaboración de las comunidades (grupos de usuarios) y esperemos que esta iniciativa se expanda a otros países de Latinoamérica en un futuro proximo.
El objetivo de estos eventos es:
1. Tener en Latinoamérica eventos de alta calidad y compartir la misma información que se ofrece en eventos del mismo tipo que se ofrecen en Estados Unidos varias veces al año, pero en nuestro idioma y a nuestro alcance. Esto nos permite alcanzar y ayudar a más usuarios ya que muchas personas que trabajan con tecnología Microsoft o están interesados en ella no les es fácil viajar a los Estados Unidos por diversas razones.
2. Mostrar las ventajas y beneficios de negocio que los productos y tecnologías Microsoft ofrecen, proveyendo una mayor productividad y eficiencia a las empresas y personas que trabajan con estas. Esto lo logramos compartiendo y detallando las características de las últimas versiones de los productos de SQL Server
Este año Microsoft fue el patrocinador y fue pieza clave para unir los esfuerzos de la Comunidad de SQL Server para lograr que el evento fuera un éxito. El objetivo del evento no es únicamente dar a conocer los productos y sus beneficios, sino también generar una simbiosis que permita a nuestros partners o socios de negocios (categoría IW) el dar a conocer sus productos y servicios, generando áreas de oportunidad y así fortalecer nuestro ecosistema de partners.
En esta ocasión tuvimos aproximadamente 200 participantes de 89 distintas empresas. Las presentaciones expuestas durante el simposio las podrás descargar aquí.
Te invitamos a que nos compartas tus comentarios sobre los temas y nos digas que te gustaría ver en los siguientes eventos.
“Las opiniones e ideas expresadas en este blog son las de los Autores y no necesariamente declaran o reflejan la opinión de Microsoft”
Hola a todos, esta vez les voy a hablar de tema que no esta relacionado con SQL Server directamente, les voy a hablar de un issue relacionado con Windows Server 2003 Failover Clustering.
El problema en si es que luego de instalar los discos compartidos en los Nodos del Cluster no podían ser agregados como un recurso de Disco físico en el clúster, al realizar el procedimiento para crear un Physical Disk Resource los discos no aparecían en la lista de para seleccionar discos, en realidad no aparecía ningún disco.
Luego de introducir algunas palabras claves en Bing encontré un artículo donde se menciona el problema.
Unable to select disk from dropdown in Cluster Administrator http://support.microsoft.com/kb/969053
Aunque me ayudo, la solución no resolvió completamente el problema, vamos a seguir los pasos del método Alternativo:
1. The following command will create a resource of type physical disk: cluster res "Disk F:" /Create /group:"Cluster Group" /Type:"physical disk"
Este paso te permite crear el un recurso de disco con el nombre Disk F: en el grupo Cluster Group, el recurso se crear offline y sin propiedades especificas.
2. The next command is needed for associating the disk through its disk signature to the physical disk resource.
Este paso se utiliza para asociar el disco compartido al recurso del disco físico creado en el paso anterior a través de la firma (signature) del disco. Sin embargo al ejecutar el comando se generaba un error System Error 87.
Por lo tanto decidí asociarlo directamente a través del registro. Con los siguientes pasos:
- Abro el clúster administrator en el nodo donde esta el Grupo de clúster donde quiero agregar el disco
- Añado el recurso de disco a través de cluster.exe como se muestra en el artículo. Ejm: cluster res "Disk F:" /Create /group:"Cluster Group" /Type:"physical disk". El recurso es agregado offline
- En la llave de registro HKEY_LOCAL_MACHINE\Cluster\Resources ubico el {GUID} para el recurso de disk agregado anteriormente, deberás ir uno a uno hasta encontrar el que tenga el mismo nombre, Ejm: Disk F:
- En el Key Parameters, añadir un valor DWORD llamado Signature, y en el mismo agregaras la firma hexadecimal del disco
- Ahora podrás ir al cluster administrator y colocar el disco en línea. Puedes ver la propiedades para verificar que esta mapeado al disco adecuado.
De esta manera podrás agregar los discos como recursos del cluster. Este problema es poco común y generalmente se da cuando hay algún tipo de incompatibilidad o issue con los drivers de los discos de la SAN. Es probable que un reinicio de todos los nodos del cluster también resuelva
Si deseas saber como obtener la firma (Signature) del disco sigue los siguientes pasos:
1) Ir al command prompt y escribir "diskpart".
2) En DISKPART> prompt, escribe “list disk”
3) En DISKPART> prompt, escribe "select disk n" <- donde n es el disco que deseas saber la firma
4) En DISKPART> prompt, escribe "detail disk"
5) El valor de "Disk ID: " es el valor en Hexadecimal de la firma del disco
Uno de los clientes para los que labore posee una base de datos central completamente transaccional. Esta base de datos es leída por una aplicación web, la cual posee una capa intermedia de servidores de aplicación los cuales se conectan directamente a las bases de datos.
En este punto podemos diferenciar 3 niveles: web, aplicación y bases de datos. Las correctas practicas de programación nos llevarían a mantener la mayor parte del código dentro de la base de datos para de esta forma obtener un mejor performance disminuyendo la cantidad de información que viaja por la red, en este caso a través de los 3 niveles ya explicados anteriormente.
Sin embargo por una serie de antiguas practicas de programación incorrectas los desarrolladores mantienen mas del 70% de código fuente en las rutinas de .NET en los servidores de aplicación.
Esto no se convirtió en un problema real en cuanto el nivel de transacciones no era tan alto como lo ha llegado a ser, al igual como el tamaño y la complejidad de las bases de datos ha alcanzado atreves del tiempo.
Una de las políticas de la compañía es no hacer cambios en el código y en las bases de datos de Producción fuera de los “Service Packs” o cambios de versión de las aplicaciones, por lo que podrán suponer que cada “Service Pack” conlleva una gran serie de actualizaciones que son liberadas en el ambiente de Producción al mismo tiempo.
Habiendo aclarado el tipo de ambiente, practicas de programación y alguna de las políticas para los deployments podre llegar al punto que deseo exponer en este blog; una vez, un día después de la liberación de uno de los “Service Packs”, un lunes, los clientes comenzaron a contactar a servicio al cliente quejándose que nadie podía ingresar a ninguna de las aplicaciones, al aparecer la pantalla de LOGIN y darle aceptar, nada sucedía hasta obtener un time-out como respuesta.
Inmediatamente tuve que ingresar a los servidores de bases de datos y me lleve la desagradable sorpresa que el CPU de uno de ellos estaba al 100% de utilización, solo me preguntaba que cambio pudo venir con el Service Pack que estuviera ocasionando este extraño comportamiento!!
Después de un tiempo capturando traces, obteniendo información de las DMV’s entre otras herramientas llegamos a la conclusión que el nivel de compilamiento era muy superior al mostrado históricamente antes del cambio de versión, pero entre tantos cambios que vinieron con este Service Pack hubiéramos tenido que tener la aplicación abajo por demasiado tiempo hasta encontrar los statements responsables de semejante horror.
Dos cosas se hicieron para solucionar este problema, primero; por medio del análisis de los traces llegamos a la conclusión que había que crear índices en un par de tablas que los necesitaban desesperadamente y segundo; al saber que la mayoría de las ejecuciones eran tipo BATCH, ya que las llamadas del código están en los servidores de aplicación cambiamos el tipo de PARAMETERIZATION de simple a forced.
Comando:
ALTER DATABASE <DB_NAME> SET PARAMETERIZATION FORCED
Que es lo que esta opción de base de datos realiza?
Parametriza todos los valores que vienen con los selects, updates, deletes e inserts que sean tipo batch, individualmente, para que estos no sean recompilados cada vez que son ejecutados. O sea los mantiene a nivel de memoria.
Lógicamente esta opción no aplica para todos los statements que estén dentro de los procedimientos almacenados ya que estos son compilados efectivamente por el motor de base de datos.
También hay otras situaciones donde la parametrizacion no aplica, pueden acceder a estas ingresando al siguiente link.
http://technet.microsoft.com/en-us/library/ms175037.aspx
Al aplicar estos cambios el grado de recompilamiento bajo significativamente y junto a los índices creados el CPU volvió a niveles normales de entre 20% y 30%, y todos los usuarios pudieron felizmente ingresar de nuevo a las aplicaciones.
Antes de finalizar este tema sugiero siempre recomendar a los desarrolladores mantener todo el código posible siempre dentro del motor de base de datos y cuando nos topamos con ambientes como el expuesto aquí recomiendo hacer el cambio de la parametrizacion a “FORCED” antes de que ocurran los desastres.
Durante una plática con amigos sobre cómo obtener un mejor performance de SQL Server, me hicieron la siguiente pregunta… ¿Existe alguna otra optimización para aplicar a un servidor de SQL Server, aparte de aplicación de Best Practice a nivel de sistema operativo y Aplicación? A lo cual les indique que también se podrían hacer optimizaciones a nivel Hardware, en este caso a nivel Storage.
Con lo anterior, empezamos a explicar el tema de SAN pero enfocándolo a Administradores de Base de Datos.
Son muchos factores los que afectan el buen rendimiento de I/O de los discos, factores como el Discos compartidos o dedicados, niveles de RAID, la velocidad del bus, configuraciones de adaptadores HBA, un punto muy importante que frecuentemente se pasa por alto es la alineación en las particiones de disco.
Algunos de los factores no-disco en los que se puede observar cuellos de botella son:
- HBA (Host Bus Adapters) o tarjetas de interface de red
- Capacidad de procesamiento de FC (Fibre Channel) o puertos iSCSI
- Switch
- Numero de paths entre el servidor y el storage.
Es importante considerar y entender los límites de los componentes envueltos en la arquitectura, algunos de los límites que se tienen establecidos en el mercado son:
Component
Limits
SAS cable
Theoretical: 1.5 gigabytes per second (GB/s)
Typical: 1.2 GB/s
PCI-X v1 bus
X4 slot: 750 MB/s
X8 slot: 1.5 GB/s
X16 slot: roughly 3 GB/s
PCI-X v2 bus
X4 slot: 1.5 – 1.8 GB/s
X8 slot: 3 GB/s
Note: Be aware that a PCI-X bus can be v2 compliant but still run at v1 speeds.
Fibre Channel HBAs, switch ports and front end Fibre Channel array ports
4 gigabits per second (Gbps): 360-400 MB/s
8 Gbps: Double the speed of 4 Gbps
Note: Make sure to consider the limits of the PCI bus. An 8-Gbps card requires a PCI-X4 v2 slot or faster.
Pero, ¿Cómo se liga todo lo anterior con SQL Server? La unidad fundamental de almacenamiento de datos en SQL Server es la página (8KB), el espacio asignado a un archivo de datos (mdf o ndf) de una base de datos se divide lógicamente en páginas enumeradas de forma continua de 0 a n. La operación de I/O de disco se realiza a nivel página.
Los Discos duros están conformados por platos finos y circulares, en su superficie poseen medios de comunicación electrónicos que almacenan información. Cada lado de cada plato cuenta con miles de pistas o tracks, un set de tracks con el mismo diámetro en toda la superficie del plato conforman un cilindro (Para los nuevos dispositivos el concepto de cilindro no es relevante, ya que no están dispuestas en círculos concéntricos, sin embargo es útil entender el origen de los términos). Cada superficie de disco tiene dedicada una cabeza de I/O. Las pistas o tracks se dividen en sectores. Un sector es el fragmento mínimo de datos que se pueden leer o escribir en un disco duro. Las nuevas unidades pueden ofrecer sectores de 1KB, 3KB o 4 KB.
Con la tecnología RAID, la data es repartida a través de un grupo de discos físicos. El esquema de distribución de la data determina como el sistema operativo hace las operaciones de I/O de los datos. La granularidad con la cual la data es almacenada en un disco antes de que la data se almacena en otro de los discos del grupo de llama stripe unit size. La colección de stripe units, desde el primer disco al último del grupo se conoce como stripe.
Pero con todo esto que es la Alineación de las particiones? Y que efecto tiene en el performance de SQL Server??? En el siguiente diagrama se explica.. La línea vertical punteada negra que se superponen a un a la línea de color rojo corresponden a los límites entre diferentes discos físicos de un RAID. Las versiones anteriores a Windows Server 2008 nuestra los 63 sectores reservados reportados por el hardware del disco, inmediatamente después de lo cual el resto de la partición son expuestas al usuario. En la figura, el tamaño común del sector que se utiliza es de 512 bytes. El tamaño del Stripe unit en el ejemplos es de 64 KB, y 4KB para el tamaño de clúster NTFS, adecuado para, un file server. La falta de alineación de discos obliga a que el octavo clúster de 4KB de data se establezca a través de dos stripe units. Iniciando con el último sector vacío de 512 bytes del primer stripe unit y continuando con el segundo stripe unit. Esta situación se perpetua en el resto de la partición, ya que cada cierto numero el clúster de data se establecerá en dos stripe unit, por lo tanto dos I/O son requeridos para realizar una Lectura o Escritura.
El file allocation Unit size (Clúster size) recomendado para SQL Server es de 64KB; esta mejor practica en combinación con la desalineación de disco que existe por defecto fuerza que la data se establezca en dos stripe units, iniciando con el primer sector disponible del primer stripe unit y continuando con el segundo stripe unit. Esta situación es perpetuada en el resto de la partición. En esta configuración, cada clúster es escrito en dos stripe units, esto significa que todas las escrituras y lecturas se ven afectadas
El siguiente es un experimento en el cual se analizó el performance de disco, la prueba se realizó Windows Server 2003 y SQL Server 2005. Se ejecutó un query para extraer la información de SQL Server, durante cada ejecución se aplicó DBCC DROPCLEANBUFFERS para limpiar el buffer cache de SQL Server, con esto obtener pruebas satisfactorias. Los contadores de performance que se monitorearon fueron Avg. Disk Transfer/sec de los objetos PhysicalDisk y LogicalDisk los cuales son utilizados para la métrica de la latencia del disco. Los resultados muestran una mejoría significante comparando la alineación de discos, las métricas muestran una mejoría mayor al 30% entre latencia y duración.
Para la revisión de una correcta alineación de discos, es recomendable tener claro varios conceptos:
- Starting Partition Offset: Es el punto inicial en la partición del volumen que garantiza la omisión de asignación de páginas de datos en n sectores ocultos al principio de los volúmenes.
- Stripe Unit Size: Es la granularidad a la que la data se almacena en un disco del arreglo antes de que la data subsiguiente sea almacenada en otro disco del arreglo. Este valor es proporcionado por su administrador de la SAN
- File Allocation Unit Size: Es conocido también como Clúster Size, y representa la cantidad mínima de espacio de disco que puede ser suministrado para contener un archivo y se determina cuando la partición es formateada por el sistema operativo.
Existen dos reglas, que se deben cumplir para una correcta alineación de discos. Los resultados de los cálculos siguientes han de dar un valor entero.
Partition_Offset / Stripe_Unit_Size
Stripe_Unit_Size / File_Allocation_Unit_size
De las dos reglas anteriores, la primera es la más importante para conseguir un rendimiento óptimo.
Ejemplos de Escenarios con desalineación en los discos
Dada una partición con Starting Partition Offset de 32.256 bytes (31,5Kb) y con un tamaño en Stripe Unit Size de 65.536 bytes (64 Kb), el resultado de Partition_Offset ÷ Stripe_Unit_Size es de 0.4921875, no es un número entero, por lo que se consideran que los discos no están alineados.
Ejemplo de escenario con alineación en los discos
Dada una partición con Starting Partition Offset de 1048576 bytes (1Kb) y con un tamaño de Stripe Unit Size de 65.536 bytes (64 Kb), el resultado de Partition_Offset ÷ Stripe_Unit_Size es exactamente 8, un numero entero exacto, lo cual se puede decir que la alineación es correcta.
Después de todo lo anterior explicado, la pregunta que hace falta contestar es… ¿Y como puedo consultar el estado actual de los discos?
Para revisar el valor del Starting Offset en discos basicos, podemos utilizar el comando WMIC (Windows Management Instrumentation Command-line) para obtener los datos del disco, la sintaxis es la siguiente:
wmic partition get BlockSize, BootPartition, DeviceID, DiskIndex, HiddenSectors, NumberOfBlocks, StartingOffset, Name, Index
El valor a verificar con el commando anterior es StartingOffset, en este ejemplo está alineado a 1024 kb.
También se puede obtener el resultado a través de DISKPART, seleccionando el disco a analizar y ejecutando el comando list partition, en el cual se obtendrá el Offset.
Para revisar el Starting Offset en discos básicos se deberá utilizar la utilidad dmdiag con el switch -v
Si se desea revisar el valor del File_Allocation_Unit_Size se puede ejecutar el comando
fsutil fsinfo ntfsinfo [drive]
El siguiente ejemplo muestra la ejecución de todos los comandos anteriormente escritos.
Muchos factores contribuyen para un óptimo performance de disco. Para las particiones de disco creadas con Windows Server 2003, es adecuado validar la correcta correlación entre el Stripe Unit Size y File Allocation Unit Size como best practice. Windows Server 2008 crea particiones alineadas por default y aunque para la mayoría de los casos es adecuada, es importante siempre preguntar y seguir las mejores practicas del Vendor de discos. Cuando los servidores son actualizados de Windows Server 2003 a Windows Server 2008, las particiones preexistentes no se alinean automáticamente, es recomendable reconstruirlas para un rendimiento óptimo.
¿Qué es Integration Services?
Es una herramienta que permite obtener datos de diversas fuentes, transformarlos y cargarlos a bases de datos, hojas de trabajo, archivos de texto u otro destino que sea compatible con OLE-DB.
Historia
En las versiones SQL Server 7 y 2000, las capacidades de ETL (Extracción, Transformación y Carga) eran provistas por Data Transformation Services (DTS)
A partir de SQL Server 2005, Microsoft decidió que la gran variedad de innovaciones implementadas en la nueva versión justificaban el nuevo nombre. Como resultado surgió SQL Server Integration Services (SSIS)
Mejoras en la versión 2012 de SSIS
Cambios generales en la interfaz
1. Caja de herramientas de SSIS
La caja de herramientas de SSIS te permite agregar treas y componentes del flujo de data a un paquete, en vez de usar la caja de herramientas de Visual Studio, que se utiliza en versiones anteriores. Además incluye una descripción para el ítem que está seleccionado. También incluye dos categorías: Favoritos y Común.
2. Parámetros
El diseñador del paquete incluye una nueva lengüeta para abrir la ventana de los parámetros para un paquete. Los parámetros permiten que usted especifique los valores en tiempo de ejecución para el paquete, el contenedor, y las propiedades de la tarea o las variables.
3. Botón de variable
Este nuevo botón en la barra de herramientas del diseñador del paquete proporciona el acceso rápido a la ventana de las variables.
4. Botón de Caja de herramientas de SSIS
Este botón permite que usted abra la caja de herramientas de SSIS cuando no es visible.
5. Comenzando (Getting Started)
Proporciona el acceso a los enlaces de los vídeos y los ejemplos que usted puede utilizar para aprender a trabajar con Integration Services.
6. Control de Acercamiento (Zoom control)
Usted puede acercar o alejar a un tamaño máximo de 500 por ciento de la visión normal o a un tamaño mínimo del 10 por ciento, respectivamente.
7. Administrador de Conexiones Compartidas (Shared Connection Managers)
La carpeta Administrador de Conexiones es un nuevo contenedor que puede ser compartido entre múltiples paquetes. Para crear un nuevo Administrador de Conexiones compartidas siga los siguientes pasos:
8. Deshacer y Rehacer (Undo / Redo)
Estas opciones fueron añadidas como parte de las herramientas de datos de SQL Server. A través de esta opción se puede editar el control de flujo o flujo de datos y revertir o reaplicar los cambios. Estas opciones también funcionan en la ventana de variables, en el manejador de eventos y parámetros. Se puede utilizar Ctrl+Z para Deshacer o Ctrl+Y para reaplicar.
9. Paquetes ordenados por Nombre
Los paquetes pueden ser ordenados por nombre al presionar el botón de la derecha del ratón sobre la carpeta Paquetes de SSIS.
10. Indicador de estatus
La interfaz del usuario ahora presenta íconos en la esquina superior derecha de cada ítem para indicar si la ejecución fue exitosa o fallida.
Control de flujo
1. Tarea de Expresión
El propósito de esta tarea es el facilitar la asignación de un valor dinámico a una variable.
2. Tarea de Ejecución de Paquete
Esta tarea incluye una nueva propiedad llamada Tipo de Referencia que permite especificar la localización del paquete a ser ejecutado. Si se selecciona Referencia del Proyecto, usted podrá seleccionar el paquete hijo desde una lista. Si se selecciona Referencia Externa, usted podrá configurar la ruta del paquete hijo como se hacía en versiones anteriores.
Flujo de Datos
Entre las mejoras se encuentran:
1. Los Asistentes para la selección de fuentes y destinos.
2. Transformaciones de Merge y Merge Join
Estas transformaciones permiten recolectar datos de dos fuentes y producir una sola salida de los resultados combinados. La versión actual se ajusta automáticamente a las presiones de memoria.
3. Transformación de Limpieza de Datos para DQS
Es un nuevo componente que se usa en conjunto con Data Quality Services (DQS)El propósito es ayudar a mejorar la calidad de los datos a través de reglas establecidas para el dominio de los datos. Se pueden crear reglas para hacer pruebas a los datos por errores comunes como errores de escritura en un campo tipo texto o asegurar que el largo de una columna cumple con las especificaciones.
4. Grupo que puede ser Colapsado
Permite consolidar los componentes del flujo de datos en grupos que pueden expandir o colapsar. Para crear un grupo, siga los siguientes pasos:
Transferencia del Proyecto (Deployment)
En SSIS 2012 se utiliza un proyecto el cual es almacenado en un archivo con la extensión ISPAC. El proyecto es una colección de paquetes y parámetros. Usted puede transferir el proyecto a un catálogo de Integration Services. A diferencia de versiones anteriores donde se utilizaban configuraciones, en esta versión se utilizan parámetros para asignar valores a las propiedades del proyecto en tiempo de ejecución. Antes de ejecutar un paquete, se debe crear un objeto de ejecución en el catálogo y opcionalmente asignarle valores a los parámetros o hacer referencia al ambiente del objeto de ejecución.
El catálogo de SSIS esencialmente es una aplicación de SQL (una base de datos del usuario en una instancia de SQL con un conjunto de procedimientos almacenados y un API de T-SQL.
Creación del catálogo
El instalar Integration Services no crea automáticamente el catálogo. Para crear el catálogo hay que realizar los siguientes pasos:
1) En SQL Server Management Studio, conéctese a la instancia, presione el botón de la derecha del ratón sobre la carpeta de Integration Services en el Explorador de Objetos y seleccione Crear el Catálogo.
2) En la pantalla de Creación del Catálogo, seleccione la opción de habilitar la integración CLR. Esta opción es requerida para administrar la funcionalidad de Integration Services.
3) Opcionalmente se puede seleccionar la opción de Ejecución automática de Procedimientos Almacenados de Integration Services. Este procedimiento almacenado realiza una operación de limpieza cuando el servicio se ejecuta y ajusta el estatus de los paquetes que fueron ejecutados cuando el servicio es detenido.
4) El nombre de la base de datos no puede ser cambiado (SSISDB) así que como paso final se requiere proveer una contraseña compleja y presionar OK. La contraseña crea una llave maestra a nivel de base de datos que es utilizada por Integration Services para cifrar los datos sensitivos que han sido almacenados en el catálogo.
Herramientas para detección de fallas y bitácoras
Los reportes de Integration Services localizados en SQL Server Management Studio proveen información a cerca de los resultados de ejecución de los paquetes en las últimas 24 horas. Estos incluyen información de rendimiento y mensajes de error para el caso de los paquetes fallidos.
Cambios en el formato de los paquetes
La meta de estos cambios fue el facilitar la lectura e identificar más fácilmente las diferencias cuando se trabaja con sistemas de control de fuentes.
Formato de SSIS 2008
Formato de SSIS 2012
Resumen
Unos de los cambios mayores es la introducción del modelo de proyecto para simplificar los cambios a los valores del paquete en tiempo de ejecución. Un beneficio de este modelo es el catálogo. El catálogo almacena información a cerca de paquetes, validaciones, y resultados de ejecución en tablas que pueden ser consultadas a través de vistas o de reportes. El acceso a la información nos provee de una gran visibilidad de Integration Services lo cual no era posible realizar fácilmente en versiones anteriores.
En los últimos 6 meses me encontré con 2 casos de linked servers entre una instancia de SQL Server 2008 R2 64 bits en un Cluster de Windows 2008 R2 y una instancia standalone de SQL Server 2000 32 bits en los cuáles los cuáles las transacciones distribuidas no estaban funcionando.
La causa raíz del problema sigue en investigación, sin embargo, tratando de entender el problema verifiqué que todo estuviera bien configurado y realicé algunas pruebas.
Revisé lo siguiente:
- Que la resolución de nombres funcionara bien
- Que el DTC estuviera bien configurado en cuanto a la sección de seguridad
- Se probó el linked server sin transacción distribuida y funcionaba
- El DTCPing dio resultado correcto
- Hasta donde recuerdo el DTCTester también dio resultado correcto.
Aún cuando todos los puntos anteriores fueron exitosos, las transacciones distribuidas seguían fallando. En las pruebas que hice, probé creando un DTC Clusterizado en el grupo de SQL Server 2008 y siguió fallando.
Después, sin muchas esperanzas, probé borrando todos los DTC Clusterizados y configurando los DTC locales y, para mi sorpresa, funcionó.
En éste punto la pregunta se convirtió en, ¿Que desventajas tengo en utilizar los local DTC’s en lugar de los DTC’s clusterizados?, así que tuve que investigar y probar éste punto.
Antes que nada, ¿Cuál es la razón de tener DTC’s clusterizados?, antes de Windows Server 2008, la razón era que en Windows Cluster la única forma de utilizar el MSDTC era clusterizándolo, sin embargo en Windows Server 2008 el número de opciones aumentó. Ahora es posible tener más de un DTC clusterizado y también es posible utilizar el DTC no clusterizado de cada nodo. Entonces, ¿Sigue siendo necesario clusterizar el DTC?, ¿Cuáles son los beneficios de clusterizarlo y cuáles son las limitantes de solo utilizar el local DTC?
La respuesta corta (basado en mi conocimiento y pruebas) es que hay algunos escenarios por los que el ambiente clusterizado tiene beneficios, pero en muchos casos la diferencia es muy pequeña y puedes usar el local DTC en lugar del DTC clusterizado con muy poco riesgo.
¿Cuándo es preferible usar el DTC Clusterizado en lugar del local?, Un escenario es cuando tienes múltiples instancias de SQL Server en cada nodo. En ese caso con local DTC todas las instancias usarán el único DTC disponible en la instancia, si quieres mayor escalabilidad y disponibilidad entonces es recomendable configurar múltiples DTC’s clusterizados, uno para cada instancia.
Otro escenario sería cuando el DTC local falla, en ese caso, las instancias no van a hacer failover automático, en cambio, si estuviéramos utilizando un DTC Clusterizado, el failover del DTC es automático y solo las transacciones distribuidas activas hacen rollback, las nuevas transacciones distribuidas corren sin problema.
En resumen, es recomendable tener los DTC clusterizados, sin embargo, si estás teniendo problemas prueba con los DTC locales para ver si eso soluciona tu problema.
Hola a todos, hace algunos días reflexionaba que pese al uso común que personalmente hago del stored procedure xp_readerrorlog (o bien sp_readerrorlog) para revisar el log de errores de SQL Server, si realizamos una búsqueda del comando en la ayuda de SQL Server no encontraríamos referencias al mismo. Así como este stored hay varios más que no están documentados en la ayuda de SQL Server pero que en un momento dado nos pueden ser útiles para revisar información que necesitemos conocer.
En esta entrada al blog platico un poco acerca de estos “undocumented stored procedures” y presento una lista de algunos que pueden ayudarnos en nuestras actividades diarias.
Algunos autores opinan que en muchos casos no hay una razón importante para que Microsoft no libere documentación acerca de algunos de estos stored procedures con el objetivo de que los administradores y usuarios de SQL Server pudieran utilizarlos sin problemas, o bien, que en todo caso, ninguno de ellos debería estar accesible para su ejecución por parte de los administradores de los sistemas.
La posición anterior, si bien tiene un poco de lógica desde la perspectiva de usuario final, me parece que no es del todo correcta, según lo que he podido investigar muchos de estos stored procedures, y en general otras herramientas no documentadas disponibles en SQL Server (comandos DBCC, Funciones, Trace Flags y Startup Options) pudieron ser utilizados para propósitos de “testing” durante el desarrollo del Producto o bien fueron creados con propósitos de “deep debuggin” para Soporte del mismo.
Creo que no es casualidad u olvido (como algún otro autor opina) que las herramientas mencionadas no estén documentadas, muchas de ellas pueden llegar a ser “peligrosas” en su utilización, el que no estén documentadas también nos advierte del hecho que en cualquier momento (con la liberación de algún hotfix, parche de seguridad, service pack o bien una nueva versión del producto) puede ser cambiada su funcionalidad, el comportamiento de su ejecución o definitivamente ser eliminadas, es también muy probable que la funcionalidad de cada uno de ellos no este revisada con exhaustivos casos de prueba, así que definitivamente no es recomendable su utilización por parte de usuarios finales en sus aplicaciones (no deben incluirse referencias a ellos en el código), tampoco debe hacerse dependiente algún proceso de su ejecución.
Para poner un ejemplo de que tan real es el riesgo al que se expone alguno de nuestros clientes que implemente dentro de su código llamadas a alguno de estos procedimientos, basta mencionar que mientras preparaba esta entrada al blog, me enteré de que el uso de procesador de un server se iba a rangos del 100%, en tal servidor está instalada una instancia de SQL Server 2005 SP3, y en dicha instancia se estaba ejecutando un proceso del cliente que hace una llamada al xp_readerrorlog precisamente, es muy probable, de acuerdo al escenario que se presenta, que la causa raíz del problema sea un bug relacionado a la ejecución del extended stored procedure mencionado (http://support.microsoft.com/kb/973524).
Por tanto debe entenderse que, el posible uso que hagamos de cada uno de los stored procedures no documentados, es bajo nuestro propio riesgo, sin embargo como ya he mencionado antes, algunos de ellos pueden ser altamente útiles en nuestras actividades diarias.
A continuación menciono algunos procedimientos no documentados que nos pueden ser de utilidad:
La ejecución de este extended stored procedure nos da como resultado una lista de todas las sub-carpetas de una carpeta especificada como parámetro de entrada:
EXECUTE master.sys.xp_dirtree '<path>'
Existe otro extended stored procedure (xp_subdirs) que sólo nos regresa las sub-carpetas del primer nivel, es decir, es el resultado de xp_dirtree con la condición depth = 1.
El resultado de su ejecución es la lista de todos los proveedores de OLE DB disponibles para SQL Server:
EXEC master.sys.xp_enum_oledb_providers
Su ejecución nos regresa una lista de todos los archivos de log de SQL Server (error logs) con su última fecha de modificación:
EXECUTE master.sys.xp_enumerrorlogs
Al ejecutarse regresa a lista de los grupos de Windows y su descripción:
EXECUTE master.sys.xp_enumgroups
Regresa una lista de todos los discos (drives) y el monto de espacio libre (en MB) para cada uno de ellos:
EXEC master.sys.xp_fixeddrives
Para terminar, como ya había mencionado, uno de los que más uso. Regresa el contenido de los archivos de log de errores de SQL Server, me parece muy útil así cuando buscamos errores que están ocurriendo en las instancias:
EXEC master.sys.xp_readerrorlog
Puede recibir hasta siete parámetros:
i. Valor del archivo de log de errores que deseas leer: 0 = actual, 1 = Archivo #1, 2 = Archivo #2, etc…
ii. Tipo de archivo de log de errores que quieres leer: 1 or NULL = Error Log, 2= SQL Agent Log
iii. Cadena de búsqueda 1: Cadena de caracteres para condicionar los resultados mostrados, es decir un “string” que estés buscando.
iv. Cadena de búsqueda 2: Cadena de caracteres secundaria para realizar una búsqueda mucho más precisa.
v. Fecha/Hora de inicio de la búsqueda: Se buscará a partir de la fecha y hora indicada en este parámetro.
vi. Fecha/Hora de fin de la búsqueda: Se buscará y desplegarán resultados (si los hubiera) hasta la fecha y hora especificadas en este parámetro.
vii. Ordenamiento para los resultados: N'asc' = ascendente, N'desc' = descendente.
El stored procedure master.sys.sp_readerrorlog hace una llamada a xp_readerrorlog pero a diferencia de éste sólo puede recibir los primeros cuatro parámetros mencionados.
Como pudimos darnos cuenta, los stored procedures que presento como ejemplo son extended estored procedures, recordemos que éstos son una ejecución de una “dynamic link library” que corre directamente dentro de SQL Server, en la mayoría de los casos estos extended stored procedures sólo pueden ser ejecutados por usuarios con privilegios de sysadmin.
Existen más stored procedures no documentados en SQL Server 2008, si se desea obtener la información de los stored procedures disponibles en nuestra instancia de SQL Server 2008 y de allí buscar cuales aparecen en la ayuda y documentación del producto y cuáles no, podemos usar la siguiente consulta:
SELECT OBJECT_NAME(c.id), c.*
FROM master..syscomments c JOIN master..sysobjects o ON c.id = o.id
WHERE o.type in('X', 'P')
ORDER by 1, 4
*Como curiosidad: La herramienta de IntelliSense (nueva para SQL Server 2008) puede llegar a presentar información de algunos stored procedures no documentados (también de algunas funciones), como ejemplo puede probar escribiendo:
EXECUTE master.sys.sp_re
verá que IntelliSense ubica el stored sp_readerrorlog (aunque no aparece referencia a éste en la ayuda de SQL Server 2008) y te da información acerca del número de parámetros que puede recibir