小编Dan*_*vey的帖子

我的计算机上安装了 SQL 2012 SP1。我做了一个数据库的备份test.bak。

我有一个test2同名的数据库，但数据发生了变化。

我想test.bak通过test2数据库恢复。

我总是收到错误：

错误 3154：备份集包含现有数据库以外的数据库的备份。

我试过：

1. 我右键单击 test2 -> Restore database -> From device

   我选择test.bak并检查了With Replace但我收到错误。

2. 然后我尝试右键单击 test2 -> Restore file and filegroups

   我选择test.bak并检查了With Replace但我收到错误。

我可以删除旧数据库，然后使用正确的名称恢复备份，但是当我使用 SQL 2008 时，恢复现有数据库没有问题。

好像是因为我用的是SQL2012，所以经常出现这个错误！

我正在使用 Microsoft SQL Server 2016 (SP2-CU11) (KB4527378) - 13.0.5598.27 (X64) Nov 27 2019 18:09:22 版权所有 (c) Windows Server 2012 R2 上的 Microsoft Corporation 标准版（64 位）标准 6.3（内部版本 9600：）

该服务器位于 SSD 驱动器上，最大内存为 128 GB。Parallelism 的 CostTheshold 是 70，MaxDegree of Parallelism 是 3。

我有一个“行程”表，它由 23 个外键引用，带有 ON DELETE CASCADE 选项。

这个表本身并没有那么大（530 万行，1.3 GB 数据）。但是在 23 个引用的表中，有两个表非常大（超过 10 亿行，每行 54 和 69 GB）。

问题是当我们尝试删除“Trips”表中的少量行（假设为 4 行）时，SQL 估计将要删除这么多行，它需要 10GB 的 RAM，估计将有数百万行返回，并锁定表。一切都停止，其他查询阻塞，应用程序超时。

以下是 1 个删除语句的主表和行数：

• 行程（4 行）
• 细分（27 行，与 SegmentId 的旅行相关）
• 配置文件（2012 行，按 SegmentId 与 Segments …

我的其中一台 SQL Server 2016 Standard 服务器出现问题。我有 8 台生产服务器，这是唯一一台在日志中没有任何痕迹的情况下随机崩溃的服务器。

我在其上启用了 system_health。我注意到我在系统健康女巫中有一行是“sql_exit_invoked”。

我正在尝试查找有关该行的更多信息。这是什么意思？我在互联网上找到的唯一信息是它在调用 SQLExit() 时发生，并且它只从 SQL 2012 开始记录。（链接在 msdn 网站上可用）

所以我的问题是：我应该担心在我的日志中看到这个吗？我只在我有问题的服务器上发现了这一点，而在其他 7 台服务器上都没有。（都是SQL Server 2016标准版）

有人可以给我更多关于这方面的信息吗？

我在 Windows Server 2012 R2 Standard 6.3 上使用 Microsoft SQL Server 2016 (SP2-GDR) (KB4505220) - 13.0.5101.9 (X64) Jun 15 2019 23:15:58 版权所有 (c) Microsoft Corporation 标准版（64 位） （内部版本 9600：）

数据库大小约为 870 GB。这是 SQL 标准，我在服务器上有 128 GB 的 RAM。数据库位于 SSD 驱动器上。数据文件与日志文件位于不同的驱动器上，Tempdb 也有自己的 SSD 驱动器。服务器平均获得大约 1200 个查询/秒，它可以高达 2000 个查询/秒。重新编译保持较低，每秒只有 1 到 8 次。页面预期寿命不错，平均 61 分钟。

服务器有 6 个物理核心 + 超线程。

我们在数千个设备连接并尝试将更改与跟踪键同步的系统上大量使用 SQL Server 的更改跟踪。

它通常运行良好，但有时，有一天或另一天，服务器的闩锁会猛增，从 0 毫秒到平均 60677 毫秒。

当我检查正在运行哪些查询时，我只能看到同步查询，全部被阻止，带有“PAGELATCH_UP”，全部试图访问更改跟踪表，被阻止的 300 多个查询。

我有几个问题：

• SQL Server 是否在查找更改跟踪更改时锁定整个表？
• 使用 SQL Entreprise 会得到更好的结果还是不会改变任何东西？
• 知道为什么更改跟踪在大多数情况下运行良好，但每周都没有明显原因崩溃吗？

