suddedenly increased in size of Log files form 32GB to 70 GB [duplicate]

Question

This question already has answers here:

Why Does the Transaction Log Keep Growing or Run Out of Space? (4 answers)

Closed 3 years ago.

I am not DBA ,but I need to check on the size of database files . my database log files earlier was around 32 GB but from last few days it starts increasing and finally reached to 70 GB . first I thought it was natural , but soon I realized that I was wrong .

For shrinking the size of log file ,firstly I used to determine the % of space occupied in log file by using .

        DBCC SQLPERF(logspace)

Result was :- log size(MB) > 70 and Log Space Used > 94% with

          DBCC LOGINFO

I found more than 700 transactions having Status = '2'

After that I took "log as well as full backup" and run above query again but still got >700 transactions having Status = '2' detached and reattached , but still no difference in size .

Then I went for Shrinking log files and for testing purpose I gave the size 60GB . Then run following query again

   DBCC SQLPERF(logspace)

and result was :- log size(MB) > 66 and Log Space Used = 99.1258%.

Question is : How can I bring the size of log files near to earlier size i.e. around 32 GB or near by and how to keep check on it so that its size does not change dramatically .

** Recovery Mode :- FULL

Thanks in advance ....

Answer 1

A full database backup won't help your log size.

Full Recovery Model means "Can restore to any point in time." - including before that new database backup was taken.

Simple Recovery Model means "Can restore to the last database backup".

So... have a think about whether you need to restore to this morning or not (before your database backup). If you don't, then put your database into Simple Recovery Model, then back into Full. Then take a differential backup. Once you've done those three steps you will be able to recover to your last full database backup, the differential backup you just took, and any point in the future. Take regular log backups - try every ten-to-fifteen minutes.

And then look at your log. You should find it's mostly empty.

If not, look in sys.databases to see why it's not truncating. Other possible reasons include Replication that's broken, for example.

Answer 2

You can't shrink a full log, shrinking will only reclaim empty space and even then you should be very liberal in how you use the shrink feature.

The first thing I'd recommend checking is that your database is having transactional log backups taken as well as full backups. Full backups won't clear the transactional log. These allow point in time backups and the typical restore process will be the last full backup and then all subsequent transactional log backups up until the point you wish to restore to. You can also take differential backups which effectively group all database changes into one backup file so you don't need to restore all previous trans log backups but don't worry too much about that for now.

Of course if you don't need point in time recovery and a daily (or however regular your full backups are) backup is sufficient then you can just change your database recovery model to simple.

The other area to consider is if you use some form of replication to copy your data elsewhere for HA/DR purposes. This will also have to be copied across before a truncation of your trans log can take place. Therefore if you have for example Always On Availability Groups setup but they aren't replicating correctly then this will cause your log to fill.

Take a look through your configuration for the above and if you get stuck come back here.