Administrar los metadatos cuando una base de datos pasa a estar disponible en otra instancia de servidor
Este tema es relevante para el uso de MicrosoftSQL Server 2005 y versiones posteriores en las situaciones siguientes:
Configurar la creación de reflejo de una base de datos.
Preparar la conmutación de funciones entre los servidores primario y secundario de una configuración de trasvase de registros.
Restaurar una base de datos en otra instancia de servidor.
Adjuntar una copia de una base de datos en otra instancia de servidor.
Algunas aplicaciones dependen de información, entidades u objetos que se encuentran fuera del ámbito de una base de datos de usuario único. Normalmente, una aplicación depende de las bases de datos maestras y msdb, así como de la base de datos del usuario. Cualquier elemento almacenado fuera de la base de datos de usuario que sea necesario para el funcionamiento correcto de dicha base de datos debe estar disponible en la instancia de servidor de destino. Por ejemplo, los inicios de sesión de una aplicación se almacenan como metadatos en la base de datos maestra y se deben volver a crear en el servidor de destino. Si una aplicación o un plan de mantenimiento de bases de datos dependen de trabajos del Agente SQL Server, cuyos metadatos estén almacenados en la base de datos msdb, dichos trabajos se deben volver a crear en la instancia de servidor de destino. De forma similar, los metadatos de un desencadenador de servidor se almacenan en la base de datos maestra.
Si mueve la base de datos de una aplicación a otra instancia de servidor, debe volver a crear todos los metadatos de las entidades y objetos dependientes de las bases de datos maestra y msdb en la instancia de servidor de destino. Por ejemplo, si una aplicación de la base de datos usa desencadenadores de servidor, no basta con adjuntar o restaurar la base de datos en el nuevo sistema. La base de datos no funcionará como se espera a menos que se vuelvan a crear manualmente los metadatos para dichos desencadenadores en la base de datos maestra.
Información, entidades y objetos almacenados fuera de las bases de datos de usuario
En lo que queda de este tema se resumen los posibles problemas que podrían afectar a una base de datos que se pone a disposición de otra instancia de servidor. Podría tener que volver a crear uno o varios de los tipos de información, entidades u objetos de la lista siguiente. Para ver un resumen, haga clic en el vínculo del elemento.
Valores de configuración del servidor
Credenciales
Consultas entre bases de datos
Propiedad de la base de datos
Consultas distribuidas y servidores vinculados
Datos cifrados
Mensajes de error definidos por el usuario
Notificaciones de eventos y eventos del Instrumental de administración de Microsoft Windows (WMI) (en el nivel de servidor)
Procedimientos almacenados extendidos
Propiedades del motor de texto completo para SQL Server
Trabajos
Inicios de sesión
Permisos
Configuración de replicación
Aplicaciones de Service Broker
Procedimientos de inicio
Desencadenadores (en el nivel de servidor)
Parámetros de configuración del servidor
SQL Server 2005 y versiones posteriores instalan e inician servicios y características clave de forma selectiva. Esto ayuda a reducir el área de un sistema susceptible de recibir ataques. Con la configuración predeterminada de nuevas instalaciones, no se habilitan muchas de las características. Si la base de datos se basa un servicio o característica desactivada de forma predeterminada, este servicio o característica debe activarse en la instancia de servidor de destino.
Para obtener más información acerca de estos valores de configuración y su activación o desactivación, vea Descripción de la configuración del área expuesta y Establecer las opciones de configuración del servidor.
[Arriba]
Credenciales
Una credencial es un registro que contiene la información de autenticación necesaria para conectarse a un recurso fuera de SQL Server. La mayoría de las credenciales consta de un inicio de sesión de Windows y una contraseña.
Para obtener más información acerca de esta característica, vea Credenciales (motor de base de datos).
[!NOTA]
Las cuentas de proxy del Agente SQL Server usan credenciales. Para conocer el identificador de la credencial de una cuenta proxy, use la tabla del sistema sysproxies.
[Arriba]
Consultas entre bases de datos
Las opciones de base de datos DB_CHAINING y TRUSTWORTHY se establecen, de forma predeterminada, en OFF. Si alguna de estas opciones se establece en ON para la base de datos original, es posible que deba activarlas en la base de datos de la instancia de servidor de destino. Para obtener más información, vea ALTER DATABASE (Transact-SQL).
En el Service Pack 3 (SP3) de SQL Server 2000 y versiones posteriores de SQL Server, las operaciones de adjuntar y separar deshabilitan el encadenamiento de propiedades entre bases de datos para la base de datos. Para obtener información acerca de cómo habilitar el encadenamiento, vea cross db ownership chaining (opción).
Para obtener más información, vea también:
Extender la suplantación de la base de datos mediante EXECUTE AS
Cómo configurar una base de datos reflejada para usar la propiedad Trustworthy
[Arriba]
Propiedad de la base de datos
Cuando se restaura una base de datos en otro equipo, el inicio de sesión de SQL Server o el usuario de Windows que inicia la operación de restauración se convierte automáticamente en el propietario de la nueva base de datos. Una vez restaurada la base de datos, el administrador del sistema o el nuevo propietario de la misma pueden cambiar su propiedad.
Consultas distribuidas y servidores vinculados
Las aplicaciones OLE DB admiten las consultas distribuidas y los servidores vinculados. Las consultas distribuidas obtienen acceso a datos desde varios orígenes de datos heterogéneos del mismo equipo o diferentes equipos. Una configuración con servidores vinculados permite a SQL Server ejecutar comandos en orígenes de datos OLE DB situados en servidores remotos. Para obtener más información acerca de estas características, vea Consultas distribuidas, Vincular servidores y Obtener metadatos de servidores vinculados.
[Arriba]
Datos cifrados
Si la base de datos que pasa a estar disponible en otra instancia de servidor contiene datos cifrados y la clave maestra de la base de datos está protegida por la clave maestra de servicio del servidor original, es posible que deba volver a crear el cifrado de la clave maestra de servicio. La clave maestra de la base de datos es una clave simétrica que se utiliza para proteger las claves privadas de certificados y las claves asimétricas de una base de datos cifrada. Al crearla, la clave maestra de la base de datos se cifra mediante el algoritmo Triple DES y una contraseña proporcionada por el usuario.
Para habilitar el cifrado automático de la clave maestra de una instancia de servidor, se cifra una copia de esta clave mediante la clave maestra de servicio. Esta copia cifrada se almacena en la base de datos y en maestra. Por lo general, la copia almacenada en maestra se actualiza automáticamente siempre que la clave maestra cambia. SQL Server prueba primero a descifrar la clave maestra de la base de datos con la clave maestra de servicio de la instancia. Si este descifrado produce errores, SQL Server buscará en el almacén de credenciales las credenciales de clave maestra con el mismo GUID de familia que la base de datos para la que se necesita la clave maestra. SQL Server intentará descifrar la clave maestra de la base de datos con cada credencial coincidente hasta que el descifrado se realice correctamente o no queden más credenciales. Para abrir una clave maestra que no se haya cifrado con la clave maestra de servicio, debe utilizarse la instrucción OPEN MASTER KEY y una contraseña.
Cuando se copia, restaura o adjunta una base de datos a una nueva instancia de SQL Server, una copia de la clave maestra de la base de datos cifrada por la clave maestra de servicio no se almacena en maestra en la instancia de servidor de destino. Se debe abrir la clave maestra de la base de datos en esta instancia. Para abrir la clave maestra ejecute la siguiente instrucción, OPEN MASTER KEY DECRYPTION BY PASSWORD ='contraseña'. Se recomienda habilitar el descifrado automático de la clave maestra de la base de datos ejecutando la siguiente instrucción: ALTER MASTER KEY ADD ENCRYPTION BY SERVICE MASTER KEY. La instrucción ALTER MASTER KEY proporciona a la instancia de servidor una copia de la clave maestra de la base de datos que se ha cifrado con la clave maestra de servicio. Para obtener más información, vea OPEN MASTER KEY (Transact-SQL) y ALTER MASTER KEY (Transact-SQL).
Para obtener información acerca de cómo habilitar el descifrado automático de la clave maestra de la base de datos de una base de datos reflejada, vea Establecer una base de datos reflejada cifrada.
Para obtener más información, vea también:
[Arriba]
Mensajes de error definidos por el usuario
Los mensajes de error definidos por el usuario residen en la vista de catálogo sys.messages. Esta vista se almacena en la base de datos maestra. Si una aplicación de la base de datos depende de los mensajes de error definidos por el usuario y la base de datos pasa a estar disponible en otra instancia de servidor, use sp_addmessage para agregar esos mensajes de error en la instancia de servidor de destino.
[Arriba]
Notificaciones de eventos y eventos del Instrumental de administración de Microsoft Windows (WMI) (en el nivel de servidor)
Notificaciones de eventos del servidor
Las notificaciones de eventos del servidor se almacenan en la base de datos msdb. Por lo tanto, si una aplicación de la base de datos depende de las notificaciones de eventos del servidor, la notificación de un evento debe volver a crearse en la instancia de servidor de destino. Para ver las notificaciones de eventos de una instancia de servidor, use la vista de catálogo sys.server_event_notifications. Para obtener más información, vea Notificaciones de eventos (motor de base de datos).
Además, las notificaciones de eventos se pueden entregar mediante Service Broker. Las rutas de los mensajes entrantes no están incluidas en la base de datos que contiene un servicio. En lugar de ello, las rutas explícitas se almacenan en la base de datos msdb. Si el servicio utiliza una ruta explicita de la base de datos msdb para enrutar los mensajes entrantes al servicio, cuando adjunte una base de datos en una instancia diferente debe volver a crear esta ruta. Para obtener más información, vea Enrutamiento de Service Broker.
Para configurar una base de datos para la entrega de mensajes remota
Eventos de Instrumental de administración de Windows (WMI)
El proveedor WMI para eventos de servidor le permite utilizar el Instrumental de administración de Windows (WMI) para supervisar eventos en SQL Server. Toda aplicación que dependa de eventos de servidor expuestos a través del proveedor WMI del que depende la base de datos se debe definir en el equipo de la instancia de servidor de destino. El proveedor de eventos WMI crea notificaciones de evento con un servicio de destino definido en msdb.
[!NOTA]
Para obtener más información, vea Conceptos del proveedor WMI para eventos de servidor.
Para crear una alerta WMI mediante SQL Server Management Studio
Funcionamiento de las notificaciones de eventos para una base de datos reflejada
La entrega entre bases de datos de notificaciones de eventos en la que participa una base de datos reflejada es, por definición, remota, porque la base de datos reflejada puede realizar la conmutación por error. Service Broker proporciona compatibilidad especial con bases de datos reflejadas, en forma de rutas reflejadas. En una ruta reflejada hay dos direcciones: una para la instancia de servidor principal y otra para la instancia de servidor reflejada.
Mediante la configuración de rutas reflejadas, se hace que el enrutamiento de Service Broker reconozca la creación de reflejo de bases de datos. Las rutas reflejadas permiten que Service Broker redireccione conversaciones de manera transparente a la instancia de servidor principal actual. Por ejemplo, considere un servicio, Service_A, que es hospedado por una base de datos reflejada, Database_A. Suponga que necesita que otro servicio, Service_B, que es hospedado por Database_B, tenga un diálogo con Service_A. Para que este diálogo sea posible, Database_B debe contener una ruta reflejada para Service_A. Además, Database_A debe contener una ruta de transporte TCP no reflejada a Service_B que, a diferencia de una ruta local, sigue siendo válida después de una conmutación por error. Estas rutas permiten que los ACK regresen después de la conmutación por error. Puesto que al servicio del remitente siempre se le asigna un nombre de la misma forma, la ruta debe especificar la instancia del agente.
El requisito de las rutas reflejadas es válido independientemente de que el servicio de la base de datos reflejada sea el servicio iniciador o el de destino:
Si el servicio de destino está en la base de datos reflejada, el servicio iniciador debe tener una ruta reflejada de vuelta al destino. No obstante, el destino puede tener una ruta normal de vuelta al iniciador.
Si el servicio iniciador está en la base de datos reflejada, el servicio de destino debe tener una ruta reflejada de vuelta al iniciador para entregar reconocimientos y respuestas. No obstante, el iniciador puede tener una ruta normal al destino.
Para obtener más información, vea también:
[Arriba]
Procedimientos almacenados extendidos
.gif "Nota importante") Importante |
|---|
Esta característica se quitará en una versión futura de Microsoft SQL Server. Evite utilizar esta característica en nuevos trabajos de desarrollo y tenga previsto modificar las aplicaciones que actualmente la utilizan. En su lugar, utilice la integración CLR. |
Los procedimientos almacenados extendidos se programan mediante la API Procedimiento almacenado extendido de SQL Server. Un miembro de la función fija de servidor sysadmin puede registrar un procedimiento almacenado extendido con una instancia de SQL Server y conceder permiso a los usuarios para que ejecuten el procedimiento. Los procedimientos almacenados extendidos solo se pueden agregar a la base de datos maestra.
Los procedimientos almacenados extendidos se ejecutan directamente en el espacio de direcciones de SQL Server y pueden producir fugas de memoria y otros problemas que reducen el rendimiento y la confiabilidad del servidor. Debe considerarse la posibilidad de almacenar procedimientos almacenados extendidos en una instancia de SQL Server independiente de la instancia que contiene los datos a los que hace referencia. También se debe considerar la posibilidad de utilizar consultas distribuidas para tener acceso a la base de datos. Para obtener más información, vea Consultas distribuidas.
| Importante |
|---|
Antes de agregar procedimientos almacenados extendidos al servidor y otorgar permisos EXECUTE a otros usuarios, el administrador del sistema debe revisar por completo cada procedimiento almacenado extendido para asegurarse de que no contiene código perjudicial o malintencionado. Para obtener más información, vea Procedimientos almacenados extendidos. |
Para obtener más información, vea GRANT (permisos de objeto de Transact-SQL), DENY (permisos de objeto de Transact-SQL) y REVOKE (permisos de objeto de Transact-SQL).
[Arriba]
Propiedades del motor de texto completo para SQL Server
Las propiedades se establecen en el motor de texto completo a través de sp_fulltext_service. Asegúrese de que la instancia de servidor de destino tiene la configuración necesaria para estas propiedades. Para obtener más información acerca de estas propiedades, vea FULLTEXTSERVICEPROPERTY (Transact-SQL).
Asimismo, si el componente de separadores de palabras y lematizadores o el componente de filtros de búsqueda de texto completo tiene versiones diferentes en las instancias de servidor original y de destino, los índices de texto completo y las consultas pueden tener un comportamiento distinto. Además, el diccionario de sinónimos se almacena en archivos específicos de la instancia. Se debe transferir una copia de esos archivos a una ubicación equivalente de la instancia de servidor de destino o volver a crearlos en la nueva instancia.
[!NOTA]
Al adjuntar una base de datos de SQL Server 2005 que contiene archivos de catálogo de texto completo a una instancia del servidor de SQL Server 2008, los archivos de catálogo se adjuntan desde su ubicación anterior junto con los demás archivos de base de datos, igual que en SQL Server 2005. Para obtener más información, vea Actualización de la búsqueda de texto completo.
Para obtener más información, vea también:
Hacer copia de seguridad y restaurar un catálogo de texto completo de SQL Server 2008
Creación de reflejo de la base de datos y catálogos de texto
[Arriba]
Trabajos
Si la base de datos depende de los trabajos del Agente SQL Server, tendrá que volver a crearlos en la instancia de servidor de destino. Los trabajos dependen de sus entornos. Si tiene previsto volver a crear un trabajo existente en la instancia de servidor de destino, es posible que deba modificar esta instancia para que el entorno de ese trabajo coincida con la instancia de servidor original. Los siguientes factores del entorno son importantes:
El inicio de sesión que utiliza el trabajo
Para crear o ejecutar trabajos del Agente SQL Server, primero debe agregar en la instancia de servidor de destino cualquier inicio de sesión de SQL Server que el trabajo requiera. Para obtener más información, vea Cómo configurar un usuario para crear y administrar trabajos del Agente SQL Server (SQL Server Management Studio).
Cuenta de inicio del servicio del Agente SQL Server
La cuenta de inicio del servicio define la cuenta de Microsoft Windows en la que se ejecuta el Agente SQL Server y sus permisos de red. El Agente SQL Server se ejecuta como una cuenta de usuario especificada. El contexto del servicio del Agente afecta a la configuración del trabajo y a su entorno de ejecución. La cuenta debe tener acceso a los recursos (como por ejemplo, los recursos compartidos de red) que requiere el trabajo. Para obtener información acerca de cómo seleccionar y modificar la cuenta de inicio del servicio, vea Seleccionar una cuenta para el servicio del Agente SQL Server.
Para que funcione correctamente, la cuenta de inicio del servicio se debe configurar para que disponga del dominio, el sistema de archivos y los permisos del Registro correctos. Además, es posible que un trabajo requiera un recurso de red compartido que debe configurarse para la cuenta de servicio. Para obtener información, vea Configurar cuentas de servicio de Windows.
El servicio del Agente SQL Server, que está asociado a una instancia específica de SQL Server, tiene su propio subárbol del Registro y sus trabajos suelen depender de uno o más parámetros de este subárbol. Un trabajo requiere estos parámetro del Registro para que funcione como se espera. Si utiliza un script para volver a crear un trabajo en otro servicio del Agente SQL Server, es posible que su Registro no tenga la configuración correcta para dicho trabajo. Para que los trabajos que se vuelven a crear se comporten correctamente en una instancia de servidor de destino, los servicios originales y de destino del Agente SQL Server deberían tener la misma configuración del Registro.
AdvertenciaEl cambio de valores del Registro en el servicio del Agente SQL Server de destino para controlar un trabajo que se ha vuelto a crear puede causar problemas si otros trabajos requieren los parámetros actuales. Además, si el Registro se modifica incorrectamente, pueden provocarse daños graves en el sistema. Antes de efectuar cambios en el Registro, es recomendable realizar una copia de seguridad de los datos importantes del equipo.
Servidores proxy del Agente SQL Server
Un proxy del Agente SQL Server define el contexto de seguridad de un paso de trabajo especificado. Para ejecutar un trabajo en la instancia de servidor de destino, todos los servidores proxy que requiere se deben volver a crear manualmente en esa instancia. Para obtener más información, vea Crear cuentas de proxy del Agente SQL Server y Solucionar problemas de trabajos multiservidor que usan servidores proxy.
Para obtener más información, vea también:
Administrar inicios de sesión y trabajos tras la conmutación de funciones (para la creación de reflejo de la base de datos)
Configurar cuentas de servicio de Windows (cuando se instala una instancia de SQL Server)
Configurar el Agente SQL Server (cuando se instala una instancia de SQL Server)
Para ver los trabajos existentes y sus propiedades
Para crear un trabajo
Para generar un script de un trabajo existente
Prácticas recomendadas para usar un script para volver a crear un trabajo
Se recomienda empezar por la generación de un script para un trabajo simple; volver a crear el trabajo en el otro servicio del Agente SQL Server y ejecutarlo para ver si funciona como se espera. Esto permitirá identificar las incompatibilidades e intentar resolverlas. Si el trabajo generado con el script no funciona como se espera en este nuevo entorno, se recomienda crear un trabajo equivalente que funcione de forma correcta en ese entorno.
[Arriba]
Inicios de sesión
Para iniciar una sesión en una instancia de SQL Server se requiere un inicio de sesión de SQL Server válido. Este inicio de sesión se utiliza en el proceso de autenticación que comprueba si la entidad de seguridad puede conectarse a la instancia de SQL Server. Un usuario de base de datos cuyo inicio de sesión de SQL Server correspondiente está sin definir o se ha definido de forma incorrecta en una instancia de servidor no podrá iniciar una sesión en la instancia. Es lo que se denomina un usuario huérfano de la base de datos en esa instancia de servidor. También puede convertirse en huérfano si se restaura, adjunta o copia una base de datos a otra instancia de SQL Server.
Para generar un script de algunos o todos los objetos de la copia original de la base de datos, se puede usar el asistente Generar scripts, y en el cuadro de diálogo Elegir opciones de script, configurar la opción Incluir inicios de sesión en el script en True. Para obtener más información, vea Cómo generar un script (SQL Server Management Studio).
Para obtener información acerca de cómo ver los inicios de sesión de SQL Server y detectar y resolver usuarios huérfanos en una instancia de servidor, vea Solucionar problemas de usuarios huérfanos.
[!NOTA]
Para obtener información acerca de cómo configurar los inicios de sesión para una base de datos reflejada, vea Configurar cuentas de inicio de sesión para la creación de reflejo de la base de datos y Administrar inicios de sesión y trabajos tras la conmutación de funciones.
[Arriba]
Permisos
Los siguientes tipos de permisos se podrían ver afectados cuando una base de datos se pone a disposición de otra instancia de servidor.
Permisos GRANT, REVOKE o DENY sobre los objetos del sistema
Permisos GRANT, REVOKE o DENY sobre la instancia de servidor (permisos de servidor)
Permisos GRANT, REVOKE o DENY sobre los objetos del sistema
Los permisos de los objetos del sistema como procedimientos almacenados, procedimientos almacenados extendidos, funciones y vistas, se almacenan en la base de datos maestra y se deben configurar en la instancia de servidor de destino.
Para generar un script de algunos o todos los objetos de la copia original de la base de datos, se puede usar el asistente Generar scripts, y en el cuadro de diálogo Elegir opciones de script, configurar la opción Incluir permisos de objeto en el script en True. Para obtener más información, vea Cómo generar un script (SQL Server Management Studio).
| Importante |
|---|
Si incluye inicios de sesión en el script, no se incluirán las contraseñas. Si tiene inicios de sesión que usan la Autenticación de SQL Server, deberá modificar el script en el destino. |
Puede ver los objetos del sistema en la vista de catálogo sys.system_objects. Puede ver los permisos de objetos del sistema en la vista de catálogo sys.database_permissions de la base de datos maestra. Para obtener información acerca de las consultas de estas vistas de catálogo y la concesión de permisos de objetos del sistema, vea GRANT (permisos de objeto de sistema de Transact-SQL). Para obtener más información, vea REVOKE (permisos de objeto de sistema de Transact-SQL) y DENY (permisos de objeto de sistema de Transact-SQL).
Permisos GRANT, REVOKE o DENY sobre la instancia de servidor
Los permisos en el ámbito del servidor se almacenan en la base de datos maestra y se deben configurar en la instancia de servidor de destino. Para obtener información acera de los permisos del servidor, consulte la vista de catálogo sys.server_permissions; para obtener información acerca de las entidades de seguridad de servidor, consulte la vista de catálogo sys.server_principals; y para obtener información acerca de la pertenencia de las funciones de servidor, consulte la vista de catálogo sys.server_role_members.
Para obtener más información, vea GRANT (permisos de servidor de Transact-SQL), REVOKE (permisos de servidor de Transact-SQL) y DENY (permisos de servidor de Transact-SQL).
Permisos en el nivel de servidor para un certificado o clave asimétrica
Los permisos en el nivel de servidor para un certificado o clave asimétrica no se pueden conceder directamente. En su lugar, los permisos en el nivel de servidor se conceden a un inicio de sesión asignado que se crea exclusivamente para un certificado o clave asimétrica. Por lo tanto, cada certificado o clave asimétrica que requiere permisos en el nivel de servidor, necesita su propio inicio de sesión asignado a un certificado o inicio de sesión asignado a una clave asimétrica. Para conceder permisos en el nivel de servidor para un certificado o clave asimétrica, conceda los permisos a su inicio de sesión asignado.
[!NOTA]
Un inicio de sesión asignado solo se utiliza para la autorización de código firmado con el certificado o clave asimétrica correspondiente. Los inicios de sesión asignados no se pueden utilizar para la autenticación.
El inicio de sesión asignado y sus permisos residen en la base de datos maestra. Si un certificado o clave asimétrica reside en una base de datos que no sea maestra, se debe volver a crear en maestra y asignarlo a un inicio de sesión. Si la base de datos se mueve, copia o restaura en otra instancia de servidor, se deben volver a crear sus certificados o claves asimétricas en la base de datos maestra de la instancia de servidor de destino, asignarlos a un inicio de sesión y conceder a éste los permisos necesarios en el nivel de servidor.
Para crear un certificado o clave asimétrica
Para asignar un certificado o clave asimétrica a un inicio de sesión
Para asignar permisos a un inicio de sesión asignado
Para obtener más información acerca de los certificados y las claves asimétricas, vea Jerarquía de cifrado.
[Arriba]
Configuración de replicación
Si restaura una copia de seguridad de una base de datos replicada en otro servidor o base de datos, no se conservará la configuración de la replicación. En este caso, deberá volver a crear todas las publicaciones y suscripciones después de restaurar las copias de seguridad. Para facilitar este proceso, cree scripts para la configuración actual de la replicación y también para habilitar y deshabilitar la replicación. Para obtener más información, vea Cómo generar scripts de objetos de replicación (SQL Server Management Studio). Para volver a crear los parámetros de la replicación, copie estos scripts y cambie las referencias del nombre de servidor para que funcionen con la instancia de servidor de destino.
Para obtener más información, vea Realizar copias de seguridad de bases de datos de replicación y restaurarlas, Replicación y creación de reflejo de la base de datos y Replicación y trasvase de registros.
[Arriba]
Aplicaciones de Service Broker
Muchos aspectos de una aplicación de Service Broker se mueven con la base de datos. No obstante, algunos aspectos deben volver a crearse o configurarse en la nueva ubicación. Para obtener más información, vea Migración (Service Broker).
[Arriba]
Procedimientos de inicio
Un procedimiento de inicio es un procedimiento almacenado que se marca para su ejecución automática y se ejecuta cada vez que se inicia SQL Server. Si la base de datos depende de algún procedimiento de inicio, se deben definir en la instancia de servidor de destino y configurarse para su ejecución automática durante el inicio.
Para obtener más información, vea Ejecución automática de procedimientos almacenados.
[Arriba]
Desencadenadores (en el nivel de servidor)
Los desencadenadores DDL activan procedimientos almacenados en respuesta a una variedad de eventos del lenguaje de definición de datos (DDL). Estos eventos corresponden principalmente a instrucciones Transact-SQL que comienzan por las palabras clave CREATE, ALTER y DROP. Determinados procedimientos almacenados del sistema que realizan operaciones de estilo DDL también pueden activar desencadenadores DDL.
Para obtener más información acerca de esta característica, vea Desencadenadores DDL.
[Arriba]
Vea también