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?

asked 04 Mar, 07:55

Justin%20Willey's gravatar image

Justin Willey
7.4k128167240
accept rate: 20%

edited 04 Mar, 07:56

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.

(04 Mar, 13:38) Volker Barth
Replies hidden
1

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.

(08 Mar, 06:12) Justin Willey
Comment Text Removed

> "the database has been corrupted"

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

(08 Mar, 11:06) Breck Carter
Be the first one to answer this question!
toggle preview

Follow this question

By Email:

Once you sign in you will be able to subscribe for any updates here

By RSS:

Answers

Answers and Comments

Markdown Basics

  • *italic* or _italic_
  • **bold** or __bold__
  • link:[text](http://url.com/ "title")
  • image?![alt text](/path/img.jpg "title")
  • numbered list: 1. Foo 2. Bar
  • to add a line break simply add two spaces to where you would like the new line to be.
  • basic HTML tags are also supported

Question tags:

×179
×67
×46
×42

question asked: 04 Mar, 07:55

question was seen: 98 times

last updated: 08 Mar, 11:10