What’s the issue?
When a database is added to an Always On Availability Group, it must be joined on each secondary replica before that replica can participate in synchronizing the database. The join step is a separate operation from creating the database copy on the secondary, and it tells SQL Server on the secondary to begin tracking the database as part of the AG and to start receiving log records from the primary.A database can be in the AG configuration but not yet joined on a particular secondary, typically as a transient state during initial setup, after a manual operation that removed and re-added the database, or after a failure scenario that interrupted the join process. The unjoined database appears in the primary’s AG configuration but is not actively synchronizing on the affected secondary.
This finding identifies AGs where one or more databases are not currently joined on at least one secondary replica.
Why is this a problem?
A database that is not joined on a secondary replica is not protected by that replica. The database appears in the AG configuration, but the secondary holds no current copy of the data, so it cannot serve as a failover target for that specific database. If the primary fails, the database is unavailable until the join is completed on a remaining replica.The condition also produces inconsistent AG behavior. Some databases in the AG fail over correctly, while the unjoined databases do not, leading to a situation where part of the workload survives the failover while another part is lost or unavailable. This inconsistency is often more confusing for application teams and end users than a clean total outage would be, since it produces partial application failures that are harder to diagnose.
What should you do about this?
Determine why the database is not joined. Common causes include the database not being restored on the secondary (so there is nothing to join), the restore being completed without the WITH NORECOVERY option that joining requires, a missing log backup chain between the primary backup and the secondary restore, or a manual interruption of the join process during initial AG setup.Restore the database on the affected secondary using WITH NORECOVERY if it has not been restored, taking a fresh full backup and any subsequent log backups from the primary and applying them on the secondary. Use either traditional backup and restore, or automatic seeding if the AG is configured for it, to bring the secondary database to a state where it can be joined.
Join the database to the AG on the secondary using ALTER DATABASE [DatabaseName] SET HADR AVAILABILITY GROUP = [AGName];. Confirm that synchronization begins and that the database moves to a healthy state in the AG dashboard and in the dynamic management views.