Compartir a través de

Secundarias activas: réplicas secundarias legibles (grupos de disponibilidad AlwaysOn)

  • Artículo

Las funcionalidades secundarias activas de los grupos de disponibilidad Always On incluyen compatibilidad con el acceso de solo lectura a una o varias réplicas secundarias (réplicas secundarias legibles). Una réplica secundaria legible permite el acceso de solo lectura a todas las bases de datos secundarias. Sin embargo, las bases de datos secundarias legibles no se establecen como de solo lectura. Son dinámicas. Una base de datos secundaria dada cambia a medida que se aplican los cambios en la base de datos principal correspondiente. En lo que respecta a las réplicas secundarias típicas, los datos, lo cual incluye las tablas con optimización para memoria durables, las bases de datos secundarias están en tiempo prácticamente real. Además, los índices de texto completo se sincronizan con las bases de datos secundarias. En muchas circunstancias, la latencia de datos entre una base de datos principal y la base de datos secundaria correspondiente suele ser de solo unos pocos segundos.

La configuración de seguridad de las bases de datos principales se mantiene en las secundarias. Esto incluye usuarios, roles de base de datos y roles de aplicación, junto con sus permisos correspondientes, y también incluye cifrado de datos transparentes (TDE) si está habilitado en la base de datos principal.

Nota:

Aunque no puede escribir datos en las bases de datos secundarias, puede escribir en bases de datos de lectura y escritura de la instancia del servidor que hospeda la réplica secundaria, incluidas las bases de datos de usuario y las bases de datos del sistema, como tempdb.

Always On grupos de disponibilidad también admite el reenrutamiento de solicitudes de conexión de intención de lectura a una réplica secundaria legible (enrutamiento de solo lectura). Para obtener información sobre el enrutamiento de solo lectura, vea Usar un agente de escucha para conectarse a una réplica secundaria de solo lectura (enrutamiento de solo lectura).

Ventajas

La dirección de conexiones de solo lectura a las réplicas secundarias legibles proporciona las siguientes ventajas:

  • Alivia las cargas de trabajo de solo lectura secundarias de la réplica primaria, que conserva los recursos para las cargas de trabajo esenciales de la misión. Si tiene una carga de trabajo de lectura de gran importancia o si la carga de trabajo no puede tolerar la latencia, debe ejecutarla en el servidor principal.

  • Mejora la rentabilidad de la inversión para los sistemas que hospedan las réplicas secundarias legibles.

Además, las réplicas secundarias legibles proporcionan compatibilidad robusta con las operaciones de solo lectura, de la forma siguiente:

  • Las estadísticas temporales automáticas en las bases de datos secundarias legibles optimizan las consultas de solo lectura en tablas basadas en disco. Para las tablas con optimización para memoria, se crean automáticamente las estadísticas que faltan. Sin embargo, no hay actualizaciones automáticas de estadísticas en desuso. Deberá actualizar manualmente las estadísticas en la réplica primaria. Para obtener más información, vea Estadísticas de las bases de datos de acceso de solo lectura, más adelante en este tema.

  • Las cargas de trabajo de solo lectura para tablas basadas en disco usan las versiones de fila para quitar la contención de bloqueo en las bases de datos secundarias. Todas las consultas que se ejecutan en las bases de datos secundarias se asignan automáticamente al nivel de transacción de aislamiento de instantánea, incluso cuando se establecen otros niveles de aislamiento de transacción de forma explícita. Asimismo, se pasan por alto todas las sugerencias de bloqueo. Esto elimina la contención de lectura y escritura.

  • Las cargas de trabajo de solo lectura para tablas durables optimizadas para memoria acceden a los datos exactamente de la misma forma que en la base de datos primaria, con procedimientos almacenados nativos o interoperabilidad de SQL con las mismas limitaciones del nivel de aislamiento de transacción. La carga de trabajo de informes o las consultas de solo lectura que se ejecutan en la réplica principal se pueden ejecutar en la réplica secundaria sin necesidad de hacer ningún cambio. De forma similar, las cargas de trabajo de informes o las consultas de solo lectura que se ejecutan en una réplica secundaria se pueden ejecutar en la réplica principal sin necesidad de hacer ningún cambio. Al igual que ocurre con las tablas basadas en disco, todas las consultas que se ejecutan en las bases de datos secundarias se asignan automáticamente al nivel de transacción de aislamiento de instantánea, incluso cuando se establecen otros niveles de aislamiento de transacción de forma explícita.

  • Las operaciones DML se permiten en variables de tabla tanto para los tipos de tabla basadas en disco como para los tipos de tabla optimizada para memoria en la réplica secundaria.

