我们正在尝试对 2 节点（多子网、企业版）AG 从 sql 2016 到 2019 进行首次并行升级。我对如何最好地解决此问题有一些疑问：
当我们处理集群和 AG 时，我无法在网上找到任何分步指南
我的开发团队一直在使用数据库快照在运行大量测试后将独立的 4TB 数据库快速恢复到较早的状态。他们现在需要相同的过程来将该数据库重置为较早的状态，但它现在位于可用性组中。我不知道在这方面可以使用快照的任何方式。传统的备份和恢复方法需要 6 个多小时，并且不是快速进行多项测试的真正选择。
我在谷歌上没有发现任何东西表明有一种快速的方法可以将可用性组中的数据库重置回较早的状态。一般来说，我对快照没有太多经验，更不用说它们如何在 AG 中工作了。
我们正在运行 SQL 2019 RTM。
有没有办法在这种情况下使用数据库快照来避免正常的恢复时间？
试图在不将数据库从 AG 中取出的情况下直接恢复快照，但出现此错误：
RESTORE cannot operate on database 'agseed' because it is configured for database mirroring or has joined an availability group. If you intend to restore the database, use ALTER DATABASE to remove mirroring or to remove the database from its availability group.
然后将数据库从 AG 中取出，并能够将快照恢复到主数据库，但无法“不恢复”地恢复它以播种辅助数据库。
这里有两部分问题。
我们有一个大表（在 1-2 百万行之间），上面有非常频繁的 DML 操作。在低流量期间，我们有一个代理作业来删除旧行以控制表的大小。它使用下面的 CTE，它在运行时会导致大量阻塞：
;with agent_cte (queue_id) as
(
select top (3000) queue_id
from Table_A with (updlock, readpast)
where state in ('success','error','reject','failed','deleted')
and modify_timestamp <= DATEADD(dd,- 5,getdate())
order by modify_timestamp asc
)
delete from agent_cte
;
我重新编写了它以使用临时表来加速查询并减少阻塞，但我发现使用IN与EXISTS确定要删除的行之间存在很大的性能差异。
IN版本：
-- Create temp Table
create table #Table_AToDelete
(Queue_id uniqueidentifier,
PRIMARY KEY(Queue_id)
);
-- grab top 3k queue_id's older than 5 days, insert into temp table
Insert into #Table_AToDelete
select top (3000) queue_id
from Table_A with (nolock)
where state in ('success','error','reject','failed','deleted')
and modify_timestamp <= DATEADD(dd,- 5,getdate())
-- delete the rows from table_A based on rows in temp table
delete
from Table_A
where queue_id in (select queue_id from #Table_AToDelete)
这个版本在 40-50 秒内运行，但是当我用下面的 delete 语句替换最后一行时：
where exists(select queue_id from #Table_AToDelete)
2分钟后它还在运行，所以我取消了它。
所以，问题：
Queue_id。IN为什么delete和delete 中的性能差异很大EXISTS？关于如何调整它以更好地执行或进一步减少阻塞的任何反馈？
更多注意事项：
我还将使用本文中的视图进行测试。
不久，我会将 2008 R2 SSRS 安装迁移到 AWS 中的新 SQL 2019 Always on AG。这个将包含订阅，我以前从未处理过它们。我在这里阅读了文档：SSRS and AG's ，它指出控制订阅的代理作业在新主服务器上发生故障转移后会自动重新创建，但仍存在于旧主服务器上。
对于我的其他 SSRS 迁移，我编写的代码会在故障转移后自动负责在适当的节点上重新启动 SQL 代理和 SSRS 服务以使用新节点。我在所有副本上都有相同的作业，并且我还有一个作业步骤来检查服务器是否是主服务器。如果不是，则作业将不会运行。
由于我的作业已经同步并且根据主副本状态控制了执行，我宁愿使用它来控制订阅，但是 SQL 会覆盖订阅的现有作业吗？还是只会添加不存在的工作？我目前没有服务器可以对此进行测试，也无法在网上找到这种具体情况。我宁愿让作业一直在那里，让作业逻辑根据副本状态运行作业。订阅是否可能，或者我是否需要始终禁用旧主服务器上的作业，并让 SQL 在新主服务器上重新创建作业？
我还想将 sql 代理作业从无意义的 GUID 重命名为更直观的名称。如果我这样做，会不会影响正在执行的工作？
在接下来的几个月中，我将把一些非生产 SQL 环境从 Enterprise 版转换为 Developer 版。我非常确定我将使用的过程，该过程在这篇博文中进行了阐述： 降级 SQL Server 版本
在具有可用性组的环境中执行此操作时，我无法找到任何特定于任何特殊预防措施的信息。我们有一个 2 节点同步提交 AG。考虑到我们正在从 Enterprise 转向 Developer，我不关心仅 Enterprise 的功能是否会成为问题。我假设的工作流程将是：
这与我用于滚动补丁和升级的过程基本相同，但不确定降级版本是否有特殊考虑......有人这样做有什么问题吗？
我发现了一些处理这个问题的旧帖子（5 岁或以上），但我对这个过程感到困惑，或者这些信息是否过时，因此我提出了新问题。我在 sql 2016 SP2-CU11 企业版上。
我需要在可用性组中的数据库上启用服务代理。它的大小为 1.8TB，所以我真的不想把它完全从 AG 中取出，如果可以避免的话，我真的不想用新的备份重新播种它。一些较早的帖子说您必须完全删除数据库并将其重新添加到 AG 中，其他人引用只是运行一些代码来创建端点，以及我以前从未遇到过的路由。
下面的过程是在未启用的 AG 中的数据库上启用服务代理的唯一方法吗？
删除数据库的辅助副本，然后从 AG 中删除主副本。
运行以下代码以激活服务代理：
ALTER DATABASE XXXXXX SET ENABLE_BROKER；去
进行完整备份，将其还原到辅助服务器，无需恢复。
将数据库加入辅助节点上的 AG。
我有一个包含 2.6B 行的表，我需要将一列从 Char(1) 更改为 Varchar(64)。该表超过 300GB，有几个索引。该列可以为空，所以我正在运行的事务是：
ALTER TABLE XXXX ALTER COLUMN YYYYY varchar(64) NULL
我知道这是一个记录操作，所以我将事务日志的大小预先设置为 300GB，认为这已经足够了，尤其是每 5 分钟备份一次日志以允许日志空间重用。由于驱动器空间问题，在我不得不取消交易之前，交易日志增长到 812GB。
我还经历了数据文件 USED 大小的大幅增加，我不知道为什么会这样。使用的数据文件大小正好在 200GB 左右（在这个数据库中完成的事务非常少，所以我知道增加来自这个 alter table 命令）。
我有一些问题：
我在非生产环境中有一个 2 节点 AG，我们希望关闭辅助节点以节省成本，只保留主节点。我有一些基于这个过程的问题，我的研究并没有回答所有这些问题。能以某种方式填补这里关于什么是可能/最好做的空白吗？
是否可以只保留一个节点 AG？如果是这样，是否有理由实际这样做？据我了解，如果您删除所有辅助节点，那么保留 AG 根本没有任何好处，因为它会变成一个独立的实例。如果我保留了 AG，那么 DB 的事务日志将不会被截断，因为它试图找到将日志发送到的地方，对吗？
AG 侦听器 - 如果我们完全移除 AG，但如果我将 AG 保留为单个节点，侦听器将无法正常工作？我的应用程序团队将需要更改代码以使用其他内容，因为侦听器名称已被编码为使用，他们希望尽可能避免这种情况。我认为这是不可能的，但想检查一下。
次要节点——我们可能会按需启动次要节点，那么在我们移除 AG 后将集群资源留在原处是否存在问题，或者移除是否会删除集群对象？我认为他们会留下来，但我还没有找到答案。
根据我的发现，我假设的工作流程是这样的
我有一个 2 节点 AG 设置（不是 FCI）。我需要配置一个警报以根据错误日志中找到的字符串触发作业，该字符串显示该节点现在是新的主节点。
我要使用的字符串是：
'primary_pending' 到 'primary_normal'
这是辅助节点变为主节点时错误日志中显示的内容。我希望警报启动我创建的 SQL 作业，以自动化我们的 SSRS 以使用新的主副本。
下面是我设置的警报，但它没有正确触发。我确实将警报配置为在触发此警报时执行作业。
发生故障转移时，作业不会启动。我猜这可能是由于使用了错误号。我找到了一篇关于使用它的博客文章，但似乎无法再次找到它。错误日志在此文本的行中没有显示任何错误号，所以我认为这是问题所在。
如何根据在错误日志中找到的文本触发警报，或者有更好的方法吗？
我确实有条件逻辑来检查我所有工作中的主要/次要状态，但我不能将它用于这项工作，因为我希望它只执行 1x（当它第一次成为主要时）。
我不知道该怎么说，但我正在寻找 DBA 可以做的任何事情（除了更改应用程序中的代码之外的事情），以减少 AG 故障转移时对用户的影响。
我们有一个以同步提交模式运行 SQL 2016 SP2 CU10 的 2 节点 AG，并与侦听器连接。
什么控制连接到新主节点的切换？有没有办法加速切换？连接字符串、AG 设置、更改超时等是否有助于加快用户切换速度？
我正在测试 2016 SQL Enterprise SP2 CU7 版中新的数据库级别检测选项，它似乎没有按预期工作。我们有一个 2 节点设置、同步提交、两个节点上的自动故障转移。选中数据库级别的健康检测选项。在主节点上，我使一个驱动器脱机，其中包含 AG 中数据库的一个数据文件。我从一个从丢失的磁盘读取的表中运行了一个 select *，并得到了预期的 823 错误，该错误记录在错误日志中。跑了几次，错误日志记录了多次823。
发生这种情况时，可用性组没有像预期的那样进行故障转移。我等了大约 3 分钟，看看是否会发生故障转移，但从未发生过。我怎样才能知道数据库级别的健康检查例程设置为多久运行一次？我理解这需要根据这篇文章在 4 次连续运行中看到问题： 增强的数据库级别故障转移
我查看了AG中的健康检查超时值，是30秒。
我还查看了服务器上的故障条件级别，它设置为 On CriticalServerErrors，但据我了解，此设置完全独立于数据库级别的健康检查，它们中的任何一个都应该能够自行触发故障转移. 这个对吗？
我唯一能想到的就是防止这是 WSFC 管理器中的挂起超时。在使群集资源脱机之前，该值为 3 分钟。
知道我还应该在哪里寻找为什么这没有故障转移吗？
我最近已将 SQL Enterprise 独立 SSRS 安装迁移到新的 SQL Standard 2 节点 Basic AG。我得到了预期的“不支持扩展部署错误”，我通过从报告服务器数据库中的键表中删除旧服务器的信息来解决这个问题。我现在在该表中只有 2 行，一个 NULL 机器名和 Node1。报表服务器现在在 Node1 上运行良好，但是当我故障转移到 node2 时，当我转到 Web服务URL 链接（http://Node2:80/Reportserver）时出现“不支持横向扩展功能”错误，但不是当我转到 Web门户URL 链接 ( http://node2:80/Reports ) 时。这让我可以访问报告文件，
如果我恢复加密密钥，它可以正常工作，尽管之前已经恢复了加密密钥。
我不能在基本可用性组的两个节点上都安装 SSRS 吗？它应该只安装在 Node1 上吗？如果是这样，我仍然可以访问共享的 reportserverDB 吗？
这是我对基本可用性组的第一次尝试，自从我使用横向扩展部署以来，我在上次企业安装中根本没有遇到这个问题。
刚刚有了另一个想法……报告服务器从中提取数据的源数据库位于不同的 AG 中，因为基本 AG 中只能有 1 个数据库。如果该数据库位于不同的节点上，那么 reportserver 和 reportservertempDB 正在运行，这可能是一个问题吗？源数据库是否也需要故障转移？
我遇到了一个我无法解决的奇怪情况。我有一个运行 sql server 2016 标准的 2 节点 Basic AG。我正在尝试将报告服务器数据库添加到 AG，但在将数据库加入辅助节点时一直失败。
我做了以下事情：
回到主节点，我通过 GUI 创建了一个 AG，但是当我走到最后时，它将数据库连接到 node2 中的 AG。我得到了一些不同的错误，这基本上意味着同样的事情：
“数据库“reportserver”的远程副本尚未前滚到本地副本中包含的时间点”
“镜像数据库“reportserver”没有足够的事务日志数据来保存日志备份链。”
我知道这些意味着应该是额外的日志备份来恢复，但在此之前我刚刚进行了完整的和日志备份并将它们都恢复到辅助服务器，所以应该没有其他备份来恢复......唯一的事情我能想到的是，有些东西仍在写入主日志，但据我所知，即使是这种情况，将数据库连接到 AG 仍应作为当前未备份的部分工作日志应在同步过程中流式传输到辅助副本。我暂时跳过了监听器配置。在执行此操作之前，我还停止了两个节点上的 SSRS 服务。
有没有人遇到过这个并成功修复它？是不是因为是reportserverDB，不能和reportservertempDB加入同一个AG？
我已经尝试过自动播种和仅加入模式，奇怪的是自动播种在 AG 设置期间没有给我任何错误，但数据库从未出现在 Node2 上。当我只加入时，即出现上述错误。我对此感到非常困惑。我在这些节点上有 6 个其他数据库，每个数据库都在他们自己的基本 AG 中，我没有遇到任何问题。
这是我第一次尝试设置 SSRS，所以如果有任何问题显得很基础，我深表歉意。我已经尽可能多地进行了研究，并对以下内容感到困惑。我的环境也如下所述。
我们在 WSFC 中有一个 2 节点 AG。让我们将它们称为 sql1 和 sql2，并使用 sql-listener 的侦听器。SQL 2016 企业版。我的意图是将所有应用程序连接运行报告发送到辅助节点，以减轻主服务器的负载。节点设置为同步提交、读/写主模式和可读辅助模式。问题：
我今天遇到了一个问题，虽然我能够解决它，但我不确定是什么导致了问题的发生。
我有一列是 Varchar(20)。它仅用于存储年份数据（2010、2011 等），它正在转换为 Int 数据类型，但是当运行以下命令时，会发生错误代码。
ALTER TABLE mytable ALTER COLUMN1 int NULL
显示的错误是：Conversion failed when converting the varchar value '2010. ' to data type int.
表中有 3 行，Column1 中的值为 2010，但没有以'2010. '（句点和 10 个空格）作为值的行。我跑了
select len(Column1) from MyTable where Column1 like '%2010%'
我得到 2 行长度为 4，1 行长度为 5。在将长度为 5 的行更新为 2010 作为值后，可以更改表。
我很好奇时期和空间是从哪里来的。也很好奇 1 个字符长度的增加如何导致一个句点和 10 个空格。我在想一些类似于回车或换行的东西，但我找不到任何数据来支持它，这只是一种预感。