Ir al contenido principal

Como mover las bases de datos MASTER, MODEL, TEMPDB Y MSDB?

Una buena práctica después de instalar SQL Server es cambiar la ubicación de las bases de datos del sistema a los discos y directorios que deseemos. Especialmente interesante es el hecho de cambiar la ubicación de TEMPDB, y también al instalar un Cluster de SQL Server, ya que hasta que no finalice el proceso de Instalación de SQL Server no podremos añadir discos adicionales Esta capítulo explica como mover las bases de datos del sistema (MASTER, MSSQLSYSTEMRESOURCE, MODEL, MSDB ó TEMPDB) en SQL Server 2005.

Una operación de mantenimiento básica después de instalar SQL Server, es tener que mover las Bases de Datos el sistema (MASTER, MODEL, MSDB ó TEMPDB), principalmente porque el programa de instalación no permite personalizar la ubicación de cada uno de los ficheros de cada una de las bases de datos del sistema. Esto tampoco es muy importante, es decir, es instalaciones pequeñas realmente es indiferente, y en instalaciones grandes o críticas suele cuidarse estos detalles (con programa de instalación más listo o menos listo ;-)
La importancia de ésta configuración, es debido a que puede interesarnos no sólo mantener separados los ficheros de Datos de los ficheros de LOG, sino que además, es posible que deseemos o necesitemos separar TEMPDB, es decir, cambiar la ubicación de TEMPDB a un disco (o discos) diferente, ya sea por tratarse de un disco muy rápido que permita mejorar el rendimiento de TEMPDB (y en consecuencia de toda la Instancia de SQL Server), o quizás para evitar problemas de crecimiento de TEMPDB, etc.
Un detalle a tener en cuenta antes de mover las bases de datos el sistema, es comprobar que el usuario utilizado para iniciar SQL Server tiene permisos sobre la nueva ubicación, ya que si por ejemplo movemos TEMPDB a una ubicación en la cual no se dispone de permisos, al reiniciar la Instancia de SQL Server ésta no podrá iniciar, excepto que concedamos permisos en el sistema de ficheros o cambiemos de nuevo la ubicación de TEMPDB (lo cual, podríamos hacer iniciando la Instancia de SQL Server en modo Usuario Unico - Single User) a una ubicación con permisos suficientes.
Antes de mover cualquier base e datos del sistema, también es interesante apuntar la ruta del fichero de ERRORLOG de la Instancia SQL Server sobre la que se va a realizar el cambio (para en caso de problemas, poder consultarlo rápidamente, aunque sea con el NotePad.exe), y ademásapuntar también la ruta de los ejecutables de la Instancia (ej: sqlservr.exe) en la que se va a realizar el cambio, para poder ubicarse en dicha ruta rápidamente e iniciar SQL Server desde el símbolo del sistema si fuese necesario.
Por ejemplo, podríamos tener instalada una Instancia por defecto de SQL Server 2005 en un Cluster MSCS, con la siguiente ruta del ERRORLOG (al ser un Cluster, se tratará de un disco compartido):
F:\Microsoft SQL Server\MSSQL.1\MSSQL\LOG
Y con la siguiente ruta de los ejecutables de la Instancia de SQL Server (se tratará de un disco local, sea Cluster o no ;-):
C:\Program Files\Microsoft SQL Server\MSSQL.1\MSSQL\Binn
También es importante tener claro como arrancar una Instancia de SQL Server 2005 en modo Usuario Unico (Single User) desde el Símbolo del Sistema. Para ello, deberemos seguir los siguientes pasos:
  • Detener la Instancia de SQL Server.
  • Desde una ventana de Símbolo de Sistema (de esas tipo MSDOS de toda la vida ;-), nos posicionamos en el directorio en el que están los ejecutables de la Instancia de SQL Server deseada (ej: cd "C:\Program Files\Microsoft SQL Server\MSSQL.1\MSSQL\Binn").
  • Iniciar la Instancia de SQL Server en modo Usuario Unico (Single User), lo cual se hace con el parámetro -m, y de forma adicional, con el parámetro -c al estar iniciando la Instancia desde fuera del controlador de servicios de Windows (vamos, que es por hacerlo a pelo). Ej: sqlservr.exe -c -m
  • Ahora nos podremos conectar a la Instancia SQL Server, ya sea a través de la utilidad sqlcmd.exe, a través de una nueva consulta de SQL Server Management Studio (SSMS), etc. Recordar que estamos en modo de Usuario Unico, es decir, si abrimos el Object Browser de SQL Server Management Studio, estaremos consumiendo esa única conexión, y cuando nos intentemos conectar con una nueva consulta, no podremos (la única conexión disponible está siendo utilizada por el Object Browser).
  • Cuando acabemos, para detener la Instancia de SQL Server, desde la ventana de Símbolo de Sistema de antes, pulsar Ctrl-C, y responder que sí cuando nos pregunten confirmación para detener la Instancia de SQL Server.
