Large transaction log backups

Hi everyone,
I'm currently running sql 2k with sp3 on win2k with sp4.
I have a maintenance job set up to back up the transaction
logs every four hours every day. I also have it checked
to retain the files for only one day. Afer some intense
nightly jobs, the morning tran log backup can be over 4GB
in size. The problem is not backing up the log to file,
it's the clean-up that's supposed to happen afterwards.
After the tran backup is complete, sql server is supposed
to delete the older tran log backup file from the previous
day, but it always fails to delete the older tran log
backup when it's over 4GB in size. It marks the job as
failed, but the backup finishes so it's not that big a
deal. Is this a known bug or is there something else I'm
missing?
I know I could back up the tran logs more often to reduce
size, but I'm doing log shipping using a custom script and
I'd rather not have 20+ logs to script and ship.
LeonLeon,
First, you might be able to get the size of the log backup down. If the size
is caused by reindexing, perhaps DBCC INDEXDEFRAG will help? Of perhaps
bulk-logged recovery mode? Things you can play with...
As for backup files not being deleted. Perhaps below might help? It is my
"canned" answered for that topic:
Below KB might help:
http://support.microsoft.com/defaul...2&Product=sql2k
Also, check out below great troubleshooting suggestions from Bill H at MS:
-- Log files don't delete --
This is likely to be either a permissions problem or a sharing violation
problem. The maintenance plan is run as a job, and jobs are run by the
SQLServerAgent service.
Permissions:
1. Determine the startup account for the SQLServerAgent service
(Start|Programs|Administrative tools|Services|SQLServerAgent|Startup). This
account is the security context for jobs, and thus the maintenance plan.
2. If SQLServerAgent is started using LocalSystem (as opposed to a domain
account) then skip step 3.
3. On that box, log onto NT as that account. Using Explorer, attempt to
delete an expired backup. If that succeeds then go to Sharing Violation
section.
4. Log onto NT with an account that is an administrator and use Explorer to
look at the Properties|Security of the folder (where the backups reside)
and ensure the SQLServerAgent startup account has Full Control. If the
SQLServerAgent startup account is LocalSystem, then the account to consider
is SYSTEM.
5. In NT, if an account is a member of an NT group, and if that group has
Access is Denied, then that account will have Access is Denied, even if
that account is also a member of the Administrators group. Thus you may
need to check group permissions (if the Startup Account is a member of a
group).
6. Keep in mind that permissions (by default) are inherited from a parent
folder. Thus, if the backups are stored in C:\bak, and if someone had
denied permission to the SQLServerAgent startup account for C:\, then
C:\bak will inherit access is denied.
Sharing violation:
This is likely to be rooted in a timing issue, with the most likely cause
being another scheduled process (such as NT Backup or Anti-Virus software)
having the backup file open at the time when the SQLServerAgent (i.e., the
maintenance plan job) tried to delete it.
1. Download filemon and handle from www.sysinternals.com.
2. I am not sure whether filemon can be scheduled, or you might be able to
use NT scheduling services to start filemon just before the maintenance
plan job is started, but the filemon log can become very large, so it would
be best to start it some short time before the maintenance plan starts.
3. Inspect the filemon log for another process that has that backup file
open (if your lucky enough to have started filemon before this other
process grabs the backup folder), and inspect the log for the results when
the SQLServerAgent agent attempts to open that same file.
4. Schedule the job or that other process to do their work at different
times.
5. You can use the handle utility if you are around at the time when the
job is scheduled to run.
If the backup files are going to a \\share or a mapped drive (as opposed to
local drive), then you will need to modify the above (with respect to where
the tests and utilities are run).
Finally, inspection of the maintenance plan's history report might be
useful.
Thanks,
Bill Hollinshead
Microsoft, SQL Server
Tibor Karaszi, SQL Server MVP
Archive at:
http://groups.google.com/groups?oi=...ublic.sqlserver
"Leon" <anonymous@.discussions.microsoft.com> wrote in message
news:1320001c3f6f9$e945c820$a601280a@.phx
.gbl...
> Hi everyone,
> I'm currently running sql 2k with sp3 on win2k with sp4.
> I have a maintenance job set up to back up the transaction
> logs every four hours every day. I also have it checked
> to retain the files for only one day. Afer some intense
> nightly jobs, the morning tran log backup can be over 4GB
> in size. The problem is not backing up the log to file,
> it's the clean-up that's supposed to happen afterwards.
> After the tran backup is complete, sql server is supposed
> to delete the older tran log backup file from the previous
> day, but it always fails to delete the older tran log
> backup when it's over 4GB in size. It marks the job as
> failed, but the backup finishes so it's not that big a
> deal. Is this a known bug or is there something else I'm
> missing?
> I know I could back up the tran logs more often to reduce
> size, but I'm doing log shipping using a custom script and
> I'd rather not have 20+ logs to script and ship.
> Leon|||Tibor,
Thanks a bunch for the article and the suggestions from
Bill.
Leon

