[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference orarep::nomahs::rdb_60

Title:Oracle Rdb - Still a strategic database for DEC on Alpha AXP!
Notice:RDB_60 is archived, please use RDB_70..
Moderator:NOVA::SMITHISON
Created:Fri Mar 18 1994
Last Modified:Fri May 30 1997
Last Successful Update:Fri Jun 06 1997
Number of topics:5118
Total number of notes:28246

5004.0. "Checksums, sometimes our fault?" by M5::LWILCOX (Chocolate in January!!) Thu Feb 06 1997 11:19

Norm, very nice article on checksums but I have to ask about the following
statement because I think customers will skewer us for it:

>>          It is important to realize that Oracle Rdb and Oracle Co-
>>          dasyl DBMS only detect the inconsistency, they are not actually
>>          responsible for the problem.

The reason I think they will skewer us for it is that there has been at
least 1 and possibly 2 bugs in our products that have been responsible
for checksum errors.  One being the "off by one" on Alpha problem and
the other (possible) one being the checksum error only in snapshot files.

The release notes on the "off by one" problem state:         


          In rare circumstances it was possible for Oracle Rdb to
          store pages in the database with incorrectly calculated
          page checksums. Attempts to access those pages would result
          in checksum errors. The checksum would always be off by
          one.
          .
          .
          Checksum errors that do not exhibit a difference
          of one are not caused by this problem. Most checksum errors
          are caused by I/O subsystem problems. If the symptoms don't
          exactly match the scenario described above then the problem
          is likely to be due to errors in the I/O subsystem; i.e.,
          disks, controllers, software drivers, etc.

          This problem has been corrected in Oracle Rdb Version V6.1
          ECO2

Unless I'm misunderstanding, this pretty clearly states it was our fault.

Because the problem with snapshot files was not release noted I'm not sure
if it was really one of our problems or was due to I/O subsystem.  It's the
one I referred to in note 4888.

Thanks.

Liz
T.RTitleUserPersonal
Name		DateLines
5004.1DUCATI::LASTOVICAIs it possible to be totally partial?Thu Feb 06 1997 11:224
In all known cases using the current version of the software, this statement is
true.  Rdb/DBMS did not cause the problem.  Certainly in the past, we've
had problems that could cause checksum problems, but these have (to the best
of our information), been corrected.
5004.2Girls just wanna have checksumsM5::LWILCOXChocolate in January!!Thu Feb 06 1997 11:3317
<<< Note 5004.1 by DUCATI::LASTOVICA "Is it possible to be totally partial?" >>>

>>In all known cases using the current version of the software, this statement is
>>true.  Rdb/DBMS did not cause the problem.  Certainly in the past, we've
>>had problems that could cause checksum problems, but these have (to the best
>>of our information), been corrected.  

Of course, but my point is that since we've caused them in the past what's
to say that some present or future checksum problem won't also be our fault?

Maybe I'm being real nit-picky here but I don't want to close the window on
the however-small possibility that it could be our fault.  No, I don't want
you or us spending days/weeks/months on something that turns out to be a
problem other than ours, but I think it's somewhat arrogant of us to think
that we positively can't be at fault.  I would imagine we thought so 
previously until proven wrong.
5004.3DUCATI::LASTOVICAIs it possible to be totally partial?Thu Feb 06 1997 11:385
I agree that it is arrogant.  However, in 99.9% of the cases that
we've ever seen, it isn't Rdb's fault.  And when it was, we fixed
it right away.  I don't think that there is too much harm in the
statement, but I was trying to protect support and engineering from
wasting time debugging problems in areas that we have no control.
5004.4Just don't count me in the list of "girls" :)BOUVS::OAKEYI&#039;ll take Clueless for $500, AlexThu Feb 06 1997 11:4319
~~           <<< Note 5004.2 by M5::LWILCOX "Chocolate in January!!" >>>
~~                      -< Girls just wanna have checksums >-

~~Maybe I'm being real nit-picky here but I don't want to close the window on
~~the however-small possibility that it could be our fault.  No, I don't want
~~you or us spending days/weeks/months on something that turns out to be a
~~problem other than ours, but I think it's somewhat arrogant of us to think
~~that we positively can't be at fault.  I would imagine we thought so 
~~previously until proven wrong. 

If we've only had 1 or, at most 2, cases in over 15 years I'd say that I 
don't thing we're being "arrogant" in assuming the problem isn't ours.  I 
think Norm's point in trying to move the burden of proof to some other 
organization would be goodness since the instances where it has been 
Rdb/DBMS's fault have been extremely limited.

If you want to take on the burden of proof for customers who call in with 
checksums, I'm sure no one in engineering will complain :)
5004.5M5::LWILCOXChocolate in January!!Thu Feb 06 1997 12:473
Norm, believe me, those of us in support truely appreciate the efforts!
5004.6ukvms3.uk.oracle.com::PJACKSONOracle UK Rdb SupportFri Feb 07 1997 05:239
>If we've only had 1 or, at most 2, cases in over 15 years I'd say that I 
    
    I am fairly certain that it is at least 2, maybe 3 :-) I think there was
    one mentioned in the release notes for DBMS V3.something.
    
    I am happy with article, and have made it available to customers using
    OCIS (http://www.oracle.co.uk).
    
    Peter