Log shipping alerts: running

Showing posts with label running. Show all posts

Friday, March 30, 2012

Log Shipping with clustered database.

Hi,
We are running SQL Server Failover cluster in Active/Passive mode.
Now, we want to setup DR server for this clustered database using
Log shipping.
But my concern is, can we do log shipping with clustered database ?
and the answer of this question is Yes then Please let me know How ?
Thanks & Regards,
Sajid C.
Yep...you can. Just like how you do it in a non-clustered instance. The only
problem you will have in here is if you want to be notified thru email if
your restore jobs fail as MAPI is not supported in a clustered environment.
MCP MCDBA MCAD MCSD MCT MCTS MCITP:DBA
"Helping people grow and develop their full potential as God has plan for
them"
"csajid@.gmail.com" wrote:

> Hi,
> We are running SQL Server Failover cluster in Active/Passive mode.
> Now, we want to setup DR server for this clustered database using
> Log shipping.
> But my concern is, can we do log shipping with clustered database ?
> and the answer of this question is Yes then Please let me know How ?
>
> Thanks & Regards,
> Sajid C.
>
|||Hi,
Thanks for your reply.
Can you please provide me some document or any link for the same.
What are the necessary steps which should i take to do this task.
Thanks & Regards,
Sajid C.
bass_player wrote:[vbcol=seagreen]
> Yep...you can. Just like how you do it in a non-clustered instance. The only
> problem you will have in here is if you want to be notified thru email if
> your restore jobs fail as MAPI is not supported in a clustered environment.
> --
> MCP MCDBA MCAD MCSD MCT MCTS MCITP:DBA
> "Helping people grow and develop their full potential as God has plan for
> them"
>
> "csajid@.gmail.com" wrote:

Log Shipping with clustered database.

Hi,
We are running SQL Server Failover cluster in Active/Passive mode.
Now, we want to setup DR server for this clustered database using
Log shipping.
But my concern is, can we do log shipping with clustered database ?
and the answer of this question is Yes then Please let me know How ?
Thanks & Regards,
Sajid C.Yep...you can. Just like how you do it in a non-clustered instance. The only
problem you will have in here is if you want to be notified thru email if
your restore jobs fail as MAPI is not supported in a clustered environment.
--
MCP MCDBA MCAD MCSD MCT MCTS MCITP:DBA
"Helping people grow and develop their full potential as God has plan for
them"
"csajid@.gmail.com" wrote:
> Hi,
> We are running SQL Server Failover cluster in Active/Passive mode.
> Now, we want to setup DR server for this clustered database using
> Log shipping.
> But my concern is, can we do log shipping with clustered database ?
> and the answer of this question is Yes then Please let me know How ?
>
> Thanks & Regards,
> Sajid C.
>|||Hi,
Thanks for your reply.
Can you please provide me some document or any link for the same.
What are the necessary steps which should i take to do this task.
Thanks & Regards,
Sajid C.
bass_player wrote:
> Yep...you can. Just like how you do it in a non-clustered instance. The only
> problem you will have in here is if you want to be notified thru email if
> your restore jobs fail as MAPI is not supported in a clustered environment.
> --
> MCP MCDBA MCAD MCSD MCT MCTS MCITP:DBA
> "Helping people grow and develop their full potential as God has plan for
> them"
>
> "csajid@.gmail.com" wrote:
> > Hi,
> >
> > We are running SQL Server Failover cluster in Active/Passive mode.
> >
> > Now, we want to setup DR server for this clustered database using
> > Log shipping.
> >
> > But my concern is, can we do log shipping with clustered database ?
> > and the answer of this question is Yes then Please let me know How ?
> >
> >
> > Thanks & Regards,
> > Sajid C.
> >
> >

Log Shipping with clustered database.

Hi,
We are running SQL Server Failover cluster in Active/Passive mode.
Now, we want to setup DR server for this clustered database using
Log shipping.
But my concern is, can we do log shipping with clustered database ?
and the answer of this question is Yes then Please let me know How ?
Thanks & Regards,
Sajid C.Yep...you can. Just like how you do it in a non-clustered instance. The onl
y
problem you will have in here is if you want to be notified thru email if
your restore jobs fail as MAPI is not supported in a clustered environment.
--
MCP MCDBA MCAD MCSD MCT MCTS MCITP:DBA
"Helping people grow and develop their full potential as God has plan for
them"
"csajid@.gmail.com" wrote:

> Hi,
> We are running SQL Server Failover cluster in Active/Passive mode.
> Now, we want to setup DR server for this clustered database using
> Log shipping.
> But my concern is, can we do log shipping with clustered database ?
> and the answer of this question is Yes then Please let me know How ?
>
> Thanks & Regards,
> Sajid C.
>|||Hi,
Thanks for your reply.
Can you please provide me some document or any link for the same.
What are the necessary steps which should i take to do this task.
Thanks & Regards,
Sajid C.
bass_player wrote:[vbcol=seagreen]
> Yep...you can. Just like how you do it in a non-clustered instance. The o
nly
> problem you will have in here is if you want to be notified thru email if
> your restore jobs fail as MAPI is not supported in a clustered environment
.
> --
> MCP MCDBA MCAD MCSD MCT MCTS MCITP:DBA
> "Helping people grow and develop their full potential as God has plan for
> them"
>
> "csajid@.gmail.com" wrote:
>

