SQL Server 2000 running on W2K3 Advanced Server Cluster with 2 nodes.
We have a domain level account which the MSSQLSERVER and SQLSERVERAGENT
services use.
When I change the password for this account in active directory, I also
changed the password for the services in the Services properties on both
cluster nodes
The services Startup Type has to be Manual, or else the following error
occurs:
"17050: initerrlog: could not open error log file ... (the correct path
to the error log follows)"
The error log is on the shared drive of the cluster.
Also, when the servers boot up, the following error is in Event Viewer:
"The Data portion of event 19002 from MSSQLServer is invalid"
Microsoft (Q230393) says this is a bug and ignore it, but it didn't occur
until I changed the password.
Are these normal consequences of changing the account password?
Are there other steps I should take?
Thanks
Bill
Go back into Enterprise Manager and change the service accounts there. That
will fix any permissions and setup issues. Service startup type as Manual
is correct. That allows the cluster service to control the actual service
start/stop.
Geoff N. Hiten
Microsoft SQL Server MVP
Senior Database Administrator
"bill" <belgie@.datamti.com> wrote in message
news:uOYfAolLFHA.904@.tk2msftngp13.phx.gbl...
> SQL Server 2000 running on W2K3 Advanced Server Cluster with 2 nodes.
> We have a domain level account which the MSSQLSERVER and SQLSERVERAGENT
> services use.
> When I change the password for this account in active directory, I also
> changed the password for the services in the Services properties on both
> cluster nodes
> The services Startup Type has to be Manual, or else the following error
> occurs:
> "17050: initerrlog: could not open error log file ... (the correct path
> to the error log follows)"
> The error log is on the shared drive of the cluster.
> Also, when the servers boot up, the following error is in Event Viewer:
> "The Data portion of event 19002 from MSSQLServer is invalid"
> Microsoft (Q230393) says this is a bug and ignore it, but it didn't occur
> until I changed the password.
> Are these normal consequences of changing the account password?
> Are there other steps I should take?
> Thanks
> Bill
>
>
Showing posts with label advanced. Show all posts
Showing posts with label advanced. Show all posts
Tuesday, March 20, 2012
changing SQL server service account
Guys,
I have got WINDOWS 2000 Advanced Server and MS SQL SERVER 7.0 running on my live server. Now when we are planning for replication, we have found that SQL server will require to run under a domain account. At the moment there are so many ASP pages running on our server accesses different databases created using SQL server 7.0. Most of them are DSN connections to the database. Now if i create a domain account and restart the server and MS SQL services with the domain account, how is it going to effect the current web pages running on it?
Any help will be greatly appreciated.
ThanksA connection to a database has no bearing on what account starts the sql server service. However the account used does affect how the server interacts with other sql servers, or other machine resources, you found that out when you tried to implement replication using LocalSystem account. You can search msdn for "sql server service account" to get a better understanding of the purpose of accounts for sql server.|||Thanks very much Greg,
your reply helped me to have better understanding.
I would find out more from MSDN as you have suggested.
Cheers.
I have got WINDOWS 2000 Advanced Server and MS SQL SERVER 7.0 running on my live server. Now when we are planning for replication, we have found that SQL server will require to run under a domain account. At the moment there are so many ASP pages running on our server accesses different databases created using SQL server 7.0. Most of them are DSN connections to the database. Now if i create a domain account and restart the server and MS SQL services with the domain account, how is it going to effect the current web pages running on it?
Any help will be greatly appreciated.
ThanksA connection to a database has no bearing on what account starts the sql server service. However the account used does affect how the server interacts with other sql servers, or other machine resources, you found that out when you tried to implement replication using LocalSystem account. You can search msdn for "sql server service account" to get a better understanding of the purpose of accounts for sql server.|||Thanks very much Greg,
your reply helped me to have better understanding.
I would find out more from MSDN as you have suggested.
Cheers.
Sunday, February 19, 2012
Changing horses in midstream...
This is NOT my choice, but I am being forced to plan for migrating my 2 SQL database clusters (SQL 2000 SP3 running on Windows 2000 Advanced Server SP4) from their current SAN environment to a new SAN environment (from EMC Clariion to IBM DS4300).
The SAN hosts a quorum disk, a data disk and a log disk for both clusters. Each cluster is a 2-node Active/Passive cluster.
I have never done anything like this before and neither has the 3rd party contract service provider charged with making it happen. They did prepare a 56-step plan for the migration (plus 14 steps for backing out), but I wondered if anyone here had any experience in this realm.
We have a 4-hour window to complete the migration; realistically that is not enough time to perform a bare-metal install (which I would almost prefer to do). Your thoughts and comments are welcome (prayers are welcome, too).
Regards,
hmscottAssuming that you have two complete sets of hardware (SAN, server, infratructure), this is relatively easy. Run both systems in parallel, loading the new system from a dump of the existing one. At a point in time near cutover, do a full dump/restore. Once you reach user downtime, do a differential backup and restore it to the new box. Change the cluster ip address of the new cluster to that of the existing cluster, and you ought to be "up and running" with little fuss, muss, or bother.
It helped that we did this three times for QA before we had to do it in production. The confidence and having the bugs worked out helped a lot.
-PatP|||Nope, I do not have 2 complete sets of hardware. I have 2 clusters currently running in production (each with 2 nodes). I do not have any additional server hardware to allocate.
I do (or will) have two complete SANs (an existing EMC Clariion CX500 and a proposed IBM DS4300).
I have raised the possibility of consolidating the two clusters prior to the migration (which would yield 2 "free" servers), but this has not yet been accepted (the two clusters operate in different subnets).
Regards,
hmscott
Assuming that you have two complete sets of hardware (SAN, server, infratructure), this is relatively easy. Run both systems in parallel, loading the new system from a dump of the existing one. At a point in time near cutover, do a full dump/restore. Once you reach user downtime, do a differential backup and restore it to the new box. Change the cluster ip address of the new cluster to that of the existing cluster, and you ought to be "up and running" with little fuss, muss, or bother.
It helped that we did this three times for QA before we had to do it in production. The confidence and having the bugs worked out helped a lot.
-PatP|||Ok, then another scenario that we looked at was to install both SANs at the same time. In other words have one SAN available as drive X and the other available as drive Y. Periodically move one database at a time using detach/attach, as database usage permits. This avoids the trauma of dropping the whole load at once, and allows some "practice" on the less critical elements.
It is relatively ugly if you need to move master, model, and msdb too. If you need to do that, then what you have to do becomes a bit more complex, but it isn't a "show stopper" either.
-PatP|||What about the Quorum disk? That's the one I am stuck on. Moving the databases doesn't bother me too much. I've done master, model, tempdb and msdb before; but I am more concerned with MSCS and how it will react.
Thanks for your quick input. I've always been grateful for the responses received here.
hmscott
Ok, then another scenario that we looked at was to install both SANs at the same time. In other words have one SAN available as drive X and the other available as drive Y. Periodically move one database at a time using detach/attach, as database usage permits. This avoids the trauma of dropping the whole load at once, and allows some "practice" on the less critical elements.
It is relatively ugly if you need to move master, model, and msdb too. If you need to do that, then what you have to do becomes a bit more complex, but it isn't a "show stopper" either.
-PatP|||The exact details escape me, but I can find them. The gist of the idea is:
1) Break the SQL cluster
2) Down the SQL Servers
3) Copy the files wholesale disk X to Y
4) Swap drive letters X with Y
5) Bring the SQL Servers back up
6) Reunite (heal) the cluster.
-PatP|||Okay, I think that's what the 3rd party service provider is also saying. I'm still trolling through MS for references on moving the quorum disk. If you know of any KBs off the top of your head, I would be grateful.
Have you done this before? Do you know anyone who has?
Again, thanks for your responses.
Regards,
hmscott
The exact details escape me, but I can find them. The gist of the idea is:
1) Break the SQL cluster
2) Down the SQL Servers
3) Copy the files wholesale disk X to Y
4) Swap drive letters X with Y
5) Bring the SQL Servers back up
6) Reunite (heal) the cluster.
-PatP|||I'd go to IBM for that information. As SAN vendors, they can get propaganda from Redmond that isn't available to mere mortals.
The problem is that from the Microsoft/SQL Server perspective, if you do this little slight of hand right, nothing at all happened. MS-PSS really doesn't do much with it, because from their perspective its a non-issue.
There's an ADC in Dallas that is quite familiar with the process. He's actually done this several times (I've only done this once). I'll see if he can scare up any documentation for the process that he can give me without needing blood first.
-PatP|||That would be most excellent. I have found a few documents on MS support site. Most are only tangentially related, though one seems pretty close to the mark (280353).
I really wish I did not have to do this, but our organization just switched to a single-source contract with IBM.
Thanks again,
hmscott
The SAN hosts a quorum disk, a data disk and a log disk for both clusters. Each cluster is a 2-node Active/Passive cluster.
I have never done anything like this before and neither has the 3rd party contract service provider charged with making it happen. They did prepare a 56-step plan for the migration (plus 14 steps for backing out), but I wondered if anyone here had any experience in this realm.
We have a 4-hour window to complete the migration; realistically that is not enough time to perform a bare-metal install (which I would almost prefer to do). Your thoughts and comments are welcome (prayers are welcome, too).
Regards,
hmscottAssuming that you have two complete sets of hardware (SAN, server, infratructure), this is relatively easy. Run both systems in parallel, loading the new system from a dump of the existing one. At a point in time near cutover, do a full dump/restore. Once you reach user downtime, do a differential backup and restore it to the new box. Change the cluster ip address of the new cluster to that of the existing cluster, and you ought to be "up and running" with little fuss, muss, or bother.
It helped that we did this three times for QA before we had to do it in production. The confidence and having the bugs worked out helped a lot.
-PatP|||Nope, I do not have 2 complete sets of hardware. I have 2 clusters currently running in production (each with 2 nodes). I do not have any additional server hardware to allocate.
I do (or will) have two complete SANs (an existing EMC Clariion CX500 and a proposed IBM DS4300).
I have raised the possibility of consolidating the two clusters prior to the migration (which would yield 2 "free" servers), but this has not yet been accepted (the two clusters operate in different subnets).
Regards,
hmscott
Assuming that you have two complete sets of hardware (SAN, server, infratructure), this is relatively easy. Run both systems in parallel, loading the new system from a dump of the existing one. At a point in time near cutover, do a full dump/restore. Once you reach user downtime, do a differential backup and restore it to the new box. Change the cluster ip address of the new cluster to that of the existing cluster, and you ought to be "up and running" with little fuss, muss, or bother.
It helped that we did this three times for QA before we had to do it in production. The confidence and having the bugs worked out helped a lot.
-PatP|||Ok, then another scenario that we looked at was to install both SANs at the same time. In other words have one SAN available as drive X and the other available as drive Y. Periodically move one database at a time using detach/attach, as database usage permits. This avoids the trauma of dropping the whole load at once, and allows some "practice" on the less critical elements.
It is relatively ugly if you need to move master, model, and msdb too. If you need to do that, then what you have to do becomes a bit more complex, but it isn't a "show stopper" either.
-PatP|||What about the Quorum disk? That's the one I am stuck on. Moving the databases doesn't bother me too much. I've done master, model, tempdb and msdb before; but I am more concerned with MSCS and how it will react.
Thanks for your quick input. I've always been grateful for the responses received here.
hmscott
Ok, then another scenario that we looked at was to install both SANs at the same time. In other words have one SAN available as drive X and the other available as drive Y. Periodically move one database at a time using detach/attach, as database usage permits. This avoids the trauma of dropping the whole load at once, and allows some "practice" on the less critical elements.
It is relatively ugly if you need to move master, model, and msdb too. If you need to do that, then what you have to do becomes a bit more complex, but it isn't a "show stopper" either.
-PatP|||The exact details escape me, but I can find them. The gist of the idea is:
1) Break the SQL cluster
2) Down the SQL Servers
3) Copy the files wholesale disk X to Y
4) Swap drive letters X with Y
5) Bring the SQL Servers back up
6) Reunite (heal) the cluster.
-PatP|||Okay, I think that's what the 3rd party service provider is also saying. I'm still trolling through MS for references on moving the quorum disk. If you know of any KBs off the top of your head, I would be grateful.
Have you done this before? Do you know anyone who has?
Again, thanks for your responses.
Regards,
hmscott
The exact details escape me, but I can find them. The gist of the idea is:
1) Break the SQL cluster
2) Down the SQL Servers
3) Copy the files wholesale disk X to Y
4) Swap drive letters X with Y
5) Bring the SQL Servers back up
6) Reunite (heal) the cluster.
-PatP|||I'd go to IBM for that information. As SAN vendors, they can get propaganda from Redmond that isn't available to mere mortals.
The problem is that from the Microsoft/SQL Server perspective, if you do this little slight of hand right, nothing at all happened. MS-PSS really doesn't do much with it, because from their perspective its a non-issue.
There's an ADC in Dallas that is quite familiar with the process. He's actually done this several times (I've only done this once). I'll see if he can scare up any documentation for the process that he can give me without needing blood first.
-PatP|||That would be most excellent. I have found a few documents on MS support site. Most are only tangentially related, though one seems pretty close to the mark (280353).
I really wish I did not have to do this, but our organization just switched to a single-source contract with IBM.
Thanks again,
hmscott
Subscribe to:
Posts (Atom)