Question Re: Assertion failed: 200166 in Technology Q&A

Assertion failed: 200166

former_SQLA_member1694902 — Thu, 21 Jul 2022 03:56:29 GMT

07/21 06:50:28. ERROR Assertion failed: 200166 (17.0.10.6285)[--server/database name--] Referenced table page does not belong to this table

Had this error after restoring after a ransomware attack. I'm running a VALIDATE on the tables now. Haven't hit any errors so far. Does anyone have any information about anything else I can try?

Would a full unload-reload fix it? Would that even complete if there's corruption? I've got a back up from Saturday, before the attack but people have done work since then. Last night's back up failed because a drive was missing, but it may already be corrupt by that point.

SqlAnywhere 17.0.10.6285

Re: Assertion failed: 200166

Breck_Carter — Thu, 21 Jul 2022 08:21:45 GMT

> Had this error

Exactly when/where did you see this message? When trying to start the database? When running a query?

> I'm running a VALIDATE on the tables now

Presumably you are able to start database.

You may be able to isolate the table by doing individual UNLOAD statements for all the other tables.

You may be able to restore from the old backup, and then apply the subsequent *.log files.

Re: Assertion failed: 200166

former_SQLA_member1694902 — Thu, 21 Jul 2022 08:52:17 GMT

The error was in the -oe log "Specifies a file name to log startup errors, fatal errors, and assertions." It was created when the database shut itself down.

Yes, the database starts and runs and works "fine".

Are you saying that a full unload/reload will not work?

To be clear I don't know which table it is, there are no details.

Re: Assertion failed: 200166

Breck_Carter — Thu, 21 Jul 2022 09:36:29 GMT

> Are you saying that a full unload/reload will not work?

No, I'm not saying that.

If a full unload/reload does work, it's probably safe to say the fresh new *.db file is completely OK.

Re: Assertion failed: 200166

VolkerBarth — Thu, 21 Jul 2022 12:28:47 GMT

What kind of backups do you have? If you have incremental logs based on a validated full database backup, I would restore from that... because that's what a backup is for.