Requisitos previos del grupo de disponibilidad

  • Réplicas secundarias legibles (requeridas)

    El administrador de la base de datos debe configurar una o varias réplicas de modo que, cuando se ejecutan en el rol secundario, permiten todas las conexiones (solo para el acceso de solo lectura) o solo conexiones con intención de lectura.

    Nota:

    Opcionalmente, el administrador de bases de datos puede configurar cualquiera de las réplicas de disponibilidad para excluir las conexiones de solo lectura al ejecutarse en el rol principal.

    Para más información, consulte Acerca del acceso de conexión de cliente a réplicas de disponibilidad (SQL Server).

  • Agente de escucha de grupo de disponibilidad

    Para admitir el enrutamiento de solo lectura, un grupo de disponibilidad debe poseer un agente de escucha de grupo de disponibilidad. El cliente de solo lectura debe dirigir sus solicitudes de conexión a este cliente de escucha, y la cadena de conexión del cliente debe especificar la intención de la aplicación como de "solo lectura". Es decir, deben ser solicitudes de conexión con intención de lectura.

  • Enrutamiento de solo lectura

    Elenrutamiento de solo lectura hace referencia a la capacidad de SQL Server para enrutar las solicitudes de conexión con intención de lectura entrantes, que se dirigen a un agente de escucha de grupo de disponibilidad, a una réplica secundaria legible disponible. Los requisitos previos para el enrutamiento de solo lectura son los siguientes:

    • Para admitir el enrutamiento de solo lectura, una réplica secundaria legible requiere una dirección URL de enrutamiento de solo lectura. Esta dirección URL tiene efecto cuando la réplica local se ejecuta en el rol secundario. La dirección URL de enrutamiento de solo lectura debe especificarse réplica a réplica, según sea necesario. Cada dirección URL de solo lectura se usa para enrutar las solicitudes de conexión de intento de lectura a una réplica secundaria legible específica. Normalmente, cada réplica secundaria legible se asigna a una dirección URL de enrutamiento de solo lectura.

    • Cada réplica de disponibilidad que vaya a admitir el enrutamiento de solo lectura cuando es la réplica principal requiere una lista de enrutamiento de solo lectura. Una lista de enrutamiento de solo lectura dada solo tiene efecto cuando la réplica local se ejecuta en el rol principal. Esta lista se debe especificar réplica a réplica, según sea necesario. Normalmente, cada lista de enrutamiento de solo lectura contendría cada dirección URL de enrutamiento de solo lectura con la dirección URL de la réplica local al final de la lista.

      Nota:

      Las solicitudes de conexión de intento de lectura se enrutan al primer elemento secundario legible disponible en la lista de enrutamiento de solo lectura de la réplica principal actual. No hay equilibrio de carga.

    Para más información, consulte Configuración del enrutamiento de solo lectura para un grupo de disponibilidad AlwaysOn (SQL Server).

Nota:

Para información sobre las escuchas de grupo de disponibilidad y conocer más sobre el enrutamiento de solo lectura, consulte Escuchas de grupo de disponibilidad, conectividad de cliente y conmutación por error de una aplicación (SQL Server).

Limitaciones y restricciones

