SQLServer发布服务器数据库没重定向导致错误21871，远程修复支持故障处理

开始）

当您在使用SQL Server的复制功能，特别是事务复制时，可能会遇到一个令人头疼的错误：错误21871，这个错误信息通常会伴随着类似“在配置为使用数据库别名的服务器上，未将数据库‘%s’重定向到数据库‘%s’”的描述，这个问题就像是您告诉邮差把信送到“A小区1号楼”，但A小区最近改名成了“B小区”，而邮差手里的旧地图还没来得及更新，于是他找不到地方，信就送不过去了，报错了。

这个错误的根源,引用自微软官方技术文档和众多技术社区（如MSDN、SQLServerCentral）的讨论，核心在于发布服务器的数据库名称发生了改变，但复制配置（Replication Configuration）没有相应地更新，复制配置中记录的是旧的数据库名称，而实际数据库已经用了新名字，导致分发代理（Distribution Agent）或日志读取器代理（Log Reader Agent）在尝试连接发布数据库以获取数据变更时，无法找到正确的目标，从而触发错误21871。

为什么数据库名称会改变呢？常见的情况有几种，第一种是，数据库管理员在执行数据库还原（Restore）操作时，无意中或有意地修改了数据库名称，从生产环境备份一个叫“SalesDB”的数据库，还原到测试环境时为了方便管理，改名为“SalesDB_Test”，如果在测试环境中配置了复制，而这个复制是依赖于原始名称的，那么错误就会发生，第二种情况是，在故障转移群集（Failover Cluster）或可用性组（Always On Availability Groups）环境中，有时在切换或重新配置过程中，数据库的上下文或别名设置可能出现不一致，虽然数据库逻辑名称没变，但复制组件感知到的“地址”出现了偏差，也会引发类似问题，第三种情况相对少见，但确实存在，即直接使用T-SQL语句ALTER DATABASE修改了数据库的名称。

当这个错误发生时,最直接的影响是数据复制会停止，对于事务复制来说，这意味着发布服务器上的数据变更（如新增、修改、删除记录）无法被分发和传递到订阅服务器，订阅服务器上的数据就会变得陈旧，与发布服务器不同步，如果这是一个关键的业务系统，比如用于报表或读写分离的子系统，那么业务将会受到直接影响，报表数据不准确，或者应用程序读取到过时信息。

要修复这个错误,核心思路就是“更新地址簿”，也就是修正复制配置中的数据库名称，使其与实际数据库名称一致，由于这涉及到系统表等核心元数据的修改，操作必须非常谨慎，最好在业务低峰期进行，并强烈建议提前备份相关数据库（尤其是发布数据库、分发数据库和订阅数据库），以下是基于微软支持知识库和资深DBA实践经验总结的修复步骤。

第一步,也是最重要的一步，是确认当前错误的具体信息，您需要打开SQL Server Management Studio（SSMS），连接到发布服务器实例，展开“复制”文件夹，右键点击“本地发布”下的相应发布，选择“查看日志读取器代理状态”或“查看快照代理状态”，查看详细的错误消息，确认错误号是21871，并记下消息中提到的“期望的数据库名”和“实际的数据库名”，这一步是为了确保我们完全理解问题所在。

第二步,停止所有相关的复制代理，这是为了防止在修改配置的过程中，代理仍在尝试工作，可能导致数据不一致或锁冲突，您需要停止日志读取器代理（Log Reader Agent）和分发代理（Distribution Agent），可以在SSMS的“复制监视器”中找到这些代理，并右键选择“停止”。

第三步,执行核心的修复操作——更新系统元数据，这需要通过T-SQL命令在发布服务器实例上执行，您需要以系统管理员身份（通常是sa账号或具有sysadmin角色的账号）登录，并连接到发布数据库所在的实例，关键是要修改distribution系统数据库（如果分发器与发布器是同一实例）或发布数据库的元数据，一个常见的操作是使用系统存储过程sp_changepublication或直接更新系统表MSpublications（此操作风险较高，一般不推荐直接改表），更安全、更标准的方法是使用sp_removedbreplication存储过程先移除复制，然后重新配置，但这意味着需要重建整个复制拓扑，工作量较大。

针对错误21871,微软提供了一个更直接的解决方案，即使用sp_changedistpublisher存储过程，这个存储过程专门用于更改与分发发布服务器关联的属性，您需要连接到分发服务器实例（如果分发是远程的，则连接到远程分发服务器），然后执行类似下面的命令：

USE distribution;
GO
EXEC sp_changedistpublisher
    @publisher = 'YourPublisherServerName',
    @property = 'working_directory',
    -- 这里可能需要指定其他属性，但核心是修改发布数据库的映射
    -- 更精确的方法是针对特定的发布数据库进行操作

根据具体案例,有时更有效的方法是直接修改MSpublications表中对应发布的publisher_db字段，但再次强调，直接操作系统表风险极高，除非您非常清楚后果，否则不应尝试，一个相对折中的方法是，先编写查询语句确认需要修改的记录，

USE distribution;
GO
SELECT publisher_db, publisher_db FROM MSpublications WHERE publisher_db = 'OldDatabaseName';

确认无误后,再在严格的备份和测试环境下，考虑使用UPDATE语句进行修改，但最佳实践仍然是寻求官方支持或使用官方提供的脚本。

第四步,在完成元数据更新后，重新启动之前停止的复制代理，首先启动日志读取器代理，然后启动分发代理，之后，密切监视复制监视器中的状态，查看是否有新的错误产生，并确认积压的命令（Pending Commands）数量是否开始下降，这表示复制正在恢复正常。

第五步,进行验证，可以在发布服务器上对已发布的表做一些简单的数据变更（在一个测试表中插入一条记录），然后观察订阅服务器上是否能在预期的时间内看到这条新记录。

为了避免未来再次出现错误21871,数据库管理员应该建立规范的操作流程，在进行任何可能改变数据库名称的操作（如还原、迁移）之前，必须先评估其对复制等依赖关系的影响，如果必须重命名数据库，正确的做法是：首先删除现有的复制发布和订阅，然后执行数据库重命名操作，最后再重新建立复制配置，虽然这个过程比直接修改元数据要繁琐，但它保证了配置的干净和一致性，避免了潜在的风险。

错误21871是一个典型的因配置信息过时而导致的连接故障,解决它需要准确的问题定位、谨慎的系统操作以及对SQL Server复制机制的基本理解，在不确定的情况下，寻求微软官方支持或有经验的数据库专家的帮助是明智的选择。 结束）