Mover una base de datos de un servidor SQL Server a otro.

 

Introducción

Es bastante común tener que mover bases de datos entre servidores ya sea por traspasos de entornos de desarrollo a producción o por tener información para detectar errores en las aplicaciones, hacer pruebas de carga etc.

Para realizar el movimiento entre servidores pueden seguirse varias alternativas, intentaremos desarrollar algunas y exponer cuales son los mecanismos. Incluiremos también parte de un artículo que ya está publicado en portalsql.com sobre los logins ya que son uno de los temas que suelen dar problemillas al migrar las bases de datos.


DTS. Data Transformation Services.

Los DTS y el asistente que proporciona SQL-SERVER son una estupenda herramienta para mover datos entre servidores, son adecuados cuando los servidores tienen una conexión física entre ellos y por tanto pueden verse. En principio puede migrarse con este mecanismo cualquier base de datos que tenga un controlador ODBC a  nuestro SQL, aunque como todo siempre hay alguna pequeña particularidad que hay que tener en cuenta.

Veamos como se usan. En el menú del directorio de SQL-Server, aparece una aplicación que se llama Asistente para importación y exportación de base de datos que se basa en DTS y que con un sencillo asistente basado en pasos, permite configurar esta información.

Esta pantalla que veis, es la segunda del asistente, pero es exactamente igual que la primera y sirve para identificar origen y destino del movimiento, ahí se pueden crear base  de datos nuevas, o mover los datos a una base de datos existente, utilizando los modelos de autenticación habituales. Inmediatamente después de esta nos aparecerá una pantalla en la que tendremos tres opciones. En esas opciones, elegiremos copiar Tablas y vistas, o bien elegir una consulta específica para elegir los datos a transferir o bien transferir objetos entre servidores  Sql-server. Para esta última opción hace falta tener instalado al menos el Service pack 2 de sql y algunas veces hay ciertos problemas con el modo de licenciamiento para poder realizar esta operación. Posteriormente aparece una pantalla en la que podemos elegir que objetos migrar y con que condiciones, incluso puede personalizarse el mecanismo de migración.

 

 

En la opción transformar se eligen distintas opciones, que sirven para para transformar tipos de datos, asignar variables e incluso puede usarse un lenguaje de script para migrar los datos.

 

Esta opción permite “arreglar” datos que algunas veces no son posible introducir a SQL-SERVER como fechas anteriores a 1792 etc. También permite transformar datos.

Después puede programarse el proceso para que se ejecute de forma inmediata o bien para que se guarde el proceso y se ejecute inmediatamente o bien se ponga a la espera del momento elegido.

También elegimos la forma de almacenamiento del paquete DTS bien en Visual Basic, bien en el propio server. En la siguiente figura se ve de forma clara como funciona esta cuestión.

 

 

Por último se lanza el proceso que se realiza en paralelo y mediante bulk insert, por lo que la introducción de filas es muy rúpida.

 

Backup / Restore.

Otro mecanismo interesante para mover los datos es utilizar backup-restore, es decir, crear una copia de seguridad y restaurar esa copia en el servidor de destino. Esta opción es bastante útil cuando no se pueden conectar los servidores de origen y destino. Básicamente con las instrucciones siguientes sería suficiente.

En el servidor de origen se haría la copia de seguridad. Esta copia se realiza mediante la siguiente instrucción, usando como base de datos northwind, la base de datos de ejemplo que viene con SQL-Server.

backup database northwind to disk =’c:\Northwind.bak’

En el servidor de destino con instrucciones como la siguiente podríamos restaurar la base de datos en el servidor de destino.

restore database nueva from disk=’c:\Northwind.bak’
   with move ‘northwind’ to ‘PON AQUI TU PATH\n1.mdf’ ,
        move ‘northwind_log’ to ‘PON AQUI TU PATH\l1.ldf’

Esto es una opción muy a tener en cuenta, pero hay que tener en cuenta algunas peculiaridades. De una parte, en sql-server 7.0 es necesario que los servidores de origen y destino tengan el mismo sort-order y además tengan la misma página de codigos. Esto es imprescindible y si no es así este sistema no funcionaría.

Si estamos en SQL-SERVER 2000, sin embargo esto no es ningún problema ya que esto ha cambiado, aunque alguna particularidad sigue teniendo.


Servidores vinculados.

Los linked servers, son una opción También si se está físicamente conectados, además hay que tener en cuenta los permisos necesarios para que un servidor acceda al otro y configurar todas estas opciones. No comentamos más acerca de esta opción, porque  sale un poco del objeto del presente documento, pero es una opción que entendemos que puede resultar interesante en ciertos casos y que aunque solamente sea a modo de mención debe figurar.


Vinculación / Desvinculación.

El mecanismo para usar este procedimiento es parecido al de Backup/restore. Sin embargo este método obliga a que no haya ningún usuario conectado a la base de datos de origen en el momento de ejecutarlo. Por otra parte, También es el mecanismo más peligroso de movimiento ya que de alguna manera se desvinculará la base de datos del servidor y por tanto, es un proceso que permite que un error suponga incluso perder los datos.

Los pasos a hacer será ejecutar el procedimiento almacenado sp_detach_db, pasándole como parámetro el nombre de la base de datos.

sp_detach_db ‘nueva’

Esta ejecución desvincula los ficheros de la base de datos. Si esta base de datos se ha creado siguiendo este documento, tendremos dos ficheros en el path elegido con nombres n1.mdf, l1.ldf.

En este momento movemos los ficheros físicamente al nuevo servidor.

Ahora vamos a volver a asociar la base de datos al servidor, utilizando para ello el procedimiento almacenado.

sp_attach_db ‘nueva’, ‘c:\n.mdf’, ‘c:\l.ldf’

Esto es el mismo mecanismo tanto en el origen como en el destino, eso sí, en cada uno de los servidores habrá que tener su path de forma correcta.

Vea También el siguiente artículo para comprender algunos de los problemas que nos podemos encontrar con los usuarios y logins Después de hacer este traspaso de base de datos.


Mover la base de datos Master.

La localización física de la base de datos master se le indica a SQl-Server mediante el parámetro -l y -d y pueden cambiarse desde el administrador corporativo, aunque para cambiarlo hay que borrar el parámetro y volverlo a crear.

Los pasos básicos para realizar esta operación será, cambiar estos parámetros para la localización en la que queremos que quede (en el administrador corporativo propiedades del servidor, parámetros de inicio).

Inmediatamente Después, deberíamos parar el servidor y mover los ficheros a la nueva localización.

Por último arrancaríamos el servicio de Sql-Server.

NOTA: Es imprescindible que se hagan copias de seguridad de la base de datos, de todas las bases de datos y además yo no usaría este mecanismo en ningún servidor en explotación, es bastante peligrosa y las posibilidades de error son bastante grandes.

En el site de SQLservercentral.com hay artículos de Steve Jones que explica más en detalle este movimiento de la base de datos master y enlaces a como mover msdb y tempdb.

También en la knowledge base de Microsoft hay un artículo interesante sobre este tema:
Move Databases Between Computers That Are Running SQL Server

Otros enlaces interesantes:

http://www.programacion.com/bbdd/articulo/man_moverbasesdatos/

datos/