How can I troubleshoot eratic, slow SQL Backup job?

I have a SQL 2000 sp3 server running on a server class machine with
local drives.
I'm backing up a 50 gig db from the e partition to the F: partition.
Sometimes the backup takes 20 minutes...sometimes it takes 2.5 hours.
There are no jobs running when the backups execute, no index rebuilds,
no veritas, no virus scans running.
I'll run a backup and it will take 20 minutes. I rerun it again
right away and it takes 2.5 hours.
I run a statistics IO trace, and the only difference is the cumulative
wait time...which is much much higher when the backup takes 2.5 hours.
Any suggestions on how to troubleshoot this? Or why it might be
happening?On Apr 16, 5:51 pm, "Sanctus" <mch...@.hotmail.com> wrote:
> I have a SQL 2000 sp3 server running on a server class machine with
> local drives.
> I'm backing up a 50 gig db from the e partition to the F: partition.
> Sometimes the backup takes 20 minutes...sometimes it takes 2.5 hours.
> There are no jobs running when the backups execute, no index rebuilds,
> no veritas, no virus scans running.
> I'll run a backup and it will take 20 minutes. I rerun it again
> right away and it takes 2.5 hours.
> I run a statistics IO trace, and the only difference is the cumulative
> wait time...which is much much higher when the backup takes 2.5 hours.
> Any suggestions on how to troubleshoot this? Or why it might be
> happening?
Here are some ideas...
E: to F: - are these different drives on a san and does the backup
have to go accross the network - higher network traffic at times?
Network saturation?
Are their heavier user processes at times? Heavy duty queries/long
running transactions?
Is this a dedicated SQL Server, could another application be hogging
the Memory or IO?
As you can see, I am just shooting blind. Maybe some of these ideas
can help you think how to investigate?