March 2, 2005 at 7:06 am
Hello,
Yesterday we replaced a disk in our sql server due to capacity problems. First we made a backup disconnected the disk (SAN), replaced the disk (with same driveletter) and restored the data. After a reboot, mssqlservice did not start. Could there something wrong with the disk signature? How can we fix it?
regards,
Ed
March 2, 2005 at 9:58 am
Did you put back the permission on the disk correctly to allow the sql service account full rights?
mom
March 2, 2005 at 11:11 am
Was the Master, Model, MSDB and temp db's also on the SAN?
March 2, 2005 at 4:13 pm
Same question, different context. Our QA box had a duo drive failure (both sides of a mirror) and we had to replace the drives. We installed a new OS to a RestoreOS directory structure (NT 4, don't yell) and then restored the previous file structure from a flat file backup system. This allowed us to reboot to our previous OS install, but SQL Server 2000 (sp3a) would not start. We then tried to "repair" the registry via the 2000 install disk, but it gave us an error trying to run the Microsoft Management Console install process complaining about "not enough storage space" (which isn't true for ram or disk) and then it balked about not being able to start the SQLServer Service. When we looked at the services console SQLSERVER was not in the list anymore. All in all a complete failure. What we then did may not have been appropriate (feel free to correct me), but we took the master, pubs, msdb, and tempdb MDX/LDX files from another server since they were never backed up due to being in use (actually, none of the MDX/LDX files were backed up). The plan was that once SQL Server would start we could restore all our databases from the BAK files which we do have. Once I copied those over I was able to manually run sqlservr.exe from a command prompt and watched it start up and "recover" those databases. Re-running the repair process produced the same results as before.
In the morning we plan to restore the file system again to start over, but I was wondering if anyone could tell us where we went wrong? Of primary concern right now would be how we should have recovered SQL Server. Another "where we went wrong" might be an additional backup or similar step we should have done prior to failure should one jump out at you. Exclude "practice" recovery because I know that one and just haven't had that kind of authority or pull. It's one of those things we all know but can't get the time and/or hardware to do.
Related to the previous post about file permissions, are there special file permissions that need to be applied? If so then that hasn't been done. I don't know whether the SQL Server service was configured to use the system account or a local one since 2 other servers we checked used one of each approach and the server being restored don't list the service anymore. If the "repair" attempt is what removed it then I may be able to find out in the morning after we restore the file system again.
March 2, 2005 at 7:09 pm
Not knowing how many user accounts you had, why not just do a fresh install of SQL, re-create the shell db's and do a force restore from the BU and fix the orphaned users?
March 3, 2005 at 5:31 am
Hi,
don't you do backups of ALL your databases on a regular basis?
If you have got native backups of master, msdb and model (if you changed that one) all you have to do is install SQL-Server + SP new and then restore first master, then msdb and the user-databases...
karl
Best regards
karl
March 3, 2005 at 6:57 am
That is what I thought. We uninstalled SQL Server, rebooted, and tried to re-install it but the install fails with the same Microsoft Management Console error that we got with the repair attempts. We'll be trying some more stuff today and I'll let everyone know how it turns out.
March 3, 2005 at 7:28 am
Hmm, as i remember the error about "not enough storage space" during installs may occur if there is no c:\temp, or if the path to the install-directory (if you install from disk and not from cd) includes spaces or other non-dos2.11 compatible characters...
Don't know if the sql2000-install has the same bug though...
Did you try to manually create the entry for SQL-Server in the registry:
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSSQLSERVER]
"Type"=dword:00000010
"Start"=dword:00000002
"ErrorControl"=dword:00000001
"ImagePath"=hex(2):43,00,3a,00,5c,00,50,00,52,00,4f,00,47,00,52,00,41,00,7e,00,
31,00,5c,00,4d,00,49,00,43,00,52,00,4f,00,53,00,7e,00,34,00,5c,00,4d,00,53,
00,53,00,51,00,4c,00,5c,00,62,00,69,00,6e,00,6e,00,5c,00,73,00,71,00,6c,00,
73,00,65,00,72,00,76,00,72,00,2e,00,65,00,78,00,65,00,00,00
"DisplayName"="MSSQLSERVER"
"ObjectName"="Domain\\User"
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSSQLSERVER\Linkage]
"Export"=hex(7):4d,00,53,00,53,00,51,00,4c,00,53,00,45,00,52,00,56,00,45,00,52,
00,00,00,00,00
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSSQLSERVER\Performance]
"Library"="C:\\PROGRA~1\\MICROS~4\\MSSQL\\BINN\\SQLCTR80.DLL"
"Collect"="CollectSQLPerformanceData"
"Open"="OpenSQLPerformanceData"
"Close"="CloseSQLPerformanceData"
"Last Counter"=dword:0000107a
"Last Help"=dword:0000107b
"First Counter"=dword:00000f66
"First Help"=dword:00000f67
"WbemAdapFileTime"=hex:00,56,16,80,e0,a5,c2,01
"WbemAdapFileSize"=dword:00008238
"WbemAdapStatus"=dword:00000000
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSSQLSERVER\Security]
"Security"=hex:01,00,14,80,a0,00,00,00,ac,00,00,00,14,00,00,00,30,00,00,00,02,
00,1c,00,01,00,00,00,02,80,14,00,ff,01,0f,00,01,01,00,00,00,00,00,01,00,00,
00,00,02,00,70,00,04,00,00,00,00,00,18,00,fd,01,02,00,01,01,00,00,00,00,00,
05,12,00,00,00,00,00,00,00,00,00,1c,00,ff,01,0f,00,01,02,00,00,00,00,00,05,
20,00,00,00,20,02,00,00,a8,0c,00,00,00,00,18,00,8d,01,02,00,01,01,00,00,00,
00,00,05,0b,00,00,00,20,02,00,00,00,00,1c,00,fd,01,02,00,01,02,00,00,00,00,
00,05,20,00,00,00,23,02,00,00,a8,0c,00,00,01,01,00,00,00,00,00,05,12,00,00,
00,01,01,00,00,00,00,00,05,12,00,00,00
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSSQLSERVER\Enum]
"0"="Root\\LEGACY_MSSQLSERVER\\0000"
"Count"=dword:00000001
"NextInstance"=dword:00000001
karl
Best regards
karl
March 3, 2005 at 7:29 am
Aaron
I think i remember of running into this one. All i can think about is deleting all references to Microsoft SQL Server and MSSQLSERVER(or your named instance if you have one) from your registry.
Ed,
I have gone through a handful of SAN migrations and we follow the same exact path which you did, i.e. copy the data files to a safe location, remove the old SAN and then allocate the new SAN and rename the drive and copy the files again. SQL Server does not look at disk signatures. If you are running Clusters, then yes, you do have to be concerned about disk signatures but not for Stand Alone. Can you try to start SQL from the command line and give the parameters for master database and see how that goes ?
March 3, 2005 at 8:43 am
Thanks for the help. We did get things going again. We started over (deleted C drive and re-restored it). To avoid the storage space error we unfortunately did two things at once. We uninstalled symantic antivirus and ungraded I.E. from 5.5 to 6.0 sp1. After we Ghost the server we may start over again to see if all we had to do was remove symantic antivirus (my guess). To avoid having to uninstall/reinstall SQL Server itself I still just took the master, temp, model, pub, northwind, and msdb databases from another server. After starting in single user mode I started restoring databases beginning with master. All seems good now. Again, thanks for the responses.
March 3, 2005 at 9:30 am
Thanks for the help. But the problem was TSM. We had two directories, one is called microsoft sql data and one is called microsoft sql server. When we restored the data, sql service will start from the wrong path.
Ed
Viewing 11 posts - 1 through 10 (of 10 total)
You must be logged in to reply to this topic. Login to reply