我们有一对 SQL2000 服务器,它们正在使用合并复制同步几个数据库。在过去几个月的某个阶段,其中一个数据库的合并代理消失了。很难说这是什么时候发生的,这个系统每年只使用几个月几次。
据我所知(我不是复制专家)订阅和发布仍然存在,但是由于缺少合并代理,其中之一不再进行合并复制。另一个是完美的合并复制。
数据库之间的架构仍然相同,但数据已更改。订阅服务器具有比发布服务器更新的数据。
让合并代理返回的最佳方法是什么?我查看了 BOL,搜索了网络,所有这些复制的东西都令人困惑地可怕!
我们有一对 SQL2000 服务器,它们正在使用合并复制同步几个数据库。在过去几个月的某个阶段,其中一个数据库的合并代理消失了。很难说这是什么时候发生的,这个系统每年只使用几个月几次。
据我所知(我不是复制专家)订阅和发布仍然存在,但是由于缺少合并代理,其中之一不再进行合并复制。另一个是完美的合并复制。
数据库之间的架构仍然相同,但数据已更改。订阅服务器具有比发布服务器更新的数据。
让合并代理返回的最佳方法是什么?我查看了 BOL,搜索了网络,所有这些复制的东西都令人困惑地可怕!
是的,这很可怕。
我记得不久前,如果复制不是至少每 2 周完成一次(我认为),默认情况下,订阅将过期并消失。自从我这样做以来已经有好几年了,所以这真的很模糊。对我们来说,当最终用户休假 2 周时,工作站订阅将过期(在高速互联网时代之前,我们对现场单元使用合并复制)。
我们将设置更改为到期前 6 个月。
不知道这是否是您的问题,由于复制,该项目有很多深夜和挠头……以及我们睡觉时的噩梦。
编辑:我刚刚记得的其他东西。复制将使用 SQL 代理帐户正在运行的权限运行。因此,如果 SQL 代理服务使用的帐户有任何问题,将对复制产生不利影响。
我也不是复制方面的专家,但是当我们不得不重做合并复制时,我只是确保发布者拥有使用 sql 数据比较工具的最新数据并重新创建整个内容。我不知道这是否适合你们,但我们的数据库非常小,而且地理上并不遥远。
我们使用的工具是 Apex SQL Data Diff。我敢肯定还有很多其他的选择。