The author then gave their solution to this problem as a way to resolve it:

Backup log [mydb] with truncate_only
go
DBCC SHRINKFILE (2)
go

The author then followed this up with a “so if you ever get this problem run this script and you’ll be fine”.

 Very dangerous script to run in a production environment.  While this may solve the “my log file is too big” problem if you run this script you are going to be breaking your LSN chain and all future log backups will fail until you take a full or differential backup. 

I know a few people have written articles (sorry I can’t find/link to any right now) about giving bad advice online and that anything you read should NOT be taken as gospel.  You just need to make sure if you’re going to use a solution that you’ve seen online that you make sure that for your environment it’s the right solution. 

The online community is a wonderful place and I fully endorse the sharing of information…but

Authors:  Make sure to do your best to properly illustrate when you should/shouldn’t use potentially dangerous scripts like the one above along with the corresponding risks

Readers:  Make sure that you fully understand the solutions provided by the online community before implementing them into your production environment

As Jerry Springer would say: “Take care of yourself and each other”

Enjoy!!