La base de datos maestra está dañada, la instancia no se inicia, ¿cuáles son mis opciones?

¡Ayuda! Mi base de datos maestra está dañada, ¡ni siquiera puedo poner en línea la instancia de SQL! ¿Cuáles son mis opciones para recuperar mi servidor?

Tengo una copia de seguridad de master, pero la página de MSDN "Restaurar la base de datos master" me pide que inicie la instancia en modo de usuario único, ¡lo cual no puedo hacer!

(Nota: dejo esta pregunta sin especificar en cuanto a la versión de SQL, para que sea una referencia más ampliamente aplicable. Hay algunas preguntas similares en DBA.SE, pero ninguna que involucra al servidor que no puede iniciarse).

Aquí hay algunas avenidas que investigaría. No haga todo esto (algunas de ellas son técnicas diferentes para lograr el mismo propósito), pero vale la pena considerarlas:

1. Examine el registro de errores de SQL directamente

Navegue directamente a la carpeta que contiene los registros de errores de SQL y cargue el más reciente ERRORLOGen el bloc de notas para obtener más detalles sobre por qué no se iniciará la instancia de SQL. Quizás descubra que el problema no está relacionado con la base de datos maestra.

2. Intente iniciar la instancia en modo de usuario único

Aquí hay una lista completa de opciones de inicio para el servidor SQL , que incluye -m(modo de usuario único) y -f(modo de configuración mínima). Otras opciones le permiten especificar la ruta de la base de datos maestra, si ese es el problema.

Si puede iniciar la instancia, siga los pasos en el artículo de MSDN que vinculó para restaurar la base de datos maestra, o este tutorial detallado de Thomas LaRock .

Si otra aplicación siempre toma la conexión de usuario único antes de que pueda, primero deshabilite el Agente SQL para que no se inicie. En segundo lugar, vea las ideas sobre esta pregunta para usar el -m"Application Name"parámetro para especificar el nombre de la aplicación.

3. Restaurar mastera otra instancia y copiar sus archivos

Solo he encontrado otra mención de esta técnica indocumentada, pero la utilicé con éxito el pasado fin de semana, por lo que podría valer la pena intentarlo.

Si no puede iniciar la instancia en modo de usuario único, pero tiene otra instancia de SQL que ejecuta exactamente la misma versión y compilación , intente restaurar la última copia de seguridad de la base de datos maestra del servidor muerto a la otra instancia:

• Restaurar con un nombre diferente, por supuesto ( master_please_god_let_this_work), WITH MOVEpara que no sobrescribas masteren tu buen servidor
• Restaurar WITH NORECOVERY. No estoy seguro de que esto sea necesario, pero me hizo sentir mejor saber que el otro servidor no iba a alterar nada en el maestro restaurado
• Configúrelo como fuera de línea: ALTER DATABASE [master_please_god_let_this_work] SET OFFLINE
• Copie los archivos MDF y LDF restaurados del buen servidor al servidor muerto
• Cambie el nombre de los archivos master.mdfy mastlog.ldfsegún sea necesario para reemplazar los archivos maestros defectuosos con sus versiones restauradas
• Cruza los dedos y comienza la instancia
• Opcional: realice una nueva restauración del maestro en el servidor revivido. No estoy seguro de que esto sea necesario, ya que tuvimos mucho cuidado de no cambiar master.

4. Reconstruir las bases de datos del sistema.

Si no tiene otra instancia que ejecute la misma versión, o si no se siente cómodo con el procedimiento no documentado que figura en el n. ° 3, o si no tiene copias de seguridad de master( ¿por qué no tiene copias de seguridad? ), Puede reconstruir las bases de datos del sistema SQL desde el disco de instalación original :

Setup.exe /ACTION=REBUILDDATABASE /...

Cuando esto se complete, puede seguir los pasos vinculados anteriormente para restaurar masterdesde su última copia de seguridad válida. También deberá restaurar una copia de seguridad reciente de msdbpara mantener todos sus trabajos, cronograma de trabajo e historial de trabajo.

5. Restaurar todas las bases de datos de USUARIO a una instancia SQL nueva (o existente)

Si ya tiene otra instancia existente ejecutándose (versión adecuada de SQL, suficiente espacio en disco), probablemente comenzaría las restauraciones de la base de datos de las copias de seguridad más recientes mientras estoy trabajando en los otros pasos de solución de problemas anteriores, en caso de que los necesite.

Si su instancia nueva (o reinstalada) tiene acceso al mismo disco, es mucho más rápido simplemente adjuntarlos como nuevas bases de datos:

CREATE DATABASE foo 
ON (FILENAME = 'D:\data\foo.mdf'),
   (FILENAME = 'D:\data\foo_log.ldf')
FOR ATTACH;

6. Vuelva a hacer cualquier cambio en master

Una vez que restaure con éxito master(a través de cualquiera de las técnicas anteriores), debe investigar los cambios que podrían haberse perdido, si se realizaron después de la copia de seguridad que acaba de restaurar:

• Cambios de seguridad
• Nuevas bases de datos (los archivos seguirán en el disco, solo adjúntelos)
• Configuración de todo el servidor

No hay una forma mágica de encontrarlos, si tiene uno, tendrá que volver al rastro de documentación de su propia empresa para ver este tipo de cambios.

Solo quería agregar un posible problema y solución que acabo de encontrar: tuve una situación similar durante una actualización acumulativa fallida (CU202016 CU12) y los mensajes en el visor de eventos y errlog decían "No se puede recuperar la base de datos maestra. SQL Server es no se puede ejecutar. Restaurar el maestro desde una copia de seguridad completa, repararlo o reconstruirlo ". Sin embargo, eventualmente descubrí que si volvía a ejecutar el CU ejecutable, detectaba el estado de actualización como" Incompletamente instalado "y me permitía simplemente ejecutar el actualizar de nuevo, después de lo cual se completó con éxito y la base de datos maestra y todos los demás se abrieron sin problemas.