En el caso de estar trabajando con una Instancia de SQL Server en Cluster, se debe tener en cuenta, que para detener una Instancia de SQL Server en Cluster es recomendable hacerlo a través de la herramienta administrativa Cluster Administrator, seleccionando el Recurso correspondiente al Servicio de SQL Server, y poniéndolo OffLine (opción Take OffLine). Si hacemos esta operativa desde el Administrador de Servicios de Windows de uno de los Nodos, el Servicio de Cluster observará la detención del servicio de SQL Server, y se encargará de volver a iniciarlo, por lo cual no podremos detener la Instancia de SQL Server. Por el contrario, en caso de una Instancia de SQL Server que no esté montada en Cluster, si es posible detenerla desde el Administrador de Servicios de Windows (o con un comando NET STOP de los de toda la vida ;-).
También tener en cuenta el mismo detalle para iniciar una Instancia de SQL Server en Cluster: a ser posible, Cluster Administrator (opción Take OnLine).
Otro detalle a tener en cuenta, es recordar que consultando la vista del sistema sys.master_files podemos conocer las rutas de los ficheros de las bases de datos, por lo cual, nos sirve para chequear la ubicación de las bases de datos antes del cambio y después del cambio (ej: SELECT * FROM sys.master_files).
Con todo esto, ya estamos preparados para cambiar las bases de datos del sistema de ubicación (para moverlas). A continuación se detallan los pasos a seguir para mover las bases de datos del sistema de SQL Server:
  • Mover las bases de datos MASTER y MSSQLSYSTEMRESOURCE. Las bases de datos MASTER y MSSQLSYSTEMRESOURCE son hermanas, son dos bases de datos que estan juntas y relacionadas, siendo el principal motivo, que MSSQLSYSTEMRESOURCE es dónde persisten muchos de los objetos del sistema. En versiones anteriores de SQL Server toda esa información se almacenaba directamente en MASTER, pero a partir de SQL Server 2005 la mayoría de los objetos (prácticamente todos) del sistema quedan almacenado en MSSQLSYSTEMRESOURCE.

    Como consecuencia de esto, vamos a explicar el método para mover ambas bases de datos (MASTER y MSSQLSYSTEMRESOURCE). Los pasos a seguir son muy sencillos:

    Especificar la nueva ruta deseada para MASTER (y en consecuencia tambián para MSSQLSYSTEMRESOURCE) utilizando la herramienta SQL Server Configuration Manager. Seleccionaremos el nodo SQL Server 2005 Services, editaremos las propiedades del servicio correspondiente a la Instancia que deseamos modificar, y en la pestaña Advances modificaremos la propiedad Startup Parameters. Por defecto, se especificarán los parámetro -d, -l y -e, que especifican la ruta del fichero de datos de MASTER, el fichero de LOG de MASTER y el directorio del ERRORLOG. En consecuencia, sólo deberemos modificar los parámetro -d y -l para especificar la nueva ubicación.

    Detener la Instancia de SQL Server.

    Mover los ficheros de las bases de datos MASTER y MSSQLSYSTEMRESOURCE a la nueva ubicación. Esto puede hacerse fácilmente con el Explorador de Windows.

    Iniciar la Instancia de SQL Server.

    Realizados estos pasos, habremos conseguido cambiar la ubicación de las bases de datos del sistema MASTER y MSSQLSYSTEMRESOURCE.
  • Mover la base de datos TEMPDB. Es suficiente con ejecutar los correspondiente comandos ALTER DATABASE tempdb MODIFY FILE para cada uno de los ficheros de TEMPDB que deseemos mover de ubicación, teniendo en cuenta que el cambio tomará efecto al reiniciar la Instancia de SQL Server. Eso sí, al reiniciar la Instancia de SQL Server se crearán los nuevos ficheros de TEMPDB, pero deberemos eliminar manualmente los antiguos ficheros de TEMPDB (y así liberar espacio), por ejemplo, utilizando el Explorador de Windows. A continuación se incluye un ejemplo:
