Administración de inicios de sesión y trabajos tras la conmutación de roles (SQL Server)
Al implementar una solución de alta disponibilidad o de recuperación ante desastres para una base de datos de SQL Server, es importante reproducir información relevante que se almacena para dicha base de datos en las bases de datos master o msdb. Generalmente, la información relevante incluye los trabajos de la base de datos principal y los inicios de sesión de los usuarios o los procesos que necesitan conectarse con la base de datos. Debe duplicar esta información en las instancias de SQL Server que hospeden una base de datos reflejada o secundaria. 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.
Inicios de sesión
En las instancias de servidor que hospeden una copia de la base de datos, debe reproducir los inicios de sesión que tengan permiso de acceso a la base de datos principal. Cuando cambie el rol principal, solo los usuarios cuyos inicios de sesión existan en la nueva instancia del servidor principal podrán tener acceso la nueva base de datos principal. Los usuarios cuyos inicios de sesión no estén definidos en la nueva instancia del servidor principal se quedarán huérfanos y no podrán tener acceso a la base de datos.
Si un usuario se queda huérfano, cree el inicio de sesión en la nueva instancia del servidor principal y ejecute sp_change_users_login. Para obtener más información, vea Solucionar problemas de usuarios huérfanos (SQL Server).
Inicios de sesión de aplicaciones que usan la autenticación de SQL Server o un inicio de sesión local de Windows
Si una aplicación usa la Autenticación de SQL Server o un inicio de sesión local de Windows, los SID que no coinciden pueden impedir que el inicio de sesión de la aplicación se resuelva en una instancia remota de SQL Server. Los SID que no coincidan harán que el inicio de sesión sea un usuario huérfano en la instancia del servidor remoto. Este problema puede producirse cuando una aplicación se conecta con una base de datos reflejada o de trasvase de registros después de una conmutación por error o con una base de datos Suscriptor de replicación que se inicializó desde una copia de seguridad.
Para evitar que se produzca este problema, se recomienda tomar medidas preventivas al configurar una aplicación de este tipo para que utilice una base de datos hospedada por una instancia remota de SQL Server. La prevención implica la transferencia de los inicios de sesión y las contraseñas de la instancia local de SQL Server a la instancia remota de SQL Server. Para obtener más 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 afecta a las cuentas locales de Windows en distintos equipos. Sin embargo, este problema no ocurre en las cuentas de dominio debido a que el SID es el mismo en todos los equipos.
Para obtener más información, vea Usuarios huérfanos con creación de reflejo de base de datos y trasvase de registros (un blog del motor de base de datos).
Jobs
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 la que antes era la instancia del servidor principal, debería eliminar los trabajos originales en dicha instancia de SQL Server. Observe que los trabajos de la base de datos reflejada actual generan un error porque la base de datos se encuentra en el estado RESTORING y, por lo tanto, no está disponible.
[!NOTA]
Las distintas instancias de SQL Server pueden configurarse de forma diferente, con distintas letras de unidad, por ejemplo. Los trabajos para cada asociado deben permitir tales diferencias.