Lost Delayed - Write Data

Hello All,

Thanks in advance for your help.

I am wondering if there is a correlation between the size of a database and the amount of RAM required in the server. Here's what's going on:

NT4.0 SP 6a, SQL 7.0
2-800 MHz Pentium III Processors
512 MB RAM
Swap Files: two, divided evenly between two partitions, min 512 per partition (dynamic)
3- 9.2 GB Drives, RAID 5

SQL Database size: 2.5 GB

The SQL administrators have a scheduled job set to dump the database every four hours, so they have 6 of these dump files per day. Seagate Backup Exec v 6.? backs up those files every evening. Of course, this is a mission-critical application.

As the NT/Hardware administrator, I was tasked to flash upgrade all the hardware that could be flashed. That happened about three weeks ago. Ever since I flashed it, getting the data dumps has been an inconsistent process. Sometimes it works, sometimes it errors out. The error message is " Lost Delayed - Write Data: The system was attempting to transfer file data from buffers to (path). The write operation failed, and only some to the data may have been written to the file."

On and off during the day, you can't even copy a small file on the server without receiving the same message.

Before I flashed the server, it was blue-screening and needing to be rebooted about once every two weeks. Since I flashed it, the server hasn't been rebooted, because it hasn't blue-screened.

The database dumps are about 2 GB. We were thinking that the way the dump process worked was that a snapshot of the data was put into memory before it was written to disk. We thought since the dump size was larger than Physical Memory + Virtual Memory, that that could be causing the error.

What do you guys think?
1. Is dumping the database first the preferred way to get a backup, or should a backup directly to tape be scheduled instead?
2. Do we have enough RAM for the database?
3. Are there special settings we should set for the RAID controller card to maximize throughput for SQL?

Thanks again. I am definitely not a SQL DBA and any information you can provide would be really helpful.