Jonathan Fite's questions

对于给定的当前秒数和上下边界，我需要找到所有落在该范围内的秒数，并在 59 秒标记处结束。

不用说沙拉这个词，这里有一些示例输入和输出。

• 如果输入为 58 秒且间隔为 +/- 5 秒，那么我想返回 58、59、0、1、2、3 和 57、56、55、54、53
• 如果 Input 是 22 且间隔相同，那么我想返回 22、23、24、25、26、27 AND 21、20、19、18、17
• 如果 Input 为 5 且间隔相同，那么我想返回 0、1、2、3、4、5 AND 5、7、8、9、10。

我一直在使用 TIME 数据类型来尝试使用内置的 datemath 来处理 59 秒标记附近的环绕，但我取得的成功有限。这里包括我的完整非工作版本。

我对代码的状态表示歉意，我已经研究了一段时间了，我选择留下所有的点点滴滴来充分说明我的尝试。如果我找不到更优雅的解决方案，我将不得不为我们的初始间隔值建立一个带有“正确”答案的计数表，但如果可能的话，我希望拥有比这更大的灵活性。

DECLARE @CurrentSecond SMALLINT = 22 -- DATEPART(SECOND, SYSUTCDATETIME()) 
DECLARE @LowerBoundary INT  = -5
DECLARE @UpperBoundary INT = 5

;WITH CTE_Parts AS
        (
        SELECT P.ID 
            , LowerBound = DATEPART(SECOND, DATEADD(SECOND, @LowerBoundary, CONVERT(TIME, '00:00:' + CONVERT(NVARCHAR(20), P.ID))))
            --, lowerBoundTime = DATEADD(SECOND, @LowerBoundary, CONVERT(TIME, '00:00:' + CONVERT(NVARCHAR(20), P.ID)))
            , UpperBound = DATEPART(SECOND, DATEADD(SECOND, @UpperBoundary , CONVERT(TIME, '00:00:' + CONVERT(NVARCHAR(20), P.ID)))) 
            --, UpperBoundTime = DATEADD(SECOND, @UpperBoundary , CONVERT(TIME, '00:00:' + CONVERT(NVARCHAR(20), P.ID)))
            , C.LowerBoundary_Current
            --, C.LowerBoundTime_Current
            , C.UpperBoundary_Current
            --, C.UpperBoundTime_Current
        FROM (VALUES (0), (1), (2), (3), (4), (5), (6), (7), (8), (9)
                    , (10), (11), (12), (13), (14), (15), (16), (17), (18), (19)
                    , (20), (21), (22), (23), (24), (25), (26), (27), (28), (29)
                    , (30), (31), (32), (33), (34), (35), (36), (37), (38), (39)
                    , (40), (41), (42), (43), (44), (45), (46), (47), (48), (49)
                    , (50), (51), (52), (53), (54), (55), (56), (57), (58), (59)
                    ) AS P (ID)
            OUTER APPLY (SELECT DATEPART(SECOND, DATEADD(SECOND, @LowerBoundary, CONVERT(TIME, '00:00:' + CONVERT(NVARCHAR(20), @CurrentSecond)))) AS LowerBoundary_Current
                                , LowerBoundTime_Current = DATEADD(SECOND, @LowerBoundary, CONVERT(TIME, '00:00:' + CONVERT(NVARCHAR(20), @CurrentSecond)))
                                , DATEPART(SECOND, DATEADD(SECOND, @UpperBoundary, CONVERT(TIME, '00:00:' + CONVERT(NVARCHAR(20), @CurrentSecond))))  AS UpperBoundary_Current
                                , UpperBoundTime_Current = DATEADD(SECOND, @UpperBoundary, CONVERT(TIME, '00:00:' + CONVERT(NVARCHAR(20), @CurrentSecond)))
                            ) AS C
        )
SELECT * 
    , Ignore = CASE WHEN @CurrentSecond + @UpperBoundary <= 59 AND @CurrentSecond + @LowerBoundary >= 0 AND ID BETWEEN LowerBoundary_Current AND UpperBoundary_Current THEN 1 
                    WHEN NOT(@CurrentSecond + @UpperBoundary <= 59 AND @CurrentSecond + @LowerBoundary >= 0)
                        AND ID >= LowerBoundary_Current
                        OR ID <= UpperBoundary_Current
                        THEN 1
                    ELSE 0 END
FROM CTE_Parts AS P 
ORDER BY P.ID

绝对清楚，上面没有做我想要做的事情（除了给我一个从 0-06 的 ID 值列表）

精简版：