>--Original Message--
>Leon,
>First, you might be able to get the size of the log
backup down. If the size
>is caused by reindexing, perhaps DBCC INDEXDEFRAG will
help? Of perhaps
>bulk-logged recovery mode? Things you can play with...
>As for backup files not being deleted. Perhaps below
might help? It is my
>"canned" answered for that topic:
>Below KB might help:
>http://support.microsoft.com/default.aspx?scid=kb;en-
us;303292&Product=sql2k
>
>Also, check out below great troubleshooting suggestions
from Bill H at MS:
>
>-- Log files don't delete --
>This is likely to be either a permissions problem or a
sharing violation
>problem. The maintenance plan is run as a job, and jobs
are run by the
>SQLServerAgent service.
>Permissions:
>1. Determine the startup account for the SQLServerAgent
service
>(Start|Programs|Administrative
tools|Services|SQLServerAgent|Startup). This
>account is the security context for jobs, and thus the
maintenance plan.
>2. If SQLServerAgent is started using LocalSystem (as
opposed to a domain
>account) then skip step 3.
>3. On that box, log onto NT as that account. Using
Explorer, attempt to
>delete an expired backup. If that succeeds then go to
Sharing Violation
>section.
>4. Log onto NT with an account that is an administrator
and use Explorer to
>look at the Properties|Security of the folder (where the
backups reside)
>and ensure the SQLServerAgent startup account has Full
Control. If the
>SQLServerAgent startup account is LocalSystem, then the
account to consider
>is SYSTEM.
>5. In NT, if an account is a member of an NT group, and
if that group has
>Access is Denied, then that account will have Access is
Denied, even if
>that account is also a member of the Administrators
group. Thus you may
>need to check group permissions (if the Startup Account
is a member of a
>group).
>6. Keep in mind that permissions (by default) are
inherited from a parent
>folder. Thus, if the backups are stored in C:\bak, and if
someone had
>denied permission to the SQLServerAgent startup account
for C:\, then
>C:\bak will inherit access is denied.
>Sharing violation:
>This is likely to be rooted in a timing issue, with the
most likely cause
>being another scheduled process (such as NT Backup or
Anti-Virus software)
>having the backup file open at the time when the
SQLServerAgent (i.e., the
>maintenance plan job) tried to delete it.
>1. Download filemon and handle from www.sysinternals.com.
>2. I am not sure whether filemon can be scheduled, or you
might be able to
>use NT scheduling services to start filemon just before
the maintenance
>plan job is started, but the filemon log can become very
large, so it would
>be best to start it some short time before the
maintenance plan starts.
>3. Inspect the filemon log for another process that has
that backup file
>open (if your lucky enough to have started filemon before
this other
>process grabs the backup folder), and inspect the log for
the results when
>the SQLServerAgent agent attempts to open that same file.
>4. Schedule the job or that other process to do their
work at different
>times.
>5. You can use the handle utility if you are around at
the time when the
>job is scheduled to run.
>If the backup files are going to a \\share or a mapped
drive (as opposed to
>local drive), then you will need to modify the above
(with respect to where
>the tests and utilities are run).
>Finally, inspection of the maintenance plan's history
report might be
>useful.
>Thanks,
>Bill Hollinshead
>Microsoft, SQL Server
>
>
>--
>Tibor Karaszi, SQL Server MVP
>Archive at:
>http://groups.google.com/groups?
oi=djq&as_ugroup=microsoft.public.sqlserver
>
>"Leon" <anonymous@.discussions.microsoft.com> wrote in
message
> news:1320001c3f6f9$e945c820$a601280a@.phx
.gbl...
transaction
4GB
supposed
previous
I'm
reduce
and
>
>.
>