Algunas operaciones no se admiten por completo, como se indica a continuación:

  • Tan pronto como se habilita una réplica legible para lectura, puede comenzar a aceptar conexiones a sus bases de datos secundarias. Sin embargo, si hay transacciones activas en una base de datos principal, las versiones de fila no estarán del todo disponibles en la base de datos secundaria correspondiente. Las transacciones activas que existían en la réplica principal cuando se configuró la réplica secundaria deben confirmarse o revertirse. Hasta que el proceso finalice, la asignación del nivel de aislamiento de transacción en la base de datos secundaria estará incompleta y las consultas se bloquearán temporalmente.

    Advertencia

    La ejecución de transacciones largas afecta al número de filas con control de versiones que se conservan, tanto en tablas basadas en disco como en tablas optimizadas para memoria.

  • En las bases de datos secundarias con tablas optimizadas para memoria, pese a que siempre se generan versiones de filas para las tablas optimizadas para memoria, las consultas se bloquean hasta que se completen todas las transacciones activas que había en la réplica principal cuando se habilitó la réplica secundaria para lectura. De esta forma se garantiza que las tablas basadas en disco y las tablas optimizadas para memoria estén disponibles para la carga de trabajo de informes y para las consultas de solo lectura al mismo tiempo.

  • El seguimiento de cambios y la captura de datos modificados no se admiten en las bases de datos secundarias que pertenecen a una réplica secundaria legible:

    • El seguimiento de cambios está deshabilitado de forma explícita en las bases de datos secundarias.

    • La captura de datos modificados se puede habilitar en una base de datos secundaria, pero no se admite.

  • Dado que las operaciones de lectura se asignan al nivel de transacción de aislamiento de instantánea, la limpieza de registros fantasma en la réplica principal puede bloquearse por las transacciones en una o varias réplicas secundarias. La tarea de limpieza de registros fantasma limpiará automáticamente los registros fantasma para las tablas basadas en disco en la réplica principal cuando las réplicas secundarias ya no los necesiten. Esto es similar a lo que se realiza cuando se ejecutan transacciones en la réplica principal. En el caso extremo de la base de datos secundaria, deberá eliminar una consulta de lectura de ejecución prolongada que esté bloqueando la limpieza de registros fantasma. Tenga en cuenta que la limpieza de registros fantasma se puede bloquear si la réplica secundaria se desconecta o cuando se suspende el movimiento de datos en la base de datos secundaria. Este estado también evita el truncamiento del registro, por lo que si el estado persiste, se recomienda quitar esta base de datos secundaria del grupo de disponibilidad. No existen problemas de limpieza de registros fantasma con las tablas con optimización para memoria porque las versiones de filas se conservan en memoria y son independientes de las versiones de fila de la réplica principal.

  • Se puede producir un error en la operación DBCC SHRINKFILE en los archivos que contienen tablas basadas en disco en la réplica principal si el archivo contiene registros fantasma que siguen siendo necesarios en una réplica secundaria.

  • A partir de SQL Server 2014, las réplicas secundarias legibles pueden permanecer en línea incluso cuando la réplica principal está sin conexión debido a una acción del usuario o a un error. Sin embargo, el enrutamiento de solo lectura no funciona en esta situación porque el agente de escucha del grupo de disponibilidad está desconectado también. Los clientes deben conectarse directamente a las réplicas secundarias de solo lectura para las cargas de trabajo de solo lectura.

Nota:

Si consulta la vista de administración dinámica sys.dm_db_index_physical_stats en una instancia del servidor que está hospedando una réplica secundaria legible, puede producirse un problema de bloqueo de REDO. Esto se debe a que esta vista de administración dinámica adquiere un bloqueo IS en la tabla de usuario especificada o la vista que puede bloquear las solicitudes de un subproceso de REDO durante un bloqueo X en esa tabla o vista de usuario.

Consideraciones de rendimiento

En esta sección se describen las consideraciones de rendimiento para las bases de datos secundarias legibles

Latencia de datos

