I have a SQL 2000 (SP3) running on a Windows NT 4.0 (SP6) box used in our test environment. The SQL Server was configured to run under the local system account before I got here. In an effort to standardize things, I tried changing the SQL Service account to run under a designated domain user account purpose built for the job. We use this particular account for all of our new-build servers (which are W2K). This domain account is configured to be a "Power User" on the NT 4.0 Server in question.
Soon after changing things over to run under the new account, all the developers complained that they could no longer connect to the server. I could through QA and EM, but none of the developers could.
The developers are using WebLogic and JDBC drivers for the most part. I wasn't aware that the SQL Server service account affected client connectivity. Was I wrong or is there something else at work here?
Thanks,
hmscottDamn...I'm dealing with something similar right now...
The SSSA run things on behalf of the server...
My guess is that they all connect using sa blank (or whatever, connection pooling id and are still connectiong using sql server auth) and now that it's trusted, their connections are wrong...
How do they connect?
Like when you register a server in EM?
I don't think the service account has anything to do with it...
MOO|||Hi Brett,
They're connecting via various user accounts that are application-specific. Unfortunately, I am only beginning to make progress on convincing management to swing to all trusted connections. The developers insist that WebLogic doesn't support the concept of running under a service account.
Anyway, one guy was using sa, others were using different application accounts. I was able to connect successfully using a trusted connection (but then, I'm a Domain Admin, too, so there's no telling for sure.
It's far from an ideal setup; I'm just trying to correct things bit by bit.
Regards,
Hugh|||Hi Brett,
The developers insist that WebLogic doesn't support the concept of running under a service account.
That may be true...we use websphere and we set a connection pooling account that authenticates through sql server...but it's 1 id and many connections
Anyway, one guy was using sa
Hugh
There's always one...
Still no one is using the SSSA to connect...right?|||No, no one is using that account. I'm sure because the pasword is quite complex and other than being documented in a restricted folder for the DBAs, it's not known.
Thanks for your time...
Regards,
hmscott
Showing posts with label sp3. Show all posts
Showing posts with label sp3. Show all posts
Thursday, March 29, 2012
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)