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

We're implementing log shipping and have run into problems
when we attempt to reverse server roles.
The error occurs when we run the sp_change_secondary_role.
We receive a "sqlmaint.exe" error. If the stored procedure
is run 3 or 4 times it will occasionally succeed but the
role reversal is not successful even then.
Has anyone had any experience with this?
Thanks,
JohnKen,
See the KB article 294397 BUG: sp_change_secondary_role Fails with Error
3101 if There Are Outstanding Transaction Log Backups
http://support.microsoft.com/defaul...7&Product=sql2k
This is similar, though not identical, to the error you are getting. The
upshot is that you need to make sure that all the transaction logs have been
restored if you set the @.terminate parameter to 1.
Hope this helps,
Ron
--
Ron Talmage
SQL Server MVP
"kmkrause2" <kmkrause2@.discussions.microsoft.com> wrote in message
news:733456B1-BC99-43B2-B6BD-4030A08DB6EC@.microsoft.com...
> I have log shipping configured on a pair of test SQL 2000 servers, both
are
> at SP3. The log shipping is working fine, but the problem occurs when I
try
> to reverse roles. I run this SQL statement on the primary server:
> USE master
> GO
> EXEC msdb.dbo.sp_change_primary_role
> @.db_name = 'ModelCopy',
> @.backup_log = 1,
> @.terminate = 1,
> @.final_state = 3,
> @.access_level = 1
> This places the primary database into read-only mode. I then run this SQL
> statement on the secondary server.
> USE master
> GO
> EXEC msdb.dbo.sp_change_secondary_role
> @.db_name = 'ModelCopy',
> @.do_load = 1,
> @.force_load = 1,
> @.final_state = 1,
> @.access_level = 1,
> @.terminate = 1,
> @.keep_replication = 0,
> @.stopat = null
> At which time I get this error:
> Server: Msg 927, Level 14, State 2, Line 1
> Database 'ModelCopy' cannot be opened. It is in the middle of a restore.
> Server: Msg 5069, Level 16, State 1, Line 1
> ALTER DATABASE statement failed.
> Server: Msg 14440, Level 16, State 1, Procedure sp_change_secondary_role,
> Line 49
> Could not set single user mode.
> In each case, I am runnig the statements in Query Analyzer with the
> Enterprise Manager window closed. I understand that these statements cause
> the primary to make a final copy and the secondary to do a final restore,
but
> the database I'm using is very small (a copy of the Model databae) and
> shouldn't take but a few seconds, which is all the time it took to create
and
> initialize the database on the secondary to begin with. Is this process
hung,
> or am I just being impatient? It's been over 20 minutes.
> TIA,
> Ken|||Thanks for the info Ron. It pointed me in the right direction. I still neede
d
to to a detach/attach sequesnce on the database before running the secondary
stored procedure, but at least it is working in a predictable manner now.
"Ron Talmage" wrote:

> Ken,
> See the KB article 294397 BUG: sp_change_secondary_role Fails with Error
> 3101 if There Are Outstanding Transaction Log Backups
> [url]http://support.microsoft.com/default.aspx?scid=kb;en-us;294397&Product=sql2k[/ur
l]
> This is similar, though not identical, to the error you are getting. The
> upshot is that you need to make sure that all the transaction logs have be
en
> restored if you set the @.terminate parameter to 1.
> Hope this helps,
> Ron
> --
> Ron Talmage
> SQL Server MVP
> "kmkrause2" <kmkrause2@.discussions.microsoft.com> wrote in message
> news:733456B1-BC99-43B2-B6BD-4030A08DB6EC@.microsoft.com...
> are
> try
> but
> and
> hung,
>
>|||OK, I spoke too soon. Occasionally, the sp_change_secondary_role procedure
will end with a "sqlmaint.exe failed. [SQLSTATE 42000][Error 22029].
The step
failed." message. I haven't been able to find any helpful information on thi
s
message yet. Can you shed some more light on what is happening during this
procedure? Same scripts as posted previously in this thread, and include the
manual running of the restore job and a database detach/attach sequence in
Enterprise Manager immediately prior to running the secondary role change
stpred procedure.
Thanks Again,
Ken
"kmkrause2" wrote:
[vbcol=seagreen]
> Thanks for the info Ron. It pointed me in the right direction. I still nee
ded
> to to a detach/attach sequesnce on the database before running the seconda
ry
> stored procedure, but at least it is working in a predictable manner now.
> "Ron Talmage" wrote:
>

