• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 114
  • Last Modified:

SQL Server Log File Space

I am somewhat of a novice SQL Server user and have some general questions about SQL Server log (.ldf) files. When I create a database in Management Studio (SQL Server 2012), 2 files are automatically created - a data file (.mdf) and a log file (.ldf). My database is now quite large as I have imported millions of rows into it. The data file is approximately 45 GB. The log file is about the same size. What I don't understand is why the log file is as big as the data file and whether there is a way to significantly reduce it. I've tried shrinking it but that only gives back about 8% of the space.

I guess I really don't understand a log file's purpose. I thought it was built to ensure that a database would be "rolled back" to a starting point if a big import query failed three fourths of the way through. If that is what a log file is for, why do they have to stick around after the query runs successfully?

Maybe that's really not their purpose at all.

Can someone help me to better understand them? i've read a few things that I've found on the web but most of them are over my head.

Thanks in advance for your help.
0
cbridgman
Asked:
cbridgman
2 Solutions
 
Daniel JonesData Research AnalystCommented:
Transaction log file records all transactions and the database modifications made by each transaction. Internally it is split into the smaller parts called Virtual Log Files (VLFs)

If there is a system failure, you will need that log to bring your database back to a consistent state. Never delete or move this log unless you fully understand the ramifications of doing this.

Log record can deleted from the transaction log if:
> Transaction of which it is part has committed
> Database pages it changed have all been written to disk by a checkpoint
> Log record is not needed for a backup (full, differential, or log)
> Log record is not needed for database mirroring or transaction replication

One command that is extremely helpful in understanding how much of the transaction log is being used is DBCC SQLPERF(logspace).  This one command will give you details about the current size of all of your database transaction logs as well as the percent currently in use.

The transaction log must be truncated regularly to keep it from filling! Some factors can delay log truncation, so monitoring log size matters. Some operations can be minimally logged to reduce their impact on transaction log size.

Your goal with transaction log maintenance should be to maintain it a a reasonable size. You do this by frequently backing up the log. Once you have log backups set up and running, then do a ONE-TIME shrink of the log file to a reasonable size using DBCC SHRINKFILE.

The reason you don't want to shrink the log file repeatedly is:
> Log file growths require locking the log file. This means that all running queries have to be paused.
> Repeatedly shrinking and auto-growing log files causes a high number of Virtual Log Files  which can drastically affect performance of any activity that scans the log file

SQL Server recovery models is critical to this log file growth problem
0
 
Vitor MontalvãoMSSQL Senior EngineerCommented:
My database is now quite large as I have imported millions of rows into it. The data file is approximately 45 GB. The log file is about the same size.
That's because the database recovery model for your database is set to Full Recovery Model.
With this type of recovery model it will require that you perform a transaction log backup regularly to truncate the logs and keep the file small.
If you are new to SQL Server then the best way is to create a Maintenance Plan using the wizard.
0
 
Scott PletcherSenior DBACommented:
You need to decide which recovery model you want to operate the db under.

In FULL (or BULK-LOGGED) mode, you can recover to any point in time, but you must back up the log file periodically and keep those backups.

In SIMPLE mode, you can only recover to full or differential backup points, but you do not have to back up the log file.

Which to use is primarily a business decision, since either is doable in technical terms.

For now, determine what the current recovery model is, and what is keeping the existing trans log from truncating, if anything.  If "NOTHING", then you can shrink the log file.  The "is...on" columns are just to allow you to also verify that both are 0/OFF; if either is on, you need to turn it off immediately.

SELECT name, recovery_model_desc, log_reuse_wait_desc, compatibility_level, is_auto_close_on, is_auto_shrink_on
FROM sys.databases
WHERE name = 'your_db_name'

--DBCC SHRINKFILE(2, 8192) /*shrink (primary) log file to 8GB*/
0
 
Vitor MontalvãoMSSQL Senior EngineerCommented:
cbridgman, is your question answered?
If so, please mark the comment or comments that answered your question so this question can be closed properly.
Cheers
0
 
cbridgmanAuthor Commented:
Thanks for everyone's help on this. Sorry for the delay in closing this. It kind of got pushed to the bottom of the pile and I forgot about the question. At the end of the day, however, choosing simple recovery did the trick for us. With the database that I was referring to we really had no need for anything more than the ability to recover to the most recent backup
0

Featured Post

Independent Software Vendors: We Want Your Opinion

We value your feedback.

Take our survey and automatically be enter to win anyone of the following:
Yeti Cooler, Amazon eGift Card, and Movie eGift Card!

Tackle projects and never again get stuck behind a technical roadblock.
Join Now