Solved

question about backing up transaction logs

Posted on 2016-09-09
8
62 Views
Last Modified: 2016-09-13
I have a database that has a transaction log that has gotten really large.  The database is in full recovery model.
I ran the backup transaction log maintenance plan on this log file twice.
the first time.  it created a backup file that was appropriate and large.

I go back to see the log file hoping that is has shrunk and it has not.

i run the maintenance plan again for grins.
this time the bak file for this transaction log is only a couple hundred kb which would indicate to me that the transaction log is small

i go back to the transaction log and it is still huge.........

Can someone give me some insight on this.
0
Comment
Question by:jamesmetcalf74
8 Comments
 
LVL 45

Expert Comment

by:Vitor Montalvão
Comment Utility
Backup transaction log doesn't shrink it. It only empties the file by truncating the log. You'll need to perform a Shrink operation ONLY on the transaction log file to get it shrunk.
0
 
LVL 45

Expert Comment

by:Vitor Montalvão
Comment Utility
USE database
GO

DBCC SHRINKFILE(<log_file_name_Log>)

Open in new window

0
 

Author Comment

by:jamesmetcalf74
Comment Utility
Ok i did that through management studio... the shrink file.  and it shrunk it to 8 gigs from 13
which is better but...
the db mdf file itself is only 4 gigs.

shouldnt it be closer to ten percent of the mdf file size?
0
 

Author Comment

by:jamesmetcalf74
Comment Utility
so i ran the cmd you suggest this time and the results are

currentsize  991960   minimumsize 47985   usedpages 991960  estimatedpages 47984

after completion of the shrinkfile command, it is still 8 gigs
0
What Security Threats Are You Missing?

Enhance your security with threat intelligence from the web. Get trending threat insights on hackers, exploits, and suspicious IP addresses delivered to your inbox with our free Cyber Daily.

 
LVL 11

Accepted Solution

by:
Nakul Vachhrajani earned 250 total points
Comment Utility
The internal space within the log files will not be freed up even with log backups if there are factors that prevent cleanup of the log (e.g. replication, mirroring, etc).

Do you have any such integration/interface that is not working right now? It is probably stopping the log from freeing up.

Here the documentation on various things that can prevent a transaction log from opening up space for use: https://technet.microsoft.com/en-us/library/ms345414(v=sql.105).aspx
0
 
LVL 42

Assisted Solution

by:EugeneZ
EugeneZ earned 125 total points
Comment Utility
run sp_who2 (or DMV code) and see what is running against your DB ..
---

<I ran the backup transaction log maintenance plan on this log file twice.>

it sounds you do not need point-of-time recovery
so switch to Simple recovery DB - shrink trans log ( see above posts)
and set  Differential backup additionally to full backup as needed.

in case you need DB be in the Full recovery  -- you should review the transactions (long running code); indexes sizes ( reindex can take some space)
and run trans log backup at least every 30 mins - (based on your DB activities).

--
for Full recovery - you can try (if you can) switch DB to Simple - shrink trans log -> switch back to FULL-> do Full backup -> set regularly running trans log
0
 
LVL 45

Expert Comment

by:Vitor Montalvão
Comment Utility
after completion of the shrinkfile command, it is still 8 gigs
This is the size for all database or only for the transaction log file?
0
 
LVL 69

Assisted Solution

by:ScottPletcher
ScottPletcher earned 125 total points
Comment Utility
FIrst you need to determine if anything is preventing the log file from being fully truncated:

SELECT name, log_reuse_wait_desc
FROM sys.databases
WHERE name = '<db_name>'

What you want to see in the log reuse column is "NOTHING".

Assuming it is nothing, you just need to shrink the existing log file.

The complication is that:
1) the log is written sequentially, from start to end, and then wraps around and repeats;
2) current, active log writes could thus occur at any physical point in the file;
3) SQL can only free space from after the current active point of the log.

OK, so, say you have an 8GB log file.  If SQL is current writing within that last gig, you can't shrink the log any further.  Checkpoints can also help free otherwise active log records.

Thus, the way to really shrink the log is to:
1) wait a while for the log to move to a different physical location near the start of the log file;
2) issue a CHECKPOINT;
3) try the shrink again.

USE [db_name];
--WAITFOR DELAY '00:02:00' --wait 2 minutes
CHECKPOINT;
DBCC SHRINKFILE(2, 4096);

If you want to see exactly what spot(s) is(are) active in the log, you can use this command:
DBCC LOGINFO
the row(s) with status>0 are active.
0

Featured Post

IT, Stop Being Called Into Every Meeting

Highfive is so simple that setting up every meeting room takes just minutes and every employee will be able to start or join a call from any room with ease. Never be called into a meeting just to get it started again. This is how video conferencing should work!

Join & Write a Comment

When you hear the word proxy, you may become apprehensive. This article will help you to understand Proxy and when it is useful. Let's talk Proxy for SQL Server. (Not in terms of Internet access.) Typically, you'll run into this type of problem w…
This article explains how to reset the password of the sa account on a Microsoft SQL Server.  The steps in this article work in SQL 2005, 2008, 2008 R2, 2012, 2014 and 2016.
Via a live example, show how to backup a database, simulate a failure backup the tail of the database transaction log and perform the restore.
Via a live example, show how to setup several different housekeeping processes for a SQL Server.

772 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question

Need Help in Real-Time?

Connect with top rated Experts

11 Experts available now in Live!

Get 1:1 Help Now