Esecuele Sin Fronteras

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

    Habilito el FullText en Sharepoint, pero mis búsquedas no me devuelven los resultados esperados.

    • 0 Comments

    En algunas ocasiones, la generación de índices de los catálogos de FullText (population) no llega a completarse. Por tanto, al hacer búsquedas en los catálogos de FullText, la consulta no devuelve todos los registros que debería.

    A nivel de SQL Server, cuando miramos las propiedades de los catálogos, algunos o todos no están en estado "population in progress", y tanto los "Item count" como los tamaños de los catálogos no varían durante un tiempo "razonable". El tiempo razonable depende de cuánto tiempo suelen tardan los catálogos para rellenarse. Se puede considerar por ejemplo que si ninguno de los "ítem counts" o de los tamaños de los catálogos con estado "population in progress" no ha variado en 1 hora, el proceso de relleno se ha ‘colgado’.

    En estos casos, los logs de aplicación de la máquina donde está SQL Server devuelve mensajes. Debemos mirar los Gather Logs de FullText para ver por qué razón estamos en este estado. Para poder leer los Gather Logs, es necesario utilizar el script gthrlog.vbs. Puedes leer el detalle en el siguiente artículo: How to Use the Gthrlog.vbs Utility to View Gatherer Logs.

    Una de la razones por las cuales podemos estar en esta situación es porque el proceso que se encarga de rellenar los índices de los catálogos no tiene memoria suficiente para acabar. Analizando los Gather logs, se puede ver un mensaje como el siguiente:

    En SQL Server 2000: Error fetching URL, (800700e9 - No process is on the other end of the pipe. )

    En SQL Server 2005: Error fetching URL, (80040d19 - The filtering process was stopped because its memory quota was exceeded. To increase the memory quota of the filtering process, increase the value for the following registry key: HKEY_LOCAL_MACHINE\Software\Microsoft\Search\1.0\Gathering Manager\FilterProcessMemoryQuota. )

    El proceso MSSDmn (Microsoft Search Service Daemon) es utilizado para hacer filtrado de texto e imagen. La entrada de registro FilterProcessMemoryQuota determina cuanta memoria es asignada a este proceso. Si el valor especificado no es lo suficientemente grande para hacer el filtrado, no finaliza el llenado de índices de los catálogos de FullText.

    Para solventar esta situación, es necesario cambiar el valor de la entrada del registro FilterProcessMemoryQuota. Sin embargo, no hay manera de saber cuál es el valor que debemos especificar. Hay que ir aumentando ese valor, probar de nuevo, hasta que los catálogos se rellenen correctamente. Si vuelve a fallar, es conveniente volver a mirar los GatherLogs para ver si la razón es la misma.

    Puedes encontrar más detalles en nuestro artículo siguiente:

    PRB: A Full-Text Search May Not Return Any Hits If It Fails to Index a File

     

    Espero que esta información te sea útil.

     

    Marcos Celada

    Ingeniero de Soporte de SQL Server

  • Esecuele Sin Fronteras

    Instalación del Service Pack 3 (de SQL server) para Reporting Services 2005 cuando SQL Server está en una máquina remota y Reporting Services está en NLB

    • 0 Comments

     

    ·         Si se actualiza la máquina de Reporting Services a SP3, ¿Hace falta actualizar la máquina de SQL server remota al SP3 también?

    ·         Consideraciones para la instalación del Service Pack 3.

    ·         Pasos a seguir para la instalación del Service Pack 3 en modo Web Farm.

    ·         Plan de contingencia en caso de fallo en la instalación

     

     

     

    1.       Si se actualiza la máquina de Reporting Services a SP3, ¿Hace falta actualizar la máquina de SQL server remota al SP3 también?

     

    No hace falta actualizar la máquina de SQL server remota al Service Pack 3. Sin embargo, sí que habrá que actualizar el esquema de las bases de datos (véase siguiente sección)

     

    2.       Consideraciones para la instalación del Service Pack 3.

    Actualización del esquema de base de datos

     

    Por defecto, el programa de instalación utiliza un token de seguridad del usuario que ejecuta la instalación para conectarse a la instancia de SQL server de la máquina remota y actualizar el esquema de las bases de datos de Reporting Services (reportserver y reportservertempdb). Si el usuario tiene permisos de administrador en las dos máquinas (local y remota) la actualización de la base de datos se hará sin problemas.

     

    Si la instalación se hiciese mediante comandos, habría que especificar el usuario y contraseña con los siguientes parámetros: /rsupgradedatabaseaccount y /rsupgradepassword con una cuenta que tenga permisos para modificar el esquema en la maquina remota.

     

    Si el usuario utilizado para la instalación no tuviese permisos para actualizar el esquema en la máquina remota, la conexión dará el siguiente error:

    "Setup was not able to upgrade the report server database schema. You must run the Reporting Services Configuration tool and on the Database Setup tab upgrade the report server database to the current database schema version."

    Los ficheros del Report Server se actualizarán a SP3, pero la base de datos seguirá en formato de la versión anterior. El Report Server no estará disponible mientras la versión del esquema no sea actualizada.

    Para actualizar el esquema de la base de datos manualmente, habrá que ejecutar el Para actualizar el esquema de la base de datos manualmente, habrá que ejecutar la herramienta de configuración de Reporting Services, conectarse al servidor remoto y utilizar la opción de actualización bajo la sección de configuración de la base de datos. El report Server volverá a estar disponible después de la actualización.

     

    Instalación del Cumulative Update 1 (Post SP3)

    Si la versión de Reporting Services antes de instalar SP3 es ó Cumulative Update 10 ó Cumulative Update 11, estos fixes se perderán. Como recomendación, se deberá instalar el Cumulative Update 1 (Post SP3) que Salió el 19 de Diciembre (o cualquier CU que salga posterior) y que incluye las últimas actualizaciones.

     

     

    3.       Pasos a seguir para la instalación del Service Pack 3 en modo Web Farm.

     

    Para proceder a la instalación del Service Pack en un Web Farm, habrá que realizar la instalación en todos los nodos, empezando por el nodo 1, ya que éste realizará la actualización del esquema de las bases de datos (de Reporting Services) del servidor de SQL server, ya sea automáticamente desde la instalación utilizando un usuario administrador en las dos máquinas o manualmente desde la herramienta de configuración de Reporting Services.

     

     

    4.       Plan de contingencia en caso de fallo en la instalación

    Como comentamos en el punto 1, no hay forma de desinstalar el SP3 sin hacerlo con el producto completo.

    El mejor plan de contingencia sería tener un backup válido de cada una de las máquinas previa a la instalación del SP3.

     

    Si no existe un backup, y quisiéramos montar Reporting Services de nuevo en otro entorno,  o si la máquina fallase, podriais seguir las sugerencias del siguiente artículo.

     

    Cómo mover una base de datos de Reporting Services desde un equipo que ejecuta Reporting Services a otro equipo

    http://support.microsoft.com/kb/842425/es

     

    En resumen, lo que se necesitaría, en caso de que el sistema falle, es un backup es de las 2 bases de datos de Reporting Services: ReportServer y ReportServerTempDB  (y el resto de las bases de datos a las que se tendrán acceso sus informes) y también del fichero que contiene las claves de cifrado.

     

     

    Maria Esteban

    Ingeniero de Soporte de Reporting Services

  • Esecuele Sin Fronteras

    Cómo revisar rápidamente la configuración de tu clúster SQL Server en Windows Server 2003

    • 0 Comments

    Desde nuestro trabajo en los Servicios de Soporte al Cliente de Microsoft (Customer Support Services, CSS) nos vemos frecuentemente en la necesidad de revisar la configuración de clústeres con SQL Server. Aunque la tarea de instalación y configuración de un clúster se ha visto simplificada con cada nueva versión del sistema operativo Windows, no es extraño encontrar clústeres con configuraciones no óptimas. Parte del problema reside en la cantidad de parámetros que el profesional de IT debe de tener en cuenta al configurar un nuevo clúster. Por suerte, Window Server 2008 incorpora cambios significativos en la instalación, configuración y mantenimiento de un clúster, con el objetivo de facilitar muchas de las tareas del Adminstrador de Sistemas.

    El objetivo de este post es proporcionar una guía rápida para evitar algunos de los errores más comunes durante la configuración de SQL Server en un clúster Windows Server 2003. Para realizar esta tarea emplearemos la utilidad CLUSMPS.EXE incluida en MPSReports.

    MPSReports al Rescate

    La herramienta MPSReports es posiblemetne una de las más populares entre los profesionales de Soporte en Microsoft. Esta herramienta es empleada en la mayoría de los incidentes de soporte para la captura de ficheros de configuración y logs de Windows y SQL Server. Al ejecutar MPSReports (para SQL Server deberemos descargar y ejecutar el fichero MPSRPT_SQL.exe) estamos realmente llevando a cabo la ejecución de diversos scripts y ejecutables en un segundo plando uno de los cuales, CLUSMPS.EXE, vuelca la configuración del clúster de SQL Server en un fichero de texto con el formato SERVERNAME_CLUSTER_MPS_INFORMATION.txt.

    El proceso de setup de MPSReports es bastante simple, aunque siempre es recomendable revisar el fichero ReadMe.txt que acompaña a esta utilidad para comprender qué tipo de test se llevan a cabo y los ficheros generados en cada caso. Este fichero ReadMe.txt puede encontarse aquí y existe información adicional sobre esta utilidad aquí.

    Instalación de MPSReports

    Tras ejecutar esta utilidad econtraremos el fichero de configuración del clúster en el fichero CAB generado, dentro de la carpeta MPSReporst (la ruta por defecto a esta carpeta es %WINDIR%\MPSReports\). Opcionalmente podemos ejecutar CLUSMPS.EXE directamente a través de una ventana de línea de comandos en el nodo activo del clúster; el ejecutable CLUSMPS.EXE se encuentra por defecto en el directorio %WINDIR%\MPSReports\SQLServer\BIN\x86. La siguiente imagen muestra las opciones disponibles para esta utilidad:

    21Ene09B

    Es importante indicar que ni CLUSMPS.EXE ni el resto de herramientas ejecutada con MPSReports llevan a cabo ninguna modificación en el servidor Windows o SQL Server.

    Configuración General del Clúster

    La primera sección del fichero resultante SERVERNAME_CLUSTER_MPS_INFORMATION.txt proporcona una visión general acerca de qué nodos forman parte del clúster y qué recuros existen configurados en estos nodos. Esta es una vista integrada de la información a la que podemos acceder desde el Administrador del Clúster de Windows (cluadmin.exe).

    Esta primera sección incluye Nodes Information, Group and Resource Information, que nos será útil si necesitamos estudiar en detalle los eventos del clúster (puedes encontrar más información sobre esto en este blog de MSDN) y Resource to Guid Information.

    Configuración de Red

    La sección de Configuración de Red incluye Cluster Networks Information, Cluster Networks Priority, Network Interfaces y Network Interfaces Binding Order. Es importante no pasar por alto los valores de esta sección; en muchas ocasiones una configuración de red incorrecta pude dar lugar a un funcionamiento no óptimo del clúster.

    En Cluster Networks Information encontramos las redes reconocidas por los Servicios de Clúster (Microsoft Cluster Services o MCS). En una configuración típica cada uno de los nodos del clúster dispondrá de al menos dos interfaces de red: Una de ellas es usada para la comunicación entre los distintos nodos (hablamos normalmente de red de "HeartBeat") y la otra es usada para las comunicaicones externas (hablamos normalmetne de red "Pública").

    Debemos fijarnos en la columna Network Role ya que por defecto tanto la red de Heartbeat como la Pública están configuradas para atender a todas las comunicaciones ("All Comm") pero constituye una buena práctica modificar la configuración de la red de Heartbeat para que sólo atienda a las comunicaciones internas. Para configurar esta opción abiremos las propiedade de la red de Heartbeat desde la consola del Administrador del Clúster (cluadmin.exe) y seleccionarmeos la opción Internal Cluster Communications ONly (Private Network):

    21Ene09C

    La sección Cluster Networks Priority muestra la prioridad de cada una de las redes. Es conveniente comprobar que la red Privada se encuentra listada con la máxima prioridad. Esta configuración puede ser cambiada desde las propiedades del clúster utilizando la consola del Administrador de Clúster:

    21Ene09D

    La sección Network Interfaces Binding Order muestra la asociación entre los interfaces de red y los servicios que hacen uso de estos interfaces. Por regla general, las redes más frecuentemente utilizadas deberán estar listadas primero. El orden recomendado para un clúster de Windows sería el siguiente:

        • Red Pública externa
        • Red Privada interna (red de Heartbeat)
        • Otras comunicaciones, si existe alguna

    Esta opción puede ser configurada accediendo a las opciones avanzadas de Network and Dial-up Connections en Control Panel.

    Los siguientes artículos de la Knowledge Base proporciona información completa sobre cómo configurar los componentes de red en un clúster de Windows: Recommended private “Heartbeat” configuration on a cluster server.

    Existe información adicional sobre la configuración de estos componentes en siguiente enlace de TechNet: Server Clusters: Network Configuration Best Practices for Windows 2000 and Windows Server 2003.

    Dependencias en los Recursos de Clúster

    En cada uno de los grupos de clústrer es frecuente encontrar recursos que dependen a su vez de otros para funcionar correctamente. Estas dependencias se encuentran descritas en la secciones Dependency Tree ListDependency List del fichero de configuración SERVERNAME_CLUSTER_MPS_INFORMATION.txt. Por regla genreal no es necesario tener en cuenta estas dependencias ya que son configuradas automáticamente por SQL Server durante el proceso de setup. En cualqueir caso, siempre es recomendable comprobar si alguna de las dependencias se aleja de la configuaración recomendada, tal y como aparece descrita en el artículo de la Knowledge Base KB835185.

    A continuación podemos ver las dependecias por defecto para los servicios de una instancia clusterizada de SQL Server 2000:

    SQL Server (SHILOH) { SQL Server }
        +(1)-----Depends On-> SQL Network Name(SQL2000)  { Network Name }
            +(2)-----Depends On-> SQL IP Address1(SQL2000)  { IP Address }
        +(1)-----Depends On-> Disk S:  { Physical Disk }

    SQL Server Agent (SHILOH) { SQL Server Agent }
        +(1)-----Depends On-> SQL Server (SHILOH)  { SQL Server }
            +(2)-----Depends On-> SQL Network Name(SQL2000)  { Network Name }
                +(3)-----Depends On-> SQL IP Address1(SQL2000)  { IP Address }
            +(2)-----Depends On-> Disk S:  { Physical Disk }

    SQL Server Fulltext (SHILOH) { Microsoft Search Service Instance }
        +(1)-----Depends On-> SQL Server (SHILOH)  { SQL Server }
            +(2)-----Depends On-> SQL Network Name(SQL2000)  { Network Name }
                +(3)-----Depends On-> SQL IP Address1(SQL2000)  { IP Address }
            +(2)-----Depends On-> Disk S:  { Physical Disk }

    Y aquí podemos econtrar las dependencias por defecto para los componentes en clúster de una instancia de SQL Server 2005:

    SQL Server (YUKON) { SQL Server }
        +(1)-----Depends On-> Disk Y:  { Physical Disk }
        +(1)-----Depends On-> SQL Network Name (SQL2005)  { Network Name }
            +(2)-----Depends On-> SQL IP Address 1 (SQL2005)  { IP Address }

    SQL Server Agent (YUKON) { SQL Server Agent }
        +(1)-----Depends On-> SQL Server (YUKON)  { SQL Server }
            +(2)-----Depends On-> Disk Y:  { Physical Disk }
            +(2)-----Depends On-> SQL Network Name (SQL2005)  { Network Name }
                +(3)-----Depends On-> SQL IP Address 1 (SQL2005)  { IP Address }

    SQL Server Fulltext (YUKON) { Generic Service }
        +(1)-----Depends On-> Disk Y:  { Physical Disk }

     

    Permisos de la Cuenta de Servicio del Clúster

    La sección Account Privileges incluye una lista de los diferentes permisos requeridos por la cuenta de servicio del clúster. El siguiente ejmplo muestra una situación en la que dos de los permisos necesarios para esta cuenta no han sido concedidos:

    _____________________________________________
    |/////////////////////////////////////////////|
    |//         Current Effective Rights        //|
    |/////////////////////////////////////////////|

    Act as part of the operating system.
    Back up files and directories.
    Restore files and directories.
    Adjust memory quotas for a process.
    Increase scheduling priority.
    Log on as Service.
    Debug programs.
    Manage auditing and security log.
    Access this computer from the network.

    _____________________________________________
    |/////////////////////////////////////////////|
    |//     Missing Current Effective Rights    //|
    |/////////////////////////////////////////////|

    Load and unload device drivers.
    Impersonate a client after authentication.

    Los permisos requeridos deberán ser configurados en cada uno de los nodos del clúster. Un error en la configuración de los mismos provocará que SQL Server muestre mensajes de error sobre permisos o que falle completamente durante el proceso de arranque. El artículo KB269229 de la Knowledge Base muestra los permisos necesarios por la cuenta de servicio del clúster en Windows Server 2003.

    Otra Información

    Si nuestro clúster va a requerir los Servicios de Transación Distribuida en SQL Server deberemos de planificar con antelación la instalación del recuros en clúster Microsoft Distributed Transaction Coordinator (MSDTC) El artículo de la Knowledge Base How to configure Microsoft Distributed Transaction Coordinator on a Windows Server 2003 cluster es el mejor punto de partida para esta tarea. En caso de que sea necesario modificar una instalación en clúster ya existente de MSDTC de forma que pueda ser utilizada por SQL Server, deberemos referirnos a este enlace.

    El lectura del documento de TechNet Clustered SQL Server do’s, don’ts, and basic warnings es altamente recomendable para un estudio en profundidad de las mejores prácticas en la configuración de un clúster de SQL Server.

    El siguiente enlace, también de TechNet, contiene una guía de referencia rápida para instalar y configurar una nuevo clúster de Windows Server 2003: Quick Start Guide for Server Clusters. Podremos encontrar información específica sobre SQL Server en los Libros en Línea.

    En esta nueva artículo he intentado resumier algunos de los puntos que podemos revisar en la configuración de nuestro clúster de SQL Server 2005 en Windows Server 2003. Esta información no constituye un listado completo pero a través de los enlaces facilitados podremos acceder a información más detallada. El nuevo Asistente de Validación de Clúster incorporado en Windows Server 2008 simplifica significativamente las operaciones de instalación y configuración asociadas al clúster en versiones anteriores de Windows. Si aún no has tenido la oportunidad de trabajar con un clúster de Windows Server 2008, te animo desde aquí a montar tu primer laboratorio y empezar a famililarizarte con este nuevo modelo de clúster.

    - Jorge Pérez, Microsoft Customer Support Services

Page 1 of 1 (3 items)