相关疑难解决方法(0)

在升级 SQL Server 2014 SP1 (12.0.4422.0) 实例中的存储时，我们遇到了一个问题，即在重新启动 SQL Server 后，两个数据库无法在辅助数据库上启动。当我们安装新的（更大的）SSD 并将数据文件复制到新卷时，服务器已离线几个小时。当我们重新启动 SQL Server 时，除了两个数据库之外的所有数据库再次开始同步。另外两个在 SSMS 中显示为Not Synchronizing / Recovery Pending。

之前遇到过类似的Not Synchronizing / In Recovery问题，我检查了 Availability Groups -> Availability Databases 部分下的状态，但它们显示了一个红色的 X：

甚至尝试暂停数据移动生成了一条错误消息：

无法暂停数据库“StackExchange.Bycycles.Meta”中的数据移动，该数据库驻留在可用性组“SENetwork_AG”中的可用性副本“ny-sql03”上。(Microsoft.SqlServer.Smo)

附加信息：执行 transact-SQL 语句或批处理时发生异常。(Microsoft.SqlServer.ConnectionInfo)

由于无法访问文件或内存或磁盘空间不足，无法打开数据库“StackExchange.Bycycles.Meta”。有关详细信息，请参阅 SQL Server 错误日志。（Microsoft Sql Server，错误：945）

我检查过文件存在并且没有任何权限问题。我还检查了管理下 SSMS 中的 SQL Server 日志，但没有看到任何有关挂起恢复或两个数据库的任何问题的信息。

在寻求帮助时，我发现两篇不同的文章都说需要恢复数据库。

当数据库卡在 Recovery Pending 中时，有什么方法可以在辅助节点上恢复数据复制？

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

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

我想了解的是 HA/DR 解决方案是否透明地处理架构更改（新列、索引被添加到辅助节点），或者是否需要手动干预在每个实例上创建架构然后重新打开 Always On。

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

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

简而言之; 在我的应用程序的任何给定版本中，我可能会通过向其中添加列来更改非常大的表（数百万条记录的数十到数百条记录）。某些列可能是“全新的”，因此它们可以使用 Enterprise Online 架构更改功能。其他列可能是现有列的重构（全名被拆分为名字和姓氏），并且将为表中的每一行运行迁移以填充这些字段。这些行为中的任何一个是否需要 DBA 更改 AlwaysOn 配置，或者这是默认处理的，并且所有辅助节点都“免费”获得 DDL 和 DML 语句？

感谢您提供的任何清晰度。