场景

在我们的复制方案中，我们复制了许多表，包括包含二进制图像数据的 photos 表。所有其他表都按预期复制，但照片表没有。我怀疑这是因为照片表中的数据量较大，或者可能是因为图像数据是 varbinary 字段。但是，使用较小的 varbinary 字段没有帮助。

配置信息

这里是一些配置信息:

每张图片的大小可以在 65-120 Kb 之间
修订和批准的副本与缩略图一起存储，因此单行可能接近 ~800Kb
我曾经遇到过“max text repl size”配置字段的问题，但我已经使用 sp_configure 和 reconfigure with override 将其设置为最大值
照片是根据“已发布”字段过滤的，其他工作表也是如此
数据库使用相同的本地数据库服务器(在开发环境中)并配置为事务复制
复制的数据库使用“推送”订阅

另外，我注意到有时重新生成快照并重新初始化订阅会导致图像复制。考虑到这一点，我将快照代理配置为每分钟左右重新生成一次快照以用于调试目的(显然这对于生产环境来说太过分了)。然而，这并没有帮助。

是什么导致 photos 表无法复制而其他所有表都没有问题？有没有解决的办法？如果没有，我将如何进一步调试？

我使用 SQL Server Profiler 和复制监视器来查找错误。不存在错误。据我所知，该操作只是默默地失败了。

我在 Windows Server 2003 Service Pack 2 上使用带有 Service Pack 3 的 SQL Server 2005。

我很难发现 Philippe Grondier他在下面的回答是绝对正确的。图片、视频和其他二进制文件不应存储在数据库中。 IIS 处理这些文件的效率比我多。

最佳答案

对于您的问题，我没有直接的答案，因为我们的标准政策一直是“永远不要在(数据库)字段中存储(图片)文件”。我们的解决方案不仅适用于图片，而且适用于任何类型的文件或文档，现在已成为标准:

我们的数据库中有一个“文档”表，其中存储了文档/文件名和相关文件夹(为了获得唯一的文档/文件名，我们从“文档”的主键/uniqueIdentifier 值生成它们 table )。

这个“文档”表在我们不同的订阅者之间复制，就像所有其他表一样

我们有一个“文档”文件夹和子文件夹，可在我们的每个数据库服务器。
然后使用一些文件和文件夹复制软件(allwaysynch 是一个选项)独立于数据库复制文档文件夹
主发布者的文件夹可以通过 ftp 完全访问，用户试图阅读在他的本地服务器上(仍然)不可用的文档将被建议通过 ftp 客户端软件(例如 coreFTP 及其命令)从主服务器下载它行选项)

关于sql-server-2005 - SQL Server 2005 : Replication, 变量二进制，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/738121/