Sql-server – Changing IP address of SQL Server 2012

Changing the IP Address for a machine running SQL Server is not a problem at all. You'll need to restart the SQL Server after changing the IP Address so that the SQL Server will start listening on the new IP address. But that's it.

If no users actually connect to the machine then there's nothing else to do.

If users did connect to the machine they'd need to refresh their DNS cache on their workstations by running "ipconfig /flushdns" or by simply restarting their computers.

Unless you've done something very unusual with the TCP listeners within SQL there's nothing else that needs to be done with SQL Server other than the quick restart.

1.When and how do we install Microsoft Updates?

Using AOAGs could potentially help with this, depending on how much downtime is considered to be "too much". There is still a blip associated with switching the primary to a synchronous secondary as the clients will be disconnected (this may or may not be an issue in your environment) as the move happens. They will need to reconnect using the listener name (so no connection string changes should be required) and be using a library that supports this.

1.For Windows Updates, bring one server down, install windows updates, bring it back up, and then update the second instance.

That's the basics of how it works. Remove automatic failover (synchronous), install the updates/patches, reboot (in this scenario).

2.How do we apply schema changes?

AOAGs aren't going to help you in this respect. The transaction log is basically replayed from the primary to all of the secondary's. The secondary's could be readable (if you allow them to be) but won't be able to have any write activity (including ddl changes) made to them. A synchronous secondary is a mirror copy of the primary.

Could these changes be made when the application changes are made to minimize downtime? It may make more sense to use a load balanced front end using something such as an F5 and keeping the data in sync through something such as peer to peer replication than use AOAGs. I'm not a replication expert, but it definitely sounds like you will need two distinct systems that have some type of load balanced front end so that changes can be made to a single system at a time to move resources in and out while keeping them in sync.

2.For schema changes, bring one server down, apply schema changes, bring it back up, and then apply same changes to the second instance.

This can't be done this way (or any way, really) with AOAGs.