Question Description:
A SharePoint site that corresponds to a database log is too big to thin the log. I then separated the entire database and then attached the database to regenerate the log file. Who knows at the time of attaching, unexpectedly error "Additional database error: Unable to regenerate log because the database is not completely shut down"
Cause of the problem: there is an open transaction/user when the database shuts down, the database does not have checkpoints, or the database is read-only. This error can occur if the transaction log files are manually deleted or lost due to hardware or environmental issues.
Treatment methods:
First, the separation of the log files are also copied over to attach it
From the error note, it should be that your log file also includes useful data that has not been correctly written back to the data file, resulting in additional failures.
Second, this situation is best to retrieve the previous log file, if not found, the workaround is to create a new database, set the database to offline, and then replace the data file of the new library with the attached failed data file, and then set the database as the Emergency Recovery mode, so that the data can be read in general
ALTER DATABASE db_name SET EMERGENCY
After the database can be read, you can try to set it to ONLINE mode, if successful, then DBCC CHECKDB once, confirm no problem
If you can't online, you probably have to create a new library and then take the data from the contingency mode library to the new library.
Special Note: The compression (shrinking) method should be used to handle this.
The SQL SERVER data log is too large, the disk has no space, and the recovery hangs after the database log is deleted directly.