Síntomas
Suponga que usa el grupo de disponibilidad AlwaysOn en una base de datos de Microsoft SQL Server 2012 o de SQL Server 2014 y hay una gran transacción activa abierta y requiere espacio de registro adicional. Cuando el archivo de registro no puede crecer por uno de los motivos siguientes, se produce un error en la transacción.
-
Falta de espacio adicional en el archivo
-
El archivo de registro está configurado para no crecer
-
El archivo de registro alcanzó su tamaño máximo configurado
Además, aparece un mensaje de error similar al siguiente:
Error: 9002, gravedad: 17, estado: 9. el registro de transacciones de la base de datos ' <nombre de base de datos> ' está lleno debido a "LOG_BACKUP".
Después de ejecutar una copia de seguridad del registro, recibe otro mensaje de error 9002:
Error: 9002, gravedad: 17, estado: 9. el registro de transacciones de la base de datos ' <nombre de base de datos> ' está lleno debido a "ACTIVE_TRANSACTION".
Después de otra copia de seguridad del registro, recibirá otro mensaje de error 9002 seguido de un mensaje de error 5901:
Error: 9002, gravedad: 17, estado: 9. el registro de transacciones de la base de datos ' <nombre de base de datos> ' está lleno debido a "AVAILABILITY_REPLICA".
No se pudo escribir un registro de control en la base de datos <nombre de la base de datos> porque el registro no tiene espacio suficiente. Póngase en contacto con el administrador de la base de datos para truncar el registro o asignar más espacio a los archivos de registro de la base de datos. Error: 5901, gravedad: 16, estado: 1. en una o más unidades de recuperación que pertenecen a la base de datos ' <nombre de base de datos> ' no se pudo generar un punto de control. Esto suele deberse a la falta de recursos del sistema, como el disco o la memoria, o en algunos casos debido a daños en la base de datos. Examine las entradas anteriores en el registro de errores para obtener información más detallada sobre este error.
Cuando se realicen las copias de seguridad del registro o el control subsiguientes durante la reversión de la transacción, es posible que reciba el siguiente mensaje de error:
Msj 3052, nivel 16, estado 1, line 4BACKUP LOG no pudo registrar las actualizaciones de la base de datos ' <nombre de base de datos '>. Las copias de seguridad del registro posteriores deberán avanzar en el punto de copia de seguridad desde ' <LSN ID 1> ' hasta ' <lsn ID 2> ' después de que el espacio de registro esté disponible para registrarlos.
Cuando reciba estos mensajes, ya no podrá enviar ninguna nueva transacción a la base de datos y no podrá ampliar el archivo de registro ni agregar otro archivo de registro.
Resolución
El problema se solucionó por primera vez en la siguiente actualización acumulativa de SQL Server:
Cada actualización acumulativa para SQL Server contiene todas las revisiones y todas las revisiones de seguridad incluidas en la actualización acumulativa anterior. Le recomendamos que descargue e instale las últimas actualizaciones acumulativas de SQL Server:
Solución alternativa
Puede usar la solución alternativa siguiente para truncar la actividad de registros y reanudar.
-
Compruebe cada réplica secundaria para comprobar que la réplica secundaria last_hardened_lsn (vea Sys.dm_hadr_database_replica_states) coincide con el last_hardened_lsnde réplica principal. Para ello, ejecute la consulta siguiente que está conectada a la instancia de la réplica principal.
SELECT ags.name as AGGroupName, ar.replica_server_name as InstanceName, hars.role_desc, db_name(drs.database_id)as DBName, drs.last_hardened_lsn, drs.log_send_queue_size, drs.synchronization_state_desc as SyncState, ar.availability_mode_desc as SyncMode, CASE drs.is_local WHEN 1 THEN drs.database_id ELSE NULL END as database_id FROM sys.dm_hadr_database_replica_states drs LEFT JOIN sys.availability_replicas ar ON drs.replica_id = ar.replica_id LEFT JOIN sys.availability_groups ags ON ar.group_id = ags.group_id LEFT JOIN sys.dm_hadr_availability_replica_states hars ON ar.group_id = hars.group_id and ar.replica_id = hars.replica_id WHERE db_name(drs.database_id) = '<database name>'
-
En la réplica principal
-
Quite la base de datos del grupo de disponibilidad.
-
Vuelva a agregar la base de datos al grupo de disponibilidad.
-
-
En cada réplica secundaria
-
Vuelva a agregar la base de datos al grupo de disponibilidad.
-
Al quitar la base de datos del grupo de disponibilidad, se truncarán inmediatamente los registros y se liberará espacio en el registro. Si el last_hardened_lsn en cada réplica secundaria es idéntico a la réplica principal, y no se toma ninguna copia de seguridad del registro durante el momento de quitar la base de datos del grupo de disponibilidad y vuelve a agregar la base de datos en cada secundario, la réplica secundaria se volverá a agregar correctamente sin ningún error ni tendrá que restaurar las copias de seguridad del registro en el secundario. Si una réplica secundaria no está actualizada con la réplica principal y tiene que quitar la base de datos del grupo de disponibilidad antes de que la secundaria pueda ponerse al día, esa réplica secundaria puede tener que restaurar las copias de seguridad del registro antes de volver a agregarlo al grupo de disponibilidad o quitar la base de datos de la réplica secundaria y reinicializarla con una copia de seguridad de la base
Estado
Microsoft ha confirmado que se trata de un problema de los productos de Microsoft enumerados en la sección "Se aplica a".
