I wanted to add that the database is a restore from a SQL Server 2005
When you restore a database the Service Broker in it gets disabled and must be explicitly enabled (there are reasons why this is necessary, but I won't go into them). If you restored the DB and then set up the AG w/o enabling broker first, you have set up the AG w/o the Service Broker enabled and now you cannot run the ALTER DATABASE SET ENABLE_BROKER
. Unfortunately to set it up correctly you must enable broker before adding it to the AG, which means you must tear apart the AG, enable broker, then set set up the AG again.
In order to understanding why error 3456 would be thrown, we need to take a little step back and understand how SQL Server handles this corner of recovery.
When SQL Server is redoing an operation, and that redo is a page modification, it makes a quick check. In the page header there is ultimately going to be a PageLSN
, which is an indication of the last LSN that has modified that page, recorded by the page. Think about it like this, the page keeps track of the last LSN that has made modifications to it. This is the PageLSN
.
Every time there is a logged page modification operation, that log record includes a few LSNs. Namely, the log record's LSN (think... Current LSN), and then it has what's called the Previous Page LSN (PrevPageLSN
going forward). So when we modify a page, one of the pieces of data that is put into the log record is what the page indicates as being the last LSN before you to have modified the page.
Think about it like this... Your car needs to have work done on it. Mechanic John works on your car, and in the engine bay it has a little tag and Mechanic John writes "John worked on this car last". Then the next time you take your car in to another shop, Mechanic Mark looks in the engine bay and sees that Mechanic John worked on this car last. On his data sheet he writes this information. Same idea with SQL Server.
This can be somewhat confusing, so take a look at this image below on sequential page modifications, and how the PageLSN
and PrevPageLSN
relate:
Let's loop back around, as this all comes into play when you need to redo an operation on a page (restores, recovery, HA, etc.). When SQL Server needs to redo a page operation, it makes a sanity check to see if the PageLSN
on the page matches the PrevPageLSN
that the log record includes. If that is not equal, then you will see error 3456 get thrown.
Does PageLSN equal PrevPageLSN? No??? Stop and raise error 3456...
Let's analyze your error message, which includes the how:
Could not redo log record (210388:123648:232), for transaction ID (0:1016710921), on page (4:8088), database 'SomeDB' (database ID 6). Page: LSN = (0:0:1), type = 11. Log: OpCode = 4, context 11, PrevPageLSN: (210388:122007:1). Restore from a backup of the database, or repair the database. Msg 3013, Level 16, State 1, Line 1 RESTORE LOG is terminating abnormally.
I have bold'd the two pieces of data that have an inequality causing the error. You can see that our PageLSN
is 0:0:1 (this was found in the page's header), and our PrevPageLSN
is 210388:122007:1 (this was found in the data on the log record that was attempting to be redone). These are obviously not equal, hence err3456.
So in order to find out the why of this event, would be to find out why there is a disparity here. We really need to trace the lifecycle of page 4:8088 and see where the disconnect is. Unfortunately without further information, or hands-on troubleshooting there isn't much else I can do besides give you the background of this recovery operation and what causes the error.
Best Answer
I have a feeling something is iffy about your setup here.
If you run the following script:
You should see this in the error log:
In other words, only the transaction log needs to be zeroed out. The data file should skip this.
I can run this commands and have it finish instantly as well:
If you're on a new enough version of SQL Server (as your question >implies), you can see if this query helps:
If that doesn't work, you'll have to go back in time and use
whoami
to determine that.Keep in mind that your server needs to be restarted to enable IFI, so if you just added the priv, or you added it and never restarted SQL, it won't be in effect.
If this is sync mirroring, perhaps IFI isn't enabled on the parter? Have you checked to see what's up over there?