Error 17204 y 5120 al iniciar los servicios de SQL Server.
Por: Daniel Torres Garrido
Trabajar en casos en donde el servicio de SQL Server no inicia es relativamente común. Son varias y muy diversas las causas de estos problemas sin embargo en este último año tuvimos uno en donde fue particularmente difícil encontrar la causa raíz.
Inicialmente el cliente reportó que había creado una máquina virtual utilizando VMWare, después instaló una nueva instancia con SQL Server 2012, el asistente de instalación finalizó con éxito. Después se dispuso a aplicar el Service Pack 1 para SQL Server 2012 sin embargo obtuvo un error indicando que no podía acceder a los archivos de la TEMPDB por lo que la instalación finalizó con errores. Después de iniciar el servicio de SQL todas las bases de datos se encontraban en el estado “Recovery”.
Al revisar los logs de errores se detectaron los siguientes mensajes
05/09/2013 16:35:11,spid22s,Unknown,Error: 17204<c/> Severity: 16<c/> State: 1.
05/09/2013 16:35:11,spid22s,Unknown,FCB::Open failed: Could not open file E:\MyDatabasePath\DATA\contoso.mdf for file number 1. OS error: 5(Access is denied.).
05/09/2013 16:35:11,spid22s,Unknown,Error: 5120<c/> Severity: 16<c/> State: 101.
05/09/2013 16:35:11,spid24s,Unknown,FCB::Open failed: Could not open file E:\ MyDatabasePath\DATA\adventureworks.mdf for file number 1. OS error: 5(Access is denied.).
En ambos casos teníamos un error de acceso denegado en la ruta donde se encontraban 2 data files. Inicialmente se verificaron los servicios de SQL Server y encontramos que el motor estaba en ejecución bajo una cuenta de dominio. Una vez conocida la cuenta de dominio nos aseguramos que tuviera permisos en las carpetas donde se encontraban los archivos MDF. Usando esa cuenta se podían crear archivos y leerlos sin ningún problema, para estar seguros de los accesos se agregó manualmente la cuenta de dominio a la carpeta y se otorgaron permisos FULL CONTROL incluso a las carpetas padre así como al propio disco E:\. Se reiniciaron los servicios y el problema persistió.
En un intento se modificó la cuenta de servicio con la que iniciaba SQL Server por Local System, al hacerlo el servicio inicio sin problemas, los errores 17204 y 5120 desaparecieron. Se tomaron trazas con el Process Monitor y ciertamente no había muchas pistas sobre el origen del error. Como prueba adicional se creó una base de datos directamente en el disco C:\, se reinició el servicio de SQL Server y la base levantó sin problemas, aquellas bases que tenían archivos en la unidad E:\ seguían presentando la falla.
Realizando una búsqueda se identificó el siguiente KB de VMWare:
Disabling the HotAdd/HotPlug capability in ESXi 5.x and ESXi/ESX 4.x virtual machines (1012225)
Si revisamos el KB dentro de la sección de Síntomas veremos que no hay nada relacionado con el problema de acceso a discos sin embargo hemos visto que la características hotadd/hotplug de VMware ocasionan el problema de acceso denegado a los archivos de bases de datos utilizando una cuenta de dominio. El problema se hace más crítico cuando los archivos de las bases de sistema se encuentran en un disco distinto a C:\ porque evidentemente el servicio de SQL como tal no podrá iniciar. En este caso las bases de datos de sistema estaban en C:\ y únicamente las de usuario en discos distintos.
Definitivamente es importante considerar este KB de VMWare cuando existen máquinas virtuales que ejecutan servicios de SQL Server. Como medida preventiva puede deshabilitar el HotAdd/HotPlug de VMware para evitar caer en este escenario o si ya tiene un problema similar es posible que la solución del KB le ayude a resolverlo.