Llegamos a ustedes gracias a:



Reportajes y análisis

Siete razones para seguirle la pista al SQL Server 2008 R2

[28/06/2010] Con Microsoft SQL Server 2008 R2, Microsoft comienza a cristalizar finalmente su visión de SQL Server como una plataforma de información y no "solamente" una base de datos. Es por eso que el eje de este lanzamiento -según Microsoft, por lo menos- es el concepto de autoservicio en BI. De todos sus nuevos atributos, los plug-ins PowerPivot para Excel 2010 y SharePoint 2010 son, sin lugar a dudas, los que causarán mayor entusiasmo, y no solo por tratarse de los más completos. Sin embargo, como el sistema funciona con varias fuentes datos, no es estrictamente necesario usar SQL Server 2008 R2 para trabajar con PowerPivot for Excel.

Hay otros atributos que también justifican un detenido análisis, y que no requieren Office 2010 ni SharePoint 2010. Por ejemplo, StreamInsight y Master Data Services deberían tomar viada en corto plazo, mientras que otros, como el SQL Server SysPrep y el DACPAC, necesitan unos minutos más de cocción. En general, SQL Server 2008 R2 es un sólido lanzamiento provisional, a pesar de que algunas de sus novedades más importantes no están a la altura de las expectativas.
Además de los nuevos atributos, otra modificación que puede tener repercusión en el negocio es la incorporación de la nueva edición Datacenter. Junto con el nuevo SKU, Microsoft le ha hecho un downgrade a la edición Enterprise para que soporte solo ocho CPU. Si tiene un servidor SQL Server 2008 Enterprise, tome en cuenta esta modificación antes de actualizarse a R2.
Personalmente, opino que los niveles para Enterprise han sido fijados a un nivel demasiado bajo. Los negocios que tienen servidores de 16-CPU no van a actualizarse al R2 si ello significa que tendrán que pagar unos 60 mil dólares por procesador. Un punto de inflexión más realista para la edición Datacenter sería superar los 64 CPU.
De todas maneras, si es de los que no tiene que lidiar con la disyuntiva Enterprise vs. Datacenter, hay un puñado de buenas razones para actualizarse a R2, y dos o tres de ellas pueden ser más que convincentes. 
Razón No. 1: Self-service BI
El nuevo concepto de gestión de autoservicio de BI que propone Microsoft implica principalmente combinar el SQL Server 2008 R2 con los nuevos plug-ins PowerPivot para obtener robustos sets de columnas en Excel 2010 o SharePoint 2010. La clave para que esta propuesta funcione consiste en usar la compresión de nivel de columna en el conjunto de data, de forma que PowerPivot pueda procesar millones de columnas en la misma cantidad de tiempo que normalmente le tomaría a Excel procesar solo miles de columnas. 
No hay duda de que los profesionales del sector financiero estarán de plácemes con PowerPivot, aunque en realidad todos los usuarios de Excel podrían sacarle provecho. Es complicado hacer caber un conjunto de datos relativamente importante en Excel: aunque consigamos pasar todas las columnas a la memoria, procesarlas puede tomar una eternidad. Ya ni sé cuántas veces he tenido ese tipo de problema al intentar analizar datos de perfomance, así que estoy seguro de que muchos usuarios de Excel estarán más que agradecidos por la incorporación de PowerPivot.
Cabe recordar que PowerPivot for Excel no solo puede extraer data de SQL Server sino también de casi cualquier base de datos. La participación del SQL Server 2008 R2 solo es solicitada para alimentar los libros de PowerPivot compartidos a través de SharePoint 2010. Los plug-ins PowerPivot para Excel 2010 y SharePoint 2010 ya se pueden descargar gratuitamente en http://www.powerpivot.com/.
Razón No. 2: Report Parts
Uno de mis atributos preferidos del R2 es el nuevo Report Parts, que se encuentra en el Report Builder 3.0. Report Parts permite publicar las diferentes secciones de un reporte en una biblioteca centralizada, donde otras personas pueden tomarlas para incluirlas en sus propios reportes. Así, tablas, cuadros y otros segmentos se convierten en componentes que podemos agregar a cualquier reporte. 
Digamos que crea un cuadro con una serie de cálculos complejos adjuntos, como sofisticadas fórmulas de composición o reglas del negocio. Si las publicamos como Report Part, cualquiera podrá hacer referencia a los mismos cuadros en sus reportes. Mejor aun - me da escalofríos de solo pensarlo-: todos los reportes que mencionen este cuadro solamente están extrayendo un ejemplar de del objeto de la biblioteca. Si cambia la lógica en la copia del cuadro que figura en la biblioteca, el cambio se propagará inmediatamente a todos los reportes que lo usan. (Los usuarios posteriores que no deseen que el contenido se actualice pueden desconectar el Report Part de la biblioteca.)
En resumen, mucho poder en nuestras manos. Editar estos Report Parts fue tan sencillo que pensé que estaba cometiendo algún error. Me encanta este atributo.
Razón No. 3: StreamInsight
StreamInsight es el nombre del nuevo motor de procesamiento de eventos complejos de Microsoft, el mismo que ha sido implementado como un conjunto de clases de.Net. Con StreamInsight resulta verdaderamente sencillo manejar el procesamiento de eventos en transferencia -ejecutando rápidamente los queries en un flujo de información-, lo cual a su vez nos permite tomar decisiones con mayor prontitud. En este caso, hay muchos ejemplos de aplicación, pero uno de mis favoritos es el de los servidores de monitoreo de producción. 
Digamos que se encuentra monitoreando las mediciones de un CPU para un servidor y no desea repetir cada medida en la base de datos. Con StreamInsight, podría capturar los eventos del CPU conforme vayan ocurriendo, agregarlos como desee, y solo repetir las mediciones agregadas en la base de datos. También podría correlacionar las mediciones del CPU con otros registros para deducir su significado real  y lograr alertas más precisas.
Si bien es un ejemplo simple, debería dar una idea de los tipos de acción que se pueden realizar. Es importante precisar que si bien StreamInsight no es un atributo fuera de lo común, tiene que estar escrito en aplicaciones .Net applications. Asimismo, aunque es muy probable que los programadores padezcan un poco para acostumbrarse a StreamInsight, sin duda terminarán agradeciendo a Microsoft por haberles allanado tan estupendamente el camino.
Razón No. 4: Master Data Services
Master Data Services ayuda a los negocios a construir y mantener una fuente autorizada para la información crítica, como productos, clientes, posiciones, cuentas, empleados, etc. Master Data Services es una base de datos, una interfase usuario y un conjunto de servicios que les permite a las organizaciones construir rápidamente un modelo para administrar la data del sistema de dimensiones u otros. Puede contener reglas de validación, notificaciones y roles de seguridad. Cuenta con función de versiones y permite revertir los cambios no deseados de la información. Master Data Services puede servir como un sistema de registro o de control. Usando herramientas estándar (como SQL Server Integration Services o BizTalk), la data se puede enviar hacia o desde Master Data Services, según los requerimientos del negocio.
¿Qué significa todo esto en cristiano? En pocas palabras, el enfoque de Master Data Services consiste en un modelo de data y una base de datos. El usuario pasa la información de su empresa a través del motor master data, que valida los datos confrontándolos con las reglas antes de enviarlos. Por lo general, uno tiene que construir manualmente sus modelos, pero eso no suele ser impedimento para la implementación, sobre todo tomando en cuenta que solo se supone que aplicaremos Master Data Services a algunos sistemas importantes que necesitan verificación extra. De todas maneras, sería interesante que Master Data Services pudiera leer el modelo y, durante el proceso, permitir que los usuarios se concentren en crear las reglas. 
Razón No. 5: Monitoreo multiservidor 
El SQL Server Utility Control Point es el corazón de las nuevas capacidades de gestión multiservidor del R2. Gracias a él, ahora podemos monitorear el estado de los recursos a través de varios servidores SQL. Sin embargo, hasta el momento no soporta acciones en ítems ajenos a sus parámetros, lo cual significa, que en lo que respecta a las medidas que nos muestra, Control Point es solo lectura. Otra limitación: la edición Enterprise solo reconoce 25 ejemplares; para administrar más tendríamos que saltar a la edición Datacenter. Este uno de los puntos en los que el Enterprise SKU ha fijado niveles muy bajos: nunca he trabajado en una empresa donde 25 sea un límite aceptable para el monitoreo de nodos múltiples. 
¿Qué controles se pueden medir? Por lo general, se puede ver el servidor CPU y la instancia CPU, junto con las estadísticas de almacenamiento más importantes. La distinción servidor CPU e instancia CPU es muy útil cuando, por ejemplo, encontramos una incidencia sostenida en el CPU y queremos asegurarnos de que se trata de algo relacionado con la instancia de base de datos antes de seguir tratando de resolver el problema. Otra capacidad interesante es la posibilidad de ver el CPU en bases de datos individuales: cuando se tienen muchas bases de datos en el servidor es importante saber cuál de ellos está causando el problema. 
En cuanto al almacenamiento, la utilización del volumen de almacenamiento se puede ver tanto en el nivel drive como en las estadísticas de espacio de la base de datos y en los niveles de grupo de archivo y archivo (data y log). Es bien sabido que -además de las estadísticas de I/O y fila de espera- las estadísticas de almacenamiento son las que más preocupan a los administradores de bases de datos, de manera que estas funcionalidades les ahorran buena parte del trabajo. A pesar de que le falta todavía buen trecho para proveer control real, el Utility Control Point ofrece un buen nivel de monitoreo y seguramente hará que los usuarios comiencen a preguntarse qué es lo que realmente les gustaría encontrar en una herramienta como esta.
Razón No. 6: DACPAC
DACPAC, o paquetes de componentes de aplicación de nivel de datos por sus siglas en inglés (Data-tier Application Component Packages), es un atributo que ha recibido mucha propaganda y que permite que los desarrolladores reúnan los cambios de bases de datos en un solo archivo en Visual Studio y lo envíen al administrador para su implantación. Se trata de un avance significativo respecto a la manera en que se distribuyen las modificaciones actualmente. Hoy por hoy, los cambios se envían como una serie de archivos .SQL con instrucciones de implantación o como un conjunto de pautas de Team Foundation Server para que el administrador extraiga el mismo documento de implantación. En ambos casos, el proceso ocasiona problemas de implantación, debido a que requiere demasiada interacción humana y deja espacio para malas interpretaciones.
Con DACPAC, el administrador de la base de datos recibe -de parte de los desarrolladores- un solo archivo de implantación con todos los cambios; no hay lugar para confusiones ni olvidos. Sin embargo, esta primera encarnación de DACPAC no está exenta de problemas. Para ejecutar el cambio más mínimo en la base de datos, DACPAC reproduce completamente la base de datos y todos sus objetos, luego pasa toda la información a las estructuras duplicadas. En el paso final, abandona la base de datos original y le da un nombre a la nueva. Obviamente, no siempre tiene sentido crear una nueva copia de la base de datos para una pequeña modificación de código. Además, DACPAC no copia los permisos de usuarios ni trabaja con gestores de servicio o replicación de objetos. 
Si bien se trata de una gran idea, el DACPAC solo es recomendable para bases de datos muy pequeñas con estructuras muy limitadas. No obstante, hay que seguirle la pista a este atributo: sospecho que muchas de estas limitaciones serán corregidas en las versiones futuras. El DACPAC está destinado a ser cada vez mejor.
Razón No. 7: SQL Server Sysprep
SQL Server Sysprep es un atributo realmente simpático que, con toda seguridad, hará las delicias de los administradores de bases de datos. Sin embargo, al igual que DACPAC, su utilidad se ve recortada debido a ciertas limitaciones de esta versión inicial. Tal como el Sysprep de Windows, el Sysprep de SQL Server permite instalar el software y dejar la configuración final para más tarde. Esta posibilidad resulta más interesante cuando se usa el SQL Server Sysprep en combinación con Windows Sysprep, de manera que  el SQL Server 2008 R2 se puede instalar con el sistema operativo durante el suministro de servidor; y luego lo único que tiene que hacer el administrador es configurarlo. Desgraciadamente, esta versión solo cubre el motor de base de datos y los servicios de reporte; mientras que las herramientas, los servicios de información y clustering no están disponibles. Mayormente, cuando estas últimas no se pueden pasar por el Sysprep, hay que instalar SQL Server 2008 R2 desde cero.
Sean McCown, InfoWorld (US)