La implementación del acceso de solo lectura en las réplicas secundarias resulta útil si las cargas de trabajo de solo lectura pueden tolerar cierta latencia de datos. En las situaciones en las que la latencia de datos no es aceptable, considere la posibilidad de ejecutar cargas de trabajo de solo lectura en la réplica principal.

La réplica principal envía las entradas de registro de los cambios en la base de datos principal a las réplicas secundarias. En cada base de datos secundaria, un subproceso de rehacer dedicado aplica las entradas de registro. En una base de datos secundaria de acceso de lectura, un cambio determinado de datos no aparece en los resultados de la consulta hasta que la entrada del registro que contiene el cambio se haya aplicado a la base de datos secundaria y la transacción se haya confirmado en la base de datos principal.

Esto significa que hay latencia, normalmente solo se trata de unos segundos, entre las réplicas principales y secundarias. No obstante, en casos excepcionales, por ejemplo, si los problemas de red reducen el rendimiento, la latencia puede ser importante. La latencia aumenta cuando se producen cuellos de botella de E/S y cuando se suspende el movimiento de los datos. Para supervisar el movimiento de datos suspendido, puede usar el panel AlwaysOn o la vista de administración dinámica sys.dm_hadr_database_replica_states .

Latencia de datos en bases de datos con tablas optimizadas para memoria

Al tener acceso a tablas optimizadas para memoria en una réplica secundaria de una carga de trabajo de lectura, se usa una marca de tiempo de seguridad para devolver filas de las transacciones que se han confirmado antes de la marca de tiempo de seguridad. La marca de tiempo de seguridad es la sugerencia de marca de tiempo más antigua que el subproceso de recolección de elementos no utilizados usa para recopilar las filas no utilizadas de la réplica principal. Esta marca de tiempo se actualiza cuando el número de transacciones DML de las tablas optimizadas para memoria supera un umbral interno desde la última actualización. Siempre que la marca de tiempo de transacción más antigua se actualiza en la réplica principal, la siguiente transacción DML de una tabla optimizada para memoria durable envía esta marca de tiempo a la réplica secundaria como parte de una entrada de registro especial. El subproceso REDO de la réplica secundaria actualiza la marca de tiempo de seguridad como parte del procesamiento de esta entrada de registro.

El impacto de la marca de tiempo de seguridad sobre la latencia

  • Para las cargas de trabajo OLTP con un rendimiento de transacciones elevado, la latencia debe ser comparable a la de las tablas basadas en disco. Esperamos que este sea el caso más frecuente.

  • Una transacción de ejecución prolongada puede provocar que la marca de tiempo de seguridad se retrase arbitrariamente. Esto no es distinto cuando se accede a tablas basadas en disco, ya que la marca de tiempo de aislamiento de instantánea está determinada por la confirmación de la transacción más antigua.

  • Los cambios realizados por las transacciones en la réplica principal desde la última actualización de la marca de tiempo de seguridad no son visibles en la réplica secundaria hasta la siguiente transmisión y actualización de la marca de tiempo de seguridad. Si la actividad transaccional en la réplica principal se detiene antes de que se llegue al umbral interno para la actualización de la marca de tiempo de seguridad, los cambios realizados desde la última actualización a la marca de tiempo de seguridad no será visible en la réplica secundaria. Para mitigar este problema, puede que tenga que ejecutar algunas transacciones DML en una tabla optimizada para memoria durable ficticia en la réplica principal. O bien, aunque no se recomienda, puede forzar el trasvase de la marca de tiempo de seguridad ejecutando un punto de comprobación manual.

Supervisar y solucionar problemas de latencia de datos en tablas optimizadas para memoria

Puede averiguar la marca de tiempo de seguridad ejecutando la siguiente consulta en la réplica principal

  
SELECT MAX(base_generation)   
   AS max_base_generation  
   FROM sys.dm_db_xtp_gc_cycle_stats  
GO

También puede identificar la marca de tiempo de seguridad usada en la réplica secundaria ejecutando la siguiente consulta simultáneamente a la carga de trabajo de lectura activa.

  
SELECT begin_tsn   
   FROM sys.dm_db_xtp_transactions  
