Error en la solicitud de inicio del servicio 'SQLBrowser' Durante la Instalación de SQL Server 2008

El pasado día me encontré con un problema bastante curioso durante la instalación de SQL Server 2008 y creo que merece la pena compartir aquí lo que descubrí. En este caso mi cliente estaba llevando a cabo una instalación de SQL Server 2008 en un ordendador con Windows XP SP3 para dar soporte a un paquete de ERP instalado localmente.

El proceso de instalación de SQL Server 2008 parecía funcionar bien inicialmente pero fallaba en un determinado punto con el siguiente mensaje de error:

Error en la solicitud de inicio del servicio ‘SQLBrowser’. Haga clic en Reintentar para reintentar la accion o haga clic en Cancelar para cancelar el proceso de instalación.

Pulsando en el botón Reintentar llevaba a cabo un nuevo intento de arrancar el servicio, pero fallaba de nuevo con el mismo error de modo que no había otra opción que no fuese cancelar el proceso de instalación.

El Visor de Eventos de Windows no mostraba ninguna pista acerca del origen del error de manera que decidí comprobar el fichero de registro de instalación de SQL Server 2008 que se encuentra en la carpeta C:\Archivos de Programa\Microsoft SQL Server\100\Setup Bootstrap\Log. Existen diferentes archivos de registro en esta carpeta y cada uno de ellos proporciona información específica para un componente de SQL Server (SSIS, AS, Motor de Base de Datos, Herramientas Cliente, etc.). El fichero Detail.txt incluye información detallada de proceso global de instalación y es normalmente el primer fichero que abro a la hora de investigar un problema de instalación; esto fue lo que encontramos en nuestro caso:

2009-05-14 17:25:13 SQLBrowser: The last attempted operation: Iniciando el servicio SQL Server Browser 'SQLBrowser' y esperando hasta '900' segundos para que se complete el proceso. .
2009-05-14 17:25:13 Slp: Prompting user if they want to retry this action due to the following failure:
2009-05-14 10:25:13 Slp: ----------------------------------------
2009-05-14 17:25:13 Slp: The following is an exception stack listing the exceptions in outermost to innermost order
2009-05-14 17:25:13 Slp: Inner exceptions are being indented
2009-05-14 17:25:13 Slp:
2009-05-14 17:25:13 Slp: Exception type: Microsoft.SqlServer.Configuration.Sco.ScoException
2009-05-14 17:25:13 Slp: Message:
2009-05-14 17:25:13 Slp: Error en la solicitud de inicio del servicio 'SQLBrowser'.
2009-05-14 17:25:13 Slp: Data:
2009-05-14 17:25:13 Slp: Feature = SQL_Browser_Redist_SqlBrowser_Cpu32

Aquí podíamos ver que efectivamente el servidio SQLBrowser había sido creado pero no podía ser arrancado por alguna razón. A continuación pasé al archivo de registro de instalación Summary.txt que proporciona un resumen de los eventos llevados a cabo durante el proceso; este fichero puede encontrarse también bajo la carpeta \LOG e incluye un lista de qué componentes han sido instalados con éxito y cuáles no. Lo interesante en este caso es que el error en este fichero no apuntaba al servicio de SQL Browser sino al componente MSXML 6.0 (el motor XML de Microsoft):

Detailed results:
  Feature:                       Servicios de Motor de base de datos
  Status:                        Error: consulte los registros para obtener detalles
  MSI status:                    Error: vea los detalles a continuación
  MSI error code:                0x5EBE5729
  MSI log file location:         C:\Archivos de programa\Microsoft SQL Server\100\Setup Bootstrap\Log\20090514_170659\Msxml6_Cpu32_1.log

Buscando dentro del fichero indicado se podía ver los siguiente (Msxml6_Cpu32_1.log):

MSI (s) (30:58) [17:22:37:661]: Note: 1: 1708
MSI (s) (30:58) [17:22:37:661]: Producto: MSXML 6.0 Parser (KB933579) -- Error en la instalación.

MSI (s) (30:58) [17:22:37:661]: Windows Installer instaló el producto. Nombre del producto: MSXML 6.0 Parser (KB933579). Versión del producto: 6.10.1200.0. Idioma del producto: 3082. Resultado de la instalación: 1603.

MSI (s) (30:58) [17:22:37:661]: Cleaning up uninstalled install packages, if any exist
MSI (s) (30:58) [17:22:37:661]: MainEngineThread is returning 1603

Estaba claro por tanto que el servicio SQL Browser no era el único componente que fallaba durante el proceso de instalación, el motor de Microsoft para XML 6.0 estaba también fallando. Observando los tiempos de los ficheros Detail.txt y Msxml6_Cpu32_1.log se podía comprobar además que este último mostraba el error antes; en otras palabras, el error de instalación de MSXML estaba teniendo lugar antes del error de instalación de SQL Browser. Volví de nuevo al fichero Detail.txt para confirmar este punto:

