Trans log backup based on size rather than time?

[aj]

SQL Server SP2 9.0.3042 64-bit

I recently put my first SQL Server DB in production. In the "other"
database that I use (not interested in any arguments), you can indicate
the desired size of your transaction logs. When the current log reaches
that size, it gets backed up (or whatever you have configured to
happen). Certain events in the database might cause the logs to get
prematurely "cut" at a particular time, but the logs are for the most
part a consistent size.

In SQL Server, it looks as if the notion of transaction log backup is
based on /time/ rather than log size. When I use Maintenance Plans to
create a log backup plan, it wants to know WHEN to back the log up.

When the I/O in the database is not consistent, this can make the size
of your logs vary quite a bit. For example, on Sundays, when my
database is fairly quiet, I see /really/ small transaction log backups..

This leads to a few questions:
1. Is it possible to back up SQL Server transaction logs based on size
rather than time?
2. Even if there is, is this a good idea?
3. Is there another method to back up transaction logs other than maint
plans/Agent? Perhaps one that uses size as its determination?

Any help/thoughts appreciated.

cheers
aj

[Erland Sommarskog]

aj (ro****@mcdonal ds.com) writes:

In SQL Server, it looks as if the notion of transaction log backup is
based on /time/ rather than log size. When I use Maintenance Plans to
create a log backup plan, it wants to know WHEN to back the log up.

When the I/O in the database is not consistent, this can make the size
of your logs vary quite a bit. For example, on Sundays, when my
database is fairly quiet, I see /really/ small transaction log backups..

Well, it is a good idea to ask yourself *why* you take transaction log
backups. If the only reason is to keep the transaction log down in
size, you should consider simple recovery.

The normal reason to backup the transaction log is to be able to
restore to a point in time in case of a catastrophic failure. It may
be a quiet day in terms of transaction log growth, but 1000 new orders
were inserted and then your log disk goes capoot. If the data disk
fails, you can still back up the translog, but if the log disk you
are in trouble. And since it was a quite day, you find that the
log-size threshold you set up was never reached, and those 1000 orders
are lost.

I think the question most businesses ask is: how many minutes of data can
we afford to lose in case of a failure?

This leads to a few questions:
1. Is it possible to back up SQL Server transaction logs based on size
rather than time?

You could set up an Agent job that checks the log size, and goes to
sleep again if the limit has not been exceeded. But that's a more complex
operation that just backing up the transaction log in the first place.

2. Even if there is, is this a good idea?

No.

3. Is there another method to back up transaction logs other than maint
plans/Agent? Perhaps one that uses size as its determination?

Well, you can use Windows Task Scheduler, if you dislike Agent for some
reason. You could also define a startup procedure that perfoms:

WHILE 1 = 1
BEGIN
WAITFOR DELAY '00:10:00'
BACKUP LOG db TO ...
END

Whatever, since log backups should be taken regularly, there is all
reason to schedule them. But you don't need maintenenance plans. The
advantage with maintenance plans is that the name the files uniquely,
and delete them after a while. If you were to run BACKUP LOG directly
from an Agent job, you would have to cater for this yourself. Then
again, that is not exactly rocket science.

SQL Server SP2 9.0.3042 64-bit

Beware! There is a very serious bug with maintenance plans in that version
which causes DBCC CHECKDB to run in the same database when you schedule
it for many.

Get hold of version 9.0.3073 which is publically available. It also includes
two security fixes, whereof one looks quite serious.

--
Erland Sommarskog, SQL Server MVP, es****@sommarsk og.se

Links for SQL Server Books Online:
SQL 2008: http://msdn.microsoft.com/en-us/sqlserver/cc514207.aspx
SQL 2005: http://msdn.microsoft.com/en-us/sqlserver/bb895970.aspx
SQL 2000: http://www.microsoft.com/sql/prodinf...ons/books.mspx

[aj]

Erland Sommarskog wrote:

aj (ro****@mcdonal ds.com) writes:

>In SQL Server, it looks as if the notion of transaction log backup is
based on /time/ rather than log size. When I use Maintenance Plans to
create a log backup plan, it wants to know WHEN to back the log up.

When the I/O in the database is not consistent, this can make the size
of your logs vary quite a bit. For example, on Sundays, when my
database is fairly quiet, I see /really/ small transaction log backups..

Well, it is a good idea to ask yourself *why* you take transaction log
backups. If the only reason is to keep the transaction log down in
size, you should consider simple recovery.