Log Shipping Restore Failing

**PLEASE help. Restore of Log Shippng is failing**
Job error is: sqlmaint.exe failed. [SQLSTATE 42000] (Error 22029). The step failed.
Detailed output of the job says: [Microsoft SQL-DMO (ODBC SQLState: 42000)] Error 4305: [Microsoft][ODBC SQL Server Driver][SQL Server]The log in this backup set begins at LSN 31433000001386500001, which is too late to apply to the database. An earlier lo
g backup that includes LSN 314320
00002000300001 can be restored.[Microsoft][ODBC SQL Server Driver][SQL Server]RESTORE LOG is terminating abnormally. (null) [Microsoft SQL-DMO (ODBC SQLState: 42000)] Error 4305: [Microsoft][ODBC SQL Server Driver][SQL Server]The log in this backup set be
gins at LSN 31433000001386500001, which is too late to apply to the database. An earlier log backup that includes LSN 31432000002000300001 can be restored. [Microsoft][ODBC SQL Server Driver][SQL Server]RESTORE LOG is terminating abnormally.(null) [Micros
oft SQL-DMO (ODBC SQLState: 42000)] Error 3201: [Microsoft][ODBC SQL Server Driver][SQL Server]Cannot open backup device 'D:\SHIPPEDLOGS\LVBOEProd_tlog_200406272345.TRN'. Device error or device off-line. See the SQL Server error log for more details.[Micr
osoft][ODBC SQL Server Driver][SQL Server]RESTORE LOG is terminating abnormally.(null Loaded 0 files
**All of my shares/directories are correct. I have tried this at least a dozen times. It was successfull the 1st time the restore ran, but after that it has failed every time.
VC,
have a look at your chain of log backups and the log-shipping monitor. See
if you have any logs before 27th June 11:45pm which haven't been transfered
and/or restored. Manually restoring these 'missing' logs then restarting the
logshipping job should fix the problem.
HTH,
Paul Ibison
|||Paul, thank you very much for your reply. this is very important that i get this working ASAP. i have been fighting this day in and day out.
i re-did the log shipping and it's the same problem. do you have an email account that i can email the log to. it has been appending since the 1st restore. you can email me at v_c@.hotmail.com and i'll reply with the log.
there are no files earlier than the 1st file. in fact, this time around, it was successful.
|||VC,
no need to send over the log - it won't help me solve your issue.
I suspect that someone inadvertantly truncated the transaction log before
the first backup and hence the log sequence numbers were out of sync.
Alternatively it could be that the databases themselves were initially out
of sync. You could use LogExplorer (even the evaluation edn) to test if the
former is the case - to see if there are some records missing from the log.
Still, if it's running OK now then fine.
Regards,
Paul Ibison
|||VC,
no need to send over the log - it won't help me solve your issue.
I suspect that someone inadvertantly truncated the transaction log before
the first backup and hence the log sequence numbers were out of sync.
Alternatively it could be that the databases themselves were initially out
of sync. You could use LogExplorer (even the evaluation edn) to test if the
former is the case - to see if there are some records missing from the log.
Still, if it's running OK now then fine.
Regards,
Paul Ibison
|||i was doing this all night, like 2 in the morning. i doubt anyone was truncating logs. however, this is a good suspicion. any other ideas how the log could have gotten truncated?
|||i was doing this all night, like 2 in the morning. i doubt anyone was truncating logs. however, this is a good suspicion. any other ideas how the log could have gotten truncated?
|||2am - and I thought I worked too long hours ;-)
No other ideas really about how else your log got truncated.
I'd check out the transaction log using a 3rd party tool to try to make
sense of it.
Regards,
Paul Ibison
|||2am - and I thought I worked too long hours ;-)
No other ideas really about how else your log got truncated.
I'd check out the transaction log using a 3rd party tool to try to make
sense of it.
Regards,
Paul Ibison

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

Log Shipping question

