28 mayo 2009

Ojo con el SP2 de Sharepoint

Poniéndome al día en la web encontré esta noticia muy importante (Attention: Important Information on Service Pack 2)  con respecto al SP2 para Sharepoint. Este es el mensaje oficial del problema de la página de Help and Support de Microsoft:

“During the installation of Service Pack 2 a product expiration date is improperly activated. This means Office SharePoint Server will expire as though it was a trial installation 180 days after SP2 is deployed.  The activation of the expiration date will not affect the normal function of SharePoint up until the expiration date passes, 180 days after SP2 installation. If the product expires, it will not affect data, configuration or application code but will render SharePoint inaccessible for end-users.”

Como se menciona, una vez instalado dicho componente, se activa incorrectamente el mecanismo de “product expiration”, lo cual les da 180 días más de uso de Sharepoint antes de que “expire” y por tanto no lo podrán usar más. Según la noticia, la forma de reparar manualmente este bug es ingresando nuevamente el ID de instalación (ProductID) en la página “Convert License Type” en el “Central Administration” de su Sharepoint.

De todos modos esto no debe desatar mayor pánico con respecto a nuestra data ya que este “bug” no afecta nada de nuestra data o meta-data. Microsoft ya está trabajando en un fix que desactive este mecanismo incorrecto. Para no correr el riesgo si ya instalaron el SP2 los insto a corregir el problema manualmente con el ProductID.

Finalmente, aún es recomendable instalar el SP2, más aún si alguno de los fix o nueva funcionalidad está cubierto en esta actualización.

Alan

19 mayo 2009

Kilimanjaro = SQL Server 2008 R2

Leí un artículo súper interesante que salió del último TechEd 2009. La novedad es que lo que hasta hace algunos días se conocía como SQL Server Kilimanjaro (la próxima versión de SQL Server), ya ha sido oficialmente bautizada como SQL Server 2008 R2 (Release 2). Pueden leer el artículo original en http://www.sqlmag.com/Articles/ArticleID/102112/102112.html?Ad=1 

Actualmente tenemos disponible la versión 10 de SQL (SQL Server 2008). Ya que Kilimanjaro es la versión 10.5, hace mucho sentido que hayan bautizado esta nueva versión como R2 para no dejarnos con una versión intermedia (.5) o 2009 lo cuál sería un cambio demasiado rápido para la versión actual ya que incluso todavía hay mucha gente con servidores en versión 2000. Por otro lado, como decimos por aquí, “aparente y alegadamente” al ser una versión R2 de SQL Server 2008, los clientes que hayan comprado la versión original de SQL 2008, se deberían beneficiar automáticamente con ésta actualización. Lo cual habla muy bien del compromiso de Microsoft para seguir mejorando el producto y de beneficiar a las inversiones ya hechas en su producto (todo lo contrario a lo que hizo con PPS Planning y eso es bueno Open-mouthed).

Vendrían muchas cosas nuevas en el R2, pero las características que más me entusiasman son lo que hasta ahora se conocía como Project Gemini (self service in-memory analysis) y Master Data Services.

A continuación un resumen básico a 3,000 metros de altura (~ 10,000 pies).

Project Gemini: Autoservicio en Inteligencia de Negocios (Self-Service BI)

Gemini tiene como objetivo darle más posibilidades al usuario final para realizar sus análisis incluyendo millones de filas en cuestión de segundos (¡y realmente son pocos segundos!), apoyado de  las características de BI de Excel 2010 (¡que son alucinantes!) para hacer “slice & dice”, filtros, ordenamiento, etc.; y finalmente, publicar sus resultados a la intranet para compartirlos con su grupo de trabajo.

¡Hey, hey, hey!!! ¡Un momentito aquí!, ¿y qué pasó con la problemática de la fragmentación de datos?, muchas hojas de Excel en las PCs de los usuarios, múltiples “formas de la verdad” lo cual nos complicaba construir un simple reporte consolidado porque no sabíamos qué usuario tenía la última versión de los datos. O en todo caso, tener que pasar muchas horas haciendo tareas de limpieza de datos, consolidación y esas cosas aburridas para lograr tener una versión “oficial” de nuestros datos.

Confieso que me costó hace unos meses entender un poquito esto, pero estos chicos de Microsoft obviamente lo pensaron ya. Gemini busca hacer todo lo que mencioné anteriormente pero con la bendición de la gente de TI. Esto quiere decir, que TI es quien define aspectos claves como dónde residirán los datos, la permisología (quién accede a qué), los tiempos en que la data será actualizada (data refresh), etc. Así que de esta forma Gemini, busca dar “al César lo que es del César”, pues los usuarios, quienes saben qué es lo que realmente quieren hacer con sus datos, tendrán más poder para utilizarlos sin depender de la gente de TI; y la gente de TI se encarga del trabajo “sucio”, incluyendo las tareas de limpieza, integración y seguridad lo cual es su especialidad.

