After creating the ticket, I go to the environment and see with SSMS that on the secondary, the database is in the state Not Synchronizing \/ Suspect<\/strong>…<\/p>\n\n\n\n Like usual, I go to the errorlog and see this error:<\/p>\n\n\n\n Error: 17204, Severity: 16, State: 1.<\/em>\n It seems that we have a file on a share which is not accessible, and which is putting the database in a suspicious state. If you look at the database on the primary, you can see that someone has created a data file on a share…<\/p>\n\n\n\n SQL Server has allowed you to create files on shares for years.<\/p>\n\n\n\n When you’re in an HA system with AlwaysOn AG and with automatic seeding(the problem coming from this point), adding a file on the primary will be replicated on the secondary and so in our case, it will be necessary to create the file on the same share with the same name, which isn’t possible.<\/p>\n\n\n\n The second consequence is that the Tlog file doesn’t get emptied and continues to grow despite the backup logs, because the pending synchronisation anticipates the commit… until the big alert that the Tlog disk is full…<\/p>\n\n\n\n The moral of the story is simple: before making a structural change to a database, think about how it works and the consequences. <\/p>\n\n\n\n In any case, we’ll always be here to help! \ud83d\ude09<\/p>\n\n\n\n <\/p>\n","protected":false},"excerpt":{"rendered":" Few days ago, through our alerting at the Service Desk, we receive an alert about a database in an AlwaysOn cluster with the message: CRITICAL: Database xxxx [replica: xxxxxx] [role: SECONDARY] state is SUSPECT, synchronization health is NOT_HEALTHY, synchronization state is NOT SYNCHRONIZING [suspended: true] [failover ready: false] [joined: true] After creating the ticket, I […]<\/p>\n","protected":false},"author":15,"featured_media":0,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[229,198],"tags":[49,51],"type_dbi":[2874],"class_list":["post-37905","post","type-post","status-publish","format-standard","hentry","category-database-administration-monitoring","category-database-management","tag-microsoft","tag-sql-server","type-sql-server"],"acf":[],"yoast_head":"\n![\"\"](\"https:\/\/www.dbi-services.com\/blog\/wp-content\/uploads\/sites\/2\/2025\/04\/image-3.png\")
<\/figure>\n\n\n\n
FCB::Open failed: Could not open file \\\\ xxxx \\BackupSQL\\Temp\\Backup_Table\\ xxxx.ndf for file number 307. OS error: 5(Access is denied.)<\/em>\n
Error: 5120, Severity: 16, State: 101.<\/em>\n
Unable to open the physical file “\\\\ xxxx \\BackupSQL\\Temp\\Backup_Table\\ xxxx.ndf”. Operating system error 5: “5(Access is denied.)”.<\/em>\n
Error: 3459, Severity: 16, State: 1.<\/em>\n
Recovery of database “xxxx” failed to redo a file add for file “\\\\xxxxx\\BackupSQL\\Temp\\Backup_Table\\xxxx.ndf”. Please delete the file and retry.<\/em><\/p>\n<\/div>\n<\/div>\n\n\n\n![\"\"](\"https:\/\/www.dbi-services.com\/blog\/wp-content\/uploads\/sites\/2\/2025\/04\/image-4.png\")
<\/figure>\n\n\n\n![\"\"](\"https:\/\/www.dbi-services.com\/blog\/wp-content\/uploads\/sites\/2\/2025\/04\/image-5.png\")
<\/figure>\n\n\n\n