Administrar inicios de sesión y trabajos tras la conmutación de roles
Sólo se refleja el contenido de la base de datos principal. La información asociada de las bases de datos del sistema maestra o msdb no se pueden reflejar. Esta información asociada incluye trabajos configurados en la base de datos principal e inicios de sesión agregados al servidor principal.
Si tal información es importante para admitir la conmutación de roles, la información debería duplicarse en el sitio reflejado. Si es posible, tras la conmutación de roles es mejor reproducir mediante programación la información en la nueva base de datos principal. Los problemas más habituales los representan los inicios de sesión y los trabajos.
Inicios de sesión
Para que los usuarios puedan tener acceso a la base de datos tras una conmutación de roles, en el servidor reflejado también debe definirse un inicio de sesión del servidor principal que tenga permiso de acceso a la base de datos principal. Sin embargo, la base de datos maestra no se puede reflejar. Por lo tanto, si en el servidor principal actual crea un inicio de sesión para este inicio de sesión de la base de datos principal, deberá hacer lo mismo en el reflejo.
El inicio de sesión de cada usuario de la base de datos debe definirse manualmente en el servidor reflejado y en el servidor principal. De lo contrario, cuando el rol principal cambia y el que antes era el servidor reflejado ofrece su base de datos como la base de datos principal, los usuarios cuyos inicios de sesión no estén definidos en el que antes era el servidor reflejado no podrán tener acceso al nuevo servidor principal. Los usuarios se quedan huérfanos.
Si un usuario está huérfano en el nuevo servidor principal, cree el inicio de sesión en el nuevo servidor principal y ejecute sp_change_users_login (Transact-SQL). Para obtener más información, vea Solucionar problemas de usuarios huérfanos.
Inicios de sesión de aplicaciones que usan la autenticación de SQL Server
Si una aplicación que intenta conectarse a una base de datos reflejada usa la autenticación de SQL, la discrepancia de los SID puede impedir que se resuelva el inicio de sesión de la aplicación tras una conmutación por error dejando al usuario huérfano. Puede usar sp_change_users_login para resolver un usuario huérfano (vea Solucionar problemas de usuarios huérfanos).
Sin embargo, es recomendable que tome medidas preventivas cuando configure una aplicación de este tipo para que use la base de datos reflejada. Para obtener información sobre cómo evitar que se produzca este problema, vea el artículo de KB 918992: Cómo transferir inicios de sesión y contraseñas entre instancias de SQL Server 2005 y 2008.
Nota
Este problema no se produce con la autenticación de Windows porque los SID de los inicios de sesión de Windows no son específicos del equipo y se obtienen de Active Directory.
Trabajos
Los trabajos, como, por ejemplo, los trabajos de copia de seguridad, requieren una consideración especial. Normalmente, tras una conmutación de roles, el propietario de la base de datos o el administrador del sistema deben volver a crear los trabajos de la nueva base de datos principal.
Cuando está disponible el que antes era el servidor principal, debería eliminar también los trabajos originales de la nueva base de datos reflejada. Los trabajos de la base de datos reflejada generan un error porque la base de datos se encuentra en el estado RESTORING y, por lo tanto, no está disponible.
Nota
Los asociados pueden configurarse de forma diferente, con distintas letras de unidad de cinta, por ejemplo. Los trabajos para cada asociado deben permitir tales diferencias.