I would do like this:
- Backup database
- Create new log file
- Run shrinkfile on the old database
- Set the Initial Size of old Log File to 1MB and Authogrowth to None.
You will have two log files, but one will have only 1 MB.
Hope it would help. I hope there is some better way to do that
Oh, the horror! Please stop telling people they should shrink their log files!
If you've gotten yourself in this situation, then one of the following cases is extremely likely:
- Your database is in full recovery mode, and it should really be in simple mode
- Your database is in full recovery mode, and you should be taking regular log backups
- Your database is in full recovery mode, and your log backups are failing for some reason
- You are running massively huge transactions that are blowing the log file up to massive sizes
The answer for each of these is as follows:
If (1), then switch the database to simple mode
If (2), then schedule regular log backups
If (3), then fix your scheduled log backups
If (4), then just don't do that :) Instead, do work in smaller batches.
Note that NONE of these require the use of the (deprecated) "backup log dbname with truncate_only"
Instead, once you do clear the log file using one of the above techniques, then shrink the (now empty) log with:
DBCC SHRINKFILE ('log logical name', 2000)
Always specify a reasonable final size, otherwise it'll shrink down to nearly 0, and the next time it is needed, will have to take the time to grow.
Best Answer
The short answer is "No, It's not recommended to shrink your log file(s)"
What is a solution is to run a full backup of your database, then detach your database, rename the log file to be something like database.ldf.old then reattach the database, without specifying the new location of the log file. This will create a new, empty log file.
The correct way to ensure that your log files do not grow excessively is to carry out regular backups of the transaction log. This is in addition to carrying out the regular full backups. This however, only applies if your database is using the Full recovery model. You can find which model it is using by right clicking on the database in Management Studio, then clicking on properties. Navigate to the options page and on that screen you will see the Collation Type, Recovery Model and Compatibility Level.
Unless you require the ability to restore to any point in time by replaying the transaction log to a specific transaction, using Simple recovery mode and ensuring that you backup your database regularly by doing a full backup will prevent your log file from growing excessively. It is also recommended that you have your log files on a separate volume (at a minimum) to stop a log file from possibly preventing login to your server (i.e. if it is on your boot partition, and fills the disk completely)