When your transaction log grows large and you want a quick way to shrink it, try this option. Change the database recovery mode of the database you want to shrink from “full” to "simple," then truncate the log file by performing a full backup of the database, then switch back to the “full” recovery mode. By temporally changing from the Full recovery model to the Simple recovery mode, and then back, SQL Server will only keep the "active" portion of the log, which is very small. [7.0, 2000, 2005] Contributed by Tom Kitta. Updated 5-7-2007*****If you need to delete all the rows in a table, don't use DELETE to delete them, as the DELETE statement is a logged operation and can take a significant amount of time, especially if the table is large. To perform the same task much faster, use the TRUNCATE...

Almost from birth, database developers are taught that their databases must be normalized.  In many shops, failing to fully normalize can result in anything from public ridicule to exile to the company’s Siberian office.  Rarely discussed are the significant benefits that can accrue from intentionally denormalizing portions of a database schema.  Myths about denormalization abound, such as:A normalized schema is always more stable and maintainable than a denormalized one. The only benefit of denormalization is increased performance. The performance increases from denormalization aren’t worth the drawbacks. This article will address the first two points (I’ll tackle the final point in the second part of this series).  Other than for increased performance, when might you...