Master Data Services

Con respecto a Master Data Services éste ataca una necesidad totalmente de la vida real, pues tal vez muchos de ustedes tal como yo, han tenido que lidiar con muchas fuentes de información en donde supuestamente hay una entidad que debe ser común a todos los sistemas fuentes pero no lo es. Un ejemplo más sencillo; en uno de mis proyectos para la industria turística, cada hospedería (hotel, motel, hospedaje, parador, etc.) debía tener un identificador único para realizar procesos o trámites en distintas entidades o dependencias. El problema es que cada una de estas dependencias tenía su propia base de datos de las hospederías con identificadores únicos pero distintos a las demás fuentes, y lo que complicaba más el asunto, con información básica como el nombre o dirección de la hospedería distinta en cada sistema (probablemente por errores de entrada de datos o en la frecuencia de actualización de los mismos).

Ante esta problemática tuvimos que crear nuestro propio mecanismo de “Master Data Management” (MDM) para esta entidad clave (hospederías) la cual es el eje de todas las operaciones de esta industria. Este mecanismo se encarga de consolidar las distintas fuentes de información, asignar quién es propietario de cada atributo (o pedazo de información) de la hospedería y algunas otras reglas de negocio para la sincronización de todas las fuentes de datos con los mismos datos. Sólo atacando este problema de MDM, nuestro cliente puede dedicarse ya a resolver los problemas del negocio y no de los datos de las hospederías. De esto es lo que trataría (aún no lo he visto “live”) SQL Server Master Data Services: proveer una infraestructura para manejar problemas de Master Data Management. Este tipo de problemática se ha puesto aún muy de moda debido a que en los últimos años se han fusionado muchas compañías (Oracle compra Hyperion, IBM compra Cognos, Microsoft compra Proclarity, HP compra a Compaq, y la lista de casos sigue). ¿Cómo hacen estas compañías para consolidar sus sistemas u orquestar sus fuentes de información de una forma eficiente y en el mejor tiempo posible? Master Data Services al rescate.

08 mayo 2009

Analysis Services Dynamic Management Views (DMV)

Hasta ahora el poder monitorear nuestro servidor de Analysis Services había sido todo un reto. No todos encontramos muy fácil el usar los Contadores de Rendimiento (Performance Counters) u obtener información dentro de los arhivos de log del servidor. Por otro lado a veces el comprar una herramienta de terceros para lograr este fin puede no ser muy costo/efectivo cuando lo que necesito en la mayoria de los casos es ver cuáles son los procesos (consultas) ejecutándose actualmente y, para en algún caso, eliminar los procesos que me estén bloqueando el servidor o tomando mucho tiempo en obtener un resultado.

Para nuestro beneficio Analysis Services 2008 viene al rescate introduciendo los Dynamic Management Views (DMV) ó Vistas de Administración Dinámica, un concepto idéntico al que existe en SQL Server desde la versión 2005 pero que esta vez no está limitada al motor relacional sino a nuestro servidor OLAP.

Si no han tenido la oportunidad de usar los DMV de SQL Server 2005, su uso es bastante sencillo. Los DMV están representados por una serie de vistas (views) predefinidas a nivel de la instancia a las cuales les podemos aplicar un SELECT * FROM <vista>. Dichas vistas están conectadas directamente al motor (de SQL o SSAS) para brindarnos información dinámica acerca de las conexiones existentes, las sesiones abiertas, las consultas ejecutadas y su estado, los objetos utilizados y muchas otras estadísticas interesantes que aplican al instante en el cual se ejecuta la consulta (por esto lo de “dinámica”).

De acuerdo a la documentación de Analysis Services 2008, los DMV nos ayudan a:

  • Monitorear los recursos de manera optimizada
  • Ejecutar un mejor análisis de los recursos
  • Utilizar la información expuesta por un recurso del servidor
  • Identificar quién ejecuta qué consulta y por cuánto tiempo
  • Optimizar la carga y uso de los recursos

Importante: Para ejecutar las consultas sobre los DMV pueden hacerlo al menos de 2 formas:

1. Abriendo un nuevo query de tipo MDX dentro del Management Studio.
2. Creando un Linked Server en SQL Server que apunte a su instancia de Analysis Services. A partir de este punto pueden ejecutar las consultas usando un OPENQUERY dentro de Transact-SQL.

La opción # 1 es la más sencilla para hacer consultas Ad-Hoc.
La opción # 2 es la apropiada si queremos llamar los DMV desde nuestros propios reportes o aplicaciones.