GO

Repercusión de la carga de trabajo de solo lectura

Al configurar una réplica secundaria para el acceso de solo lectura, las cargas de trabajo de solo lectura en las bases de datos secundarias utilizan los recursos del sistema, como la CPU y E/S (para tablas basadas en disco) de los subprocesos REDO, especialmente si las cargas de trabajo de solo lectura en tablas basadas en disco realizan un uso intensivo de E/S. No hay ningún impacto en la E/S cuando se tiene acceso a tablas con optimización para memoria porque todas las filas residen en memoria.

Además, las cargas de trabajo de solo lectura en las réplicas secundarias pueden bloquear los cambios de lenguaje de definición de datos (DDL) que se aplican a través de las entradas de registro.

  • Aunque las operaciones de lectura no tienen bloqueos compartidos debido a las versiones de fila, estas operaciones tienen bloqueos de estabilidad de esquema (Sch-S), que pueden bloquear las operaciones de puesta al día que aplican cambios DDL. Las operaciones DDL incluyen tablas de instrucciones ALTER/DROP y vistas, pero no incluyen instrucciones DROP o ALTER de procedimientos almacenados. Por ejemplo, cuando se quita una tabla basada en disco o con optimización para memoria en la réplica principal. Cuando el subproceso REDO procesa el registro para quitar la tabla, debe adquirir un bloqueo de SCH_M en la tabla y puede bloquearse mediante una consulta en ejecución con acceso a tablas. Este comportamiento es el mismo que en la réplica primaria, salvo que la acción de quitar la tabla forma parte de una sesión de usuario y no de un subproceso REDO.

  • Las tablas con optimización para memoria tienen un bloqueo adicional. Si se quita un procedimiento almacenado, podría hacer que el proceso REDO provoque bloqueos si existen ejecuciones simultáneas del procedimiento almacenado nativo en la réplica secundaria. Este comportamiento es el mismo en la réplica primaria, salvo que la acción de quitar el procedimiento almacenado forma parte de una sesión de usuario y no de un subproceso REDO.

Debe tener en cuenta los procedimientos recomendados acerca de la creación de consultas y aplicarlos a las bases de datos secundarias. Por ejemplo, programe las consultas de ejecución prolongada tales como agregaciones de datos durante las horas de menos actividad.

Nota:

Cuando las consultas en la réplica secundaria bloquean un subproceso de puesta al día, se genera el evento XEvent sqlserver.lock_redo_blocked .

Indización

Para optimizar las cargas de trabajo de solo lectura en réplicas secundarias legibles, tal vez desee crear índices en las tablas de las bases de datos secundarias. Debido a que no se pueden realizar cambios de esquema o de datos en las bases de datos secundarias, cree los índices en las bases de datos principales y permita que los cambios se transfieran a la base de datos secundaria mediante el proceso de puesta al día.

Para supervisar la actividad de uso de índices en una réplica secundaria, consulte las columnas user_seeks, user_scansy user_lookups de la vista de administración dinámica sys.dm_db_index_usage_stats .

Estadísticas de las bases de datos de acceso de solo lectura

Las estadísticas de las columnas de tablas y vistas indizadas se usan para optimizar los planes de consulta. Para los grupos de disponibilidad, las estadísticas que se crean y se mantienen en las bases de datos principales se conservan automáticamente en las bases de datos secundarias como parte de la aplicación de los registros de transacciones. No obstante, la carga de trabajo de solo lectura en las bases de datos secundarias puede necesitar estadísticas distintas de las que se crean en las bases de datos principales. Sin embargo, debido a que las bases de datos secundarias están restringidas al acceso de solo lectura, las estadísticas no se pueden crear en las bases de datos secundarias.

Para resolver este problema, la réplica secundaria crea y mantiene las estadísticas temporales para las bases de datos secundarias en tempdb. El sufijo _readonly_database_statistic se anexa al nombre de las estadísticas temporales para diferenciarlas de las estadísticas permanentes que se mantienen de la base de datos principal.

