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: vantage@onelist.com
> Subject: RE: [Vantage] Raid 5
>
> From: Max Nealon <mnealon@...>
>
> The issues with RAID5 are not just limited to performance. The major
> issue
> is that Raid5 can cause database integrity issues as follows....
>
> When a transaction is started, Progress will write a Transaction Start
> Note
> to the .bi file. This will be flagged as a "raw" write, to ensure that
> this
> gets there. Raid 5 does not support raw writes, so it cannot be
> guaranteed.
>
> 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
> changed
> 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
> by
> -B), which is fine, it can also be cached by the disk controller, but
> I
> 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
> server,
> but this interval is normally less than 60 seconds. it can be set
> higher,
> 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
> written
> to it, once more this is raw.
>
> It may be up to 60 (write interval again) seconds before the .db is
> written
> 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
> order
> that the integrity of each transaction is maintained, thereby
> guaranteeing
> the integrity of the database overall.
>
> Now as RAID5 includes its own caching algorithms, and does not respond
> to
> the "write this transaction raw" command (I am not aware of any way to
> turn
> 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
> possibility
> 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
> .db
> has, and the machine crashes, the partial transaction will not be
> backed
> 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
> that
> worries me.
>
> Epicor recommend Raid 1, 0 or 10 only for very good reason. Those of
> you
> running Raid 5, are running against the recommendation, and
> potentially you
> are putting the integrity of your database at risk. If this is a
> business
> critical application, then you are potentially putting the business at
> risk.
> You can reduce this risk by adding multiple power supplies, and
> multiple
> everything else, but you are nowhere near as safe as good old
> mirroring.
>
> 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>
>
> ----------------------------------------------------------------------
> --