|
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 |
Follow this question
By Email:Once you sign in you will be able to subscribe for any updates here
By RSS:Markdown Basics
- *italic* or _italic_
- **bold** or __bold__
- link:[text](http://url.com/ "title")
- image?
- 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:
question asked: 21 Jul '22, 03:56
question was seen: 420 times
last updated: 21 Jul '22, 12:29
> 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.
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.
> 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.
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.