Log Shipping using SQL Server Standard

I'm trying to implement Log Shipping to my database but I
am running SQL Server Standard. I understand that SQL
Enterprise edition has this built into it, but we
currently can't perform an upgrade. How can I do this in
the standard edition, or how can I get access to the jobs
and store procedures or any other objects that get
created using the enterprise edtion so that I can
implement log shipping using the standard edition?
Thanks in advanced,
Vichttp://www.sql-server-performance.com/sql_server_log_shipping.asp
"Vic" <vduran@.specpro-inc.com> wrote in message
news:025b01c3d496$d9112bf0$a401280a@.phx.gbl...
> I'm trying to implement Log Shipping to my database but I
> am running SQL Server Standard. I understand that SQL
> Enterprise edition has this built into it, but we
> currently can't perform an upgrade. How can I do this in
> the standard edition, or how can I get access to the jobs
> and store procedures or any other objects that get
> created using the enterprise edtion so that I can
> implement log shipping using the standard edition?
> Thanks in advanced,
> Vic|||Hi Vic.
A couple of more alternatives for you are:
(a) http://sqlguy.home.comcast.net/logship.htm
(b) There's also a log shipping utility in the SQL Server Resource Kit which
you can downlaod from msdn if you're got a subscription.
These can be used with SQL Standard edition. You may even find others if you
spent some time searching the web..
HTH
Regards,
Greg Linwood
SQL Server MVP
"Vic" <vduran@.specpro-inc.com> wrote in message
news:025b01c3d496$d9112bf0$a401280a@.phx.gbl...
> I'm trying to implement Log Shipping to my database but I
> am running SQL Server Standard. I understand that SQL
> Enterprise edition has this built into it, but we
> currently can't perform an upgrade. How can I do this in
> the standard edition, or how can I get access to the jobs
> and store procedures or any other objects that get
> created using the enterprise edtion so that I can
> implement log shipping using the standard edition?
> Thanks in advanced,
> Vic

Log Shipping Transaction Logs.

Hi,

We currently have a couple a large Databases running on SQL 2000 SP3 Clustered Windows 2000 SP3 environment.

Log Shipping is enabled for both databases shipping to a Standalone SQL 2000 SP3 Windows 2000 SP3 box.

Log Shipping occurs every 15 mins with the Transaction Files on average being no more than 500KB in size. However, every now and then a Transaction Log comes through and it can be as big as 3.52GB.

Not sure why this is happening. Anyone got any ideas?

Regards

Paul TowlerIs this after substantial activity or reindexing?|||i think auto shrink or some other job is enabled
if iam right, the auto shrink or job gets activated and the step goes thru
which will obviously create transaction file with huge size.|||Thanks for your replies.

There is a Job to Optimise the Database which does re-index the database. I presume all the indexing changes count as changes and therefore shipped as one big Transacton file.

Hopefully there is a way to prevent these hugh Transaction Files without turning off the indexing job.

Regards
Paul Towlersql

Wednesday, March 28, 2012

Log Shipping to old box?

My primary SQL Server box is 2005 Standard x64 running on 2 quad-core processors. I'm licensed for 2 processors.

I'd like to set up some kind of redundancy. The hardware I have available is about 4 years old and is currently running SQL Server 2000. Let's assume I upgrade the old box to SQL Server 2005 Standard. A couple of questions:

1) It seems the hardware gap between the 2 will make little difference in a log shipping. Please confirm this. Any other things that might be an issue?

2) Do I need lots of CALs on the backup box for Log Shipping? Or can I get by with 5?

3) I'd like to schedule log shipping pretty often--maybe every 5 or 10 minutes. Will this be an issue?

Thanks!

1. No

2. No, Yes, as long as it is not accessed by users that are not covered with CALs. A SQL Server CAL is good for all SQL Servers in the domain.

3. 5-10 minutes 'should' not be an issue. As long as the performance/load differential is not so great that the log cannot be applied in the time alloted.

Another option with SQL 2005 is Database Mirroring. Have you explored the benefits of Database Mirroring?

|||>Another option with SQL 2005 is Database Mirroring. Have you explored the benefits of Database Mirroring?

I've read a little about Database Mirroring. How will my old hardware affect the mirroring process? Will I have trouble with the slower server keeping up with the transactions?

Brian

|||

The same issue occurs with Log Shipping.

Will, in fact, the old box have enough 'power' to keep up with the data flow. That is something you will have to test.

|||

I guess I made this assumption (that could be very wrong):

Log Shipping moves data in batches. Database mirroring moves data by record or transaction. (Not sure what method is used). A batch append should be less stressful on a backup server than a bunch of individual appends.

