 |
 |
Archives of the TeradataForum
Message Posted: Fri, 22 Oct 2004 @ 18:04:45 GMT
| Subj: | | Re: V2R5 Upgrade and CHECKSUM |
| |
| From: | | Victor Sokovin |
John,
| | Doesn't the existing hardware (either the disk controller or the drive itself) already write a checksum during each write (on a sector-by-
sector basis)? And don't the various system memories already have either parity and/or EDC (Error Detection and Correction)? | |
| | If so, then wouldn't the CHECKSUM option merely (but with significant overhead) duplicate that which is inherent to the hardware? So
what's the benefit of a table-level CHECKSUM option? | |
I am sure Mark can give a comprehensive answer but I just want to give one of the examples when the new feature in TD might prove useful. If it
is a wrong example and it gets corrected I'll extra benefit from clearing my own possible confusion.
Suppose the data has been written perfectly to the disk sector and stays there unchanged for some time. It is only occasionally being read.
Now, the reading activity turns out to be too much for our sector and it gets physically damaged. Without the new CHECKSUM feature enabled, it can
happen that the next read of the sector will pass on the incomplete data to the client without any visible failure in the application. Of course,
the disk check utility will detect the bad sector one day but when will it run next time? It might take some time before it does.
If the CHECKSUM feature is enabled, the chance that the bad sector is reported immediately is high because its correct checksum was stored in
the safe place (we hope that place is not affected at the same time as our sector) and TD will check whether the new checksum matches the stored
one before it returns the data to the client. No match will mean read failure.
Regards,
Victor
| |