Hi!
I managed to make a plan of log shipping and have some questions.
In the first trn back up I recieved an error
[Microsoft SQL-DMO (ODBC SQLState: 42000)] Error 3201: [Microsoft][ODBC SQL
Server Driver][SQL Server]Cannot open backup device
'D:\logshipping\Pergam2_tlog_200312250945.TRN'. Device error or device
off-line. See the SQL Server error log for more details.
[Microsoft][ODBC SQL Server Driver][SQL Server]RESTORE LOG is terminating
abnormally.
All other back ups are fine and databases seeens to be identical. But Log
shipping monitor shows out of sync ?!!!
What it can be?
if backup/restore or restore fails what will be with databases in the next
step when all will work fine?
Thanks
DmitryI have seen messages like this sometimes on our log
shipping installation too. I believe Sql Server sometimes
starts reading the log files even before they have been
completely transferred. This seems to be best ignored. Set
your monitor to a higher out of sync value.
If the databases get out of sync, the best way is to back
up and restore them and restart log shipping.
>--Original Message--
>Hi!
>I managed to make a plan of log shipping and have some
questions.
>In the first trn back up I recieved an error
>[Microsoft SQL-DMO (ODBC SQLState: 42000)] Error 3201:
[Microsoft][ODBC SQL
>Server Driver][SQL Server]Cannot open backup device
>'D:\logshipping\Pergam2_tlog_200312250945.TRN'. Device
error or device
>off-line. See the SQL Server error log for more details.
>[Microsoft][ODBC SQL Server Driver][SQL Server]RESTORE
LOG is terminating
>abnormally.
>All other back ups are fine and databases seeens to be
identical. But Log
>shipping monitor shows out of sync ?!!!
>What it can be?
>if backup/restore or restore fails what will be with
databases in the next
>step when all will work fine?
>Thanks
>Dmitry
>
>.
>

Log Shipping Problem

I've installed log shipping, it was working very fine but since last 2 days
it is givving this type error as given below. Anyone plz help me it's urgent
and in this scenario what should I do
[Microsoft SQL-DMO (ODBC SQLState: 42000)] Error 4305: [Microsoft]&#
91;ODBC SQL Server Driver][SQL Server]The log in this backup set begins
at LSN 589000000013600001, which is too late to apply to the database. An ea
rlier log backup that includes LSN 58900000
0011700001 can be restored.
[Microsoft][ODBC SQL Server Driver][SQL Server]RESTORE LOG is te
rminating abnormally.
Thanks in advance and Regards,
SunilSunil
How do you implement the log shipping?
Do you perform BACKUP LOG withinit OPTION and then RESTORE it.
It seems you have lost a consistency (brocken a chain) of the database.
drop database test
go
create database test
GO
Alter database set recovery full
create table test..test(id int identity)
insert test..test default values
backup database test to disk = 'd:\db.bak' WITH INIT
insert test..test default values
backup log test to disk = 'd:\log.bak'WITH INIT
insert test..test default values
backup log test to disk = 'd:\log.bak' WITH INIT
GO
RESTORE DATABASE test FROM disk = 'd:\db.bak' WITH FILE = 1, norecovery
RESTORE LOG test FROM disk = 'd:\log.bak' WITH recovery
GO
After running tthis script you supposed to get the same error.
"Sunil" <anonymous@.discussions.microsoft.com> wrote in message
news:61F86E7E-5F98-4582-8740-AF5DE5F31000@.microsoft.com...
> I've installed log shipping, it was working very fine but since last 2
days it is givving this type error as given below. Anyone plz help me it's
urgent and in this scenario what should I do
>
>
> [Microsoft SQL-DMO (ODBC SQLState: 42000)] Error 4305: [Microsoft][ODB
C
SQL Server Driver][SQL Server]The log in this backup set begins at LSN
589000000013600001, which is too late to apply to the database. An earlier
log backup that includes LSN 589000000011700001 can be restored.
> [Microsoft][ODBC SQL Server Driver][SQL Server]RESTORE LOG is terminat
ing
abnormally.
>
> Thanks in advance and Regards,
>
> Sunil

log shipping monitor report error

I have SQL Server 2005 log shipping setup with primary/secondary configuration. I can confirm from the logs that log shipping is working without issue, however, reports generated from the monitor server show this message:

Violation of PRIMARY KEY constraint 'PK__#log_shipping_mo__3ABBDC91'. Cannot insert duplicate key in object 'dbo.#log_shipping_monitor'. The statement has been terminated.

There is nothing special about the configuration. Any ideas?

Clear out the log on Log shipping monitor and ensure the log shipping is working properly on secondary server too.|||Log shipping is working properly on the secondary server. The error is generated when I try to view the Log Shipping Status report on the secondary server. The monitor server instance is also throwing incorrect alerts.|||

