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

question about backing up transaction logs

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
jamesmetcalf74
Asked:
jamesmetcalf74
3 Solutions
 
Vitor MontalvãoMSSQL Senior EngineerCommented:
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
 
Vitor MontalvãoMSSQL Senior EngineerCommented:
USE database
GO

DBCC SHRINKFILE(<log_file_name_Log>)

Open in new window

0
 
jamesmetcalf74Author Commented:
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
What does it mean to be "Always On"?

Is your cloud always on? With an Always On cloud you won't have to worry about downtime for maintenance or software application code updates, ensuring that your bottom line isn't affected.

 
jamesmetcalf74Author Commented:
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
 
Nakul VachhrajaniTechnical Architect, Capgemini IndiaCommented:
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
 
Eugene ZCommented:
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
 
Vitor MontalvãoMSSQL Senior EngineerCommented:
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
 
Scott PletcherSenior DBACommented:
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

Industry Leaders: 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