我有一个问题，当主数据库负载很重时，软件驱动的复制系统将无法完全复制。例如，如果我们执行一个 sproc 500 次，实际上可能会执行 450 次。但只有当我们处于疯狂的数据库负载下时（一个例子是 SAN 管理员在工作时间更新固件）。我关心的是为每条消息创建事务，等待它们超时，然后回滚，因为目标 SQL 服务器有可能位于另一个数据中心的 WAN 上。
询问：我想重振我的 DEV SQL 服务器，以便在开发中复制大量的锁定/cxpacket 等待。但还不足以让所有访问完全死锁数小时，也许只是为了模拟数据包丢失。
场景：服务器 B（实用程序机器）有一个本地 SQL Express 实例。它用于瞬态数据。它针对目标数据库触发一系列存储过程以插入新行，然后将新行插入到由 PK 链接的子表中。等等等等。
通常它只是花花公子。除了生产 DBA 之外，不要让该系统的主题专家有任何控制权或对锁统计信息的可见性。我有完全的控制权，可以分析将数据传播到目的地的系统，但没有分析另一端发生的事情，除了等待……等待……等待……我被锁定了吗？我不知道！
我想在实验室中对此进行模拟并尝试调整所使用的存储过程。我正在考虑心跳更新 anx xp_cmdshell 更新到簿记表，并且还使用 xp_cmdshell 使用 ping 分析来查询/优化/调整事务，并在必要时回滚事务，以防所有事务都未提交。然后再试一次，也许在另一个分布式主机上。
问题：上次发生这种情况是因为 TEMPDB 非常庞大（正在使用大量临时表）并且必须分页。DBA 表示没有任何问题，但也报告磁盘队列长度一次超过 50+ 数小时。必须喜欢它。
刚发现Hammer DB，它是一个开源的、可配置的负载生成器。我们将其用于 VM 开销评估。您应该能够选择合适数量的模拟用户来对您的系统施加压力而不会破坏它。
要对系统施加压力，您可以增加负载或减少资源。
那里有许多商业负载创建包，可能还有一些免费软件。不过，这听起来好像您已将它隔离到一个 SP，因此一个自定义脚本并行触发 500 个示例应该可以解决问题。在数据库服务器上运行脚本将对 SQL Server 造成更大的压力。我有一些 Powershell 脚本，可以一次最大化四核服务器几分钟！将数据与某些数据相乘
INSERT dbo.Xx SELECT * FROM dbo.Xx（通过适当的主键调整）也会使 SP 更加努力地工作。在资源方面，减少最大服务器内存将导致更多的缓冲池分页，并且可能导致更多的 SP 重新编译。设置实例处理器 affinint 使其具有更少的可用内核将导致每个内核更加努力地工作。当然，这些可能会导致细微的次要变化，从而影响您要测量的内容。例如，新的、不同的执行计划。
在监控方面，我发现这些DMV有助于理解锁定。
HTH