Hi all
Can someone put their finger on why my log file continues to grow event though I have a database backup and transaction log backup running nightly, the backup is then restored to a fresh training database.
The Recovery Model is Full (as far as I have been informed this cannot be changed to simple) as the database is being mirrored.
What is worse is that I'm positive this has been running successfully until recently some recently added maintenance tasks to reorganize indexes.
These are the scripts;
BACKUP DATABASE [Dynamics Nav 2009 LIVE] TO DISK = N'T:\SQL Log Backup LIVE\Dynamics Nav COPY.bak' WITH COPY_ONLY,
NOFORMAT,
INIT,
NAME = N'Dynamics Nav 2009 LIVE-Full Database Backup',
SKIP,
NOREWIND,
NOUNLOAD,
STATS = 10
GO
BACKUP LOG [Dynamics Nav 2009 LIVE] TO
DISK = N'T:\SQL Log Backup LIVE\LIVELog' WITH NOFORMAT, NOINIT,
NAME = N'Dynamics Nav 2009 LIVE-Transaction Log Backup', SKIP, NOREWIND, NOUNLOAD, STATS = 10
GO
Any help is appreciated
Life is for enjoying ... if you find yourself frowning you're doing something wrong
Answers
Also why COPY_ONLY?
What's the issue with COPY_Only? Is this causing the log not to truncate?
Is your log file growing simply because your daily transaction volume is increasing? How often do you run log backups?
There is a high transaction volume thus the need to have the log truncated each night.
To start with you should run log backups much more frequently. I would suggest at least every hour. If not sooner.
A log backup will only truncate the continuous inactive portion of the log. So it's not unusual for it to not clear the entire log. Especially in a very active system.
The system is not very active during the early morning, this is when the backup is scheduled so that should clear space in the log.
I have seen this;
http://stackoverflow.com/questions/646845/sql-server-2008-log-will-not-truncate-driving-me-crazy
It suggests this;
I'll try that in tonight's job
That's not big. :-$
Is there a way to pause the mirror service from T-SQL?
Since I don't know how your mirroring is configured, I'll avoid giving you recommendations in that area for now.
With this command, you can check WHY SQL Server cannot free the transaction log:
SELECT name,log_reuse_wait_desc
FROM sys.databases
WHERE log_reuse_wait_desc <> 'NOTHING'; -- nothing means Nothing is blocking the reusing of transactionlog space.
With this command, you can see how many virtual log files there are in your DB (you need to run it using the db you want to check):
DBCC LOGINFO;
It is also possible (I doubt this is your case) you have too few virtual log files in your transactionlog, log space can only be reused when your virtual log file is not used anymore.
No PM,please use the forum. || May the <SOLVED>-attribute be in your title!
FROM sys.databases
WHERE log_reuse_wait_desc <> 'NOTHING';
DBCC LOGINFO;
What am i looking for?
The second query tells me you have +- 187 VTL's (=Virtual Transaction Log files) in your transaction log. This is quite a lot but still acceptable (I have seen logfiles with over 20000 VLF's! => performance down the drain!).
So, the mirroring is not the problem. And neither is having to few VTL's.
Rereading your post, it seems you only do a transaction log backup at night.
To keep your transactionlog file used-% low, you need to do regular transaction log backups. Usually I do that every 15 minutes. Otherwise transaction log backups, full recovery model, mirroring have no sense.
Example : if someone (=developer) does a DELETEALL(FALSE) on your G/L Entry table. What do you do? Your mirror has lost the G/L entries too.
That is when regular transactionlog backups come into play : You can restore the DB up too a few minutes before the DELETEALL and lose very little transactions that have to be redone again instead of taking the backup of last night.
PS: "SQL Enterprise Manager". I suppose you mean SQL Server Management Studio because the Enterprise manager existed until SQL2000.
BTW: about the COPY_ONLY : what bbrown says is true : get rid of it in your backup strategy. It is to be used if you do a full backup that is completely out of the backup plan to avoid SQL uses it to propose a restore plan (=which backups to restore). In your case, you would need the VERY FIRST full backup without the "COPY_ONLY" and all transaction log backup after that to restore a database up to a few minutes ago.
About the NOREWIND and NOUNLOAD : those don't do anything for disk-backups but why dirten your backup command with those?
No PM,please use the forum. || May the <SOLVED>-attribute be in your title!
Does this mean there is a stuck job somewhere locking the transaction log?
No. You just need to do log backups during the day. Like I said: generally I implement it at customers to do a logbackup every 15 minutes. And if the database is communicating with another database in real time, I even go down to 10 and 5 minutes on both databases.
If something happens on 1 of the databases, it generally is a big problem to get them back in sync. With those very often TL backups, it gets easier.
No PM,please use the forum. || May the <SOLVED>-attribute be in your title!
I will start to truncate the log more frequently (good advice there guys) every hour to start with to make sure there is no impact on performance.
Many thanks guys