我们正在尝试让 Service Broker 在我们的环境中工作以解决业务案例。我不知道消息标题是否合适，但我的问题如下。但这可能不是一个好问题，所以在那之后是我们正在做的事情以及为什么我认为这是一个正确的问题。
在结束对话之前，应该在对话中发送多少条消息？
我们想使用 Service Broker 来异步更新结果表。结果表变平且快速。我们在基表上有触发器，它们发送带有表和主键的消息。我们有三个队列：
基本上，如果客户的信息更新，则会影响许多产品，因此会被发送到批量队列以进行较慢的处理。但是，如果产品更新，则会将其发送到低延迟队列。
我们重用类似于 Remus Rusanu 的博客http://rusanu.com/2007/04/25/reusing-conversations/ 的对话，除了我们根据主键的模数来做。这具有辅助主键重复数据删除的附带好处。
因此，我们正在重复使用对话并且符合我们的指导方针。使用两个线程，我能够每秒处理 125 条消息（人工丢弃数千条消息），这足以跟上生产速度（估计为 15 条消息/秒）。
但是，我们遇到的问题是，经过一段时间（约 4 小时或 120K 条消息）后，我们开始在 sysdesend 和队列表中看到阻塞和高争用。锁是 LCK_M_U 和 KEY 锁。有时，hobt 解析为 sysdesend，有时解析为特定的队列表 (queue_)。
我们有一个流程可以在 24 小时或 30 分钟不活动后结束对话，我们可以增加对话循环之前的时间。
我们使用的是 SQL 2016 Enterprise (13.0.4001.0)
清理过程每 10 分钟运行一次，以查看是否有任何空闲对话。ltd 它连续发现它们超过 3 次，它将其标记为不活动并结束对话。
如果有任何可能有益的其他细节，请告诉我。我对 Service Broker 没有太多经验，所以我不知道我们的消息/秒是低、高还是无动于衷。
更新
所以我们今天再次尝试，遇到了同样的问题。我们将对话生命周期更改为 2 小时，但没有任何影响。所以我们然后实现了 …
精简版：
我正在尝试将备份从一个 SQL 托管实例恢复到另一个 SQL 托管实例。这些在不同的订阅中。使用此处的示例 3，我至少可以看到恢复从 sys.dm_operation_status 开始，但错误消息是“订阅 [目标] 不包含 [源 SQL MI]”。
问题： 如何将数据库从一个 SQL 托管实例迁移到另一个（在不同订阅中）？我目前的解决方法是对 blob 存储执行 copy_only 并以这种方式恢复。
一旦我们启用 TDE（进行中），我们将无法对 blob 执行 copy_only 备份。然后怎样呢？
长版：
最近，我们公司开始在 SQL 托管实例（和其他 PaaS/IaaS）上运行 Azure 中的生产工作负载，并且进展顺利。尽管我确实熟悉数据库迁移服务 (DMS)，但我们有一个足够大的窗口，表明我们能够使用完整备份执行初始加载。
但是现在我们正在扩展我们的 dev/test/qa 环境，当然我们现在希望从生产环境恢复到这些环境。出于隔离目的，每个人都获得了自己的订阅。
这些命令有效，因为我至少可以在 sys.dm_operation_status 中看到恢复操作开始，但它失败并出现错误。错误是“订阅 [目标] 不包含 [源 SQL MI]”并让我相信交叉订阅还原对我们不起作用（尽管跨区域可以）。
DMS 似乎不支持使用数据库迁移服务作为源的方案。
Select-AzSubscription -Subscription $SourceSubscriptionID
$GeoBackup = Get-AzSqlInstanceDatabaseGeoBackup -ResourceGroupName $SourceResourceGroupName `
-InstanceName $SourceSQLMI `
-Name $SourceDatabaseName
Select-AzSubscription -Subscription $TargetSubscriptionID
Restore-AzSqlInstanceDatabase -FromGeoBackup `
-GeoBackupObject $GeoBackup `
-TargetInstanceDatabaseName $TargetDatabaseName `
-TargetInstanceName $TargetSQLMI ` …因此，我们的数据团队寻求帮助以解决他们遇到的问题。我最终将其追踪到了一些真正超出范围的数据 (1/1/0001) 和他们使用的 DATEDIFF 函数。虽然我已经解决了他们的问题，但实际上我并不知道 0 在他们使用时会变成什么。
我最初认为它更接近整数溢出而不是真正的转换错误，但事实并非如此。我在带有 DATEDIFF_BIG 和相同错误的 SQL 2016 框中尝试了它。我有一个样本供你们在下面一起玩，以及哪些有效，哪些无效。
/** Setup The Sample */
DECLARE @TestValue DATETIME2(7)
SET @TestValue = '0001-01-01 10:30:00.0000000'
/** Conversion Error
Msg 242, Level 16, State 3, Line 10
The conversion of a datetime2 data type to a datetime data type resulted in an out-of-range value.
*/
SELECT DATEDIFF(MINUTE, 0, @TestValue)
--Also does not work, same error.
SELECT DATEDIFF_BIG(MINUTE, 0, @TestValue)
/** Works */
SELECT DATEDIFF(MINUTE, '1/1/1900', @TestValue)
/** Works */
SELECT …