I have two SQL Server databases, each with their own server. Is it suitable
to implement log shipping from each server to the other i.e. rather than
having the standard set up with a production server and a standby server, I
will set it up with two production servers 'swapping' logs...?
Hi,
Instead of "swapping logs" you might want to implement merge
replication, however you don't give a case for why you want to
implement log shipping. Is it for a hot standby (you could setup
clustering) or do you plan to utilise one server for reporting
purposes?
Also the official line from MS is that to implement log shipping both
SQL Server Editions should be Enterprise Version, however if you can
get hold of the SQL Server 2000 Resource Kit there is a Simple Log
Shipper Tool (basically two stored procs) on there. However with the
Enterprise methond it does monitor the log shipping for you. The only
disclaimer is that I could get SLS to work in a dev environment but not
in our production setup, so we went with snapshot replication.
Good Luck
Scott
|||Hi
You can't use log shipping for Scale Out as the destination DB can not be
used for write activities.
If you need to impliment something like scale out, look at replication, but
replication could use more resources than what you might gain by off loading
a server.
Regards
Mike Epprecht, Microsoft SQL Server MVP
Zurich, Switzerland
MVP Program: http://www.microsoft.com/mvp
Blog: http://www.msmvps.com/epprecht/
"Mike" wrote:
> I have two SQL Server databases, each with their own server. Is it suitable
> to implement log shipping from each server to the other i.e. rather than
> having the standard set up with a production server and a standby server, I
> will set it up with two production servers 'swapping' logs...?
>
>
Showing posts with label production. Show all posts
Showing posts with label production. Show all posts
Friday, March 30, 2012
Log Shipping with two production servers
I have two SQL Server databases, each with their own server. Is it suitable
to implement log shipping from each server to the other i.e. rather than
having the standard set up with a production server and a standby server, I
will set it up with two production servers 'swapping' logs...?Hi,
Instead of "swapping logs" you might want to implement merge
replication, however you don't give a case for why you want to
implement log shipping. Is it for a hot standby (you could setup
clustering) or do you plan to utilise one server for reporting
purposes?
Also the official line from MS is that to implement log shipping both
SQL Server Editions should be Enterprise Version, however if you can
get hold of the SQL Server 2000 Resource Kit there is a Simple Log
Shipper Tool (basically two stored procs) on there. However with the
Enterprise methond it does monitor the log shipping for you. The only
disclaimer is that I could get SLS to work in a dev environment but not
in our production setup, so we went with snapshot replication.
Good Luck
Scott|||Hi
You can't use log shipping for Scale Out as the destination DB can not be
used for write activities.
If you need to impliment something like scale out, look at replication, but
replication could use more resources than what you might gain by off loading
a server.
Regards
--
Mike Epprecht, Microsoft SQL Server MVP
Zurich, Switzerland
MVP Program: http://www.microsoft.com/mvp
Blog: http://www.msmvps.com/epprecht/
"Mike" wrote:
> I have two SQL Server databases, each with their own server. Is it suitabl
e
> to implement log shipping from each server to the other i.e. rather than
> having the standard set up with a production server and a standby server,
I
> will set it up with two production servers 'swapping' logs...?
>
>
to implement log shipping from each server to the other i.e. rather than
having the standard set up with a production server and a standby server, I
will set it up with two production servers 'swapping' logs...?Hi,
Instead of "swapping logs" you might want to implement merge
replication, however you don't give a case for why you want to
implement log shipping. Is it for a hot standby (you could setup
clustering) or do you plan to utilise one server for reporting
purposes?
Also the official line from MS is that to implement log shipping both
SQL Server Editions should be Enterprise Version, however if you can
get hold of the SQL Server 2000 Resource Kit there is a Simple Log
Shipper Tool (basically two stored procs) on there. However with the
Enterprise methond it does monitor the log shipping for you. The only
disclaimer is that I could get SLS to work in a dev environment but not
in our production setup, so we went with snapshot replication.
Good Luck
Scott|||Hi
You can't use log shipping for Scale Out as the destination DB can not be
used for write activities.
If you need to impliment something like scale out, look at replication, but
replication could use more resources than what you might gain by off loading
a server.
Regards
--
Mike Epprecht, Microsoft SQL Server MVP
Zurich, Switzerland
MVP Program: http://www.microsoft.com/mvp
Blog: http://www.msmvps.com/epprecht/
"Mike" wrote:
> I have two SQL Server databases, each with their own server. Is it suitabl
e
> to implement log shipping from each server to the other i.e. rather than
> having the standard set up with a production server and a standby server,
I
> will set it up with two production servers 'swapping' logs...?
>
>
Log Shipping with two production servers
I have two SQL Server databases, each with their own server. Is it suitable
to implement log shipping from each server to the other i.e. rather than
having the standard set up with a production server and a standby server, I
will set it up with two production servers 'swapping' logs...?Hi,
Instead of "swapping logs" you might want to implement merge
replication, however you don't give a case for why you want to
implement log shipping. Is it for a hot standby (you could setup
clustering) or do you plan to utilise one server for reporting
purposes?
Also the official line from MS is that to implement log shipping both
SQL Server Editions should be Enterprise Version, however if you can
get hold of the SQL Server 2000 Resource Kit there is a Simple Log
Shipper Tool (basically two stored procs) on there. However with the
Enterprise methond it does monitor the log shipping for you. The only
disclaimer is that I could get SLS to work in a dev environment but not
in our production setup, so we went with snapshot replication.
Good Luck
Scott|||Hi
You can't use log shipping for Scale Out as the destination DB can not be
used for write activities.
If you need to impliment something like scale out, look at replication, but
replication could use more resources than what you might gain by off loading
a server.
Regards
--
Mike Epprecht, Microsoft SQL Server MVP
Zurich, Switzerland
MVP Program: http://www.microsoft.com/mvp
Blog: http://www.msmvps.com/epprecht/
"Mike" wrote:
> I have two SQL Server databases, each with their own server. Is it suitable
> to implement log shipping from each server to the other i.e. rather than
> having the standard set up with a production server and a standby server, I
> will set it up with two production servers 'swapping' logs...?
>
>
to implement log shipping from each server to the other i.e. rather than
having the standard set up with a production server and a standby server, I
will set it up with two production servers 'swapping' logs...?Hi,
Instead of "swapping logs" you might want to implement merge
replication, however you don't give a case for why you want to
implement log shipping. Is it for a hot standby (you could setup
clustering) or do you plan to utilise one server for reporting
purposes?
Also the official line from MS is that to implement log shipping both
SQL Server Editions should be Enterprise Version, however if you can
get hold of the SQL Server 2000 Resource Kit there is a Simple Log
Shipper Tool (basically two stored procs) on there. However with the
Enterprise methond it does monitor the log shipping for you. The only
disclaimer is that I could get SLS to work in a dev environment but not
in our production setup, so we went with snapshot replication.
Good Luck
Scott|||Hi
You can't use log shipping for Scale Out as the destination DB can not be
used for write activities.
If you need to impliment something like scale out, look at replication, but
replication could use more resources than what you might gain by off loading
a server.
Regards
--
Mike Epprecht, Microsoft SQL Server MVP
Zurich, Switzerland
MVP Program: http://www.microsoft.com/mvp
Blog: http://www.msmvps.com/epprecht/
"Mike" wrote:
> I have two SQL Server databases, each with their own server. Is it suitable
> to implement log shipping from each server to the other i.e. rather than
> having the standard set up with a production server and a standby server, I
> will set it up with two production servers 'swapping' logs...?
>
>
Log Shipping vs Replication
I am seting up log shipping from a production SQL 2000 Enterprise server to a
similar server in our Disaster Recovery Site.
Various problems with log shipping have forced to rethink its use. I was
wondering how replication stacks up against Log Shipping, especially in the
areas of fail over and availability. I would want to cut over to the SQL
Server in the DR site in case of problems occuring. The two sites have a high
speed (~100 Megabit) link between them.
Thanks.
Sam
Log Shipping "replicates" the entire database as well as system objects,
permissions and database users.
While applying the logs the users cannot access the destination database.
Log Shipping's latency is at best 1 minute, assuming 0 s to copy the dumped
transaction log, and 0 seconds to apply it. In practice the latency is
around 2 minutes.
Log Shipping requires that the destination database be read only.
Transactional replication allows you to select which objects you wish to
replicate, and you can filter these objects by column or by row. Each table
object you replicate must have a PK.
Latency is at best a couple of seconds (setting the PollingInterval to 1s on
both the log reader and distribution agent), however underload you will
probably see a latency of 1 - 2 minutes.
With Transactional Replication users can access and update the subscription
database.
Paul Ibison has written an article on the differences which I can't locate
right now. I think its on SQL Server Central.
"Sam" <Sam@.discussions.microsoft.com> wrote in message
news:D0A5697C-6290-457C-8FC6-40FF814F409C@.microsoft.com...
> I am seting up log shipping from a production SQL 2000 Enterprise server
to a
> similar server in our Disaster Recovery Site.
> Various problems with log shipping have forced to rethink its use. I was
> wondering how replication stacks up against Log Shipping, especially in
the
> areas of fail over and availability. I would want to cut over to the SQL
> Server in the DR site in case of problems occuring. The two sites have a
high
> speed (~100 Megabit) link between them.
> Thanks.
> Sam
|||Sam,
I did a comparison of the functionality of these 2 methods on
sqlservercentral.com - it's also in the articles section on
www.replicationanswers.com. The article concentrates on the functional
differences, as they are not identical or equivalent. Although not exactly
what you are asking for it might still be useful.
Rgds,
Paul Ibison SQL Server MVP, www.replicationanswers.com
(recommended sql server 2000 replication book:
http://www.nwsu.com/0974973602p.html)
|||Hillary - thank you for your comments and information.
Paul - thank you for pointing out the articles on both web sites. I think I
will be purchasing your book before I do any real work on it.
Sam
"Paul Ibison" wrote:
> Sam,
> I did a comparison of the functionality of these 2 methods on
> sqlservercentral.com - it's also in the articles section on
> www.replicationanswers.com. The article concentrates on the functional
> differences, as they are not identical or equivalent. Although not exactly
> what you are asking for it might still be useful.
> Rgds,
> Paul Ibison SQL Server MVP, www.replicationanswers.com
> (recommended sql server 2000 replication book:
> http://www.nwsu.com/0974973602p.html)
>
>
|||Sam,
I wish I'd written it, but Hilary is the author
Rgds,
Paul
"Sam" <Sam@.discussions.microsoft.com> wrote in message
news:AEF16260-42B1-469E-AC30-F55C059C8536@.microsoft.com...
> Hillary - thank you for your comments and information.
> Paul - thank you for pointing out the articles on both web sites. I think
I[vbcol=seagreen]
> will be purchasing your book before I do any real work on it.
> Sam
> "Paul Ibison" wrote:
exactly[vbcol=seagreen]
sql
similar server in our Disaster Recovery Site.
Various problems with log shipping have forced to rethink its use. I was
wondering how replication stacks up against Log Shipping, especially in the
areas of fail over and availability. I would want to cut over to the SQL
Server in the DR site in case of problems occuring. The two sites have a high
speed (~100 Megabit) link between them.
Thanks.
Sam
Log Shipping "replicates" the entire database as well as system objects,
permissions and database users.
While applying the logs the users cannot access the destination database.
Log Shipping's latency is at best 1 minute, assuming 0 s to copy the dumped
transaction log, and 0 seconds to apply it. In practice the latency is
around 2 minutes.
Log Shipping requires that the destination database be read only.
Transactional replication allows you to select which objects you wish to
replicate, and you can filter these objects by column or by row. Each table
object you replicate must have a PK.
Latency is at best a couple of seconds (setting the PollingInterval to 1s on
both the log reader and distribution agent), however underload you will
probably see a latency of 1 - 2 minutes.
With Transactional Replication users can access and update the subscription
database.
Paul Ibison has written an article on the differences which I can't locate
right now. I think its on SQL Server Central.
"Sam" <Sam@.discussions.microsoft.com> wrote in message
news:D0A5697C-6290-457C-8FC6-40FF814F409C@.microsoft.com...
> I am seting up log shipping from a production SQL 2000 Enterprise server
to a
> similar server in our Disaster Recovery Site.
> Various problems with log shipping have forced to rethink its use. I was
> wondering how replication stacks up against Log Shipping, especially in
the
> areas of fail over and availability. I would want to cut over to the SQL
> Server in the DR site in case of problems occuring. The two sites have a
high
> speed (~100 Megabit) link between them.
> Thanks.
> Sam
|||Sam,
I did a comparison of the functionality of these 2 methods on
sqlservercentral.com - it's also in the articles section on
www.replicationanswers.com. The article concentrates on the functional
differences, as they are not identical or equivalent. Although not exactly
what you are asking for it might still be useful.
Rgds,
Paul Ibison SQL Server MVP, www.replicationanswers.com
(recommended sql server 2000 replication book:
http://www.nwsu.com/0974973602p.html)
|||Hillary - thank you for your comments and information.
Paul - thank you for pointing out the articles on both web sites. I think I
will be purchasing your book before I do any real work on it.
Sam
"Paul Ibison" wrote:
> Sam,
> I did a comparison of the functionality of these 2 methods on
> sqlservercentral.com - it's also in the articles section on
> www.replicationanswers.com. The article concentrates on the functional
> differences, as they are not identical or equivalent. Although not exactly
> what you are asking for it might still be useful.
> Rgds,
> Paul Ibison SQL Server MVP, www.replicationanswers.com
> (recommended sql server 2000 replication book:
> http://www.nwsu.com/0974973602p.html)
>
>
|||Sam,
I wish I'd written it, but Hilary is the author
Rgds,
Paul
"Sam" <Sam@.discussions.microsoft.com> wrote in message
news:AEF16260-42B1-469E-AC30-F55C059C8536@.microsoft.com...
> Hillary - thank you for your comments and information.
> Paul - thank you for pointing out the articles on both web sites. I think
I[vbcol=seagreen]
> will be purchasing your book before I do any real work on it.
> Sam
> "Paul Ibison" wrote:
exactly[vbcol=seagreen]
sql
Log shipping trn file retention
What's the logshipping trn file retention most DBA usually set, 1,2 or 3
days? I am curious. In our production database, we set our LS file retention
for 3 days and I am just wonder if it 's too long or too short. Is there a
guideline or some short.
Thanks in advance
PhilN wrote:
> What's the logshipping trn file retention most DBA usually set, 1,2 or 3
> days? I am curious. In our production database, we set our LS file retention
> for 3 days and I am just wonder if it 's too long or too short. Is there a
> guideline or some short.
> Thanks in advance
>
We use a home-grown log shipping process here, and keep a solid week's
worth of backups. As each log is restored, it is zipped up into an
archive for that day. At any given point, we have 7 zip files,
containing the t-logs for the previous 7 days.
Tracy McKibben
MCDBA
http://www.realsqlguy.com
days? I am curious. In our production database, we set our LS file retention
for 3 days and I am just wonder if it 's too long or too short. Is there a
guideline or some short.
Thanks in advance
PhilN wrote:
> What's the logshipping trn file retention most DBA usually set, 1,2 or 3
> days? I am curious. In our production database, we set our LS file retention
> for 3 days and I am just wonder if it 's too long or too short. Is there a
> guideline or some short.
> Thanks in advance
>
We use a home-grown log shipping process here, and keep a solid week's
worth of backups. As each log is restored, it is zipped up into an
archive for that day. At any given point, we have 7 zip files,
containing the t-logs for the previous 7 days.
Tracy McKibben
MCDBA
http://www.realsqlguy.com
Log shipping trn file retention
What's the logshipping trn file retention most DBA usually set, 1,2 or 3
days? I am curious. In our production database, we set our LS file retention
for 3 days and I am just wonder if it 's too long or too short. Is there a
guideline or some short.
Thanks in advancePhilN wrote:
> What's the logshipping trn file retention most DBA usually set, 1,2 or 3
> days? I am curious. In our production database, we set our LS file retention
> for 3 days and I am just wonder if it 's too long or too short. Is there a
> guideline or some short.
> Thanks in advance
>
We use a home-grown log shipping process here, and keep a solid week's
worth of backups. As each log is restored, it is zipped up into an
archive for that day. At any given point, we have 7 zip files,
containing the t-logs for the previous 7 days.
Tracy McKibben
MCDBA
http://www.realsqlguy.comsql
days? I am curious. In our production database, we set our LS file retention
for 3 days and I am just wonder if it 's too long or too short. Is there a
guideline or some short.
Thanks in advancePhilN wrote:
> What's the logshipping trn file retention most DBA usually set, 1,2 or 3
> days? I am curious. In our production database, we set our LS file retention
> for 3 days and I am just wonder if it 's too long or too short. Is there a
> guideline or some short.
> Thanks in advance
>
We use a home-grown log shipping process here, and keep a solid week's
worth of backups. As each log is restored, it is zipped up into an
archive for that day. At any given point, we have 7 zip files,
containing the t-logs for the previous 7 days.
Tracy McKibben
MCDBA
http://www.realsqlguy.comsql
Log shipping trn file retention
What's the logshipping trn file retention most DBA usually set, 1,2 or 3
days? I am curious. In our production database, we set our LS file retention
for 3 days and I am just wonder if it 's too long or too short. Is there a
guideline or some short.
Thanks in advancePhilN wrote:
> What's the logshipping trn file retention most DBA usually set, 1,2 or 3
> days? I am curious. In our production database, we set our LS file retenti
on
> for 3 days and I am just wonder if it 's too long or too short. Is there a
> guideline or some short.
> Thanks in advance
>
We use a home-grown log shipping process here, and keep a solid week's
worth of backups. As each log is restored, it is zipped up into an
archive for that day. At any given point, we have 7 zip files,
containing the t-logs for the previous 7 days.
Tracy McKibben
MCDBA
http://www.realsqlguy.com
days? I am curious. In our production database, we set our LS file retention
for 3 days and I am just wonder if it 's too long or too short. Is there a
guideline or some short.
Thanks in advancePhilN wrote:
> What's the logshipping trn file retention most DBA usually set, 1,2 or 3
> days? I am curious. In our production database, we set our LS file retenti
on
> for 3 days and I am just wonder if it 's too long or too short. Is there a
> guideline or some short.
> Thanks in advance
>
We use a home-grown log shipping process here, and keep a solid week's
worth of backups. As each log is restored, it is zipped up into an
archive for that day. At any given point, we have 7 zip files,
containing the t-logs for the previous 7 days.
Tracy McKibben
MCDBA
http://www.realsqlguy.com
Wednesday, March 28, 2012
Log Shipping transaction log backup files have wrong timestamp
I'm experiencing a weird problem with log shipping in SQL 2005.
I've setup Log Shipping for a production database between two sites. The standby database is being updated correctly and everything seems to be working as expected but for one detail: the name of the transaction log backups are generated with an UTC timestamp instead of my local timezone.
The the data below extracted from the backup history:
2007-06-23 17:30:00.000 D:\Backup\Databases\mydb\mydb_20070623073000.trn
2007-06-23 17:15:00.000 D:\Backup\Databases\mydb\mydb_20070623071500.trn
2007-06-23 17:00:00.000 D:\Backup\Databases\mydb\mydb_20070623070000.trn
2007-06-23 16:45:00.000 D:\Backup\Databases\mydb\mydb_20070623064500.trn
My timezone here is GMT+10.
Although it's not affecting Log Shipping, it's very confusing as the full backups have a timestamp in the local timezone!
Has anyone seen experienced something similar to this? Please see below my SQL details:
1 ProductName NULL Microsoft SQL Server
2 ProductVersion 589824 9.00.3042.00
3 Language 1033 English (United States)
4 Platform NULL NT AMD64
5 Comments NULL NT AMD64
6 CompanyName NULL Microsoft Corporation
7 FileDescription NULL SQL Server Windows NT - 64 Bit
8 FileVersion NULL 2005.090.3042.00
9 InternalName NULL SQLSERVR
10 LegalCopyright NULL ? Microsoft Corp. All rights reserved.
11 LegalTrademarks NULL Microsoft? is a registered trademark of Microsoft Corporation. Windows(TM) is a trademark of Microsoft Corporation
12 OriginalFilename NULL SQLSERVR.EXE
13 PrivateBuild NULL NULL
14 SpecialBuild 199360512 NULL
15 WindowsVersion 248381957 5.2 (3790)
16 ProcessorCount 4 4
17 ProcessorActiveMask 4 f
18 ProcessorType 8664 NULL
19 PhysicalMemory 4095 4095 (4294037504)
20 Product ID NULL NULL
Thanks,
Andr
Hi Andre
The use of UTC timestamp for the log shipping files is by design and how log shipping is supposed to work. The main reason for this is so that there is no way timestamps can jump backward or forward when daylight savings time starts or finishes, for example. Log shipping uses the timestamps to work out if there is anything new to process and using UTC ensures this process works reliably.
Thanks, Mark
|||Thanks, Mark.It would be good, though, that the maintenance plan's backup task had at least an option to use the same approach when naming backup files, for consistency purposes.
Is this feature documented in Books Online? I couldn't find any reference.
Thanks,
Andr
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.
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...
>
>
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...
>
>
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
> >
> >
>
>
Monday, March 26, 2012
Log Shipping Restore Error 3456
Hi,
I've got a production server log shipping a 280GB database to a remote DR
site server. It has been running without incident for months now, but last
week it stopped restoring logs (the copy process was still running) with an
error 3456:
[Microsoft SQL-DMO (ODBC SQLState: HY000)] Error 3456: [Microsoft][ODBC SQL
Server Driver][SQL Server]Could not redo log record (500478:68225:4), for
transaction ID (3:1085081790), on page (3:2789016), database 'JDE_Prod' (5).
Page: LSN = (500478:57038:10), type = 2. Log: OpCode = 2, context 3,
PrevPageLSN: (500478:68221:4).
I restored the remote database from a full tape backup shipped to the site
via courier (because we weren't sure if the link was to blame for the problem
restoring). Log shipping worked well again for a few days, but this morning
has again stopped restoring with the exact same error!
I've read the article "http://support.microsoft.com/kb/831950", and although
it describes the same error, it doesnt seem to apply to us as we weren't
doing any role changing, and weren't backing up the database manually with
the NORECOVERY switch (i.e. the backups were being done as usual by the log
shipping maint. plan).
Local server build is 8.00.997, and remote (DR) server build is 8.00.818.
Could the fact that they are slightly different versions have anything to do
with this problem?
Could this be corruption introducted by the network link? If so, is the
only way to fix this to fully restore the database again? Or is there some
way to get good copies of the log it failed on and restore those manually? I
don't have a huge amount of experience with log shipping, so any help would
be greatly appreciated - especially being a 24/7 mission critical DR server,
and in the middle of the holidays! Murphy's Law!
Thanks,
david
Hi David
The SQL Builds may cause a problem. I am not sure about it.
Rearding the file restore; it isn't necessary that you restore the entire
db. I would suggest the following steps:
1) Check the table msdb..log_shipping_plan_history for the last loaded file.
try
select * from msdb..log_shipping_plan_history order by endtime desc
2) Try restoring tha tfile manually from the Query Analyzer. try
restore log
<db_name>
from
disk = 'file_path'
with
standby = 'undo.txt'
3) if the above step succeeds keep restoring the successive trn files till
the step fails. Then that file at which the step fails is the corrupt file.
4) Copy only that file from the primary server and try step 2 with it.
5) re-run the LS Jobs and the ywill succeed.
Hope this helps.
I shall get back with mpre information about the affect of SQL builds on LS.
Thanks
Amer M J
MCP
"DavidCur" wrote:
> Hi,
> I've got a production server log shipping a 280GB database to a remote DR
> site server. It has been running without incident for months now, but last
> week it stopped restoring logs (the copy process was still running) with an
> error 3456:
> [Microsoft SQL-DMO (ODBC SQLState: HY000)] Error 3456: [Microsoft][ODBC SQL
> Server Driver][SQL Server]Could not redo log record (500478:68225:4), for
> transaction ID (3:1085081790), on page (3:2789016), database 'JDE_Prod' (5).
> Page: LSN = (500478:57038:10), type = 2. Log: OpCode = 2, context 3,
> PrevPageLSN: (500478:68221:4).
> I restored the remote database from a full tape backup shipped to the site
> via courier (because we weren't sure if the link was to blame for the problem
> restoring). Log shipping worked well again for a few days, but this morning
> has again stopped restoring with the exact same error!
> I've read the article "http://support.microsoft.com/kb/831950", and although
> it describes the same error, it doesnt seem to apply to us as we weren't
> doing any role changing, and weren't backing up the database manually with
> the NORECOVERY switch (i.e. the backups were being done as usual by the log
> shipping maint. plan).
> Local server build is 8.00.997, and remote (DR) server build is 8.00.818.
> Could the fact that they are slightly different versions have anything to do
> with this problem?
> Could this be corruption introducted by the network link? If so, is the
> only way to fix this to fully restore the database again? Or is there some
> way to get good copies of the log it failed on and restore those manually? I
> don't have a huge amount of experience with log shipping, so any help would
> be greatly appreciated - especially being a 24/7 mission critical DR server,
> and in the middle of the holidays! Murphy's Law!
>
> Thanks,
> david
|||Thanks for the quick response. The log files are copied and restored every
15 minutes. The problem occurred this morning around 12:15am. I've tried
your suggestion about restoring manually with the standby undo file.
I ran the following command (using the 12:00am file) successfully, but the
12:15am file produces the following output:
restore log JDE_Prod
from disk = 'K:\Backups\DRLogsIn\JDE_Prod_tlog_200512300015.TR N'
with standby = 'K:\Backups\DRLogsIn\LogUndo.tuf'
Deleting database file 'K:\Backups\DRLogsIn\LogUndo.tuf'.
Processed 34415 pages for database 'JDE_Prod', file 'JDE_PRODUCTION_log' on
file 1.
Server: Msg 3456, Level 21, State 1, Line 1
Could not redo log record (500478:68225:4), for transaction ID
(3:1085081790), on page (3:2789016), database 'JDE_Prod' (5). Page: LSN =
(500478:57038:10), type = 2. Log: OpCode = 2, context 3, PrevPageLSN:
(500478:68221:4).
Connection Broken
This 12:15 file has already been re-copied, but I will try again.
Would be interesting to see if you find any issues with different builds in
log shipping. The patches were applied to the local server a few months ago
(3 or 4 months), and log shipping has been running without incident this
whole time.
Thanks again,
Dave
"Amer M J" wrote:
> Hi David
> The SQL Builds may cause a problem. I am not sure about it.
> Rearding the file restore; it isn't necessary that you restore the entire
> db. I would suggest the following steps:
> 1) Check the table msdb..log_shipping_plan_history for the last loaded file.
> try
> select * from msdb..log_shipping_plan_history order by endtime desc
> 2) Try restoring tha tfile manually from the Query Analyzer. try
> restore log
> <db_name>
> from
> disk = 'file_path'
> with
> standby = 'undo.txt'
> 3) if the above step succeeds keep restoring the successive trn files till
> the step fails. Then that file at which the step fails is the corrupt file.
> 4) Copy only that file from the primary server and try step 2 with it.
> 5) re-run the LS Jobs and the ywill succeed.
> Hope this helps.
> I shall get back with mpre information about the affect of SQL builds on LS.
> Thanks
> Amer M J
> MCP
|||Hi Dave
I am curious here. Was the '.tuf' file deleted as per a part of the process
of manually ?
Also the builds do play a major role here. From what I can see as per your
information, the primary server is of a higher build than the secondary
server. So I was wondering how a log file of a db from a higher build was
getting restored onto a lower build server.
Also I would suggest checking out the integrity of the trn files on the
primary server. try
restore verifyonly command to check the backup set's integrity.
Please do check if anyother process is accessing the db on the secondary
server as this may disrupt the LS process.
Also check this link.
http://support.microsoft.com/kb/329487/en-us
Thanks
Amer M J
MCP
"DavidCur" wrote:
[vbcol=seagreen]
> Thanks for the quick response. The log files are copied and restored every
> 15 minutes. The problem occurred this morning around 12:15am. I've tried
> your suggestion about restoring manually with the standby undo file.
> I ran the following command (using the 12:00am file) successfully, but the
> 12:15am file produces the following output:
> restore log JDE_Prod
> from disk = 'K:\Backups\DRLogsIn\JDE_Prod_tlog_200512300015.TR N'
> with standby = 'K:\Backups\DRLogsIn\LogUndo.tuf'
> Deleting database file 'K:\Backups\DRLogsIn\LogUndo.tuf'.
> Processed 34415 pages for database 'JDE_Prod', file 'JDE_PRODUCTION_log' on
> file 1.
> Server: Msg 3456, Level 21, State 1, Line 1
> Could not redo log record (500478:68225:4), for transaction ID
> (3:1085081790), on page (3:2789016), database 'JDE_Prod' (5). Page: LSN =
> (500478:57038:10), type = 2. Log: OpCode = 2, context 3, PrevPageLSN:
> (500478:68221:4).
> Connection Broken
> This 12:15 file has already been re-copied, but I will try again.
> Would be interesting to see if you find any issues with different builds in
> log shipping. The patches were applied to the local server a few months ago
> (3 or 4 months), and log shipping has been running without incident this
> whole time.
> Thanks again,
> Dave
>
> "Amer M J" wrote:
|||Hi again,
Yes, the standby file (whatever it has been called) is automatically deleted
by the restore process.
Good news though, I seem to have log shipping going again! :-)
I re-copied the 12:15am log file (yet again, 3rd time) and restored it with
the same syntax as in my previous post, and it worked. So the problem must
lie with our link to the remote DR server. Its now been logged to the
telecom company who provide the WAN pipe.
As a precautionary measure I will schedule the remote server to be patched
to the same build level as our local server (will be next year though as we
are in a "holiday change freeze" now).
Funnily enough, the restore headeronly, verifyonly and filelistonly all
seemed to work fine with the corrupt file. Is it possible that the header of
the file was okay, while the actual data was bad?
Thanks very much for the help though, and I will update with anything new we
find.
Dave
"Amer M J" wrote:
> Hi Dave
> I am curious here. Was the '.tuf' file deleted as per a part of the process
> of manually ?
> Also the builds do play a major role here. From what I can see as per your
> information, the primary server is of a higher build than the secondary
> server. So I was wondering how a log file of a db from a higher build was
> getting restored onto a lower build server.
> Also I would suggest checking out the integrity of the trn files on the
> primary server. try
> restore verifyonly command to check the backup set's integrity.
> Please do check if anyother process is accessing the db on the secondary
> server as this may disrupt the LS process.
> Also check this link.
> http://support.microsoft.com/kb/329487/en-us
> Thanks
> Amer M J
> MCP
sql
I've got a production server log shipping a 280GB database to a remote DR
site server. It has been running without incident for months now, but last
week it stopped restoring logs (the copy process was still running) with an
error 3456:
[Microsoft SQL-DMO (ODBC SQLState: HY000)] Error 3456: [Microsoft][ODBC SQL
Server Driver][SQL Server]Could not redo log record (500478:68225:4), for
transaction ID (3:1085081790), on page (3:2789016), database 'JDE_Prod' (5).
Page: LSN = (500478:57038:10), type = 2. Log: OpCode = 2, context 3,
PrevPageLSN: (500478:68221:4).
I restored the remote database from a full tape backup shipped to the site
via courier (because we weren't sure if the link was to blame for the problem
restoring). Log shipping worked well again for a few days, but this morning
has again stopped restoring with the exact same error!
I've read the article "http://support.microsoft.com/kb/831950", and although
it describes the same error, it doesnt seem to apply to us as we weren't
doing any role changing, and weren't backing up the database manually with
the NORECOVERY switch (i.e. the backups were being done as usual by the log
shipping maint. plan).
Local server build is 8.00.997, and remote (DR) server build is 8.00.818.
Could the fact that they are slightly different versions have anything to do
with this problem?
Could this be corruption introducted by the network link? If so, is the
only way to fix this to fully restore the database again? Or is there some
way to get good copies of the log it failed on and restore those manually? I
don't have a huge amount of experience with log shipping, so any help would
be greatly appreciated - especially being a 24/7 mission critical DR server,
and in the middle of the holidays! Murphy's Law!
Thanks,
david
Hi David
The SQL Builds may cause a problem. I am not sure about it.
Rearding the file restore; it isn't necessary that you restore the entire
db. I would suggest the following steps:
1) Check the table msdb..log_shipping_plan_history for the last loaded file.
try
select * from msdb..log_shipping_plan_history order by endtime desc
2) Try restoring tha tfile manually from the Query Analyzer. try
restore log
<db_name>
from
disk = 'file_path'
with
standby = 'undo.txt'
3) if the above step succeeds keep restoring the successive trn files till
the step fails. Then that file at which the step fails is the corrupt file.
4) Copy only that file from the primary server and try step 2 with it.
5) re-run the LS Jobs and the ywill succeed.
Hope this helps.
I shall get back with mpre information about the affect of SQL builds on LS.
Thanks
Amer M J
MCP
"DavidCur" wrote:
> Hi,
> I've got a production server log shipping a 280GB database to a remote DR
> site server. It has been running without incident for months now, but last
> week it stopped restoring logs (the copy process was still running) with an
> error 3456:
> [Microsoft SQL-DMO (ODBC SQLState: HY000)] Error 3456: [Microsoft][ODBC SQL
> Server Driver][SQL Server]Could not redo log record (500478:68225:4), for
> transaction ID (3:1085081790), on page (3:2789016), database 'JDE_Prod' (5).
> Page: LSN = (500478:57038:10), type = 2. Log: OpCode = 2, context 3,
> PrevPageLSN: (500478:68221:4).
> I restored the remote database from a full tape backup shipped to the site
> via courier (because we weren't sure if the link was to blame for the problem
> restoring). Log shipping worked well again for a few days, but this morning
> has again stopped restoring with the exact same error!
> I've read the article "http://support.microsoft.com/kb/831950", and although
> it describes the same error, it doesnt seem to apply to us as we weren't
> doing any role changing, and weren't backing up the database manually with
> the NORECOVERY switch (i.e. the backups were being done as usual by the log
> shipping maint. plan).
> Local server build is 8.00.997, and remote (DR) server build is 8.00.818.
> Could the fact that they are slightly different versions have anything to do
> with this problem?
> Could this be corruption introducted by the network link? If so, is the
> only way to fix this to fully restore the database again? Or is there some
> way to get good copies of the log it failed on and restore those manually? I
> don't have a huge amount of experience with log shipping, so any help would
> be greatly appreciated - especially being a 24/7 mission critical DR server,
> and in the middle of the holidays! Murphy's Law!
>
> Thanks,
> david
|||Thanks for the quick response. The log files are copied and restored every
15 minutes. The problem occurred this morning around 12:15am. I've tried
your suggestion about restoring manually with the standby undo file.
I ran the following command (using the 12:00am file) successfully, but the
12:15am file produces the following output:
restore log JDE_Prod
from disk = 'K:\Backups\DRLogsIn\JDE_Prod_tlog_200512300015.TR N'
with standby = 'K:\Backups\DRLogsIn\LogUndo.tuf'
Deleting database file 'K:\Backups\DRLogsIn\LogUndo.tuf'.
Processed 34415 pages for database 'JDE_Prod', file 'JDE_PRODUCTION_log' on
file 1.
Server: Msg 3456, Level 21, State 1, Line 1
Could not redo log record (500478:68225:4), for transaction ID
(3:1085081790), on page (3:2789016), database 'JDE_Prod' (5). Page: LSN =
(500478:57038:10), type = 2. Log: OpCode = 2, context 3, PrevPageLSN:
(500478:68221:4).
Connection Broken
This 12:15 file has already been re-copied, but I will try again.
Would be interesting to see if you find any issues with different builds in
log shipping. The patches were applied to the local server a few months ago
(3 or 4 months), and log shipping has been running without incident this
whole time.
Thanks again,
Dave
"Amer M J" wrote:
> Hi David
> The SQL Builds may cause a problem. I am not sure about it.
> Rearding the file restore; it isn't necessary that you restore the entire
> db. I would suggest the following steps:
> 1) Check the table msdb..log_shipping_plan_history for the last loaded file.
> try
> select * from msdb..log_shipping_plan_history order by endtime desc
> 2) Try restoring tha tfile manually from the Query Analyzer. try
> restore log
> <db_name>
> from
> disk = 'file_path'
> with
> standby = 'undo.txt'
> 3) if the above step succeeds keep restoring the successive trn files till
> the step fails. Then that file at which the step fails is the corrupt file.
> 4) Copy only that file from the primary server and try step 2 with it.
> 5) re-run the LS Jobs and the ywill succeed.
> Hope this helps.
> I shall get back with mpre information about the affect of SQL builds on LS.
> Thanks
> Amer M J
> MCP
|||Hi Dave
I am curious here. Was the '.tuf' file deleted as per a part of the process
of manually ?
Also the builds do play a major role here. From what I can see as per your
information, the primary server is of a higher build than the secondary
server. So I was wondering how a log file of a db from a higher build was
getting restored onto a lower build server.
Also I would suggest checking out the integrity of the trn files on the
primary server. try
restore verifyonly command to check the backup set's integrity.
Please do check if anyother process is accessing the db on the secondary
server as this may disrupt the LS process.
Also check this link.
http://support.microsoft.com/kb/329487/en-us
Thanks
Amer M J
MCP
"DavidCur" wrote:
[vbcol=seagreen]
> Thanks for the quick response. The log files are copied and restored every
> 15 minutes. The problem occurred this morning around 12:15am. I've tried
> your suggestion about restoring manually with the standby undo file.
> I ran the following command (using the 12:00am file) successfully, but the
> 12:15am file produces the following output:
> restore log JDE_Prod
> from disk = 'K:\Backups\DRLogsIn\JDE_Prod_tlog_200512300015.TR N'
> with standby = 'K:\Backups\DRLogsIn\LogUndo.tuf'
> Deleting database file 'K:\Backups\DRLogsIn\LogUndo.tuf'.
> Processed 34415 pages for database 'JDE_Prod', file 'JDE_PRODUCTION_log' on
> file 1.
> Server: Msg 3456, Level 21, State 1, Line 1
> Could not redo log record (500478:68225:4), for transaction ID
> (3:1085081790), on page (3:2789016), database 'JDE_Prod' (5). Page: LSN =
> (500478:57038:10), type = 2. Log: OpCode = 2, context 3, PrevPageLSN:
> (500478:68221:4).
> Connection Broken
> This 12:15 file has already been re-copied, but I will try again.
> Would be interesting to see if you find any issues with different builds in
> log shipping. The patches were applied to the local server a few months ago
> (3 or 4 months), and log shipping has been running without incident this
> whole time.
> Thanks again,
> Dave
>
> "Amer M J" wrote:
|||Hi again,
Yes, the standby file (whatever it has been called) is automatically deleted
by the restore process.
Good news though, I seem to have log shipping going again! :-)
I re-copied the 12:15am log file (yet again, 3rd time) and restored it with
the same syntax as in my previous post, and it worked. So the problem must
lie with our link to the remote DR server. Its now been logged to the
telecom company who provide the WAN pipe.
As a precautionary measure I will schedule the remote server to be patched
to the same build level as our local server (will be next year though as we
are in a "holiday change freeze" now).
Funnily enough, the restore headeronly, verifyonly and filelistonly all
seemed to work fine with the corrupt file. Is it possible that the header of
the file was okay, while the actual data was bad?
Thanks very much for the help though, and I will update with anything new we
find.
Dave
"Amer M J" wrote:
> Hi Dave
> I am curious here. Was the '.tuf' file deleted as per a part of the process
> of manually ?
> Also the builds do play a major role here. From what I can see as per your
> information, the primary server is of a higher build than the secondary
> server. So I was wondering how a log file of a db from a higher build was
> getting restored onto a lower build server.
> Also I would suggest checking out the integrity of the trn files on the
> primary server. try
> restore verifyonly command to check the backup set's integrity.
> Please do check if anyother process is accessing the db on the secondary
> server as this may disrupt the LS process.
> Also check this link.
> http://support.microsoft.com/kb/329487/en-us
> Thanks
> Amer M J
> MCP
sql
Log Shipping Restore Error 3456
Hi,
I've got a production server log shipping a 280GB database to a remote DR
site server. It has been running without incident for months now, but last
week it stopped restoring logs (the copy process was still running) with an
error 3456:
[Microsoft SQL-DMO (ODBC SQLState: HY000)] Error 3456: [Microsoft]&#
91;ODBC SQL
Server Driver][SQL Server]Could not redo log record (500478:68225:4), fo
r
transaction ID (3:1085081790), on page (3:2789016), database 'JDE_Prod' (5).
Page: LSN = (500478:57038:10), type = 2. Log: OpCode = 2, context 3,
PrevPageLSN: (500478:68221:4).
I restored the remote database from a full tape backup shipped to the site
via courier (because we weren't sure if the link was to blame for the proble
m
restoring). Log shipping worked well again for a few days, but this morning
has again stopped restoring with the exact same error!
I've read the article "http://support.microsoft.com/kb/831950", and although
it describes the same error, it doesnt seem to apply to us as we weren't
doing any role changing, and weren't backing up the database manually with
the NORECOVERY switch (i.e. the backups were being done as usual by the log
shipping maint. plan).
Local server build is 8.00.997, and remote (DR) server build is 8.00.818.
Could the fact that they are slightly different versions have anything to do
with this problem?
Could this be corruption introducted by the network link? If so, is the
only way to fix this to fully restore the database again? Or is there some
way to get good copies of the log it failed on and restore those manually?
I
don't have a huge amount of experience with log shipping, so any help would
be greatly appreciated - especially being a 24/7 mission critical DR server,
and in the middle of the holidays! Murphy's Law!
Thanks,
davidHi David
The SQL Builds may cause a problem. I am not sure about it.
Rearding the file restore; it isn't necessary that you restore the entire
db. I would suggest the following steps:
1) Check the table msdb..log_shipping_plan_history for the last loaded file.
try
select * from msdb..log_shipping_plan_history order by endtime desc
2) Try restoring tha tfile manually from the Query Analyzer. try
restore log
<db_name>
from
disk = 'file_path'
with
standby = 'undo.txt'
3) if the above step succeeds keep restoring the successive trn files till
the step fails. Then that file at which the step fails is the corrupt file.
4) Copy only that file from the primary server and try step 2 with it.
5) re-run the LS Jobs and the ywill succeed.
Hope this helps.
I shall get back with mpre information about the affect of SQL builds on LS.
Thanks
Amer M J
MCP
"DavidCur" wrote:
> Hi,
> I've got a production server log shipping a 280GB database to a remote DR
> site server. It has been running without incident for months now, but las
t
> week it stopped restoring logs (the copy process was still running) with a
n
> error 3456:
> [Microsoft SQL-DMO (ODBC SQLState: HY000)] Error 3456: [Microsoft]
[ODBC SQL
> Server Driver][SQL Server]Could not redo log record (500478:68225:4),
for
> transaction ID (3:1085081790), on page (3:2789016), database 'JDE_Prod' (5
).
> Page: LSN = (500478:57038:10), type = 2. Log: OpCode = 2, context 3,
> PrevPageLSN: (500478:68221:4).
> I restored the remote database from a full tape backup shipped to the site
> via courier (because we weren't sure if the link was to blame for the prob
lem
> restoring). Log shipping worked well again for a few days, but this morni
ng
> has again stopped restoring with the exact same error!
> I've read the article "http://support.microsoft.com/kb/831950", and althou
gh
> it describes the same error, it doesnt seem to apply to us as we weren't
> doing any role changing, and weren't backing up the database manually with
> the NORECOVERY switch (i.e. the backups were being done as usual by the lo
g
> shipping maint. plan).
> Local server build is 8.00.997, and remote (DR) server build is 8.00.818.
> Could the fact that they are slightly different versions have anything to
do
> with this problem?
> Could this be corruption introducted by the network link? If so, is the
> only way to fix this to fully restore the database again? Or is there some
> way to get good copies of the log it failed on and restore those manually?
I
> don't have a huge amount of experience with log shipping, so any help woul
d
> be greatly appreciated - especially being a 24/7 mission critical DR serve
r,
> and in the middle of the holidays! Murphy's Law!
>
> Thanks,
> david|||Thanks for the quick response. The log files are copied and restored every
15 minutes. The problem occurred this morning around 12:15am. I've tried
your suggestion about restoring manually with the standby undo file.
I ran the following command (using the 12:00am file) successfully, but the
12:15am file produces the following output:
---
restore log JDE_Prod
from disk = 'K:\Backups\DRLogsIn\JDE_Prod_tlog_20051
2300015.TRN'
with standby = 'K:\Backups\DRLogsIn\LogUndo.tuf'
---
Deleting database file 'K:\Backups\DRLogsIn\LogUndo.tuf'.
Processed 34415 pages for database 'JDE_Prod', file 'JDE_PRODUCTION_log' on
file 1.
Server: Msg 3456, Level 21, State 1, Line 1
Could not redo log record (500478:68225:4), for transaction ID
(3:1085081790), on page (3:2789016), database 'JDE_Prod' (5). Page: LSN =
(500478:57038:10), type = 2. Log: OpCode = 2, context 3, PrevPageLSN:
(500478:68221:4).
Connection Broken
---
This 12:15 file has already been re-copied, but I will try again.
Would be interesting to see if you find any issues with different builds in
log shipping. The patches were applied to the local server a few months ago
(3 or 4 months), and log shipping has been running without incident this
whole time.
Thanks again,
Dave
"Amer M J" wrote:
> Hi David
> The SQL Builds may cause a problem. I am not sure about it.
> Rearding the file restore; it isn't necessary that you restore the entire
> db. I would suggest the following steps:
> 1) Check the table msdb..log_shipping_plan_history for the last loaded fil
e.
> try
> select * from msdb..log_shipping_plan_history order by endtime desc
> 2) Try restoring tha tfile manually from the Query Analyzer. try
> restore log
> <db_name>
> from
> disk = 'file_path'
> with
> standby = 'undo.txt'
> 3) if the above step succeeds keep restoring the successive trn files till
> the step fails. Then that file at which the step fails is the corrupt file
.
> 4) Copy only that file from the primary server and try step 2 with it.
> 5) re-run the LS Jobs and the ywill succeed.
> Hope this helps.
> I shall get back with mpre information about the affect of SQL builds on L
S.
> Thanks
> Amer M J
> MCP|||Hi Dave
I am curious here. Was the '.tuf' file deleted as per a part of the process
of manually ?
Also the builds do play a major role here. From what I can see as per your
information, the primary server is of a higher build than the secondary
server. So I was wondering how a log file of a db from a higher build was
getting restored onto a lower build server.
Also I would suggest checking out the integrity of the trn files on the
primary server. try
restore verifyonly command to check the backup set's integrity.
Please do check if anyother process is accessing the db on the secondary
server as this may disrupt the LS process.
Also check this link.
http://support.microsoft.com/kb/329487/en-us
Thanks
Amer M J
MCP
"DavidCur" wrote:
[vbcol=seagreen]
> Thanks for the quick response. The log files are copied and restored ever
y
> 15 minutes. The problem occurred this morning around 12:15am. I've tried
> your suggestion about restoring manually with the standby undo file.
> I ran the following command (using the 12:00am file) successfully, but the
> 12:15am file produces the following output:
> ---
> restore log JDE_Prod
> from disk = 'K:\Backups\DRLogsIn\JDE_Prod_tlog_20051
2300015.TRN'
> with standby = 'K:\Backups\DRLogsIn\LogUndo.tuf'
> ---
> Deleting database file 'K:\Backups\DRLogsIn\LogUndo.tuf'.
> Processed 34415 pages for database 'JDE_Prod', file 'JDE_PRODUCTION_log' o
n
> file 1.
> Server: Msg 3456, Level 21, State 1, Line 1
> Could not redo log record (500478:68225:4), for transaction ID
> (3:1085081790), on page (3:2789016), database 'JDE_Prod' (5). Page: LSN =
> (500478:57038:10), type = 2. Log: OpCode = 2, context 3, PrevPageLSN:
> (500478:68221:4).
> Connection Broken
> ---
> This 12:15 file has already been re-copied, but I will try again.
> Would be interesting to see if you find any issues with different builds i
n
> log shipping. The patches were applied to the local server a few months a
go
> (3 or 4 months), and log shipping has been running without incident this
> whole time.
> Thanks again,
> Dave
>
> "Amer M J" wrote:
>|||Hi again,
Yes, the standby file (whatever it has been called) is automatically deleted
by the restore process.
Good news though, I seem to have log shipping going again! :-)
I re-copied the 12:15am log file (yet again, 3rd time) and restored it with
the same syntax as in my previous post, and it worked. So the problem must
lie with our link to the remote DR server. Its now been logged to the
telecom company who provide the WAN pipe.
As a precautionary measure I will schedule the remote server to be patched
to the same build level as our local server (will be next year though as we
are in a "holiday change freeze" now).
Funnily enough, the restore headeronly, verifyonly and filelistonly all
seemed to work fine with the corrupt file. Is it possible that the header o
f
the file was okay, while the actual data was bad'
Thanks very much for the help though, and I will update with anything new we
find.
Dave
"Amer M J" wrote:
> Hi Dave
> I am curious here. Was the '.tuf' file deleted as per a part of the proces
s
> of manually ?
> Also the builds do play a major role here. From what I can see as per your
> information, the primary server is of a higher build than the secondary
> server. So I was wondering how a log file of a db from a higher build was
> getting restored onto a lower build server.
> Also I would suggest checking out the integrity of the trn files on the
> primary server. try
> restore verifyonly command to check the backup set's integrity.
> Please do check if anyother process is accessing the db on the secondary
> server as this may disrupt the LS process.
> Also check this link.
> http://support.microsoft.com/kb/329487/en-us
> Thanks
> Amer M J
> MCP
I've got a production server log shipping a 280GB database to a remote DR
site server. It has been running without incident for months now, but last
week it stopped restoring logs (the copy process was still running) with an
error 3456:
[Microsoft SQL-DMO (ODBC SQLState: HY000)] Error 3456: [Microsoft]&#
91;ODBC SQL
Server Driver][SQL Server]Could not redo log record (500478:68225:4), fo
r
transaction ID (3:1085081790), on page (3:2789016), database 'JDE_Prod' (5).
Page: LSN = (500478:57038:10), type = 2. Log: OpCode = 2, context 3,
PrevPageLSN: (500478:68221:4).
I restored the remote database from a full tape backup shipped to the site
via courier (because we weren't sure if the link was to blame for the proble
m
restoring). Log shipping worked well again for a few days, but this morning
has again stopped restoring with the exact same error!
I've read the article "http://support.microsoft.com/kb/831950", and although
it describes the same error, it doesnt seem to apply to us as we weren't
doing any role changing, and weren't backing up the database manually with
the NORECOVERY switch (i.e. the backups were being done as usual by the log
shipping maint. plan).
Local server build is 8.00.997, and remote (DR) server build is 8.00.818.
Could the fact that they are slightly different versions have anything to do
with this problem?
Could this be corruption introducted by the network link? If so, is the
only way to fix this to fully restore the database again? Or is there some
way to get good copies of the log it failed on and restore those manually?
I
don't have a huge amount of experience with log shipping, so any help would
be greatly appreciated - especially being a 24/7 mission critical DR server,
and in the middle of the holidays! Murphy's Law!
Thanks,
davidHi David
The SQL Builds may cause a problem. I am not sure about it.
Rearding the file restore; it isn't necessary that you restore the entire
db. I would suggest the following steps:
1) Check the table msdb..log_shipping_plan_history for the last loaded file.
try
select * from msdb..log_shipping_plan_history order by endtime desc
2) Try restoring tha tfile manually from the Query Analyzer. try
restore log
<db_name>
from
disk = 'file_path'
with
standby = 'undo.txt'
3) if the above step succeeds keep restoring the successive trn files till
the step fails. Then that file at which the step fails is the corrupt file.
4) Copy only that file from the primary server and try step 2 with it.
5) re-run the LS Jobs and the ywill succeed.
Hope this helps.
I shall get back with mpre information about the affect of SQL builds on LS.
Thanks
Amer M J
MCP
"DavidCur" wrote:
> Hi,
> I've got a production server log shipping a 280GB database to a remote DR
> site server. It has been running without incident for months now, but las
t
> week it stopped restoring logs (the copy process was still running) with a
n
> error 3456:
> [Microsoft SQL-DMO (ODBC SQLState: HY000)] Error 3456: [Microsoft]
[ODBC SQL
> Server Driver][SQL Server]Could not redo log record (500478:68225:4),
for
> transaction ID (3:1085081790), on page (3:2789016), database 'JDE_Prod' (5
).
> Page: LSN = (500478:57038:10), type = 2. Log: OpCode = 2, context 3,
> PrevPageLSN: (500478:68221:4).
> I restored the remote database from a full tape backup shipped to the site
> via courier (because we weren't sure if the link was to blame for the prob
lem
> restoring). Log shipping worked well again for a few days, but this morni
ng
> has again stopped restoring with the exact same error!
> I've read the article "http://support.microsoft.com/kb/831950", and althou
gh
> it describes the same error, it doesnt seem to apply to us as we weren't
> doing any role changing, and weren't backing up the database manually with
> the NORECOVERY switch (i.e. the backups were being done as usual by the lo
g
> shipping maint. plan).
> Local server build is 8.00.997, and remote (DR) server build is 8.00.818.
> Could the fact that they are slightly different versions have anything to
do
> with this problem?
> Could this be corruption introducted by the network link? If so, is the
> only way to fix this to fully restore the database again? Or is there some
> way to get good copies of the log it failed on and restore those manually?
I
> don't have a huge amount of experience with log shipping, so any help woul
d
> be greatly appreciated - especially being a 24/7 mission critical DR serve
r,
> and in the middle of the holidays! Murphy's Law!
>
> Thanks,
> david|||Thanks for the quick response. The log files are copied and restored every
15 minutes. The problem occurred this morning around 12:15am. I've tried
your suggestion about restoring manually with the standby undo file.
I ran the following command (using the 12:00am file) successfully, but the
12:15am file produces the following output:
---
restore log JDE_Prod
from disk = 'K:\Backups\DRLogsIn\JDE_Prod_tlog_20051
2300015.TRN'
with standby = 'K:\Backups\DRLogsIn\LogUndo.tuf'
---
Deleting database file 'K:\Backups\DRLogsIn\LogUndo.tuf'.
Processed 34415 pages for database 'JDE_Prod', file 'JDE_PRODUCTION_log' on
file 1.
Server: Msg 3456, Level 21, State 1, Line 1
Could not redo log record (500478:68225:4), for transaction ID
(3:1085081790), on page (3:2789016), database 'JDE_Prod' (5). Page: LSN =
(500478:57038:10), type = 2. Log: OpCode = 2, context 3, PrevPageLSN:
(500478:68221:4).
Connection Broken
---
This 12:15 file has already been re-copied, but I will try again.
Would be interesting to see if you find any issues with different builds in
log shipping. The patches were applied to the local server a few months ago
(3 or 4 months), and log shipping has been running without incident this
whole time.
Thanks again,
Dave
"Amer M J" wrote:
> Hi David
> The SQL Builds may cause a problem. I am not sure about it.
> Rearding the file restore; it isn't necessary that you restore the entire
> db. I would suggest the following steps:
> 1) Check the table msdb..log_shipping_plan_history for the last loaded fil
e.
> try
> select * from msdb..log_shipping_plan_history order by endtime desc
> 2) Try restoring tha tfile manually from the Query Analyzer. try
> restore log
> <db_name>
> from
> disk = 'file_path'
> with
> standby = 'undo.txt'
> 3) if the above step succeeds keep restoring the successive trn files till
> the step fails. Then that file at which the step fails is the corrupt file
.
> 4) Copy only that file from the primary server and try step 2 with it.
> 5) re-run the LS Jobs and the ywill succeed.
> Hope this helps.
> I shall get back with mpre information about the affect of SQL builds on L
S.
> Thanks
> Amer M J
> MCP|||Hi Dave
I am curious here. Was the '.tuf' file deleted as per a part of the process
of manually ?
Also the builds do play a major role here. From what I can see as per your
information, the primary server is of a higher build than the secondary
server. So I was wondering how a log file of a db from a higher build was
getting restored onto a lower build server.
Also I would suggest checking out the integrity of the trn files on the
primary server. try
restore verifyonly command to check the backup set's integrity.
Please do check if anyother process is accessing the db on the secondary
server as this may disrupt the LS process.
Also check this link.
http://support.microsoft.com/kb/329487/en-us
Thanks
Amer M J
MCP
"DavidCur" wrote:
[vbcol=seagreen]
> Thanks for the quick response. The log files are copied and restored ever
y
> 15 minutes. The problem occurred this morning around 12:15am. I've tried
> your suggestion about restoring manually with the standby undo file.
> I ran the following command (using the 12:00am file) successfully, but the
> 12:15am file produces the following output:
> ---
> restore log JDE_Prod
> from disk = 'K:\Backups\DRLogsIn\JDE_Prod_tlog_20051
2300015.TRN'
> with standby = 'K:\Backups\DRLogsIn\LogUndo.tuf'
> ---
> Deleting database file 'K:\Backups\DRLogsIn\LogUndo.tuf'.
> Processed 34415 pages for database 'JDE_Prod', file 'JDE_PRODUCTION_log' o
n
> file 1.
> Server: Msg 3456, Level 21, State 1, Line 1
> Could not redo log record (500478:68225:4), for transaction ID
> (3:1085081790), on page (3:2789016), database 'JDE_Prod' (5). Page: LSN =
> (500478:57038:10), type = 2. Log: OpCode = 2, context 3, PrevPageLSN:
> (500478:68221:4).
> Connection Broken
> ---
> This 12:15 file has already been re-copied, but I will try again.
> Would be interesting to see if you find any issues with different builds i
n
> log shipping. The patches were applied to the local server a few months a
go
> (3 or 4 months), and log shipping has been running without incident this
> whole time.
> Thanks again,
> Dave
>
> "Amer M J" wrote:
>|||Hi again,
Yes, the standby file (whatever it has been called) is automatically deleted
by the restore process.
Good news though, I seem to have log shipping going again! :-)
I re-copied the 12:15am log file (yet again, 3rd time) and restored it with
the same syntax as in my previous post, and it worked. So the problem must
lie with our link to the remote DR server. Its now been logged to the
telecom company who provide the WAN pipe.
As a precautionary measure I will schedule the remote server to be patched
to the same build level as our local server (will be next year though as we
are in a "holiday change freeze" now).
Funnily enough, the restore headeronly, verifyonly and filelistonly all
seemed to work fine with the corrupt file. Is it possible that the header o
f
the file was okay, while the actual data was bad'
Thanks very much for the help though, and I will update with anything new we
find.
Dave
"Amer M J" wrote:
> Hi Dave
> I am curious here. Was the '.tuf' file deleted as per a part of the proces
s
> of manually ?
> Also the builds do play a major role here. From what I can see as per your
> information, the primary server is of a higher build than the secondary
> server. So I was wondering how a log file of a db from a higher build was
> getting restored onto a lower build server.
> Also I would suggest checking out the integrity of the trn files on the
> primary server. try
> restore verifyonly command to check the backup set's integrity.
> Please do check if anyother process is accessing the db on the secondary
> server as this may disrupt the LS process.
> Also check this link.
> http://support.microsoft.com/kb/329487/en-us
> Thanks
> Amer M J
> MCP
Log Shipping Restore Error 3456
Hi,
I've got a production server log shipping a 280GB database to a remote DR
site server. It has been running without incident for months now, but last
week it stopped restoring logs (the copy process was still running) with an
error 3456:
[Microsoft SQL-DMO (ODBC SQLState: HY000)] Error 3456: [Microsoft][ODBC SQL
Server Driver][SQL Server]Could not redo log record (500478:68225:4), for
transaction ID (3:1085081790), on page (3:2789016), database 'JDE_Prod' (5).
Page: LSN = (500478:57038:10), type = 2. Log: OpCode = 2, context 3,
PrevPageLSN: (500478:68221:4).
I restored the remote database from a full tape backup shipped to the site
via courier (because we weren't sure if the link was to blame for the problem
restoring). Log shipping worked well again for a few days, but this morning
has again stopped restoring with the exact same error!
I've read the article "http://support.microsoft.com/kb/831950", and although
it describes the same error, it doesnt seem to apply to us as we weren't
doing any role changing, and weren't backing up the database manually with
the NORECOVERY switch (i.e. the backups were being done as usual by the log
shipping maint. plan).
Local server build is 8.00.997, and remote (DR) server build is 8.00.818.
Could the fact that they are slightly different versions have anything to do
with this problem?
Could this be corruption introducted by the network link? If so, is the
only way to fix this to fully restore the database again? Or is there some
way to get good copies of the log it failed on and restore those manually? I
don't have a huge amount of experience with log shipping, so any help would
be greatly appreciated - especially being a 24/7 mission critical DR server,
and in the middle of the holidays! Murphy's Law!
Thanks,
davidHi David
The SQL Builds may cause a problem. I am not sure about it.
Rearding the file restore; it isn't necessary that you restore the entire
db. I would suggest the following steps:
1) Check the table msdb..log_shipping_plan_history for the last loaded file.
try
select * from msdb..log_shipping_plan_history order by endtime desc
2) Try restoring tha tfile manually from the Query Analyzer. try
restore log
<db_name>
from
disk = 'file_path'
with
standby = 'undo.txt'
3) if the above step succeeds keep restoring the successive trn files till
the step fails. Then that file at which the step fails is the corrupt file.
4) Copy only that file from the primary server and try step 2 with it.
5) re-run the LS Jobs and the ywill succeed.
Hope this helps.
I shall get back with mpre information about the affect of SQL builds on LS.
Thanks
Amer M J
MCP
"DavidCur" wrote:
> Hi,
> I've got a production server log shipping a 280GB database to a remote DR
> site server. It has been running without incident for months now, but last
> week it stopped restoring logs (the copy process was still running) with an
> error 3456:
> [Microsoft SQL-DMO (ODBC SQLState: HY000)] Error 3456: [Microsoft][ODBC SQL
> Server Driver][SQL Server]Could not redo log record (500478:68225:4), for
> transaction ID (3:1085081790), on page (3:2789016), database 'JDE_Prod' (5).
> Page: LSN = (500478:57038:10), type = 2. Log: OpCode = 2, context 3,
> PrevPageLSN: (500478:68221:4).
> I restored the remote database from a full tape backup shipped to the site
> via courier (because we weren't sure if the link was to blame for the problem
> restoring). Log shipping worked well again for a few days, but this morning
> has again stopped restoring with the exact same error!
> I've read the article "http://support.microsoft.com/kb/831950", and although
> it describes the same error, it doesnt seem to apply to us as we weren't
> doing any role changing, and weren't backing up the database manually with
> the NORECOVERY switch (i.e. the backups were being done as usual by the log
> shipping maint. plan).
> Local server build is 8.00.997, and remote (DR) server build is 8.00.818.
> Could the fact that they are slightly different versions have anything to do
> with this problem?
> Could this be corruption introducted by the network link? If so, is the
> only way to fix this to fully restore the database again? Or is there some
> way to get good copies of the log it failed on and restore those manually? I
> don't have a huge amount of experience with log shipping, so any help would
> be greatly appreciated - especially being a 24/7 mission critical DR server,
> and in the middle of the holidays! Murphy's Law!
>
> Thanks,
> david|||Thanks for the quick response. The log files are copied and restored every
15 minutes. The problem occurred this morning around 12:15am. I've tried
your suggestion about restoring manually with the standby undo file.
I ran the following command (using the 12:00am file) successfully, but the
12:15am file produces the following output:
---
restore log JDE_Prod
from disk = 'K:\Backups\DRLogsIn\JDE_Prod_tlog_200512300015.TRN'
with standby = 'K:\Backups\DRLogsIn\LogUndo.tuf'
---
Deleting database file 'K:\Backups\DRLogsIn\LogUndo.tuf'.
Processed 34415 pages for database 'JDE_Prod', file 'JDE_PRODUCTION_log' on
file 1.
Server: Msg 3456, Level 21, State 1, Line 1
Could not redo log record (500478:68225:4), for transaction ID
(3:1085081790), on page (3:2789016), database 'JDE_Prod' (5). Page: LSN =(500478:57038:10), type = 2. Log: OpCode = 2, context 3, PrevPageLSN:
(500478:68221:4).
Connection Broken
---
This 12:15 file has already been re-copied, but I will try again.
Would be interesting to see if you find any issues with different builds in
log shipping. The patches were applied to the local server a few months ago
(3 or 4 months), and log shipping has been running without incident this
whole time.
Thanks again,
Dave
"Amer M J" wrote:
> Hi David
> The SQL Builds may cause a problem. I am not sure about it.
> Rearding the file restore; it isn't necessary that you restore the entire
> db. I would suggest the following steps:
> 1) Check the table msdb..log_shipping_plan_history for the last loaded file.
> try
> select * from msdb..log_shipping_plan_history order by endtime desc
> 2) Try restoring tha tfile manually from the Query Analyzer. try
> restore log
> <db_name>
> from
> disk = 'file_path'
> with
> standby = 'undo.txt'
> 3) if the above step succeeds keep restoring the successive trn files till
> the step fails. Then that file at which the step fails is the corrupt file.
> 4) Copy only that file from the primary server and try step 2 with it.
> 5) re-run the LS Jobs and the ywill succeed.
> Hope this helps.
> I shall get back with mpre information about the affect of SQL builds on LS.
> Thanks
> Amer M J
> MCP|||Hi Dave
I am curious here. Was the '.tuf' file deleted as per a part of the process
of manually ?
Also the builds do play a major role here. From what I can see as per your
information, the primary server is of a higher build than the secondary
server. So I was wondering how a log file of a db from a higher build was
getting restored onto a lower build server.
Also I would suggest checking out the integrity of the trn files on the
primary server. try
restore verifyonly command to check the backup set's integrity.
Please do check if anyother process is accessing the db on the secondary
server as this may disrupt the LS process.
Also check this link.
http://support.microsoft.com/kb/329487/en-us
Thanks
Amer M J
MCP
"DavidCur" wrote:
> Thanks for the quick response. The log files are copied and restored every
> 15 minutes. The problem occurred this morning around 12:15am. I've tried
> your suggestion about restoring manually with the standby undo file.
> I ran the following command (using the 12:00am file) successfully, but the
> 12:15am file produces the following output:
> ---
> restore log JDE_Prod
> from disk = 'K:\Backups\DRLogsIn\JDE_Prod_tlog_200512300015.TRN'
> with standby = 'K:\Backups\DRLogsIn\LogUndo.tuf'
> ---
> Deleting database file 'K:\Backups\DRLogsIn\LogUndo.tuf'.
> Processed 34415 pages for database 'JDE_Prod', file 'JDE_PRODUCTION_log' on
> file 1.
> Server: Msg 3456, Level 21, State 1, Line 1
> Could not redo log record (500478:68225:4), for transaction ID
> (3:1085081790), on page (3:2789016), database 'JDE_Prod' (5). Page: LSN => (500478:57038:10), type = 2. Log: OpCode = 2, context 3, PrevPageLSN:
> (500478:68221:4).
> Connection Broken
> ---
> This 12:15 file has already been re-copied, but I will try again.
> Would be interesting to see if you find any issues with different builds in
> log shipping. The patches were applied to the local server a few months ago
> (3 or 4 months), and log shipping has been running without incident this
> whole time.
> Thanks again,
> Dave
>
> "Amer M J" wrote:
> > Hi David
> >
> > The SQL Builds may cause a problem. I am not sure about it.
> >
> > Rearding the file restore; it isn't necessary that you restore the entire
> > db. I would suggest the following steps:
> >
> > 1) Check the table msdb..log_shipping_plan_history for the last loaded file.
> > try
> >
> > select * from msdb..log_shipping_plan_history order by endtime desc
> >
> > 2) Try restoring tha tfile manually from the Query Analyzer. try
> >
> > restore log
> > <db_name>
> > from
> > disk = 'file_path'
> > with
> > standby = 'undo.txt'
> >
> > 3) if the above step succeeds keep restoring the successive trn files till
> > the step fails. Then that file at which the step fails is the corrupt file.
> >
> > 4) Copy only that file from the primary server and try step 2 with it.
> >
> > 5) re-run the LS Jobs and the ywill succeed.
> >
> > Hope this helps.
> >
> > I shall get back with mpre information about the affect of SQL builds on LS.
> >
> > Thanks
> > Amer M J
> > MCP|||Hi again,
Yes, the standby file (whatever it has been called) is automatically deleted
by the restore process.
Good news though, I seem to have log shipping going again! :-)
I re-copied the 12:15am log file (yet again, 3rd time) and restored it with
the same syntax as in my previous post, and it worked. So the problem must
lie with our link to the remote DR server. Its now been logged to the
telecom company who provide the WAN pipe.
As a precautionary measure I will schedule the remote server to be patched
to the same build level as our local server (will be next year though as we
are in a "holiday change freeze" now).
Funnily enough, the restore headeronly, verifyonly and filelistonly all
seemed to work fine with the corrupt file. Is it possible that the header of
the file was okay, while the actual data was bad'
Thanks very much for the help though, and I will update with anything new we
find.
Dave
"Amer M J" wrote:
> Hi Dave
> I am curious here. Was the '.tuf' file deleted as per a part of the process
> of manually ?
> Also the builds do play a major role here. From what I can see as per your
> information, the primary server is of a higher build than the secondary
> server. So I was wondering how a log file of a db from a higher build was
> getting restored onto a lower build server.
> Also I would suggest checking out the integrity of the trn files on the
> primary server. try
> restore verifyonly command to check the backup set's integrity.
> Please do check if anyother process is accessing the db on the secondary
> server as this may disrupt the LS process.
> Also check this link.
> http://support.microsoft.com/kb/329487/en-us
> Thanks
> Amer M J
> MCP
I've got a production server log shipping a 280GB database to a remote DR
site server. It has been running without incident for months now, but last
week it stopped restoring logs (the copy process was still running) with an
error 3456:
[Microsoft SQL-DMO (ODBC SQLState: HY000)] Error 3456: [Microsoft][ODBC SQL
Server Driver][SQL Server]Could not redo log record (500478:68225:4), for
transaction ID (3:1085081790), on page (3:2789016), database 'JDE_Prod' (5).
Page: LSN = (500478:57038:10), type = 2. Log: OpCode = 2, context 3,
PrevPageLSN: (500478:68221:4).
I restored the remote database from a full tape backup shipped to the site
via courier (because we weren't sure if the link was to blame for the problem
restoring). Log shipping worked well again for a few days, but this morning
has again stopped restoring with the exact same error!
I've read the article "http://support.microsoft.com/kb/831950", and although
it describes the same error, it doesnt seem to apply to us as we weren't
doing any role changing, and weren't backing up the database manually with
the NORECOVERY switch (i.e. the backups were being done as usual by the log
shipping maint. plan).
Local server build is 8.00.997, and remote (DR) server build is 8.00.818.
Could the fact that they are slightly different versions have anything to do
with this problem?
Could this be corruption introducted by the network link? If so, is the
only way to fix this to fully restore the database again? Or is there some
way to get good copies of the log it failed on and restore those manually? I
don't have a huge amount of experience with log shipping, so any help would
be greatly appreciated - especially being a 24/7 mission critical DR server,
and in the middle of the holidays! Murphy's Law!
Thanks,
davidHi David
The SQL Builds may cause a problem. I am not sure about it.
Rearding the file restore; it isn't necessary that you restore the entire
db. I would suggest the following steps:
1) Check the table msdb..log_shipping_plan_history for the last loaded file.
try
select * from msdb..log_shipping_plan_history order by endtime desc
2) Try restoring tha tfile manually from the Query Analyzer. try
restore log
<db_name>
from
disk = 'file_path'
with
standby = 'undo.txt'
3) if the above step succeeds keep restoring the successive trn files till
the step fails. Then that file at which the step fails is the corrupt file.
4) Copy only that file from the primary server and try step 2 with it.
5) re-run the LS Jobs and the ywill succeed.
Hope this helps.
I shall get back with mpre information about the affect of SQL builds on LS.
Thanks
Amer M J
MCP
"DavidCur" wrote:
> Hi,
> I've got a production server log shipping a 280GB database to a remote DR
> site server. It has been running without incident for months now, but last
> week it stopped restoring logs (the copy process was still running) with an
> error 3456:
> [Microsoft SQL-DMO (ODBC SQLState: HY000)] Error 3456: [Microsoft][ODBC SQL
> Server Driver][SQL Server]Could not redo log record (500478:68225:4), for
> transaction ID (3:1085081790), on page (3:2789016), database 'JDE_Prod' (5).
> Page: LSN = (500478:57038:10), type = 2. Log: OpCode = 2, context 3,
> PrevPageLSN: (500478:68221:4).
> I restored the remote database from a full tape backup shipped to the site
> via courier (because we weren't sure if the link was to blame for the problem
> restoring). Log shipping worked well again for a few days, but this morning
> has again stopped restoring with the exact same error!
> I've read the article "http://support.microsoft.com/kb/831950", and although
> it describes the same error, it doesnt seem to apply to us as we weren't
> doing any role changing, and weren't backing up the database manually with
> the NORECOVERY switch (i.e. the backups were being done as usual by the log
> shipping maint. plan).
> Local server build is 8.00.997, and remote (DR) server build is 8.00.818.
> Could the fact that they are slightly different versions have anything to do
> with this problem?
> Could this be corruption introducted by the network link? If so, is the
> only way to fix this to fully restore the database again? Or is there some
> way to get good copies of the log it failed on and restore those manually? I
> don't have a huge amount of experience with log shipping, so any help would
> be greatly appreciated - especially being a 24/7 mission critical DR server,
> and in the middle of the holidays! Murphy's Law!
>
> Thanks,
> david|||Thanks for the quick response. The log files are copied and restored every
15 minutes. The problem occurred this morning around 12:15am. I've tried
your suggestion about restoring manually with the standby undo file.
I ran the following command (using the 12:00am file) successfully, but the
12:15am file produces the following output:
---
restore log JDE_Prod
from disk = 'K:\Backups\DRLogsIn\JDE_Prod_tlog_200512300015.TRN'
with standby = 'K:\Backups\DRLogsIn\LogUndo.tuf'
---
Deleting database file 'K:\Backups\DRLogsIn\LogUndo.tuf'.
Processed 34415 pages for database 'JDE_Prod', file 'JDE_PRODUCTION_log' on
file 1.
Server: Msg 3456, Level 21, State 1, Line 1
Could not redo log record (500478:68225:4), for transaction ID
(3:1085081790), on page (3:2789016), database 'JDE_Prod' (5). Page: LSN =(500478:57038:10), type = 2. Log: OpCode = 2, context 3, PrevPageLSN:
(500478:68221:4).
Connection Broken
---
This 12:15 file has already been re-copied, but I will try again.
Would be interesting to see if you find any issues with different builds in
log shipping. The patches were applied to the local server a few months ago
(3 or 4 months), and log shipping has been running without incident this
whole time.
Thanks again,
Dave
"Amer M J" wrote:
> Hi David
> The SQL Builds may cause a problem. I am not sure about it.
> Rearding the file restore; it isn't necessary that you restore the entire
> db. I would suggest the following steps:
> 1) Check the table msdb..log_shipping_plan_history for the last loaded file.
> try
> select * from msdb..log_shipping_plan_history order by endtime desc
> 2) Try restoring tha tfile manually from the Query Analyzer. try
> restore log
> <db_name>
> from
> disk = 'file_path'
> with
> standby = 'undo.txt'
> 3) if the above step succeeds keep restoring the successive trn files till
> the step fails. Then that file at which the step fails is the corrupt file.
> 4) Copy only that file from the primary server and try step 2 with it.
> 5) re-run the LS Jobs and the ywill succeed.
> Hope this helps.
> I shall get back with mpre information about the affect of SQL builds on LS.
> Thanks
> Amer M J
> MCP|||Hi Dave
I am curious here. Was the '.tuf' file deleted as per a part of the process
of manually ?
Also the builds do play a major role here. From what I can see as per your
information, the primary server is of a higher build than the secondary
server. So I was wondering how a log file of a db from a higher build was
getting restored onto a lower build server.
Also I would suggest checking out the integrity of the trn files on the
primary server. try
restore verifyonly command to check the backup set's integrity.
Please do check if anyother process is accessing the db on the secondary
server as this may disrupt the LS process.
Also check this link.
http://support.microsoft.com/kb/329487/en-us
Thanks
Amer M J
MCP
"DavidCur" wrote:
> Thanks for the quick response. The log files are copied and restored every
> 15 minutes. The problem occurred this morning around 12:15am. I've tried
> your suggestion about restoring manually with the standby undo file.
> I ran the following command (using the 12:00am file) successfully, but the
> 12:15am file produces the following output:
> ---
> restore log JDE_Prod
> from disk = 'K:\Backups\DRLogsIn\JDE_Prod_tlog_200512300015.TRN'
> with standby = 'K:\Backups\DRLogsIn\LogUndo.tuf'
> ---
> Deleting database file 'K:\Backups\DRLogsIn\LogUndo.tuf'.
> Processed 34415 pages for database 'JDE_Prod', file 'JDE_PRODUCTION_log' on
> file 1.
> Server: Msg 3456, Level 21, State 1, Line 1
> Could not redo log record (500478:68225:4), for transaction ID
> (3:1085081790), on page (3:2789016), database 'JDE_Prod' (5). Page: LSN => (500478:57038:10), type = 2. Log: OpCode = 2, context 3, PrevPageLSN:
> (500478:68221:4).
> Connection Broken
> ---
> This 12:15 file has already been re-copied, but I will try again.
> Would be interesting to see if you find any issues with different builds in
> log shipping. The patches were applied to the local server a few months ago
> (3 or 4 months), and log shipping has been running without incident this
> whole time.
> Thanks again,
> Dave
>
> "Amer M J" wrote:
> > Hi David
> >
> > The SQL Builds may cause a problem. I am not sure about it.
> >
> > Rearding the file restore; it isn't necessary that you restore the entire
> > db. I would suggest the following steps:
> >
> > 1) Check the table msdb..log_shipping_plan_history for the last loaded file.
> > try
> >
> > select * from msdb..log_shipping_plan_history order by endtime desc
> >
> > 2) Try restoring tha tfile manually from the Query Analyzer. try
> >
> > restore log
> > <db_name>
> > from
> > disk = 'file_path'
> > with
> > standby = 'undo.txt'
> >
> > 3) if the above step succeeds keep restoring the successive trn files till
> > the step fails. Then that file at which the step fails is the corrupt file.
> >
> > 4) Copy only that file from the primary server and try step 2 with it.
> >
> > 5) re-run the LS Jobs and the ywill succeed.
> >
> > Hope this helps.
> >
> > I shall get back with mpre information about the affect of SQL builds on LS.
> >
> > Thanks
> > Amer M J
> > MCP|||Hi again,
Yes, the standby file (whatever it has been called) is automatically deleted
by the restore process.
Good news though, I seem to have log shipping going again! :-)
I re-copied the 12:15am log file (yet again, 3rd time) and restored it with
the same syntax as in my previous post, and it worked. So the problem must
lie with our link to the remote DR server. Its now been logged to the
telecom company who provide the WAN pipe.
As a precautionary measure I will schedule the remote server to be patched
to the same build level as our local server (will be next year though as we
are in a "holiday change freeze" now).
Funnily enough, the restore headeronly, verifyonly and filelistonly all
seemed to work fine with the corrupt file. Is it possible that the header of
the file was okay, while the actual data was bad'
Thanks very much for the help though, and I will update with anything new we
find.
Dave
"Amer M J" wrote:
> Hi Dave
> I am curious here. Was the '.tuf' file deleted as per a part of the process
> of manually ?
> Also the builds do play a major role here. From what I can see as per your
> information, the primary server is of a higher build than the secondary
> server. So I was wondering how a log file of a db from a higher build was
> getting restored onto a lower build server.
> Also I would suggest checking out the integrity of the trn files on the
> primary server. try
> restore verifyonly command to check the backup set's integrity.
> Please do check if anyother process is accessing the db on the secondary
> server as this may disrupt the LS process.
> Also check this link.
> http://support.microsoft.com/kb/329487/en-us
> Thanks
> Amer M J
> MCP
Log shipping recovery trials
We have a Production Server A thats log shipped to Standby Server B. We want
to simulate some disaster recovery runs .
What are some things to consider. It seems obtainable from A to B.. But how
do I revert back to A again.. Do I have to redo log shipping and this time
from B to A which means I need to restore all dbs/logs in norecovery state
onto A from B using the wizard
Are there better ways to simulate this ? I dont wish for it to be a
nightmare especially since if we are going to test this and we would want to
revert back to A as soon as possible during this run...You don't have to set up reverse log-shipping. You simply backup B & restore
it on A & then re-initialise the log shipping process to continue testing..
Regards,
Greg Linwood
SQL Server MVP
"sql" <sql@.hotmail.com> wrote in message
news:uNMLuPA%23DHA.888@.tk2msftngp13.phx.gbl...
> We have a Production Server A thats log shipped to Standby Server B. We
want
> to simulate some disaster recovery runs .
> What are some things to consider. It seems obtainable from A to B.. But
how
> do I revert back to A again.. Do I have to redo log shipping and this time
> from B to A which means I need to restore all dbs/logs in norecovery state
> onto A from B using the wizard
> Are there better ways to simulate this ? I dont wish for it to be a
> nightmare especially since if we are going to test this and we would want
to
> revert back to A as soon as possible during this run...
>
>|||When we fail to Standby Server B initially and simulate to run for 1 or 2
days before we recover Primary Server A, does that mean my downtime to
revert back to server A would be taking server B offline... doing a total
restore of all dbs to server A and then proceed. So my downtime is equal to
the amount of time it takes to restore the dbs as opposed to the initial
failover from A to B as the only process involved there is recovering the
dbs.. and other minor stuff such as logins,msdb related jobs and DTS
packages,sysmessages..assuming we are good to go here
"Greg Linwood" <g_linwoodQhotmail.com> wrote in message
news:O%23wVThA%23DHA.632@.TK2MSFTNGP12.phx.gbl...
> You don't have to set up reverse log-shipping. You simply backup B &
restore
> it on A & then re-initialise the log shipping process to continue
testing..
> Regards,
> Greg Linwood
> SQL Server MVP
> "sql" <sql@.hotmail.com> wrote in message
> news:uNMLuPA%23DHA.888@.tk2msftngp13.phx.gbl...
> want
> how
time
state
want
> to
>|||Hi Hassan.
That's one way of doing it. Another is to do it in multiple steps - eg leave
B online whilst you perform your full backup restore to A (DTS packages &
whatever else), then restore the remaining log tails to A & your window of
downtime is fairly small. If you want to keep that downtime window even
smaller you could iterate the log tail restores.
Regards,
Greg Linwood
SQL Server MVP
"Hassan" <fatima_ja@.hotmail.com> wrote in message
news:%23YHO71D%23DHA.132@.TK2MSFTNGP09.phx.gbl...
> When we fail to Standby Server B initially and simulate to run for 1 or 2
> days before we recover Primary Server A, does that mean my downtime to
> revert back to server A would be taking server B offline... doing a total
> restore of all dbs to server A and then proceed. So my downtime is equal
to
> the amount of time it takes to restore the dbs as opposed to the initial
> failover from A to B as the only process involved there is recovering the
> dbs.. and other minor stuff such as logins,msdb related jobs and DTS
> packages,sysmessages..assuming we are good to go here
>
> "Greg Linwood" <g_linwoodQhotmail.com> wrote in message
> news:O%23wVThA%23DHA.632@.TK2MSFTNGP12.phx.gbl...
> restore
> testing..
We
But
> time
> state
> want
>
to simulate some disaster recovery runs .
What are some things to consider. It seems obtainable from A to B.. But how
do I revert back to A again.. Do I have to redo log shipping and this time
from B to A which means I need to restore all dbs/logs in norecovery state
onto A from B using the wizard
Are there better ways to simulate this ? I dont wish for it to be a
nightmare especially since if we are going to test this and we would want to
revert back to A as soon as possible during this run...You don't have to set up reverse log-shipping. You simply backup B & restore
it on A & then re-initialise the log shipping process to continue testing..
Regards,
Greg Linwood
SQL Server MVP
"sql" <sql@.hotmail.com> wrote in message
news:uNMLuPA%23DHA.888@.tk2msftngp13.phx.gbl...
> We have a Production Server A thats log shipped to Standby Server B. We
want
> to simulate some disaster recovery runs .
> What are some things to consider. It seems obtainable from A to B.. But
how
> do I revert back to A again.. Do I have to redo log shipping and this time
> from B to A which means I need to restore all dbs/logs in norecovery state
> onto A from B using the wizard
> Are there better ways to simulate this ? I dont wish for it to be a
> nightmare especially since if we are going to test this and we would want
to
> revert back to A as soon as possible during this run...
>
>|||When we fail to Standby Server B initially and simulate to run for 1 or 2
days before we recover Primary Server A, does that mean my downtime to
revert back to server A would be taking server B offline... doing a total
restore of all dbs to server A and then proceed. So my downtime is equal to
the amount of time it takes to restore the dbs as opposed to the initial
failover from A to B as the only process involved there is recovering the
dbs.. and other minor stuff such as logins,msdb related jobs and DTS
packages,sysmessages..assuming we are good to go here
"Greg Linwood" <g_linwoodQhotmail.com> wrote in message
news:O%23wVThA%23DHA.632@.TK2MSFTNGP12.phx.gbl...
> You don't have to set up reverse log-shipping. You simply backup B &
restore
> it on A & then re-initialise the log shipping process to continue
testing..
> Regards,
> Greg Linwood
> SQL Server MVP
> "sql" <sql@.hotmail.com> wrote in message
> news:uNMLuPA%23DHA.888@.tk2msftngp13.phx.gbl...
> want
> how
time
state
want
> to
>|||Hi Hassan.
That's one way of doing it. Another is to do it in multiple steps - eg leave
B online whilst you perform your full backup restore to A (DTS packages &
whatever else), then restore the remaining log tails to A & your window of
downtime is fairly small. If you want to keep that downtime window even
smaller you could iterate the log tail restores.
Regards,
Greg Linwood
SQL Server MVP
"Hassan" <fatima_ja@.hotmail.com> wrote in message
news:%23YHO71D%23DHA.132@.TK2MSFTNGP09.phx.gbl...
> When we fail to Standby Server B initially and simulate to run for 1 or 2
> days before we recover Primary Server A, does that mean my downtime to
> revert back to server A would be taking server B offline... doing a total
> restore of all dbs to server A and then proceed. So my downtime is equal
to
> the amount of time it takes to restore the dbs as opposed to the initial
> failover from A to B as the only process involved there is recovering the
> dbs.. and other minor stuff such as logins,msdb related jobs and DTS
> packages,sysmessages..assuming we are good to go here
>
> "Greg Linwood" <g_linwoodQhotmail.com> wrote in message
> news:O%23wVThA%23DHA.632@.TK2MSFTNGP12.phx.gbl...
> restore
> testing..
We
But
> time
> state
> want
>
Log shipping recovery trials
We have a Production Server A thats log shipped to Standby Server B. We want
to simulate some disaster recovery runs .
What are some things to consider. It seems obtainable from A to B.. But how
do I revert back to A again.. Do I have to redo log shipping and this time
from B to A which means I need to restore all dbs/logs in norecovery state
onto A from B using the wizard
Are there better ways to simulate this ? I dont wish for it to be a
nightmare especially since if we are going to test this and we would want to
revert back to A as soon as possible during this run...You don't have to set up reverse log-shipping. You simply backup B & restore
it on A & then re-initialise the log shipping process to continue testing..
Regards,
Greg Linwood
SQL Server MVP
"sql" <sql@.hotmail.com> wrote in message
news:uNMLuPA%23DHA.888@.tk2msftngp13.phx.gbl...
> We have a Production Server A thats log shipped to Standby Server B. We
want
> to simulate some disaster recovery runs .
> What are some things to consider. It seems obtainable from A to B.. But
how
> do I revert back to A again.. Do I have to redo log shipping and this time
> from B to A which means I need to restore all dbs/logs in norecovery state
> onto A from B using the wizard
> Are there better ways to simulate this ? I dont wish for it to be a
> nightmare especially since if we are going to test this and we would want
to
> revert back to A as soon as possible during this run...
>
>|||When we fail to Standby Server B initially and simulate to run for 1 or 2
days before we recover Primary Server A, does that mean my downtime to
revert back to server A would be taking server B offline... doing a total
restore of all dbs to server A and then proceed. So my downtime is equal to
the amount of time it takes to restore the dbs as opposed to the initial
failover from A to B as the only process involved there is recovering the
dbs.. and other minor stuff such as logins,msdb related jobs and DTS
packages,sysmessages..assuming we are good to go here
"Greg Linwood" <g_linwoodQhotmail.com> wrote in message
news:O%23wVThA%23DHA.632@.TK2MSFTNGP12.phx.gbl...
> You don't have to set up reverse log-shipping. You simply backup B &
restore
> it on A & then re-initialise the log shipping process to continue
testing..
> Regards,
> Greg Linwood
> SQL Server MVP
> "sql" <sql@.hotmail.com> wrote in message
> news:uNMLuPA%23DHA.888@.tk2msftngp13.phx.gbl...
> > We have a Production Server A thats log shipped to Standby Server B. We
> want
> > to simulate some disaster recovery runs .
> >
> > What are some things to consider. It seems obtainable from A to B.. But
> how
> > do I revert back to A again.. Do I have to redo log shipping and this
time
> > from B to A which means I need to restore all dbs/logs in norecovery
state
> > onto A from B using the wizard
> >
> > Are there better ways to simulate this ? I dont wish for it to be a
> > nightmare especially since if we are going to test this and we would
want
> to
> > revert back to A as soon as possible during this run...
> >
> >
> >
>|||Hi Hassan.
That's one way of doing it. Another is to do it in multiple steps - eg leave
B online whilst you perform your full backup restore to A (DTS packages &
whatever else), then restore the remaining log tails to A & your window of
downtime is fairly small. If you want to keep that downtime window even
smaller you could iterate the log tail restores.
Regards,
Greg Linwood
SQL Server MVP
"Hassan" <fatima_ja@.hotmail.com> wrote in message
news:%23YHO71D%23DHA.132@.TK2MSFTNGP09.phx.gbl...
> When we fail to Standby Server B initially and simulate to run for 1 or 2
> days before we recover Primary Server A, does that mean my downtime to
> revert back to server A would be taking server B offline... doing a total
> restore of all dbs to server A and then proceed. So my downtime is equal
to
> the amount of time it takes to restore the dbs as opposed to the initial
> failover from A to B as the only process involved there is recovering the
> dbs.. and other minor stuff such as logins,msdb related jobs and DTS
> packages,sysmessages..assuming we are good to go here
>
> "Greg Linwood" <g_linwoodQhotmail.com> wrote in message
> news:O%23wVThA%23DHA.632@.TK2MSFTNGP12.phx.gbl...
> > You don't have to set up reverse log-shipping. You simply backup B &
> restore
> > it on A & then re-initialise the log shipping process to continue
> testing..
> >
> > Regards,
> > Greg Linwood
> > SQL Server MVP
> >
> > "sql" <sql@.hotmail.com> wrote in message
> > news:uNMLuPA%23DHA.888@.tk2msftngp13.phx.gbl...
> > > We have a Production Server A thats log shipped to Standby Server B.
We
> > want
> > > to simulate some disaster recovery runs .
> > >
> > > What are some things to consider. It seems obtainable from A to B..
But
> > how
> > > do I revert back to A again.. Do I have to redo log shipping and this
> time
> > > from B to A which means I need to restore all dbs/logs in norecovery
> state
> > > onto A from B using the wizard
> > >
> > > Are there better ways to simulate this ? I dont wish for it to be a
> > > nightmare especially since if we are going to test this and we would
> want
> > to
> > > revert back to A as soon as possible during this run...
> > >
> > >
> > >
> >
> >
>
to simulate some disaster recovery runs .
What are some things to consider. It seems obtainable from A to B.. But how
do I revert back to A again.. Do I have to redo log shipping and this time
from B to A which means I need to restore all dbs/logs in norecovery state
onto A from B using the wizard
Are there better ways to simulate this ? I dont wish for it to be a
nightmare especially since if we are going to test this and we would want to
revert back to A as soon as possible during this run...You don't have to set up reverse log-shipping. You simply backup B & restore
it on A & then re-initialise the log shipping process to continue testing..
Regards,
Greg Linwood
SQL Server MVP
"sql" <sql@.hotmail.com> wrote in message
news:uNMLuPA%23DHA.888@.tk2msftngp13.phx.gbl...
> We have a Production Server A thats log shipped to Standby Server B. We
want
> to simulate some disaster recovery runs .
> What are some things to consider. It seems obtainable from A to B.. But
how
> do I revert back to A again.. Do I have to redo log shipping and this time
> from B to A which means I need to restore all dbs/logs in norecovery state
> onto A from B using the wizard
> Are there better ways to simulate this ? I dont wish for it to be a
> nightmare especially since if we are going to test this and we would want
to
> revert back to A as soon as possible during this run...
>
>|||When we fail to Standby Server B initially and simulate to run for 1 or 2
days before we recover Primary Server A, does that mean my downtime to
revert back to server A would be taking server B offline... doing a total
restore of all dbs to server A and then proceed. So my downtime is equal to
the amount of time it takes to restore the dbs as opposed to the initial
failover from A to B as the only process involved there is recovering the
dbs.. and other minor stuff such as logins,msdb related jobs and DTS
packages,sysmessages..assuming we are good to go here
"Greg Linwood" <g_linwoodQhotmail.com> wrote in message
news:O%23wVThA%23DHA.632@.TK2MSFTNGP12.phx.gbl...
> You don't have to set up reverse log-shipping. You simply backup B &
restore
> it on A & then re-initialise the log shipping process to continue
testing..
> Regards,
> Greg Linwood
> SQL Server MVP
> "sql" <sql@.hotmail.com> wrote in message
> news:uNMLuPA%23DHA.888@.tk2msftngp13.phx.gbl...
> > We have a Production Server A thats log shipped to Standby Server B. We
> want
> > to simulate some disaster recovery runs .
> >
> > What are some things to consider. It seems obtainable from A to B.. But
> how
> > do I revert back to A again.. Do I have to redo log shipping and this
time
> > from B to A which means I need to restore all dbs/logs in norecovery
state
> > onto A from B using the wizard
> >
> > Are there better ways to simulate this ? I dont wish for it to be a
> > nightmare especially since if we are going to test this and we would
want
> to
> > revert back to A as soon as possible during this run...
> >
> >
> >
>|||Hi Hassan.
That's one way of doing it. Another is to do it in multiple steps - eg leave
B online whilst you perform your full backup restore to A (DTS packages &
whatever else), then restore the remaining log tails to A & your window of
downtime is fairly small. If you want to keep that downtime window even
smaller you could iterate the log tail restores.
Regards,
Greg Linwood
SQL Server MVP
"Hassan" <fatima_ja@.hotmail.com> wrote in message
news:%23YHO71D%23DHA.132@.TK2MSFTNGP09.phx.gbl...
> When we fail to Standby Server B initially and simulate to run for 1 or 2
> days before we recover Primary Server A, does that mean my downtime to
> revert back to server A would be taking server B offline... doing a total
> restore of all dbs to server A and then proceed. So my downtime is equal
to
> the amount of time it takes to restore the dbs as opposed to the initial
> failover from A to B as the only process involved there is recovering the
> dbs.. and other minor stuff such as logins,msdb related jobs and DTS
> packages,sysmessages..assuming we are good to go here
>
> "Greg Linwood" <g_linwoodQhotmail.com> wrote in message
> news:O%23wVThA%23DHA.632@.TK2MSFTNGP12.phx.gbl...
> > You don't have to set up reverse log-shipping. You simply backup B &
> restore
> > it on A & then re-initialise the log shipping process to continue
> testing..
> >
> > Regards,
> > Greg Linwood
> > SQL Server MVP
> >
> > "sql" <sql@.hotmail.com> wrote in message
> > news:uNMLuPA%23DHA.888@.tk2msftngp13.phx.gbl...
> > > We have a Production Server A thats log shipped to Standby Server B.
We
> > want
> > > to simulate some disaster recovery runs .
> > >
> > > What are some things to consider. It seems obtainable from A to B..
But
> > how
> > > do I revert back to A again.. Do I have to redo log shipping and this
> time
> > > from B to A which means I need to restore all dbs/logs in norecovery
> state
> > > onto A from B using the wizard
> > >
> > > Are there better ways to simulate this ? I dont wish for it to be a
> > > nightmare especially since if we are going to test this and we would
> want
> > to
> > > revert back to A as soon as possible during this run...
> > >
> > >
> > >
> >
> >
>
Log Shipping question
I have SQL 2000 Enterprise edition on my production server, and SQL 2000
Standard on another server that will be used for my standby server. Can I
use Log Shipping in this case? I read I must have enterprise edition, but
do I need it on both servers?
Mike
Yes you can use log shipping.
Log shipping is a feature that is built in to the Enterprise Edition but it
is easy to set this up on your own.
314515 INF: Frequently Asked Questions - SQL Server 2000 - Log Shipping
http://support.microsoft.com/?id=314515
323135 INF: Microsoft SQL Server 2000 - How to Set Up Log Shipping (White
Paper)
http://support.microsoft.com/?id=323135
325220 Support WebCast: Microsoft SQL Server 2000 Log Shipping
http://support.microsoft.com/?id=325220
821786 Support WebCast: Microsoft SQL Server 2000: Using Log Shipping
http://support.microsoft.com/?id=821786
321247 HOW TO: Configure Security for Log Shipping
http://support.microsoft.com/?id=321247
329133 INF: Troubleshooting SQL Server 2000 Log Shipping "Out of Sync"
Errors
http://support.microsoft.com/?id=329133
Keith
"Mike" <mrfaber@.att.net> wrote in message
news:unR3RDIsEHA.3520@.TK2MSFTNGP11.phx.gbl...
> I have SQL 2000 Enterprise edition on my production server, and SQL 2000
> Standard on another server that will be used for my standby server. Can I
> use Log Shipping in this case? I read I must have enterprise edition, but
> do I need it on both servers?
> Mike
>
|||I know that log shipping is built in to Enterprise edition, and also that
you can configure it manully on standard edition, but can I use the builtin
log shipping on my production server(Enterprise Edition) to my standby
server(standard Edition) Or do they both have to be enterprise edition to
use the builtin feature.
Mike
"Keith Kratochvil" <sqlguy.back2u@.comcast.net> wrote in message
news:%231ZNUhIsEHA.324@.TK2MSFTNGP11.phx.gbl...
> Yes you can use log shipping.
> Log shipping is a feature that is built in to the Enterprise Edition but
> it
> is easy to set this up on your own.
>
> 314515 INF: Frequently Asked Questions - SQL Server 2000 - Log Shipping
> http://support.microsoft.com/?id=314515
> 323135 INF: Microsoft SQL Server 2000 - How to Set Up Log Shipping (White
> Paper)
> http://support.microsoft.com/?id=323135
> 325220 Support WebCast: Microsoft SQL Server 2000 Log Shipping
> http://support.microsoft.com/?id=325220
> 821786 Support WebCast: Microsoft SQL Server 2000: Using Log Shipping
> http://support.microsoft.com/?id=821786
> 321247 HOW TO: Configure Security for Log Shipping
> http://support.microsoft.com/?id=321247
> 329133 INF: Troubleshooting SQL Server 2000 Log Shipping "Out of Sync"
> Errors
> http://support.microsoft.com/?id=329133
> --
> Keith
>
> "Mike" <mrfaber@.att.net> wrote in message
> news:unR3RDIsEHA.3520@.TK2MSFTNGP11.phx.gbl...
>
|||I don't know. I have never used the built in method -- I have always
created the log shipping routines myself. Call me old fashioned or call me
a control freak. Heck, I was doing this back in the SQL Server 6.5 days.
It is easy enough to set up the appropriate jobs so I always went that
route.
Keith
"Mike" <mrfaber@.att.net> wrote in message
news:%23Oa1NqJsEHA.3936@.TK2MSFTNGP09.phx.gbl...
> I know that log shipping is built in to Enterprise edition, and also that
> you can configure it manully on standard edition, but can I use the
builtin[vbcol=seagreen]
> log shipping on my production server(Enterprise Edition) to my standby
> server(standard Edition) Or do they both have to be enterprise edition to
> use the builtin feature.
> Mike
> "Keith Kratochvil" <sqlguy.back2u@.comcast.net> wrote in message
> news:%231ZNUhIsEHA.324@.TK2MSFTNGP11.phx.gbl...
(White[vbcol=seagreen]
2000[vbcol=seagreen]
Can
>
sql
Standard on another server that will be used for my standby server. Can I
use Log Shipping in this case? I read I must have enterprise edition, but
do I need it on both servers?
Mike
Yes you can use log shipping.
Log shipping is a feature that is built in to the Enterprise Edition but it
is easy to set this up on your own.
314515 INF: Frequently Asked Questions - SQL Server 2000 - Log Shipping
http://support.microsoft.com/?id=314515
323135 INF: Microsoft SQL Server 2000 - How to Set Up Log Shipping (White
Paper)
http://support.microsoft.com/?id=323135
325220 Support WebCast: Microsoft SQL Server 2000 Log Shipping
http://support.microsoft.com/?id=325220
821786 Support WebCast: Microsoft SQL Server 2000: Using Log Shipping
http://support.microsoft.com/?id=821786
321247 HOW TO: Configure Security for Log Shipping
http://support.microsoft.com/?id=321247
329133 INF: Troubleshooting SQL Server 2000 Log Shipping "Out of Sync"
Errors
http://support.microsoft.com/?id=329133
Keith
"Mike" <mrfaber@.att.net> wrote in message
news:unR3RDIsEHA.3520@.TK2MSFTNGP11.phx.gbl...
> I have SQL 2000 Enterprise edition on my production server, and SQL 2000
> Standard on another server that will be used for my standby server. Can I
> use Log Shipping in this case? I read I must have enterprise edition, but
> do I need it on both servers?
> Mike
>
|||I know that log shipping is built in to Enterprise edition, and also that
you can configure it manully on standard edition, but can I use the builtin
log shipping on my production server(Enterprise Edition) to my standby
server(standard Edition) Or do they both have to be enterprise edition to
use the builtin feature.
Mike
"Keith Kratochvil" <sqlguy.back2u@.comcast.net> wrote in message
news:%231ZNUhIsEHA.324@.TK2MSFTNGP11.phx.gbl...
> Yes you can use log shipping.
> Log shipping is a feature that is built in to the Enterprise Edition but
> it
> is easy to set this up on your own.
>
> 314515 INF: Frequently Asked Questions - SQL Server 2000 - Log Shipping
> http://support.microsoft.com/?id=314515
> 323135 INF: Microsoft SQL Server 2000 - How to Set Up Log Shipping (White
> Paper)
> http://support.microsoft.com/?id=323135
> 325220 Support WebCast: Microsoft SQL Server 2000 Log Shipping
> http://support.microsoft.com/?id=325220
> 821786 Support WebCast: Microsoft SQL Server 2000: Using Log Shipping
> http://support.microsoft.com/?id=821786
> 321247 HOW TO: Configure Security for Log Shipping
> http://support.microsoft.com/?id=321247
> 329133 INF: Troubleshooting SQL Server 2000 Log Shipping "Out of Sync"
> Errors
> http://support.microsoft.com/?id=329133
> --
> Keith
>
> "Mike" <mrfaber@.att.net> wrote in message
> news:unR3RDIsEHA.3520@.TK2MSFTNGP11.phx.gbl...
>
|||I don't know. I have never used the built in method -- I have always
created the log shipping routines myself. Call me old fashioned or call me
a control freak. Heck, I was doing this back in the SQL Server 6.5 days.
It is easy enough to set up the appropriate jobs so I always went that
route.
Keith
"Mike" <mrfaber@.att.net> wrote in message
news:%23Oa1NqJsEHA.3936@.TK2MSFTNGP09.phx.gbl...
> I know that log shipping is built in to Enterprise edition, and also that
> you can configure it manully on standard edition, but can I use the
builtin[vbcol=seagreen]
> log shipping on my production server(Enterprise Edition) to my standby
> server(standard Edition) Or do they both have to be enterprise edition to
> use the builtin feature.
> Mike
> "Keith Kratochvil" <sqlguy.back2u@.comcast.net> wrote in message
> news:%231ZNUhIsEHA.324@.TK2MSFTNGP11.phx.gbl...
(White[vbcol=seagreen]
2000[vbcol=seagreen]
Can
>
sql
Friday, March 23, 2012
Log Shipping Question
A user has SQL Server 2000 Personal Edition for production and wants
a
stand-by server to ensure availability of her data. I suggested that
we use a log shipping server so she has provided the Enterprise
Edition of SQL Server 2000. So correct me if the best approach here
is to:
1. Upgrade her personal edition version to Enterprise (Server 1)
2. Install Standard Edition to Server 2.
3. Instigate log shipping on Server 1 so that the data on Server 2
is
kept current.
or should she keep her Personal Edition on Server 1 and install the
Enterprise Edition to Server 2 with the Log Shipping features?
Thanks for any suggestions!
RBollingerAFAIK, the built-in log shipping support requires EE on both machines. I sug
gest you Google on
home-grown scripts for log shipping. They will work on any edition. After al
l, log shipping is
nothing more than backup and restore.
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://sqlblog.com/blogs/tibor_karaszi
"robboll" <robboll@.hotmail.com> wrote in message
news:1174396428.546943.113190@.o5g2000hsb.googlegroups.com...
>A user has SQL Server 2000 Personal Edition for production and wants
> a
> stand-by server to ensure availability of her data. I suggested that
> we use a log shipping server so she has provided the Enterprise
> Edition of SQL Server 2000. So correct me if the best approach here
> is to:
> 1. Upgrade her personal edition version to Enterprise (Server 1)
> 2. Install Standard Edition to Server 2.
> 3. Instigate log shipping on Server 1 so that the data on Server 2
> is
> kept current.
> or should she keep her Personal Edition on Server 1 and install the
> Enterprise Edition to Server 2 with the Log Shipping features?
> Thanks for any suggestions!
>
> RBollinger
>sql
a
stand-by server to ensure availability of her data. I suggested that
we use a log shipping server so she has provided the Enterprise
Edition of SQL Server 2000. So correct me if the best approach here
is to:
1. Upgrade her personal edition version to Enterprise (Server 1)
2. Install Standard Edition to Server 2.
3. Instigate log shipping on Server 1 so that the data on Server 2
is
kept current.
or should she keep her Personal Edition on Server 1 and install the
Enterprise Edition to Server 2 with the Log Shipping features?
Thanks for any suggestions!
RBollingerAFAIK, the built-in log shipping support requires EE on both machines. I sug
gest you Google on
home-grown scripts for log shipping. They will work on any edition. After al
l, log shipping is
nothing more than backup and restore.
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://sqlblog.com/blogs/tibor_karaszi
"robboll" <robboll@.hotmail.com> wrote in message
news:1174396428.546943.113190@.o5g2000hsb.googlegroups.com...
>A user has SQL Server 2000 Personal Edition for production and wants
> a
> stand-by server to ensure availability of her data. I suggested that
> we use a log shipping server so she has provided the Enterprise
> Edition of SQL Server 2000. So correct me if the best approach here
> is to:
> 1. Upgrade her personal edition version to Enterprise (Server 1)
> 2. Install Standard Edition to Server 2.
> 3. Instigate log shipping on Server 1 so that the data on Server 2
> is
> kept current.
> or should she keep her Personal Edition on Server 1 and install the
> Enterprise Edition to Server 2 with the Log Shipping features?
> Thanks for any suggestions!
>
> RBollinger
>sql
Log Shipping question
I have SQL 2000 Enterprise edition on my production server, and SQL 2000
Standard on another server that will be used for my standby server. Can I
use Log Shipping in this case? I read I must have enterprise edition, but
do I need it on both servers?
MikeYes you can use log shipping.
Log shipping is a feature that is built in to the Enterprise Edition but it
is easy to set this up on your own.
314515 INF: Frequently Asked Questions - SQL Server 2000 - Log Shipping
http://support.microsoft.com/?id=314515
323135 INF: Microsoft SQL Server 2000 - How to Set Up Log Shipping (White
Paper)
http://support.microsoft.com/?id=323135
325220 Support WebCast: Microsoft SQL Server 2000 Log Shipping
http://support.microsoft.com/?id=325220
821786 Support WebCast: Microsoft SQL Server 2000: Using Log Shipping
http://support.microsoft.com/?id=821786
321247 HOW TO: Configure Security for Log Shipping
http://support.microsoft.com/?id=321247
329133 INF: Troubleshooting SQL Server 2000 Log Shipping "Out of Sync"
Errors
http://support.microsoft.com/?id=329133
Keith
"Mike" <mrfaber@.att.net> wrote in message
news:unR3RDIsEHA.3520@.TK2MSFTNGP11.phx.gbl...
> I have SQL 2000 Enterprise edition on my production server, and SQL 2000
> Standard on another server that will be used for my standby server. Can I
> use Log Shipping in this case? I read I must have enterprise edition, but
> do I need it on both servers?
> Mike
>|||I know that log shipping is built in to Enterprise edition, and also that
you can configure it manully on standard edition, but can I use the builtin
log shipping on my production server(Enterprise Edition) to my standby
server(standard Edition) Or do they both have to be enterprise edition to
use the builtin feature.
Mike
"Keith Kratochvil" <sqlguy.back2u@.comcast.net> wrote in message
news:%231ZNUhIsEHA.324@.TK2MSFTNGP11.phx.gbl...
> Yes you can use log shipping.
> Log shipping is a feature that is built in to the Enterprise Edition but
> it
> is easy to set this up on your own.
>
> 314515 INF: Frequently Asked Questions - SQL Server 2000 - Log Shipping
> http://support.microsoft.com/?id=314515
> 323135 INF: Microsoft SQL Server 2000 - How to Set Up Log Shipping (White
> Paper)
> http://support.microsoft.com/?id=323135
> 325220 Support WebCast: Microsoft SQL Server 2000 Log Shipping
> http://support.microsoft.com/?id=325220
> 821786 Support WebCast: Microsoft SQL Server 2000: Using Log Shipping
> http://support.microsoft.com/?id=821786
> 321247 HOW TO: Configure Security for Log Shipping
> http://support.microsoft.com/?id=321247
> 329133 INF: Troubleshooting SQL Server 2000 Log Shipping "Out of Sync"
> Errors
> http://support.microsoft.com/?id=329133
> --
> Keith
>
> "Mike" <mrfaber@.att.net> wrote in message
> news:unR3RDIsEHA.3520@.TK2MSFTNGP11.phx.gbl...
>|||I don't know. I have never used the built in method -- I have always
created the log shipping routines myself. Call me old fashioned or call me
a control freak. Heck, I was doing this back in the SQL Server 6.5 days.
It is easy enough to set up the appropriate jobs so I always went that
route.
Keith
"Mike" <mrfaber@.att.net> wrote in message
news:%23Oa1NqJsEHA.3936@.TK2MSFTNGP09.phx.gbl...
> I know that log shipping is built in to Enterprise edition, and also that
> you can configure it manully on standard edition, but can I use the
builtin
> log shipping on my production server(Enterprise Edition) to my standby
> server(standard Edition) Or do they both have to be enterprise edition to
> use the builtin feature.
> Mike
> "Keith Kratochvil" <sqlguy.back2u@.comcast.net> wrote in message
> news:%231ZNUhIsEHA.324@.TK2MSFTNGP11.phx.gbl...
(White[vbcol=seagreen]
2000[vbcol=seagreen]
Can[vbcol=seagreen]
>
Standard on another server that will be used for my standby server. Can I
use Log Shipping in this case? I read I must have enterprise edition, but
do I need it on both servers?
MikeYes you can use log shipping.
Log shipping is a feature that is built in to the Enterprise Edition but it
is easy to set this up on your own.
314515 INF: Frequently Asked Questions - SQL Server 2000 - Log Shipping
http://support.microsoft.com/?id=314515
323135 INF: Microsoft SQL Server 2000 - How to Set Up Log Shipping (White
Paper)
http://support.microsoft.com/?id=323135
325220 Support WebCast: Microsoft SQL Server 2000 Log Shipping
http://support.microsoft.com/?id=325220
821786 Support WebCast: Microsoft SQL Server 2000: Using Log Shipping
http://support.microsoft.com/?id=821786
321247 HOW TO: Configure Security for Log Shipping
http://support.microsoft.com/?id=321247
329133 INF: Troubleshooting SQL Server 2000 Log Shipping "Out of Sync"
Errors
http://support.microsoft.com/?id=329133
Keith
"Mike" <mrfaber@.att.net> wrote in message
news:unR3RDIsEHA.3520@.TK2MSFTNGP11.phx.gbl...
> I have SQL 2000 Enterprise edition on my production server, and SQL 2000
> Standard on another server that will be used for my standby server. Can I
> use Log Shipping in this case? I read I must have enterprise edition, but
> do I need it on both servers?
> Mike
>|||I know that log shipping is built in to Enterprise edition, and also that
you can configure it manully on standard edition, but can I use the builtin
log shipping on my production server(Enterprise Edition) to my standby
server(standard Edition) Or do they both have to be enterprise edition to
use the builtin feature.
Mike
"Keith Kratochvil" <sqlguy.back2u@.comcast.net> wrote in message
news:%231ZNUhIsEHA.324@.TK2MSFTNGP11.phx.gbl...
> Yes you can use log shipping.
> Log shipping is a feature that is built in to the Enterprise Edition but
> it
> is easy to set this up on your own.
>
> 314515 INF: Frequently Asked Questions - SQL Server 2000 - Log Shipping
> http://support.microsoft.com/?id=314515
> 323135 INF: Microsoft SQL Server 2000 - How to Set Up Log Shipping (White
> Paper)
> http://support.microsoft.com/?id=323135
> 325220 Support WebCast: Microsoft SQL Server 2000 Log Shipping
> http://support.microsoft.com/?id=325220
> 821786 Support WebCast: Microsoft SQL Server 2000: Using Log Shipping
> http://support.microsoft.com/?id=821786
> 321247 HOW TO: Configure Security for Log Shipping
> http://support.microsoft.com/?id=321247
> 329133 INF: Troubleshooting SQL Server 2000 Log Shipping "Out of Sync"
> Errors
> http://support.microsoft.com/?id=329133
> --
> Keith
>
> "Mike" <mrfaber@.att.net> wrote in message
> news:unR3RDIsEHA.3520@.TK2MSFTNGP11.phx.gbl...
>|||I don't know. I have never used the built in method -- I have always
created the log shipping routines myself. Call me old fashioned or call me
a control freak. Heck, I was doing this back in the SQL Server 6.5 days.
It is easy enough to set up the appropriate jobs so I always went that
route.
Keith
"Mike" <mrfaber@.att.net> wrote in message
news:%23Oa1NqJsEHA.3936@.TK2MSFTNGP09.phx.gbl...
> I know that log shipping is built in to Enterprise edition, and also that
> you can configure it manully on standard edition, but can I use the
builtin
> log shipping on my production server(Enterprise Edition) to my standby
> server(standard Edition) Or do they both have to be enterprise edition to
> use the builtin feature.
> Mike
> "Keith Kratochvil" <sqlguy.back2u@.comcast.net> wrote in message
> news:%231ZNUhIsEHA.324@.TK2MSFTNGP11.phx.gbl...
(White[vbcol=seagreen]
2000[vbcol=seagreen]
Can[vbcol=seagreen]
>
Log Shipping Question
I have successfully setup log shipping between my production SQL 2000 Server
(setup in a Cluster) and my Disaster Recovery SQL 2000 Server (across a WAN)
What is the best way if any to stop the log shipping for a extended period
of time and re-enable it without setting up the entire maintenance plan
again. Is this possible? What happened is I needed to shut down my
production server due to hurricane Wilma as a precaution. I disabled the log
shipping jobs on both servers but didn't actually physicall shut down the
Disaster Recovery SQL 2000 Server.
The servers got out of synch...although it said the logs were being shipped
and they were working correctly after I turned the production server back on.
However, the log were not being copied to the Disaster Recovery Server.
Any help would be appreciated. Thanks!!
Hello mate,
The way I understand it is you could have just shut down your production
server without changing/stopping/disabling the log shipping jobs and just
bring it back online when your happy (the hurricane has passed!) and the
backup/copy and restores should resume as normal?
The shipping jobs seems very automated once started and syncronised - think
of it like a 'long reboot' of your production boxes. Your boxes aer fine
after bouncing them right - so whats the difference if they are down for a
few days?
I'm in the middle of documenting a similar setup with my production box (non
clustered) getting logs sent to the backup SQL box accross a WAN - the most
complex part of the exercise seems to be getting the backup DB up and running
post failure/disaster of the production box.
Hope this helps you mate.
Paul.
"foghorn69@.news.postalias" wrote:
> I have successfully setup log shipping between my production SQL 2000 Server
> (setup in a Cluster) and my Disaster Recovery SQL 2000 Server (across a WAN)
> What is the best way if any to stop the log shipping for a extended period
> of time and re-enable it without setting up the entire maintenance plan
> again. Is this possible? What happened is I needed to shut down my
> production server due to hurricane Wilma as a precaution. I disabled the log
> shipping jobs on both servers but didn't actually physicall shut down the
> Disaster Recovery SQL 2000 Server.
> The servers got out of synch...although it said the logs were being shipped
> and they were working correctly after I turned the production server back on.
> However, the log were not being copied to the Disaster Recovery Server.
> Any help would be appreciated. Thanks!!
(setup in a Cluster) and my Disaster Recovery SQL 2000 Server (across a WAN)
What is the best way if any to stop the log shipping for a extended period
of time and re-enable it without setting up the entire maintenance plan
again. Is this possible? What happened is I needed to shut down my
production server due to hurricane Wilma as a precaution. I disabled the log
shipping jobs on both servers but didn't actually physicall shut down the
Disaster Recovery SQL 2000 Server.
The servers got out of synch...although it said the logs were being shipped
and they were working correctly after I turned the production server back on.
However, the log were not being copied to the Disaster Recovery Server.
Any help would be appreciated. Thanks!!
Hello mate,
The way I understand it is you could have just shut down your production
server without changing/stopping/disabling the log shipping jobs and just
bring it back online when your happy (the hurricane has passed!) and the
backup/copy and restores should resume as normal?
The shipping jobs seems very automated once started and syncronised - think
of it like a 'long reboot' of your production boxes. Your boxes aer fine
after bouncing them right - so whats the difference if they are down for a
few days?
I'm in the middle of documenting a similar setup with my production box (non
clustered) getting logs sent to the backup SQL box accross a WAN - the most
complex part of the exercise seems to be getting the backup DB up and running
post failure/disaster of the production box.
Hope this helps you mate.
Paul.
"foghorn69@.news.postalias" wrote:
> I have successfully setup log shipping between my production SQL 2000 Server
> (setup in a Cluster) and my Disaster Recovery SQL 2000 Server (across a WAN)
> What is the best way if any to stop the log shipping for a extended period
> of time and re-enable it without setting up the entire maintenance plan
> again. Is this possible? What happened is I needed to shut down my
> production server due to hurricane Wilma as a precaution. I disabled the log
> shipping jobs on both servers but didn't actually physicall shut down the
> Disaster Recovery SQL 2000 Server.
> The servers got out of synch...although it said the logs were being shipped
> and they were working correctly after I turned the production server back on.
> However, the log were not being copied to the Disaster Recovery Server.
> Any help would be appreciated. Thanks!!
Subscribe to:
Posts (Atom)