I think the problem you are seeing is related to some old information being present in the tables used to store log shipping configuration. There are some scenarios where this can happen and it causes the problem you reported in your first post. We are working on correcting this in a future release.

As you can tell from the error, the problem is caused by an insert to a temp table causing a PK constraint violation. The PK for the temp table is server name and database name. This error is normally caused by old configuration being present in the tables log_shipping_monitor_primary and/or log_shipping_monitor_secondary. You can view the contents of these tables directly (in msdb) or use some supplied help SP's (see BOL topic titled "Log Shipping Tables and Stored Procedures").

The workaround is to remove the old rows from log_shipping_monitor_primary and/or log_shipping_monitor_secondary tables. Can you determine that you do indeed have stale data in the log shipping tables. If this is the case I can work with you on how to remove the old rows.

The old configuration data is probably causing the incorrect alerts you are seeing.

|||

Hi, Is that possible for you to show how to delete the old data in the tables log_shipping_monitor_primary and/or log_shipping_monitor_secondary.

Thank you

|||

Hi Mark,

I am getting a similar error when I try to run the report on the primary server. The report on the secondary server which is also the monitor runs fine.

I queried the tables mentioned by you and got one row in each. FYI, I have only one DB on the primary server being log shipped to the secondary.

For,

select * from dbo.log_shipping_monitor_secondary

I am geeting null values for last_copied_file, last_copied_date, last_copied_date_utc and last restored_file. However, I know that the log shipping is working well for the database.

So How do I go about correcting the report? Should I delete the row in log_shipping_monitor_secondary? In log_shipping_monitor_primary the information is up to date and correct.

Thanks in anticipation.

Amit

sql

log shipping monitor report error

I have SQL Server 2005 log shipping setup with primary/secondary configuration. I can confirm from the logs that log shipping is working without issue, however, reports generated from the monitor server show this message:

Violation of PRIMARY KEY constraint 'PK__#log_shipping_mo__3ABBDC91'. Cannot insert duplicate key in object 'dbo.#log_shipping_monitor'. The statement has been terminated.

There is nothing special about the configuration. Any ideas?

Clear out the log on Log shipping monitor and ensure the log shipping is working properly on secondary server too.|||Log shipping is working properly on the secondary server. The error is generated when I try to view the Log Shipping Status report on the secondary server. The monitor server instance is also throwing incorrect alerts.|||

I think the problem you are seeing is related to some old information being present in the tables used to store log shipping configuration. There are some scenarios where this can happen and it causes the problem you reported in your first post. We are working on correcting this in a future release.

As you can tell from the error, the problem is caused by an insert to a temp table causing a PK constraint violation. The PK for the temp table is server name and database name. This error is normally caused by old configuration being present in the tables log_shipping_monitor_primary and/or log_shipping_monitor_secondary. You can view the contents of these tables directly (in msdb) or use some supplied help SP's (see BOL topic titled "Log Shipping Tables and Stored Procedures").

The workaround is to remove the old rows from log_shipping_monitor_primary and/or log_shipping_monitor_secondary tables. Can you determine that you do indeed have stale data in the log shipping tables. If this is the case I can work with you on how to remove the old rows.

The old configuration data is probably causing the incorrect alerts you are seeing.

|||

Hi, Is that possible for you to show how to delete the old data in the tables log_shipping_monitor_primary and/or log_shipping_monitor_secondary.

Thank you

|||

Hi Mark,

I am getting a similar error when I try to run the report on the primary server. The report on the secondary server which is also the monitor runs fine.

I queried the tables mentioned by you and got one row in each. FYI, I have only one DB on the primary server being log shipped to the secondary.

For,

select * from dbo.log_shipping_monitor_secondary

I am geeting null values for last_copied_file, last_copied_date, last_copied_date_utc and last restored_file. However, I know that the log shipping is working well for the database.

So How do I go about correcting the report? Should I delete the row in log_shipping_monitor_secondary? In log_shipping_monitor_primary the information is up to date and correct.

Thanks in anticipation.

Amit

log shipping monitor report error

I have SQL Server 2005 log shipping setup with primary/secondary configuration. I can confirm from the logs that log shipping is working without issue, however, reports generated from the monitor server show this message:

