So the items in Brent's answer should be investigated first: make sure you don't have some sort of larger issue that needs fixed a different way.
But once you have done so, it is absolutely possible you will determine that there is no ongoing issue, and that the excessive log growth was due to a problem that you've since resolved. For example:
- Logs grew due to a one-time runaway query by a developer, who has been sufficiently chastised.
- Logs grew due to a one-time problem with tran log backups, which have since been fixed
- Logs grew due a problem with replication, which has since been fixed
- Logs grew because databases were in Full recovery mode, but they should have been in Simple (restoring a prod db to a dev environment, for example)
In those cases, the large log file will be almost entirely empty, and it is absolutely fine to shrink the logs to a more appropriate size.
A few notes when you do:
- This should be a rare one-time operation, not something you do routinely. If you find yourself having to do this routinely, then check back with the items on Brent's list.
- Always do a SHRINK FILE, never a SHRINK DATABASE
- Shrinking data files is an entirely different matter, with serious performance implications. Don't do that, except in very rare, very carefully planned situations.
- Always shrink with a reasonable target size in mind, never shrink to recover all free space from a log, since it would just have to immediately regrow
- Make sure you understand the information about how VLF size impacts SQL performance discussed by Kimberly Tripp here and summarized by this DBA.SE post. In short, you might need to shrink your log down very small, and grow it in specific-sized increments.
- Make sure the log growth setting are appropriate (never use %, never a multiple of 4GB, keep expected VLF size considerations in mind).
Your target size will vary widely by the expected activity on the database. Especially with Simple mode, you certainly wouldn't need a log that is any larger than the used data space in the database.
Once you've understood all that, then simply shrink your log with a statement like the following:
DBCC SHRINKFILE (name = 'mydb_log', size = 2000)
Which will shrink the log file down to 2GB.
It is possible an active transaction may prevent it from shrinking down immediately. If so, wait for the transaction to complete and repeat the command later.
If you are doing this to a database in full recovery mode, you will likely have to shrink, then run the log backup, then shrink again to the target size.