Esecuele Sin Fronteras

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

    ¿Por qué he reducido el registro de datos históricos y mi base de datos de distribución ha empezado a crecer?

    • 0 Comments

     

     Hoy toca replicación. Vamos a tratar el efecto de un cambio aparentemente inocuo en el registro histórico del agente de distribución y sus posibles consecuencias.

    El perfil del agente de distribución, entre otros parámetros, tiene uno llamado: HistoryVerboseLevel. Este parámetro según los books on line: “Especifica la cantidad de historial registrado durante una operación de la distribución. Puede minimizar el efecto sobre el rendimiento del registro del historial seleccionando 1.”  (http://msdn.microsoft.com/es-es/library/ms147328.aspx)

    Tal y como indican los books on line, para mejorar el rendimiento, se recomienda un valor 1, ya que un valor 0 puede tener efectos secundarios, en particular el crecimiento de la base de datos de distribución.

    Este comportamiento puede parecer extraño, para entenderlo veamos primero cuál es el proceso de reciclaje esperado en la base de datos de distribución:

    En la base de datos de distribución se guardan las transacciones de la base de datos publicada, ¿durante cuánto tiempo? Hasta que todos los subscriptores las han recibido, con un tiempo máximo del período de retención. Pasado el período de retención, serán eliminadas independientemente de si las han recibido los subscriptores o no, precisamente para evitar el crecimiento sin límite de la base de datos de distribución. El período de retención es configurable, y por defecto son 72 horas.

    El encargado de borrar las transacciones no necesarias en la base de datos de distribución es el trabajo “Limpieza de la distribución” (Distribution clean up), y cada vez que se ejecuta:  

    -Si hay subscripciones anónimas, no tiene información acerca de qué subscripciones han recibido las transacciones, por lo tanto mantiene todas las transacciones que se encuentran dentro del período de retención.

    -Si las subscripciones no son anónimas, si todos los subscriptores han marcado una transacción como recibida, el trabajo de limpieza las eliminará aunque estén dentro del  período de retención.

    Cuanto menos transacciones tengamos en la base de datos de distribución, mejor será el rendimiento del agente.

    ¿Cuál es el efecto de configurar un valor 0 para el HistoryVerboseLevel?  De nuevo, según los books on line: Los registros del historial no se registran en la base de datos de distribución”. La implicación es que en la base de datos de distribución no hay información sobre qué transacciones ha recibido cada subscriptor.  Estaríamos en el mismo caso que trabajando con subscripciones anónimas. Por lo tanto la base de datos de distribución es mayor de lo necesario, y empeora el rendimiento.

    Otra funcionalidad que necesita el registro histórico en distribución es el monitor de réplica, y la consecuencia de utilizar el valor 0 para HistoryVerboseLevel, es que las transacciones aparecerán como no distribuidas, y la subscripción como no actualizada.

    Como resumen, no se recomienda tener un valor 0 para el parámetro HistoryVerboseLevel.

    Un saludo.

    Raquel Vicente de la Rosa

    Ingeniero de Soporte de SQL Server

  • Esecuele Sin Fronteras

    Cómo cambiar el directorio donde se guardan los logs de Reporting Services RS 2008

    • 0 Comments

    Muchos os habéis preguntado si es posible cambiar el directorio donde se guardan los logs de Reporting Services,  Por ejemplo que se guarden en una unidad de discos diferentes.

    Esto se puede lograr añadiendo la clave Directory a la sección RStrace del fichero ReportingServicesService.exe.config file.

     

    Esto es un ejemplo donde se utiliza el elemento Directory. Habrá que descomentar el elemento XML y añadir un valor para empezar a utilizarlo.

     

             <RStrace>

                    <add name="FileName" value="ReportServerService_" />

                    <!-- <add name="Directory" value="" /> -->

                    <add name="HttpLogFileName" value="ReportServerService_HTTP_" />

                    <add name="FileSizeLimitMb" value="32" />

                    <add name="KeepFilesForDays" value="14" />

                    <add name="Prefix" value="tid, time" />

                    <add name="TraceListeners" value="debugwindow, file" />

                    <add name="TraceFileMode" value="unique" />

                    <add name="Components" value="all" />

            </RStrace>

     

    Nota: Aseguraros de que el directorio elegido tenga los mismos permisos que el directorio donde se encuentras los logs inicialmente.

     

    Maria Esteban

    Ingeniero de Soporte de Reporting Services

  • Esecuele Sin Fronteras

    Webcast de instalación del Service Pack 3 de SQL Server 2005

    • 1 Comments

    Hola a todos,

     

    Mañana 22/04/09 a las 4PM (hora de España) presento un webcast de instalación del Service Pack 3 de SQL Server 2005. Si tenéis algunas dudas o preguntas, podéis registraros en el enlace siguiente:

    http://msevents.microsoft.com/CUI/WebCastEventDetails.aspx?EventID=1032408159&EventCategory=4&culture=es-ES&CountryCode=ES

    En el caso de no poder contestar a todas las preguntas en el webcast, os invito a mandárnoslas por el medio de este blog (con un comentario a este post) y contestaremos lo antes posible.

     

    Un saludo,

    Marcos Celada

    Ingeniero de soporte de SQL Server

  • Esecuele Sin Fronteras

    Consideraciones de mejora de rendimiento Reporting Services

    • 0 Comments

     

    Para entender el funcionamiento de Reporting Services en cuanto al rendimiento, es conveniente saber que hay 3 fases en la ejecución del informe: “data retrieval” (traerse de los datos puros desde Analysis Services), “procesing” (el procesado de los datos dentro del informe) y “rendering” (componer el informe para su visualización).

     

     

    Para poder saber en qué fase del proceso de ejecución del informe se está yendo el tiempo, existe una tabla en Reporting Services llamada “ExecutionLog” que muestra, entre otras cosas, el tiempo en milisegundos que tarda un informe de cada fase. La tabla “ExecutionLog” se encuentra dentro de la base de datos “Report Server” y las columnas a mirar son “TimeDataRetrieval”, “TimeProcessing”, y “TimeRendering”.

     

    ·         Si el tiempo se estuviese yendo en la fase del “Data Retrieval”, se podría intentar disminuírel número de registros que se traen (a lo mejor no hacen falta todos, mirar si se pueden filtrar) o ver si la red por la que viajan los datos es lenta o remota…

     

    ·         Si el tiempo se estuviese yendo en la fase de “Processing” del informe, es decir, el tiempo de procesamiento de los datos que nos hemos traído del servidor, mediante operaciones de agrupamiento, filtrado, operaciones de agregado, ordenamiento, código añadido por el desarrollador, se podría analizar si se podrían minimizar o realizar en Analysis Services antes de traernos los datos. Por ejemplo, una matriz tardaría más en ejecutarse que una tabla.

     

    ·         Si el tiempo se estuviese yendo en la fase de “Rendering”, o sea, con la información que se muestra finalmente al usuario, y como se muestra ésta, habría ciertos factores que influirían como el número y tipos de controles, la relación entre ellos, el formato y la cantidad de datos mostrada.

    También te comentaba adjunto un enlace que contiene los pasos a seguir sobre como mostrar la información de la tabla ExecutionLog en caso de que queráis mostrarla en un informe de una manera más presentable por si lo queréis mostrar a alguien más:

     

    Monitoring Report Execution Performance with Execution Logs

    http://msdn2.microsoft.com/en-us/library/Aa964131.aspx

     

     

    Ciclo de ejecución de informes

     

    *      5 Fases:

    *      Ejecución de la consulta que nos traerá con los datos a utilizar en el informe

    *      Retorno de datos, operaciones de agrupado y cálculo de agregados

    *      Ordenación y filtrado

    *      Funciones de agregado posterior como: Running Results, First, Last, Previous (agregados especiales basados en el orden de los datos)

    *      Creación de la instancia del informe (la creación del Snapshot)

     

    Consideraciones

    *      Un informe Snapshot contiene la instancia completa (Datos combinados con formato)

    *      Matrix/Chart son más caros que otros controles (son bidimensionales)

    *      Funciones de Agregado posterior son más caros que otras funciones de agregado

     

     

    Optimización de procesamiento

    *      Devolver la menor cantidad de datos en las consultas (no traerse datos de detalle si solo necesitamos los valores de agregado, usar DrillThrough para mostrar detalles)

    *      Restringir las consultas con la clausula WHERE

    *      Mover agregados complejos al servidor

     

    Optimización de ejecución

    *      Bajo Demanda:

    *      Necesitamos los datos actualizados en todo momento

    *      Crea formato intermedio y lo guarda en la Caché

    *      Programado de antemano:

    *      Utilizar mecanismos de Cache desde el Report Manager

    *      Crear Snapshots y verlos a trav'es de su historia en el Report Manager

     

    Maria Esteban

    Ingeniero de Soporte de Reporting Services

  • Esecuele Sin Fronteras

    Está soportado crear informes en Reporting Services 2005 cuyo origen de datos sea Análisis Services 2008?

    • 0 Comments

     

    Después de haber recibido  varias preguntas sobre el tema, os confirmamos que Análisis Services SI está soportado como origen de datos de un informe creado con Reporting Services.

     

    Una puntualización importante: Reporting Services presenta ciertas limitaciones en cuanto a trabajar con datos de estructuras dinámicas y multidimensionales como es Analysis Services:

     

    1.       Cuando se intenta generar un informe de Reporting Services, se utiliza un dataset para traerse los datos (en este caso de Analysis Services). En este punto, el dataset es una tabla estática basada en el cubo de OLAP que refleja el estado del momento en el que el informe se generó. Esto significa que, cada vez que el informe se genere, las columnas pueden cambiar.

    Para datasets horizontales dinámicos habría que editar la definición del informe para cada periodo de tiempo en incluir la última fecha en el informe.

     

    2.       La segunda limitación es que Reporting Services proporciona un filtrado que funciona para datasets bidimensionales pero no proporciona filtrado “post-retrieval” para datasets dinámicos. En este caso, hará falta una reordenación o esconder determinadas filas columnas filtradas. En definitiva, el filtrado de columnas no ha sido diseñado para trabajar con datasets multidimensionales. Solo funciona para datos bidimensionales. Esto significa que los datos se consultarán durante la fase de “data retrieval” pero no una vez que se haya mostrado el informe

     

     

    Importante:

    Aseguraos de instalar Service Pack 3 de Reporting Services 2005 para que funcione correctamente. Lo podréis descargar del siguiente enlace: http://www.microsoft.com/downloads/details.aspx?FamilyID=ae7387c3-348c-4faa-8ae5-949fdfbe59c4

     

     

    Información adicional:

     

    ·         Podéis encontrar información sobre Análisis Services como origen de datos de Reporting Services en:

    Crear conjuntos de datos de informe a partir de SQL Server Analysis Services

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

    (todos los puntos aplican a Reporting Services 2005 y Reporting Services 2008)

     

    ·         La documentación sobre orígenes de datos para 2005 en:

    Integrating Analysis Services with Reporting Services

    http://msdn.microsoft.com/en-us/library/ms159219(SQL.90).aspx

    No habla explícitamente de Análisis Services 2008 pero debería funcionar correctamente si se ha instalado Service Pack 3

     

     

    Maria Esteban

    Ingeniero de Soporte de Reporting Services

  • Esecuele Sin Fronteras

    Estreno de Screencasts en Edge

    • 0 Comments

    Buenos días,

     

    Hemos publicado un video en http://edge.technet.com/spain:

    - http://edge.technet.com/Media/Filestream-almacenamiento-de-BLOBs-con-SQL-Server-2008/  en el que explico brevemente la funcionalidad de Filestream con SQL Server 2008.

    - Mi compañero Jorge Perez también tiene publicado el screencast siguiente http://edge.technet.com/Media/Cmo-Migrar-Paquetes-DTS-a-SQL-Server-2008/ en el que explica la migración de paquetes DTS SQL Server 2000 a SSIS en SQL Server 2008.

     

    Tenemos pensado crear nuevos contenidos de este tipo y publicarlos pronto, y os invito a mirar mientras los diferentes videos de otras tecnologías publicados en el mismo sitio web de Edge.

    Esperamos que os gusten. Un saludo,

     

    Marcos Celada

    Ingeniero de soporte de SQL Server

     

  • Esecuele Sin Fronteras

    Aclaración de los Service Packs y Cumulative Updates de SQL Server 2005 (Post Service Pack 2)

    • 0 Comments

    Buenas a todos,

     

    En alguna ocasión he tenido preguntas de qué Cumulative Updates estaban incluídos en tal build de SQL Server, o cuales eran los Cumulative Updates post SP3 que incluyan los fixes de los Cumulative Updates post SP2 aunque no sean las mismas Builds de SQL Server...

    He creado la tabla siguiente por orden cronológico inverso:

    Fecha de salida Build SP2 CU SP3 CU KB Comentarios
    16/02/2009 9.00.3315 SP2CU12   962970  
    9.00.4211   SP3CU2  
    15/02/2009 9.00.3301 SP2CU11   958735  
    19/12/2008 9.00.4207   SP3CU1 => Incluye los mismos fixes de SP2CU10 +SP2CU11
    15/12/2008 9.00.4035   SP3RTM  
    20/10/2008 9.00.3294 SP2CU10   956854  
    18/08/2008 9.00.3282 SP2CU9   953752 =>  SP3RTM contiene todos los fixes hasta SP2CU9
    16/06/2008 9.00.3257 SP2CU8   951217  
    14/04/2008 9.00.3239 SP2CU7   949095  
    18/02/2008 9.00.3228 SP2CU6   946608  
    17/12/2007 9.00.3215 SP2CU5   943656  
    15/10/2007 9.00.3200 SP2CU4   941450  
    20/08/2007 9.00.3186 SP2CU3   939537  
    18/06/2007 9.00.3175 SP2CU2   936305  
    16/04/2007 9.00.3161 SP2CU1   935356  
    27/02/2007 9.00.3042 SP2RTM   921896  
     

    Espero con esta tabla y este sistema de correspondencia de colores haber podido aclarar vuestras dudas al respeto.

    Podéis obtener más información de todas las versiones de SQL Server 2005 Post SP2 en el artículo siguiente:

    The SQL Server 2005 builds that were released after SQL Server 2005 Service Pack 2 was released.

     

    Lo mismo para las versiones Post SP3:

    The SQL Server 2005 builds that were released after SQL Server 2005 Service Pack 3 was released.

    Para obtener más información sobre el servicio de correctivos incremental, podéis consultar la página siguiente:

    An Incremental Servicing Model is available from the SQL Server team to deliver hotfixes for reported problems

     

    Un saludo!

    Marcos Celada

    Ingeniero de Soporte de SQL Server

     

  • Esecuele Sin Fronteras

    Otros blogs de los compañeros del soporte de España

    • 0 Comments

    Hola a todos,

    Pongo este post simplemente para comentaros que además del blog de nuestros compañeros de LATAM, existen otros blogs de nuestros compañeros del soporte en España relacionados con distintos productos de Microsoft, en los cuales podéis encontrar información muy útil sobre distintos problemas encontrados y mejores prácticas.

    Blog/Technología

    URL

    Exchange

    http://blogs.technet.com/esexblog/

    Plataformas

    http://blogs.technet.com/plataformas/

    Seguridad

    http://blogs.technet.com/ksarens/

    MOSS

    http://blogs.technet.com/hablamoss/

    PlatDev y Criptografía

    http://blogs.msdn.com/alejacma/

    SQL Reporting Services

    http://blogs.msdn.com/mariae/

    SQL

    http://blogs.msdn.com/jorgepc/

    IIS

    http://blogs.msdn.com/alvar/

    IIS

    http://blogs.msdn.com/daniem/

    CRM

    http://blogs.msdn.com/benlec/

    NAV SCM

    http://dynamicsnavscmboost.spaces.live.com/

    Dynamics AX

    http://blogs.msdn.com/ax/

    CRM

    http://blogs.msdn.com/crmlandia /

    ISV Partner Support

    http://blogs.msdn.com/micham/

     

    Un saludo,

     

    Marcos Celada

    Ingeniero de Soporte de SQL Server

     

  • Esecuele Sin Fronteras

    Que versión de SQL Server es soportada por las distintas versiones de BizTalk.

    • 0 Comments

    Ahora que la versión de BizTalk 2009 esta apunto de salir al mercado, surgen muchas dudas sobre si nuestra versión de SQL Server va a ser compatible con esta nueva versión o si tendremos que migrar nuestro motor de base de datos. Solamente, tendremos que migrar si estamos utilizando  SQL Server 2000, ya que BizTalk 2009 estará soportado para entornos con SQL Server 2005 SP3 y SQL Server 2008

    Os adjunto una tabla de soportabilidad, que espero ayude a clarificar dudas:

      SQL Server 2000 SQL Server 2005 SQL Server 2008
    BizTalk 2004 Si con SP3a No No
    BizTalk 2006 Si con SP4 Si No
    BizTalk 2006R2 Si con SP4 Si No
    BizTalk 2009 No Si con SP3 SI

     

    Para más información sobre compatibilidad de versiones tenemos el KB926628

    Un saludo

    Enrique Palomino

    BizTalk Escalation Engineer

  • Esecuele Sin Fronteras

    Por qué me pueden aparecer errores de acceso al ERRORLOG cuando mi instancia de SQL Server funciona correctamente?

    • 0 Comments

    Tenemos un cluster de 2 nodos, con varias instancias cluster de SQL Server 2000 SP4. Una de ella se llama SERVIDOR\Instancia.

     

    En los logs de aplicación y sistema aparecen mensajes poniendo en evidencia problemas de acceso de la instancia SERVIDOR\Instancia a su errorlog, y caídas de servicio del agente SQL de esta misma instancia.

    No aparecen errores con las demás instancias.

    Lo más curioso es que la instancia SERVIDOR\Instancia funciona correctamente en cualquiera de los nodos. No hay caída de servicio ni problema para arrancarlo (lo que pasaría si realmente tuviese un problema de acceso al errorlog), la instancia se ejecuta correctamente.

     

    Los errores que aparecen son:

     

    LOG DE SISTEMA

    Event Type:            Error

    Event Source:         MSSQL$Instancia

    Event Category:      (2)

    Event ID: 17055

    Date:                       01/01/2009

    Time:                       00:00:01

    User:                       N/A

    Computer:               Nodo1

    Description:

    17050 :

    initerrlog: Could not open error log file 'X:\Program Files\Microsoft SQL Server\MSSQL$Instancia\log\ERRORLOG'. Operating system error = 21(The device is not ready.).

     

    LOG DE APLICACIÓN

    Event Type:            Error

    Event Source:         Service Control Manager

    Event Category:      None

    Event ID: 7001

    Date:                       01/01/2009

    Time:                       00:00:01

    User:                       N/A

    Computer:               Nodo1

    Description:

    The SQLAgent$INSTANCIA service depends on the MSSQL$INSTANCIA service which failed to start because of the following error:

    The operation completed successfully.

    For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.

     

    Se puede ver incluso que estos mensajes son generados con intervalos regulares (cada 4 minutos por defecto).

     

    Podemos notar también que cuando ejecutamos un job que escribe en un fichero FicheroDelJob.out ubicado en la misma unidad de disco que los ficheros de datos de la instancia SERVIDOR\Instancia (en nuestro ejemplo X:), se ve que el job se ejecuta perfectamente, y el fichero FicheroDelJob.out contiene la información de la ejecución.

    Sin embargo, el log de sistema registra el error siguiente:

     

    Event Type:            Error

    Event Source:         HPOV-MAA

    Event Category:      None

    Event ID: 1024

    Date:                       01/01/2009

    Time:                       10:21:34

    User:                       N/A

    Computer:               Nodo1

    Description:

    Cannot read contents of file X:\Program Files\Microsoft SQL Server\MSSQL$INSTANCIA\FicheroDelJob.out.

    System Error Number: 21 (15) - The device is not ready.

     (OpC20-64)

     

     

    Si ejecutamos un Process Monitor en el momento en que aparecen esos mensajes, podemos identificar el evento siguiente:

     

    00:04:01,9509055  opcmona.exe          4884        ReadFile  C:\Program Files\HP OpenView\Installed Packages\{790c06b4-844e-11d2-972b-080009ef8c2a}\tmp\OpC\monagtq       SUCCESS               Offset: 0, Length: 36

    Date & Time:           01/01/2009 00:04:01

    Event Class:            File System

    Operation:               ReadFile

    Result:     SUCCESS

    Path:       C:\Program Files\HP OpenView\Installed Packages\{790c06b4-844e-11d2-972b-080009ef8c2a}\tmp\OpC\monagtq

    TID:         8164

    Duration: 0.0000249

    Offset:     0

    Length:    36

     

     

    Al deshabilitar el servicio del HP OpenView Performance Agent (OVPA) los mensajes dejan de aparecer. Reinstalar HP OpenView puede hacer desaparecer los mensajes por completo.

     

     

    Marcos Celada

    Ingeniero de Soporte de SQL Server

Page 7 of 9 (81 items) «56789