On July 15th, 2015 I spoke to the PASS Architecture Virtual Chapter about AlwaysOn Failover Cluster Instances and AlwaysOn Availability Groups.  Obviously we focused on the technology from an architectural standpoint.  We discussed a lot of things that come into play when designing an AlwaysOn infrastructure whether it be FCIs and/or AGs.  We answered questions like, “Where are my replicas located on the network and how they are connected?”, “What OS should I use?”, “How import is the Windows Clustering piece?” and many others.  However, we only had time for a handful of questions so I thought I would just blog all the questions and my answers here.

1. Although we can use a readable replica for reporting, we can’t have different indexes on the primary and the replica, true?
   1. Correct.  All indexes must be created and maintained on the primary and they all get replicated to the secondary replicas.
2. How do you handle synchronizing system databases in Disaster Recovery setup?
   1. It’s true that you cannot mirror system databases nor can you add them to an AG.  You can, however, protect them with an FCI, log ship them, and replicate them.  NONE of those are a replacement for backups though, so go do that first.
3. You recommended SQL Server 2012, why not 2014?
   1. I didn’t recommend SQL Server 2012, I recommended Windows 2012.
4. Here is the situation: I have 5 instances on 64CPU/256Gb/SAN multi TB storage. 5 instances SQL Server 2008 with over 250 databases on each. All are in sync mirroring. Per MS: 10 availability groups 100 databases should be fine. How would you handle the situation to transition from mirroring to Always-On?
   1. There are actually several questions buried in this one, but I think the real question is that you have some DBs mirrored today so how do you move those to AGs?  You could create a cluster with your mirrored servers, break the mirror, and create the AG (You’ll need to do some cleanup though).  The other solution would be to create an AG on other servers and migrate from the mirrored servers to the AG.  So there is more than one solution and there are more than just these two.  The direction you choose really lies within your business requirements and current hardware.
5. For Availability Groups: If you use the default instance for both Primary and Secondary replicas.  Can both/either servers support multiple SQL instances where the other instances are not using AG?
   1. Yes you can have other instances running that do not have any AGs.  You can also have other instances that do have AGs.  For the latter, you cannot have a DB in an AG whose replicas are different instances on the same OS.
6. I’d be interested in your thoughts (blog post?) regarding why DBCC CHECKDB on a secondary without doing it on the primary is insufficient. Does that also apply to needing to do it on a PROD server even if the databases are restored to a TEST server on a scheduled basis and DBCC CHECKDB is done as part of the restore job?
   1. My reasoning is the same for both scenarios.  If you run DBCC on a secondary replica or test server the physical checks are looking at completely different drives and hardware.  That means I’m never checking the physical side of my production server.  An alternative that I have seen many folks do, especially with larger databases, is to run a full DBCC on the test server and run it with the PhysicalOnly parameter on the primary.
7. For secondary node does it make much difference keeping read-intent or readable secondary except mentioning read intent in connection?
   1. Let me try and rephrase this one.  What is the difference between setting a secondary replica’s “Read Only” property to “Yes” versus “Read-intent Only”?  Yes means that anyone that has access can connect and read data.  Read-intent Only means that anyone that has access can connect so long as they have “applicationintent=readonly” or “applicationintent=yes” in the connection string.  This is a way to “hide” users from reading your secondaries when you might have an application like SSRS that needs read only and they should be using that instead of accessing it directly.  It’s not a security feature and it only takes a user an internet search to find the secret sauce.  Of course you can also select No for the option and prevent read on that replica entirely.
8. Do we need to do log backups on the secondary server?
   1. That is entirely up to you.  You can take log backups on the primary or secondary.  The log chain is kept in tact regardless of which replica you take a log backup on.