Hi All,
We have a 2 node cluster running SQL Server 2000 on Windows 2000 which
needs replacing. The nature of our business is 24 hour operation, so
the downtime to do such needs to be as small as possible.
We have a new cluster ready and waiting in our data centre that is
built on Windows 2003 with SQL Server 2000.
Our issues are:
=B7Configuring all the applications to the new Cluster Name / IP
Address - In the past we have found things hard-coded
=B7Migrate all the data (~100GB) over to the new MSA
=B7Smallest downtime possible
The idea's we have come up with already are:
=B7Frigg DNS to point the old cluster name to the new cluster name and
then migrate all the applications to the new name as time permits.
=B7Rename the new nodes as <NAME>3/4 and add these into the existing
cluster; however the MSA is directly connected to Nodes 1/2.
=B7Remove 1 node from the old cluster, add a new node in, fail-over to
new node, remove 2nd old node, add new node, however I'm thinking
this may not work?
Another consideration is that we use SecurePath on the MSA's so this
could be a PITA.
Does anyone have any other suggestions which we could consider?
Thanks
Well, since you asked.
You could do a minimally disruptive replacement by replacing each node with
one of the new nodes. Uninstall SQL from the "other" node, evict the node,
add the node, run the SQL nstaller to install and configure SQL on the new
node. Wait for maintenance window and do a failover test. Repeat with the
other node.
The other process I use to migrate systems is to run a custom log ship
script (they aren't that hard to write, google will point to some nice free
examples.) to get them ready. Do a final log backup and put the old
databases into norecovery mode. Do a final catch up and go live on the new
system. Patch DNS (hint, use the SRV record type). and go. I can switch
over a typical server with 10-30 databases with less than 10 minutes of
downtime this way.
Geoff N. Hiten
Senior Database Administrator
Microsoft SQL Server MVP
"Steve" <SMaxwell@.NationalExpress.com> wrote in message
news:1160476240.405910.76230@.e3g2000cwe.googlegrou ps.com...
Hi All,
We have a 2 node cluster running SQL Server 2000 on Windows 2000 which
needs replacing. The nature of our business is 24 hour operation, so
the downtime to do such needs to be as small as possible.
We have a new cluster ready and waiting in our data centre that is
built on Windows 2003 with SQL Server 2000.
Our issues are:
Configuring all the applications to the new Cluster Name / IP
Address - In the past we have found things hard-coded
Migrate all the data (~100GB) over to the new MSA
Smallest downtime possible
The idea's we have come up with already are:
Frigg DNS to point the old cluster name to the new cluster name and
then migrate all the applications to the new name as time permits.
Rename the new nodes as <NAME>3/4 and add these into the existing
cluster; however the MSA is directly connected to Nodes 1/2.
Remove 1 node from the old cluster, add a new node in, fail-over to
new node, remove 2nd old node, add new node, however I'm thinking
this may not work?
Another consideration is that we use SecurePath on the MSA's so this
could be a PITA.
Does anyone have any other suggestions which we could consider?
Thanks
Showing posts with label cluster. Show all posts
Showing posts with label cluster. Show all posts
Wednesday, March 28, 2012
migrating cluster instances to stand alone install
Hello all: looking for some general advice on proper approach. looking to move databases off of a clustered instance to a new (non-clustered) server.
Got several issues i'd like some advice on.
1. This is an OLTP instance that's been around for a while & it's pretty well encrusted with apps & processes that attach to it. Therefore it would be a very good thing if we didn't need to change the connection information in several hundred places after the move.
I've tested one approach to this that seems to work: moved the instance to a server which has the same name as the cluster resource associated with the clustered instance and an instance that has the same name as the clustered instance.
For example: cluster install is aiproddb\production, moved it to a box called aiproddb with a named instance called "production". There's a bunch of tedious network stuff that has to be done to make this work (binding an IP address to the MAC address of the new box and some murky DHCP reservation fiddling), but after the network crew got done cursing me it did finally work.
Does this seem like a reasonable approach?
2. What's the best way to transfer security info to the new instance? I used the transfer Logins DTS widget but had some problems with it not being able to find some groups in AD.
3. what's the best way to transfer DTS packages?
4. is it necessary for the new instance to be at the same patch level as the old instance? the old clustered instance is still at SP3 and i threw the latest SP4 on the new location. good/bad/indifferent?
5. i was planning on taking a full backup & restoring it to the new machine. Is there a better way? Is the wizard for copying databases a good thing?
Those are these issues i'm aware of and have given some thought to. There are probably things about this i haven't considered and would appreciate some word on.
thanks,
Garth:D 5. [...] Is the wizard for copying databases a good thing?
thanks,
Garth
NOOOOOOOOOOOOOOOOOOOOOOOOOOOO!!!!!!!!!!!!!!!!!!
:D
hmscott|||ok. that's one vote against the copy database wizard...|||Hello all: looking for some general advice on proper approach. looking to move databases off of a clustered instance to a new (non-clustered) server.
Got several issues i'd like some advice on.
1. This is an OLTP instance that's been around for a while & it's pretty well encrusted with apps & processes that attach to it. Therefore it would be a very good thing if we didn't need to change the connection information in several hundred places after the move.
I've tested one approach to this that seems to work: moved the instance to a server which has the same name as the cluster resource associated with the clustered instance and an instance that has the same name as the clustered instance.
I know this does not help you now, but in the future, try adding a layer of virtualization in between by using a DNS zone specific to your apps. Then you can move physical servers in and out of production smoothly without impacting application connection strings. Use one DNS A record per database (e.g. MyDB.dev.apps, MySecondDB.dev.apps and MyDB.test.apps and MySecondDB.test.apps). The apps point to the DNS name, the DNS name translates to a physical IP. When it comes time to migrate a database (or an entire server) you have one place to go to update IP addresses (the DNS server).
2. What's the best way to transfer security info to the new instance? I used the transfer Logins DTS widget but had some problems with it not being able to find some groups in AD.
Try exporting the logins to a file, cull selected logins that you don't want/need (sa comes to mind) and then inserting them with proper syntax. Somewhere there is an MS article about using BCP to do this. If I recall correctly, use "bcp log shipping sgl server logins" for your google. I also did it by copying and pasting into an Excel spreadsheet and then using formulae to build the SQL syntax. Crude, but it worked.
This will only build the logins and it will not link the users within the database to the logins (SID mismatch). For that you can use sp_change_users_login.
3. what's the best way to transfer DTS packages?
Depends on how much of your connection info is embedded. A while back I posted a script for backing up DTS packages to a structured file. If there aren't too many, this is a workable approach.
By the way, is this an upgrade to SQL 2005, or a lateral to another SQL 2000 instance? If the former, you have more work cut out for you. If the latter, you should really consider the former (ie, you should be working on an upgrade).
4. is it necessary for the new instance to be at the same patch level as the old instance? the old clustered instance is still at SP3 and i threw the latest SP4 on the new location. good/bad/indifferent?
Should be all right. Watch the AWE memory thing with SP4, but I don't remember specific issues with SP4. Be careful if you are using replication.
5. i was planning on taking a full backup & restoring it to the new machine. Is there a better way?
sp_detach and sp_attach?
The advantage with your method (if you have a large database) is that you can do a partial restore (which might take a long time) and then apply just the last log file to bring the new instance up to date to minimize your outage.
Is the wizard for copying databases a good thing?
Noooooooooooooooo!!!!!
But enough on that subject :D .
Those are these issues i'm aware of and have given some thought to. There are probably things about this i haven't considered and would appreciate some word on.
thanks,
Garth
Test, test, test, practice, practice, practice.
Good luck.
Regards,
hmscott
Got several issues i'd like some advice on.
1. This is an OLTP instance that's been around for a while & it's pretty well encrusted with apps & processes that attach to it. Therefore it would be a very good thing if we didn't need to change the connection information in several hundred places after the move.
I've tested one approach to this that seems to work: moved the instance to a server which has the same name as the cluster resource associated with the clustered instance and an instance that has the same name as the clustered instance.
For example: cluster install is aiproddb\production, moved it to a box called aiproddb with a named instance called "production". There's a bunch of tedious network stuff that has to be done to make this work (binding an IP address to the MAC address of the new box and some murky DHCP reservation fiddling), but after the network crew got done cursing me it did finally work.
Does this seem like a reasonable approach?
2. What's the best way to transfer security info to the new instance? I used the transfer Logins DTS widget but had some problems with it not being able to find some groups in AD.
3. what's the best way to transfer DTS packages?
4. is it necessary for the new instance to be at the same patch level as the old instance? the old clustered instance is still at SP3 and i threw the latest SP4 on the new location. good/bad/indifferent?
5. i was planning on taking a full backup & restoring it to the new machine. Is there a better way? Is the wizard for copying databases a good thing?
Those are these issues i'm aware of and have given some thought to. There are probably things about this i haven't considered and would appreciate some word on.
thanks,
Garth:D 5. [...] Is the wizard for copying databases a good thing?
thanks,
Garth
NOOOOOOOOOOOOOOOOOOOOOOOOOOOO!!!!!!!!!!!!!!!!!!
:D
hmscott|||ok. that's one vote against the copy database wizard...|||Hello all: looking for some general advice on proper approach. looking to move databases off of a clustered instance to a new (non-clustered) server.
Got several issues i'd like some advice on.
1. This is an OLTP instance that's been around for a while & it's pretty well encrusted with apps & processes that attach to it. Therefore it would be a very good thing if we didn't need to change the connection information in several hundred places after the move.
I've tested one approach to this that seems to work: moved the instance to a server which has the same name as the cluster resource associated with the clustered instance and an instance that has the same name as the clustered instance.
I know this does not help you now, but in the future, try adding a layer of virtualization in between by using a DNS zone specific to your apps. Then you can move physical servers in and out of production smoothly without impacting application connection strings. Use one DNS A record per database (e.g. MyDB.dev.apps, MySecondDB.dev.apps and MyDB.test.apps and MySecondDB.test.apps). The apps point to the DNS name, the DNS name translates to a physical IP. When it comes time to migrate a database (or an entire server) you have one place to go to update IP addresses (the DNS server).
2. What's the best way to transfer security info to the new instance? I used the transfer Logins DTS widget but had some problems with it not being able to find some groups in AD.
Try exporting the logins to a file, cull selected logins that you don't want/need (sa comes to mind) and then inserting them with proper syntax. Somewhere there is an MS article about using BCP to do this. If I recall correctly, use "bcp log shipping sgl server logins" for your google. I also did it by copying and pasting into an Excel spreadsheet and then using formulae to build the SQL syntax. Crude, but it worked.
This will only build the logins and it will not link the users within the database to the logins (SID mismatch). For that you can use sp_change_users_login.
3. what's the best way to transfer DTS packages?
Depends on how much of your connection info is embedded. A while back I posted a script for backing up DTS packages to a structured file. If there aren't too many, this is a workable approach.
By the way, is this an upgrade to SQL 2005, or a lateral to another SQL 2000 instance? If the former, you have more work cut out for you. If the latter, you should really consider the former (ie, you should be working on an upgrade).
4. is it necessary for the new instance to be at the same patch level as the old instance? the old clustered instance is still at SP3 and i threw the latest SP4 on the new location. good/bad/indifferent?
Should be all right. Watch the AWE memory thing with SP4, but I don't remember specific issues with SP4. Be careful if you are using replication.
5. i was planning on taking a full backup & restoring it to the new machine. Is there a better way?
sp_detach and sp_attach?
The advantage with your method (if you have a large database) is that you can do a partial restore (which might take a long time) and then apply just the last log file to bring the new instance up to date to minimize your outage.
Is the wizard for copying databases a good thing?
Noooooooooooooooo!!!!!
But enough on that subject :D .
Those are these issues i'm aware of and have given some thought to. There are probably things about this i haven't considered and would appreciate some word on.
thanks,
Garth
Test, test, test, practice, practice, practice.
Good luck.
Regards,
hmscott
Monday, March 26, 2012
Migrating an app from one cluster to another .. with the same name
Currently migrating a SQL application from an old Win2k cluster to some new
hardware.
The new hardware will run as a Win2K3SP1 cluster.
The App people would like to keep the names the same for all servers and
virtual services so that clients are not affected.
Downtime is not an option.
Whats the easiest way to do this?
Consider a DNS alias.
Tom
Thomas A. Moreau, BSc, PhD, MCSE, MCDBA
SQL Server MVP
Columnist, SQL Server Professional
Toronto, ON Canada
www.pinpub.com
..
"Rory Niland" <RoryNiland@.discussions.microsoft.com> wrote in message
news:DDCB983B-3F22-4360-8E07-91B02887ABB3@.microsoft.com...
Currently migrating a SQL application from an old Win2k cluster to some new
hardware.
The new hardware will run as a Win2K3SP1 cluster.
The App people would like to keep the names the same for all servers and
virtual services so that clients are not affected.
Downtime is not an option.
Whats the easiest way to do this?
|||Agreed, because you can't rename a SQL machine.
Cheers,
Rod
MVP - Windows Server - Clustering
http://www.nw-america.com - Clustering Website
http://www.msmvps.com/clustering - Blog
"Tom Moreau" <tom@.dont.spam.me.cips.ca> wrote in message
news:OvlMaCNcFHA.580@.TK2MSFTNGP15.phx.gbl...
> Consider a DNS alias.
> --
> Tom
> ----
> Thomas A. Moreau, BSc, PhD, MCSE, MCDBA
> SQL Server MVP
> Columnist, SQL Server Professional
> Toronto, ON Canada
> www.pinpub.com
> .
> "Rory Niland" <RoryNiland@.discussions.microsoft.com> wrote in message
> news:DDCB983B-3F22-4360-8E07-91B02887ABB3@.microsoft.com...
> Currently migrating a SQL application from an old Win2k cluster to some
> new
> hardware.
> The new hardware will run as a Win2K3SP1 cluster.
> The App people would like to keep the names the same for all servers and
> virtual services so that clients are not affected.
> Downtime is not an option.
> Whats the easiest way to do this?
>
hardware.
The new hardware will run as a Win2K3SP1 cluster.
The App people would like to keep the names the same for all servers and
virtual services so that clients are not affected.
Downtime is not an option.
Whats the easiest way to do this?
Consider a DNS alias.
Tom
Thomas A. Moreau, BSc, PhD, MCSE, MCDBA
SQL Server MVP
Columnist, SQL Server Professional
Toronto, ON Canada
www.pinpub.com
..
"Rory Niland" <RoryNiland@.discussions.microsoft.com> wrote in message
news:DDCB983B-3F22-4360-8E07-91B02887ABB3@.microsoft.com...
Currently migrating a SQL application from an old Win2k cluster to some new
hardware.
The new hardware will run as a Win2K3SP1 cluster.
The App people would like to keep the names the same for all servers and
virtual services so that clients are not affected.
Downtime is not an option.
Whats the easiest way to do this?
|||Agreed, because you can't rename a SQL machine.
Cheers,
Rod
MVP - Windows Server - Clustering
http://www.nw-america.com - Clustering Website
http://www.msmvps.com/clustering - Blog
"Tom Moreau" <tom@.dont.spam.me.cips.ca> wrote in message
news:OvlMaCNcFHA.580@.TK2MSFTNGP15.phx.gbl...
> Consider a DNS alias.
> --
> Tom
> ----
> Thomas A. Moreau, BSc, PhD, MCSE, MCDBA
> SQL Server MVP
> Columnist, SQL Server Professional
> Toronto, ON Canada
> www.pinpub.com
> .
> "Rory Niland" <RoryNiland@.discussions.microsoft.com> wrote in message
> news:DDCB983B-3F22-4360-8E07-91B02887ABB3@.microsoft.com...
> Currently migrating a SQL application from an old Win2k cluster to some
> new
> hardware.
> The new hardware will run as a Win2K3SP1 cluster.
> The App people would like to keep the names the same for all servers and
> virtual services so that clients are not affected.
> Downtime is not an option.
> Whats the easiest way to do this?
>
migrating a SQL Cluster to new hardware
I need your advise on migrating a two node SQL 2000 cluster to new hardware
including servers and disks.
thanks.
Amila
Create a new cluster with the new hardware, install a SQL instance, and then
migrate the databases over to the new instance (e.g. following steps in
http://vyaskn.tripod.com/moving_sql_server.htm and its referenced articles).
If the shared drives are presented from a SAN, you can remove the drives
from the cluster, create a new cluster, install a SQL instance in exactly the
same way as the existing SQL instance, and present the shared drives to the
new cluster.
If you can afford the downtime, and want to keep the server names, you can
remove the shared drives (LUNs), deactivate the cluster nodes, create a new
cluster with the same node names, cluster names, and virtual server names,
install a SQL instance, and present the same LUNs to the new cluster. The new
SQL instance can come up exactly the same as the previous one.
You may also try to perform the so-called rolling upgrade, i.e. upgrade one
node to new hardware a time.
Which method to choose depends on your upgrade requirements.
Linchi
"Amila chandrasekera" wrote:
> I need your advise on migrating a two node SQL 2000 cluster to new hardware
> including servers and disks.
>
> thanks.
> Amila
>
>
|||We have done both of what Linchi suggested: new system build/disk migration
versus node rebuild/upgrade.
The new cluster build is cleaner/easier, but then your applications have to
be migrated to the new host name (unless you can incur the long outage).
The node rebuild/upgrade is not quite as clean, but it minimizes the impact
to your end users.
Check out the maintenance and troubleshooting sections of the following
guide. There is also a link at the top that directs you to the 2005 doc as
well. Read both.
http://www.microsoft.com/technet/prodtechnol/sql/2000/maintain/failclus.mspx#E14AG
The short sequence is:
Uninstall passive node from the sql server setup.
Evict passive node from cluster administrator.
Rebuild passive node.
Join rebuilt node through cluster administrator.
Install rebuilt node to sql server setup.
Patch sql server rebuilt node to current patch + hotfix as active node.
Move over resources and repeat for each cluster node.
Sincerely,
Anthony Thomas
"Amila chandrasekera" <achandra@.insight.com> wrote in message
news:%23h6t5u7SHHA.412@.TK2MSFTNGP02.phx.gbl...
> I need your advise on migrating a two node SQL 2000 cluster to new
hardware
> including servers and disks.
>
> thanks.
> Amila
>
|||Run upgrade advisor to detect upgrade issues, run checkdb on the databases
on the clusters, detach them, copy them (do not move them) to the new
cluster, attach them, run checkdb, update statistics, back them up. Migrate
all dependencies (logins, jobs, extended stored procedures, com objects and
file paths).
Check all functionality on the new cluster. Roll back if you have to by
reattaching the existing database on the old cluster.
repoint the client applications.
You might want to review all methods to do this in the
http://download.microsoft.com/download/1/6/c/16c0ec7a-bb53-4aea-9020-cb2f80424322/SQL2005UpgradeTechRef.doc
Hilary Cotter
Looking for a SQL Server replication book?
http://www.nwsu.com/0974973602.html
Looking for a FAQ on Indexing Services/SQL FTS
http://www.indexserverfaq.com
"Amila chandrasekera" <achandra@.insight.com> wrote in message
news:%23h6t5u7SHHA.412@.TK2MSFTNGP02.phx.gbl...
>I need your advise on migrating a two node SQL 2000 cluster to new hardware
>including servers and disks.
>
> thanks.
> Amila
>
|||Thanks for the replies so far. This migration is from SQL 2000 to SQL 2000
(both source and target are running on Windows 2003 Advanced server). I am
not planning to do a SQL 2005 upgrade with this migration. It is purely a
hardware upgrade only.
Here is what I am thinking of doing.
Asume Node1 and Node2 are the current production SQL cluster nodes.
Node3 and Node4 are the new servers.
1. Move all cluster roles to Node1
2. Evict node2 from the cluster
3. Conect Node3 and join it to the cluster
4. Move all cluster roles to Node3
5. Evict Node1 from cluster
6. Connect Node4 and join it to the cluster
7. Connect Node3 and Node4 to the new SAN (while connected to the old SAN )
8. Setup Quorum and data stores in the new SAN
9. Move Quorum to the new SAN
10. Shutdown the SQL Server
11. Copy SQL DBs from old SAN to the new SAN. Change Drive letter mappings
to maintain the paths.
12. Disconnect old SAN connection completely.
13. Start SQL Server
Is this feasible ? Am I missing anything here ?
"Amila chandrasekera" <achandra@.insight.com> wrote in message
news:%23h6t5u7SHHA.412@.TK2MSFTNGP02.phx.gbl...
>I need your advise on migrating a two node SQL 2000 cluster to new hardware
>including servers and disks.
>
> thanks.
> Amila
>
|||Before eviting the nodes, you have to run the SQL installer to remove the
node from the SQL cluster configuration. You cn run it afterwards and force
it out, but that takes longer. You also have to run the installer and
install SQL to the new nodes. You then need to re-apply any service packs.
GNH
"Amila chandrasekera" <achandra@.insight.com> wrote in message
news:OGAFgGFUHHA.1212@.TK2MSFTNGP03.phx.gbl...
> Thanks for the replies so far. This migration is from SQL 2000 to SQL 2000
> (both source and target are running on Windows 2003 Advanced server). I am
> not planning to do a SQL 2005 upgrade with this migration. It is purely a
> hardware upgrade only.
> Here is what I am thinking of doing.
> Asume Node1 and Node2 are the current production SQL cluster nodes.
> Node3 and Node4 are the new servers.
> 1. Move all cluster roles to Node1
> 2. Evict node2 from the cluster
> 3. Conect Node3 and join it to the cluster
> 4. Move all cluster roles to Node3
> 5. Evict Node1 from cluster
> 6. Connect Node4 and join it to the cluster
> 7. Connect Node3 and Node4 to the new SAN (while connected to the old
> SAN )
> 8. Setup Quorum and data stores in the new SAN
> 9. Move Quorum to the new SAN
> 10. Shutdown the SQL Server
> 11. Copy SQL DBs from old SAN to the new SAN. Change Drive letter mappings
> to maintain the paths.
> 12. Disconnect old SAN connection completely.
> 13. Start SQL Server
> Is this feasible ? Am I missing anything here ?
>
> "Amila chandrasekera" <achandra@.insight.com> wrote in message
> news:%23h6t5u7SHHA.412@.TK2MSFTNGP02.phx.gbl...
>
|||How Can I remove SQL after evicting the node ?
"Geoff N. Hiten" <SQLCraftsman@.gmail.com> wrote in message
news:OQ5q9KFUHHA.1180@.TK2MSFTNGP05.phx.gbl...
> Before eviting the nodes, you have to run the SQL installer to remove the
> node from the SQL cluster configuration. You cn run it afterwards and
> force it out, but that takes longer. You also have to run the installer
> and install SQL to the new nodes. You then need to re-apply any service
> packs.
> GNH
>
> "Amila chandrasekera" <achandra@.insight.com> wrote in message
> news:OGAFgGFUHHA.1212@.TK2MSFTNGP03.phx.gbl...
>
|||Go ahead and run the installer on the remaining node. When you remove the
evicted node from SQL the installer will time out and isue a warning, but it
will remove it from the SQL configuration.
Geoff N. Hiten
Senior Database Administrator
Microsoft SQL Server MVP
"Amila chandrasekera" <achandra@.insight.com> wrote in message
news:e9erf1pVHHA.3568@.TK2MSFTNGP06.phx.gbl...
> How Can I remove SQL after evicting the node ?
> "Geoff N. Hiten" <SQLCraftsman@.gmail.com> wrote in message
> news:OQ5q9KFUHHA.1180@.TK2MSFTNGP05.phx.gbl...
>
|||You can also remove it manually, but the Best Practice is to use the SQL
Server setup instead.
http://support.microsoft.com/kb/290991/en-us
Sincerely,
Anthony Thomas
"Geoff N. Hiten" <SQLCraftsman@.gmail.com> wrote in message
news:O84Iu3qVHHA.4964@.TK2MSFTNGP06.phx.gbl...
> Go ahead and run the installer on the remaining node. When you remove the
> evicted node from SQL the installer will time out and isue a warning, but
it[vbcol=seagreen]
> will remove it from the SQL configuration.
>
> --
> Geoff N. Hiten
> Senior Database Administrator
> Microsoft SQL Server MVP
>
> "Amila chandrasekera" <achandra@.insight.com> wrote in message
> news:e9erf1pVHHA.3568@.TK2MSFTNGP06.phx.gbl...
the[vbcol=seagreen]
installer[vbcol=seagreen]
service[vbcol=seagreen]
migration.
>
including servers and disks.
thanks.
Amila
Create a new cluster with the new hardware, install a SQL instance, and then
migrate the databases over to the new instance (e.g. following steps in
http://vyaskn.tripod.com/moving_sql_server.htm and its referenced articles).
If the shared drives are presented from a SAN, you can remove the drives
from the cluster, create a new cluster, install a SQL instance in exactly the
same way as the existing SQL instance, and present the shared drives to the
new cluster.
If you can afford the downtime, and want to keep the server names, you can
remove the shared drives (LUNs), deactivate the cluster nodes, create a new
cluster with the same node names, cluster names, and virtual server names,
install a SQL instance, and present the same LUNs to the new cluster. The new
SQL instance can come up exactly the same as the previous one.
You may also try to perform the so-called rolling upgrade, i.e. upgrade one
node to new hardware a time.
Which method to choose depends on your upgrade requirements.
Linchi
"Amila chandrasekera" wrote:
> I need your advise on migrating a two node SQL 2000 cluster to new hardware
> including servers and disks.
>
> thanks.
> Amila
>
>
|||We have done both of what Linchi suggested: new system build/disk migration
versus node rebuild/upgrade.
The new cluster build is cleaner/easier, but then your applications have to
be migrated to the new host name (unless you can incur the long outage).
The node rebuild/upgrade is not quite as clean, but it minimizes the impact
to your end users.
Check out the maintenance and troubleshooting sections of the following
guide. There is also a link at the top that directs you to the 2005 doc as
well. Read both.
http://www.microsoft.com/technet/prodtechnol/sql/2000/maintain/failclus.mspx#E14AG
The short sequence is:
Uninstall passive node from the sql server setup.
Evict passive node from cluster administrator.
Rebuild passive node.
Join rebuilt node through cluster administrator.
Install rebuilt node to sql server setup.
Patch sql server rebuilt node to current patch + hotfix as active node.
Move over resources and repeat for each cluster node.
Sincerely,
Anthony Thomas
"Amila chandrasekera" <achandra@.insight.com> wrote in message
news:%23h6t5u7SHHA.412@.TK2MSFTNGP02.phx.gbl...
> I need your advise on migrating a two node SQL 2000 cluster to new
hardware
> including servers and disks.
>
> thanks.
> Amila
>
|||Run upgrade advisor to detect upgrade issues, run checkdb on the databases
on the clusters, detach them, copy them (do not move them) to the new
cluster, attach them, run checkdb, update statistics, back them up. Migrate
all dependencies (logins, jobs, extended stored procedures, com objects and
file paths).
Check all functionality on the new cluster. Roll back if you have to by
reattaching the existing database on the old cluster.
repoint the client applications.
You might want to review all methods to do this in the
http://download.microsoft.com/download/1/6/c/16c0ec7a-bb53-4aea-9020-cb2f80424322/SQL2005UpgradeTechRef.doc
Hilary Cotter
Looking for a SQL Server replication book?
http://www.nwsu.com/0974973602.html
Looking for a FAQ on Indexing Services/SQL FTS
http://www.indexserverfaq.com
"Amila chandrasekera" <achandra@.insight.com> wrote in message
news:%23h6t5u7SHHA.412@.TK2MSFTNGP02.phx.gbl...
>I need your advise on migrating a two node SQL 2000 cluster to new hardware
>including servers and disks.
>
> thanks.
> Amila
>
|||Thanks for the replies so far. This migration is from SQL 2000 to SQL 2000
(both source and target are running on Windows 2003 Advanced server). I am
not planning to do a SQL 2005 upgrade with this migration. It is purely a
hardware upgrade only.
Here is what I am thinking of doing.
Asume Node1 and Node2 are the current production SQL cluster nodes.
Node3 and Node4 are the new servers.
1. Move all cluster roles to Node1
2. Evict node2 from the cluster
3. Conect Node3 and join it to the cluster
4. Move all cluster roles to Node3
5. Evict Node1 from cluster
6. Connect Node4 and join it to the cluster
7. Connect Node3 and Node4 to the new SAN (while connected to the old SAN )
8. Setup Quorum and data stores in the new SAN
9. Move Quorum to the new SAN
10. Shutdown the SQL Server
11. Copy SQL DBs from old SAN to the new SAN. Change Drive letter mappings
to maintain the paths.
12. Disconnect old SAN connection completely.
13. Start SQL Server
Is this feasible ? Am I missing anything here ?
"Amila chandrasekera" <achandra@.insight.com> wrote in message
news:%23h6t5u7SHHA.412@.TK2MSFTNGP02.phx.gbl...
>I need your advise on migrating a two node SQL 2000 cluster to new hardware
>including servers and disks.
>
> thanks.
> Amila
>
|||Before eviting the nodes, you have to run the SQL installer to remove the
node from the SQL cluster configuration. You cn run it afterwards and force
it out, but that takes longer. You also have to run the installer and
install SQL to the new nodes. You then need to re-apply any service packs.
GNH
"Amila chandrasekera" <achandra@.insight.com> wrote in message
news:OGAFgGFUHHA.1212@.TK2MSFTNGP03.phx.gbl...
> Thanks for the replies so far. This migration is from SQL 2000 to SQL 2000
> (both source and target are running on Windows 2003 Advanced server). I am
> not planning to do a SQL 2005 upgrade with this migration. It is purely a
> hardware upgrade only.
> Here is what I am thinking of doing.
> Asume Node1 and Node2 are the current production SQL cluster nodes.
> Node3 and Node4 are the new servers.
> 1. Move all cluster roles to Node1
> 2. Evict node2 from the cluster
> 3. Conect Node3 and join it to the cluster
> 4. Move all cluster roles to Node3
> 5. Evict Node1 from cluster
> 6. Connect Node4 and join it to the cluster
> 7. Connect Node3 and Node4 to the new SAN (while connected to the old
> SAN )
> 8. Setup Quorum and data stores in the new SAN
> 9. Move Quorum to the new SAN
> 10. Shutdown the SQL Server
> 11. Copy SQL DBs from old SAN to the new SAN. Change Drive letter mappings
> to maintain the paths.
> 12. Disconnect old SAN connection completely.
> 13. Start SQL Server
> Is this feasible ? Am I missing anything here ?
>
> "Amila chandrasekera" <achandra@.insight.com> wrote in message
> news:%23h6t5u7SHHA.412@.TK2MSFTNGP02.phx.gbl...
>
|||How Can I remove SQL after evicting the node ?
"Geoff N. Hiten" <SQLCraftsman@.gmail.com> wrote in message
news:OQ5q9KFUHHA.1180@.TK2MSFTNGP05.phx.gbl...
> Before eviting the nodes, you have to run the SQL installer to remove the
> node from the SQL cluster configuration. You cn run it afterwards and
> force it out, but that takes longer. You also have to run the installer
> and install SQL to the new nodes. You then need to re-apply any service
> packs.
> GNH
>
> "Amila chandrasekera" <achandra@.insight.com> wrote in message
> news:OGAFgGFUHHA.1212@.TK2MSFTNGP03.phx.gbl...
>
|||Go ahead and run the installer on the remaining node. When you remove the
evicted node from SQL the installer will time out and isue a warning, but it
will remove it from the SQL configuration.
Geoff N. Hiten
Senior Database Administrator
Microsoft SQL Server MVP
"Amila chandrasekera" <achandra@.insight.com> wrote in message
news:e9erf1pVHHA.3568@.TK2MSFTNGP06.phx.gbl...
> How Can I remove SQL after evicting the node ?
> "Geoff N. Hiten" <SQLCraftsman@.gmail.com> wrote in message
> news:OQ5q9KFUHHA.1180@.TK2MSFTNGP05.phx.gbl...
>
|||You can also remove it manually, but the Best Practice is to use the SQL
Server setup instead.
http://support.microsoft.com/kb/290991/en-us
Sincerely,
Anthony Thomas
"Geoff N. Hiten" <SQLCraftsman@.gmail.com> wrote in message
news:O84Iu3qVHHA.4964@.TK2MSFTNGP06.phx.gbl...
> Go ahead and run the installer on the remaining node. When you remove the
> evicted node from SQL the installer will time out and isue a warning, but
it[vbcol=seagreen]
> will remove it from the SQL configuration.
>
> --
> Geoff N. Hiten
> Senior Database Administrator
> Microsoft SQL Server MVP
>
> "Amila chandrasekera" <achandra@.insight.com> wrote in message
> news:e9erf1pVHHA.3568@.TK2MSFTNGP06.phx.gbl...
the[vbcol=seagreen]
installer[vbcol=seagreen]
service[vbcol=seagreen]
migration.
>
Migrate Windows 2000 cluster to Windows 2003
Hi,
I am trying to determine the best method for rebuilding some existing
Windows 2000 clusters to Windows 2003. I have both SQL clusters and
some application clusters.
I do not want to upgrade the OS, but rather rebuild from scratch, one
node at a time, using the existing hardware. Is this possible? I am
having a hard time finding documentation on the best process for this
and want to follow the method which will provide me with the smallest
amount of downtime.
thanks for your help!
http://support.microsoft.com/?kbid=313037 explains how to upgrade, but like
you said, you really want to migrate. You can rebuild one node as a time,
and then rejoin the cluster.
Cheers,
Rod
MVP - Windows Server - Clustering
http://www.nw-america.com - Clustering
http://msmvps.com/clustering - Blog
"Mel" <Qtip027@.hotmail.com> wrote in message
news:a29a42e2.0411301100.34356ad9@.posting.google.c om...
> Hi,
> I am trying to determine the best method for rebuilding some existing
> Windows 2000 clusters to Windows 2003. I have both SQL clusters and
> some application clusters.
> I do not want to upgrade the OS, but rather rebuild from scratch, one
> node at a time, using the existing hardware. Is this possible? I am
> having a hard time finding documentation on the best process for this
> and want to follow the method which will provide me with the smallest
> amount of downtime.
> thanks for your help!
|||Been there, done that, bought the t-shirt. I prefer a mixed solution.
Upgrade THEN reload the OS. More work but less risk. Biggest thing is to
make absolutely sure you have correct 2003 drivers and software for your
SAN.
Geoff N. Hiten
Microsoft SQL Server MVP
Senior Database Administrator
Careerbuilder.com
I support the Professional Association for SQL Server
www.sqlpass.org
"Mel" <Qtip027@.hotmail.com> wrote in message
news:a29a42e2.0411301100.34356ad9@.posting.google.c om...
> Hi,
> I am trying to determine the best method for rebuilding some existing
> Windows 2000 clusters to Windows 2003. I have both SQL clusters and
> some application clusters.
> I do not want to upgrade the OS, but rather rebuild from scratch, one
> node at a time, using the existing hardware. Is this possible? I am
> having a hard time finding documentation on the best process for this
> and want to follow the method which will provide me with the smallest
> amount of downtime.
> thanks for your help!
I am trying to determine the best method for rebuilding some existing
Windows 2000 clusters to Windows 2003. I have both SQL clusters and
some application clusters.
I do not want to upgrade the OS, but rather rebuild from scratch, one
node at a time, using the existing hardware. Is this possible? I am
having a hard time finding documentation on the best process for this
and want to follow the method which will provide me with the smallest
amount of downtime.
thanks for your help!
http://support.microsoft.com/?kbid=313037 explains how to upgrade, but like
you said, you really want to migrate. You can rebuild one node as a time,
and then rejoin the cluster.
Cheers,
Rod
MVP - Windows Server - Clustering
http://www.nw-america.com - Clustering
http://msmvps.com/clustering - Blog
"Mel" <Qtip027@.hotmail.com> wrote in message
news:a29a42e2.0411301100.34356ad9@.posting.google.c om...
> Hi,
> I am trying to determine the best method for rebuilding some existing
> Windows 2000 clusters to Windows 2003. I have both SQL clusters and
> some application clusters.
> I do not want to upgrade the OS, but rather rebuild from scratch, one
> node at a time, using the existing hardware. Is this possible? I am
> having a hard time finding documentation on the best process for this
> and want to follow the method which will provide me with the smallest
> amount of downtime.
> thanks for your help!
|||Been there, done that, bought the t-shirt. I prefer a mixed solution.
Upgrade THEN reload the OS. More work but less risk. Biggest thing is to
make absolutely sure you have correct 2003 drivers and software for your
SAN.
Geoff N. Hiten
Microsoft SQL Server MVP
Senior Database Administrator
Careerbuilder.com
I support the Professional Association for SQL Server
www.sqlpass.org
"Mel" <Qtip027@.hotmail.com> wrote in message
news:a29a42e2.0411301100.34356ad9@.posting.google.c om...
> Hi,
> I am trying to determine the best method for rebuilding some existing
> Windows 2000 clusters to Windows 2003. I have both SQL clusters and
> some application clusters.
> I do not want to upgrade the OS, but rather rebuild from scratch, one
> node at a time, using the existing hardware. Is this possible? I am
> having a hard time finding documentation on the best process for this
> and want to follow the method which will provide me with the smallest
> amount of downtime.
> thanks for your help!
Friday, March 23, 2012
migrate to cluster
I need to migrate a non-clustered server up to a cluster. Usually I use this
resource to migrate servers but have not tried it with a cluster
http://vyaskn.tripod.com/moving_sql_server.htm
Does anyone see any issues with using this to migrate to a cluster form a
non-clustered server?
Thanks.Hi
"Terri" wrote:
> I need to migrate a non-clustered server up to a cluster. Usually I use th
is
> resource to migrate servers but have not tried it with a cluster
> http://vyaskn.tripod.com/moving_sql_server.htm
> Does anyone see any issues with using this to migrate to a cluster form a
> non-clustered server?
> Thanks.
The instance on the cluster can in be considered in the same way as any
different instance when transferring a database see
http://support.microsoft.com/default.aspx/kb/314546
including moving logins/jobs etc.. and matching orphaned users.
I assume that you are not going to try and give the virtual server the same
name as the actual machine as it would a different process to the article yo
u
posted.
Johnsql
resource to migrate servers but have not tried it with a cluster
http://vyaskn.tripod.com/moving_sql_server.htm
Does anyone see any issues with using this to migrate to a cluster form a
non-clustered server?
Thanks.Hi
"Terri" wrote:
> I need to migrate a non-clustered server up to a cluster. Usually I use th
is
> resource to migrate servers but have not tried it with a cluster
> http://vyaskn.tripod.com/moving_sql_server.htm
> Does anyone see any issues with using this to migrate to a cluster form a
> non-clustered server?
> Thanks.
The instance on the cluster can in be considered in the same way as any
different instance when transferring a database see
http://support.microsoft.com/default.aspx/kb/314546
including moving logins/jobs etc.. and matching orphaned users.
I assume that you are not going to try and give the virtual server the same
name as the actual machine as it would a different process to the article yo
u
posted.
Johnsql
migrate to cluster
I need to migrate a non-clustered server up to a cluster. Usually I use this
resource to migrate servers but have not tried it with a cluster
http://vyaskn.tripod.com/moving_sql_server.htm
Does anyone see any issues with using this to migrate to a cluster form a
non-clustered server?
Thanks.
Hi
"Terri" wrote:
> I need to migrate a non-clustered server up to a cluster. Usually I use this
> resource to migrate servers but have not tried it with a cluster
> http://vyaskn.tripod.com/moving_sql_server.htm
> Does anyone see any issues with using this to migrate to a cluster form a
> non-clustered server?
> Thanks.
The instance on the cluster can in be considered in the same way as any
different instance when transferring a database see
http://support.microsoft.com/default.aspx/kb/314546
including moving logins/jobs etc.. and matching orphaned users.
I assume that you are not going to try and give the virtual server the same
name as the actual machine as it would a different process to the article you
posted.
John
resource to migrate servers but have not tried it with a cluster
http://vyaskn.tripod.com/moving_sql_server.htm
Does anyone see any issues with using this to migrate to a cluster form a
non-clustered server?
Thanks.
Hi
"Terri" wrote:
> I need to migrate a non-clustered server up to a cluster. Usually I use this
> resource to migrate servers but have not tried it with a cluster
> http://vyaskn.tripod.com/moving_sql_server.htm
> Does anyone see any issues with using this to migrate to a cluster form a
> non-clustered server?
> Thanks.
The instance on the cluster can in be considered in the same way as any
different instance when transferring a database see
http://support.microsoft.com/default.aspx/kb/314546
including moving logins/jobs etc.. and matching orphaned users.
I assume that you are not going to try and give the virtual server the same
name as the actual machine as it would a different process to the article you
posted.
John
migrate to cluster
I need to migrate a non-clustered server up to a cluster. Usually I use this
resource to migrate servers but have not tried it with a cluster
http://vyaskn.tripod.com/moving_sql_server.htm
Does anyone see any issues with using this to migrate to a cluster form a
non-clustered server?
Thanks.Hi
"Terri" wrote:
> I need to migrate a non-clustered server up to a cluster. Usually I use this
> resource to migrate servers but have not tried it with a cluster
> http://vyaskn.tripod.com/moving_sql_server.htm
> Does anyone see any issues with using this to migrate to a cluster form a
> non-clustered server?
> Thanks.
The instance on the cluster can in be considered in the same way as any
different instance when transferring a database see
http://support.microsoft.com/default.aspx/kb/314546
including moving logins/jobs etc.. and matching orphaned users.
I assume that you are not going to try and give the virtual server the same
name as the actual machine as it would a different process to the article you
posted.
John
resource to migrate servers but have not tried it with a cluster
http://vyaskn.tripod.com/moving_sql_server.htm
Does anyone see any issues with using this to migrate to a cluster form a
non-clustered server?
Thanks.Hi
"Terri" wrote:
> I need to migrate a non-clustered server up to a cluster. Usually I use this
> resource to migrate servers but have not tried it with a cluster
> http://vyaskn.tripod.com/moving_sql_server.htm
> Does anyone see any issues with using this to migrate to a cluster form a
> non-clustered server?
> Thanks.
The instance on the cluster can in be considered in the same way as any
different instance when transferring a database see
http://support.microsoft.com/default.aspx/kb/314546
including moving logins/jobs etc.. and matching orphaned users.
I assume that you are not going to try and give the virtual server the same
name as the actual machine as it would a different process to the article you
posted.
John
Migrate stand alone sql server to a cluster without downtime
Hi
I have read most the articles and posts about move sql server.
Here is my situation:
I have stand alone standard sql server 2000 and with about 40 databases. And
I am moving the server to a SQL cluster(Active/passive). I have to use the
old name, IP on the new server and with minimum down time. Anybody has done
this? What is the precedure? Will Virutas BackupExe backup/restore work? I
know Deattach/Reattach works but I have to do it one DB at a time, right?
That will take a long time. Will permission be carried over using these
mothed?
Any information will be greatly appreciated.
Thanks,
Yuhong
First, you cannot use the same name and IP address. The cluster
installation and any data transfer will fail.
Here is how you do this.
First, make sure all your SQL connections to the old box use a DNS entry to
resolve their names. Eliminate any hard-coded IP addresses by using client
aliases if necessary. You will use an SVC record in the DNS system to
repoint the old connections to the new server when you do the changeover.
Test this using a bogus alias before going live.
Set all your production databases to full recovery and implement a log
backup plan.
Use backup and restore to create the databases on the new system. Use the
'NORECOVERY' or 'STANDBY' option so you can apply later transaction logs.
Manually copy and apply the transaction log backups from the old system to
the new cluster.
I suggest scripting the following tasks well ahead of time.
Run a log backup WITH STANDBY on each database on the old server. Copy the
files (or restore from a common network share) and restore the final log for
each database using the WITH RECOVERY option.
When you have transferred the final database log, use sp_change_users_login
to remap your pre-generated logins to the users in the restored databases.
I typically use a bogus password for SQL logins until this step so that
users cannot accidentally connect to the new server.
Stop the old server. Add the SVC record to DNS to alias the old servername
to the new service. Remember to include the port number if you are using a
named instance or a non-standard port.
Get ready to deal with the handful of systems you missed that are still
connecting via IP.
Remember to test everything before going live. If you mess up, you can
always bring the old server back up and take the databases out of standby to
get back to where you started. The actual changeover should take less than
one hour IF you plan, test, and practice.
Good luck.
Geoff N. Hiten
Microsoft SQL Server MVP
Senior Database Administrator
Careerbuilder.com
I support the Professional Association for SQL Server
www.sqlpass.org
"Yuhong" <Yuhong@.discussions.microsoft.com> wrote in message
news:59B178D2-D730-4142-BE76-E0A38FE53F69@.microsoft.com...
> Hi
> I have read most the articles and posts about move sql server.
> Here is my situation:
> I have stand alone standard sql server 2000 and with about 40 databases.
And
> I am moving the server to a SQL cluster(Active/passive). I have to use the
> old name, IP on the new server and with minimum down time. Anybody has
done
> this? What is the precedure? Will Virutas BackupExe backup/restore work? I
> know Deattach/Reattach works but I have to do it one DB at a time, right?
> That will take a long time. Will permission be carried over using these
> mothed?
> Any information will be greatly appreciated.
> Thanks,
> --
> Yuhong
|||Thanks, Geoff! This is very helpful. I have setup a test cluster and I will
have to do a few full test before the real migration.
Thanks again!
Yuhong
"Geoff N. Hiten" wrote:
> First, you cannot use the same name and IP address. The cluster
> installation and any data transfer will fail.
> Here is how you do this.
> First, make sure all your SQL connections to the old box use a DNS entry to
> resolve their names. Eliminate any hard-coded IP addresses by using client
> aliases if necessary. You will use an SVC record in the DNS system to
> repoint the old connections to the new server when you do the changeover.
> Test this using a bogus alias before going live.
> Set all your production databases to full recovery and implement a log
> backup plan.
> Use backup and restore to create the databases on the new system. Use the
> 'NORECOVERY' or 'STANDBY' option so you can apply later transaction logs.
> Manually copy and apply the transaction log backups from the old system to
> the new cluster.
> I suggest scripting the following tasks well ahead of time.
> Run a log backup WITH STANDBY on each database on the old server. Copy the
> files (or restore from a common network share) and restore the final log for
> each database using the WITH RECOVERY option.
> When you have transferred the final database log, use sp_change_users_login
> to remap your pre-generated logins to the users in the restored databases.
> I typically use a bogus password for SQL logins until this step so that
> users cannot accidentally connect to the new server.
> Stop the old server. Add the SVC record to DNS to alias the old servername
> to the new service. Remember to include the port number if you are using a
> named instance or a non-standard port.
> Get ready to deal with the handful of systems you missed that are still
> connecting via IP.
> Remember to test everything before going live. If you mess up, you can
> always bring the old server back up and take the databases out of standby to
> get back to where you started. The actual changeover should take less than
> one hour IF you plan, test, and practice.
> Good luck.
> --
> Geoff N. Hiten
> Microsoft SQL Server MVP
> Senior Database Administrator
> Careerbuilder.com
> I support the Professional Association for SQL Server
> www.sqlpass.org
> "Yuhong" <Yuhong@.discussions.microsoft.com> wrote in message
> news:59B178D2-D730-4142-BE76-E0A38FE53F69@.microsoft.com...
> And
> done
>
>
sql
I have read most the articles and posts about move sql server.
Here is my situation:
I have stand alone standard sql server 2000 and with about 40 databases. And
I am moving the server to a SQL cluster(Active/passive). I have to use the
old name, IP on the new server and with minimum down time. Anybody has done
this? What is the precedure? Will Virutas BackupExe backup/restore work? I
know Deattach/Reattach works but I have to do it one DB at a time, right?
That will take a long time. Will permission be carried over using these
mothed?
Any information will be greatly appreciated.
Thanks,
Yuhong
First, you cannot use the same name and IP address. The cluster
installation and any data transfer will fail.
Here is how you do this.
First, make sure all your SQL connections to the old box use a DNS entry to
resolve their names. Eliminate any hard-coded IP addresses by using client
aliases if necessary. You will use an SVC record in the DNS system to
repoint the old connections to the new server when you do the changeover.
Test this using a bogus alias before going live.
Set all your production databases to full recovery and implement a log
backup plan.
Use backup and restore to create the databases on the new system. Use the
'NORECOVERY' or 'STANDBY' option so you can apply later transaction logs.
Manually copy and apply the transaction log backups from the old system to
the new cluster.
I suggest scripting the following tasks well ahead of time.
Run a log backup WITH STANDBY on each database on the old server. Copy the
files (or restore from a common network share) and restore the final log for
each database using the WITH RECOVERY option.
When you have transferred the final database log, use sp_change_users_login
to remap your pre-generated logins to the users in the restored databases.
I typically use a bogus password for SQL logins until this step so that
users cannot accidentally connect to the new server.
Stop the old server. Add the SVC record to DNS to alias the old servername
to the new service. Remember to include the port number if you are using a
named instance or a non-standard port.
Get ready to deal with the handful of systems you missed that are still
connecting via IP.
Remember to test everything before going live. If you mess up, you can
always bring the old server back up and take the databases out of standby to
get back to where you started. The actual changeover should take less than
one hour IF you plan, test, and practice.
Good luck.
Geoff N. Hiten
Microsoft SQL Server MVP
Senior Database Administrator
Careerbuilder.com
I support the Professional Association for SQL Server
www.sqlpass.org
"Yuhong" <Yuhong@.discussions.microsoft.com> wrote in message
news:59B178D2-D730-4142-BE76-E0A38FE53F69@.microsoft.com...
> Hi
> I have read most the articles and posts about move sql server.
> Here is my situation:
> I have stand alone standard sql server 2000 and with about 40 databases.
And
> I am moving the server to a SQL cluster(Active/passive). I have to use the
> old name, IP on the new server and with minimum down time. Anybody has
done
> this? What is the precedure? Will Virutas BackupExe backup/restore work? I
> know Deattach/Reattach works but I have to do it one DB at a time, right?
> That will take a long time. Will permission be carried over using these
> mothed?
> Any information will be greatly appreciated.
> Thanks,
> --
> Yuhong
|||Thanks, Geoff! This is very helpful. I have setup a test cluster and I will
have to do a few full test before the real migration.
Thanks again!
Yuhong
"Geoff N. Hiten" wrote:
> First, you cannot use the same name and IP address. The cluster
> installation and any data transfer will fail.
> Here is how you do this.
> First, make sure all your SQL connections to the old box use a DNS entry to
> resolve their names. Eliminate any hard-coded IP addresses by using client
> aliases if necessary. You will use an SVC record in the DNS system to
> repoint the old connections to the new server when you do the changeover.
> Test this using a bogus alias before going live.
> Set all your production databases to full recovery and implement a log
> backup plan.
> Use backup and restore to create the databases on the new system. Use the
> 'NORECOVERY' or 'STANDBY' option so you can apply later transaction logs.
> Manually copy and apply the transaction log backups from the old system to
> the new cluster.
> I suggest scripting the following tasks well ahead of time.
> Run a log backup WITH STANDBY on each database on the old server. Copy the
> files (or restore from a common network share) and restore the final log for
> each database using the WITH RECOVERY option.
> When you have transferred the final database log, use sp_change_users_login
> to remap your pre-generated logins to the users in the restored databases.
> I typically use a bogus password for SQL logins until this step so that
> users cannot accidentally connect to the new server.
> Stop the old server. Add the SVC record to DNS to alias the old servername
> to the new service. Remember to include the port number if you are using a
> named instance or a non-standard port.
> Get ready to deal with the handful of systems you missed that are still
> connecting via IP.
> Remember to test everything before going live. If you mess up, you can
> always bring the old server back up and take the databases out of standby to
> get back to where you started. The actual changeover should take less than
> one hour IF you plan, test, and practice.
> Good luck.
> --
> Geoff N. Hiten
> Microsoft SQL Server MVP
> Senior Database Administrator
> Careerbuilder.com
> I support the Professional Association for SQL Server
> www.sqlpass.org
> "Yuhong" <Yuhong@.discussions.microsoft.com> wrote in message
> news:59B178D2-D730-4142-BE76-E0A38FE53F69@.microsoft.com...
> And
> done
>
>
sql
Monday, March 19, 2012
Migrate from Single-Server to Cluster
I have a SharePoint installation that currently uses a single SQL Server and
connects to the default instance. I want to migrate to a cluster without
doing a full backup/move/restore. I'm thinking if I set up the cluster with
the same name as the current SQL server it should be transparent to
SharePoint. Has anyone tried this?
This is not a good idea, not even a great one. SPS can get picky. I would
due a true migration, with a tested backup/restore, then move the DB's.
Cheers,
Rodney R. Fournier
MVP - Windows Server - Clustering
http://www.nw-america.com - Clustering Website
http://www.msmvps.com/clustering - Blog
http://www.clusterhelp.com - Cluster Training
ClusterHelp.com is a Microsoft Certified Gold Partner
"Milan Gross" <MilanGross@.discussions.microsoft.com> wrote in message
news:19F19F3B-7721-4301-9303-B7ECF518B4A2@.microsoft.com...
>I have a SharePoint installation that currently uses a single SQL Server
>and
> connects to the default instance. I want to migrate to a cluster without
> doing a full backup/move/restore. I'm thinking if I set up the cluster
> with
> the same name as the current SQL server it should be transparent to
> SharePoint. Has anyone tried this?
connects to the default instance. I want to migrate to a cluster without
doing a full backup/move/restore. I'm thinking if I set up the cluster with
the same name as the current SQL server it should be transparent to
SharePoint. Has anyone tried this?
This is not a good idea, not even a great one. SPS can get picky. I would
due a true migration, with a tested backup/restore, then move the DB's.
Cheers,
Rodney R. Fournier
MVP - Windows Server - Clustering
http://www.nw-america.com - Clustering Website
http://www.msmvps.com/clustering - Blog
http://www.clusterhelp.com - Cluster Training
ClusterHelp.com is a Microsoft Certified Gold Partner
"Milan Gross" <MilanGross@.discussions.microsoft.com> wrote in message
news:19F19F3B-7721-4301-9303-B7ECF518B4A2@.microsoft.com...
>I have a SharePoint installation that currently uses a single SQL Server
>and
> connects to the default instance. I want to migrate to a cluster without
> doing a full backup/move/restore. I'm thinking if I set up the cluster
> with
> the same name as the current SQL server it should be transparent to
> SharePoint. Has anyone tried this?
Migrate from non-cluster to Cluster
I have a single SQL 2000 Enterprise server and I need to turn it into a
cluster. We have several applications using SQL, so the hostname and
configuration of the cluster must be the same as the existing single server.
The operating system is WS2003E and they are in a AD domain.
Is there a fairly easy migration path from a single to clustered
configuration, or do I have to setup two new servers and somehow get the
cluster to use the old hostname? Do I just do a SQL backup of the old
server, power it off, setup the cluster using the old hostname and then do a
SQL restore? I need to minimize downtime and I can't reconfigure the
applications to point to another SQL server.
Do I register the SPNs for the virtual hostname of the cluster?
Thanks,
Derek
Reusing the name is not really an option for several reasons (AD name
conflict, DNS name conflict, SQL cluster naming options). You can use DNS to
alias the old name to the new name.
While it is possible to migrate a non-clustered instance to a clustered
instance, I would recommend setting up a new system. That way if anything
goes wrong, your existing system is right there to pick up and run. Failure
isn't so painful. You can use manual log shipping or a simple log shipping
script to minimize downtime by getting your new server 'close' to the old
one. Be sure and plan the cutover process and test it (maybe in a smaller
scale using a couple of SQL instances on a test box).
Geoff N. Hiten
Microsoft SQL Server MVP
Senior Database Administrator
Careerbuilder.com
I support the Professional Association for SQL Server
www.sqlpass.org
"Derek" <dseaman@.spawar.navy.mil> wrote in message
news:ep1mEXCyEHA.3584@.TK2MSFTNGP10.phx.gbl...
> I have a single SQL 2000 Enterprise server and I need to turn it into a
> cluster. We have several applications using SQL, so the hostname and
> configuration of the cluster must be the same as the existing single
server.
> The operating system is WS2003E and they are in a AD domain.
> Is there a fairly easy migration path from a single to clustered
> configuration, or do I have to setup two new servers and somehow get the
> cluster to use the old hostname? Do I just do a SQL backup of the old
> server, power it off, setup the cluster using the old hostname and then do
a
> SQL restore? I need to minimize downtime and I can't reconfigure the
> applications to point to another SQL server.
> Do I register the SPNs for the virtual hostname of the cluster?
> Thanks,
> Derek
>
>
|||How about if I backup the non-clustered server, remove it from AD, and built
up a cluster with the virtual name being the name of the old SQL server and
then do a SQL restore? We have too many apps to be changing the name, and I
hate to play tricks with DNS that are prone to human error.
Derek
"Geoff N. Hiten" <SRDBA@.Careerbuilder.com> wrote in message
news:eKaQfWDyEHA.1188@.tk2msftngp13.phx.gbl...
> Reusing the name is not really an option for several reasons (AD name
> conflict, DNS name conflict, SQL cluster naming options). You can use DNS
> to
> alias the old name to the new name.
> While it is possible to migrate a non-clustered instance to a clustered
> instance, I would recommend setting up a new system. That way if anything
> goes wrong, your existing system is right there to pick up and run.
> Failure
> isn't so painful. You can use manual log shipping or a simple log
> shipping
> script to minimize downtime by getting your new server 'close' to the old
> one. Be sure and plan the cutover process and test it (maybe in a smaller
> scale using a couple of SQL instances on a test box).
> --
> Geoff N. Hiten
> Microsoft SQL Server MVP
> Senior Database Administrator
> Careerbuilder.com
> I support the Professional Association for SQL Server
> www.sqlpass.org
> "Derek" <dseaman@.spawar.navy.mil> wrote in message
> news:ep1mEXCyEHA.3584@.TK2MSFTNGP10.phx.gbl...
> server.
> a
>
|||Try this in a test environment first.
Geoff N. Hiten
Microsoft SQL Server MVP
Senior Database Administrator
Careerbuilder.com
I support the Professional Association for SQL Server
www.sqlpass.org
"Derek" <dseaman@.spawar.navy.mil> wrote in message
news:uyD4T%23czEHA.3336@.TK2MSFTNGP11.phx.gbl...
> How about if I backup the non-clustered server, remove it from AD, and
built
> up a cluster with the virtual name being the name of the old SQL server
and
> then do a SQL restore? We have too many apps to be changing the name, and
I[vbcol=seagreen]
> hate to play tricks with DNS that are prone to human error.
> Derek
>
> "Geoff N. Hiten" <SRDBA@.Careerbuilder.com> wrote in message
> news:eKaQfWDyEHA.1188@.tk2msftngp13.phx.gbl...
DNS[vbcol=seagreen]
anything[vbcol=seagreen]
old[vbcol=seagreen]
smaller[vbcol=seagreen]
the
>
cluster. We have several applications using SQL, so the hostname and
configuration of the cluster must be the same as the existing single server.
The operating system is WS2003E and they are in a AD domain.
Is there a fairly easy migration path from a single to clustered
configuration, or do I have to setup two new servers and somehow get the
cluster to use the old hostname? Do I just do a SQL backup of the old
server, power it off, setup the cluster using the old hostname and then do a
SQL restore? I need to minimize downtime and I can't reconfigure the
applications to point to another SQL server.
Do I register the SPNs for the virtual hostname of the cluster?
Thanks,
Derek
Reusing the name is not really an option for several reasons (AD name
conflict, DNS name conflict, SQL cluster naming options). You can use DNS to
alias the old name to the new name.
While it is possible to migrate a non-clustered instance to a clustered
instance, I would recommend setting up a new system. That way if anything
goes wrong, your existing system is right there to pick up and run. Failure
isn't so painful. You can use manual log shipping or a simple log shipping
script to minimize downtime by getting your new server 'close' to the old
one. Be sure and plan the cutover process and test it (maybe in a smaller
scale using a couple of SQL instances on a test box).
Geoff N. Hiten
Microsoft SQL Server MVP
Senior Database Administrator
Careerbuilder.com
I support the Professional Association for SQL Server
www.sqlpass.org
"Derek" <dseaman@.spawar.navy.mil> wrote in message
news:ep1mEXCyEHA.3584@.TK2MSFTNGP10.phx.gbl...
> I have a single SQL 2000 Enterprise server and I need to turn it into a
> cluster. We have several applications using SQL, so the hostname and
> configuration of the cluster must be the same as the existing single
server.
> The operating system is WS2003E and they are in a AD domain.
> Is there a fairly easy migration path from a single to clustered
> configuration, or do I have to setup two new servers and somehow get the
> cluster to use the old hostname? Do I just do a SQL backup of the old
> server, power it off, setup the cluster using the old hostname and then do
a
> SQL restore? I need to minimize downtime and I can't reconfigure the
> applications to point to another SQL server.
> Do I register the SPNs for the virtual hostname of the cluster?
> Thanks,
> Derek
>
>
|||How about if I backup the non-clustered server, remove it from AD, and built
up a cluster with the virtual name being the name of the old SQL server and
then do a SQL restore? We have too many apps to be changing the name, and I
hate to play tricks with DNS that are prone to human error.
Derek
"Geoff N. Hiten" <SRDBA@.Careerbuilder.com> wrote in message
news:eKaQfWDyEHA.1188@.tk2msftngp13.phx.gbl...
> Reusing the name is not really an option for several reasons (AD name
> conflict, DNS name conflict, SQL cluster naming options). You can use DNS
> to
> alias the old name to the new name.
> While it is possible to migrate a non-clustered instance to a clustered
> instance, I would recommend setting up a new system. That way if anything
> goes wrong, your existing system is right there to pick up and run.
> Failure
> isn't so painful. You can use manual log shipping or a simple log
> shipping
> script to minimize downtime by getting your new server 'close' to the old
> one. Be sure and plan the cutover process and test it (maybe in a smaller
> scale using a couple of SQL instances on a test box).
> --
> Geoff N. Hiten
> Microsoft SQL Server MVP
> Senior Database Administrator
> Careerbuilder.com
> I support the Professional Association for SQL Server
> www.sqlpass.org
> "Derek" <dseaman@.spawar.navy.mil> wrote in message
> news:ep1mEXCyEHA.3584@.TK2MSFTNGP10.phx.gbl...
> server.
> a
>
|||Try this in a test environment first.
Geoff N. Hiten
Microsoft SQL Server MVP
Senior Database Administrator
Careerbuilder.com
I support the Professional Association for SQL Server
www.sqlpass.org
"Derek" <dseaman@.spawar.navy.mil> wrote in message
news:uyD4T%23czEHA.3336@.TK2MSFTNGP11.phx.gbl...
> How about if I backup the non-clustered server, remove it from AD, and
built
> up a cluster with the virtual name being the name of the old SQL server
and
> then do a SQL restore? We have too many apps to be changing the name, and
I[vbcol=seagreen]
> hate to play tricks with DNS that are prone to human error.
> Derek
>
> "Geoff N. Hiten" <SRDBA@.Careerbuilder.com> wrote in message
> news:eKaQfWDyEHA.1188@.tk2msftngp13.phx.gbl...
DNS[vbcol=seagreen]
anything[vbcol=seagreen]
old[vbcol=seagreen]
smaller[vbcol=seagreen]
the
>
Migrate existing standalone to cluster
While away on vacation my company had some software installed that required a
new instance of SQL Server 2K to be created on our existing active/passive
cluster.
Because the techs doing the install did not know the password for our domain
cluster user account they created the standalone instance on the db server.
What I need to know is how do I go about migrating it to a clustered instance
instead of a standalone so as to take advantage of the failover capabilities?
i.e. I already have a clustered server with one clustered instance. They
installed a standalone instance alongside and now I need to migrate the new
instance to another named clustered instance.
Is it possible to go with the existing clustered instance and simply move
the DB's to the cluster? What's driving the need for two instances?
Tom
Thomas A. Moreau, BSc, PhD, MCSE, MCDBA
SQL Server MVP
Columnist, SQL Server Professional
Toronto, ON Canada
www.pinpub.com
..
"Cary" <Cary@.discussions.microsoft.com> wrote in message
news:F9743B37-FC4D-4909-A4CA-608078BB5A3E@.microsoft.com...
While away on vacation my company had some software installed that required
a
new instance of SQL Server 2K to be created on our existing active/passive
cluster.
Because the techs doing the install did not know the password for our domain
cluster user account they created the standalone instance on the db server.
What I need to know is how do I go about migrating it to a clustered
instance
instead of a standalone so as to take advantage of the failover
capabilities?
i.e. I already have a clustered server with one clustered instance. They
installed a standalone instance alongside and now I need to migrate the new
instance to another named clustered instance.
|||Oh you'll love this...
The software we purchased for our new document management system *cough*
Documentum *cough*, is designed so as to require a case-sensitive database.
I know...D-U-M Dum...And because all of our other databases are NOT
case-sensitive (and there's no way in h*ll I would change that) we had to
create a new instance that was.
"Tom Moreau" wrote:
> Is it possible to go with the existing clustered instance and simply move
> the DB's to the cluster? What's driving the need for two instances?
> --
> Tom
> ----
> Thomas A. Moreau, BSc, PhD, MCSE, MCDBA
> SQL Server MVP
> Columnist, SQL Server Professional
> Toronto, ON Canada
> www.pinpub.com
> ..
> "Cary" <Cary@.discussions.microsoft.com> wrote in message
> news:F9743B37-FC4D-4909-A4CA-608078BB5A3E@.microsoft.com...
> While away on vacation my company had some software installed that required
> a
> new instance of SQL Server 2K to be created on our existing active/passive
> cluster.
> Because the techs doing the install did not know the password for our domain
> cluster user account they created the standalone instance on the db server.
> What I need to know is how do I go about migrating it to a clustered
> instance
> instead of a standalone so as to take advantage of the failover
> capabilities?
> i.e. I already have a clustered server with one clustered instance. They
> installed a standalone instance alongside and now I need to migrate the new
> instance to another named clustered instance.
>
|||That's not justification enough. You can create a case-sensitive database
within an instance that is not case sensitive.
Tom
Thomas A. Moreau, BSc, PhD, MCSE, MCDBA
SQL Server MVP
Columnist, SQL Server Professional
Toronto, ON Canada
www.pinpub.com
..
"Cary" <Cary@.discussions.microsoft.com> wrote in message
news:A8F1525E-3D96-4842-AFBD-87160EC34CB8@.microsoft.com...
Oh you'll love this...
The software we purchased for our new document management system *cough*
Documentum *cough*, is designed so as to require a case-sensitive database.
I know...D-U-M Dum...And because all of our other databases are NOT
case-sensitive (and there's no way in h*ll I would change that) we had to
create a new instance that was.
"Tom Moreau" wrote:
> Is it possible to go with the existing clustered instance and simply move
> the DB's to the cluster? What's driving the need for two instances?
> --
> Tom
> ----
> Thomas A. Moreau, BSc, PhD, MCSE, MCDBA
> SQL Server MVP
> Columnist, SQL Server Professional
> Toronto, ON Canada
> www.pinpub.com
> ..
> "Cary" <Cary@.discussions.microsoft.com> wrote in message
> news:F9743B37-FC4D-4909-A4CA-608078BB5A3E@.microsoft.com...
> While away on vacation my company had some software installed that
> required
> a
> new instance of SQL Server 2K to be created on our existing active/passive
> cluster.
> Because the techs doing the install did not know the password for our
> domain
> cluster user account they created the standalone instance on the db
> server.
> What I need to know is how do I go about migrating it to a clustered
> instance
> instead of a standalone so as to take advantage of the failover
> capabilities?
> i.e. I already have a clustered server with one clustered instance. They
> installed a standalone instance alongside and now I need to migrate the
> new
> instance to another named clustered instance.
>
|||Not that it will matter much anyway, since it is already installed, but how
do you go about making a case-sensitive db inside of an insensitive instance?
And I still need to know how to change the standalone to a clustered...
"Tom Moreau" wrote:
> That's not justification enough. You can create a case-sensitive database
> within an instance that is not case sensitive.
> --
> Tom
> ----
> Thomas A. Moreau, BSc, PhD, MCSE, MCDBA
> SQL Server MVP
> Columnist, SQL Server Professional
> Toronto, ON Canada
> www.pinpub.com
> ..
> "Cary" <Cary@.discussions.microsoft.com> wrote in message
> news:A8F1525E-3D96-4842-AFBD-87160EC34CB8@.microsoft.com...
> Oh you'll love this...
> The software we purchased for our new document management system *cough*
> Documentum *cough*, is designed so as to require a case-sensitive database.
> I know...D-U-M Dum...And because all of our other databases are NOT
> case-sensitive (and there's no way in h*ll I would change that) we had to
> create a new instance that was.
> "Tom Moreau" wrote:
>
>
|||To create a database with a case-sensitive collation, just use the COLLATE
option:
create database MyDB
collate Latin1_General_CS_AI
As for the other bit, you'll have to create the new virtual server (and
named instance) in the same manner as you created the other virtual server
and instance. However, you can specify the collation for the new instance
at that time. Once that's done, then backup and restore the DB's from the
standalone to the new instance. Finally, remove the standalone.
Tom
Thomas A. Moreau, BSc, PhD, MCSE, MCDBA
SQL Server MVP
Columnist, SQL Server Professional
Toronto, ON Canada
www.pinpub.com
..
"Cary" <Cary@.discussions.microsoft.com> wrote in message
news:FBFC5A77-4A41-4B6E-B076-370E9111321B@.microsoft.com...
Not that it will matter much anyway, since it is already installed, but how
do you go about making a case-sensitive db inside of an insensitive
instance?
And I still need to know how to change the standalone to a clustered...
"Tom Moreau" wrote:
> That's not justification enough. You can create a case-sensitive database
> within an instance that is not case sensitive.
> --
> Tom
> ----
> Thomas A. Moreau, BSc, PhD, MCSE, MCDBA
> SQL Server MVP
> Columnist, SQL Server Professional
> Toronto, ON Canada
> www.pinpub.com
> ..
> "Cary" <Cary@.discussions.microsoft.com> wrote in message
> news:A8F1525E-3D96-4842-AFBD-87160EC34CB8@.microsoft.com...
> Oh you'll love this...
> The software we purchased for our new document management system *cough*
> Documentum *cough*, is designed so as to require a case-sensitive
> database.
> I know...D-U-M Dum...And because all of our other databases are NOT
> case-sensitive (and there's no way in h*ll I would change that) we had to
> create a new instance that was.
> "Tom Moreau" wrote:
>
>
|||Creating a database in an instance with a collation that is differnt than
the default server collation, as Tom suggested, is certainly one approach
you can explore. If everything is under your control, you can make this
work. A vendor package like Ducumentum, however, may crap out becasue of the
likely collation conflict with the tempdb database. So test it out!
Linchi
"Cary" <Cary@.discussions.microsoft.com> wrote in message
news:FBFC5A77-4A41-4B6E-B076-370E9111321B@.microsoft.com...[vbcol=seagreen]
> Not that it will matter much anyway, since it is already installed, but
> how
> do you go about making a case-sensitive db inside of an insensitive
> instance?
> And I still need to know how to change the standalone to a clustered...
>
> "Tom Moreau" wrote:
|||Question regarding what Linchi wrote about the temp DB being an issue. We
are currently in the same situation with a mulitnode cluster that will house
a peoplesoft instance (different collation than the other instances) but have
concerns on how failover will happen with this different collation instance
vs the collation instances that are indentical. Will failover happen just as
if all the collations were the same or do we have to take special precautions?
"Linchi Shea" wrote:
> Creating a database in an instance with a collation that is differnt than
> the default server collation, as Tom suggested, is certainly one approach
> you can explore. If everything is under your control, you can make this
> work. A vendor package like Ducumentum, however, may crap out becasue of the
> likely collation conflict with the tempdb database. So test it out!
> Linchi
> "Cary" <Cary@.discussions.microsoft.com> wrote in message
> news:FBFC5A77-4A41-4B6E-B076-370E9111321B@.microsoft.com...
>
>
|||Multiple collations are no different on a cluster than on a stand-alone box.
Failover will work exactly the same regardless of the system or anyuser
database collation. Collations have been separated from the system code
page since SQL 7.0
Geoff N. Hiten
Senior Database Administrator
Microsoft SQL Server MVP
"Todd" <Todd@.discussions.microsoft.com> wrote in message
news:32F54FD8-2882-4125-8202-D6CE442C83E5@.microsoft.com...[vbcol=seagreen]
> Question regarding what Linchi wrote about the temp DB being an issue. We
> are currently in the same situation with a mulitnode cluster that will
> house
> a peoplesoft instance (different collation than the other instances) but
> have
> concerns on how failover will happen with this different collation
> instance
> vs the collation instances that are indentical. Will failover happen just
> as
> if all the collations were the same or do we have to take special
> precautions?
> "Linchi Shea" wrote:
new instance of SQL Server 2K to be created on our existing active/passive
cluster.
Because the techs doing the install did not know the password for our domain
cluster user account they created the standalone instance on the db server.
What I need to know is how do I go about migrating it to a clustered instance
instead of a standalone so as to take advantage of the failover capabilities?
i.e. I already have a clustered server with one clustered instance. They
installed a standalone instance alongside and now I need to migrate the new
instance to another named clustered instance.
Is it possible to go with the existing clustered instance and simply move
the DB's to the cluster? What's driving the need for two instances?
Tom
Thomas A. Moreau, BSc, PhD, MCSE, MCDBA
SQL Server MVP
Columnist, SQL Server Professional
Toronto, ON Canada
www.pinpub.com
..
"Cary" <Cary@.discussions.microsoft.com> wrote in message
news:F9743B37-FC4D-4909-A4CA-608078BB5A3E@.microsoft.com...
While away on vacation my company had some software installed that required
a
new instance of SQL Server 2K to be created on our existing active/passive
cluster.
Because the techs doing the install did not know the password for our domain
cluster user account they created the standalone instance on the db server.
What I need to know is how do I go about migrating it to a clustered
instance
instead of a standalone so as to take advantage of the failover
capabilities?
i.e. I already have a clustered server with one clustered instance. They
installed a standalone instance alongside and now I need to migrate the new
instance to another named clustered instance.
|||Oh you'll love this...
The software we purchased for our new document management system *cough*
Documentum *cough*, is designed so as to require a case-sensitive database.
I know...D-U-M Dum...And because all of our other databases are NOT
case-sensitive (and there's no way in h*ll I would change that) we had to
create a new instance that was.
"Tom Moreau" wrote:
> Is it possible to go with the existing clustered instance and simply move
> the DB's to the cluster? What's driving the need for two instances?
> --
> Tom
> ----
> Thomas A. Moreau, BSc, PhD, MCSE, MCDBA
> SQL Server MVP
> Columnist, SQL Server Professional
> Toronto, ON Canada
> www.pinpub.com
> ..
> "Cary" <Cary@.discussions.microsoft.com> wrote in message
> news:F9743B37-FC4D-4909-A4CA-608078BB5A3E@.microsoft.com...
> While away on vacation my company had some software installed that required
> a
> new instance of SQL Server 2K to be created on our existing active/passive
> cluster.
> Because the techs doing the install did not know the password for our domain
> cluster user account they created the standalone instance on the db server.
> What I need to know is how do I go about migrating it to a clustered
> instance
> instead of a standalone so as to take advantage of the failover
> capabilities?
> i.e. I already have a clustered server with one clustered instance. They
> installed a standalone instance alongside and now I need to migrate the new
> instance to another named clustered instance.
>
|||That's not justification enough. You can create a case-sensitive database
within an instance that is not case sensitive.
Tom
Thomas A. Moreau, BSc, PhD, MCSE, MCDBA
SQL Server MVP
Columnist, SQL Server Professional
Toronto, ON Canada
www.pinpub.com
..
"Cary" <Cary@.discussions.microsoft.com> wrote in message
news:A8F1525E-3D96-4842-AFBD-87160EC34CB8@.microsoft.com...
Oh you'll love this...
The software we purchased for our new document management system *cough*
Documentum *cough*, is designed so as to require a case-sensitive database.
I know...D-U-M Dum...And because all of our other databases are NOT
case-sensitive (and there's no way in h*ll I would change that) we had to
create a new instance that was.
"Tom Moreau" wrote:
> Is it possible to go with the existing clustered instance and simply move
> the DB's to the cluster? What's driving the need for two instances?
> --
> Tom
> ----
> Thomas A. Moreau, BSc, PhD, MCSE, MCDBA
> SQL Server MVP
> Columnist, SQL Server Professional
> Toronto, ON Canada
> www.pinpub.com
> ..
> "Cary" <Cary@.discussions.microsoft.com> wrote in message
> news:F9743B37-FC4D-4909-A4CA-608078BB5A3E@.microsoft.com...
> While away on vacation my company had some software installed that
> required
> a
> new instance of SQL Server 2K to be created on our existing active/passive
> cluster.
> Because the techs doing the install did not know the password for our
> domain
> cluster user account they created the standalone instance on the db
> server.
> What I need to know is how do I go about migrating it to a clustered
> instance
> instead of a standalone so as to take advantage of the failover
> capabilities?
> i.e. I already have a clustered server with one clustered instance. They
> installed a standalone instance alongside and now I need to migrate the
> new
> instance to another named clustered instance.
>
|||Not that it will matter much anyway, since it is already installed, but how
do you go about making a case-sensitive db inside of an insensitive instance?
And I still need to know how to change the standalone to a clustered...
"Tom Moreau" wrote:
> That's not justification enough. You can create a case-sensitive database
> within an instance that is not case sensitive.
> --
> Tom
> ----
> Thomas A. Moreau, BSc, PhD, MCSE, MCDBA
> SQL Server MVP
> Columnist, SQL Server Professional
> Toronto, ON Canada
> www.pinpub.com
> ..
> "Cary" <Cary@.discussions.microsoft.com> wrote in message
> news:A8F1525E-3D96-4842-AFBD-87160EC34CB8@.microsoft.com...
> Oh you'll love this...
> The software we purchased for our new document management system *cough*
> Documentum *cough*, is designed so as to require a case-sensitive database.
> I know...D-U-M Dum...And because all of our other databases are NOT
> case-sensitive (and there's no way in h*ll I would change that) we had to
> create a new instance that was.
> "Tom Moreau" wrote:
>
>
|||To create a database with a case-sensitive collation, just use the COLLATE
option:
create database MyDB
collate Latin1_General_CS_AI
As for the other bit, you'll have to create the new virtual server (and
named instance) in the same manner as you created the other virtual server
and instance. However, you can specify the collation for the new instance
at that time. Once that's done, then backup and restore the DB's from the
standalone to the new instance. Finally, remove the standalone.
Tom
Thomas A. Moreau, BSc, PhD, MCSE, MCDBA
SQL Server MVP
Columnist, SQL Server Professional
Toronto, ON Canada
www.pinpub.com
..
"Cary" <Cary@.discussions.microsoft.com> wrote in message
news:FBFC5A77-4A41-4B6E-B076-370E9111321B@.microsoft.com...
Not that it will matter much anyway, since it is already installed, but how
do you go about making a case-sensitive db inside of an insensitive
instance?
And I still need to know how to change the standalone to a clustered...
"Tom Moreau" wrote:
> That's not justification enough. You can create a case-sensitive database
> within an instance that is not case sensitive.
> --
> Tom
> ----
> Thomas A. Moreau, BSc, PhD, MCSE, MCDBA
> SQL Server MVP
> Columnist, SQL Server Professional
> Toronto, ON Canada
> www.pinpub.com
> ..
> "Cary" <Cary@.discussions.microsoft.com> wrote in message
> news:A8F1525E-3D96-4842-AFBD-87160EC34CB8@.microsoft.com...
> Oh you'll love this...
> The software we purchased for our new document management system *cough*
> Documentum *cough*, is designed so as to require a case-sensitive
> database.
> I know...D-U-M Dum...And because all of our other databases are NOT
> case-sensitive (and there's no way in h*ll I would change that) we had to
> create a new instance that was.
> "Tom Moreau" wrote:
>
>
|||Creating a database in an instance with a collation that is differnt than
the default server collation, as Tom suggested, is certainly one approach
you can explore. If everything is under your control, you can make this
work. A vendor package like Ducumentum, however, may crap out becasue of the
likely collation conflict with the tempdb database. So test it out!
Linchi
"Cary" <Cary@.discussions.microsoft.com> wrote in message
news:FBFC5A77-4A41-4B6E-B076-370E9111321B@.microsoft.com...[vbcol=seagreen]
> Not that it will matter much anyway, since it is already installed, but
> how
> do you go about making a case-sensitive db inside of an insensitive
> instance?
> And I still need to know how to change the standalone to a clustered...
>
> "Tom Moreau" wrote:
|||Question regarding what Linchi wrote about the temp DB being an issue. We
are currently in the same situation with a mulitnode cluster that will house
a peoplesoft instance (different collation than the other instances) but have
concerns on how failover will happen with this different collation instance
vs the collation instances that are indentical. Will failover happen just as
if all the collations were the same or do we have to take special precautions?
"Linchi Shea" wrote:
> Creating a database in an instance with a collation that is differnt than
> the default server collation, as Tom suggested, is certainly one approach
> you can explore. If everything is under your control, you can make this
> work. A vendor package like Ducumentum, however, may crap out becasue of the
> likely collation conflict with the tempdb database. So test it out!
> Linchi
> "Cary" <Cary@.discussions.microsoft.com> wrote in message
> news:FBFC5A77-4A41-4B6E-B076-370E9111321B@.microsoft.com...
>
>
|||Multiple collations are no different on a cluster than on a stand-alone box.
Failover will work exactly the same regardless of the system or anyuser
database collation. Collations have been separated from the system code
page since SQL 7.0
Geoff N. Hiten
Senior Database Administrator
Microsoft SQL Server MVP
"Todd" <Todd@.discussions.microsoft.com> wrote in message
news:32F54FD8-2882-4125-8202-D6CE442C83E5@.microsoft.com...[vbcol=seagreen]
> Question regarding what Linchi wrote about the temp DB being an issue. We
> are currently in the same situation with a mulitnode cluster that will
> house
> a peoplesoft instance (different collation than the other instances) but
> have
> concerns on how failover will happen with this different collation
> instance
> vs the collation instances that are indentical. Will failover happen just
> as
> if all the collations were the same or do we have to take special
> precautions?
> "Linchi Shea" wrote:
migrate existing sql database to cluster
We are in the process of putting together a Windows 2000
distributed failover cluster. We have numerous SQL 2000
servers functioning as DB servers for a few different
departments. What we would like to do is eventually
migrate theses databases off of the stand alone servers to
the clustered servers.
Few questions:
Are there any major things to look out for when migrating
the databases? Or is it basically using the migration
wizard thats built into SQL server and dumping the
databases to one of the new installs of SQL on the cluster?
What about transaction and data files? Do these need to
be migrated as well?
Anything major I should be on the lookout for?
Any documentation about this on MS site? I couldnt find
any.
TIA!
Jeff BaileyYou should read on "moving databases between servers".
One Issue that often comes is security (logins/users).
"JBailey" <abc@.123.com> wrote in message
news:096701c34afd$255562c0$a001280a@.phx.gbl...
> We are in the process of putting together a Windows 2000
> distributed failover cluster. We have numerous SQL 2000
> servers functioning as DB servers for a few different
> departments. What we would like to do is eventually
> migrate theses databases off of the stand alone servers to
> the clustered servers.
> Few questions:
> Are there any major things to look out for when migrating
> the databases? Or is it basically using the migration
> wizard thats built into SQL server and dumping the
> databases to one of the new installs of SQL on the cluster?
> What about transaction and data files? Do these need to
> be migrated as well?
> Anything major I should be on the lookout for?
> Any documentation about this on MS site? I couldnt find
> any.
> TIA!
> Jeff Bailey
>|||Easiest way is probably to restore a backup to the other server
or detach/attach
INF: Moving SQL Server Databases to a New Location with Detach/Attach
http://support.microsoft.com/default.aspx?scid=kb;EN-US;q224071
or use the Copy database wizard
INF: Understanding and Troubleshooting the Copy Database Wizard in SQL
Server 2000
http://support.microsoft.com/default.aspx?scid=kb;en-us;Q274463
Also check out
INF: How To Transfer Logins and Passwords Between SQL Servers
http://support.microsoft.com/default.aspx?scid=kb;en-us;Q246133
PRB: User Logon and/or Permission Errors After Restoring Dump
http://support.microsoft.com/default.aspx?scid=kb;en-us;Q168001
INF: How to Resolve Permission Issues When a Database is Moved Between SQL
Servers
http://support.microsoft.com/default.aspx?scid=kb;en-us;Q240872
PRB: "Troubleshooting Orphaned Users" Topic in Books Online is Incomplete
http://support.microsoft.com/default.aspx?scid=kb;en-us;Q274188
--
HTH
Jasper Smith (SQL Server MVP)
I support PASS - the definitive, global
community for SQL Server professionals -
http://www.sqlpass.org
"JBailey" <abc@.123.com> wrote in message
news:096701c34afd$255562c0$a001280a@.phx.gbl...
We are in the process of putting together a Windows 2000
distributed failover cluster. We have numerous SQL 2000
servers functioning as DB servers for a few different
departments. What we would like to do is eventually
migrate theses databases off of the stand alone servers to
the clustered servers.
Few questions:
Are there any major things to look out for when migrating
the databases? Or is it basically using the migration
wizard thats built into SQL server and dumping the
databases to one of the new installs of SQL on the cluster?
What about transaction and data files? Do these need to
be migrated as well?
Anything major I should be on the lookout for?
Any documentation about this on MS site? I couldnt find
any.
TIA!
Jeff Bailey
distributed failover cluster. We have numerous SQL 2000
servers functioning as DB servers for a few different
departments. What we would like to do is eventually
migrate theses databases off of the stand alone servers to
the clustered servers.
Few questions:
Are there any major things to look out for when migrating
the databases? Or is it basically using the migration
wizard thats built into SQL server and dumping the
databases to one of the new installs of SQL on the cluster?
What about transaction and data files? Do these need to
be migrated as well?
Anything major I should be on the lookout for?
Any documentation about this on MS site? I couldnt find
any.
TIA!
Jeff BaileyYou should read on "moving databases between servers".
One Issue that often comes is security (logins/users).
"JBailey" <abc@.123.com> wrote in message
news:096701c34afd$255562c0$a001280a@.phx.gbl...
> We are in the process of putting together a Windows 2000
> distributed failover cluster. We have numerous SQL 2000
> servers functioning as DB servers for a few different
> departments. What we would like to do is eventually
> migrate theses databases off of the stand alone servers to
> the clustered servers.
> Few questions:
> Are there any major things to look out for when migrating
> the databases? Or is it basically using the migration
> wizard thats built into SQL server and dumping the
> databases to one of the new installs of SQL on the cluster?
> What about transaction and data files? Do these need to
> be migrated as well?
> Anything major I should be on the lookout for?
> Any documentation about this on MS site? I couldnt find
> any.
> TIA!
> Jeff Bailey
>|||Easiest way is probably to restore a backup to the other server
or detach/attach
INF: Moving SQL Server Databases to a New Location with Detach/Attach
http://support.microsoft.com/default.aspx?scid=kb;EN-US;q224071
or use the Copy database wizard
INF: Understanding and Troubleshooting the Copy Database Wizard in SQL
Server 2000
http://support.microsoft.com/default.aspx?scid=kb;en-us;Q274463
Also check out
INF: How To Transfer Logins and Passwords Between SQL Servers
http://support.microsoft.com/default.aspx?scid=kb;en-us;Q246133
PRB: User Logon and/or Permission Errors After Restoring Dump
http://support.microsoft.com/default.aspx?scid=kb;en-us;Q168001
INF: How to Resolve Permission Issues When a Database is Moved Between SQL
Servers
http://support.microsoft.com/default.aspx?scid=kb;en-us;Q240872
PRB: "Troubleshooting Orphaned Users" Topic in Books Online is Incomplete
http://support.microsoft.com/default.aspx?scid=kb;en-us;Q274188
--
HTH
Jasper Smith (SQL Server MVP)
I support PASS - the definitive, global
community for SQL Server professionals -
http://www.sqlpass.org
"JBailey" <abc@.123.com> wrote in message
news:096701c34afd$255562c0$a001280a@.phx.gbl...
We are in the process of putting together a Windows 2000
distributed failover cluster. We have numerous SQL 2000
servers functioning as DB servers for a few different
departments. What we would like to do is eventually
migrate theses databases off of the stand alone servers to
the clustered servers.
Few questions:
Are there any major things to look out for when migrating
the databases? Or is it basically using the migration
wizard thats built into SQL server and dumping the
databases to one of the new installs of SQL on the cluster?
What about transaction and data files? Do these need to
be migrated as well?
Anything major I should be on the lookout for?
Any documentation about this on MS site? I couldnt find
any.
TIA!
Jeff Bailey
Friday, February 24, 2012
Microsoft SQL-DMO (ODBC SQLState: 42000) Error 22022
Hi,
We have recently setup a new cluster server. At the moment
the resources have swapped over so that 1 is running on
node 2 and vice-versa.
However this appears to be causing a problem with the SQL
scheduled tasks. All tasks in the list have (Date and
Time are not available) under 'Next Run Date.' All the
tasks will try and run at their scheduled time however if
we try and manually execute tasks we get the error message
Microsoft SQL-DMO (ODBC SQLState: 42000) Error 22022:
SqlServerAgent Error: Job ... does not exist in the job
cache.
Has anyone seen this error before?
We do not have this problem on our other clustered servers.
Thanks in advance for your help.
Do you have SQL Server Agent starting with a domain account that is valid
on both nodes?
Are there any messages in the SQL Server or SQL Agent logs?
Are there any messages in the event logs?
Do the jobs refer to any files or other objects that only exist on one node?
Cindy Gross, MCDBA, MCSE
http://cindygross.tripod.com
This posting is provided "AS IS" with no warranties, and confers no rights.
We have recently setup a new cluster server. At the moment
the resources have swapped over so that 1 is running on
node 2 and vice-versa.
However this appears to be causing a problem with the SQL
scheduled tasks. All tasks in the list have (Date and
Time are not available) under 'Next Run Date.' All the
tasks will try and run at their scheduled time however if
we try and manually execute tasks we get the error message
Microsoft SQL-DMO (ODBC SQLState: 42000) Error 22022:
SqlServerAgent Error: Job ... does not exist in the job
cache.
Has anyone seen this error before?
We do not have this problem on our other clustered servers.
Thanks in advance for your help.
Do you have SQL Server Agent starting with a domain account that is valid
on both nodes?
Are there any messages in the SQL Server or SQL Agent logs?
Are there any messages in the event logs?
Do the jobs refer to any files or other objects that only exist on one node?
Cindy Gross, MCDBA, MCSE
http://cindygross.tripod.com
This posting is provided "AS IS" with no warranties, and confers no rights.
Subscribe to:
Posts (Atom)