cbridgman
asked on
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.
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.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
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
If so, please mark the comment or comments that answered your question so this question can be closed properly.
Cheers
ASKER
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
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