Rec_init: Found that page %d had non-log object id %d while checking Syslogs allocation.
This error can occur during startup or during database/transaction log load. It indicates that the transaction log for the database being recovered might be corrupted.
If this error occurs while loading a master database, it is sometimes due to a mismatch between master..sysusages entries in the source and the target master databases.
The following example shows the entries in sysusages that might cause this error:
Source master..sysusages:
dbid |
segmap |
lstart |
size |
vstart |
------ |
------ |
------ |
------ |
------ |
1 |
7 |
0 |
1536 |
4 |
1 |
7 |
1536 |
2560 |
3588 |
1 |
7 |
4096 |
1280 |
6148 |
2 |
7 |
0 |
1024 |
2564 |
3 |
7 |
0 |
1024 |
1540 |
5 |
7 |
0 |
51200 |
33554432 |
6 |
7 |
0 |
51200 |
16777216 |
Target master..sysusages:
dbid |
segmap |
lstart |
size |
vstart |
------ |
------ |
------ |
------ |
------ |
1 |
7 |
0 |
1536 |
4 |
1 |
7 |
1536 |
2560 |
8708 |
1 |
7 |
4096 |
1280 |
6148 |
2 |
7 |
0 |
1024 |
2564 |
3 |
7 |
0 |
1024 |
1540 |
5 |
7 |
0 |
1024 |
6148 |
6 |
7 |
1024 |
1536 |
7172 |
Notice that vstart for dbid 1 is 6148 in the source master..sysusages; 6148 corresponds to vstart for dbid 4 in the target master..sysusages. During the load process, vstart from the target database will be used for writing pages in the target database, so there is a chance that log pages from the master database might get written in a totally different database on the master device. This can result in a 3403 error.
If this error occurs while you are loading a master database dump, you can sometimes prevent it by ensuring that the entries in the master..sysusages table for the source master database match the corresponding entries for the target master database. Do this by altering or extending the target master database similarly to the source master database. Instead of loading the master database in the target server, you can copy the master.dat file from the source server to the target server.
If this error occurs in a user database or, due to other reasons, in the master database, restore the database from a known clean backup. If the problem persists, contact your primary support provider.