Solo SQL Server puede crear y actualizar las estadísticas temporales. No obstante, puede eliminar las estadísticas temporales y supervisar sus propiedades mediante las mismas herramientas que se usan para las estadísticas permanentes:

  • Elimine estadísticas temporales mediante la instrucción DROP STATISTICSde Transact-SQL.

  • Supervise las estadísticas con las vistas de catálogo sys.stats y sys.stats_columns . sys_stats incluye una columna, is_temporary, para indicar las estadísticas que son permanentes y las que son temporales.

No se permite la actualización de estadísticas automáticas para tablas con optimización de memoria en la réplica principal o secundaria. Debe supervisar el rendimiento de las consultas y planes en la réplica secundaria y actualizar manualmente las estadísticas de la réplica principal cuando sea necesario. Sin embargo, las estadísticas que faltan se crean automáticamente tanto en la réplica principal como en la secundaria.

Para obtener más información sobre las estadísticas de SQL Server, vea Estadísticas.

Estadísticas permanentes obsoletas en bases de datos secundarias

SQL Server detecta cuándo están obsoletas las estadísticas permanentes de una base de datos secundaria. Pero no se pueden realizar cambios en las estadísticas permanentes, excepto a través de los cambios en la base de datos principal. Para la optimización de consultas, SQL Server crea estadísticas temporales para tablas basadas en disco en la base de datos secundaria y usa estas estadísticas en lugar de las estadísticas en desuso permanentes.

Cuando las estadísticas permanentes se actualizan en la base de datos principal, se guardan automáticamente en la base de datos secundaria. A continuación SQL Server usa las estadísticas actualizadas permanentes, más actuales que las estadísticas temporales.

Si el grupo de disponibilidad conmuta por error, las estadísticas temporales se eliminan en todas las réplicas secundarias.

Limitaciones y restricciones

  • Debido a que las estadísticas temporales se almacenan en tempdb, el reinicio del servicio SQL Server provoca que desaparezcan todas las estadísticas temporales.

  • El sufijo _readonly_database_statistic está reservado para las estadísticas que genera SQL Server. Este sufijo no se puede usar al crear estadísticas en una base de datos principal. Para más información, consulte Estadísticas.

Obtener acceso a tablas optimizadas para memoria en una réplica secundaria

Los niveles de aislamiento de la carga de trabajo de lectura en la réplica secundaria son únicamente aquellos que se permiten en la réplica principal. En la réplica secundaria no se realizan asignaciones de niveles de aislamiento. De esta forma se garantiza que cualquier carga de trabajo de informes que se puede ejecutar en una réplica principal podrá ejecutarse en una réplica secundaria sin necesidad de realizar cambios. Esto facilita la migración de una carga de trabajo de informes desde la réplica primaria a una secundaria o viceversa cuando la réplica secundaria no está disponible.

Las siguientes consultas no se ejecutan correctamente en la réplica secundaria de forma similar a como ocurre en la réplica principal.

  • Para las consultas que se ejecutan solo en tablas optimizadas para memoria, los únicos niveles de aislamiento admitidos son instantánea, lectura repetible y serializable. Cualquier consulta con nivel de aislamiento de lectura no confirmada o lectura confirmada devuelve un error salvo que haya habilitado la opción MEMORY_OPTIMIZED_ELEVATE_TO_SNAPSHOT en el nivel de base de datos.

    SET TRANSACTION ISOLATION LEVEL READ_COMMITTED  
-- This is not allowed  
BEGIN TRAN  
SELECT * FROM t_hk  
COMMIT

    Mensaje de error:

    Msg 41368, Level 16, State 0, Line 2  