我正在尝试将备份从一个 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 `
    -TargetResourceGroupName $TargetResourceGroupName

有什么建议、想法吗？如有必要，我愿意使用各种 Azure PowerShell 的预览版，尽管我没有发现任何东西表明它在那里有所不同。

可能的解决方法

我确实从我们的一位 Microsoft 联系人那里获得了一个链接，该链接似乎表明您可以在同一个订阅中建立一个托管实例，恢复到它，然后将托管实例移动到另一个订阅。我没有尝试过，所以我不知道。他们提供的链接在这里，尽管我怀疑它的有效性。

因此，我们的数据团队寻求一些帮助来解决他们遇到的问题。我最终将其追踪到一些真正超出范围的数据（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 DATEDIFF(MINUTE, CAST(0 AS DATETIME), @TestValue)

/** Doesn't Work, you can't cast 0 to a DATETIME2 */
--SELECT DATEDIFF(MINUTE, CAST(0 AS DATETIME2), @TestValue)

/** Works (or no error, which is fine)*/
SELECT DATEDIFF(MINUTE, 0, TRY_CAST(@TestValue AS DATETIME))

额外的问题，因为 0 在 DATETIME2 的所有情况下都不起作用，还有什么替代方法？

我们决定做什么

因此，我开始建议我的团队执行以下操作，因为您在很多 datemath 示例（每月的第一天等）中看到 0。因此，我建议您将 0 显式转换为 datetime，然后继续。这将在仍然工作时避免错误。所以：

DATEDIFF(MINUTE, CAST(DATETIME, 0), <Date>)

我们正在尝试让 Service Broker 在我们的环境中工作以解决业务案例。我不知道消息标题是否好，但我的问题如下。但这可能不是一个好问题，所以这就是我们正在做的事情以及为什么我认为这是一个正确的问题。

在结束对话之前，应该在对话中发送多少条消息？

我们想使用 Service Broker 来异步更新结果表。结果表扁平且快速。我们在基表上有触发器，它们使用它们的表和主键发送消息。我们有三个队列：

• 低延迟 - 目标是 15 秒处理。它处理与特定项目相关的更改项目。
• 批量队列 - 目标是 5 分钟处理。它会处理影响数百（或数千）项的更改。它分解了受影响的项目列表并将它们提供给延迟低延迟队列。
• 延迟低延迟 - 目标是处理 30 分钟。这会处理项目，但仅来自批量队列。

基本上，如果客户的信息更新，这会影响许多产品，因此会被发送到批量队列以减慢处理速度。但是，如果产品得到更新，则会被发送到低延迟队列。

我们重复使用类似于 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)

1. 触发触发（发送到低延迟或批量）
2. 查找或创建对话句柄。
3. 发信息
4. 队列激活程序
5. 更新结果表

清理过程每 10 分钟运行一次，以查看是否有任何空闲对话。ltd 它连续找到它们超过 3 次，将其标记为非活动并结束对话。

如果有任何其他可能有益的细节，请告诉我。我对 Service Broker 没有太多经验，所以我不知道我们的消息/秒是低、高还是无关紧要。

更新

所以我们今天又试了一次，遇到了同样的问题。我们将对话生命周期更改为 2 小时，但没有任何效果。所以我们然后实施了 150 技巧，它有同样的问题。

在 SEND CONVERSATION 上等待大量等待，在 sysdesend 上等待。有没有人有任何进一步的想法？

更新 2

今天我们运行了更长时间的测试，在其中一个 17 分钟的样本时间段内，我们在 4 个对话句柄上处理了 41K 条消息。我们能够跟上，除了接近尾声时 sysdesend 和队列表上的锁变得太多，我们在停止它之前开始落后。我们似乎在处理消息时没有问题，没有东西进入队列：我们可以将它们拉下来并以至少 5 倍的速度处理它们。基于添加消息，我们的速度似乎受到限制。

在后来的测试中，我们删除了占消息的 80% 的触发器之一。即使负载大大减少，我们也开始看到相同的等待。

更新 3

谢谢你，Remus 的建议（也感谢你发布关于这个主题的如此优秀的博客文章，它们有助于达到这一点）。

我们今天再次运行它并且做得更好（因为我们在看到等待之前走了更长的时间，甚至在它使我们瘫痪之前更长时间）。所以，细节。

我们改变了：

• 将每个线程维护的对话数量从 1:1 增加到 2:1。基本上，我们有 4 个线程的 8 个对话句柄。

• 合并批量队列（因为一条传入消息可能意味着数百条传出消息）以合并为更少、更大的消息。

关于此尝试的注意事项：

• 禁用目标队列激活过程。阻塞没有变化（我们等了 5 分钟），消息确实被发送到了 sys.transmission_queues。

• 监控 sys.conversation_endpoints。这个数字非常迅速地从 0 变为 13K，然后全天缓慢上升，大约 5 小时后最终达到 25K。阻塞直到达到 16K+/- 才开始发生

• 我进入 DAC 并为队列运行 DBREINDEX 命令，尽管从查询中发现，在清理出现并将计数降至 0 之前，幽灵记录从未超过 200 条左右。

• 当我结束测试时，sysdesend 和 sysdercv 的计数相同，均为 24,932。

• 我们在 5 小时内处理了约 31 万条消息。

在事情崩溃之前我们已经走了这么远，以至于我真的认为这次我们会成功。明天我们将尝试强制消息通过线路。