Los DMV que ayudan al monitoreo del servidor existen dentro del schema “$SYSTEM_” y tienen como prefijo la palabra “DISCOVER_” en el nombre de la vista. Alguno de los principales DMV para monitoreo son:

  • DISCOVER_CONNECTIONS
  • DISCOVER_SESSIONS
  • DISCOVER_COMMANDS
  • DISCOVER_COMMAND_OBJECTS
  • DISCOVER_OBJECT_ACTIVITY
  • DISCOVER_OBJECT_MEMORY_USAGE
  • DISCOVER_PERFORMANCE_COUNTERS

En total existen 27 tablas DISCOVER_ en esta versión de SSAS. Si quieren obtener un listado de todas las tablas pueden usar el query que se muestra a continuación (lo pueden correr como un MDX query en el Management Studio).

SELECT TABLE_NAME
FROM $system.dbschema_tables
WHERE TABLE_SCHEMA = '$SYSTEM'
AND LEFT(TABLE_NAME,8) = 'DISCOVER'
ORDER BY table_name





Pueden referirse a la documentación de SQL para obtener la descripción de cada DMV y la información que contienen: http://msdn.microsoft.com/en-us/library/bb934105.aspx.



Existen algunos DMV que tienen algunas restricciones para ser ejecutados. Por ejemplo DISCOVER_PERFORMANCE_COUNTERS requiere que se indique cuál es el contador que se quiere consultar. Aquí el ejemplo:




SELECT *
FROM SYSTEMRESTRICTSCHEMA($SYSTEM.DISCOVER_PERFORMANCE_COUNTERS,
PERF_COUNTER_NAME = '\MSOLAP$SQL2K8:Cache\Current KB')





La palabra reservada SYSTEMRESTRICTSCHEMA requiere 2 parámetros: el nombre del DMV y el filtro que queremos aplicar. En este caso le estamos pasando como filtro el nombre del Performance Counter que queremos obtener.



Si alguna vez tienen un usuario creativo que realizó un query al cubo para traer el catálogo completo de productos con más de 1 millón de productos y ya lleva más de 20 minutos esperando respuesta, probablemente ustedes quieran cancelar ese proceso y poder dejar que otros usuarios de mayor jerarquía como su gerente general pueda ver el resumen de las ventas. Una forma sencilla aquí sería ejecutar un query para verificar las sesiones en ejecución buscando las sesiones activas y el nombre del usuario que realizó el query. Algo como:




SELECT * FROM $SYSTEM.DISCOVER_SESSIONS
WHERE SESSION_USER_NAME = 'UsuarioDePocaImportancia'
AND SESSION_STATUS = 1





Una vez que identifiquen el query que causa el problema en el conjunto de resultados, basta con obtener el SESSION_SPID y ejecutar un comando de XMLA para “matar” el proceso:




<Cancel xmlns="http://schemas.microsoft.com/analysisservices/2003/engine">
<SPID>42016</SPID>
</Cancel>





Como les comenté anteriormente, si necesitan incluir los resultados de los DMV en un reporte o una aplicación, lo que primero deben hacer es crear un Linked Server en su instancia de SQL Server. Esto debido a que por ejemplo en el caso del "Query Editor de Visual Studio, éste no puede interpretar los resultados del DMV si sometemos el query como MDX. El LinkedServer nos permitirá realizar las consultas desde SQL usando Transact SQL.



En mi caso he creado un LinkedServer llamado SSAS2008 que apunta a mi instancia de Analysis Services 2008 llamada SQL2K8. El LinkedServer requiere además que se le especifique una base de datos destino, en este caso estoy usando Adventure Works aunque para el caso de los DMV, esto es irrelevante:



image



Ahora ya pueden someter consultas usando OPENQUERY:




-- Ejemplo 1
SELECT * FROM OPENQUERY(SSAS2008,'SELECT * FROM $SYSTEM.DISCOVER_CONNECTIONS')
GO
-- Ejemplo 2
SELECT * FROM OPENQUERY(SSAS2008,'SELECT * FROM $SYSTEM.Discover_Object_Memory_Usage')
ORDER BY OBJECT_MEMORY_SHRINKABLE DESC
GO





Finalmente, he construido un par de ejemplos en Reporting Services 2008 que usan los DMV Connections y Sessions. Esto puede ser un buen inicio para quienes quieran crear su versión personalizada para el monitoreo de SSAS por mucho, mucho menos dinero. Los reportes usan un Shared Data Source, recuerden cambiar la información de su servidor aquí. También deben de cambiar el nombre de su LinkedServer dentro de cada DataSet de los reportes. El screenshot a continuación muestra el reporte con información de las sesiones existentes incluyendo filtros por UserName, ConnectionID y Status de la sesión:



image



Pueden descargar el proyecto de Reporting Services 2008 desde el siguiente link:






Alan.