Violation of PRIMARY KEY constraint 'PK__#log_shipping_mo__3ABBDC91'. Cannot insert duplicate key in object 'dbo.#log_shipping_monitor'. The statement has been terminated.

There is nothing special about the configuration. Any ideas?

Clear out the log on Log shipping monitor and ensure the log shipping is working properly on secondary server too.|||Log shipping is working properly on the secondary server. The error is generated when I try to view the Log Shipping Status report on the secondary server. The monitor server instance is also throwing incorrect alerts.|||

I think the problem you are seeing is related to some old information being present in the tables used to store log shipping configuration. There are some scenarios where this can happen and it causes the problem you reported in your first post. We are working on correcting this in a future release.

As you can tell from the error, the problem is caused by an insert to a temp table causing a PK constraint violation. The PK for the temp table is server name and database name. This error is normally caused by old configuration being present in the tables log_shipping_monitor_primary and/or log_shipping_monitor_secondary. You can view the contents of these tables directly (in msdb) or use some supplied help SP's (see BOL topic titled "Log Shipping Tables and Stored Procedures").

The workaround is to remove the old rows from log_shipping_monitor_primary and/or log_shipping_monitor_secondary tables. Can you determine that you do indeed have stale data in the log shipping tables. If this is the case I can work with you on how to remove the old rows.

The old configuration data is probably causing the incorrect alerts you are seeing.

|||

Hi, Is that possible for you to show how to delete the old data in the tables log_shipping_monitor_primary and/or log_shipping_monitor_secondary.

Thank you

|||

Hi Mark,

I am getting a similar error when I try to run the report on the primary server. The report on the secondary server which is also the monitor runs fine.

I queried the tables mentioned by you and got one row in each. FYI, I have only one DB on the primary server being log shipped to the secondary.

For,

select * from dbo.log_shipping_monitor_secondary

I am geeting null values for last_copied_file, last_copied_date, last_copied_date_utc and last restored_file. However, I know that the log shipping is working well for the database.

So How do I go about correcting the report? Should I delete the row in log_shipping_monitor_secondary? In log_shipping_monitor_primary the information is up to date and correct.

Thanks in anticipation.

Amit

log shipping monitor report error

I have SQL Server 2005 log shipping setup with primary/secondary configuration. I can confirm from the logs that log shipping is working without issue, however, reports generated from the monitor server show this message:

Violation of PRIMARY KEY constraint 'PK__#log_shipping_mo__3ABBDC91'. Cannot insert duplicate key in object 'dbo.#log_shipping_monitor'. The statement has been terminated.

There is nothing special about the configuration. Any ideas?

Clear out the log on Log shipping monitor and ensure the log shipping is working properly on secondary server too.|||Log shipping is working properly on the secondary server. The error is generated when I try to view the Log Shipping Status report on the secondary server. The monitor server instance is also throwing incorrect alerts.|||

I think the problem you are seeing is related to some old information being present in the tables used to store log shipping configuration. There are some scenarios where this can happen and it causes the problem you reported in your first post. We are working on correcting this in a future release.

As you can tell from the error, the problem is caused by an insert to a temp table causing a PK constraint violation. The PK for the temp table is server name and database name. This error is normally caused by old configuration being present in the tables log_shipping_monitor_primary and/or log_shipping_monitor_secondary. You can view the contents of these tables directly (in msdb) or use some supplied help SP's (see BOL topic titled "Log Shipping Tables and Stored Procedures").

The workaround is to remove the old rows from log_shipping_monitor_primary and/or log_shipping_monitor_secondary tables. Can you determine that you do indeed have stale data in the log shipping tables. If this is the case I can work with you on how to remove the old rows.

The old configuration data is probably causing the incorrect alerts you are seeing.

|||

Hi, Is that possible for you to show how to delete the old data in the tables log_shipping_monitor_primary and/or log_shipping_monitor_secondary.

Thank you

|||

Hi Mark,

I am getting a similar error when I try to run the report on the primary server. The report on the secondary server which is also the monitor runs fine.

I queried the tables mentioned by you and got one row in each. FYI, I have only one DB on the primary server being log shipped to the secondary.

For,

select * from dbo.log_shipping_monitor_secondary

I am geeting null values for last_copied_file, last_copied_date, last_copied_date_utc and last restored_file. However, I know that the log shipping is working well for the database.

So How do I go about correcting the report? Should I delete the row in log_shipping_monitor_secondary? In log_shipping_monitor_primary the information is up to date and correct.

