We seem to have a strange problem that we're trying to pinpoint the source of.
We have tried rolling out the Azure Arc SQL Server Extension (ArcSQL) in our non‑production environment, but we quickly ran into log backup errors on our AG's (only AG's as far as we can see).
We see that when the ArcSQL service is running, we frequently encounter these errors in the files "DatabaseBackup - USER_DATABASES - LOG xxxxx".
On an AG where we have non‑readable secondaries, the error message we see is:
"Msg 976, Sev 14, State 1, Line 2801: The target database, '<DBNAME>', is participating in an availability group and is currently not accessible for queries. Either data movement is suspended or the availability r"
On an AG with read‑intent enabled:
"Msg 978, Sev 14, State 1, Line 2801: The target database ('<AnotherDBName>') is in an availability group and is currently accessible for connections when the application intent is set to read only. For more information about application intent, see SQL Server Books Online. [SQLSTATE 42000]"
This happens more frequently on a server with many databases, where there is a chance that the backup jobs and Arc operations collide. Microsoft is involved at the product level with this issue, but we really can't figure out what causes what. The errors disapear at once when the ArcSQL is stopped. MS is involved on product level but they can't figure out the real reason either.
What we would really like to know at this stage is what the Maintenance Solution is doing when it fails. From what we can gather from the log, it performs some kind of metadata gathering about the database and that step fails. But reading 4000+ rows TSQL is not my strongest skill :)
A normal backup looks similar to:
User access: MULTI_USER [SQLSTATE 01000]
Recovery model: FULL [SQLSTATE 01000]
Encrypted: No [SQLSTATE 01000]
Availability group: fp‑uat‑ag01 [SQLSTATE 01000]
Availability group role: SECONDARY [SQLSTATE 01000]
Availability group backup preference: SECONDARY [SQLSTATE 01000]
Is preferred backup replica: Yes [SQLSTATE 01000]
Differential base LSN: 1851000016072300002 [SQLSTATE 01000]
Last log backup LSN: 1853000002377100001 [SQLSTATE 01000]
Last log backup: 2026‑02‑20 10:30:05 [SQLSTATE 01000]
Log size since last log backup (MB): N/A [SQLSTATE 01000]
[SQLSTATE 01000]
Date and time: 2026‑02‑20 10:45:05 [SQLSTATE 01000]
A failed backup looks similar to this (on a secondary with read‑intent, but the situation is similar on a non‑readable secondary):
State: ONLINE [SQLSTATE 01000]
Standby: No [SQLSTATE 01000]
Updateability: READ_WRITE [SQLSTATE 01000]
User access: MULTI_USER [SQLSTATE 01000]
Recovery model: FULL [SQLSTATE 01000]
Encrypted: No [SQLSTATE 01000]
Msg 978, Sev 14, State 1, Line 2801: The target database ('<not-a-chance>') is in an availability group and is currently accessible for connections when the application intent is set to read only. For more information about application intent, see SQL Server Books Online. [SQLSTATE 42000]
We are using a fairly vanilla setup:
- A 2‑node AG with or without a readable secondary (usually without)
- Using the Maintenance Solution for all maintenance
- Backups are preferred to run on the secondary (default)
- Log backups runs several times/day.
One problem for us is that there is no retry mechanism in the Maintenance Solution. If it fails, it fails. There is a good chance it would work if it retried again on that particulare database after one second or so (not a real fix, but…).
We seem to have a strange problem that we're trying to pinpoint the source of.
We have tried rolling out the Azure Arc SQL Server Extension (ArcSQL) in our non‑production environment, but we quickly ran into log backup errors on our AG's (only AG's as far as we can see).
We see that when the ArcSQL service is running, we frequently encounter these errors in the files "DatabaseBackup - USER_DATABASES - LOG xxxxx".
On an AG where we have non‑readable secondaries, the error message we see is:
"Msg 976, Sev 14, State 1, Line 2801: The target database, '<DBNAME>', is participating in an availability group and is currently not accessible for queries. Either data movement is suspended or the availability r"
On an AG with read‑intent enabled:
"Msg 978, Sev 14, State 1, Line 2801: The target database ('<AnotherDBName>') is in an availability group and is currently accessible for connections when the application intent is set to read only. For more information about application intent, see SQL Server Books Online. [SQLSTATE 42000]"
This happens more frequently on a server with many databases, where there is a chance that the backup jobs and Arc operations collide. Microsoft is involved at the product level with this issue, but we really can't figure out what causes what. The errors disapear at once when the ArcSQL is stopped. MS is involved on product level but they can't figure out the real reason either.
What we would really like to know at this stage is what the Maintenance Solution is doing when it fails. From what we can gather from the log, it performs some kind of metadata gathering about the database and that step fails. But reading 4000+ rows TSQL is not my strongest skill :)
A normal backup looks similar to:
User access: MULTI_USER [SQLSTATE 01000]
Recovery model: FULL [SQLSTATE 01000]
Encrypted: No [SQLSTATE 01000]
Availability group: fp‑uat‑ag01 [SQLSTATE 01000]
Availability group role: SECONDARY [SQLSTATE 01000]
Availability group backup preference: SECONDARY [SQLSTATE 01000]
Is preferred backup replica: Yes [SQLSTATE 01000]
Differential base LSN: 1851000016072300002 [SQLSTATE 01000]
Last log backup LSN: 1853000002377100001 [SQLSTATE 01000]
Last log backup: 2026‑02‑20 10:30:05 [SQLSTATE 01000]
Log size since last log backup (MB): N/A [SQLSTATE 01000]
[SQLSTATE 01000]
Date and time: 2026‑02‑20 10:45:05 [SQLSTATE 01000]
A failed backup looks similar to this (on a secondary with read‑intent, but the situation is similar on a non‑readable secondary):
State: ONLINE [SQLSTATE 01000]
Standby: No [SQLSTATE 01000]
Updateability: READ_WRITE [SQLSTATE 01000]
User access: MULTI_USER [SQLSTATE 01000]
Recovery model: FULL [SQLSTATE 01000]
Encrypted: No [SQLSTATE 01000]
Msg 978, Sev 14, State 1, Line 2801: The target database ('<not-a-chance>') is in an availability group and is currently accessible for connections when the application intent is set to read only. For more information about application intent, see SQL Server Books Online. [SQLSTATE 42000]
We are using a fairly vanilla setup:
One problem for us is that there is no retry mechanism in the Maintenance Solution. If it fails, it fails. There is a good chance it would work if it retried again on that particulare database after one second or so (not a real fix, but…).