Even if these are true, maybe the difference in stress is much less than I think.

Brian

|||

It could go either way.

I would set up a test environment and test both if they seemed equally valid solution candidates. You're trying to balance the trade-offs of cost of solution vs. speed of recovery.

sql

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
> >
> >
>
>

Log shipping sync error 14421

Hi
SQLServer 2000 sp3 enterprise running logshipping smoothly, today its
broken, out of sync error for all databases on standby server error
14421. I have manually restored all the log backups and updated manually
log_shipping_secondaries columns set last_copied_last_updated &
last_loaded_last_updated with 15 min difference which i have configured.
But the log backups are not copied &last_copied_filename is not getting
updated. how can i fix this issues and continue log shipping with out
reconfiguring?
thanks for looking
kris
Did you look at:
Description of error message 14420 and error message 14421 that occur when
you use log shipping in SQL Server
http://support.microsoft.com/kb/329133
?
"krishna" wrote:

> Hi
> SQLServer 2000 sp3 enterprise running logshipping smoothly, today its
> broken, out of sync error for all databases on standby server error
> 14421. I have manually restored all the log backups and updated manually
> log_shipping_secondaries columns set last_copied_last_updated &
> last_loaded_last_updated with 15 min difference which i have configured.
> But the log backups are not copied &last_copied_filename is not getting
> updated. how can i fix this issues and continue log shipping with out
> reconfiguring?
> thanks for looking
> kris
>
|||I looked into that kb article, i have tried accessing the folder on the
standby server from source machine. it is fine. i dont know why the logs
are not copied to standby server. I just want to fix the issue without
reconfiguring. Is there any way to copy & restore the remaining logs and
updating the logshipping tables and continue the process?
Edgardo Valdez wrote:[vbcol=seagreen]
> Did you look at:
> Description of error message 14420 and error message 14421 that occur when
> you use log shipping in SQL Server
> http://support.microsoft.com/kb/329133
> ?
> "krishna" wrote:
|||I looked into that kb article, i have tried accessing the folder on the
standby server from source machine. it is fine. i dont know why the logs
are not copied to standby server. I just want to fix the issue without
reconfiguring. Is there any way to copy & restore the remaining logs and
updating the logshipping tables and continue the process?
krishna wrote:
> Hi
> SQLServer 2000 sp3 enterprise running logshipping smoothly, today its
> broken, out of sync error for all databases on standby server error
> 14421. I have manually restored all the log backups and updated manually
> log_shipping_secondaries columns set last_copied_last_updated &
> last_loaded_last_updated with 15 min difference which i have configured.
> But the log backups are not copied &last_copied_filename is not getting
> updated. how can i fix this issues and continue log shipping with out
> reconfiguring?
> thanks for looking
> kris

Log shipping sync error 14421

Hi
SQLServer 2000 sp3 enterprise running logshipping smoothly, today its
broken, out of sync error for all databases on standby server error
14421. I have manually restored all the log backups and updated manually
log_shipping_secondaries columns set last_copied_last_updated &
last_loaded_last_updated with 15 min difference which i have configured.
But the log backups are not copied &last_copied_filename is not getting
updated. how can i fix this issues and continue log shipping with out
reconfiguring?
thanks for looking
krisDid you look at:
Description of error message 14420 and error message 14421 that occur when
you use log shipping in SQL Server
http://support.microsoft.com/kb/329133
?
"krishna" wrote:

> Hi
> SQLServer 2000 sp3 enterprise running logshipping smoothly, today its
> broken, out of sync error for all databases on standby server error
> 14421. I have manually restored all the log backups and updated manually
> log_shipping_secondaries columns set last_copied_last_updated &
> last_loaded_last_updated with 15 min difference which i have configured.
> But the log backups are not copied &last_copied_filename is not getting
> updated. how can i fix this issues and continue log shipping with out
> reconfiguring?
> thanks for looking
> kris
>|||I looked into that kb article, i have tried accessing the folder on the
standby server from source machine. it is fine. i dont know why the logs
are not copied to standby server. I just want to fix the issue without
reconfiguring. Is there any way to copy & restore the remaining logs and
updating the logshipping tables and continue the process?
Edgardo Valdez wrote:[vbcol=seagreen]
> Did you look at:
> Description of error message 14420 and error message 14421 that occur when
> you use log shipping in SQL Server
> http://support.microsoft.com/kb/329133
> ?
> "krishna" wrote:
>|||I looked into that kb article, i have tried accessing the folder on the
standby server from source machine. it is fine. i dont know why the logs
are not copied to standby server. I just want to fix the issue without
reconfiguring. Is there any way to copy & restore the remaining logs and
updating the logshipping tables and continue the process?
krishna wrote:
> Hi
> SQLServer 2000 sp3 enterprise running logshipping smoothly, today its
> broken, out of sync error for all databases on standby server error
> 14421. I have manually restored all the log backups and updated manually
> log_shipping_secondaries columns set last_copied_last_updated &
> last_loaded_last_updated with 15 min difference which i have configured.
> But the log backups are not copied &last_copied_filename is not getting
> updated. how can i fix this issues and continue log shipping with out
> reconfiguring?
> thanks for looking
> kris

