December 12, 2017 at 9:25 am
Hi there,
Had a log shipment process implemented successfully since months for 5 databases from primary to secondary server
Everything worked fine untill last night where ls restore job failed on secondary server
The error occured is like could not redo log record for transaction id
due to which log files are not able to restore on the secondary database,
Any help on this to resolve would br more appreciated
December 12, 2017 at 1:20 pm
Hi, could you post the exact error message?
December 12, 2017 at 10:18 pm
*** Error: Could not apply log backup file '\\YYYYY\Log Shippment\Copy Log\ABC\ABC_20171211011000.trn' to secondary database 'ABC'.(Microsoft.SqlServer.Management.LogShipping) ***
2017-12-11 07:44:39.26 *** Error: Could not redo log record (4498040:1556446:222), for transaction ID (2:1010975470), on page (1:260090248), allocation unit 72057615547957248, database 'ABC' (database ID 11). Page: LSN = (4497865:2067759:36), allocation unit = 72057615547957248, type = 1. Log: OpCode = 6, context 1, PrevPageLSN: (4497870:721823:568). Restore from a backup of the database, or repair the database.
RESTORE LOG is terminating abnormally.
Processed 0 pages for database 'ABC', file 'ABC' on file 1.
Processed 9874394 pages for database 'ABC', file 'ABC_log' on file 1.(.Net SqlClient Data Provider) ***
Database Name on both Primary and Secondary Servers : ABC
The Log file is taking from the network YYYYY
December 13, 2017 at 1:08 am
Sounds like the log backup is corrupt or incomplete or the primary database has become corrupt
What is the full output of the below when run in the database context?
DBCC CHECKDB WITH ALL_ERRORMSGS, NO_INFOMSGS, DATA_PURITY, TABLERESULTS
December 14, 2017 at 12:01 am
Hi Sir,
Thanks for your mail.
Since this is a production database, running DBCC Checkdb is quite risk state as many transactions run on the server.
We re-started the Log shipment process again on the database by restoring the latest backup in the Secondary server; the log shipment is working fine now and logs are able to restore on the secondary server.
Thanks for help!
Regards,
Adil
December 14, 2017 at 12:54 am
adilahmed1989 - Thursday, December 14, 2017 12:01 AMHi Sir,
Thanks for your mail.
Since this is a production database, running DBCC Checkdb is quite risk state as many transactions run on the server.
We re-started the Log shipment process again on the database by restoring the latest backup in the Secondary server; the log shipment is working fine now and logs are able to restore on the secondary server.
Thanks for help!
Regards,
Adil
You should still be running DBCC CHECKDB frequently as your backup schedule dictates to ensure you can recover from corruption. Schedule it in the quiet times, of your system. Either that or do restores and then checkdb, that way your testing your backups and corruption.
CheckDB is lightweight against the actual database due to the snapshot and tempdb usage which it does to offset that checkdb performance against your operational DB.
December 14, 2017 at 2:57 am
Hi Sir,
Thanks for your valuable advice.
Is the below following syntax good to execute on the Database as we want to ensure that there is no effect on the Data tables or transactions.
DBCC CHECKDB ('ABC', REPAIR_FAST)
WITH ALL_ERRORMSGS
GO
Thanks,
Adil
December 14, 2017 at 3:13 am
Adil
Go with the syntax that Anthony posted. Like he said, it'll only have a small effect on the database, and it's certainly preferable to not knowing about corruption in your database. And check the documentation - the REPAIR_FAST option has no effect, so there's no point including it in your command.
John
December 14, 2017 at 3:40 am
Fine, Thanks Sir for valuable input
Viewing 9 posts - 1 through 8 (of 8 total)
You must be logged in to reply to this topic. Login to reply