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.