Log shipping sync error 14421

Hi
SQLServer 2000 sp3 enterprise running logshipping smoothly, today its
broken, out of sync error for all databases on standby server error
14421. I have manually restored all the log backups and updated manually
log_shipping_secondaries columns set last_copied_last_updated &
last_loaded_last_updated with 15 min difference which i have configured.
But the log backups are not copied &last_copied_filename is not getting
updated. how can i fix this issues and continue log shipping with out
reconfiguring?
thanks for looking
krisDid you look at:
Description of error message 14420 and error message 14421 that occur when
you use log shipping in SQL Server
http://support.microsoft.com/kb/329133
?
"krishna" wrote:
> Hi
> SQLServer 2000 sp3 enterprise running logshipping smoothly, today its
> broken, out of sync error for all databases on standby server error
> 14421. I have manually restored all the log backups and updated manually
> log_shipping_secondaries columns set last_copied_last_updated &
> last_loaded_last_updated with 15 min difference which i have configured.
> But the log backups are not copied &last_copied_filename is not getting
> updated. how can i fix this issues and continue log shipping with out
> reconfiguring?
> thanks for looking
> kris
>|||I looked into that kb article, i have tried accessing the folder on the
standby server from source machine. it is fine. i dont know why the logs
are not copied to standby server. I just want to fix the issue without
reconfiguring. Is there any way to copy & restore the remaining logs and
updating the logshipping tables and continue the process?
Edgardo Valdez wrote:
> Did you look at:
> Description of error message 14420 and error message 14421 that occur when
> you use log shipping in SQL Server
> http://support.microsoft.com/kb/329133
> ?
> "krishna" wrote:
>> Hi
>> SQLServer 2000 sp3 enterprise running logshipping smoothly, today its
>> broken, out of sync error for all databases on standby server error
>> 14421. I have manually restored all the log backups and updated manually
>> log_shipping_secondaries columns set last_copied_last_updated &
>> last_loaded_last_updated with 15 min difference which i have configured.
>> But the log backups are not copied &last_copied_filename is not getting
>> updated. how can i fix this issues and continue log shipping with out
>> reconfiguring?
>> thanks for looking
>> kris|||I looked into that kb article, i have tried accessing the folder on the
standby server from source machine. it is fine. i dont know why the logs
are not copied to standby server. I just want to fix the issue without
reconfiguring. Is there any way to copy & restore the remaining logs and
updating the logshipping tables and continue the process?
krishna wrote:
> Hi
> SQLServer 2000 sp3 enterprise running logshipping smoothly, today its
> broken, out of sync error for all databases on standby server error
> 14421. I have manually restored all the log backups and updated manually
> log_shipping_secondaries columns set last_copied_last_updated &
> last_loaded_last_updated with 15 min difference which i have configured.
> But the log backups are not copied &last_copied_filename is not getting
> updated. how can i fix this issues and continue log shipping with out
> reconfiguring?
> thanks for looking
> kris

log shipping sql 2005 database remains in (restoring...) mode

I've been playing with the SQL 2005 log shipping and have been running into a
few problems.
My system is configured on a virtual server with two instances of SQL 2005.
The OS is Windows 2003. I'm shipping logs from the default instance to the
named instance with the default having the primary database and the named,
the secondary.
When I use the log shipping wizard, and have it do the initial restore to
the secondary, all appears to work well but the database remains in
"(Restoring ...) in the Management Studio (MS) GUI. So after starting over
and manually restoring the database to the secondary, I used the wizard again
to set this up and now the Agent jobs indicate success in applying the logs
but again, the database continues to show as (Restoring ...) in the MS GUI.
It is indeed unavailable as you can't query it in a Query window. I tried
this with upgraded SQL 2000 databases and newly created SQL 2005 databases,
both with the same result.
Has anyone run into this and can you tell me what might be happening?
Hi
By default, you can not access the destination DB in a log shipping
partnership. It was the same in SQL Server 2000.
If you want to have read only access, subject to having your connections
dropped when the next log restore occurs,
you need to execute a restore with the additional parameter of "STANDBY =
{standby_file_name}".
This can not be done in the GUI.
What are you trying to achieve?
Regards
Mike Epprecht, Microsoft SQL Server MVP
Zurich, Switzerland
IM: mike@.epprecht.net
MVP Program: http://www.microsoft.com/mvp
Blog: http://www.msmvps.com/epprecht/
"Dlorbecki" <Dlorbecki@.discussions.microsoft.com> wrote in message
news:4262DE8E-343E-4C2C-B2D6-43A5D6A425A3@.microsoft.com...
> I've been playing with the SQL 2005 log shipping and have been running
> into a
> few problems.
> My system is configured on a virtual server with two instances of SQL
> 2005.
> The OS is Windows 2003. I'm shipping logs from the default instance to the
> named instance with the default having the primary database and the named,
> the secondary.
> When I use the log shipping wizard, and have it do the initial restore to
> the secondary, all appears to work well but the database remains in
> "(Restoring ...) in the Management Studio (MS) GUI. So after starting over
> and manually restoring the database to the secondary, I used the wizard
> again
> to set this up and now the Agent jobs indicate success in applying the
> logs
> but again, the database continues to show as (Restoring ...) in the MS
> GUI.
> It is indeed unavailable as you can't query it in a Query window. I tried
> this with upgraded SQL 2000 databases and newly created SQL 2005
> databases,
> both with the same result.
> Has anyone run into this and can you tell me what might be happening?
|||My goal was to have a readable database on the destination side that could be
accessible in case of failure of the primary database. I guess I'm ignorant
of a basic tenent of log shipping and for that I apologize. Apparently, the
process is working as it should be and I thank you for pointing that out. (I
never used log shipping in 2000 since we only have standard edition). I will
"read up" on the subject a bit more. Thanks much!
"Mike Epprecht (SQL MVP)" wrote:

