3

Simply run RESTORE DATABASE TestDB WITH RECOVERY on the secondary.


2

The message that is returned is not accurate as it is referring to the name that it will give the network name resource (SQLPROD_AG_SQLPROD), and it is labelled incorrectly as the DNS name. You can see that the network name resource in your AG is named SQLPROD_AG_SQLPROD, and that is what it's referring to. It really should say something like, "The ...


2

It doesn't matter where the login is created first. The only important thing is that the SIDs match. All permissions, role memberships, etc. that are assigned to the associated users on databases in the availability group on the primary will be effective on the secondaries for the login with the same SID.


2

The reason the documentation states that automatic failover is not supported is that there are post-failover tasks that must be carried out to ensure the Report Server is completely online. See this section for information on exactly what tasks need to be completed. Essentially it boils down to needing to stop the SQL Agent on the old primary and restart the ...


2

You cannot add a Linux system to a Windows cluster, so you won't be able to add any Linux systems into a SQL Server 2014 availability group. You also cannot do the migration with distributed availability groups because SQL Server 2014 did not have support for distributed availability groups. From Distributed availability groups: Because the distributed ...


1

I had lots of confusion around the topic - In AG cluster restoring Log backup following with Copy - only full backup. It is now working fine. We can use copy only backup from secondary replica: USE [master] RESTORE DATABASE [xxxxx_testDB] FROM DISK = N'D:\Backups\FULL_COPY_ONLY\xxxxx_testDB_FULL_COPY_ONLY.bak' WITH FILE = 1, MOVE N'xxxxx_testDB' TO N'...


1

What happens when the old primary is available and back online? Synchronous-commit mode and Automatic Failover: When the former primary replica comes back online, it takes on the secondary role, and the former primary database becomes the secondary database. The new secondary replica quickly resynchronizes the new secondary databases with the corresponding ...


1

This is not possible since database is added to AOAG You cannot take the db offline unless you remove it from AG You can see and verify this yourself simply by adding some "TestDB" to your AG and try to take if offline Do I have to wait for the sync to finish before manually failing back over to Database A from Database B? Yes you have to wait for sync ...


1

The problem is that procedure only works if read access is enabled for the secondaries and, as per the documentation, Basic Availability Groups do not allow readable secondaries. You need to manually perform the checks that this procedure normally handles as per the doco: This is expected behavior. You must verify the presence of the subscriber server ...


1

why would that be the case only with SSRS? As addition note to the Handy's answer, one of the main reason, SSRS dependencies are not only in ReportServer and ReportServerTempDB databases, but also on SQL Server Agent which host all the subscription configuration of the SSRS and which would not be a scope of AG replication. So, you got covered ReportServer ...


Only top voted, non community-wiki answers of a minimum length are eligible