Esecuele Sin Fronteras

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

    Cómo Abrir Fácilmente los Puertos del Firewall de Windows para SQL Server

    • 0 Comments

    El pasado día, tras realizar una instalación de SQL Server 2008 en mi portátil con Windows 7, me encontré sin poder conectar a la instancia utilizando SQL Server Management Studio (SSMS). Recordaba que debido a los cambios introducidos en el Firewall de Windows Server 2008 y Windows Vista esto se debía con seguridad a puertos requeridos por SQL Server que no estaban abiertos en el Firewall.

    La sección Configurar Firewall de Windows para permitir el acceso a SQL Server de la documentación en línea de SQL Server incluye información sobre cómo abrir en el Firewall de Windows los puertos requeridos por los diferentes servicios de SQL Server. Sin embargo, buscando esta información descubrí una manera mucho más sencilla de abrir estos puertos en el artículo de la Knowlege Base KB968872:

    25082009B

    El artículo incluye la opción de resolución automática Microsoft "Fix it" que permite solucionar de manera sencilla el problema en cuestión a través de un sencillo programa de setup. El setup de "Fix it" en este artículo está diseñado para Windows Server 2008 pero el script que es finalmente ejecutado por este setup está incluido en el mismo artículo y puede ser ejecutado tanto en Windows Vista como en Windows 7:

    @echo =========  SQL Server Ports  ===================
    @echo Enabling SQLServer default instance port 1433
    netsh firewall set portopening TCP 1433 "SQLServer"
    @echo Enabling Dedicated Admin Connection port 1434
    netsh firewall set portopening TCP 1434 "SQL Admin Connection"
    @echo Enabling conventional SQL Server Service Broker port 4022 
    netsh firewall set portopening TCP 4022 "SQL Service Broker"
    @echo Enabling Transact-SQL Debugger/RPC port 135
    netsh firewall set portopening TCP 135 "SQL Debugger/RPC"
    @echo =========  Analysis Services Ports  ==============
    @echo Enabling SSAS Default Instance port 2383
    netsh firewall set portopening TCP 2383 "Analysis Services"
    @echo Enabling SQL Server Browser Service port 2382
    netsh firewall set portopening TCP 2382 "SQL Browser"
    @echo =========  Misc Applications  ==============
    @echo Enabling HTTP port 80
    netsh firewall set portopening TCP 80 "HTTP"
    @echo Enabling SSL port 443
    netsh firewall set portopening TCP 443 "SSL"
    @echo Enabling port for SQL Server Browser Service's 'Browse' Button
    netsh firewall set portopening UDP 1434 "SQL Browser"
    @echo Allowing multicast broadcast response on UDP (Browser Service Enumerations OK)
    netsh firewall set multicastbroadcastresponse ENABLE

    Al ejecutar este script en Windows 7 se mostrarán varios mensajes de "warning" ya que el comando netsh firewall se encuentra depreciado en Windows 7 (netsh advfirewall firewall es el comando recomenado) aunque el script funcionará en cualquier caso.

    ¡Gracias por este script al equipo de Microsoft "Fix it"!

    -- Jorge Pérez Campo, Microsoft Customer Support Services

  • Esecuele Sin Fronteras

    SQL Server 2008 en Cluster 2008 no se inicia

    • 0 Comments

    Buenos días,

     

    Voy a compartir con vosotros algunos de los pasos que sigo para intentar identificar donde está la causa de un problema concreto.

     

    PROBLEMA

    =========

    Tenemos un cluster de 2 nodos con Windows Server 2008, y una instancia de SQL Server 2008 en cluster.

    La instancia funciona perfectamente en el Nodo1. Hacemos un balanceo de la instancia al Nodo2. Al intentar levantar la instancia en el Nodo2, nos encontramos con que el recurso falla y se hace un failover automático al Nodo1.

    La instancia VSERVER\VINSTANCE escucha por Named Pipes, TCPIP (en ip 157.58.114.35, puerto 3650)

    Paso 1

    =====

    - Pongo los recursos offline en el Nodo1

    - Hago un failover al Nodo2

    - Pongo los recursos online (1 tras otro)

    El recurso que falla es SQL Server.

    Los errorlog de la instancia muestran también que sí se levanta la instancia, y que para de la manera siguiente:

    2009-07-22 14:45:57.21 spid7s      Recovery is complete. This is an informational message only. No user action is required.

       :   :   :   :   :   :   :

    2009-07-22 14:49:28.08 spid14s     Service Broker manager has shut down.

    2009-07-22 14:49:28.60 spid7s      SQL Server is terminating in response to a 'stop' request from Service Control Manager. This is an informational message only. No user action is required.

    2009-07-22 14:49:28.60 spid7s      SQL Trace was stopped due to server shutdown. Trace ID = '1'. This is an informational message only; no user action is required.

    Siempre puedo comprobar que la instancia se levanta durante 3m30s. El errorlog nos muestra que si SQL Server para es porque alguien le ha pedido que se pare.

    En el periodo de tiempo en que la instancia está levantada, se pueden ver los errores siguientes en el log de aplicación:

    Error            7/22/2009 2:46:07 PM                 MSSQL$NLZEI06011 19019         Failover     "[sqsrvres] checkODBCConnectError: sqlstate = 08001; native error = 274d; message = [Microsoft][SQL Server Native Client 10.0]A network-related or instance-specific error has occurred while establishing a connection to SQL Server. Server is not found or not accessible. Check if instance name is correct and if SQL Server is configured to allow remote connections. For more information see SQL Server Books Online.

    "

    Error            7/22/2009 2:46:07 PM                 MSSQL$VINSTANCE  19019         Failover     "[sqsrvres] ODBC sqldriverconnect failed

    "

    Error            7/22/2009 2:46:07 PM                 MSSQL$VINSTANCE 19019         Failover     "[sqsrvres] checkODBCConnectError: sqlstate = HYT00; native error = 0; message = [Microsoft][SQL Server Native Client 10.0]Login timeout expired

    "

    Error            7/22/2009 2:46:07 PM                MSSQL$VINSTANCE  19019         Failover     "[sqsrvres] ODBC sqldriverconnect failed

    "

    Error            7/22/2009 2:46:07 PM                 MSSQL$VINSTANCE 19019         Failover     "[sqsrvres] checkODBCConnectError: sqlstate = 08001; native error = 274d; message = [Microsoft][SQL Server Native Client 10.0]TCP Provider: No connection could be made because the target machine actively refused it.

     

    "

    Error            7/22/2009 2:46:07 PM                 MSSQL$VINSTANCE  19019         Failover     "[sqsrvres] ODBC sqldriverconnect failed

     

    Paso 2

    =====

    Al levantar la instancia en el Nodo2, en realidad, la instancia de SQL Server sí levanta, y consigo conectarme a ella utilizando la cadena de conexión TCP:157.58.114.35, 3650, pero no por el nombre VSERVER\VINSTANCE.

    Por alguna razón, el proceso de IsAlive del cluster considera que la instancia de SQL Server está caída y decide apagarla y hacer el failover. Por lo que tenemos básicamente un problema de conexión a la instancia.

     

    Paso 3

    =====

    Verifico en el errorlog de SQL Server que la instancia está escuchando por la ip 157.58.114.35 y el puerto 3650.

    En el Nodo2, ejecuto el SQL Server Configuration Manager y verifico si tenemos algún alias.

    Efectivamente, existe un alias TCP con la información siguiente:

    Nombre de alias: VSERVER\VINSTANCE

    Nombre de servidor: 157.58.114.35

    Puerto: 365

    El servicio de cluster, al querer conectarse a la instancia, utiliza este alias (creado previamente a mano, que NO existe en el Nodo1) y no lo consigue.

     

    SOLUCION

    =========

    Podemos definir el alias con el puerto correcto, o directamente eliminat el alias.

     

    Un saludo!

    Marcos Celada

    Ingeniero de Soporte de SQL Server

  • Esecuele Sin Fronteras

    Como conectar a Sybase ASE desde Reporting Services utilizando del proveedor ADO.NET:

    • 0 Comments

    Como ya sabemos, Reporting Services puede conectarse a diferentes servidores de bases de datos aparte de SQL server. En este post, comentamos como configurar Reporting Services para poder crear orígenes de datos que se puedan conectar a Sybase utilizando el proveedor de ADO.NET.

     

    Lo podemos hacer de dos maneras:

     

    ·         Utilizando una extensión de datos:

     

    Una forma, quizás la más compleja, sería creando una extensión de procesamiento de datos. Para ello habrá que modificar los ficheros de configuración de Reporting Services rsreportserver.config y rssrvpolicy.config añadiendo una extensión para Sybase y  luego darle permisos de FullTrust en segundo fichero de configuración, como explica el siguiente enlace:

    Cómo implementar una extensión de procesamiento de datos en un servidor de informes

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

     

    ·         Sin utilizar una extensión de datos:

     

    Pero la forma más fácil, es registrando el proveedor directamente en el fichero de configuración rsreportserver.config.

     

    Nota: ni que decir tiene, que el proveedor ASE deberá de ser previamente instalado en la máquina correctamente, para que el diseñador de informes pueda cargar las dlls del proveedor. Si, aun así, no pudiesen cargarse las dlls, se podrían incluso copiar las dlls al directorio del Report Designer directamente o a los directorios de instalación de Reporting Services

                   

    Además, es aconsejable hacer una copia de los ficheros rsReportDesigner.config y rsReportServer.config ya que van a ser modificados, por si hubiese algun problema.

     

    Los pasos a seguir serían:

     

    1.       Parar el servicio Windows de Reporting Services

    2.       La modificación del fichero de configuración rsReportServer.config sería algo así. Añadiríamos lo siguiente a la sección de datos (Data)

    <Extension Name="Sybase" Type=" Sybase.Data.AseClient.AseConnection,Sybase.Data.AseClient "/>

    3.       Y en el fichero rsReportDesigner.config bajo la sección del diseñador (Designer)

    <Extension Name="Sybase" Type="
    "Microsoft.ReportDesigner.Design.GenericQueryDesigner,Microsoft.ReportingservicesDesigner"/>

    4.       Reiniciar el servicio Windows de Reporting Services

    5.       Hacer un reset de IIS. Esto lo podéis conseguir ejecutando iisreset  desde la ventana de comandos.

     

     

     

    Maria Esteban
    EMEA GTSC Development Support Engineer
    Microsoft Product Support Services

  • Esecuele Sin Fronteras

    Errores en el visor de eventos y errorlog realizando una instalación de SQL 2008 + SP1 Slipstreaming

    • 0 Comments

    Una pequeña introducción: Se llama instalación slipstreaming cuando con un solo proceso de instalación instalamos un producto y el service pack correspondiente. En algunos casos Microsoft provee directamente de los binarios para esta instalación (el caso más famoso Windows XP + SP2) y en otros casos, del proceso para crearlos. Este último es el caso de SQL 2008 + SP1. El proceso viene descrito en: http://support.microsoft.com/kb/955392 - Procedure 1: Basic slipstream steps

    Si nos decidimos por este método de instalación: Una vez terminado el proceso, una práctica recomendada es revisar logs de instalación, visores de entos, logs de SQL… para confirmar que todo ha ido según lo esperado. Sin embargo, en esta instalación, al revisar el visor de eventos de aplicación y/o el errorlog, podemos llevarnos una pequeña sorpresa.

    El visor de eventos y el errorlog tendrá un alto número de entradas similares a:

    Error: 15151, Severity: 16, State: 1.

    Cannot find the object 'nombre_objeto', because it does not exist or you do not have permission.

     

    Estos errores se pueden ignorar de forma segura, ya que no indican un problema real en la instalación.

    Estas líneas con error son debidas al orden en el que se ejecutan las distintas acciones en una instalación con slipstreaming: en un punto intermedio de la instalación, parecen estas líneas de error, sin embargo, al final del proceso completo, todos los objetos son creados correctamente y con las propiedades adecuadas.

    Una instalación en la que sólo nos encontremos estos errores puede ser considerada una instalación limpia, y no hay ninguna razón por la que deba tener errores en un futuro.

    Espero que este post os ahorre algún quebradero de cabeza.

    Un saludo.

    Raquel Vicente de la Rosa

    Ingeniero de Soporte de SQL Server

Page 1 of 1 (4 items)