Y así se cerraba el PASS European Conference 2006. Dos días de conocimientos sobre SQL Server 2005, con sus más y sus menos, pero sin duda interesantes. Y a esperar al año que viene, si es que se deciden a celebrarla de nuevo.
posted by lleonard.- @ 7:08 PM
0 comments
La última conferencia a la que asistí fue la de Don Vilen, en la que se discutieron las tecnologías de alta disponibilidad de SQL Server 2005. La ponencia, de nivel 3, fue bastante interesante ya que fue un buen repaso a la extensa lista de tecnologías que SQL Server 2005 incorpora al respecto de este tema. Una conferencia “generalista” para cerrar los dos días de congreso. Don Vilen es Program Manager del motor de almacenamiento de SQL Server en Microsoft. Y propuso algunas ideas interesantes en cuanto a disponibilidad, además de cómo solucionarlas con SQL Server.
Antes que nada, dejar claro que la disponibilidad no es un tema sólo de producto, sino que hay muchos aspectos relacionados. Lo ilustra la siguiente “pila” (stack) de disponibilidad, en la que se muestran las distintas categorías de las que depende:
Los problemas más habituales que a partir de estas categorías podemos deducir constituyen las barreras a la alta disponibilidad:
SQL Server 2005 proporciona distintas herramientas para solucionar estas barreras. Cada herramienta tiene su objetivo, sus pros y sus contras. Las podemos agrupar en tres grupos según la respuesta que dan a la alta disponibilidad:
a) Basic: No failover and a potential data loss. Son técnicas totalmente manuales y que pueden tener pérdida de datos en caso de caída el sistema. Son lentas de recuperar pero fáciles de implementar.
Backup / restore: incorpora diferentes mejoras en SQL 2005, como por ejemplo la opción RESTORE VERIFYONLY.
Detach / copy / attach: Uno de los sistemas más simples para tener una copia de los datos. Desvincular la base de datos, copiar los ficheros y volver a vincularla.
b) Better: Manual failover and potencial data loss. Es posible recuperar la información, pero de forma manual y de nuevo con una eventual pérdida de datos.
Peer-to-peer replication: Funcionalidad nueva en SQL 2005. Replicación en la que todos los participantes son iguales. El esquema de datos es común, pero cada conjunto de datos sólo puede actualizarse en uno de los servidores miembro cada vez. Permite balanceo de cargas y alta disponibilidad. La posibilidad de pérdida de datos es baja.
Log shipping: La idea es hacer backup del log en la base de datos origen y aplicarlo en la de destino. La replicación es siempre a nivel de base de datos y la base de datos de destino es de sólo lectura.
Database mirroring – high performance mode: Ver más adelante.
c) Best: Automatic failover and zero data loss. En este grupo de métodos aseguramos que la disponibilidad es total y que no hay pérdida de datos.
Database mirroring – high availability mode: Ver más adelante.
Failover clustering: El clásico mecanismo de clustering, tiene el “down time” más bajo y una pérdida de datos prácticamente nula.
El mecanismo de Database Mirroring es una de las novedades más destacables de SQL Server 2005, aunque en la versión RTM no se soporta; se espera que sí se soporte en la a partir del Service Pack 1. Mediante Database Mirroring se puede tener una copia actualizada de la base de datos en un servidor de Standby. En caso de fallo del servidor principal, la redirección al servidor de Standby puede ser manual o automática, transparente al cliente. Lo mejor de este mecanismo es que no necesita ningún hardware especial, aunque sí necesita de un tercer servidor SQL Server que haga de testigo (witness). El servidor testigo, que puede ser un SQL Server Express, es quien dice qué servidor es el “bueno”. Hay tres modos de Database Mirroring:
High-Availability Mode: Seguro, no hay pérdida de datos, “failover” automático (con testigo).
High-Protection Mode: Seguro, no hay pérdida de datos, “failover” manual – puede haber un tiempo de no-disponibilidad.
High-Performance Mode: Hay pérdida de datos, “failover” manual.
En definitiva, como se puede ver, el tema de la alta disponibilidad en SQL Server 2005 da bastante de sí. El ponente, Don Vilen, acabó de explicar los distintos mecanismos y las posibilidades que se tienen al combinarlos entre ellos, pero como resumen creo que más o menos lo aquí expuesto ya sirve...
posted by lleonard.- @ 6:01 PM
1 comments
De nuevo tuve la ocasión de escuchar a Bob Meyers, esta vez hablando de la segunda gran novedad de los SSRS: el Report Builder (la primera novedad eran los Report Controls, ver este post). Aunque Bob no fue especialmente ameno, la conferencia –de nivel 2– sí fue bastante provechosa. Bien, ¿cuál es el objetivo del Report Builder? Para los usuarios de los informes está el Report Viewer. Para los desarrolladores está el Report Designer. Y para los “Business Users” y los usuarios expertos, está el Report Builder.
El Report Builder es una nueva herramienta de diseño dirigida a aquellos usuarios de la empresa que necesitan de la capacidad de realizar consultas e informes por sí mismos. Utiliza un “modelo de datos” previamente preparado por el personal técnico para modelar su informe. Su objetivo no es reemplazar el Report Designer (más potente) ni las tablas dinámicas de Excel (análisis), sinó cubrir el vacío entre ambos. Está completamente integrado con los Reporting Services, y puede atacar SQL Server 2000 y 2005 y Analysis Services 2005.
Físicamente, el Report Builder es una aplicación Windows, basada en el .NET Framework 2.0, que se lanza a partir del Report Manager. La interfaz de usuario sigue las guías de estilo de Office. Soporta tablas y gráficos, y una vez diseñado el informe puede almacenarse en el servidor.
Los informes generados con Report Builder son RDLs como cualquier otro, que posteriormente pueden editarse con el Report Designer. Incorporan la capacidad de hacer infinitos “drill-through” a través de la información relacionada con los datos del informe.
El diseño del modelo se realiza con el Model Designer, herramienta basada (¡como no!) en Visual Studio 2005. Permite definir un modelo con entidades, campos y roles a partir de un origen de datos. El modelo se almacena el el Report Server, y sobre el mismo se puede definir seguridad para determinar qué datos puede ver el usuario.
En definitiva, como se puede deducir, es el invento del siglo en cuanto a Reporting Services se refiere. No queda más que decir que ¡tienes que probarlo!
posted by lleonard.- @ 10:25 PM
0 comments
Otra ponencia extremadamente específica. Personalmente, creo que Greg Low (consultor de Readify, MVP, MSDN Regional Director, etc.) no es quizás de los mejores ponentes, pero hay que reconocer que los conocimientos los tiene…
Bien, algunas ideas que dio Greg... Desde hace unas cuantas versiones de SQL Server, es de todos conocido que antes de ejecutar un Stored Procedure, el motor lo compila, lo cual significa elegir un plan de ejecución. Tras la compilación, los Stored Procedure se almacenan en una cache de forma que se reutiliza el plan de ejecución siempre que se puede y se evita su recompilación.
SQL2005 incorpora algunas mejoras en este tema. Por ejemplo, la recompilación a nivel de sentencia en vez de a nivel de batch. Aún y así, hay muchos casos en que no se usa la cache entre llamadas, por ejemplo las consultas “ad-hoc” requieren que el texto sea exactamente el mismo (SQL Server es “case sensitive” y “space sensitive”). Por tanto hay que estudiar los accesos de nuestras aplicaciones con cuidado, ya que fácilmente se puede incurrir en recompilaciones...
De hecho, el mecanismo en el que se basa la cache de SQL Server es complejo. Parte del concepto de coste en “ticks”, y según se reutiliza un Stored Procedure, y en función de los costes que supone su compilación, se incrementa o decremente el coste, jugando entre 0 y 31 "ticks".
La verdad es que hay muchos aspectos que pueden intervenir en la recompilación de sentencias. La explicación de Greg, bastante exhaustiva, hizo que nos diésemos cuenta de la complejidad de la situación. No puedo decir más que si queremos optimizar nuestros accesos a base de datos en este punto, vale la pena estudiar con detalle las posibilidades…
posted by lleonard.- @ 1:42 PM
0 comments
Empezamos el viernes con esta conferencia sobre los Analysis Services (SSAS) 2005. Como en todo, tuvimos dos tipos de ponencias en el PASS European Conference: las generalistas, que te introducían en una parte del producto a nivel “macro”, y las especialistas, que ahondaban en un aspecto específico de SQL Server, o sea a nivel “micro”. Esta ponencia fue claramente de las últimas: Nos centramos durante una hora en uno de los pasos del asistente de generación de cubos de Análisis Services: el de diseño de la agregación. Parece mentira que un paso de un asistente dé para tanto, ¿no? El ponente de esta específica conferencia fue Reed Jacobson, de Hitachi Consulting, un auténtico experto en BI sobre SQL Server, y también un gran ponente.
En primer lugar Reed centró la problemática de la explotación de datos, y para ello ejemplarizó el tema a través de los conceptos de base de datos vs. Excel. Con una base de datos, disponemos de la capacidad de tratar un alto volumen de datos, pero la capacidad de cálculo es limitada. Con Excel pasa lo contrario, tenemos una gran capacidad de cálculo pero podemos tratar un volumen de datos limitado.
La solución a esta problemática son, obviamente, los Analysis Services. Una de sus principales bazas es el precálculo de resultados, que permiten bajar enormemente los tiempos de respuesta en el caso de que tratemos con grandes volúmenes de datos. Precalcular los valores que se quieren estudiar necesita que las operaciones que queramos realizar sean aditivas, cosa que no siempre es posible. Si las operaciones que se desean estudiar no son aditivas, aún cabe la posibilidad de ver si se pueden derivar de operaciones que sí lo sean…
Una vez sabemos que podemos agregar los datos, podemos afinar el sistema mediante controlar cómo los AS2005 calculan estas agregaciones. Para ello disponemos de un conjunto de atributos en el diseño de los cubos (IsAggregatable, AttributeHierarchyEnabled, AttributeHierarchyVisible) que nos ayudan en el tema. No me voy a extender en su uso, para ello están los Books on line, pero queda dicho.
En cambio sí es interesante saber que de los posibles conjuntos de permutaciones que Analysis Services utiliza para generar las agregaciones, en realidad sólo aplica aquellas cuyo tamaño estimado sea menor que el 30% de la tabla de hechos. Esta regla descarta aquellas agregaciones que llevarán más tiempo usarlas que realizar los cálculos directamente sobre la tabla de hechos, y “de fábrica” viene que esto ocurre cuando el tamaño de la agregación es superior a este número.
Otro hecho destacable de los AS2005 es que por defecto, los atributos no están incluidos en el “pool” de valores a agregar. Este es un cambio respecto la versión anterior (la 2000) en que por defecto sí estaban incluidos. Si se desea que se agreguen, por tanto, hay que decírselo explícitamente.
Bien, aunque el contenido de la conferencia aún dio para más, creo que lo importante está dicho, con lo que lo dejo aquí. Repito, ¡lo que da de si un aspecto tan específico de los Analysis Services!
posted by lleonard.- @ 9:35 PM
0 comments
Realmente parecía que hubiesen hecho un concurso de a ver quien tenía el título de la conferencia más largo. Si así hubiese sido, esta ponencia de Bob Meyers se hubiese llevado la palma. Sinceramente el título lo dice todo. Y por una vez, el contenido de la conferencia fue el esperado: cómo incrustar informes de SSRSen una aplicación (WinForms o WebForms). E incluso el nivel estaba bien puesto: un 2, o sea, la cosa iba a ser sencillita, digamos, lo justo para abrir boca sobre el tema.
Bob Meyers es un chico Microsoft. Venía de una empresa llamada Active Views, comprada por Microsoft por lo que ha acabado siendo el Report Builder, así que Bob como es natural ha ido a parar al equipo de SSRS, donde es “Development Lead”. También a Bob tuve la ocasión de entrevistarlo para la dotNetMania, entrevista que también está a la espera de ser publicada (o no).
Objetivo: integrar Reporting Services en las aplicaciones cliente (Windows o Web). Incorporar a una aplicación la capacidad de realizar informes y consultas con resultados atractivos. Nos “cargamos” con esto los “Crystal Reports” y controles del estilo, pero podemos ir aún más lejos. Posiblemente podamos también sustituir gran parte de las “grids” que tengamos en nuestra aplicación…
Solución: Los Report Controls. “Run-time free”, pueden mostrar informes remotos (cargados de un Report Server) o locales (sin necesidad de servidor). Estos últimos se integran completamente con los proyectos estándar de Visual Studio: se construyen a partir de los mismos orígenes de datos de la aplicación y soportan todo tipo de interactividad.
posted by lleonard.- @ 7:31 PM
0 comments
