April 13, 2012 at 8:37 am
I have a customer that is insisting on migrating a 2000 Cluster from one data center to another. Originally I had recommended just pack it up and move the physical hardware but they've rejected that option. The databases are quite large, in the multi-terrabyte range. They're not fully patched (they're on 8.00.2249) so Microsoft is going to laugh at us when if we have to call for help if it comes to that. So here are my concerns and if anyone has any other suggestions I'd appreciate it:
1. Seed the new hardware at the 2nd data center on the same versions, hoping drivers don't cause me issues.
2. Use a replication production like Double-Take to do block copies on the database drives to the new location.
3. Set up a SQL Alias to hopefully cause the 20+ applications to re-connect properly.
4. Recommend a re-work on the DTS packages so the connection is updated. I don't want to rely on an alias here because in 6 months who will remember the reason for the alias.
5. They want to use local host files (which I'm discouraging), to allow for testing during the cycle.
Other things to caution on?
Since these servers are at 8.00.2249, what kind of help can I expect out of Microsoft if we hit a serious driver issue? I'm guessing none. Extended life support for that product ends 4/13/2012, but it is my understanding if they're not on 8.00.2282, Microsoft won't touch it.
Other ideas?
April 13, 2012 at 11:55 am
I would definitely try to get them onto a supportable build before starting. Is upgrading to 2008R2 running in 80 compatibility mode an option? SQL 2012 was the first version to drop the 80 compat mode support. With 2008R2 you could have the new cluster setup and use log shipping from 2000 to 2008R2 to "keep the databases close" leading up to the cutover.
Hosts files? :sick: I guess those are fine for testing, but I would take this opportunity to abstract the host names using DNS (or some other layer like Cisco GSS) for the cutover.
I think you can still run DTS packages against SQL 2008R2 so long as you have the DTSRun.exe installed and the DTS packages are file resident, but I have not tried this on Server 2008R2 (64-bit). I think SQL 2005 was the last version that supported a DTS repository in msdb.
Fight the good fight!
There are no special teachers of virtue, because virtue is taught by the whole community.
--Plato
April 13, 2012 at 12:41 pm
Upgrading to a version later than SQL 2000 is not an option at this point. I simply have to get this thing moved from one data center to another either by (Moving the hardware 'as is') or Seeding new hardware with SQL 2000 and moving the databases via a replication method. Not a lot of options. I'm just trying to figure out how to get it there in one piece in a weekend allotted for the move. I can pre-sync with a product like Double-take, but have to do the final move in less than 36 hours.
I'm concerned about running into a driver problem with seeded hardware that I may not be able to solve.
I'm concerned about the SQL Aliasing not working for connections.
I'm concerned since it's on 8.00.2249 that if I run into a serious issue I may have to abort back to the original data center because Microsoft won't provide any support.
Ideas?
April 13, 2012 at 1:05 pm
csoloway (4/13/2012)
Upgrading to a version later than SQL 2000 is not an option at this point. I simply have to get this thing moved from one data center to another either by (Moving the hardware 'as is') or Seeding new hardware with SQL 2000 and moving the databases via a replication method. Not a lot of options. I'm just trying to figure out how to get it there in one piece in a weekend allotted for the move. I can pre-sync with a product like Double-take, but have to do the final move in less than 36 hours.
DoubleTake is good, but I would not use it for database files. They do not guarantee no corruption. I have only ever used it for replicating regular files.
I'm concerned about running into a driver problem with seeded hardware that I may not be able to solve.
No way to know until you try it. If you can't move the hardware then all you can do is present the risks to the decision-makers and do your best. Rooting our issues early is critical because support calls can drag on for weeks, especially if you're working on Microsoft's good graces in them supporting a product that has been end-of-lifed.
I'm concerned about the SQL Aliasing not working for connections.
SQL aliasing is pretty reliable, but I would opt to take-over the DNS of the old host if possible and point it to the new host at cutover time and turn down the old host to prevent cached DNS from allowing connection attempts from making it to the old host. If you're using a named instance now used a named instance in the new setup, and if you're using a default instance now use a default instance in the new setup.
I'm concerned since it's on 8.00.2249 that if I run into a serious issue I may have to abort back to the original data center because Microsoft won't provide any support.
Already said my peace on this one.
There are no special teachers of virtue, because virtue is taught by the whole community.
--Plato
April 13, 2012 at 2:02 pm
We are actually doing this for a company sub. We are doing a bunch of different servers one is SQL 2000 and one has a 2TB database in SQL 2008.
Our plan is that for the large 2TB database and some other large ones we
- set recovery to full
- took a full backup (using compression for SQL2008) to a NAS or SAN can't remember exactly what it was
- Overnighted the hardware with the backups cross country
- Restore backups to new machines
- Established logshipping (mirroring for SQL 2008)
When we are ready we fail over to the new machines. Create C-Names for anything we need to or have coding changes where needed.
We have not failed over yet but in theory we should have very little down time.
Viewing 5 posts - 1 through 4 (of 4 total)
You must be logged in to reply to this topic. Login to reply