 |
 |
Archives of the TeradataForum
Message Posted: Mon, 25 Oct 2004 @ 09:33:55 GMT
| Subj: | | Re: V2R5 Upgrade and CHECKSUM |
| |
| From: | | Victor Sokovin |
| | So if the CHECKSUM option is being handled at the RDBMS level and the corruption is caused before the data is written, how is the CHECKSUM
option going to be any more effective than the CRC written by the disk subsystem? And being the hardcore cynic, I can't help but wonder that if
the CHECKSUM option is a good idea for tables, wouldn't it also be a good idea for spool files? If I can trust the spool files, then why can't I
trust the tables? | |
I understand CHECKSUM is on the "application" level. Of course it must understand the RDBMS format but it monitors *what* is written in the BD
blocks (on RDBMS level, we don' care as long as the data just fits). To describe what I mean, I'll use the following example. Suppose some
software or user, intentionally or not, overwrites the data by direct access to the disk, not via SQL. If they are lucky and the DB format is not
violated, the change will remain unnoticed to any utility on the levels below the CHECKSUM. Perhaps I should have used this example and not the
hardware failure one to describe the main difference I see in the CHECKSUM.
As far as the hardware failures are concerned, I suspect some crosslinks can cause the same behaviour. Also, the influence of parallel
datastreams like in the cache or busses, if the hardware and software managing them are not perfect, and, as it happens, quite often they are
not.
Regards,
Victor
| |
