Esecuele Sin Fronteras

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

    Nuevo Screencast en Edge - PSSDiag & SQL Nexus

    • 0 Comments

    Hola a todos.

     

    Hemos publicado otro screencast de 15 minutos en hthttp://technet.microsoft.com/es-es/edge/Ff945289.

    En este screencast explicamos como utilizar las herramientas PSSDiag y SQL Nexus que nos permiten:

    - PSDDIAG: recoger información de rendimiento (trazas de Profiler, trazas de bloqueos, contadores de rendimiento, ...)

    - SQL Nexus: generar informes basados en las trazas capturadas con el PSSDiag.

     

    Espero que esta informacíón os resulte útil.

     

    Marcos Celada

    Ingeniero de soporte de SQL Server

  • Esecuele Sin Fronteras

    10 buenas razones para usar Reporting Services 2008

    • 0 Comments
    Si aun no conoceis Reporting Services, os sugeriria que echaseis un vistazo a la presentación adjunta...
  • Esecuele Sin Fronteras

    Ejecutando un Plan de Manteniminto con la Utilidad dtexec.exe no Produce Ningún Resultado

    • 0 Comments

    Los planes de mantenimiento en SQL Server proporcionan a los administradores de bases de datos un método rápido para configurar tareas de mantenimiento rutinarias. A partir de SQL Server 2005 los planes de mantenimineto son creados como paquetes de Integration Services (SSIS) y pueden ser ejecutados del mismo modo que cualquier otro paquete de SSIS:

    • Usando Business Intelligence Development Studio (BIDS)
    • Usando la utilidad "Import Export Wizard"
    • A través de tareas de SQL Server Agent
    • A través de la utilidad gráfica DTExecUI
    • Usando la utilidad en línea de comandos dtExec.exe

    En el caso que quiero discutir me encontraba tratando de ejecutar un plan de mantenimiento con la utilidad dtExec.exe. Mi objetivo era realizar un backup de las bases de datos usando un plan de mantenimiento y podía comprobar que la ejecución del plan desde la línea de comandos no arrojaba ningún error, pero tampoco generaba ningún resultado. Esta es la sintaxis que estaba utilizando y los resultados obtenidos:

    C:\>dtexec /SQL "Maintenance Plans\Backup MP" /Server SQL2005\YUKON
    Microsoft (R) SQL Server Execute Package Utility
    Version 9.00.3042.00 for 32-bit
    Copyright (C) Microsoft Corp 1984-2005. All rights reserved.

    Started: 15:21:20
    DTExec: The package execution returned DTSER_SUCCESS (0).
    Started: 15:21:20
    Finished: 15:21:51
    Elapsed: 31.046 seconds

    Mi primer pensamiento fue, "¿necesito tener los servicios de SSIS en ejecución para poder ejecutar este paquete desde la línea de comandos?". El artículo de la Knowlege Base KB942176 explica cláramente que no es necesario tener estos servicios en ejecución:

    "If you only want to design and to execute SSIS packages, you do not have to start the SSIS service. When the SSIS service is stopped, you can run SSIS packages by using the following utilities:

      - The SQL Server Import and Export Wizard
      - The SSIS designer
      - The Execute Package utility (DTExecUI.exe)
      - The DTExec.exe command prompt utility"

    Cuando creamos un plan de mantenimiento usando SQL Server Management Studio podemos ver que se generan una o más tareas bajo el Agente de SQL Server que se corresponden con el plan de mantenimiento:

    image

     

    Existe una forma sencilla de comprobar qué parámetros en línea de comandos son utilizados por dtexec.exe a través de las propiedades del job del Agent de SQL Server, más concretamente en la opción "Command line" de la propiedades del subplan:

    image

     

    En mi caso pude comprobar que ejecutando dtexec.exe con los parámetros aquí descritos el plan de mantenimiento se ejecutaba correctamente y el archivo de backup era generado:

    DTEXEC.EXE /SQL "Maintenance Plans\Backup MP" /Server SQL2005\YUKON /SET "\Package\Subplan_1.Disable";false

    La parte más importante en este caso es la referida al modificador /SET. Tal y como se puede ver en la utilidad gráfica el plan de mantenimiento tiene uno o más subplanes asociados y este/estos se encuentran deshabilitados por defecto de modo que es necesario habilitarlos a través de valor "false" en la opción "Disable" del subplan. Recuerda que cada subplan definido en el plan de mantenimiento crea un job distinto en el Agent de SQL Server.

    Podemos llevar a cabo esta misma acción dentro del propio paquete de SSIS asociado al plan de mantenimiento utilizando SQL Server Business Intelligence Development Studio (BIDS):

    - Abrimos BIDS
    - Creamos un nuevo proyecto de SSIS vacío
    - Añadimos el plan de mantenimiento existente al proyecto utilizando "Solution Explorer"; el plan de mantenimiento será añadido como un nuevo paquete de SSIS
    - Modificamos la propiedad "Disable" del subplan, configurándola como "false"
    - Guardamos el paquete de SSIS como un plan de mantenimiento de SQL Server
    - Ejecutamos el plan de mantenimiento. En este caso no es necesario utlizar el modificador /SET "\Package\Subplan_1.Disable";false

  • Esecuele Sin Fronteras

    Error “Maximum request length exceeded" in Reporting Services

    • 0 Comments

    Si os encontráis alguna vez con el siguiente error en Reporting Services al generar una nueva suscripción o al subir un informe a Reporting Services

     

     “Maximum request length exceeded"

     

    Hay una simple razón para ello:

     

    El valor por defecto de la propiedad MaxRequestLength es de 4 Mb. Al crear vuestra subscripción o subir un nuevo informe, si el resultado es mayor que este valor, os dará el error arriba mencionado.

     

    Para incrementar este valor podréis modificar la propiedad maxRequestLength bajo el elemento httpruntime del fichero Web.config del Report Manager (%\Program Files\Microsoft SQL Server\MSSQL.X\Reporting Services\ReportManager) y del Report Server (%\Program Files\Microsoft SQL Server\MSSQL.X\Reporting Services\ReportServer).

    Luego, reiniciar el servicio de Reporting Services e intentar crear la descripción de nuevo para ver si el error desaparece.

     

    Por defecto, la propiedad MaxRequestLength no existe en el fichero de configuración de Reporting Services. Pero el valor por defecto internamente es de 4 Mb. Para modificar el valor tendríais que añadirlo a la sección httpRuntime. Por ejemplo:

     

    <httpRuntime ... maxRequestLength="10240" .../>

     

    Para definir el valor adecuado para la propiedad, podéis exportar el informe y ver su tamaño como indica el siguiente enlace.

     

    Report Size and Limits

    http://msdn.microsoft.com/en-us/library/aa237805(SQL.80).aspx

     

     

    Maria Esteban

    Reporting Services Support Engineer

  • Esecuele Sin Fronteras

    Error "Unable to load client print control" en Reporting Services 2005 (MS09-062)

    • 0 Comments

     

    Puede que os encontréis este error después de instalar las actualizaciones de seguridad de Octubre (como MS09-062: http://support.microsoft.com/kb/971023)

    Para solucionarlo,  tendréis que instalar lo siguiente:

    -          CU6 de SQ Server 2005 SP3 (http://support.microsoft.com/kb/974648).

     

    -          Si utilizáis CRM, SharePoint o alguna otra aplicación que utilize el visor de informes para mostrarlos, e intentéis imprimirlos, tendréis que instalar el Report Viewer Redistributable 2005 SP1 (http://www.microsoft.com/downloads/details.aspx?familyid=E7D661BA-DC95-4EB3-8916-3E31340DDC2C&displaylang=en). And update to the latest Report Viewer update:

          Report Viewer Redistributable 2005 Service Pack 1 GDIPLUS.DLL Security Update
    http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=0dfaf300-2b53-4678-a779-0d805ddfe538

     

    Maria Esteban

    Reporting Services Support Engineer

  • Esecuele Sin Fronteras

    No desinstalar SQL Browser 2008 en una máquina donde tenemos una instancia de SQL Server 2005

    • 0 Comments

    Planteémonos el contexto siguiente:

    Tenemos una máquina con al menos una instancia de SQL Server 2005, e instalamos una instancia de SQL Server 2008.
    Ambas versiones utilizan SQL Browser. Al instalar una instancia de SQL Server 2008, vemos en Agregar/Quitar Programas del panel de control que SQL Server Browser se "convirtió" en versión 2008 (aparece como "SQL Server Browser 2008").

    Si queremos desinstalar todos los componentes de SQL Server 2008 (y guardar la instancia de SQL Server 2005 ya existente), es necesario no desinstalar "SQL Server Browser 2008".

    Al quitar la instancia de SQL Server 2008 y todos sus componentes (menos el SQL Browser 2008), se detecta que sigue existiendo una instancia de SQL Server 2005, por lo tanto la funcionalidad de SQL Server Browser se adapta a SQL Server 2005 (ya que sabe que no quedan más instancias de SQL Server 2008 y sí alguna de SQL Server 2005).
    De esta manera el Browser de SQL 2008 funciona perfectamente con la instancia de SQL Server 2005.

    Qué pasa si desinstalamos el Browser de los programas instalados?

    Si queremos desinstalar "SQL Server Browser 2008", se nos advierte con el mensaje siguiente:
    "Microsoft SQL Server 2008 Browser
    Warning 26002. The following products depend on Microsoft SQL Server 2008 Browser:
    Microsoft SQL Server 2005 (64-bit)
    If you uninstall Microsoft SQL Server 2008 Browser, dependent products might not function as expected. To avoid unexpected behavior, you should uninstall dependent products first. Do you want to uninstall Microsoft SQL Server 2008 Browser anyway?"

    Si lo quitamos, SQL Browser sigue apareciendo como servicio en la consola de servicios (services.msc). Sin embargo cuando intentamos arrancarlo aparece el error siguiente:
    "The SQL Server Browser service on Local Computer started and then stopped. Some services stop automatically if they have no work to do, for example, the Performance Logs and Alerts service."

    Iniciar el SQLBrowser en linea de comando tampoco funciona.

    Como consecuencia de esta desinstalación, si la instancia de SQL Server 2005 es una instancia nombrada, la conectividad a esta instancia se puede ver afectada.

    Qué puedo hacer si he desinstalado el SQL Browser 2008 y sigo teniendo una instancia de SQL Server 2005?
    Una reinstalación (o actualización) de la instancia de SQL Server 2005 no soluciona el problema.
    Para solucionar esta situación, es necesario volver a instalar una instancia de SQL Server 2008 en la máquina (esta instalación volverá a instalar el Browser de SQL Server 2008). De este modo, el SQL Browser ya funciona de nuevo para la instancia de SQL Server 2008 nuevamente instalada, así como la instancia de SQL Server 2005 ya instalada.
    Luego podemos desinstalar la nueva instancia de SQL Server 2008 (únicamente la instancia, no la parte de SQL Server Browser 2008). De ese modo, “SQL Browser 2008” sigue existiendo en los programas instalados, y éste trabaja en modo de compatibilidad de SQL Server 2005 (con la instancia existente de SQL 2005).

     

    Más información:

    - de SQL Browser: http://msdn.microsoft.com/en-us/library/ms181087.aspx

    - de la desinstalación de SQL Server 2008 en los Books OnLine: http://msdn.microsoft.com/en-us/library/ms143412.aspx

    Un saludo,

     

    Marcos Celada

    Ingeniero de soporte de SQL Server

  • Esecuele Sin Fronteras

    El Setup de SQL Server 2005 Service Pack 3 no actualiza la instancia de Analysis Services

    • 1 Comments

    Os comentaré en este post un problema con el que me he encontrado al querer actualizar los componentes de SQL Server 2005 en un cluster de 2 nodos. Tengo una instancia de SQL Server 2005 y una instancia de Analysis Services. Ejecuto el Service Pack 3, la instancia de SQL Server 2005 se me actualiza correctamente al SP3, sin embargo la instancia de Analysis Services no se actualiza y da un fallo indicando que estamos ejecutando la instalación en el nodo pasivo (cuando sin embargo sí estamos en el nodo activo!). El error es el siguiente:

    "This installation must be run from the active node. You are running it from a passive node. To proceed, cancel the installation and run it again from the active node."

    En el fichero hotfix.log de instalación del Service Pack (por defecto en la carpeta C:\Program Files\Microsoft SQL Server\100\Setup Bootstrap), se puede ver la información siguiente:

    11/17/2009 17:18:12.173   Instance Details: MSSQLSERVER
    11/17/2009 17:18:12.173     agentservicename = SQLSERVERAGENT
    11/17/2009 17:18:12.173     associatedhotfixbuild = 4261
    11/17/2009 17:18:12.173     clustername = CLUSNAME
    :   :   :   :   :
    11/17/2009 17:18:12.188   Instance Details: MSSQLSERVER
    11/17/2009 17:18:12.188     associatedhotfixbuild = 1520
    11/17/2009 17:18:12.188     clustername = CLUSNAMEX

    La primera parte del hotfix.log que muestro aquí corresponde a SQL Server Agent, y la segunda a OLAP.
    Vemos que el clustername es distinto. En ambos casos debería ser el mismo.
    No he identificado el porqué de esta diferencia (sospecho que se instaló anteriormente una aplicación con este nombre CLUSNAMEX como referencia).
    En cualquier caso, para salir de esta situación he seguido los pasos siguientes:


    - En el nodo actual (donde se ejecuta el Setup, y que es activo para Analysis Services), abrir el registro
    - Ir a HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SQL Server\MSSQL.2\Cluster
    (En mi caso MSSQL.2 es el identificadorr para la instancia existente de Analysis Services)
    - comprobar que esta clave apunta a CLUSNAMEX
    - Parar la replicación de la clave de regitro entre los nodos:
    cluster res "Analysis Services" /removecheck: "Software\Microsoft\Microsoft SQL Server\MSSQL.2\Cluster"
    - Cambiar el valor a CLUSNAME en ambos nodos
    - Habilitar de nuevo el checkpointing:
    cluster res "Analysis Services" /addcheck: "Software\Microsoft\Microsoft SQL Server\MSSQL.2\Cluster"

    Después de esto la instancia de Analysis Services se actualizó correctamente al Service Pack 3.

    Para más información acerca de la instalación de Analysis Services en cluster, podéis consultar el artículo siguiente: http://support.microsoft.com/kb/910230.

     

    Espero que esta información os resulte útil.

     

    Marcos Celada

    Ingeniero de soporte de SQL Server

  • Esecuele Sin Fronteras

    Recomendaciones para evitar problemas de conectividad con SQL y TCP Chimney

    • 3 Comments

    Hoy vamos a comentar una situación que hemos observado frecuentemente: Distintos problemas de conectividad al tener activada la opción TCP Chimney.

    TCP Chimney es una característica que incluida en Windows 2003 SP2, en el  Scalable Networking Pack (SNP)  de Windows 2003, y, por defecto, en Windows 2008. Lo que permite es que parte del procesamiento se realice en el adaptador de red, por lo que reduce el consumo de CPU del procesador. Para que este traspaso de carga sea posible, el adaptador de red tiene que ser compatible con esta opción.

    Sin embargo, hemos observado que activar esta característica con SQL Server en Windows 2003, puede provocar distintos errores relacionados con conectividad. El mensaje puede ser variado y normalmente muy genérico, del tipo: “General Network Error” o “Transport-level error”. Si nuestro SQL está conectándose a otros sistemas (por ejemplo, un servidor vinculado Oracle) el mensaje de error puede estar encapsulado en un mensaje del proveedor utilizado.

    Por lo tanto, si estáis teniendo errores aleatorios de conectividad, y tenéis activado la opción TCP Chimney, os recomendamos deshabilitarlo en las dos máquinas involucradas (origen y destino de la conexión).

    En los siguientes links tenemos la información de cómo deshabilitarlo:

    - http://support.microsoft.com/kb/948496

    - http://support.microsoft.com/kb/942861

    Un saludo,

    Raquel Vicente de la Rosa

    Ingeniero de Soporte de SQL Server

  • Esecuele Sin Fronteras

    Nuevo Blog de BizTalk

    • 0 Comments

    Hola a todos.

    Comentaros que he creado un nuevo blog de BizTalk en castellano donde podréis encontrar post más específicos de este producto.

    Un saludo

    Enrique Palomino | BizTalk Escalation Engineer

     

  • Esecuele Sin Fronteras

    El email de mi subscripción no llega al destinatario

    • 0 Comments

     

    La manera en la que las subscripciones son procesadas por parte de Reporting Services es mandando el informe a un directorio de recogida (pickup directory) donde será recogido por el servidor SMTP y lo mandará al destinatario final.

     

    Cuando el email (subscripción) no llega a su destino, empezaremos a investigar si el problema está en Reporting Services o en el servidor de correo.

     

    Una forma rápida de averiguarlo es hacienda la siguiente prueba: configurar el SMTP utilizando IIS y cambiar el fichero de configuración de la siguiente manera:

     

    <SMTPServerPickupDirectory>c:\eml</SMTPServerPickupDirectory>
    <SendUsing>1</SendUsing>


    Esto creará un fichero eml en el directorio C:\eml (hay que crearlo a mano primero o especificar uno que ya exista).  Y asegurarse de que la cuenta de servicio de REporting Services tenga permisos sobre el directorio.  

    Si al ejecutar la subscripción, el fichero eml aparece en el directorio, esto significa que el problema está en el servidor de correo.

    Más información:
    Cómo configurar un servidor de informes para la entrega por correo electrónico (Configuración de Reporting Services) http://technet.microsoft.com/es-es/library/ms345234.aspx

    Bajo “Para configurar un servicio SMTP local para el servidor de informes

     

    Maria Esteban

    Reporting Services Support Engineer

Page 5 of 9 (81 items) «34567»