Si encuentras alguna parte que no entiendes puedes comentarlo y trataremos de ayudarte lo mas rápido que podamos.
Solución:
Primero, asegúrese de que la replicación no esté causando esto, como se indica en el elemento de conexión, “log_wait_reuse_desc=XTP_CHECKPOINT no significa necesariamente que el trabajador del punto de control XTP esté retrasando el truncamiento del registro”. así que empieza corriendo sp_repltrans y asegúrese de que todos los datos hayan sido distribuidos.
Luego está este pequeño fragmento aquí:
“Ocurre en una base de datos, que tiene un grupo de archivos optimizado para memoria, sin importar si tiene tablas optimizadas para memoria o no.
La solución actual es configurar AutoGrown para que tenga un tamaño fijo. O cambiar el modo de recuperación a Simple y reducir el registro”.
Entonces, si la limpieza de la replicación no funciona, intente lo siguiente:
checkpoint;
dbcc shrinkfile (Logfile, truncateonly)
alter database [database] modify file (filename = 'TRANSACTIONLOG', FILEGROWTH = 5MB)
No se indica si esto es para el archivo de registro o los archivos de la base de datos, pero comencemos probando los archivos de registro y, si no, intente configurar los archivos de la base de datos para un crecimiento fijo:
Tuve un problema similar: no tenía replicación, pero una vez que usé la tabla optimizada para memoria como prueba, la base de datos en modo de recuperación simple, pero mis registros de transacciones no se truncaron. El truncamiento manual, incluso justo después de una copia de seguridad completa, dio el error:
No se puede reducir el archivo de registro X porque el archivo de registro lógico ubicado al final del archivo está en uso.
Un punto de control manual falló:
Msg 41315, nivel 16, estado 4, la operación del punto de control de la línea N falló en la base de datos X.
Un punto de control manual solo tuvo éxito justo después de reiniciar el servicio SQL, lo que llevaría a un estado de recuperación de 4 horas debido al tamaño de mi base de datos Multi Tb. También traté de establecer el crecimiento automático en un tamaño específico, pero todo terminó haciendo lo mismo: llene los registros de transacciones hasta que no quede espacio.
Finalmente, después de días y noches de intentar e investigar, encontré la solución a mi problema al instalar la Actualización acumulativa 3 para SQL Server 2014 SP1.
Pude solucionar el problema agregando otro archivo de registro, que luego me permitió ejecutar una copia de seguridad completa, ajustar el tamaño del archivo de registro principal y limitar el crecimiento junto con la eliminación del archivo de registro adicional agregado para resolver el problema de XTP_CHECKPOINT.
Si te mola la invitación, eres capaz de dejar una sección acerca de qué te ha parecido esta reseña.