Hi there,
Thanks for the response so far. Below are the answers to your questions:
TheSQLGuru (11/26/2014)
1) What is your experience with windows clustering and SQL Server's Always On technologies? If they aren't very strong, you have a very high likelihood of things not going as you intend or functioning as you intend.
I have built quite a few FCI's on SQL 2008 (R2) and 1 or 2 AOAG's in SQL 2012 in the past, but always from a clean slate.
TheSQLGuru (11/26/2014)
2) There are quite a number of windows patches and configurations to get right. Networking stack issues too. Specific SQL Server patches to apply.
This is exactly why I asked the question. Most of my builds have been pretty straight forward in the past. I prefer to keep things as simple as possible.
TheSQLGuru (11/26/2014)
3) Are you aware that reading from a secondary will modify PRIMARY ROWS adding a slot for the 14-byte version store pointer for read rows?? This leads to latching/locking/dirty pages/tlog activity (all of which also has to be sent over the wire via mirroring to be replayed on the secondary)? Oh, lets not forget the massive index fragmentation that can occur for those that use the default index fill factor of 0.
This is news to me. I haven't read anywhere that reading from 'read only copies' would make changes to the primary. I assumed they would work similar to 'read only' snapshots.
TheSQLGuru (11/26/2014)
4) Do your myriad applications know how to properly interact with AGs? What will they do when the Primary gets yanked out from under them and moved to the other server?
We are not looking to use this particularly for High Availability or Failover, but more as an 'online backup' where the data would still be available for reading if the primary goes done. In the past my 'apps' have just connected to the listener and worked happily.
TheSQLGuru (11/26/2014)
5) Of particular concern is the various replications you have going on. Multiple forms of data synchronization can EASILY get TOTALLY HOSED UP. More i's to dot and t's to cross to have a chance of success.
Exactly why I don't want to either break what's already in place or try and redo it all.
TheSQLGuru (11/26/2014)
6) Got any SQL Agent jobs (backups, maintenance, batch activities, etc.)? They need to be dealt with too because the database they hit may or may not be the primary on the given server.
I already have a solution for this.
TheSQLGuru (11/26/2014)
7) Logins/users in the database? Another gotcha...
I already have a solution to this too.
Again, thanks for your input, it is appreciated.
Keith