Skip to Content

ASA9 terminating abnormally with message about a "null" table!?


Since this morning we have an ASA9 database terminating abnormally. 

This below is a portion of the console log right before the database terminates abnormally.

E. 06/01 11:17:56. *** ERROR *** Assertion failed: 102203 (

E. 06/01 11:17:56. Row count (-2147365485) in table ((null)) is incorrect

I. 06/01 11:17:56. *** ERROR *** Assertion failed: 102203 (

I. 06/01 11:17:56. Row count (-2147365485) in table ((null)) is incorrect

I. 06/01 11:17:56.

I. 06/01 11:17:56. Attempting to save dump file at 'C:\Users\ADMINI~1\AppData\Local\Temp\1\sa_dump.dmp'

I. 06/01 11:17:56. Connection terminated abnormally

I. 06/01 11:17:56. Dump file saved

Out of desperation we brought the server back up using "dblog -t" to start a new log  (I initially thought that the transaction log had become corrupt).

The database worked for about an hour, and then we got the same error (actually the console log extract above is from the 2nd time the datase went down).

Any ideas of what this error means, and what I could do?



Add comment
10|10000 characters needed characters exceeded

  • Get RSS Feed

1 Answer

  • Jun 01, 2016 at 06:17 PM

    Hi Edgard,

    Assertion failed to my experience often indicates a .db corruption. The .db file is assumed to be more exposed to corruption than the .log file. To validate the .db file, use the dbvalid tool, ideally when no one else uses the database (or on a file system level copy).

    If there is corruption, the general recommendation is to restore the database from a clean full backup and the backed up and / or active transaction log(s), as if you had lost the .db file.

    If you don't have a clean backup, there was a white paper available (I hope it still is, but it was from a URL, so I don't know if it's still available, and where) advising how to salvage as much as possible from the broken .db. It basically is about unloading and reloading the database (without ordering by PK). If you're lucky and there are no table pages infected, you may get along without loss of data. Otherwise, exclude the infected table(s) from dbunload and try to export the data from the infected table(s) separately by exporting them in sort order using the output statement. Use a combination of ascending and descending queries to get the clean rows on either side of those broken.

    This is the reason why you should combine dbvalid with every full backup of the database one way or the other. This way, you immediately recognize whether the full backup you are about to create or just have created is clean or not. Otherwise, a corrupt page may go undetected for months, making it hard or even impossible to restore the database.

    There are more verbose directions out in the net. HTH for the moment regardless.


    Add comment
    10|10000 characters needed characters exceeded

    • Hi  Volker,

      We finished rebuilding today at 5am.    We had to do the process manually UNLOAD/LOAD and with some other tables we used proxy tables, and with some smaller ones we used a program called "Cross-database Studio".

      The system is operational 😊!   We still need to work on some subsystems, but the major core is working.  

      A good side effect of this problem is that we trimmed old data that wasn't necessary and the database is now UNDER 100GB.    I was surprised at the change in size.    Everything is easier with 100GB compared to 300GB.

      Thanks for all your help Volker!