Cómo mover bases de datos entre equipos que están ejecutando SQL Server

En este artículo paso a paso se describe cómo mover bases de datos de usuario de Microsoft SQL Server y los componentes más comunes de SQL Server entre equipos que ejecutan SQL Server.

En los pasos descritos en este artículo se supone que no moverá las bases de datos del sistema master, model, tempdb o msdb. Los pasos proporcionan distintas opciones para transferir los inicios de sesión y la mayoría de los componentes comunes contenidos en las bases de datos master y msdb.

Para obtener información acerca de los elementos específicos que no se transfieren cuando sigue los pasos descritos en este artículo, consulte la sección "Más información" de este artículo.

Nota
Se permite la migración de datos de SQL Server 2000 a Microsoft SQL Server 2000 (64 bits). Puede asociar una base de datos de 32 bits a una base de datos de 64 bits utilizando el procedimiento almacenado del sistema sp_attach_db o sp_attach_single_file_db, o utilizando la copia de seguridad y restauración en el Administrador corporativo de 32 bits. Es posible mover bases de datos entre las versiones de 32 bits y de 64 bits de SQL Server. También puede migrar datos de SQL Server 7.0 utilizando los mismos métodos. Sin embargo, no se pueden degradar datos a SQL Server 7.0 desde SQL Server 2000 (64 bits). A continuación se describe cada método.

Si utiliza SQL Server 2005

Puede utilizar el mismo método para migrar datos de SQL Server 7.0 o SQL Server 2000. Sin embargo, la herramienta de administración de Microsoft SQL Server 2005 difiere de la de SQL Server 7.0 o SQL Server 2000. Debe utilizar Management Studio de SQL Server en lugar del Administrador corporativo de SQL Server, y el Asistente para importación/exportación de SQL Server (DTSWizard.exe) en lugar del Asistente para importación y exportación de datos de Servicios de transformación de datos.

Copia de seguridad y restauración

Haga copia de seguridad de las bases de datos de usuario en el servidor de origen y, después, restáurelas en el servidor de destino.

• La base de datos puede utilizarse mientras se realiza la copia de seguridad. Si los usuarios ejecutan instrucciones INSERT, UPDATE o DELETE en la base de datos después de que haya finalizado la copia de seguridad, la copia de seguridad no contendrá estos cambios. Si debe transferir todos los cambios, puede hacerlo con un tiempo de inactividad del sistema mínimo si realiza una copia de seguridad del registro de transacciones y una copia de seguridad completa de la base de datos.
  1. Restaure la copia de seguridad completa de la base de datos en el servidor de destino y especifique la opción WITH NORECOVERY.
     
     Nota
     Para impedir modificaciones adicionales de la base de datos, pida a los usuarios que no realicen ninguna actividad de base de datos en el servidor de origen.
  2. Realice una copia de seguridad del registro de transacciones y restáurela en el servidor de destino utilizando la opción WITH RECOVERY. El tiempo de inactividad del sistema está limitado al tiempo en que se realiza la copia de seguridad y la restauración del registro de transacciones. Para obtener más información al respecto, consulte el subtema "RESTORE" en el tema "Referencia de Transact-SQL" de los Libros en pantalla de SQL Server.
