I am wondering if you can do mirroring in sql server 2005 from an
active/passive server cluster. We have a 2 node active/passive server
cluster operating that has 3 sql server 2005 databases on it. We are
wanting to mirror those databases to another server so query's can be
run against the mirrored copy instead of the production cluster. Will
mirroring function in the configuration. ThanksDatabase Mirroring is orthogonal to failover clustering. So the answer is yes
you can do database mirroring from a cluster.
Linchi
"mmark751969" wrote:
> I am wondering if you can do mirroring in sql server 2005 from an
> active/passive server cluster. We have a 2 node active/passive server
> cluster operating that has 3 sql server 2005 databases on it. We are
> wanting to mirror those databases to another server so query's can be
> run against the mirrored copy instead of the production cluster. Will
> mirroring function in the configuration. Thanks
>
Showing posts with label cluster. Show all posts
Showing posts with label cluster. Show all posts
Wednesday, March 28, 2012
Friday, March 23, 2012
Minimun SP Level for Cluster Upgrade
I'm upgrading MSSQL2000 (RTM) cluster to 2005. I haven't seen any information regarding a minimum service pack level for 2000. This upgrade just makes me overly caution.
To upgrade to SQL 2005, you need to be running SQL 2000 SP3(or SP3a) at a minimum.
Thanks,
Sam Lester (MSFT)
|||Here's the link from Books Online:
http://msdn2.microsoft.com/en-us/library/ms144245.aspx
Sam
Friday, March 9, 2012
Migration to new cluster enviroment
My production system is on stand alone Server and it is a publisher on the
replication system. I need to Migrate to a new hardware with fail over
cluster and upgrade to SQL 2005 .
I need to do that with out impacting replication. What is my options? Can I
do that Or not
If this was to stand alone new hardware I will have no issue.
Thanks for your help
You can't do it without any impact to replication, but you should be able to
with minimal impact.
Build out your new system and test thoroughly. Once you are confident that
the new system performs adequately, then drop your publication on the
production database and copy it (several options here for you) to the new
system.
You will have to redirect your clients to the new host name and reestablish
replication publication.
This should be doable during a reasonable off hours maintenance window.
Sincerely,
Anthony Thomas
<msnews.microsoft.com> wrote in message
news:ek7ECL6THHA.1552@.TK2MSFTNGP05.phx.gbl...
> My production system is on stand alone Server and it is a publisher on the
> replication system. I need to Migrate to a new hardware with fail over
> cluster and upgrade to SQL 2005 .
> I need to do that with out impacting replication. What is my options? Can
I
> do that Or not
> If this was to stand alone new hardware I will have no issue.
> Thanks for your help
>
replication system. I need to Migrate to a new hardware with fail over
cluster and upgrade to SQL 2005 .
I need to do that with out impacting replication. What is my options? Can I
do that Or not
If this was to stand alone new hardware I will have no issue.
Thanks for your help
You can't do it without any impact to replication, but you should be able to
with minimal impact.
Build out your new system and test thoroughly. Once you are confident that
the new system performs adequately, then drop your publication on the
production database and copy it (several options here for you) to the new
system.
You will have to redirect your clients to the new host name and reestablish
replication publication.
This should be doable during a reasonable off hours maintenance window.
Sincerely,
Anthony Thomas
<msnews.microsoft.com> wrote in message
news:ek7ECL6THHA.1552@.TK2MSFTNGP05.phx.gbl...
> My production system is on stand alone Server and it is a publisher on the
> replication system. I need to Migrate to a new hardware with fail over
> cluster and upgrade to SQL 2005 .
> I need to do that with out impacting replication. What is my options? Can
I
> do that Or not
> If this was to stand alone new hardware I will have no issue.
> Thanks for your help
>
Wednesday, March 7, 2012
Migration from SQL2000 to Cluster SQL2005 ?
Hello Everyone,
What is the best solution for my predictament? I'm moving from a single
non-cluster SQL2000 STD environment (Server A) to a clustered SQL 2005 STD
environment (Server B). Seamlessly as possible, how can I migrate the
databases from Server A to Server B? I would like to preserve my instance
name on Server A with the new cluster environment (Server B) if possible.
Thank you
Alex Anderson
You can't do this as an in place upgrade. You are going to have to build
the new cluster, install a SQL Server failover cluster instance, and then
move the databases. The most seamless way would be using a detach/attach or
a backup/restore. You'll have to make sure you take care of the master and
msdb databases as well.
Mike
http://www.solidqualitylearning.com
Disclaimer: This communication is an original work and represents my sole
views on the subject. It does not represent the views of any other person
or entity either by inference or direct reference.
"Alex Anderson" <Alex Anderson@.discussions.microsoft.com> wrote in message
news:BC54F1A0-BEE4-4492-8934-4905C80B8005@.microsoft.com...
> Hello Everyone,
> What is the best solution for my predictament? I'm moving from a single
> non-cluster SQL2000 STD environment (Server A) to a clustered SQL 2005 STD
> environment (Server B). Seamlessly as possible, how can I migrate the
> databases from Server A to Server B? I would like to preserve my instance
> name on Server A with the new cluster environment (Server B) if possible.
> Thank you
> Alex Anderson
What is the best solution for my predictament? I'm moving from a single
non-cluster SQL2000 STD environment (Server A) to a clustered SQL 2005 STD
environment (Server B). Seamlessly as possible, how can I migrate the
databases from Server A to Server B? I would like to preserve my instance
name on Server A with the new cluster environment (Server B) if possible.
Thank you
Alex Anderson
You can't do this as an in place upgrade. You are going to have to build
the new cluster, install a SQL Server failover cluster instance, and then
move the databases. The most seamless way would be using a detach/attach or
a backup/restore. You'll have to make sure you take care of the master and
msdb databases as well.
Mike
http://www.solidqualitylearning.com
Disclaimer: This communication is an original work and represents my sole
views on the subject. It does not represent the views of any other person
or entity either by inference or direct reference.
"Alex Anderson" <Alex Anderson@.discussions.microsoft.com> wrote in message
news:BC54F1A0-BEE4-4492-8934-4905C80B8005@.microsoft.com...
> Hello Everyone,
> What is the best solution for my predictament? I'm moving from a single
> non-cluster SQL2000 STD environment (Server A) to a clustered SQL 2005 STD
> environment (Server B). Seamlessly as possible, how can I migrate the
> databases from Server A to Server B? I would like to preserve my instance
> name on Server A with the new cluster environment (Server B) if possible.
> Thank you
> Alex Anderson
Saturday, February 25, 2012
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
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
Migration from 2000 ro 2005 Cluster
<DaveOtt26.2@.gmail.com> wrote in message
news:1172770995.057390.293120@.j27g2000cwj.googlegr oups.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.googlegr oups.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
news:1172770995.057390.293120@.j27g2000cwj.googlegr oups.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.googlegr oups.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
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...
>> 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
>|||Geoff,
Once again you are there with the answer!
Thanks
Dave
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...
>> 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
>|||Geoff,
Once again you are there with the answer!
Thanks
Dave
Monday, February 20, 2012
Migrating to 64 bit.
I just finished installing MSSQL 2000 to an Itanium cluster and all went
well, but when I tried to use DTS to transfer the users, it says you can't
use 32-bit DTS to transfer to 64-bit. Does anyone have a good trick to
transfer user accounts since I have several and don't know all the
passwords. I can move the databases, jobs, etc...
Nevermind, I just found this...
http://support.microsoft.com/kb/246133/
"Shawn" <shawn.camner@.ccci.org> wrote in message
news:OhRpg3Q3GHA.324@.TK2MSFTNGP05.phx.gbl...
>I just finished installing MSSQL 2000 to an Itanium cluster and all went
>well, but when I tried to use DTS to transfer the users, it says you can't
>use 32-bit DTS to transfer to 64-bit. Does anyone have a good trick to
>transfer user accounts since I have several and don't know all the
>passwords. I can move the databases, jobs, etc...
>
well, but when I tried to use DTS to transfer the users, it says you can't
use 32-bit DTS to transfer to 64-bit. Does anyone have a good trick to
transfer user accounts since I have several and don't know all the
passwords. I can move the databases, jobs, etc...
Nevermind, I just found this...
http://support.microsoft.com/kb/246133/
"Shawn" <shawn.camner@.ccci.org> wrote in message
news:OhRpg3Q3GHA.324@.TK2MSFTNGP05.phx.gbl...
>I just finished installing MSSQL 2000 to an Itanium cluster and all went
>well, but when I tried to use DTS to transfer the users, it says you can't
>use 32-bit DTS to transfer to 64-bit. Does anyone have a good trick to
>transfer user accounts since I have several and don't know all the
>passwords. I can move the databases, jobs, etc...
>
Migrating to 64 bit.
I just finished installing MSSQL 2000 to an Itanium cluster and all went
well, but when I tried to use DTS to transfer the users, it says you can't
use 32-bit DTS to transfer to 64-bit. Does anyone have a good trick to
transfer user accounts since I have several and don't know all the
passwords. I can move the databases, jobs, etc...Nevermind, I just found this...
http://support.microsoft.com/kb/246133/
"Shawn" <shawn.camner@.ccci.org> wrote in message
news:OhRpg3Q3GHA.324@.TK2MSFTNGP05.phx.gbl...
>I just finished installing MSSQL 2000 to an Itanium cluster and all went
>well, but when I tried to use DTS to transfer the users, it says you can't
>use 32-bit DTS to transfer to 64-bit. Does anyone have a good trick to
>transfer user accounts since I have several and don't know all the
>passwords. I can move the databases, jobs, etc...
>
well, but when I tried to use DTS to transfer the users, it says you can't
use 32-bit DTS to transfer to 64-bit. Does anyone have a good trick to
transfer user accounts since I have several and don't know all the
passwords. I can move the databases, jobs, etc...Nevermind, I just found this...
http://support.microsoft.com/kb/246133/
"Shawn" <shawn.camner@.ccci.org> wrote in message
news:OhRpg3Q3GHA.324@.TK2MSFTNGP05.phx.gbl...
>I just finished installing MSSQL 2000 to an Itanium cluster and all went
>well, but when I tried to use DTS to transfer the users, it says you can't
>use 32-bit DTS to transfer to 64-bit. Does anyone have a good trick to
>transfer user accounts since I have several and don't know all the
>passwords. I can move the databases, jobs, etc...
>
Migrating to 64 bit.
I just finished installing MSSQL 2000 to an Itanium cluster and all went
well, but when I tried to use DTS to transfer the users, it says you can't
use 32-bit DTS to transfer to 64-bit. Does anyone have a good trick to
transfer user accounts since I have several and don't know all the
passwords. I can move the databases, jobs, etc...Nevermind, I just found this...
http://support.microsoft.com/kb/246133/
"Shawn" <shawn.camner@.ccci.org> wrote in message
news:OhRpg3Q3GHA.324@.TK2MSFTNGP05.phx.gbl...
>I just finished installing MSSQL 2000 to an Itanium cluster and all went
>well, but when I tried to use DTS to transfer the users, it says you can't
>use 32-bit DTS to transfer to 64-bit. Does anyone have a good trick to
>transfer user accounts since I have several and don't know all the
>passwords. I can move the databases, jobs, etc...
>
well, but when I tried to use DTS to transfer the users, it says you can't
use 32-bit DTS to transfer to 64-bit. Does anyone have a good trick to
transfer user accounts since I have several and don't know all the
passwords. I can move the databases, jobs, etc...Nevermind, I just found this...
http://support.microsoft.com/kb/246133/
"Shawn" <shawn.camner@.ccci.org> wrote in message
news:OhRpg3Q3GHA.324@.TK2MSFTNGP05.phx.gbl...
>I just finished installing MSSQL 2000 to an Itanium cluster and all went
>well, but when I tried to use DTS to transfer the users, it says you can't
>use 32-bit DTS to transfer to 64-bit. Does anyone have a good trick to
>transfer user accounts since I have several and don't know all the
>passwords. I can move the databases, jobs, etc...
>
Subscribe to:
Posts (Atom)