Esecuele Sin Fronteras

SQL Server, Reporting Services y Biztalk Server
  • Esecuele Sin Fronteras

    Migración de Reporting Services 2005 a Reporting Services 2008

    • 0 Comments

    ¿Alguna vez has pensado en migrar a Reporting Services 2008….

    ….  pero no sabías con que te ibas a encontrar?

     

    Antes de tomar la decisión sobre la migración de nuestro Reporting Services a 2008, junto con sus informes, modelos, orígenes de datos... es útil considerar los diferentes escenarios que nos podemos encontrar, y echarle un vistazo a la manera en la que Reporting Services realiza la actualización de los informes.

     

    En este artículo hemos recopilado información útil que le puede ayudar a planificar mejor el proceso de migración a Reporting Services 2008:

     

    1.       Escenarios y su resultado al efectuar la migración

    2.       Proceso de actualización automática de un informe de 2005 a 2008 desde el Administrador de Informes

    3.       Actualización de informes desde el diseñador de informes.

    4.       El asesor de actualizaciones (Upgrade Advisor)

    5.       Enlaces con pasos a seguir para hacer la migración o la actualización a Reporting Services 2008

     

     

    1.       Escenarios y su resultado al efectuar la migración

     

    Escenario

                 Estado

    Aplicaciones hechas para RS 2005

            Funcionarán

    Aplicaciones hechas para RS 2000

            APIs SOAP de RS 2000 no están soportados

            Acceso a URL funcionará

    Base de datos de RS en de SQL 2005

            Funcionará

    Base de datos de RS en SQL 2000

            No está soportado

    Integración con Sharepoint

            Existe un nuevo Add-in para 2008

    WebParts v2 SharePoint

            Soportado

    Implementación en uno o varios servidores

            Sigue soportado

    Implementación en Scale-out

            Sigue soportado

    RDL, RDLC

                  Estado

    RS 2005 RDL, RS 2000 RDL

            Puede publicar directamente a 2008

            Formato RDL 2005 se preserva

    Report Designer 2000

            No se pueden publicar a 2008

    Report Designer 2005

            Se pueden publicar a 2008

    Report Designer 2008

            Se actualizan de 2000 y 2005

            Se pueden crear en 2008 solo

            Se pueden publicar en 2008 solo

    ReportViewer de VS 2005

    ReportViewer de VS 2008

            Soportado  (puede mostrar 2008)

            2008 RDLC no soportado en modo local ¨todavía¨

     

     

    2.       Proceso de actualización automática de un informe de 2005 a 2008 desde el Administrador de Informes

     

    El siguiente diagrama explica el proceso que sigue Reporting Services al intentar abrir un informe de una versión de 2005 con el Administrador de Informes de 2008:

    1.       Cuando se ejecuta el informe desde el Administrador de Informes, Reporting Services comprueba si el informe ha sido creado con una versión anterior.

    2.       Si el informe ha sido creado con la versión de 2005, Reporting Services lo intentará convertir a formato 2008, creando un formato intermedio. Si surgen errores durante la actualización, el informe se marcará internamente para ser ejecutado siempre con el motor de Reporting Services 2005, y se reiniciará la ejecución de nuevo

    3.       Si el informe está marcado para ejecución con 2005, ya no intentará actualizarlo nunca más y se ejecutará siempre con el motor de RS 2005 pero no podrá beneficiarse de la mejora en el sistema de memoria ni en el motor de informes de la versión de 2008.

     

     

    3.       Actualización de informes desde el diseñador de informes.

    Si intentamos abrir un informe creado con RS 2005 desde el diseñador de informes de 2008, Reporting Services intentará actualizar el informe a 2008. Si encontrase algún error, mostraría un mensaje al usuario explicado que se han encontrado errores y daría la posibilidad de convertir el informe (perdiendo la funcionalidad no admitida) o no. Aunque se elija la opción de actualizar el informe a 2008, se creará una copia automáticamente del informe de la versión 2005 en el mismo directorio que el informe original y se le dará el mismo nombre seguido de ¨_ Backup¨

    Si los informes hubiesen sido creados con la versión de 2005 que incluyen Dundas, éstos se convertirán sin problemas siempre y cuando las versiones de 2008 estén instaladas y los informes no incluyan funcionalidad no admitida como por ejemplo código personalizado.  La siguiente lista describe la funcionalidad no admitida que no se actualizará a 2008:

           Gráficos de Dundas:

          Anotaciones

          Elementos de leyenda personalizados

          Atributos personalizados con lo siguiente:

           CUSTOM_CODE_CS

           CUSTOM_CODE_VB

           CUSTOM_CODE_COMPILED_ASSEMBLY

     

           Medidores de Dundas 2005

          Indicadores numéricos

          Indicadores de estado

          Imágenes personalizadas

     

    4.       El asesor de actualizaciones (Upgrade Advisor)

    Antes de realizar la migración, es una buena idea ejecutar el asesor de actualizaciones (Upgrade Advisor) Herramienta que analiza los componentes instalados de las versiones anteriores de SQL Server y genera un informe con los problemas que han de solucionarse antes o después de la actualización.

    Usar el Asesor de actualizaciones para preparar las actualizaciones

    http://msdn.microsoft.com/es-es/library/ms144256.aspx

     

     

    5.       Enlaces con pasos a seguir para hacer la migración o la actualización a Reporting Services 2008

     

    Cómo actualizar a SQL Server 2008 (programa de instalación)

    http://msdn.microsoft.com/es-es/library/ms144267.aspx

    Cómo migrar una instalación de Reporting Services

    http://msdn.microsoft.com/es-es/library/ms143724.aspx

     

    Maria Esteban

    Ingeniero de Soporte de Reporting Services

  • Esecuele Sin Fronteras

    Mitos y verdades de la reducción de archivos en SQL (“shrink files/database”)

    • 2 Comments

    Últimamente he tenido varias cuestiones relacionas con la reducción de archivos, por lo que escribo este post para arrojar algo de luz en este aspecto.

    Los archivos de SQL (tanto el de datos como el log de transacciones) tienen espacio marcado como “libre”, es decir, espacio asignado al archivo, pero que en este momento no contiene información, bien porque aún no se ha escrito, bien porque los datos que contenía se han borrado. SQL, por sí mismo, no libera este espacio, sino que lo mantiene en el archivo, marcándolo como libre, para ser utilizado cuando se necesite.

    La primera pregunta que debemos hacernos antes de realizar una reducción (shrink) es: ¿realmente quiero hacerlo? Hay una razón por la que SQL no libera ese espacio: normalmente es espacio que se va a necesitar durante las operaciones diarias. Tener espacio libre en los archivos es una buena práctica, porque así evitamos operaciones de crecimiento (muy pesadas).

    Mi recomendación personal es que nunca se hagan “shrinks” como parte de la tarea de mantenimiento, y que tampoco se configure de forma automática (autoshrink). Cualquiera de estas opciones probablemente desemboque en el siguiente escenario: Durante la tarea de mantenimiento, se libera espacio. Al empezar las operaciones diarias, se necesita espacio, por lo que hay una acción de autocrecimiento. Las consecuencias: Operaciones pesadas y fragmentación de los datos, ambas penalizan gravemente el rendimiento.

    Mi recomendación, por lo tanto, es realizar shrinks sólo cuando haya habido un borrado masivo de datos o cuando haya graves problemas de espacio en disco.

    Una vez que hemos decidido que queremos reducir el espacio, una situación muy frecuente es, utilizando la consola gráfica, elegir tareas en la base de datos, elegir reducir archivos, y utilizar la opción “Liberar espacio no utilizado” (release unused space). La tarea termina muy rápidamente, y en contra de lo esperado, no se libera espacio, o mucho menos del esperado.

    Cuando se especifica esta opción, se libera el espacio no utilizado que se encuentra “al final” del archivo: sólo se libera espacio si el último “extent” (conjunto de 8 páginas) se encuentra completamente libre, en cuyo caso se libera, y se comprueba el anterior, deteniéndose cuando uno de los extents no está completamente libre. Por eso, si el espacio marcado como libre se encuentra repartido entre diferentes extents que no son el último asignado a la base de datos, no se liberará el espacio que se había estimado.

    Si este es el caso, podemos liberar espacio eligiendo la opción: Reorganizar archivos antes de liberar espacio no utilizado (Reorganize files before releasing unused space). De esta manera, se “mueve” el espacio marcado como libre al final del archivo, y por lo tanto se puede liberar, reduciéndose el espacio ocupado en disco.

    Espero que sea de utilidad.

    Un saludo.  

     

    Raquel Vicente

    Ingeniero de Soporte de SQL Server

Page 1 of 1 (2 items)