A message from a similar thread early this year...
> -----Original Message-----
> From: Max Nealon [SMTP:mnealon@...]
> Sent: Tuesday, January 11, 2000 6:38 PM
> To: email@example.com
> Subject: RE: [Vantage] Raid 5
> From: Max Nealon <mnealon@...>
> The issues with RAID5 are not just limited to performance. The major
> is that Raid5 can cause database integrity issues as follows....
> When a transaction is started, Progress will write a Transaction Start
> to the .bi file. This will be flagged as a "raw" write, to ensure that
> gets there. Raid 5 does not support raw writes, so it cannot be
> The transaction progresses (excuse the pun) and the data that was
> changed in
> the .db is written to the .bi (i.e. the contents of blocks that
> before the change), and a number of pieces of control data. The .db
> write is
> cached, the .bi write should be raw.
> Now the write to the .db is cached by Progress (the size is controlled
> -B), which is fine, it can also be cached by the disk controller, but
> would rather it wasn't.
> There is a database write interval which is determined by a
> combination of
> the operating system, and the size of the cache, and the load on the
> but this interval is normally less than 60 seconds. it can be set
> reducing the load on the machine, but increasing the likelihood that
> transactions that should have been written may be backed out.
> Once the transaction is written, the .bi has a Transaction end note
> to it, once more this is raw.
> It may be up to 60 (write interval again) seconds before the .db is
> to from the cache (the cache flush interval). When the transaction is
> written, the database last write time is updated. This is held
> internally on
> the .db and is not the updated time on the file.
> If the server should die at any of the above stages, then firstly the
> .bi is
> checked for transactions that finished after the last .db write, or
> did not
> finish at all, all of these relevant transactions are backed out in
> that the integrity of each transaction is maintained, thereby
> the integrity of the database overall.
> Now as RAID5 includes its own caching algorithms, and does not respond
> the "write this transaction raw" command (I am not aware of any way to
> off the write cache under RAID5.) the whole integrity of a database
> that is
> in use that crashes cannot be maintained.
> In this scenario, it is not impossible to see that there is the
> of the writes to the .db or the .bi or both, falling out of sync. If
> the .bi
> write for the start of the transaction has not been written, yet the
> has, and the machine crashes, the partial transaction will not be
> out. Worse still the dates on the .bi and the .db may be out of sync.
> Raid 5 does add a performance hit if you are doing a lot of database
> activity, believe me, I have been there. However this is not the hit
> worries me.
> Epicor recommend Raid 1, 0 or 10 only for very good reason. Those of
> running Raid 5, are running against the recommendation, and
> potentially you
> are putting the integrity of your database at risk. If this is a
> critical application, then you are potentially putting the business at
> You can reduce this risk by adding multiple power supplies, and
> everything else, but you are nowhere near as safe as good old
> Max Nealon
> Epicor Software Corp.
> --------------------------- ONElist Sponsor
> Hey Freelancers: Find your next project through JobSwarm!
> You can even make money in your sleep by referring friends.
> <a href=" http://clickme.onelist.com/ad/jobswarm1 ">Click Here</a>