0

There is a production database ~1T, and ~200GB of log file unused space, simple recovery mode. I want it to restore at test environment and get rid of those 200GB log file to free up space for other DBs restores. What I tried:

  1. Backup DB at production
  2. Kill connections and restore DB (with recovery and replace) at test target VM
  3. Clean up replication of restored database
  4. Shrink DB DBCC SHRINKFILE (N'MyLogFile',1) of restored database

The process above is automated, so I can't run many checks during the process.

The step 4 fails with an error: Cannot shrink log file 2 (MyLogFile) because the logical log file located at the end of the file is in use.

Questions:

  1. Can this be because the database has transactional replication enabled, although I clean up replication at step 3.
  2. Do I actually need shrink of the logs, may would be enough just leave it after restored, and simple recovery mode checkpoints will do log backups (and decrease log file unused space) automatically?
NewUser
  • 11
  • 1

1 Answers1

0

The transaction log is a circular buffer containing several virtual log files. The error you're receiving occurs when the vlf actively in use is at the end of the physical file. Shrinking the log file can only release space that is not in use by an active vlf. If the log file is 300 GB, and the 50GB in use is at the end of the file, you can't shrink it.

Generate enough DB activity and you'll move past the vlf at the end and back to a vlf at the beginning, switch to simple recovery or take a log backup, then you can truncate the log.

You can generate some bogus activity like this: select * into Temp_ClearTheLog from BigTable; DELETE from Temp_ClearTheLog;

StrayCatDBA
  • 2,173
  • 16
  • 23