April 16, 2009 at 6:11 pm
I am using DoubleTake to replicate all system and user DBs to DR site. We have used this method for years and it has worked great in the past.
Today, I was performing a regular failover test. My failover procedure is as follows:
Stop services on Primary
Verify Mirror is Idle
Stop DoubleTake Mirror/Replication (disconnect)
Start services on DR
Change DNS to point to DR
When I am satisfied that the failover was successful, I restart the replication in the reverse
Now, this time, when I went to start the services on the DR server, I received an error and the instance wouldn't start.
The error.log (starting from model) reads as follows:
Starting up database 'model'.
Error: 9003, Severity: 20, State: 1.
The log scan number (23:176:1) passed to log scan in database 'model' is not valid. This error may indicate data corruption or that the log file (.ldf) does not match the data file (.mdf). If this error occurred during replication, re-create the publication. Otherwise, restore from backup if the problem results in a failure during startup.
SQL Trace was stopped due to server shutdown. Trace ID = '1'. This is an informational message only; no user action is required.
How can I discover what is wrong about this file? The file sizes and modified dates are the same. I took an MD5 of the DR files, but I cannot stop the Primary site right now to take an MD5 of those.
Any good way to discover the problem?
Any help would be great! Thanks!
April 20, 2009 at 7:05 pm
Quick fix
===
Copy the model database(MDF and LDF) of any other instance of same build and replace the model files.
Regarding the Root cause. then we need to check the errorlogs and event logs to find if doubletake is causing any issues
April 20, 2009 at 7:38 pm
I appreciate the input on the quick-fix idea. That would be no problem, but since this is an important failover instance, I would like to explore what may have caused this problem in the first place. Do you have any ideas on how to diagnose this? It seems to me that the data in the model MDF and LDFs must be at least somewhat good, because the instance was able to read the LSN... If they were completely corrupt, I would doubt they would get that far. Is there a way to see what the LSN is on each file? The Error log implies that the two LSNs did not match.
Viewing 3 posts - 1 through 2 (of 2 total)
You must be logged in to reply to this topic. Login to reply