架构更改会“破坏”可用性组，还是透明处理？

我的组织计划采用SQL Server 2012可用性组，并且我试图了解它将对我们的应用程序升级过程产生什么影响（如果有）。

我们每8周发布一次应用程序更新，任何发布都可能包含架构更改和/或数据迁移。

我想了解的是HA / DR解决方案是否透明地处理架构更改（新列，索引添加到第二级），还是在每个实例上创建架构然后重新打开Always On所需的手动干预。

我假设的数据迁移部分是透明处理的，但也想确认一下。

我想我也在做出一个笼统的假设，即基于可用性组配置的这些行为也没有差异，这可能也是错误的。请告诉我。

简而言之; 在我的应用程序的任何给定发行版中，我都可以通过向表中添加列来更改非常大的表（10s至1亿亿条记录）。一些列可能是“ net new”的，因此它们可以利用企业在线模式更改功能。其他列可能是对现有列的重构（FullName被拆分为FirstName和LastName），并且将对表中的每一行运行迁移以填充这些字段。这些行为是否需要DBA更改AlwaysOn配置，或者默认情况下会进行处理，并且所有辅助节点都“免费”获得DDL和DML语句？

感谢您的澄清。

模式更改和数据更改本质上是相同的。它的工作原理类似于今天的传统镜像：主要日志中发生的事情发生在次要日志上。并非所有在拉斯维加斯发生的事情都必须留在拉斯维加斯。:-)

当您有一个指向主数据库的应用程序并进行更新以匹配架构更改时，可能要当心。但是您可能有一个指向次要对象的其他应用程序（例如，具有只读意图），并且该应用程序更改也必须同步。

另一个潜在的难题是，作为可用性组一部分的数据库引用了其他数据库中的对象（例如，存储在实用程序数据库中的静态查找表）。如果这些更改和AG依赖于这些对象，则必须手动推送这些更改。对于作业，服务器级别的登录名，链接的服务器等，也是如此-驻留在数据库之外和/或不可事务的任何事物。数据库用户可以成为孤立用户（包含的用户除外）。我知道这可能很明显，但想完整地列出它。

来自Remus的更多答案，用户要求可能删除辅助副本上的查询并检查表中的重做队列大小状态：sys.dm_hadr_database_replica_states AlwaysOn DDL和架构更改