Administración de accesos y trabajos para las bases de datos de un grupo de disponibilidad (SQL Server)

Debe mantener periódicamente el mismo conjunto de inicios de sesión de usuario y trabajos del Agente SQL Server en cada base de datos principal de un grupo de disponibilidad AlwaysOn y las bases de datos secundarias correspondientes. Las credenciales de acceso y los trabajos deben repetirse en cada instancia de SQL Server que aloje una réplica de disponibilidad para el grupo de disponibilidad.

• trabajos del Agente SQL Server

  Debe copiar manualmente los trabajos pertinentes de la instancia de servidor que hospeda la réplica principal original a las instancias de servidor que hospedan las réplicas secundarias originales. Para todas las bases de datos, debe agregar lógica al principio de cada trabajo importante para que el trabajo solo se ejecute en la base de datos principal; es decir, solo cuando la réplica local sea la réplica principal de la base de datos.

  Las instancias de servidor que hospedan las réplicas de disponibilidad de un grupo de disponibilidad pueden configurarse de forma diferente, con letras de unidad de cinta diferentes o similares. Los trabajos para cada réplica de disponibilidad deben permitir tales diferencias.

  Tenga en cuenta que los trabajos de copia de seguridad pueden usar la función sys.fn_hadr_is_preferred_backup_replica para identificar si la réplica local es la preferida para las copias de seguridad, según las preferencias de copia de seguridad del grupo de disponibilidad. Los trabajos de copia de seguridad creados mediante el Asistente para planes de mantenimiento usan de forma nativa esta función. Para otros trabajos de copia de seguridad, se recomienda usar esta función como condición de los trabajos de copia de seguridad, de forma que solo se ejecuten en la réplica preferida. Para obtener más información, consulte Secundarias activas: Realización de copias de seguridad en las réplicas secundarias (grupos de disponibilidad AlwaysOn).

• Inicios de sesión

  Si usa bases de datos independientes, puede configurar usuarios contenidos en las bases de datos y para estos usuarios, no es necesario crear inicios de sesión en las instancias de servidor que hospedan una réplica secundaria. Para una base de datos de disponibilidad no contenida, deberá crear usuarios para los accesos en las instancias de servidor que hospedan las réplicas de disponibilidad. Para obtener más información, consulte CREATE USER (Transact-SQL).

  Si alguna de las aplicaciones usa la autenticación de SQL Server o un inicio de sesión de Windows local, consulte Inicios de sesión de aplicaciones que usan la autenticación de SQL Server o un inicio de sesión de Windows local, más adelante en este tema.

  Nota:

  Un usuario de base de datos para el que el inicio de sesión de SQL Server no está definido o está definido incorrectamente en una instancia de servidor no puede iniciar sesión en la instancia. Es lo que se denomina un usuario huérfano de la base de datos en esa instancia de servidor. Si un usuario está huérfano en una instancia de servidor determinada, puede configurar los inicios de sesión de usuario en cualquier momento. Para obtener más información, vea Solucionar problemas de usuarios huérfanos (SQL Server).

• Metadatos adicionales

  Los inicios de sesión y los trabajos no son la única información que debe volver a crearse en cada una de las instancias de servidor que hospedan una réplica secundaria para un grupo de disponibilidad determinado. Por ejemplo, puede que tenga que volver a crear la configuración del servidor, las credenciales, los datos cifrados, los permisos, la configuración de replicación, las aplicaciones de Service Broker, los desencadenadores (en el nivel de servidor), etc. Para obtener más información, consulte Administración de los metadatos cuando una base de datos pasa a estar disponible en otro servidor (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 este problema, consulte el artículo de KB 918992 cómo transferir los inicios de sesión y las contraseñas entre instancias de SQL Server).

Para obtener más información, vea Usuarios huérfanos con creación de reflejo de la base de datos y trasvase de registros (un blog del motor de base de datos).

Tareas relacionadas

• Crear un inicio de sesión

• Cree un usuario de base de datos.

• Crear un trabajo

• Administrar los metadatos cuando una base de datos pasa a estar disponible en otra instancia de servidor (SQL Server)

Véase también

Información general de los grupos de disponibilidad AlwaysOn (SQL Server)
Bases de datos independientes
Crear empleos