The only issue you will run into is that you now have broken the chain of your backups. That means that if for some reason the full backup that you have is no longer any good, you can not go to a full backup further back in time and roll the entire database forward. The process that you ran is something that should not be done with a production database. Relying on SQL Server to create a new log file by purposely blowing away the existing one is something that should only be attempted under VERY extreme circumstances since you are basically very lucky that the database even came back online.
The transaction log was NOT corrupt. Just because it will not shrink all the way does not mean you have a corrupt transaction log. If you had a corrupt transaction log, you would certainly know about it by your database going suspect. A shrink can only remove the unused portion of the transaction log. If there is data in there, it can't remove it. It will also only shrink to the last open transaction. So, if someone has left a transaction open, you can shrink the database over and over again and it will not remove any space beyond that. The correct process for doing this is to backup the transaction log and then shrink it. The backup removes any committed transactions from the log to your backup allowing the shrink to remove the maximum amount of space possible. It is still limited if there are open transactions. Detaching and reattaching a production database is something that is not recommended as a general practice.
For More Information
- Dozens more answers to tough SQL Server questions from Michael Hotek are available here.
- The Best Microsoft SQL Server Web Links: tips, tutorials, scripts, and more.
- Have a SQL Server tip to offer your fellow DBAs and developers? The best tips submitted will receive a cool prize. Submit your tip today!
- Ask your technical SQL Server questions -- or help out your peers by answering them -- in our live discussion forums.
- Ask the Experts yourself: Our SQL, database design, SQL Server, DB2, object-oriented and data warehousing gurus are waiting to answer your toughest questions.