这些是我的更改跟踪表大小。我的查询阻塞的表是前三个表，只有几 …

我在 Windows Server 2012 R2 Standard 6.3 上使用 Microsoft SQL Server 2016 (SP2-GDR) (KB4505220) - 13.0.5101.9 (X64) Jun 15 2019 23:15:58 版权所有 (c) Microsoft Corporation 标准版（64 位） (Build 9600

:) 我有多个数据库，在高插入/更新表上启用了 CHANGE_TRACKING。我的保留期是 2 天，启用了自动清理。数据库兼容性设置为 130 (SQL 2016)

跟踪的一些表很大，每天可能有数千次插入/更新。这是change_tracking 表的内容。

这是我们为获取更改而执行的查询示例。

SELECT Columns
FROM CHANGETABLE(CHANGES MyTable, @TrackingKey) AS CT 
INNER JOIN MyTable b ON b.Key=CT.Key
WHERE b.Status = 1

我不时看到在某些表上获取最新更改的查询需要很长时间才能完成并生成大量 CPU。为了解决这个问题，我在每晚运行的更改跟踪表上设置了每日更新统计信息。它有很大帮助，但有时，在用户活动频繁的日子里，即使在白天，我也必须运行此更新统计信息。当我在这些表上运行更新统计信息时，情况恢复正常，获取最新更改的查询可以正常运行一段时间。

我们对应用程序的一些重要部分使用更改跟踪，因此它必须起作用。

是否有任何选项，我可以启用跟踪标志来帮助更改跟踪统计信息？任何对高活动数据库进行更改跟踪的人都可以给我一些建议吗？

所以我最终决定做一个工作来检查自上次统计更新以来更改跟踪表是否更改了超过 20k 行，然后该作业将更新更改跟踪表上的统计信息。

如果它可以帮助其他人，我会将查询放在这里。此查询为您提供更改跟踪表的所有统计信息，其中该表自上次更新统计信息以来更改了 2 万次以上。它为您提供了一个带有要更新的 object_name 的“更新统计信息”。您只需要在您的数据库上运行查询的结果。我会根据我的工作量对其进行微调，看看 20k 是否是最好的数字。

SELECT 
 -- st.object_id                          AS [Table ID]
 --, OBJECT_NAME(st.object_id) …

在过去的几个月里，我的 SQL Server 2019 服务器运行良好，但自上周五以来它开始自行停止。今天早上，我在上面安装了最新的累积更新。

这是我的版本

Microsoft SQL Server 2019 (RTM-CU8-GDR) (KB4583459) - 15.0.4083.2 (X64) 2020 年 11 月 2 日 18:35:09 版权所有 (C) 2019 Microsoft Corporation Developer Edition（64 位），Windows Server 2019 Standard 10.0（内部版本 17763：）（管理程序）

我也遇到了 SQL Server 2019 标准版 (RTM-CU8-GDR) 的问题。

每次都会创建一个小型转储。分析转储后，我可以看到内核基础异常。

这台服务器只运行 SQL Server，我没有在机器上运行更多的东西。

在 SQL 的日志文件中，我看到在此消息之后进行了转储。

在 Windows 事件查看器中，我只有一条错误消息，指出 SQL 正在停止。

就在那个错误之前，我有关于 SQLException64 的树“Windows 错误报告”错误。

重新启动 SQL Server 不会改变任何东西。但是，如果我打开 SQL 管理控制台并启动 SQL 服务，它就可以正常启动。

我真的不知道在哪里检查，如何进一步诊断。

这是迷你转储文件。

2021-01-18 10:15:18.56 spid58      ex_terminator: Possible termination due to exception during stack unwinding. …

我们使用的是 SQL Server 2016 标准版 (SP2-CU2)。我们有几台服务器，每台服务器托管几十到数百个数据库。我们从未在我们的数据库上启用查询存储。

我知道打开查询存储进行调优有很多好处。我想知道，是否有任何情况下，当查询储存应该不被打开？或者我应该在所有数据库上打开它？

已编辑

以防万一它可以帮助其他人。我最终所做的是每天启用查询存储几个数据库并进行监控。到目前为止，我已经在几乎所有的数据库上启用了查询存储，而没有任何性能影响。事实证明，它在调查问题时很有用。