We have a customer trying to upgrade from v10.0.1.4051 to v126.96.36.1991
Their plan is to initially run the v10 database under the v16 engine, and then after a suitable period of satisfactory live running, re-build as a v16 database. The idea being that if significant issues are found under v16 they can easily revert. Their testing of this process has gone fine for some time until now.
The v10 database was run briefly under the v16 engine. The v16 engine was then stopped cleanly and the v10 engine re-started. The database would not start and gave this message:
However v16 could open the problem database without problem. Despite this the database still would not open under v10 and all attempts at recovery failed and the database had to be recovered from backup to run under v10 again.
The only reference to this assertion I can find related to a bug fixed in 2008 in v9.0.2 (CR496087):
In rare instances, assertion failure 201822 "Checkpoint log: attempt to allocate before recovery is complete" could have been reported during database recovery. The problem has been fixed. If this problem is encountered, recovery with a server containing this fix should complete normally.
The v10 release notes make a few references to checkpoint log issues but all were fixed before build 4051.
Does anyone have any thoughts as to what the issue might be? Thanks!
[WAG] Since the database was shut down cleanly, there should be no reason not to try dbsrv10 -f to force a restart without the transaction log, then run dbsrv10 normally to create a new transaction log. [/WAG]
answered 18 Feb '16, 13:34
Using -f should not succeed as the checkpoint log is actually stored within the database file. The problem seems to be that the server is going through recovery despite the claim that the database has been shutdown cleanly. I wonder if perhaps there are multiple dbspaces in this database and that not all dbspaces are being copied into both environments. I'm trying to figure out why a database that apparently was shutdown cleanly would need to go through recovery. Swapping copies of dbspaces might do that. The assertion failure is basically telling me that the server is going through recovery yet we're attempting to allocate new pages to the checkpoint log which is not allowed. I would need to see the database or a full dump/core to have a chance to figure out what is going on.
answered 19 Feb '16, 11:43