• La base de datos del servidor de destino tendrá el mismo tamaño que la base de datos del servidor de origen. Para disminuir el tamaño de la base de datos, debe reducir la base de datos de origen antes de realizar la copia de seguridad o debe reducir la base de datos de destino después de que finalice la restauración. Para obtener más información al respecto, vea el subtema "Comprimir una base de datos" en el tema "Crear y mantener bases de datos" de los Libros en pantalla de SQL Server.
• Si restaura la base de datos en una ubicación de archivo diferente que la base de datos de origen, debe especificar la opción WITH MOVE. Por ejemplo, en el servidor de origen la base de datos está en la carpeta D:\Mssql\Data. El servidor de destino no tiene una unidad D y desea restaurar la base de datos en la carpeta C:\Mssql\Data. Para obtener más información acerca de cómo restaurar una base de datos en otra ubicación diferente, haga clic en los números de artículo siguientes para verlos en Microsoft Knowledge Base:
  221465

  (http://support.microsoft.com/kb/221465/ )

  INF: Uso de la opción WITH MOVE con la instrucción RESTORE
  304692

  (http://support.microsoft.com/kb/304692/ )

  INF: Mover bases de datos de SQL Server a una nueva ubicación con BACKUP y RESTORE
• Si desea sobrescribir una base de datos ya existente en el servidor de destino, debe especificar la opción WITH REPLACE. Para obtener más información al respecto, consulte el subtema "RESTORE" en el tema "Referencia de Transact-SQL" de los Libros en pantalla de SQL Server.
• Dependiendo de la versión de SQL Server a la que vaya a restaurar, puede que el juego de caracteres, el criterio de ordenación y la intercalación Unicode deban ser iguales en los servidores de origen y de destino. Para obtener más información al respecto, consulte la sección "Nota sobre la intercalación" de este artículo.

Procedimientos almacenados Sp_detach_db y Sp_attach_db

Para utilizar los procedimientos almacenados sp_detach_db y sp_attach_db, siga estos pasos:

1. Separe la base de datos del servidor de origen mediante el procedimiento almacenado sp_detach_db. Debe copiar al servidor de destino los archivos .mdf, .ndf y .ldf asociados a la base de datos. Vea esta tabla para obtener una descripción de los tipos de archivo:
   Contraer esta tablaAmpliar esta tabla

   Extensión de nombre de archivo	Descripción
   .mdf	Archivo de datos primario
   .ndf	Archivo de datos secundario
   .ldf	Archivo de registro de transacciones

2. Asocie la base de datos del servidor de destino mediante el procedimiento almacenado sp_attach_db y señale a los archivos que copió al servidor de destino en el paso anterior. Para obtener más información acerca de cómo utilizar estos métodos, haga clic en el número de artículo siguiente para verlo en Microsoft Knowledge Base:
   224071

   (http://support.microsoft.com/kb/224071/ )

   INF: Mover bases de datos de SQL Server a una nueva ubicación utilizando Separar y Adjuntar

• La base de datos es inaccesible después de la separación y no puede utilizarla mientras copia los archivos. Todos los datos contenidos en la base de datos en el momento de la separación se moverán.
• El juego de caracteres, el criterio de ordenación y la intercalación Unicode quizás tengan que ser iguales en ambos servidores cuando utilice el método Attach o Detach. Para obtener más información al respecto, consulte la sección "Nota sobre la intercalación" de este artículo.

Nota sobre la intercalación

Si mueve bases de datos entre servidores de SQL Server 7.0 mediante copia de seguridad y restauración o con los métodos Attach y Detach, el juego de caracteres, el criterio de ordenación y la intercalación Unicode deben ser iguales en ambos servidores. Si mueve bases de datos de SQL Server 7.0 a SQL Server 2000 o entre servidores de SQL Server 2000, la base de datos conserva la intercalación de la base de datos de origen. Esto significa que si el servidor de destino que está ejecutando SQL Server 2000 tiene una intercalación diferente que la base de datos de origen, la base de datos de destino tiene una intercalación diferente que las bases de datos master, model, tempdb y msdb del servidor de destino. Para obtener más información al respecto, vea el tema ""Entornos de intercalación mixtos" en los Libros en pantalla de SQL Server 2000.

Importar y exportar datos (copiar objetos y datos entre bases de datos de SQL Server)

Puede copiar una base de datos entera o puede copiar selectivamente objetos y datos de la base de datos de origen a la base de datos de destino mediante el Asistente para importación/exportación con Servicios de transformación de datos.

• La base de datos de origen puede utilizarse durante la transferencia. Si se utiliza, puede observar algún bloqueo mientras se realiza la transferencia.
• Cuando utiliza el Asistente para importación/exportación, el juego de caracteres, el criterio de ordenación y la intercalación no tiene por qué ser iguales en el servidor de origen y el servidor de destino.
• Como el espacio no utilizado en la base de datos de origen no se mueve, puede que la base de datos de destino no sea tan grande como la base de datos de origen. Del mismo modo, si sólo mueve algunos objetos, puede que la base de datos de destino no sea tan grande como la base de datos de origen.
• Servicios de transformación de datos de SQL Server 7.0 no puede transferir correctamente texto y datos de imagen de más de 64 KB. Este problema no se aplica a la versión de SQL Server 2000 de Servicios de transformación de datos. Para obtener más información al respecto, haga clic en el número de artículo siguiente para verlo en Microsoft Knowledge Base:
  257425

  (http://support.microsoft.com/kb/257425/ )

  REVISIÓN: La transferencia del objeto DTS no transfiere datos BLOB de más de 64 KB

Paso 2: Cómo transferir inicios de sesión y contraseñas

Si no transfiere los inicios de sesión del servidor de origen al servidor de destino, los usuarios actuales de SQL Server quizás no puedan iniciar sesión en el servidor de destino. Puede transferir los inicios de sesión y las contraseñas según las instrucciones descritas en el siguiente artículo de Microsoft Knowledge Base:

Paso 3: Cómo resolver usuarios huérfanos

Después de transferir los inicios de sesión y las contraseñas al servidor de destino, los usuarios quizás no puedan tener acceso a la base de datos. Los inicios de sesión se asocian a los usuarios mediante el identificador de seguridad (SID) y si el SID es incoherente después de mover una base de datos, SQL Server puede denegar el acceso de los usuarios a la base de datos. Este problema se conoce como usuario huérfano. Si transfiere los inicios de sesión y las contraseñas mediante la característica de transferencia de inicios de sesión de DTS de SQL Server 2000, probablemente haya usuarios huérfanos. Además, los inicios de sesión integrados que concedían acceso en un servidor de destino a un dominio diferente que en el servidor de origen hacen que haya usuarios huérfanos.

1. Busque si hay usuarios huérfanos. Abra el Analizador de consultas en el servidor de destino y ejecute el código siguiente en la base de datos de usuario que ha movido:

   exec sp_change_users_login 'Report'

   El procedimiento muestra todos los usuarios huérfanos que no están vinculados a un inicio de sesión. Si no se muestra ningún usuario, omita los pasos 2 y 3, y vaya al paso 4.
2. Resuelva los usuarios huérfanos. Si hay un usuario huérfano, los usuarios de la base de datos pueden iniciar sesión correctamente en el servidor pero no tendrán permiso de acceso a la base de datos. Si intenta conceder el acceso de inicio de sesión a la base de datos, aparecerá el mensaje de error siguiente porque el usuario ya existe:
   Microsoft SQL-DMO (ODBC SQLState: 42000) Error 15023: El usuario o función '%s' ya existen en la base de datos actual.
   Para obtener más información acerca de cómo resolver usuarios huérfanos, haga clic en los números de artículo siguientes para verlos en Microsoft Knowledge Base:
   240872

   (http://support.microsoft.com/kb/240872/ )

   INF: Cómo resolver problemas de permisos cuando se traslada una base de datos entre servidores SQL Server
   
   El artículo anterior contiene instrucciones para asignar los inicios de sesión a los usuarios de la base de datos, y resuelve los usuarios huérfanos de los inicios de sesión estándar de SQL Server y los inicios de sesión integrados.
   
   
   274188

   (http://support.microsoft.com/kb/274188/ )

   El tema "Solución de problemas de usuarios huérfanos" de Libros en pantalla está incompleto
   
   En el artículo anterior se describe cómo utilizar el procedimiento almacenado sp_change_users_login para corregir los usuarios huérfanos uno a uno. El procedimiento almacenado sp_change_users_login sólo resuelve los usuarios huérfanos de los inicios de sesión estándar de SQL Server.
3. Si el propietario de la base de datos (dbo) se muestra como huérfano, ejecute este código en la base de datos de usuario:

   exec sp_changedbowner 'sa'

   El procedimiento almacenado cambia el propietario de la base de datos a dbo y corrige el problema. Para cambiar el propietario de la base de datos a otro usuario, ejecute de nuevo sp_changedbowner con el usuario que desee. Para obtener más información al respecto, consulte el subtema "sp_changedbowner" en el tema "Referencia de Transact-SQL" de los Libros en pantalla de SQL Server.
4. Si su servidor de destino está ejecutando el Service Pack 1 de SQL Server 2000, el usuario propietario de la base de datos puede no aparecer en la lista en la carpeta Usuarios del Administrador corporativo después de realizar la asociación o la restauración (o ambas). Para obtener más información al respecto, haga clic en el número de artículo siguiente para verlo en Microsoft Knowledge Base:
   305711

   (http://support.microsoft.com/kb/305711/ )

   ERROR: No se muestra el usuario DBO en el Administrador corporativo
5. Puede recibir el mensaje de error siguiente si intenta cambiar la contraseña del administrador del sistema (sa) a través del Administrador corporativo si el inicio de sesión que se asignó a dbo en el servidor de origen no existe en el servidor de destino:
   Error 21776: [SQL-DMO] No se encuentra el nombre 'dbo' en la colección Users. Si se trata de un nombre calificado, utilice [] para separar las diferentes partes y vuelva a intentarlo.
   Para obtener más información al respecto, haga clic en el número de artículo siguiente para verlo en Microsoft Knowledge Base:
   218172

   (http://support.microsoft.com/kb/218172/ )

   PRB: No se puede cambiar la contraseña de sa en el Administrador corporativo

Advertencia
Si restaura o asocia de nuevo la base de datos, se pueden volver a dejar usuarios huérfanos y tiene que repetir el paso 3.

Paso 4: Cómo mover trabajos, alertas y operadores

El paso 4 es opcional. Puede generar secuencias de comandos para todos los trabajos, alertas y operadores del servidor de origen y, a continuación, ejecutar la secuencia de comandos en el servidor de destino.

• Para mover trabajos, alertas y operadores, siga estos pasos:
  1. Abra el Administrador corporativo de SQL Server y expanda la carpeta Administración.
  2. Expanda Agente SQL Server y, a continuación, haga clic con el botón secundario del mouse (ratón) en Alertas, Trabajos u Operadores.
  3. Haga clic en Todas las tareas y, a continuación, haga clic en Generar secuencia de comandos SQL. Para SQL Server 7.0, haga clic en Secuencias de comandos de todos los trabajos, en Alertas o en Operadores.
  Tendrá la opción de generar secuencias de comandos para Todas las alertas, Todos los trabajos o Todos los operadores según el elemento en el que haga clic con el botón secundario del mouse.
• Puede mover trabajos, alertas y operadores de SQL Server 7.0 a SQL Server 2000 o entre servidores que ejecuten SQL Server 7.0 y SQL Server 2000.
• Si tiene operadores configurados para la notificación por SQLMail en el servidor de origen, debe configurar SQLMail en el servidor de destino para que tenga la misma funcionalidad. Para obtener más información al respecto, haga clic en el número de artículo siguiente para verlo en Microsoft Knowledge Base:
  263556

  (http://support.microsoft.com/kb/263556/ )

  INF: Cómo configurar SQL Mail

Paso 5: Cómo mover paquetes DTS

El paso 5 es opcional. Si los paquetes DTS se almacenan en el servidor de origen en SQL Server o en el repositorio, puede moverlos si lo desea. Para mover paquetes DTS entre servidores, utilice uno de los métodos siguientes.

Método 1

1. Guarde el paquete DTS del servidor de origen en un archivo y abra el archivo del paquete DTS en el servidor de destino.
2. Guarde el paquete del servidor de destino en SQL Server o en el repositorio.
   Nota
   Tiene que mover los paquetes uno a uno en archivos independientes.

Método 2

1. Abra cada paquete DTS en el Diseñador de DTS.
2. En el menú Paquete, haga clic en Guardar como.
3. Especifique el servidor SQL Server de destino.

Nota
Puede que el paquete no se ejecute correctamente en el nuevo servidor. Quizás tenga que modificar el paquete y cambiar cualquier referencia en el paquete a conexiones, archivos, orígenes de datos, perfiles y otra información ubicada en el servidor de origen anterior, para que haga referencia al nuevo servidor de destino. Debe realizar estos cambios paquete a paquete, según el diseño de cada paquete.

Quizás desee también mover otros elementos como la replicación, el envío del registro, catálogos de texto, dispositivos de copia de seguridad con nombre, planes de mantenimiento y servidores vinculados. Examine si el servidor de origen tiene estas configuraciones y configúrelas manualmente en el servidor de destino, si lo desea.

Para obtener más información acerca de cómo mover componentes de texto, haga clic en el número de artículo siguiente para verlo en Microsoft Knowledge Base: Los diagramas de base de datos, y el historial de copia de seguridad y de restauración no se mueven si sigue los pasos descritos en en este artículo. Si debe mover esta información, mueva la base de datos del sistema msdb. Para obtener información acerca de cómo mover la base de datos msdb, consulte los artículos de Microsoft Knowledge Base a los que se hace referencia en la sección "Paso 1: Cómo mover bases de datos de usuario" de este artículo. Si mueve la base de datos msdb, no tiene que seguir el "Paso 4: Cómo mover trabajos, alertas y operadores" o el "Paso 5: Cómo mover paquetes DTS".

Para obtener más información al respecto, haga clic en el número de artículo siguiente para verlo en Microsoft Knowledge Base: