Migration from 2000 ro 2005 Cluster

Hey All,
We have SQL Server 2000 in our production environment and we have a
brand spanking new cluster that has more CPU power and RAM than our
current server. The issue I have is how to move the data. We have 10
Databases, most are small, but we have a few that are 5 to 9 GB and
one that is over 100 GB.
I've already loaded SQL Server 2005 SP2 on the cluster for testing
etc.
My goal is to reduce downtime, and my stress, when we go live with the
cluster. My fall back plan is, backup the databases, copy the backups
to the cluster and restore them on the cluster.
I had a thought of installing SQL Server 2000 on the clusters and log
ship the databases to the SQL 2000 instance on the cluster, since I
can't log ship from 2000 to 2005. Then when go live day comes, I just
need to restore the existing logs, recover the databases and detach
the databases from 2000, then attach the databases to the 2005. From
what I know this is doable, but has anyone done this or something
similar? Are there any gotchas?
Thanks
Dave Ott<DaveOtt26.2@.gmail.com> wrote in message
news:1172770995.057390.293120@.j27g2000cwj.googlegroups.com...
> Hey All,
> We have SQL Server 2000 in our production environment and we have a
> brand spanking new cluster that has more CPU power and RAM than our
> current server. The issue I have is how to move the data. We have 10
> Databases, most are small, but we have a few that are 5 to 9 GB and
> one that is over 100 GB.
> I've already loaded SQL Server 2005 SP2 on the cluster for testing
> etc.
> My goal is to reduce downtime, and my stress, when we go live with the
> cluster. My fall back plan is, backup the databases, copy the backups
> to the cluster and restore them on the cluster.
> I had a thought of installing SQL Server 2000 on the clusters and log
> ship the databases to the SQL 2000 instance on the cluster, since I
> can't log ship from 2000 to 2005.
You can't? Why not? (I'm 99% sure a you can restore a 2000 database with
NORECOVERY in 2005. You can't however go the other way).
I'd probably go this route, but do it manually.
I.e. backup the databases, restore to the 2005 cluster with NORECOVERY.
Take a logbackup, restore to 2005 with NORECOVERY (to take care of the lag
in the original backup/restore cycle).
Repeat until you know the next round of log backup/restores will be quick
and then schedule the downtime, do one last log backup/restore and then
switch over to the 2005 server.
(I'd actually practice this once with a test client and then redo the entire
process if possible.)
Script it all out so it's fast and few mistakes.

> Then when go live day comes, I just
> need to restore the existing logs, recover the databases and detach
> the databases from 2000, then attach the databases to the 2005. From
> what I know this is doable, but has anyone done this or something
> similar? Are there any gotchas?
Seems to me more complicated than it's worth.

> Thanks
> Dave Ott
>|||If you do it all by scripts, you can log ship from SQL 2000 to SQL 2005.
You cannot use the STANDBY option but NORECOVERY works just fine. There is
no need for a SQL 2000 instance cluttering things up.
Geoff N. Hiten
Senior Database Administrator
Microsoft SQL Server MVP
"Greg D. Moore (Strider)" <mooregr_deleteth1s@.greenms.com> wrote in message
news:Ozz1v$CXHHA.528@.TK2MSFTNGP03.phx.gbl...
> <DaveOtt26.2@.gmail.com> wrote in message
> news:1172770995.057390.293120@.j27g2000cwj.googlegroups.com...
> You can't? Why not? (I'm 99% sure a you can restore a 2000 database with
> NORECOVERY in 2005. You can't however go the other way).
> I'd probably go this route, but do it manually.
> I.e. backup the databases, restore to the 2005 cluster with NORECOVERY.
> Take a logbackup, restore to 2005 with NORECOVERY (to take care of the lag
> in the original backup/restore cycle).
> Repeat until you know the next round of log backup/restores will be quick
> and then schedule the downtime, do one last log backup/restore and then
> switch over to the 2005 server.
> (I'd actually practice this once with a test client and then redo the
> entire process if possible.)
> Script it all out so it's fast and few mistakes.
>
> Seems to me more complicated than it's worth.
>
>|||Geoff,
Once again you are there with the answer!
Thanks
Dave