标签: sql-server

我们的应用程序由于以下原因突然停止工作The transaction log for database 'tempdb' is full due to 'ACTIVE_TRANSACTION'.。现在，它又开始工作了。但我怎样才能知道这个错误出现的确切原因呢？

我有一个存储时间序列数据的表，大约有 800 万行。表结构如下：

时间戳| 组件 ID | 参数1 | 参数2 | 参数3

我在Timestamp和ComponentID列上有一个聚集索引。（这也是我的主键）

我试图运行的查询是：-

SELECT * FROM table 
WHERE Timestamp BETWEEN '2020-01-01' 
AND '2020-01-02' 
AND ComponentId = 5

当我运行此查询时，似乎正在发生 RID 查找。我读过，只有当索引没有覆盖所有内容时才会发生这种情况，但由于我有一个聚集索引，我认为它本身应该覆盖所有内容并阻止查找。如何防止这种查找发生？

查询 1（时间戳 + 组件 ID）：-

查询 2（时间戳）：-

我发现我的数据库中的一项存在差异错误（剩余数量 <>（采购 - 销售））。到目前为止，有超过5000个项目，超过100,000笔交易。对于此计算，每次都运行相同的过程。

但只有一个项目有错误，而且只发生过一次。它似乎没有从应用程序方面发生，因为它已经运行了超过 100,000 次。数据库服务器没有受到物理保护，也没有连接到 Internet。只有我可以登录到服务器。自从我记录错误以来，程序中没有发生任何异常。我不明白上述错误是如何发生的。

我已经看到可以使用记事本打开未加密的 SQL Server 备份文件并读取其数据。以下场景是否可能？

1. 使用Live CD启动服务器并复制数据库 .mdf 文件
2. 编辑和更改它的数据（例如：一些数值）
3. 用被黑的数据库替换服务器上的原始 .mdf 文件

如果上述情况不可能发生，是否有可能是由于 SQL Server 端的错误或通信错误（而不是应用程序代码端）导致的。

有一个死锁 XDL 文件，其中列出了几个交换事件。不确定这些是好是坏，或者是什么导致了它们。是什么导致 SQL 死锁图中的交换事件？

 <exchangeEvent id="Pipe12dfb4bc900" WaitType="e_waitPipeGetRow" nodeId="28">
   <owner-list>
    <owner id="process4a9ee4eca8" />
   </owner-list>
   <waiter-list>
    <waiter id="process2612ca8" />
 </waiter-list>
  </exchangeEvent>

Points
------------------
PK  QuestionId  int (+30.000.000 distinct values)
PK  EventId     int (large batches where 80.000 rows have the same EventId)
    Value       smallint

该表大约有 4000 万行并且存在性能问题。

有两个主要查询：

关于QuestionId：

• 大约 3000 万个不同的QuestionId值（很多变化）
• 繁忙时段的大量查询（每分钟数千次）

在EventId 上：

• 将有 +150.000 行的批量更新where EventId=X来设置Value=NULL非常繁忙的时刻。

所以我第一个想获得最佳性能的想法是我制作EventId,QuestionIdClusteredIndex 以便批量更新可以轻松找到彼此接近的所有 EventId 并直接更新值。

我的第二个想法是添加一个包含QuestionId和包含列 的索引，Value以便它可以直接从索引中读取值（EventId在这种情况下无关紧要）。

但后来我想：聚集索引会重要吗？由于索引中包含的列值也需要在批量更新期间更新。

• 虽然不牺牲查询性能 - 是否可以快速获得批量更新（几秒钟），或者我必须接受这个过程在不升级硬件的情况下总是很慢。
• 还有其他想法什么是设置 ClusteredIndex / Indexes 的最佳方法？

我知道理论上我应该测试所有内容并对其进行测量，但是该站点是实时的并且被大量使用。

我是一名独立开发人员，我没有资源聘请某人。对此的任何估计猜测和想法都将非常有帮助，因为这已经为我提供了正确的方向！

当我使用创建向导或CREATE DATABASE命令在 SSMS 中创建新数据库时，该数据库将包含一个名为Searchinall的存储过程。此过程以前从未添加到新数据库中，但是从 2 天起，无论我如何创建它，它都会在每个新数据库中创建。我也尝试从这台服务器上的另一台计算机创建一个数据库，但存储过程仍然会出现。

当我尝试在线查找程序Searchinall 时，我找不到任何结果，所以我怀疑它不是一个新功能，默认情况下不应该创建任何功能。

有人可能不小心将它添加为要在服务器上的每个新数据库中创建的默认存储过程吗？如果是这样，我该如何禁用它？

在为 SQL 服务器进行常规操作系统修补后，我们遇到了一个奇怪的问题。

根据最佳实践，我们在被动上应用补丁并进行节点故障转移以使当前被动、主动，反之亦然以完成修补。

通常节点故障转移是无缝的并且在一分钟内完成。但是最近我们遇到了一个问题，在节点故障转移后需要 4 分钟才能使 SQL 联机：

我正在检查日志和事件，但找不到原因：以下是迄今为止的调查结果：

注意：SQL 服务器在 VM 上运行

1. SQL 服务器活动没有增加
2. 数据库是数据库镜像的一部分
3. 在此期间内运行时间更长的用户连接或用户查询不会增加
4. 所有数据库的 VLF 低于 500
5. 无 CPU/内存压力和 LPIM 已启用。
6. 在故障转移期间似乎终止长时间运行的进程是 EXEC sp_server_diagnostics 20 running for last 86745234 secs

请协助我还应该检查什么才能找到根本原因？

编辑 - 我尝试分析集群日志，可以看到 sql 离线已启动，但我不确定它在内部花了至少 4 分钟的时间来实际关闭 sql 并将其恢复。4 分钟后，sql 错误日志将数据库的所有条目都调高了大约 10 秒。所以看起来 DB 可能没有参与这里来减慢进程。

编辑 - 当前检查时的一些 VLF 信息

在下面的查询计划 - https://www.brentozar.com/pastetheplan/?id=H1dwOCHed（它有 3 个部分，最后一个是问题），最底部有一个节点，消耗了 37% 的资源. 这是实际的查询计划，而不是估计的查询计划。但是，当通过 Set Statistics IO 查看逻辑读取时，它引用的表根本不显示。这包括 ActivityFeedTeamCache 和 ActivityFeedCache 的 2 个部分。

过去，我已经能够使用逻辑读取作为性能的一个很好的代理。减少逻辑读取，您就为性能做了正确的事情。

但是，由于在这种情况下，对于最差的块（ActivityFeedTeamCache、ActivityFeedCache、Locales）没有逻辑读取，那么什么是测试性能的好代理？仅仅是实际执行计划中的成本百分比下降了吗？

我正在尝试根据参数从表中获取数据，

Declare @Loadtype varchar(10) = 'A'

Select *
from TableA (if  @Loadtype = 'A')

Select *
from TableB (if  @Loadtype = 'B')

不知道我怎么能做到这一点。

非常感谢，乌代

我正在尝试在从 Azure 云环境备份的本地计算机中还原 SQL Server 数据库实例，但收到以下消息：

System.Data.SqlClient.SqlError：数据库已在运行版本 15.00.2000 的服务器上备份。该版本与运行版本 15.00.2000 的服务器不兼容。在支持备份的服务器上还原数据库，或者使用与此服务器兼容的备份。

在此处输入图片说明

版本似乎完全相同，所以对我来说没有任何意义。我错过了什么吗？或者您根本无法从 Azure 云恢复备份？

提前致谢。