Administración de inicios de sesión para los trabajos mediante las bases de datos en un grupo de disponibilidad Always On

  • Artículo

Se aplica a: SQL Server

Debe mantener de forma sistemática el mismo conjunto de inicios de sesión de usuario y de trabajos del Agente SQL Server en cada base de datos principal de un grupo de disponibilidad Always On (AG) y sus correspondientes bases de datos secundarias. Los inicios de sesión y los trabajos se deben reproducir en cada instancia de SQL Server que hospede una réplica de disponibilidad para el grupo de disponibilidad.

  • SQL Server Trabajos de agente

    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 se pueden configurar de forma diferente, como, por ejemplo, con letras de unidad de cinta distintas. Los trabajos para cada réplica de disponibilidad deben permitir tales diferencias.

    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 Uso del asistente para planes de mantenimiento usan esta función de forma nativa. 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 más información, consulte Descarga de copias de seguridad admitidas en las réplicas secundarias de un grupo de disponibilidad.

  • Inicios de sesión

    Si usa bases de datos independientes, puede configurar usuarios independientes 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. En el caso de una base de datos de disponibilidad dependiente, debe crear usuarios para los inicios de sesión en las instancias de servidor que hospedan las réplicas de disponibilidad. Para más información, consulte CREATE USER.

    Si ninguna de las aplicaciones usa la autenticación SQL Server o un inicio de sesión local de Windows, vea Inicios de sesión de aplicaciones que usan la autenticación de SQL Server o un inicio de sesión local de Windows, más adelante en este artículo.

    Nota:

    Un usuario de base de datos cuyo inicio de sesión de SQL Server 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. 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, consulte 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 es necesario volver a crear en cada instancia de servidor que hospeda una réplica secundaria para un grupo de disponibilidad determinado. Por ejemplo, quizás necesite 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 más información, consulta Administración de los metadatos cuando una base de datos pasa a estar disponible en otro servidor.

Autenticación de SQL Server o inicio de sesión de Windows local

Si una aplicación usa la Autenticación de SQL Server o un inicio de sesión local de Windows, los identificadores de seguridad (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.

Debe 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: Transferir inicios de sesión y contraseñas entre instancias de SQL Server.

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 la base de datos y trasvase de registros (un blog del motor de base de datos).

Contenido relacionado