Error: Could not apply log backup file

Question

Error: Could not apply log backup file

dopydb

SSCertifiable

Points: 6687
More actions
February 22, 2018 at 2:24 am

#329428

hi
i have a sql 2005 db with log shipping enabled.
the secondary server is suddenly giving me the below errors, anyone any tips on how to fix the issue trans log? or am i going to have to do a full db restore?
Error: Could not apply log backup file
Error: Could not redo log record
Restore from a backup of the database, or repair the database.
An error occurred while processing the log for database 'SysproCompanyW'. If possible, restore from backup. If a backup is not available, it might be necessary to rebuild the log.
RESTORE LOG is terminating abnormally.
Processed 0 pages for database 'SysproComp

Viewing 12 posts - 1 through 11 (of 11 total)

You must be logged in to reply to this topic. Login to reply

Gail Shaw SSC Guru Points: 1004504 More actions · Answer 1

Looks like the transaction log on the secondary is damaged (or could be the data files)
You're going to need to re-do it, and it may be a good idea to recover the database (if possible) and run checkDB to see what happened, and then re-do the log shipping

Gail Shaw
Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability

We walk in the dark places no others will enter
We stand on the bridge and no one may pass

dopydb SSCertifiable Points: 6687 More actions · Answer 2

hi Gila

so the db is currently in restoring mode as you would expect, as soon as i take it out of this mode, wont i have to do a full db restore?
i have tried copying over the issue log file again and retrying restore but it fails again with same error

mal

Gail Shaw SSC Guru Points: 1004504 More actions · Answer 3

As I said, you're going to need to redo it. i.e. full database restore

But, before you do that, it may be a good idea to recover the DB and run CheckDB so that you can see what's broken.

Gail Shaw
Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability

We walk in the dark places no others will enter
We stand on the bridge and no one may pass

dopydb SSCertifiable Points: 6687 More actions · Answer 4

dopydb

SSCertifiable

Points: 6687

February 22, 2018 at 3:25 am

#1980740

cheers Gila for advise! always appreciated

Ivan R. SSChasing Mays Points: 628 More actions · Answer 5

hello, if it's a small enough database, you may want to consider restoring the adhoc full + dif + trn form the primary to another instance then do DBCC CHECKDB.

That should give some benefit of testing the restore as well before touching and re-doing the faulty replica. Also consider the DBCC on the primary maybe if it's possible size/availability wise to rule out any issue with that instance/host.

Ivan R. SSChasing Mays Points: 628 More actions · Answer 6

hello -- you might already be aware that the driver they use will have an impact?
But just in case here's the link: https://docs.microsoft.com/en-us/sql/database-engine/availability-groups/windows/always-on-client-connectivity-sql-server

e.g.

Driver	Multi-Subnet Failover	Application Intent	Read-Only Routing	Multi-Subnet Failover: Faster Single Subnet Endpoint Failover	Multi-Subnet Failover: Named Instance Resolution For SQL Clustered Instances
SQL Native Client 11.0 ODBC	Yes	Yes	Yes	Yes	Yes
SQL Native Client 11.0 OLEDB	No	Yes	Yes	No	No
ADO.NET with .NET Framework 4.0 with connectivity patch*	Yes	Yes	Yes	Yes	Yes
ADO.NET with .NET Framework 3.5 SP1 with connectivity patch**	Yes	Yes	Yes	Yes	Yes
Microsoft JDBC driver 4.0 for SQL Server	Yes	Yes	Yes	Yes	Yes

Gail Shaw SSC Guru Points: 1004504 More actions · Answer 7

He's using Log Shipping on SQL 2005 (3 versions before Availability Groups was introduced), the link and chart are hence not relevant.

Gail Shaw
Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability

We walk in the dark places no others will enter
We stand on the bridge and no one may pass

dopydb SSCertifiable Points: 6687 More actions · Answer 8

soon hopefully we will upgrade, and we can experience 10 year old Tech 🙂

Gail Shaw SSC Guru Points: 1004504 More actions · Answer 9

dopydb - Monday, February 26, 2018 6:28 AM
soon hopefully we will upgrade, and we can experience 10 year old Tech 🙂

🙂

If upgrades are in the planning phase, I would recommend straight to 2017. No more work than any other version, and some nice features to help you fix any problems from the upgrade (Query Store)

Gail Shaw
Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability

We walk in the dark places no others will enter
We stand on the bridge and no one may pass

Ivan R. SSChasing Mays Points: 628 More actions · Answer 10

GilaMonster - Monday, February 26, 2018 6:23 AM
He's using Log Shipping on SQL 2005 (3 versions before Availability Groups was introduced), the link and chart are hence not relevant.

oh shoot sorry.. so that is where my response went! i believe this is in response to another thread. thanks.

dopydb SSCertifiable Points: 6687 More actions · Answer 11

hi Gila
yea we are going straight to 2017 hopefully in later part of the year! be nice to read a new book for a change 🙂
thanks
mal