Recently I wrote a blog explaining a situation where taking log backup can break automatic seeding and synchronization would not work. Below is the blog reference. SQL SERVER – AlwaysOn Automatic Seeding – Database Stuck in Restoring State
While fixing above, I came across an interesting situation where I wanted to add multiple databases to the availability group. In my availability group, two of them were able to seed properly but one database was not getting restored on the secondary replica. In this blog, we would learn how to VDI Client failed caused during automatic seeding.
After looking into various articles on the internet, I learned that dynamic management views (DMVs) sys.dm_hadr_physical_seeding_stats can be used to track the progress of seeding. I queried the DMV to see the cause of failure. Here is the query which I used to find the status.
SELECT local_database_name ,role_desc ,internal_state_desc ,failure_code ,failure_message FROM sys.dm_hadr_physical_seeding_stats
Here is the output
I had no clue about failure_code 15 and failure_message VDI Client failed shown in above output. To move further, I check ERRORLOG on the secondary replica and found below interesting messages.
2018-03-17 02:01:48.56 spid69s Error: 911, Severity: 16, State: 1.
2018-03-17 02:01:48.56 spid69s Database ‘SQLAuthorityDB’ does not exist. Make sure that the name is entered correctly.
2018-03-17 02:01:48.70 spid69s Error: 3633, Severity: 16, State: 1.
2018-03-17 02:01:48.70 spid69s The operating system returned the error ‘5(Access is denied.)’ while attempting ‘RestoreContainer::ValidateTargetForCreation’ on ‘C:\Database\SQLAuthorityDB.mdf’ at ‘container.cpp'(2759).
2018-03-17 02:01:48.70 spid69s Error: 3634, Severity: 16, State: 1.
2018-03-17 02:01:48.70 spid69s The operating system returned the error ‘5(Access is denied.)’ while attempting ‘RestoreContainer::ValidateTargetForCreation’ on ‘C:\Database\SQLAuthorityDB.mdf’.
2018-03-17 02:01:48.70 spid69s Error: 3156, Severity: 16, State: 5.
2018-03-17 02:01:48.70 spid69s File ‘SQLAuthorityDB’ cannot be restored to ‘C:\Database\SQLAuthorityDB.mdf’. Use WITH MOVE to identify a valid location for the file.
2018-03-17 02:01:48.70 spid69s Error: 3119, Severity: 16, State: 1.
2018-03-17 02:01:48.70 spid69s Problems were identified while planning for the RESTORE statement. Previous messages provide details.
2018-03-17 02:01:48.70 spid69s Error: 3013, Severity: 16, State: 1.
2018-03-17 02:01:48.70 spid69s RESTORE DATABASE is terminating abnormally.
2018-03-17 02:01:48.70 spid71s Automatic seeding of availability database ‘SQLAuthorityDB’ in availability group ‘AG’ failed with a transient error. The operation will be retried.
Now, this was interesting and clear to tell us the problem. The automatic seeding was trying to restore the database and created file in C:\Database folder. It was failing with error operating system returned the error ‘5(Access is denied.)’. When I checked other two databases which I was adding along with this, I would that they were in a different location and permissions were perfect there.
WORKAROUND/SOLUTION
There were two options to fix the issue so that automatic seeding can work.
- Provide permission on the destination folder on secondary replica to service account. Once it’s done, we can restart the secondary so that seeding would kick in again. We can also remove and this database from availability group and add again.
- Move the files on primary to a location where seeding is working.
If we don’t want automatic seeding, then we can also perform manual backup and restore of this database and then add it to availability group by using “Join Only” option in the wizard.
Have you come across any other seeding failure code? If yes, please share your experience with other readers via comment. If I can reproduce those codes, I would write a blog on that.
Reference: Pinal Dave (https://blog.sqlauthority.com)
First appeared on SQL SERVER – AlwaysOn Automatic Seeding Failure – Failure_code 15 and Failure_message: VDI Client Failed