> Hi
> By default, you can not access the destination DB in a log shipping
> partnership. It was the same in SQL Server 2000.
> If you want to have read only access, subject to having your connections
> dropped when the next log restore occurs,
> you need to execute a restore with the additional parameter of "STANDBY =
> {standby_file_name}".
> This can not be done in the GUI.
> What are you trying to achieve?
> Regards
> --
> Mike Epprecht, Microsoft SQL Server MVP
> Zurich, Switzerland
> IM: mike@.epprecht.net
> MVP Program: http://www.microsoft.com/mvp
> Blog: http://www.msmvps.com/epprecht/
> "Dlorbecki" <Dlorbecki@.discussions.microsoft.com> wrote in message
> news:4262DE8E-343E-4C2C-B2D6-43A5D6A425A3@.microsoft.com...
>
>

log shipping sql 2005 database remains in (restoring...) mode

I've been playing with the SQL 2005 log shipping and have been running into
a
few problems.
My system is configured on a virtual server with two instances of SQL 2005.
The OS is Windows 2003. I'm shipping logs from the default instance to the
named instance with the default having the primary database and the named,
the secondary.
When I use the log shipping wizard, and have it do the initial restore to
the secondary, all appears to work well but the database remains in
"(Restoring ...) in the Management Studio (MS) GUI. So after starting over
and manually restoring the database to the secondary, I used the wizard agai
n
to set this up and now the Agent jobs indicate success in applying the logs
but again, the database continues to show as (Restoring ...) in the MS GUI.
It is indeed unavailable as you can't query it in a Query window. I tried
this with upgraded SQL 2000 databases and newly created SQL 2005 databases,
both with the same result.
Has anyone run into this and can you tell me what might be happening?Hi
By default, you can not access the destination DB in a log shipping
partnership. It was the same in SQL Server 2000.
If you want to have read only access, subject to having your connections
dropped when the next log restore occurs,
you need to execute a restore with the additional parameter of "STANDBY =
{standby_file_name}".
This can not be done in the GUI.
What are you trying to achieve?
Regards
--
Mike Epprecht, Microsoft SQL Server MVP
Zurich, Switzerland
IM: mike@.epprecht.net
MVP Program: http://www.microsoft.com/mvp
Blog: http://www.msmvps.com/epprecht/
"Dlorbecki" <Dlorbecki@.discussions.microsoft.com> wrote in message
news:4262DE8E-343E-4C2C-B2D6-43A5D6A425A3@.microsoft.com...
> I've been playing with the SQL 2005 log shipping and have been running
> into a
> few problems.
> My system is configured on a virtual server with two instances of SQL
> 2005.
> The OS is Windows 2003. I'm shipping logs from the default instance to the
> named instance with the default having the primary database and the named,
> the secondary.
> When I use the log shipping wizard, and have it do the initial restore to
> the secondary, all appears to work well but the database remains in
> "(Restoring ...) in the Management Studio (MS) GUI. So after starting over
> and manually restoring the database to the secondary, I used the wizard
> again
> to set this up and now the Agent jobs indicate success in applying the
> logs
> but again, the database continues to show as (Restoring ...) in the MS
> GUI.
> It is indeed unavailable as you can't query it in a Query window. I tried
> this with upgraded SQL 2000 databases and newly created SQL 2005
> databases,
> both with the same result.
> Has anyone run into this and can you tell me what might be happening?|||My goal was to have a readable database on the destination side that could b
e
accessible in case of failure of the primary database. I guess I'm ignorant
of a basic tenent of log shipping and for that I apologize. Apparently, the
process is working as it should be and I thank you for pointing that out. (
I
never used log shipping in 2000 since we only have standard edition). I wil
l
"read up" on the subject a bit more. Thanks much!
"Mike Epprecht (SQL MVP)" wrote:

