We can handle a performance hit.
This is also a one off as there was a new index created which caused a massive log file to be created. I need to shrink this file back down.
I just wanted to know if there were any risks running this command.
Sql Server 2005 database
Assuming you are talking about SQL Server 2000/2005, I do it on live databases with no issues.
I also shrink the trans log on active db's. It does only affect the inactive chunk of the transaction log.
Paul Randall has a pretty in depth thread here. There is also an article on his blog:
Is it safe to have SQL Server auto-shrink turned on?
Its not your exact question but does shed additional light on what/how DBCC SHRINKFILE works.
Also some pointers if your log doesn't shrink:
It's safe, but do it at a quiet time when there's low transactional activity. It's recommended to shrink the log to its minimal size and then grow it to its normal size (this will ensure the correct number of VLFs (internal virtual log files) are created, which improves performance for logged commands).
If the database's log doesn't shrink - if the database is in simple mode execute a checkpoint command first, if it's fully logged backup the log first.
If the log contains unprocessed mirrored or replication transactions then it may not shrink to a minimal size.
Remember to set an appropriate auto growth value.
See the following articles:
http://www.sqlskills.com/BLOGS/KIMBERLY/post/8-Steps-to-better-Transaction-Log-throughput.aspx
http://sqlblog.com/blogs/linchi_shea/archive/2009/02/09/performance-impact-a-large-number-of-virtual-log-files-part-i.aspx