Thanks in anticipation.

Amit

Log Shipping Jobs please help us (Urgent need)

Hi,
When i am changing Log Shipping job owner in Monitor server, stand by server
and primary server, i am getting error as "Error 14269:Job 'Log shipping
alert job-backup' is already targetted at server. xxxxxx(SQL Instance) The
Job was not saved.
please advise how to chnage the Job owners, if we are getting these errors.
Thanks,
John
All, i am working with MS Support now for this error. we analyzed due to
sp_add_job and other related stored procedures does not take instance name
more than 30 chars (our servers have more than 30 chars).
so when ever we are setting up Log shipping or replication, shall we need
our SQL Intance should be lesthan 30 character? my friend is telling for
Oracle databases they dont have any problem with intance name length.
hope this scenario may help someone in future.
good lcuk to all, John
"John" wrote:

> Hi,
> When i am changing Log Shipping job owner in Monitor server, stand by server
> and primary server, i am getting error as "Error 14269:Job 'Log shipping
> alert job-backup' is already targetted at server. xxxxxx(SQL Instance) The
> Job was not saved.
> please advise how to chnage the Job owners, if we are getting these errors.
> Thanks,
> John
|||John,
You could create aliases with shorter names. Open the client network
utility and go to Aliases.
M

Log shipping fails the second time.

Log shipping fails the second time to restore 5Gb transactional log backup with the following error.

Error 823: [Microsoft][ODBC SQL Server Driver][SQL Server]I/O error (bad page ID)

detected during read at offset 0x000001f340e000 in file 'e:\program files\microsoft sql server\DBName.mdf'.

There is no hardware problem. The restore failed in a test server on the same step with the same error message.

The DBCC CHECKDB does not give any error message.

What it might be?

My guess is that the transaction log backup is corrupt and is laying down a full-page format log record (which contains a full page image) that has a corrupt page ID. Is the source database clean as far as CHECKDB is concerned?|||

CHECKDB does not give any error. The transactional backup got corrupted after indexes rebuild operation. It does not happen every time. Is there any way to check transactional backup integrity?

|||

yes its possible to check the integrity of a backup file.just refer this command......

Restore verifyonly from disk='Full path of your tran log file'.........it will check whether all the pages in the trn file are readable and also if the backup set is complete........

Log shipping fails the second time.

Log shipping fails the second time to restore 5Gb transactional log backup with the following error.

Error 823: [Microsoft][ODBC SQL Server Driver][SQL Server]I/O error (bad page ID)

detected during read at offset 0x000001f340e000 in file 'e:\program files\microsoft sql server\DBName.mdf'.

There is no hardware problem. The restore failed in a test server on the same step with the same error message.

The DBCC CHECKDB does not give any error message.

What it might be?

My guess is that the transaction log backup is corrupt and is laying down a full-page format log record (which contains a full page image) that has a corrupt page ID. Is the source database clean as far as CHECKDB is concerned?|||

CHECKDB does not give any error. The transactional backup got corrupted after indexes rebuild operation. It does not happen every time. Is there any way to check transactional backup integrity?

|||

yes its possible to check the integrity of a backup file.just refer this command......

Restore verifyonly from disk='Full path of your tran log file'.........it will check whether all the pages in the trn file are readable and also if the backup set is complete........

Log Shipping Error on SQL 2000 SP4

I'm attempting to configure log shipping on 2 servers with SQL Server 2000 sp4 Enterprise Edition. I keep getting the following error when the job attemtps to execute.

Error 14261: The specified primary_server_name.primary_database_name('C')
already exists.

I have tried this KB http://support.microsoft.com/kb/298743 and i got the same error again!

