REVISIÓN: Error 9002 y error 3052 al intentar agregar o realizar una copia de archivo de registro en SQL Server 2012

IMPORTANTE: Este artículo ha sido traducido por un software de traducción automática de Microsoft (http://support.microsoft.com/gp/mtdetails) en lugar de un traductor humano. Microsoft le ofrece artículos traducidos por un traductor humano y artículos traducidos automáticamente para que tenga acceso en su propio idioma a todos los artículos de nuestra base de conocimientos (Knowledge Base). Sin embargo, los artículos traducidos automáticamente pueden contener errores en el vocabulario, la sintaxis o la gramática, como los que un extranjero podría cometer al hablar el idioma. Microsoft no se hace responsable de cualquier imprecisión, error o daño ocasionado por una mala traducción del contenido o como consecuencia de su utilización por nuestros clientes. Microsoft suele actualizar el software de traducción frecuentemente.

Haga clic aquí para ver el artículo original (en inglés): 3095156
Síntomas
Supongamos que utiliza una base de datos de Microsoft SQL Server 2012 grupo disponibilidad AlwaysOn, y una gran transacción activa abierta existe y requiere un espacio adicional de registro. Cuando el archivo de registro no puede crecer para uno de los motivos siguientes, se produce un error en la transacción.
  • Falta de espacio de archivos adicional
  • El archivo de registro está configurado no para crecer
  • El archivo de registro alcanza el tamaño máximo configurado
Además, recibirá el siguiente mensaje de error:
Error: 9002, gravedad: 17, estado: 9.
El registro de transacciones para la base de datos 'nombre de la base de datos>' es completa debido a 'LOG_BACKUP'.
Después de ejecutar una copia de seguridad del registro, recibirá otro mensaje de error 9002:
Error: 9002, gravedad: 17, estado: 9.
El registro de transacciones para la base de datos 'nombre de la base de datos>' es completa debido a 'ACTIVE_TRANSACTION'.
Después de la otra copia de seguridad de registro, recibirá otro mensaje de error 9002 seguido de un mensaje de error 5901:
Error: 9002, gravedad: 17, estado: 9.
El registro de transacciones para la base de datos 'nombre de la base de datos>' es completa debido a 'AVAILABILITY_REPLICA'.

No se puede escribir un registro checkpoint en la base de datosnombre de la base de datos> porque el registro está fuera del espacio. Póngase en contacto con el Administrador de la base de datos para truncar el registro o asignar más espacio para los archivos de registro de la base de datos.
Error: 5901, gravedad: 16, estado: 1.
Una o más unidades de recuperación que pertenecen a la base de datos 'nombre de la base de datos>' no se pudo generar un punto de comprobación. Normalmente esto es causado por la falta de recursos del sistema como la memoria o el disco, o en algunos casos debido a daños en la base de datos. Examine las entradas anteriores del registro de errores para obtener más información sobre este error.
Cuando, a continuación, se toman las copias de seguridad de punto de comprobación o registro posteriores durante la reversión de la transacción, puede recibir el siguiente mensaje de error:
Msj 3052, nivel 16, estado 1, línea 4
BACKUP LOG no pudo iniciar las actualizaciones de base de datos 'nombre de la base de datos>'. Copias de seguridad posteriores de registro serán necesario para avanzar desde el punto de copia de seguridad 'Id. de LSN 1>' a 'Id. LSN 2>' después de espacio de registro estará disponible para registrarla.
Cuando reciba estos mensajes, ya no se pueda enviar las nuevas transacciones a la base de datos y no puede crecer el archivo de registro o agregar otro archivo de registro.

Solución
El problema se solucionó primero en la siguiente actualización acumulativa de SQL Server: Recomendación: Instale la actualización acumulativa más reciente para SQL Server
Cada nueva actualización acumulativa para SQL Server contiene todas las revisiones y todas las revisiones de la seguridad que se incluyeron en la actualización acumulativa anterior. Recomendamos que se descargue e instalación las actualizaciones acumulativas más recientes para SQL Server:
Solución
Puede utilizar la siguiente solución para truncar los registros y reanudar la actividad.
  1. Comprobar cada réplica secundaria para comprobar la segunda réplica last_hardened_lsn (consulte Sys.dm_hadr_database_replica_states) coincide con la réplica principal last_hardened_lsn. Puede hacerlo ejecutando la consulta siguiente que está conectada la instancia principal de réplica
    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>'
  2. En la réplica principal
    • Quite la base de datos del grupo de disponibilidad.
    • Volver a agregar la base de datos al grupo de disponibilidad.
  3. En cada réplica secundario
    • Volver a agregar la base de datos al grupo de disponibilidad.
Quitando la base de datos del grupo de disponibilidad se inmediatamente truncar los registros y liberar espacio en el registro.

Si el last_hardened_lsnen cada réplica secundaria es idéntica a la réplica principal y ningún registro se realizan durante el tiempo de quitar la base de datos del grupo de disponibilidad y volver a agregar la base de datos en cada secundario, la segunda réplica correctamente se vuelven a agregar sin errores o tener que restaurar copias de seguridad del registro en el servidor secundario.

Si una segunda réplica no está actualizada con la réplica principal y tendrá que quitar la base de datos del grupo de disponibilidad antes de que el servidor secundario puede ponerse al día, esa réplica secundaria puede tener que tener copias de seguridad de registro restaurados para ponerse antes de volver a agregarlo al grupo de disponibilidad o colocar en la segunda réplica y reinicializar la base de datos con una completa y copia de seguridad de base de datos de registro de transacciones.
Estado
Microsoft ha confirmado que se trata de un problema de los productos de Microsoft que se enumeran en la sección "Aplicable a".

Advertencia: este artículo se tradujo automáticamente

Propiedades

Id. de artículo: 3095156 - Última revisión: 09/22/2015 02:57:00 - Revisión: 1.0

Microsoft SQL Server 2012 Service Pack 2

  • kbqfe kbsurveynew kbfix kbexpertiseadvanced kbmt KB3095156 KbMtes
Comentarios