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
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 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...
>
>
Showing posts with label scenario. Show all posts
Showing posts with label scenario. Show all posts
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...
>
>
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...
>
>
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...
>> 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
>|||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 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...
> >> 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
> >
> >
>
>
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...
>> 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
>|||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 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...
> >> 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
> >
> >
>
>
Wednesday, March 21, 2012
Log Shipping or something else?
Here's my scenario.
I have two sql servers, one located in another state, but connected via a
continuous vpn so it really looks like it's always on my network.
I only make changes to the sql server on the remote server, but I want the
local server to be as close as possible to having exactly the same data on
it, for primarily queries, etc.
The local server could be read only I guess, but only if no changes would
need to be made to the queries (MS query mostly).
Would log shipping work' Would something else work better'
Also the remote database is call xxx but my local db will be called yyy, but
it will essentially have the same tables in it.
This is because I have hundreds of queries that reference yyy even though
database xxx is our new database that we're using.
Thanks
Alan SawyerHi,
Do you need the local server for reporting or something ?
With Log shipping your local server is not available for reporting or as a
matter of fact for nothing as it requires an exclusive lock on the database
to restore the log and it will forcibly remove the users or the log shipping
job would fail.
I would say a transactional replication would be a better option. You might
wanna explore more on this.
Also refer to this
[url]http://www.sqlservercentral.com/columnists/pibison/logshippingvsreplication.asp[/u
rl]
Hopefully the above gives you a better idea of what you might do. Do let us
know if you face any problem in setting up the same. I am sure some one will
be able to help you.
Abhishek
"asawyer@.chambersREMOVEbelt.com" wrote:
> Here's my scenario.
> I have two sql servers, one located in another state, but connected via a
> continuous vpn so it really looks like it's always on my network.
> I only make changes to the sql server on the remote server, but I want the
> local server to be as close as possible to having exactly the same data on
> it, for primarily queries, etc.
> The local server could be read only I guess, but only if no changes would
> need to be made to the queries (MS query mostly).
> Would log shipping work' Would something else work better'
>
> Also the remote database is call xxx but my local db will be called yyy, b
ut
> it will essentially have the same tables in it.
> This is because I have hundreds of queries that reference yyy even though
> database xxx is our new database that we're using.
> Thanks
> Alan Sawyer
>|||I definetly need access to the local server, as I want to qurey from it.
I'll take a look at what you suggest.
Alan
I have two sql servers, one located in another state, but connected via a
continuous vpn so it really looks like it's always on my network.
I only make changes to the sql server on the remote server, but I want the
local server to be as close as possible to having exactly the same data on
it, for primarily queries, etc.
The local server could be read only I guess, but only if no changes would
need to be made to the queries (MS query mostly).
Would log shipping work' Would something else work better'
Also the remote database is call xxx but my local db will be called yyy, but
it will essentially have the same tables in it.
This is because I have hundreds of queries that reference yyy even though
database xxx is our new database that we're using.
Thanks
Alan SawyerHi,
Do you need the local server for reporting or something ?
With Log shipping your local server is not available for reporting or as a
matter of fact for nothing as it requires an exclusive lock on the database
to restore the log and it will forcibly remove the users or the log shipping
job would fail.
I would say a transactional replication would be a better option. You might
wanna explore more on this.
Also refer to this
[url]http://www.sqlservercentral.com/columnists/pibison/logshippingvsreplication.asp[/u
rl]
Hopefully the above gives you a better idea of what you might do. Do let us
know if you face any problem in setting up the same. I am sure some one will
be able to help you.
Abhishek
"asawyer@.chambersREMOVEbelt.com" wrote:
> Here's my scenario.
> I have two sql servers, one located in another state, but connected via a
> continuous vpn so it really looks like it's always on my network.
> I only make changes to the sql server on the remote server, but I want the
> local server to be as close as possible to having exactly the same data on
> it, for primarily queries, etc.
> The local server could be read only I guess, but only if no changes would
> need to be made to the queries (MS query mostly).
> Would log shipping work' Would something else work better'
>
> Also the remote database is call xxx but my local db will be called yyy, b
ut
> it will essentially have the same tables in it.
> This is because I have hundreds of queries that reference yyy even though
> database xxx is our new database that we're using.
> Thanks
> Alan Sawyer
>|||I definetly need access to the local server, as I want to qurey from it.
I'll take a look at what you suggest.
Alan
Friday, March 9, 2012
Log Shipping Error 4323
Hi all,
Scenario : MS Windows 2003 SP1 - MS SQL Server 2000 EE SP4
Log Shipping
My secondary server was restoring backup logs successfully, but suddenly i got the following error:
[Microsoft SQL-DMO (ODBC SQLState: 42000)] Error 4323: [Microsoft][ODBC SQL Server Driver][SQL Server]The database is marked suspect. Transaction logs cannot be restored. Use RESTORE DATABASE to recover the database.
[Microsoft][ODBC SQL Server Driver][SQL Server]RESTORE LOG is terminating abnormally.
How can I fix this situation without re create the maintenance plan ?
We had the same issue some time ago, this was related to a new file being created in a filegroup on the source. Don't know if this applies to your case, but restoring a backup of this new file on the secondary server solved the pb (unless we had to restore the whole db, sorry I can't remember, my memory is gone... together with the customer :o).
HTH,
Vincent
Log Shipping Error 4323
Hi all,
Scenario : MS Windows 2003 SP1 - MS SQL Server 2000 EE SP4
Log Shipping
My secondary server was restoring backup logs successfully, but suddenly i got the following error:
[Microsoft SQL-DMO (ODBC SQLState: 42000)] Error 4323: [Microsoft][ODBC SQL Server Driver][SQL Server]The database is marked suspect. Transaction logs cannot be restored. Use RESTORE DATABASE to recover the database.
[Microsoft][ODBC SQL Server Driver][SQL Server]RESTORE LOG is terminating abnormally.
How can I fix this situation without re create the maintenance plan ?
We had the same issue some time ago, this was related to a new file being created in a filegroup on the source. Don't know if this applies to your case, but restoring a backup of this new file on the secondary server solved the pb (unless we had to restore the whole db, sorry I can't remember, my memory is gone... together with the customer :o).
HTH,
Vincent
Wednesday, March 7, 2012
Log Shipping and Reporting Servers
My scenario:
One SQL Server (DB4) in Oklahoma, and it's warm standby (DB3) in Oklahoma
(via Log shipping).
One SQL Server in St. Louis (DB1) , which is a distant warm standby (via Log
shipping) over our WAN.
I want a reporting server in St. Louis. I don't necessary want to set up
another log shipping operation across the WAN with the high amount of
activity that the log shipping is dealing with now.. I would like to grab
the databases off of the warm standby in St. Louis and restore/etc to
another server in St. Louis. I don't want to increase traffic over our WAN
when the data is already on here on this server. The log shipping sent to
the St. Louis server happens every 5 minutes.
Is their a best way to accomplish this? I realized I cannot backup up the
current database because they're in Warm Standby mode. Is is possible to
take them out of this mode, back them up, and put them back in that mode for
the Log Shipping to resume?
TIA,
EricEric
You can not do anything with your warm standby in St
Louis, what you can do is use the transaction log backups
that the log shipping is already copying to the server in
St Louis.
You would need to copy the full database from Oklahoma and
restore it to set up the second warm standby, you could
then use the transaction logs that were already being
coppied.
You would need to then set up your own version of log
shipping using the logs you already have.
Hope this helps.
Regards
John
One SQL Server (DB4) in Oklahoma, and it's warm standby (DB3) in Oklahoma
(via Log shipping).
One SQL Server in St. Louis (DB1) , which is a distant warm standby (via Log
shipping) over our WAN.
I want a reporting server in St. Louis. I don't necessary want to set up
another log shipping operation across the WAN with the high amount of
activity that the log shipping is dealing with now.. I would like to grab
the databases off of the warm standby in St. Louis and restore/etc to
another server in St. Louis. I don't want to increase traffic over our WAN
when the data is already on here on this server. The log shipping sent to
the St. Louis server happens every 5 minutes.
Is their a best way to accomplish this? I realized I cannot backup up the
current database because they're in Warm Standby mode. Is is possible to
take them out of this mode, back them up, and put them back in that mode for
the Log Shipping to resume?
TIA,
EricEric
You can not do anything with your warm standby in St
Louis, what you can do is use the transaction log backups
that the log shipping is already copying to the server in
St Louis.
You would need to copy the full database from Oklahoma and
restore it to set up the second warm standby, you could
then use the transaction logs that were already being
coppied.
You would need to then set up your own version of log
shipping using the logs you already have.
Hope this helps.
Regards
John
Subscribe to:
Posts (Atom)