Accessing memory optimized tables using the CREAD_COMMITTED isolation level is supported only for autocommit transactions. It is not supported for explicit or implicit transactions. Provide a supported isolation level for the memory optimized table using a table hing, such as WITH (SNAPSHOT).

  • No se admiten sugerencias de bloqueo en tablas optimizadas para memoria. Por ejemplo, todas las consultas siguientes no se ejecutan correctamente y provocarán un error. Solamente se permite la sugerencia NOLOCK, que será NOOP cuando se utiliza con tablas optimizadas para memoria.

    SELECT * FROM t_hk WITH (PAGLOCK)  
SELECT * FROM t_hk WITH (READPAST)  
SELECT * FROM t_hk WITH (ROWLOCK)  
SELECT * FROM t_hk WITH (READPAST)  
SELECT * FROM t_hk WITH (TABLOCK)  
SELECT * FROM t_hk WITH (XLOCK)  
SELECT * FROM t_hk WITH (UPDLOCK)

  • En el caso de las transacciones entre contenedores, no se admiten transacciones con nivel de aislamiento de sesión "instantánea" que tienen acceso a tablas optimizadas para memoria. Por ejemplo,

    SET TRANSACTION ISOLATION LEVEL SNAPSHOT  
-- This is not allowed  
BEGIN TRAN  
   SELECT * FROM t_hk  
COMMIT

    Mensaje de error:

    Msg 41332, Level 16, State 0, Line 5  
Memory optimized tables and natively compiled stored procedures cannot be accessed or created when the session TRANSACTION ISOLATION LEVEL is set to SNAPSHOT.

Consideraciones de planeamiento de capacidad

  • En el caso de las tablas basadas en disco, las réplicas secundarias legibles pueden requerir espacio en tempdb por dos motivos:

    • El nivel de aislamiento de instantánea copia las versiones de fila en tempdb.

    • Se crean estadísticas temporales para las bases de datos secundarias y se mantienen en tempdb. Las estadísticas temporales pueden causar un ligero aumento del tamaño de tempdb. Para obtener más información, vea Estadísticas de las bases de datos de acceso de solo lectura, más adelante en esta sección.

  • Al configurar el acceso de lectura en una o varias réplicas secundarias, las bases de datos principales agregan 14 bytes de sobrecarga en las filas de datos eliminadas, modificadas o insertadas para almacenar punteros a versiones de fila en las bases de datos secundarias para tablas basadas en disco. Esta sobrecarga de 14 bytes se aplica a las bases de datos secundarias. A medida que se agrega la sobrecarga de 14 bytes a las filas de datos, se pueden producir divisiones de página.

    Las bases de datos principales no generan los datos de las versiones de fila. En su lugar, las bases de datos secundarias generan las versiones de fila. Sin embargo, el control de versiones de fila aumenta el almacenamiento de datos tanto en las bases de datos principales como en las secundarias.

    La adición de los datos de las versiones de fila depende del valor de nivel de aislamiento de instantánea o de aislamiento de instantánea de lectura confirmada (RCSI) en la base de datos principal. En la tabla siguiente se describe el comportamiento del control de versiones en una base de datos secundaria legible con configuraciones diferentes para las tablas basadas en disco.

    ¿Réplica secundaria legible? ¿Nivel de aislamiento de instantánea o de RCSI habilitado? Base de datos principal Base de datos secundaria
    No No Sin versiones de fila ni sobrecarga de 14 bytes Sin versiones de fila ni sobrecarga de 14 bytes
    No Sí Con versiones de fila y sobrecarga de 14 bytes Sin versiones de fila pero con sobrecarga de 14 bytes
    Sí No Sin versiones de fila pero con sobrecarga de 14 bytes Con versiones de fila y sobrecarga de 14 bytes
    Sí Sí Con versiones de fila y sobrecarga de 14 bytes Con versiones de fila y sobrecarga de 14 bytes

Related Tasks

Contenido relacionado

Consulte también

Información general de los grupos de disponibilidad AlwaysOn (SQL Server)
Acerca del acceso de conexión de cliente a réplicas de disponibilidad (SQL Server)
Agentes de escucha del grupo de disponibilidad, conectividad de cliente y conmutación por error de una aplicación (SQL Server)
estadísticas