Transaction log file increasing rapidly ?

You must have a great deal of transactions updating and or changing data consistently. You should do much more frequent backups. I would start with either 15 or 30 minutes. If you are already doing twice a day but it is growing to 50 GB in size, you need much more frequent backups. You should also read Kimberly's blog on virtual log files. You are probably having problems with tons of virtual log files and aren't even aware of it.

Hi Basit,

I think you should start some investigation of what is happening. Gail Shaw wrote a great article on ssc. Take a look: http://www.sqlservercentral.com/articles/Transaction+Logs/72488/

You should keep in mind that shrinking the log isn't best practice at all and should only be the last solution if there's no other way to solve a space problem.

Regards Dirk

It's hard to tell if 50GB transaction log is "large" or "small". It depends on your size of disks, your speed of disks, size of the data file(s) etc.

Use DBCC SQLPERF(logspace) to find out how much of the transaction log is actually used. If the transaction log is nearly full, you won't be able to shrink it either. (But you probably don't want to do that anyway)

If what's happening is that you have a large transaction log, back it up, shrink it and then it grows back to 50GB again in one day, I'd say you should either back it up more frequently or simply let it be 50GB. Otherwise your queries will perform poorly because the transaction log needs to auto grow all the time. (Plus you'll get a lot of virtual files, like Tim said).

check the recovery model of your database by using this command in ssms

select recovery_model_desc,name from sys.databases

for best practive to shrink a database, please cehck my blog http://sqlservr.blog.com/2012/06/26/best-practice-to-shrink-in-logldf-file-in-sql-server/

if your databse is in simple recovery mode then use

USE [dbname] GO DBCC SHRINKFILE (N'dbname_log' , 0)

to check for open transaction use dbcc opentran