June 1, 2008 at 4:44 am
moving to a new sql server box because of a problem with the SAN its connected to.
started my named instance in single user mode and restored master. sqlserve.exe -c -m -s ovops
now the instance won't start. tried starting it with the -t3608 switch.. won't start!!
Its because my drive configuration is different on the new server than it was on the old server, I cannot start the instance because it is expecting model, msdb, temdb and all of the user databases on drives that don't exist?? what can I do?????
June 1, 2008 at 5:26 am
will it start in default mode - sqlservr.exe -f -s ?
if so follow http://www.tek-tips.com/viewthread.cfm?qid=798602
else do you by any chance have a copy of the original master .mdf and .ldf files you can copy back into the correct location, it will restart then.
I am afraid if you are restoring master to another server the directory structure should be the same, so you may have to reinstall this named instance, and then rather than restoring the master over, script out logins and recreate them. Use sp_help_revlogin and sids will be maintained. Don't forget default database and language settings. You will then be able to restore msdb over if exactly the same SQL version.
---------------------------------------------------------------------
June 1, 2008 at 2:06 pm
we end up repartiioning and reinstalling.. no big deal. server is all recovered (thanks)
NOW er are getting this:: Cannot generate SSPI context" when trying to connect to sql server via ODBC for our access applications.. can anyone help?????
THE ONly thing I can see that has changed is we went from win2k server to 2003 server. sql serverwise everything appears the same!!!!!! not fun on a sunday!!! can anyone help?
June 1, 2008 at 2:16 pm
the enclosed article should help:
http://support.microsoft.com/kb/811889
I am struggling to remember the details but I have had this problem before and it was linked to the server having dropped out of the domain somehow, so get your sysadmins to check that side of things and the server entry in AD.
---------------------------------------------------------------------
June 1, 2008 at 2:38 pm
I've remembered what happened the last time I hit this error.
the server had been taken out and back into the domain but not cleanly, leaving a rogue entry for the server in AD. The fix involved cleanly dropping the server out of the domain and putting it back in. did not do this process myself so cannot be sure if any other actions were taken to remove rogue entry, but ensuring the process was done cleanly was the fix.
you need to concentrate on anythng that might have left an invalid SPN behind, and try to remove it, a clean shutdown and restart of the sever might be enough to do it, worth a go.
good luck.
---------------------------------------------------------------------
Viewing 5 posts - 1 through 5 (of 5 total)
You must be logged in to reply to this topic. Login to reply