2009-05-14 17:22:36 Slp: ----------------------------------------------------------------------
2009-05-14 17:22:36 Slp: Running Action: Install_Msxml6_Cpu32_Action
2009-05-14 17:22:36 Slp: Target package: "D:\x86\setup\x86\msxml6.msi"
2009-05-14 17:22:37 Slp: InstallPackage: MsiInstallProduct returned the result code 1603.
2009-05-14 17:22:38 Slp: Sco: Attempting to write hklm registry key SOFTWARE\Microsoft\Microsoft SQL Server to file C:\Archivos de programa\Microsoft SQL Server\100\Setup Bootstrap\Log\20090514_170659\Registry_SOFTWARE_Microsoft_Microsoft SQL Server.reg_
2009-05-14 17:22:38 Slp: Sco: Attempting to write hklm registry key SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall to file C:\Archivos de programa\Microsoft SQL Server\100\Setup Bootstrap\Log\20090514_170659\Registry_SOFTWARE_Microsoft_Windows_CurrentVersion_Uninstall.reg_
2009-05-14 17:22:38 Slp: Sco: Attempting to write hklm registry key SOFTWARE\Microsoft\MSSQLServer to file C:\Archivos de programa\Microsoft SQL Server\100\Setup Bootstrap\Log\20090514_170659\Registry_SOFTWARE_Microsoft_MSSQLServer.reg_
2009-05-14 17:22:43 Slp:
2009-05-14 17:22:43 Slp: Watson bucket for Msi based failure has been created
2009-05-14 17:22:43 Slp: No retry-able MSI return code detected.
2009-05-14 17:22:43 Slp: Checkpoint: INSTALL_MSXML6_CPU32_ACTION
2009-05-14 17:22:43 Slp: Completed Action: Install_Msxml6_Cpu32_Action, returned False
2009-05-14 17:22:43 Slp: Error: Action "Install_Msxml6_Cpu32_Action" failed during execution.

Al revisar la información de "Agregar o Quitar Programas" en el Panel de Control de Widnows podía ver que el componente MSXML 6.0 se encontraba de hecho instalado. Este es un componente compartido instalado por SQL Server 2008 pero en mi caso el cliente no estaba seguro de si este estaba ya allí antes de la instalación de SQL Server. Decidí desinstalar este componente usando el propio "Agreagar o Quitar Progamas" y lanzar la instalación de SQL Server 2008 de nuevo. Esta vez la instalación se completó sin errores.

En este caso el error inicial de SQL Server Browser era confuso al ser el primer error que se mostraba en la interfaz gráfica. Solo mirando en los ficheros de registro de instalación de SQL Server pudimos comprobar que existía un problema anterior en la instalación de los componentes MSXML 6.0.

Otra posible forma de descubrir este error es mediante el fichero de registro del Bucket de Watson que se genera al producirse un error durante el proceso de instalación y que se encuentra en el mismo directorio de Log:

En nuestro caso el contenido de este fichero era:

Watson bucket data:
  Bucket param 1: 10.0.1600.22
  Bucket param 2: 6.10.1200.0
  Bucket param 3: msxml6.msi
  Bucket param 4: 0x2D2816FE
  Bucket param 5: 0x5EBE5729
  Bucket param 6: Install_Msxml6_Cpu32_Action
  Bucket param 7:
  Bucket param 8:
  Bucket param 9:
  Bucket param 10:

He revisado las notas referentes al SP1 para SQL Server 2008 y este problema parece estar resuelto en este Paquete de Servicio de forma que otra opción para evitar este problema sería la de instalar una versión de SQL Server 2008 con el Service Pack ya integrado (esto es lo que se conoce en Inglés como Slipstreaming). Esta funcionalidad es nueva en SQL Server 2008 y permite a los administradores de bases de datos integrar Paquetes de Servicio en los medios de intalación reduciendo los tiempos de despliegue y evitando problemas conocidos.

- Jorge Pérez, Microsoft Customer Support Services

Cómo habilitar Kerberos/Delegación en Reporting Services con informes de SQL Server

MAQUINA CLIENTE:

1-Habiltar la opción “autenticación Windows Integrada” en Internet Explorer. Herramientas, Opciones de Internet Pestaña Avanazado. Hay que reiniciar la máquina para que tenga efecto.

2-Comprobar que la navegación a Reporting Services se realiza en la zona Intranet, si no es así, añadir la URL a los trusted sites en la Zona Intranet. (Kerberos no funciona en la zona Intranet).

SERVIDOR DE INFORMES:

1-Sitio IIS configurado para Kerberos

Reporting Services site debe estar configurado para soportar autenticación Kerberos. Para ello, verificar que la entrada NTAuthenticationProviders en la metabase de IIS tiene Negotiate,NTLM.

How to configure IIS to support both the Kerberos protocol and the NTLM protocol for network authentication http://support.microsoft.com/kb/215383

Los directories virtuales Report y ReportServer deben tener Seguridad Integrada en Propiedades, Seguridad de Directorio

2- Crear SPN para el servicio http de Reporting Services

How to use SPNs when you configure Web applications that are hosted on IIS 6.0 http://support.microsoft.com/kb/929650

