Podemos encontrarnos diferentes motivos por lo que necesitemos reconstruir las Bases de Datos del Sistema de SQL Server (master, model y msdb), o incluso reconstruir la Base de Datos de Recursos del Sistema (mssqlsystemresource) reparando la instancia de SQL Server. Quizás, los dos casos más típicos sea para cambiar la intercalación de las Bases de Datos del Sistema (es decir, de la Instancia), o para devolver a la vida una Instancia de SQL Server que no levanta por problemas con las Bases de Datos del Sistema (y de las que no tenemos copia de seguridad). A continuación se detallan los procedimiento a seguir para reconstruir las Bases de Datos del Sistema en SQL Server 2008 R2, incluyendo las posibles tareas previas y posteriores, y algunos consejos a tener en cuenta, ya sea una instalación StandAlone o en una instalación en Cluster de SQL Server 2008 R2.
Tareas previas antes de reconstruir las Bases de Datos del Sistema
Al reconstruir las Bases de Datos del Sistema, estamos eliminándolas y volviéndolas a crear. En cierto modo, es como hacer una nueva instalación de SQL Server, ya que el resultado que obtendremos es tener las Bases de Datos del Sistema en su estado por defecto, como si estuviesen recién instaladas.
Por lo tanto, es recomendable recopilar un mínimo de información antes de reconstruir las Bases de Datos del Sistema, con el objetivo de poder dejarlas en un estado similar a como estaban antes de la reconstrucción, y poder continuar dando servicio con normalidad. En cierto modo, es como si tuviésemos que realizar una pequeña Migración.
Algunas tareas que podemos tener que realizar antes de reconstruir las Bases de Datos del Sistema son:
- Obtener las configuraciones de la Instancia. Podemos obtenerlas consultado sys.configurations, de tal modo, que después de reconstruir las Bases de Datos del Sistema, podamos volver a configurarlas de forma equivalente utilizando sp_configure.
- Obtener algunas propiedades de la Instancia, como la versión del producto. Para ello, podemos utilizar la función del sistema SERVERPROPERTY, y consultar algunas propiedades como las siguientes: ProductVersion, ProductLevel, ResourceVersion. De este modo, podemos identificar que Service Pack, Hot Fixes y Cummulative Updates tenemos instalados, ya que los tendremos instalar después de reconstruir las Bases de Datos del Sistema.
- Obtener la información de los ficheros de las Bases de Datos del Sistema. Conocer sus propiedades, ubicación y número de ficheros, nos permitirá poder volver a configurarlas después de reconstruir las Bases de Datos del Sistema.
- Realizar un Backup de las Bases de Datos del Sistema. Por si necesitásemos utilizarlo para dar marcha atrás.
- Revisar, documentar y Exportar todos los Paquetes SSIS almacenados en MSDB.
- Revisar y documentar la configuración de Copias de Seguridad y Planes de Mantenimiento.
- Revisar y Generar Scripts de creación de los Inicios de Sesión, manteniendo correctamente sus propiedades (SID, password, Idioma, pertenencia a Server Roles, etc).
- Revisar y Generar Scripts de las Credenciales (Credentials) existentes en el servidor.
- Revisar y Generar Scripts de Attach y/o Backup y Restore de todas las Bases de Datos, incluyendo la configuración del propietario actual. Esto permitirá volver a configurar las bases de datos de usuario en la instancia de SQL Server, de forma rápida, una vez reconstruidas las Bases de Datos del Sistema. En función de nuestro escenario específico, podría ser necesario realizar los Backups previamente (FULL o FULL y Log, etc.).
- Revisar y documentar la configuración de Database Mail y SQL Mail.
- Revisar y Generar Scripts de los Jobs, Operadores, Proxies, Alertas, etc.
- Revisar y documentar la configuración de SQL Server Agent. Es decir, la información de las diferentes pestañas del diálogo de Propiedades del Agente de SQL Server.
- Revisar y Generar Scripts de Triggers de Servidor (DDL Triggers).
- Revisar y Generar Scripts de Servidores Vinculados (Linked Servers).
Hay muchos más casos que podríamos tener en consideración, dependiendo de nuestro escenario particular. Por ejemplo, en caso de estar utilizando Database Mirroring, Replicación de SQL Server, Data Collector, Data-tier Applications, etc.
Además, si no podemos recuperar las Bases de Datos del Sistema desde un Backup, aún consiguiendo configurarlas de nuevo manualmente (crear Inicios de Sesión, Jobs, Servidores Vinculados, Configurar Database Mail o SQL Mail, etc.), perderemos cosas como los diferentes Historiales que se almacenan en MSDB (ej: Historial de Backup y Restore, Historial de Database Mail, etc.).
Además, las tareas que necesitemos realizar pueden depender del motivo por el cuál necesitemos reconstruir las Bases de Datos del Sistema. Por ejemplo, si la base de datos MODEL está corrupta y no tenemos ningún backup, podríamos hacer un Backup de MASTER y MSDB, reconstruir las Bases de Datos del Sistema, y posteriormente recuperar MASTER y MSDB del Backup que acabamos de realizar. De este modo, evitamos tener que realizar muchas tareas previas y posteriores a la reconstrucción de las Bases de Datos del Sistema.
Evidentemente, si tenemos la base de datos MASTER corrupta y la instancia de SQL Server no es capaz de arrancar, si no tenemos un Backup de MASTER, la cosa estará algo más complicada, ya que no podremos obtener la información que comentábamos anteriormente ni tendremos un Backup de MASTER que podamos recuperar. Estamos hablando de errores como el siguiente, que podemos encontrar en el ERRORLOG:
During redoing of a logged operation in database 'master', an error occurred at log record ID (142:214:1). Typically, the specific failure is previously logged as an error in the Windows Event Log service. Restore the database from a full backup, or repair the database.
Cannot recover the master database. SQL Server is unable to run. Restore master from a full backup, repair it, or rebuild it. For more information about how to rebuild the master database, see SQL Server Books Online.
Es complicado definir un procedimiento universal válido para todos los casos, por lo que confío, que la información aquí descrita permita al lector evaluar qué pasos se ajustan mejor a su caso particular.
Reconstruir las Bases de Datos del Sistema (master, model, msdb)
A continuación se describe el procedimiento a seguir para reconstruir las Bases de Datos del Sistema (master, model, msdb).
Téngase en cuenta, que no es posible reconstruir una Base de Datos del Sistema en particular, con la excepción de la posibilidad de reconstruir MSDB con el script instmsdb.sql. En todo caso, deberíamos realizar un Backup de las Bases de Datos del Sistema (master, model, msdb), reconstruirlas, y restaurar desde Backup las que no deseábamos reconstruir.
Este procedimiento NO reconstruye la Base de Datos de Recursos del Sistema (mssqlsystemresource), para lo cual, deberíamos Reparar la instalación de SQL Server 2008 R2.
Para instalaciones en Cluster de SQL Server, este procedimiento debe realizarse sobre el Nodo activo con el Recurso de Cluster correspondiente al servicio de SQL Server, puesto OffLine.
Para reconstruir las Bases de Datos del Sistema (master, model, msdb), deberemos ejecutar el SETUP.EXE desde el DVD de instalación de SQL Server, para lo cual, debemos utilizar los parámetros que se muestran a continuación:
- /QUIET o /Q. Ejecutar el SETUP.EXE sin interfaz gráfica.
- /ACTION=REBUILDDATABASE. Especificar que se desea reconstruir las Bases de Datos del Sistema (mater, model, msdb).
- /INSTANCENAME=InstanceName. Especificar el nombre de la instancia sobre la que se desea actuar. Para una instancia por defecto utilizar MSSQLSERVER.
- /SQLSYSADMINACCOUNTS=accounts. Especificar los usuarios o grupos de Windows que se desea hacer miembros de SysAdmin, separados por espacios.
- [ /SAPWD=StrongPassword ]. Opcional. Especificar la password de SA, si se está utilizando autenticación Mixta.
- [ /SQLCOLLATION=CollationName ]. Opcional. Sólo debe especificarse cuando se desea cambiar la intercalación de las Bases de Datos del Sistema.
En nuestro caso de ejemplo, partimos de una instancia de SQL Server 2008 R2 Developer con el Service Pack 1 instalado (compilación 10.50.2500) con la intercalación por defecto de la instalación (en concreto, la intercalación SQL_Latin1_General_CP1_CI_AS) y el modo de autenticación Mixto. Dicha instancia contiene algunas bases de datos.
Deseamos reconstruir las Bases de Datos del Sistema para cambiar la intercalación a Modern_Spanish_CI_AS, para lo cual, ejecutaremos un comando como el que sigue:
setup /q /action=rebuilddatabase /instancename=MSSQLSERVER
/sqlsysadminaccounts=guillesql\administrator /sapwd=patata
/sqlcollation=Modern_Spanish_CI_AS
Si va todo bien, en escasos minutes habrá finalizado su ejecución, de forma similar a como se muestra en la siguiente pantalla capturada.
Si se produce algún error, se mostrará algún mensaje descriptivo, como se puede apreciar en la siguiente pantalla capturada.
En cualquier caso, deberemos revisar el fichero Summary.txt. Por ejemplo con NotePad. Podemos encontrarlo en C:\Program Files\Microsoft SQL Server\100\Setup Bootstrap\Log.
Si comprobamos que no se han producido errores, en este momento ya estarán correctamente reconstruidas las Bases de Datos del Sistema. Como podemos ver, la instancia ahora está configurada con la nueva intercalación y mantiene la versión de compilación de SQL Server 2008 R2 SP1, por lo que no necesitamos volver a parchear.
Ahora llegan las tareas posteriores. Téngase en cuenta que todas las Bases de Datos del Sistema (master, model, msdb) deben tener la misma intercalación. Es decir, sería un error reconstruir las Bases de Datos del Sistema utilizando una intercalación diferente, y posteriormente recuperar alguna de las Bases de Datos del Sistema desde un Backup anterior (con una intercalación distinta a la utilizada al reconstruir). Así, algunas tareas posteriores a realizar serían:
- Realizar un Restore de alguna de las Bases de Datos del Sistema. Ojo, recordar que todas las Bases de Datos del Sistema (master, model, msdb) deben mantener la misma intercalación.
- Recuperar manualmente las configuraciones previas y objetos de las Bases de Datos del Sistema.
- Revisar el correcto arranque de la instancia de SQL Server. En caso de un Cluster, probar a balancear la instancia.
Poco más por hoy. Como siempre confío que la lectura resulte de interés.