No - I take log backups for disaster recovery. I live in SW Florida.
Disaster Recovery is a /very/ big part of my professional life.. :(

The normal reason to backup the transaction log is to be able to
restore to a point in time in case of a catastrophic failure. It may
be a quiet day in terms of transaction log growth, but 1000 new orders
were inserted and then your log disk goes capoot. If the data disk
fails, you can still back up the translog, but if the log disk you
are in trouble. And since it was a quite day, you find that the
log-size threshold you set up was never reached, and those 1000 orders
are lost.
I think the question most businesses ask is: how many minutes of data can
we afford to lose in case of a failure?

Good points. So the way to look at is: If I take log backups every 60
minutes, and the database crashes 58 minutes into the hour, I will lose
any transactions in those 58 minutes? If I take log backups every 60
minutes, I could (or would?) lose 59 minutes of transactions?

Doesn't SQL Server have some form of what my other db calls an active
log (not an archived log), which is rolled forward during subsequent
crash recovery, and would decrease that 58 minutes of lost work to
something less than 58 minutes?

>This leads to a few questions:
1. Is it possible to back up SQL Server transaction logs based on size
rather than time?

You could set up an Agent job that checks the log size, and goes to
sleep again if the limit has not been exceeded. But that's a more complex
operation that just backing up the transaction log in the first place.

Yes, I actually thought about that myself. It does seem a lot more
complex, tho..

>2. Even if there is, is this a good idea?

No.

>3. Is there another method to back up transaction logs other than maint
plans/Agent? Perhaps one that uses size as its determination?

Well, you can use Windows Task Scheduler, if you dislike Agent for some
reason. You could also define a startup procedure that perfoms:

WHILE 1 = 1
BEGIN
WAITFOR DELAY '00:10:00'
BACKUP LOG db TO ...
END

Whatever, since log backups should be taken regularly, there is all
reason to schedule them. But you don't need maintenenance plans. The
advantage with maintenance plans is that the name the files uniquely,
and delete them after a while. If you were to run BACKUP LOG directly
from an Agent job, you would have to cater for this yourself. Then
again, that is not exactly rocket science.

No - I have no dislike for Agent. Actually, I think its pretty cool.
I just wanted to make sure I was not missing something..

>SQL Server SP2 9.0.3042 64-bit

Beware! There is a very serious bug with maintenance plans in that version
which causes DBCC CHECKDB to run in the same database when you schedule
it for many.

Great info. Is the bug only in 64 bit? Is there a KB number?

Get hold of version 9.0.3073 which is publically available. It also includes
two security fixes, whereof one looks quite serious.

Thanks.

cheers
aj

[Roy Harvey (SQL Server MVP)]

On Wed, 15 Oct 2008 09:55:45 -0400, aj <ro****@mcdonal ds.comwrote:

>Good points. So the way to look at is: If I take log backups every 60
minutes, and the database crashes 58 minutes into the hour, I will lose
any transactions in those 58 minutes? If I take log backups every 60
minutes, I could (or would?) lose 59 minutes of transactions?

Doesn't SQL Server have some form of what my other db calls an active
log (not an archived log), which is rolled forward during subsequent
crash recovery, and would decrease that 58 minutes of lost work to
something less than 58 minutes?

If the disk where the transaction log is stored is intact, then it is
possible to recover the data from the log that was not backed up as
part of the recovery. See Books Online for details.

Roy Harvey
Beacon Falls, CT

[Erland Sommarskog]

aj (ro****@mcdonal ds.com) writes:

Doesn't SQL Server have some form of what my other db calls an active
log (not an archived log), which is rolled forward during subsequent
crash recovery, and would decrease that 58 minutes of lost work to
something less than 58 minutes?

If the disk where the database files reside goes belly up, you can backup
tha active portion of the log, no sweat.

But if the disk where the log file dies, you are in dire straits if your
log backup is old. Yes, the database file is there, but there is a big
but: you don't know which state it is in. It may include half-baked
transactions and could be corrupt on both user level and internal level.

>>This leads to a few questions:

Beware! There is a very serious bug with maintenance plans in that
version which causes DBCC CHECKDB to run in the same database when you
schedule it for many.

Great info. Is the bug only in 64 bit? Is there a KB number?

As far as I now, the bug is bit-agnostic. The is
http://support.microsoft.com/?kbid=934458.

--
Erland Sommarskog, SQL Server MVP, es****@sommarsk og.se

Links for SQL Server Books Online:
SQL 2008: http://msdn.microsoft.com/en-us/sqlserver/cc514207.aspx
SQL 2005: http://msdn.microsoft.com/en-us/sqlserver/bb895970.aspx
SQL 2000: http://www.microsoft.com/sql/prodinf...ons/books.mspx

[BIGsql]

I always think of my recovery model and backup strategy in terms of
Recovery Time and Recovery Point Objctives (RTO, RPO), i.e. how long
can the business live without this database and how much data can they
lose? This pretty much dictates what you have to do.