Please HELP!any hints ? :(|||Just a wild guess... Are you logshipping to the same instance or between to SQL instances? If the latter is the case, have you ran the MS solution on both instances? (just to be sure)

log shipping error message

hi,
We set up a log shipping job on our control server for one
of our sql servers and its fail-over server. We keep
getting these kind of job failures from time to time:
'The job failed. The Job was invoked by Schedule 12 (Log
Shipping Alert Job - Restore). The last step to run was
step 1 (Log Shipping Alert Job - Restore).
Executed as user: domainName\ControlServerName. The log
shipping destination fail_overServerName.databaseName is
out of sync by 30 minutes. [SQLSTATE 42000] (Error 14421)
Associated statement is not prepared [SQLSTATE HY007]
(Error 0). The step failed.'
What does this 'Associated statement is not prepared' mean?
many thanks.
JJJJ,
You might experience these symptoms if you configured primary or secondary
servers (or both) to connect to the monitor server by using SQL Server
Authentication on a computer that is running SQL Server 2000 Service Pack 2
(SP2)
To resolve this problem, obtain the latest service pack for Microsoft SQL
Server 2000.
SQL Server 2000 Service Pack 3a (SP3a) is available from the following
Microsoft Web site: http://www.microsoft.com/sql/downloads/2000/sp3.asp
To work around this problem, click the Use Windows Authentication option in
the Specify the Log Shipping Monitor Server Information dialog box during
log shipping Setup.
Background info for Error 14421 follows:
By definition, message 14421 does not necessarily indicate a problem with
Log Shipping. This message indicates that the difference between the last
backed up file and last restored file is greater than the time selected for
the Out of Sync Alert threshold.
There are serveral reasons why the alert message is raised. The following
list includes some of these reasons:
1.. The date or time (or both) on the primary server is modified such that
the date or time on the primary server is significantly ahead between
consecutive transaction log backups.
2.. The log shipping Restore job that is running on the secondary server
cannot connect to the monitor server msdb database to update the
log_shipping_secondaries table with the correct value. This may be the
result of an authentication problem between the secondary server and the
monitor server.
3.. You may have set an incorrect value for the Out of Sync Alert
threshold. Ideally, you must set this value to at least three times the
frequency of the slower of the Copy and Restore jobs. If the frequency of
the Copy or Restore jobs is modified after log shipping is set up and
functional, you must modify the value of the Out of Sync Alert threshold
accordingly.
4.. Problems either with the Backup job or Copy job are most likely to
result in "out of sync" alert messages. If "out of sync" alert messages are
raised and if there are no problems with the Backup or the Restore job,
check the Copy job for potential problems. Additionally, network
connectivity may cause the Copy job to fail.
5.. It is also possible that the Restore job on the secondary server is
failing. In this case, check the job history for the Restore job because it
may indicate a reason for the failure.
--
Keith Wilson
This posting is provided "AS IS" without express or implied warranty,
guarantee, or rights.
"JJ Wang" <anonymous@.discussions.microsoft.com> wrote in message
news:05b001c3b2f4$44286c10$a501280a@.phx.gbl...
> hi,
> We set up a log shipping job on our control server for one
> of our sql servers and its fail-over server. We keep
> getting these kind of job failures from time to time:
> 'The job failed. The Job was invoked by Schedule 12 (Log
> Shipping Alert Job - Restore). The last step to run was
> step 1 (Log Shipping Alert Job - Restore).
> Executed as user: domainName\ControlServerName. The log
> shipping destination fail_overServerName.databaseName is
> out of sync by 30 minutes. [SQLSTATE 42000] (Error 14421)
> Associated statement is not prepared [SQLSTATE HY007]
> (Error 0). The step failed.'
> What does this 'Associated statement is not prepared' mean?
> many thanks.
> JJ
>

Log Shipping ERROR HELP

Hi All

Can someone tell me what to do with this Error:

SQL Server Management Studio could not save the configuration of 'B1' as a Secondary.

ADDITIONAL INFORMATION:

An exception occurred while executing a Transact-SQL statement or batch. (Microsoft.SqlServer.ConnectionInfo)

The specified @.server_name (A1) does not exist.

The specified @.server_name (A1) does not exist.

The specified @.server_name (A1) does not exist. (Microsoft SQL Server, Error: 14262)

I have two sql 2005 servers A1 and B1 but the databases are setup with sql 2000 compatibility.

A1 service accounts use local system account.

B1 service accounts use domain system account.

I can easily restore a database from a shared folder on A1.

I followed this article to setup log shipping.

http://deepakinsql.blogspot.com/2007/06/how-to-configure-log-shipping-in-sql.html

did anyone come across this problem?

Hi,

Check SQL servername @. both the server. Run the below query and check whether the servername is A1 and B1.

Code Snippet

select @.@.servername

If A1 is not there in the first server then rename server to A1.

|||

As Vidhya said check the server name and try configuring log shipping using local system account for both the servers as in the given link

|||

THANKS GUYS.

IT WAS THE SERVER NAME PROBLEM.