Check the data in the morning to find that there is only a few megabytes of hard disk space for a single piece of data. Habitual check log file, found that the log file unexpectedly increased to more than 350 GB
Back up the log first, then shrink-------no change. (In fact, the log backup every 1 hours 1 block, normal running.)
---------------------------------------------------------------------------
Check log space usage and cannot truncate cause:
DBCC SQLPERF (logspace) GO SELECT name,recovery_model_desc,log_reuse_wait,log_reuse_wait_ Desc from
You can see LOG_REUSE_WAIT_DESC as replication.
DBCC Loginfo () is executed under this library and you can see that all VLF states of the database are 2, which is the active state.
Dbcc
-----------------------------------------------------------------------
Find a solution to Zhao on the internet:
' XXXX '
In fact, this database has not been duplicated before. The server should not have changed the name, so the big trick is invalid.
-----------------------------------------------------------------------
Since it is not replication why LOG_REUSE_WAIT_DESC for replication?
The suspect was transferred to the CDC.
SELECTis_cdc_enabled, Case whenIs_cdc_enabled= 0 Then 'CDC feature disabled' ELSE 'CDC feature enabled'ENDDescription fromSYS. DATABASESWHERENAME= 'XXXX'
The library does open CDC and continues to check the health status of the CDC job:
Declare @Job_ID as uniqueidentifier Select @Job_ID = from where = ' CDC. Xxxx_capture'Exec@Job_ID
A return value of 4-Indicates completion (success or failure), in which case the CDC capture job should normally be 1 (running).
Determine the CDC. Xxxx_capture the job was aborted for some reason.
------------------------------------------------------------------------------------
at least the reason why the log can't be truncated is finally found .
Manually start CDC. Xxxx_capture. omit nnnn minute wait here (here to remind you that the hard disk space is not enough children's shoes, CDC capture also requires a lot of disk space OH!!! Free up enough hard disk space or create a new log file on the other disk .
Wait for the LOG_REUSE_WAIT_DESC state to change to Log_backup.
Shrink log after backup log succeeds! ~
finish the call.
LOG_REUSE_WAIT_DESC for replication, log burst, unable to shrink