|
Sometimes the server raises an assertion error for a problem with a single row. Here is a really obscure example, but there are other more common ones: *** ERROR *** Assertion failed: 200610 (11.0.1.2276) Attempting to normalize a non-continued row (0x12345:0x0) When this happens it is very difficult if not impossible to rescue the database. In this case any attempt to SELECT that row causes the server to stop, and because there is no indication what row is involved, and because there are millions of rows in that table, the database had to be restored from a backup. Here's an analogy: A airliner is halfway across the Pacific when the light in one of the lavatories burns out (the assertion); this in turn causes all the engines to shut down and the plane to crash in the middle of the ocean. In the real world, one of the flight attendants puts an "out of order" sign on the lavatory and makes a note for the aircraft maintenance crew to "replace bulb". In the SQL Anywhere world, the server should throw an exception to the affected client, log the problem for later attention... AND CARRY ON! ...no need to spread baggage and body parts over miles of ocean! |
|
[placeholder answer] |
I think this one deserves a stir-up. The whole business of assertions needs some examination. If we are going down the self-managing database route and (lets say) an index gets corrupted, isn't there an argument that the engine should just get on and fix it. Certainly flash some red lights and let people know, but do the fix anyway. After all, whats the dba going to do - drop and recreate the index, and then keep an eye on things. Obviously harder / not possible if it's real data corruption.