Bad startup parameter on clustered instance

Hello,
I inadvertantly mis-edited the SQL startup parameters on a clustered
instance and now the instance won't start. I'm wondering if there's a quick
fix to correct the problem. (short of uninstall/reinstall <g>)
I've researched this and am aware of the problems changing the local
registry not being persistent due to the cluster-shared reg overwriting the
local version. What I guess I'd like to do is force an overwrite of the
cluster version of the reg setting from the local node. Is there a way to do
this?
Thanks,
Randy Rabin
Well, you shouldn't directly edit the registry entries of a cluster-aware
app like a clustered SQL Server in the first place. That's totally
unsupported. From what you said, you are probably stuck in a vicious cycle.
No matter how hard you try to edit the startup parameter back to its correct
value, your entered value will be overwritted by the bad value, causing the
SQL Server resource to keep failing the startup.
This is because the cluster service checkpoints its changes and basically
replicates the registry changes, and your entered value is overwritten by
the checkpoint saved by the cluster service.
But there is a way to get out of the vicious cycle.
1. Remote console to the node that currently owns the offline SQL Server
group.
2. Open a command prompt on the node, and start up the SQL Server from the
command line with the correct parameters, something like the following:
cmd>sqlservr -sMSSQLSERVER -c -dE:\MSSQL\Data\master.mdl -eE:\MSSQL\Log\errorlog
-le:\MSSQL\Data\master.ldf
** (If this doesn't work, see Note below)
3. Once SQL Server is running, start up Enterprise Manager, and change your
startup parameter(s) there to their correct value. This is critical because
the change made through Enterprise Manager will be saved by the cluster
service in a checkpoint, and will be replicated to the other nodes.
4 . Go to Cluster Administrator, bring up SQL Server resource online.
5. Check the registry entries for the startup parameters to make sure tht
they are still correct, and they should be correct at this point. This step
is not necessarily. But it's just a sanity check.
6. Move the SQL Server resource group to a different node. It should come up
online on that node.
7. Check the registry entries for the startup parameters on the node to make
sure they are correct, and they should be because the startup parameter
value should have been replicated over by the cluster service from the first
node you worked on.
8. Repeat Step 6 and 7 on all the remaining nodes.
**Note that I'm typing this from my recollection. For Step 2, it may also
work if you first edit the local registry to correct the startup parameters,
and then start the SQL Server service on the command line using net start.
If Step 2 as described above doesn't work, give this a try. I know for sure
that this alternative would work for SQL Server 2005 when it's stuck in the
same situation.
***DON'T EVER DIRECTLY EDIT A CLUSTERED SQL SERVER REGISTRY ENTRIES
AGAIN****
Linchi
"Randy Rabin" <randyr@.channeladvisor.com> wrote in message
news:%23mlrK1N0FHA.2212@.TK2MSFTNGP15.phx.gbl...
> Hello,
> I inadvertantly mis-edited the SQL startup parameters on a clustered
> instance and now the instance won't start. I'm wondering if there's a
> quick
> fix to correct the problem. (short of uninstall/reinstall <g>)
> I've researched this and am aware of the problems changing the local
> registry not being persistent due to the cluster-shared reg overwriting
> the
> local version. What I guess I'd like to do is force an overwrite of the
> cluster version of the reg setting from the local node. Is there a way to
> do
> this?
> Thanks,
> Randy Rabin
>
|||Hi Linchi,
Thank you for the response, but I don't appreciate the soapbox. In fact I
*had* used Enterprise Manager to edit the startup parameter in the first
place. EntMgr wrote the incorrect parameter to the cluster-shared copy of
the registry, which then of course got replicated down to the nodes. The
"fix" I had tried was to re-edit the local node's registry (and yes, I never
do this and agree that normally nobody else should either <g>) and obviously
found out quickly that it wasn't going to work.
I did get the SQL instance running again after a 2-hour call to PSS and a
utility that allowed me to reset the value in the cluster-shared copy of the
registry. Thanks for your solution below, perhaps it will help others.
Regards,
Randy
"Linchi Shea" <linchi_shea@.NOSPAMml.om> wrote in message
news:ubi5OCU0FHA.3780@.TK2MSFTNGP12.phx.gbl...
> Well, you shouldn't directly edit the registry entries of a cluster-aware
> app like a clustered SQL Server in the first place. That's totally
> unsupported. From what you said, you are probably stuck in a vicious
cycle.
> No matter how hard you try to edit the startup parameter back to its
correct
> value, your entered value will be overwritted by the bad value, causing
the
> SQL Server resource to keep failing the startup.
> This is because the cluster service checkpoints its changes and basically
> replicates the registry changes, and your entered value is overwritten by
> the checkpoint saved by the cluster service.
> But there is a way to get out of the vicious cycle.
> 1. Remote console to the node that currently owns the offline SQL Server
> group.
> 2. Open a command prompt on the node, and start up the SQL Server from the
> command line with the correct parameters, something like the following:
>
cmd>sqlservr -sMSSQLSERVER -c -dE:\MSSQL\Data\master.mdl -eE:\MSSQL\Log\erro
rlog
> -le:\MSSQL\Data\master.ldf
> ** (If this doesn't work, see Note below)
> 3. Once SQL Server is running, start up Enterprise Manager, and change
your
> startup parameter(s) there to their correct value. This is critical
because
> the change made through Enterprise Manager will be saved by the cluster
> service in a checkpoint, and will be replicated to the other nodes.
> 4 . Go to Cluster Administrator, bring up SQL Server resource online.
> 5. Check the registry entries for the startup parameters to make sure tht
> they are still correct, and they should be correct at this point. This
step
> is not necessarily. But it's just a sanity check.
> 6. Move the SQL Server resource group to a different node. It should come
up
> online on that node.
> 7. Check the registry entries for the startup parameters on the node to
make
> sure they are correct, and they should be because the startup parameter
> value should have been replicated over by the cluster service from the
first
> node you worked on.
> 8. Repeat Step 6 and 7 on all the remaining nodes.
> **Note that I'm typing this from my recollection. For Step 2, it may also
> work if you first edit the local registry to correct the startup
parameters,
> and then start the SQL Server service on the command line using net start.
> If Step 2 as described above doesn't work, give this a try. I know for
sure
> that this alternative would work for SQL Server 2005 when it's stuck in
the[vbcol=seagreen]
> same situation.
> ***DON'T EVER DIRECTLY EDIT A CLUSTERED SQL SERVER REGISTRY ENTRIES
> AGAIN****
> Linchi
>
> "Randy Rabin" <randyr@.channeladvisor.com> wrote in message
> news:%23mlrK1N0FHA.2212@.TK2MSFTNGP15.phx.gbl...
to
>