USE master
GO
ALTER DATABASE tempdb MODIFY FILE (NAME = tempdev, FILENAME = 'F:\tempdb.mdf')
GO
ALTER DATABASE tempdb MODIFY FILE (NAME = templog, FILENAME = 'F:\templog.ldf')
GO
  • Mover la base de datos MODEL. Es necesario iniciar la Instancia de SQL Server en modo Usuario Unico (Single User) y además con el Trace Flag 3608 que evita que se realice el Recovery de bases de datos (excepto de MASTER) en el inicio de la Instancia de SQL Server. Para ello, será necesario iniciar la Instancia de SQL Server ejecutando algo como:

    sqlservr.exe -c -m -T3608

    Seguidamente, debemos conectarnos a la Instancia de SQL Server y separar (detach) la base de datos MODEL, ejecutando en una consulta de SQL Server Management Studio (o de sqlcmd.exe), algo como:
USE master
GO
sp_detach_db 'model'
GO
Ahora, deberemos mover los ficheros de sitio, por ejemplo copiándolos con el Explorador de Windows. Una vez que tenemos disponibles los ficheros de MODEL en la ubicación deseada, debemos adjuntar (attach) la base de datos MODEL desde la nueva ubicación, ejecutando una consulta similar a la del siguiente ejemplo:
USE master
GO
sp_attach_db 'model', 'F:\model.mdf', 'F:\modellog.ldf'
GO
Y con esto hemos acabado, por lo que deberemos detener la Instancia de SQL Server (que seguirá en modo Usuario Unico), y podremos iniciarla normalmente.
  • Mover la base de datos MSDB. Es necesario iniciar la Instancia de SQL Server en modo Usuario Unico (Single User) y además con el Trace Flag 3608 que evita que se realice el Recovery de bases de datos (excepto de MASTER) en el inicio de la Instancia de SQL Server. Para ello, será necesario iniciar la Instancia de SQL Server ejecutando algo como:

    sqlservr.exe -c -m -T3608

    Seguidamente, debemos conectarnos a la Instancia de SQL Server y separar (detach) la base de datos MSDB, ejecutando en una consulta de SQL Server Management Studio (o de sqlcmd.exe), algo como:
USE master
GO
sp_detach_db 'msdb'
GO
Ahora, deberemos mover los ficheros de sitio, por ejemplo copiándolos con el Explorador de Windows.

Una vez que tenemos disponibles los ficheros de MSDB en la ubicación deseada,deberemos detener la Instancia de SQL Server (que seguirá en modo Usuario Unico), y seguidamente debemos iniciar la Instancia de SQL Server normalmente.