Cómo obtener SetSPN

Para crear SPNs se puede utilizar la herramienta setspn (Para descargar  la utilidad SetSPN, visita la siguiente web site de Microsoft (http://www.microsoft.com/downloads/details.aspx?FamilyID=5fd831fd-ab77-46a3-9cfe-ff01d29e5c46&displaylang=en)

Antes de ejecutar SETSPN, obtiene :

El DNS, FQDN, hostheader, puerto de  ReportServer.

Chequea la cuenta de la identidad del pool de aplicaciones de Report Server (esta cuenta es llamada <HTTP_Service_Account>). Si se utiliza una cuenta buitin (local sytem, network services..)  la cuenta de servicio será la cuenta de máquina machinename$

Ejecuta SETSPN

1-Lista los SPN registrados

Ejecuta SETSPN -L <HTTP_Service_Account> para listar los SPNs que está registrados para una cuenta:

setspn -L <HTTP_Service_Account>

2-Registra SPN:

Setspn –A HTTP/NETBIOS_NAME_OF_IIS_SERVER domain\username

Setspn –A HTTP/FQDN_OF_IIS_SERVER domain\username

Setspn –A HTTP/HOST_HEADER NETBIOS_NAME_OF_IIS_SERVER

3-Chequea los SPNs creados con SETSPN –L (paso 1)

3-Hacer que la cuenta sea trusted for delegation

Para hacer que la cuenta <HTTP_Service_Account>  sea trusted for delegation http://technet.microsoft.com/en-us/library/cc739474.aspx

En la consola de Directorio Activo

1.            Seleccionar Users and Computers.

2.            en el arbol que aparece, seleciona Users ( si HTTP_Service_Account es la cuenta de máquina, habrá que seleccionar Computers)

3.            En el panel de detalles, botón derecho sobre la cuenta de usuario que quieres que sea trusted for delegation, y pulsa Properties.

4.            En la Pestaña Delegation, selecciona el check box para que la cuenta sea trusted for delegation, pulsa OK.

SERVIDOR DE DATOS SQL SERVER

1-Comprobar que SQL Server permite TCPI/IP protocol

SQL Server solo utilize Kerberos si el cliente utilize el protocol TCP/IP para contectarse a SQL Server.

En SQL Server:

En Programs/Microsoft SQL Server  2005/ Configuration Tool /SQL Server 2005 Surface Area Configuration

Selecciona Surface Area Configuration for Services and Connections

Selecciona the instance->database engine->Remote Connections

Checka uno de estas dos opciones “Use TCP/IP only “ o “Using both TCPIP and name pipes”

2- Create an SPN for SQL Server

How to: Enable Kerberos Authentication on a SQL Server Failover Cluster http://msdn.microsoft.com/en-us/library/ms189585(sql.90).aspx

Cómo obtener SetSPN

Para crear SPNs se puede utilizar la herramienta setspn (Para descargar  la utilidad SetSPN, visita la siguiente web site de Microsoft (http://www.microsoft.com/downloads/details.aspx?FamilyID=5fd831fd-ab77-46a3-9cfe-ff01d29e5c46&displaylang=en)

Antes de ejecutar SETSPN :

Haz un ping a la dirección virtual del cluster para obtener al dirección ip, y haz ping -a  para asegurar que el FQDN es correctamente retornado.

Chequea la cuenta con la que se ejecuta la instancia de SQL Server (esta cuenta será llamada <SQL_Service_Account>)

Anota el Puerto TCP/IP que la instancia de  SQL Server utiliza. Para determinar esta información, abre SQL Server Configuration Manager, selecciona la instancia de SQL Server y las propiedades para el protocolo TCP/IP.

Run SETSPN

Si estás usando SQL Server failover clustering, debes registrar un SPN sin Puerto y otro con Puerto.

Ejecuta SETSPN

1-Lista los SPN registrados

Ejecuta SETSPN -L <SQL_Service_Account> para listar los SPNs que está registrados para una cuenta:

setspn -L <SQL_Service_Account>

2-Registra SPN:

Ejecuta SETSPN para registrar el SPN sin el Puerto para la cuenta con la que se ejcuta el servicio de SQL Server mediante:

setspn -A MSSQLSvc/<FQDN> <SQL_Service_Account>

Ejecuta SETSPN para registrar el SPN con el Puerto para la cuenta con la que se ejcuta el servicio de SQL Server mediante:

setspn -A MSSQLSvc/<FQDN>:<Port> <SQL_Service_Account>

3-Chequea los SPNs creados con SETSPN –L (paso 1

Camino de Vicente

Ingeniero de Soporte de Reporting Services

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

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

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

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

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

Consideraciones de mejora de rendimiento Reporting Services

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

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

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

Estreno de Screencasts en Edge

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

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

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:

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

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

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.

Un saludo,

Marcos Celada

Ingeniero de Soporte de SQL Server

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

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:

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

Un saludo

Enrique Palomino

BizTalk Escalation Engineer

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

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

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

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í.

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:

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):

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:

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 List y  Dependency 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

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

·         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.

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

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