> Hi
> By default, you can not access the destination DB in a log shipping
> partnership. It was the same in SQL Server 2000.
> If you want to have read only access, subject to having your connections
> dropped when the next log restore occurs,
> you need to execute a restore with the additional parameter of "STANDBY =
> {standby_file_name}".
> This can not be done in the GUI.
> What are you trying to achieve?
> Regards
> --
> Mike Epprecht, Microsoft SQL Server MVP
> Zurich, Switzerland
> IM: mike@.epprecht.net
> MVP Program: http://www.microsoft.com/mvp
> Blog: http://www.msmvps.com/epprecht/
> "Dlorbecki" <Dlorbecki@.discussions.microsoft.com> wrote in message
> news:4262DE8E-343E-4C2C-B2D6-43A5D6A425A3@.microsoft.com...
>
>

log shipping sql 2005 database remains in (restoring...) mode

I've been playing with the SQL 2005 log shipping and have been running into a
few problems.
My system is configured on a virtual server with two instances of SQL 2005.
The OS is Windows 2003. I'm shipping logs from the default instance to the
named instance with the default having the primary database and the named,
the secondary.
When I use the log shipping wizard, and have it do the initial restore to
the secondary, all appears to work well but the database remains in
"(Restoring ...) in the Management Studio (MS) GUI. So after starting over
and manually restoring the database to the secondary, I used the wizard again
to set this up and now the Agent jobs indicate success in applying the logs
but again, the database continues to show as (Restoring ...) in the MS GUI.
It is indeed unavailable as you can't query it in a Query window. I tried
this with upgraded SQL 2000 databases and newly created SQL 2005 databases,
both with the same result.
Has anyone run into this and can you tell me what might be happening?Hi
By default, you can not access the destination DB in a log shipping
partnership. It was the same in SQL Server 2000.
If you want to have read only access, subject to having your connections
dropped when the next log restore occurs,
you need to execute a restore with the additional parameter of "STANDBY ={standby_file_name}".
This can not be done in the GUI.
What are you trying to achieve?
Regards
--
Mike Epprecht, Microsoft SQL Server MVP
Zurich, Switzerland
IM: mike@.epprecht.net
MVP Program: http://www.microsoft.com/mvp
Blog: http://www.msmvps.com/epprecht/
"Dlorbecki" <Dlorbecki@.discussions.microsoft.com> wrote in message
news:4262DE8E-343E-4C2C-B2D6-43A5D6A425A3@.microsoft.com...
> I've been playing with the SQL 2005 log shipping and have been running
> into a
> few problems.
> My system is configured on a virtual server with two instances of SQL
> 2005.
> The OS is Windows 2003. I'm shipping logs from the default instance to the
> named instance with the default having the primary database and the named,
> the secondary.
> When I use the log shipping wizard, and have it do the initial restore to
> the secondary, all appears to work well but the database remains in
> "(Restoring ...) in the Management Studio (MS) GUI. So after starting over
> and manually restoring the database to the secondary, I used the wizard
> again
> to set this up and now the Agent jobs indicate success in applying the
> logs
> but again, the database continues to show as (Restoring ...) in the MS
> GUI.
> It is indeed unavailable as you can't query it in a Query window. I tried
> this with upgraded SQL 2000 databases and newly created SQL 2005
> databases,
> both with the same result.
> Has anyone run into this and can you tell me what might be happening?|||My goal was to have a readable database on the destination side that could be
accessible in case of failure of the primary database. I guess I'm ignorant
of a basic tenent of log shipping and for that I apologize. Apparently, the
process is working as it should be and I thank you for pointing that out. (I
never used log shipping in 2000 since we only have standard edition). I will
"read up" on the subject a bit more. Thanks much!
"Mike Epprecht (SQL MVP)" wrote:
> Hi
> By default, you can not access the destination DB in a log shipping
> partnership. It was the same in SQL Server 2000.
> If you want to have read only access, subject to having your connections
> dropped when the next log restore occurs,
> you need to execute a restore with the additional parameter of "STANDBY => {standby_file_name}".
> This can not be done in the GUI.
> What are you trying to achieve?
> Regards
> --
> Mike Epprecht, Microsoft SQL Server MVP
> Zurich, Switzerland
> IM: mike@.epprecht.net
> MVP Program: http://www.microsoft.com/mvp
> Blog: http://www.msmvps.com/epprecht/
> "Dlorbecki" <Dlorbecki@.discussions.microsoft.com> wrote in message
> news:4262DE8E-343E-4C2C-B2D6-43A5D6A425A3@.microsoft.com...
> > I've been playing with the SQL 2005 log shipping and have been running
> > into a
> > few problems.
> >
> > My system is configured on a virtual server with two instances of SQL
> > 2005.
> > The OS is Windows 2003. I'm shipping logs from the default instance to the
> > named instance with the default having the primary database and the named,
> > the secondary.
> >
> > When I use the log shipping wizard, and have it do the initial restore to
> > the secondary, all appears to work well but the database remains in
> > "(Restoring ...) in the Management Studio (MS) GUI. So after starting over
> > and manually restoring the database to the secondary, I used the wizard
> > again
> > to set this up and now the Agent jobs indicate success in applying the
> > logs
> > but again, the database continues to show as (Restoring ...) in the MS
> > GUI.
> > It is indeed unavailable as you can't query it in a Query window. I tried
> > this with upgraded SQL 2000 databases and newly created SQL 2005
> > databases,
> > both with the same result.
> >
> > Has anyone run into this and can you tell me what might be happening?
>
>

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

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

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