Después de iniciar la Instancia de SQL Server, debemos adjuntar (attach) la base de datos MSDB desde la nueva ubicación, ejecutando una consulta similar a la del siguiente ejemplo:
USE master
GO
sp_attach_db 'msdb', 'F:\msdbdata.mdf', 'F:\msdblog.ldf'
GO
Y con esto ya estará cambiada la ubicación de los ficheros de la base de datos MSDB.

Comentarios

Entradas populares de este blog

¿En qué puerto TCP escucha SQL Server 2005? ¿Cómo cambiar o configurar el puerto TCP de escucha de una Instancia de SQL Server 2005?

Una buena práctica inmediatamente después de instalar SQL Server 2005 es cambiar el Puerto TCP de escucha, por múltiples motivos: Seguridad, Configuración de reglas de acceso de Firewall, Aplicaciones cliente que requieren un puerto TCP estático para SQL Server, etc. En este Artículo se explica cómo averiguar en qué puerto TCP escucha SQL Server 2005, cómo cambiar el puerto TCP de escucha de SQL Server 2005, etc. Resulta de gran interés ser capaz de responder a la pregunta  ¿En qué puerto TCP escucha SQL Server?  Por defecto, una  Instancia por Defecto de SQL Server 2005  queda configurada durante la instalación para escuchar en el  puerto TCP-1433 , sin embargo,  las Instancias con Nombre  quedan configuradas durante el proceso de instalación para escuchar en  puertos TCP dinámicos , por lo tanto, cada vez que se inicie la Instancia puede que escuche en un puerto diferente. Esta situación puede resultar problemática, por un lado desde el punto de vista de la seguridad (el hecho d

¿Qué es el nivel de aislamiento (Isolation Level) de una Transacción? ¿Qué niveles de aislamiento ofrece SQL Server?

Esta capítulo explica qué es el nivel de aislamiento (isolation level) de una transacción, el comportamiento de SQL Server en operaciones de lectura o de escritura, se detallan los diferentes niveles de aislamiento basados en bloqueos (READ UNCOMMITTED, READ COMMITTED, REPEATABLE READ, SERIALIZABLE) y los niveles de aislamiento basados en versionado de filas (READ COMMITTED SNAPSHOT, SNAPSHOT), se explican los males de la concurrencia (lecturas sucias, lecturas no repetibles, lecturas fantasma, y conflictos de actualización), como establecer el nivel de aislamiento deseado (SET TRANSACTION ISOLATION LEVEL y las opciones de base de datos READ_COMMITTED_SNAPSHOT y ALLOW_SNAPSHOT_ISOLATION), cómo conecer el tiempo máximo de bloqueo (@@LOCK_TIMEOUT) y como establecer el tiempo máximo de bloqueo (SET LOCK_TIMEOUT), etc. El nivel de aislamiento de una transacción (transaction isolation level)  define el grado en que se aísla una transacción de las modificaciones de recursos o datos rea

Aumentar y Reducir la TempDB en SQL Server?

Una buena práctica después de instalar SQL Server (y que interesa revisar periódicamente) es tener bien dimensionada la base de datos TEMPDB, es decir que el  tamaño inicial de TEMPDB  sea suficiente, y en consecuencia no sea necesario que TEMPDB crezca ni tampoco reducir TEMPDB (SHRINK). Esta artículo explica brevemente  para qué sirve TEMPDB , explica camo cambiar el tamaño inicial de TEMPDB (aumentar o reducir),  cómo reducir TEMPDB , cuántos ficheros son recomendables para TEMPDB, etc. ¿Para qué sirve TEMPDB?  La base de datos TEMPDB es un elemento de gran importancia en una Instancia de SQL Server, ya que  TEMPDB es la encargada de almacenar tanto los objetos temporales  (tablas temporales, procedimientos almacenados temporales, etc.),  como los resultados intermedios  que pueda necesitar crear el motor de base de datos, por ejemplo durante la ejecución de consultas que utilizan las cláusulas GROUP BY, ORDER BY, DISTINCT, etc. (es decir, las tablas temporales o WorkTables que