Wednesday, March 28, 2012

Log shipping to DR env

The scenario is a production W2k3 domain running a SQL 2005 cluster and
remotely located DR domain that is a clone of the production domain but is
isolated from a network standpoint. Is there a way to do log shipping - or
some other form of so that the DR dbs can be kept in fairly close (every 24
hours) synch with the production dbs? This is being done in the same sceario
but with SQL 2000 by opening of necessary firewall ports and natting between
the machines and I want to know if its doable in 2005, my DBA claims log
shipping machines must be part of the same domain in Sql 2005.
My goal is to to keep the production domains and DR domains as stand-alone
clones but keep sql in synch. The dba is proposing that the DR machines be
part of the production domain in order to keep the dbs in synch.
ThanksYour DBA is wrong - Log Shipping has nothing to do with domains. As long as
you can automate the scripting involved to backup the TLog on the production
server, copy / ftp it to the DR server & restore it (with no recovery) on
the DR server, you will have the foundations of Log Shipping in place.
Regards,
Greg Linwood
SQL Server MVP
http://blogs.sqlserver.org.au/blogs/greg_linwood
Benchmark your query performance
http://www.SQLBenchmarkPro.com
"pdx" <pdx@.discussions.microsoft.com> wrote in message
news:3EDE4AB5-9793-43A5-B056-1C11D3436A9D@.microsoft.com...
> The scenario is a production W2k3 domain running a SQL 2005 cluster and
> remotely located DR domain that is a clone of the production domain but is
> isolated from a network standpoint. Is there a way to do log shipping - or
> some other form of so that the DR dbs can be kept in fairly close (every
> 24
> hours) synch with the production dbs? This is being done in the same
> sceario
> but with SQL 2000 by opening of necessary firewall ports and natting
> between
> the machines and I want to know if its doable in 2005, my DBA claims log
> shipping machines must be part of the same domain in Sql 2005.
> My goal is to to keep the production domains and DR domains as stand-alone
> clones but keep sql in synch. The dba is proposing that the DR machines be
> part of the production domain in order to keep the dbs in synch.
> Thanks|||Just realised I should've pointed out that "out of the box" Log Shipping
does require domain permissions, but you need to use the standard version
really as it doesn't offer much extra functionality than a few scripts can
achieve as it essentially just builds SQLAgent jobs in the background which
you can easily script yourself..
Regards,
Greg Linwood
SQL Server MVP
http://blogs.sqlserver.org.au/blogs/greg_linwood
Benchmark your query performance
http://www.SQLBenchmarkPro.com
"Greg Linwood" <g_linwood@.hotmail.com> wrote in message
news:uhLQ8D01HHA.3760@.TK2MSFTNGP03.phx.gbl...
> Your DBA is wrong - Log Shipping has nothing to do with domains. As long
> as you can automate the scripting involved to backup the TLog on the
> production server, copy / ftp it to the DR server & restore it (with no
> recovery) on the DR server, you will have the foundations of Log Shipping
> in place.
> Regards,
> Greg Linwood
> SQL Server MVP
> http://blogs.sqlserver.org.au/blogs/greg_linwood
> Benchmark your query performance
> http://www.SQLBenchmarkPro.com
> "pdx" <pdx@.discussions.microsoft.com> wrote in message
> news:3EDE4AB5-9793-43A5-B056-1C11D3436A9D@.microsoft.com...
>|||Thanks for the reply and information.
"Greg Linwood" wrote:

> Just realised I should've pointed out that "out of the box" Log Shipping
> does require domain permissions, but you need to use the standard version
> really as it doesn't offer much extra functionality than a few scripts can
> achieve as it essentially just builds SQLAgent jobs in the background whic
h
> you can easily script yourself..
> Regards,
> Greg Linwood
> SQL Server MVP
> http://blogs.sqlserver.org.au/blogs/greg_linwood
> Benchmark your query performance
> http://www.SQLBenchmarkPro.com
> "Greg Linwood" <g_linwood@.hotmail.com> wrote in message
> news:uhLQ8D01HHA.3760@.TK2MSFTNGP03.phx.gbl...
>
>

No comments:

Post a Comment