June 20, 2005 at 9:56 am
Hello,
We had a situation where the Windows Registry setting(s) for the SQL Server Agent were manually deleted. Therefore it stopped working.
This is a Windows 2000 Server/SQL Server 2000 installation.
Can the SQL Server Agent be reinstalled without installing anything else?
Thanks,
Steve
June 23, 2005 at 8:00 am
This was removed by the editor as SPAM
June 23, 2005 at 8:51 am
To the best of my knowledge (which is not absolute), it is not possible (using the "out of the box" installation SQL Server installation utilities) to install SQL Agent on it's own, or to reinstall it over an existing installation.
The fact that no one else has replied to this in the past few days bolsters my confidence in saying that no, it can't be done.
Here's a shot at a work-around: shut down SQL Server, make copies of the system databases (master, msdb, model), uninstall SQL Server (when I've done this in the past the user databases were not touched--we had them in their own folders), reinstall SQL server--using the exact same settings as before (down to collation settings, file locations, and so forth), shut it down, make copies of the "new" system databases, copy them over with the "old" databases, and start it up again. If everything works, you'll be back in business. (I've pulled this stunt once or twice before, but it's not for the faint of heart.)
Philip
June 23, 2005 at 8:58 am
"but it's not for the faint of heart."... certainly not, but the keyword here is BACKUP BEFORE.
June 23, 2005 at 10:33 am
Thanks Philip. Our Network guys thought they could, but I suspected we couldn’t. We had to do the full install. I had backups of master and msdb before the failure. All of the other databases were intact and attached just fine after the installation of SQL Server and the restore of master and msdb. The failure was due to someone manually deleting a registry key, which was for some backup software at used the Agent. This caused the Agent and the Programs Group for SQL Server to disappear. Then they put the SQL Server CD into the Server CD-ROM drive to re-install the Agent. After that the entire instance, we are a single instance installation, of SQL Server was trashed. I have no idea what really happened. For the record here is the sequence of events: 1.) Wed. 6/8 Delete registry key, 2.) Fri. 6/10 7am Re-boot Server for weekly maintenance, 3.) SQL Server Agent is not running (and cannot be started) and the Programs Group for SQL Server is not being listed. 4.) The SQL Server CD is put into the drive and some of the installation runs. 5.) SQL Server stops working completely. This is all I really know. SQL Server was running for 2 days after the registry key was deleted. I can understand that the re-boot of the server would be different with the registry key missing. The Agent and the Program Groups for SQL Server were missing, but the SQL Server service was still working. Then someone did something with the CD in the drive. Oh, they are telling me that they think the SQL Server installation software did an uninstall without notifying the Network Operator.
June 23, 2005 at 9:25 pm
Sound very convoluted... and like most things of that ilk, next to impossible to sort out after (worse, days after) the fact. It sounds like the deleted registry keys were ones read at startup to initialize the system, so their absence wouldn't affect the software running continuously in memory until the next startup.
If it was a "standard" SQL Install disk, nothing would get automatically installed or uninstalle; actions would only be done if and as a user selected options. I haven't tried it, but to install or reinstall software, it might well uninstall first--though I'd think it would prompt for confirmation first.
It is possible to take a SQL Server instance, stop it, copy the master database somewhere else (which is about as good as performing a conventional backup), start SQL Server, goof around, stop it, and copy over the "goofed up" master database with your old copy. (This is hair-raising stuff, you want to get comfortable doing this on a test machine before doing it with live data.) As the master database contains the info on where all the user databases are, this can be useful. Technically you can do this with conventional backups and restores of the master database, but how you could restore over it while actively using it to perform the restore is beyond my comprehension.
Philip
June 24, 2005 at 6:33 am
Thanks again Philip
June 24, 2005 at 12:41 pm
Hi,
My next advice will be valid only in a case if SQL Server can be started. Then you will do steps 1 through 4. If it can not be started, do steps 2 and 3 OR just 2 and 4, whatever approach you like better.
Is it only the registry keys that were deleted? And you don't mind a Fresh Start for Agent?
I had a case where SQL Server keys were deleted by uninstall of one of the applications, it happened on the test server, thank you!
What I did was to export those keys from the fresh install of SQL Server and import them into the server that had keys deleted. Both machines had the same configuration. Since your installation does not work perfectly anyway you may test just importing Agent reg entries from the fresh install on a similar machine.
Before you try that do what Philip is saying:
1. Backup ALL your Databases,user and system including Master, MSDB, Model, all of them, copy out somewhere Backups (just in case)
2. Stop SQL Server, copy somewhere the whole Data directory(directories) containg ALL your and system Databases AND Transaction logs and other directories that you really care for, like Backup directory.
3. After you did 1 and 2 import Agent registry entries from the similar installation. If importing the registry entries for Agent does not work for some reason the go to 4
4. Reinstall SQL Server, apply same Service Packs as Original Copy. Stop SQL Server. Replace Data directory with the Original one (or ones). By Original I mean your original data that you copied out in step 2. It worked for me 2 times.
Yelena
Regards,Yelena Varsha
Viewing 8 posts - 1 through 7 (of 7 total)
You must be logged in to reply to this topic. Login to reply