Assertierung fehlgeschlagen: 101412 (SB10) - DB still online

[Former Member]

I used dbvalid for checking a copy of my productiv database in Sybase 10. Today i got an error like this

Foreign key "XXXXX_FK" has invalid or duplicate index entries SQL error (-300) Run-time SQL error - Validation of the Table "XXXXXXXXX" failed

So i try to reoganize the database to get the error number. ** SQL-Fehler: Interal Database Eroor FEHLER *** Assertion failed: 101412 (10.0.1.3990) Page number on page does not match page requested - Transaktion rolled back

So i lookup but don't find the error number http://wiki.scn.sap.com/wiki/display/SQLANY/Handling+an+Assertion+Failure

The Database is still online but with these error. Anyone know what to do to fix that? Anyone know the cause of these failure?

[VolkerBarth]

So i lookup but don't find the error number...

Note, that page is not meant as a full list of possible assertion numbers, it's just a list of those that v16 does treat as a "database-level" assertion and may therefore allow other databases on the same database server to keep running. v12 and older versions do not make that difference. So for v10, that list is quite useless.

So i try to reoganize the database to ...

Have you tried to follow the steps noted in the doc? Does an unload/reload produce that assertion? If so, I guess it's time to think about a recovery...

[Former Member · Accepted solution]

I've got the solution!

I opend SQL Anyhwere go to the Table>Indizies>recreate Index

An Again i checked the database with dbvalid... no errors.

[VolkerBarth · Accepted solution]

Glad to hear that:)

However, please note that paragraph from the doc you have quoted:

Even if the validation process does not return errors after validating a database, once an assertion condition has been hit, there is still potential for corruption of the database file during runtime. The only way to guarantee removal of all pre-existing corruptions in the database file is to rebuild the database using the unload/reload process. The ability to restart the database file on a database server alone does not guarantee that the database file is free from corruption. See: The rebuild process for SQL Anywhere 10 and later databases

[Breck_Carter · Accepted solution]

In addition to Volker's suggestion, you should do hardware-level checks of both the hard drive AND the computer memory. Memory failures can appear as data errors, even hard drive errors... every single piece of software uses memory to perform data checking, so you really never know what the problem is until you check the memory.