Wednesday, March 7, 2012

Log Shipping between SQL Server versions

Is it possible to perform log shipping between a server running SQL 2000
Enterprise and another server running SQL 2005 Enterprise?What would be the purpose of the secondary database?
Since you can restore SQL Server 2000 databases into SQL Server 2005
technically you can do log shipping to SQL Server 2005. But the opposite is
not possible because you can not restore SQL Server 2005 databases into SQL
Server 2000.
So, if you lose your SQL Server 2000 database and you only have the 2005
database. Do you plan to continue with 2005 only?
Ben Nevarez
Senior Database Administrator
"KnightFall1" wrote:
> Is it possible to perform log shipping between a server running SQL 2000
> Enterprise and another server running SQL 2005 Enterprise?|||Hi Ben,
The original question relates to a work situation where we have a SQL 2000
Enterprise production database that needs to be replicated (for reporting
purposes) to an environment that has SQL 2005 running.
So I was curious if we could perform log shipping between the 2 servers to
replicate the database (assuming this is supported between these 2 versions
of SQL Server). This also brings up the question about whether transactional
replication is permitted between SQL 2000 and SQL 2005.
"Ben Nevarez" wrote:
> What would be the purpose of the secondary database?
> Since you can restore SQL Server 2000 databases into SQL Server 2005
> technically you can do log shipping to SQL Server 2005. But the opposite is
> not possible because you can not restore SQL Server 2005 databases into SQL
> Server 2000.
> So, if you lose your SQL Server 2000 database and you only have the 2005
> database. Do you plan to continue with 2005 only?
> Ben Nevarez
> Senior Database Administrator
>
> "KnightFall1" wrote:
> > Is it possible to perform log shipping between a server running SQL 2000
> > Enterprise and another server running SQL 2005 Enterprise?|||You say that you want to use the Secondary Server (in Log Shipping) for
reporting purposes. Then you should set its recovery state as STANDBY to
query against it. However then your users will be disconnected for the
coming Transaction Log to be applied to your Secondary Server. So your users
would experience disconnections.
--
Ekrem Ã?nsoy
"KnightFall1" <KnightFall1@.discussions.microsoft.com> wrote in message
news:C8170C24-90E5-47C6-ABA0-5139B920FB1C@.microsoft.com...
> Hi Ben,
> The original question relates to a work situation where we have a SQL 2000
> Enterprise production database that needs to be replicated (for reporting
> purposes) to an environment that has SQL 2005 running.
> So I was curious if we could perform log shipping between the 2 servers to
> replicate the database (assuming this is supported between these 2
> versions
> of SQL Server). This also brings up the question about whether
> transactional
> replication is permitted between SQL 2000 and SQL 2005.
> "Ben Nevarez" wrote:
>> What would be the purpose of the secondary database?
>> Since you can restore SQL Server 2000 databases into SQL Server 2005
>> technically you can do log shipping to SQL Server 2005. But the opposite
>> is
>> not possible because you can not restore SQL Server 2005 databases into
>> SQL
>> Server 2000.
>> So, if you lose your SQL Server 2000 database and you only have the 2005
>> database. Do you plan to continue with 2005 only?
>> Ben Nevarez
>> Senior Database Administrator
>>
>> "KnightFall1" wrote:
>> > Is it possible to perform log shipping between a server running SQL
>> > 2000
>> > Enterprise and another server running SQL 2005 Enterprise?|||Hi Ekrem,
The log shipping will be on a set schedule. Currently the business
requirement is once a day (we are still in the process of establishing a
specific time of day) for this process. So even if there is a disconnection,
the users on that end will know when the log shipping is occurring, so there
shouldn't be a problem.
Wouldn't you agree?
"Ekrem Ã?nsoy" wrote:
> You say that you want to use the Secondary Server (in Log Shipping) for
> reporting purposes. Then you should set its recovery state as STANDBY to
> query against it. However then your users will be disconnected for the
> coming Transaction Log to be applied to your Secondary Server. So your users
> would experience disconnections.
> --
> Ekrem Ã?nsoy
>
> "KnightFall1" <KnightFall1@.discussions.microsoft.com> wrote in message
> news:C8170C24-90E5-47C6-ABA0-5139B920FB1C@.microsoft.com...
> > Hi Ben,
> >
> > The original question relates to a work situation where we have a SQL 2000
> > Enterprise production database that needs to be replicated (for reporting
> > purposes) to an environment that has SQL 2005 running.
> >
> > So I was curious if we could perform log shipping between the 2 servers to
> > replicate the database (assuming this is supported between these 2
> > versions
> > of SQL Server). This also brings up the question about whether
> > transactional
> > replication is permitted between SQL 2000 and SQL 2005.
> >
> > "Ben Nevarez" wrote:
> >
> >>
> >> What would be the purpose of the secondary database?
> >>
> >> Since you can restore SQL Server 2000 databases into SQL Server 2005
> >> technically you can do log shipping to SQL Server 2005. But the opposite
> >> is
> >> not possible because you can not restore SQL Server 2005 databases into
> >> SQL
> >> Server 2000.
> >>
> >> So, if you lose your SQL Server 2000 database and you only have the 2005
> >> database. Do you plan to continue with 2005 only?
> >>
> >> Ben Nevarez
> >> Senior Database Administrator
> >>
> >>
> >>
> >> "KnightFall1" wrote:
> >>
> >> > Is it possible to perform log shipping between a server running SQL
> >> > 2000
> >> > Enterprise and another server running SQL 2005 Enterprise?
>|||Then your users would be querying a database which is older between 0-24
hours than the original one.
If this would not make any trouble and if you set up the Restore job (on the
Secondary Server) to start at a time when your users would be asleep then I
don't think there would be any problem with this setup.
P.S.
You know that your users will be able to use only SELECT against your
Secondary Database right? I just wanted to be sure you know about this.
--
Ekrem Ã?nsoy
"KnightFall1" <KnightFall1@.discussions.microsoft.com> wrote in message
news:1F9B7D48-BCC2-4086-8CC5-CE2E01DE9959@.microsoft.com...
> Hi Ekrem,
> The log shipping will be on a set schedule. Currently the business
> requirement is once a day (we are still in the process of establishing a
> specific time of day) for this process. So even if there is a
> disconnection,
> the users on that end will know when the log shipping is occurring, so
> there
> shouldn't be a problem.
> Wouldn't you agree?
>
> "Ekrem Ã?nsoy" wrote:
>> You say that you want to use the Secondary Server (in Log Shipping) for
>> reporting purposes. Then you should set its recovery state as STANDBY to
>> query against it. However then your users will be disconnected for the
>> coming Transaction Log to be applied to your Secondary Server. So your
>> users
>> would experience disconnections.
>> --
>> Ekrem Ã?nsoy
>>
>> "KnightFall1" <KnightFall1@.discussions.microsoft.com> wrote in message
>> news:C8170C24-90E5-47C6-ABA0-5139B920FB1C@.microsoft.com...
>> > Hi Ben,
>> >
>> > The original question relates to a work situation where we have a SQL
>> > 2000
>> > Enterprise production database that needs to be replicated (for
>> > reporting
>> > purposes) to an environment that has SQL 2005 running.
>> >
>> > So I was curious if we could perform log shipping between the 2 servers
>> > to
>> > replicate the database (assuming this is supported between these 2
>> > versions
>> > of SQL Server). This also brings up the question about whether
>> > transactional
>> > replication is permitted between SQL 2000 and SQL 2005.
>> >
>> > "Ben Nevarez" wrote:
>> >
>> >>
>> >> What would be the purpose of the secondary database?
>> >>
>> >> Since you can restore SQL Server 2000 databases into SQL Server 2005
>> >> technically you can do log shipping to SQL Server 2005. But the
>> >> opposite
>> >> is
>> >> not possible because you can not restore SQL Server 2005 databases
>> >> into
>> >> SQL
>> >> Server 2000.
>> >>
>> >> So, if you lose your SQL Server 2000 database and you only have the
>> >> 2005
>> >> database. Do you plan to continue with 2005 only?
>> >>
>> >> Ben Nevarez
>> >> Senior Database Administrator
>> >>
>> >>
>> >>
>> >> "KnightFall1" wrote:
>> >>
>> >> > Is it possible to perform log shipping between a server running SQL
>> >> > 2000
>> >> > Enterprise and another server running SQL 2005 Enterprise?
>>

Friday, March 30, 2012

Log Shipping with clustered database.

Log Shipping with clustered database.

Log Shipping with clustered database.

Log Shipping using SQL Server Standard

Log Shipping Transaction Logs.

Wednesday, March 28, 2012

Log Shipping to old box?

Log shipping to DR env

Log shipping to DR env

Log shipping to DR env

Log shipping sync error 14421

Log shipping sync error 14421

Log shipping sync error 14421

log shipping sql 2005 database remains in (restoring...) mode

log shipping sql 2005 database remains in (restoring...) mode

log shipping sql 2005 database remains in (restoring...) mode

Monday, March 26, 2012

Log Shipping Restore Error 3456

Log Shipping Restore Error 3456

Log Shipping Restore Error 3456

Wednesday, March 7, 2012

Log Shipping between SQL Server versions

Log Shipping between SQL Server versions

Log shipping alerts

Blog Archive

About Me