I am not quite a DBA, and this issue has me at the end of my rope.
We have a large (150 GB) database on Win2K3 Standard Ed w/ SQL Server 2000.
This backup takes over 8 hours to complete. Each night toward the end, our
backup job fails with the following error:
BackupMedium::ReportIoError: write failure on backup device
'F:\ourbackupfile.BAK'. Operating system error 33(The process cannot access
the file because another process has locked a portion of the file.).
For the life of me, I cannot determine what process is locking the file. I
have tried executing the backup with the database in Single User mode, and
it still fails.
Are there any utilities that I can use to spy on the access to the file, so
I can turn them off?
ANY help is really appreciated. Thanks.Ive discovered the drives are all compressed (and the accompanying KBs that
say its bad to backup to compressed drives)...
"codejockey" <cj@.hotmail.com> wrote in message
news:#nAnWiISEHA.2468@.TK2MSFTNGP11.phx.gbl...
> I am not quite a DBA, and this issue has me at the end of my rope.
> We have a large (150 GB) database on Win2K3 Standard Ed w/ SQL Server
2000.
> This backup takes over 8 hours to complete. Each night toward the end, our
> backup job fails with the following error:
> BackupMedium::ReportIoError: write failure on backup device
> 'F:\ourbackupfile.BAK'. Operating system error 33(The process cannot
access
> the file because another process has locked a portion of the file.).
> For the life of me, I cannot determine what process is locking the file. I
> have tried executing the backup with the database in Single User mode, and
> it still fails.
> Are there any utilities that I can use to spy on the access to the file,
so
> I can turn them off?
> ANY help is really appreciated. Thanks.
>|||You might try FileMon from sysinternals (http://www.sysinternals.com).
Peter Yeoh
http://www.yohz.com
Need smaller backup files? Try MiniSQLBackup
"codejockey" <cj@.hotmail.com> wrote in message
news:%23nAnWiISEHA.2468@.TK2MSFTNGP11.phx.gbl...
> I am not quite a DBA, and this issue has me at the end of my rope.
> We have a large (150 GB) database on Win2K3 Standard Ed w/ SQL Server
2000.
> This backup takes over 8 hours to complete. Each night toward the end, our
> backup job fails with the following error:
> BackupMedium::ReportIoError: write failure on backup device
> 'F:\ourbackupfile.BAK'. Operating system error 33(The process cannot
access
> the file because another process has locked a portion of the file.).
> For the life of me, I cannot determine what process is locking the file. I
> have tried executing the backup with the database in Single User mode, and
> it still fails.
> Are there any utilities that I can use to spy on the access to the file,
so
> I can turn them off?
> ANY help is really appreciated. Thanks.
>|||codejockey,
Annoying isn't it? I have had this a lot and 99% of the time it has been
a tape backup job that has the file locked copying it to tape. Quite
often the tape backup program is awaiting someone to change the tape as
the tape is full.
sysinternals.com is a great resource as Peter mentioned. FileMon should
highlight the culprit.
Mark Allison, SQL Server MVP
http://www.markallison.co.uk
Looking for a SQL Server replication book?
http://www.nwsu.com/0974973602.html
codejockey wrote:
> I am not quite a DBA, and this issue has me at the end of my rope.
> We have a large (150 GB) database on Win2K3 Standard Ed w/ SQL Server 2000
.
> This backup takes over 8 hours to complete. Each night toward the end, our
> backup job fails with the following error:
> BackupMedium::ReportIoError: write failure on backup device
> 'F:\ourbackupfile.BAK'. Operating system error 33(The process cannot acces
s
> the file because another process has locked a portion of the file.).
> For the life of me, I cannot determine what process is locking the file. I
> have tried executing the backup with the database in Single User mode, and
> it still fails.
> Are there any utilities that I can use to spy on the access to the file, s
o
> I can turn them off?
> ANY help is really appreciated. Thanks.
>
No comments:
Post a Comment