Assertion failed: 106222 - applying log file to an encrypted database

[justin_willey]

v 17.0.10.6175 on Linux (Suse 15.2)

I got this error message:

 ERROR  Assertion failed: 106222 (17.0.10.6175)[IQX]
Unexpected error adding posting index entry - Error: Primary key for table '9789pos1' is not unique: Primary key value (''effective',8152678429,0,1,4136')

when applying a log file to a backup database using this command line:

dbsrv17 -n LogApply -o "/srv/iqx/backup/XXXX/Messages/20210304084506 Live Backup Log Apply.txt" -qs -c 1G -ca 0 -x none -xd /srv/iqx/backup/XXXX/IQX.db -a /srv/iqx/backup/XXXX/SafeLive.log -ek ***

The backup database validated fine before the log application and the live database the log came from is also fine. The table 9789pos1 isn't something we have created and doesn't appear in the catalog, so presumably something very internal?

My friend, Ms Google, doesn't seem to recognise assertion 106222. Does anyone know what might cause this?

[VolkerBarth]

Very wild guessing: Could this be related to different settings for MPL or intra-query parallelism compared to the original database server? Does the error also appear when translating the log to a SQL file and doing the restore via that? (Which may not count as a real restore, if you need to retain log offsets and the like...). And could the value in the table above relate to a log offset? - Yes, very very wild guesses, indeed.

[justin_willey]

Thanks Volker. The settings are the same - this database only exists as a stand-by for the main one and has never had anything done to it (even connections) except applying logs and read-only validations. I haven't tried it, but I'm pretty sure the translated SQL would work - but of course it would then be no use for further log applications as the offsets would be messed up.

I wonder if there is a problem in the log application system that occasionally means that logs won't apply. It could be on the lines you suggest but the difference being a slightly different processor architecture or something like that? We've occasionally had similar (but different assertion number) problems when applying logs, that we've not been able to get to the bottom of. SAP support just say "the database has been corrupted", but the only activity that has happened is that logs have been applied.

[Breck_Carter]

> "the database has been corrupted"

...or "the RAM is bad", either way you're off the phone 🙂