标签: tempdb

我们的 Ola Hallengren IntegrityCheck 作业由于在用户数据库上运行 DBCC CHECKDB 时发生缓冲区锁存超时而失败。

但是，报告的缓冲区锁存器超时位于 TempDB（数据库 ID 2）中。

作业的输出：

Date and time: 2022-01-22 09:04:15 [SQLSTATE 01000]
Database context: [master] [SQLSTATE 01000]
Command: SET LOCK_TIMEOUT 600000; DBCC CHECKDB ([SentryOne]) WITH NO_INFOMSGS, ALL_ERRORMSGS, MAXDOP = 4 [SQLSTATE 01000]
Msg 845, Sev 17, State 1, Line 1 : Time-out occurred while waiting for buffer latch type 2 for page (6:222), database ID 2. [SQLSTATE 42000]
Outcome: Failed [SQLSTATE 01000]
Duration: 12:40:32 [SQLSTATE 01000]
Date and time: 2022-01-22 21:44:47 [SQLSTATE …

因此，理想情况下，您希望适当地预先调整 TempDB 数据和日志文件的大小，以便这不是问题，但有时流氓开发人员会在工作时间内在生产服务器上运行疯狂的大型查询，从而导致 TempDB 数据文件爆炸巨大的。

如果 TempDB 确实是驱动器上唯一的东西，那么我可能就这样保留它，但在某些服务器上，我有几个 SQL 实例，它们都共享同一个 TempDB 驱动器。

那么如何在不重启实例的情况下缩小这些 TempDB 数据文件呢？

我通常会尝试：

DBCC SHRINKFILE (name = 'tempdev', size = 5000)

这在 SQL 2000 和 2005 中相当一致地工作（假设实际的 tempdb 活动已经逐渐减少），但在 2008 年似乎不经常工作（在我当前的服务器上，它只适用于 4 个数据文件中的 1 个，其他人继续保留大 2-3 倍）。

假设我有一个比 LOG 和 tempdb（通过随机写入速度衡量）磁盘快 50 倍的数据磁盘。（不要问为什么这是我们会在需要时修复的东西）

我有一个表，它有 1900 万行，大约有 30 个索引（所以基本上很重要）。

如果我的磁盘速度与数据磁盘相同，那么 LOG 和 tempdb 的磁盘速度会增加多少因素。

编辑： 更多的统计数据。

我们已将 LOG 移至 RAID 数据驱动器作为测试，遗憾的是 REBUILD 的速度没有提高。还是1小时。

• tempdb 在它自己的 Raid10 阵列上
• LOG 在它自己的 Raid10 阵列上

• 数据在它自己的 Raid10 阵列上

• RAM > 100 Gb（是 100 Gb）并且对使用它创建数据或索引的 SQL 没有限制

请注意，这不是一个事务系统，而是一个数据仓库。

由于我们的一个表增长超出了 INT 的范围，这是在生成 DB 时未预测到的，我们需要将 PK 字段改为 BIGINT。

然而，在处理该表的第一步中，我们遇到了有关 tempdb 空间使用的问题：尝试删除其上的主键约束，以便我们可以更改它。我们的测试环境都没有为 tempdb 保留超过 50 GB 的空间，而该表目前占用大约 120 GB 的空间。该表只有 5 列，它们仅包含其他 INT 和一些短的 varchar。

在涉及 tempdb 和 logfile 时，你们有没有更好的，也许更轻松的建议来进行相同的更改？该表只有几列，所有列都包含很少的数据。示例如下，尽可能简单。

ALTER TABLE OURTABLE DROP CONSTRAINT OURTABLE_PK

ALTER TABLE OURTABLE ALTER COLUMN OURTABLE_ID BIGINT NOT NULL

ALTER TABLE OURTABLE ADD CONSTRAINT OURTABLE_PK PRIMARY KEY CLUSTERED (OURTABLE_ID)

谢谢！

我一直在考虑创建一个具有相同定义和 BIGINT 作为批量插入的新表，然后在删除旧表的同时重命名它。但我不确定这是否会被证明是更好的解决方案，因为无论如何都必须在之后加入约束。

我有一个将本地 SSD 用于 tempDB 的生产部署。我在 RAID1 配置中有 2 个 SSD。我看到平均读取时间为 1-2 毫秒，但所有四个 tempdb 数据文件的平均写入时间都显示为 1377 毫秒。

每个 tempdb 数据文件为 2GB，具有 1GB 的增长设置（自 5 个月前部署以来没有增长）

tempdb 日志显示平均读取时间为 67 毫秒，平均写入时间为 215 毫秒。

SSD 是三星 840 专业版。

以下代码是我用来获取统计信息的代码

SELECT a.database_Id, 
a.file_id, 
db_name(a.database_id) AS dbname, 
b.name, 
db_file_type =  CASE 
                WHEN a.file_id = 2 THEN 'Log' 
                ELSE 'Data' 
                END, 
UPPER(SUBSTRING(b.physical_name, 1, 2)) AS disk_location, 
a.io_stall, 
a.io_stall_read_ms / Case When a.num_of_reads = 0 Then 1 Else a.num_of_reads end AvgRead,  
a.io_stall_write_ms / Case When a.num_of_writes = 0 …

建议每个 SQL 实例都打开 TF 1118

Paul 对使用跟踪标志 1118 的建议是什么？从 SQL Server 2000 开始，每个人都应该在 SQL Server 的所有实例上打开它。打开它没有任何缺点。 保罗·兰德尔

它记录在KB 2154845 中，虽然它确实影响所有数据库，但影响最大的是 tempdb

这意味着实例上每个数据库中的每个新分配的对象都会获得自己的私有 64KB 数据。Tempdb 通常是创建大多数对象的地方，因此它在那里发挥了最大的作用。 肯德拉·利特尔

我环顾四周，没有发现任何人反对使用它。那么，我们应该在创建新实例时将其作为我们流程的一部分，并在机会出现时将其追溯添加到现有 SQL 实例中吗？

我在 2014 年使用 SQL 2000，还没有在 2016 年上线。我们按照说明为每个处理器使用 1 个 tempdb，最多 8 个。

我们最近在多次接近中断后停用了一个实施得相当糟糕的服务代理设置，但是在我早上检查时，我注意到有 2 个服务代理内部 SPID (<50) 仍然持有约 75% 的 TempDB空间。

现在，我知道这些是服务代理任务，因为 SysProcesses 上的 CMD 列显示“BRKR EVENT HNDLR”和“BRKR TASK”，而最后的等待类型分别是“BROKER_EVENTHANDLER”和“SLEEP_TASK”。两者都将“背景”作为状态，0 开放交易和一个多月前的最后一批时间。

目前服务代理实现已完全禁用（从代码角度），队列已禁用（is_activation_enabled 和 is_receive_enabled = 0），transmission_queue、conversation_endpoints 或实际队列中没有任何内容，但有问题的数据库仍然有 is_broker_enabled = 1（与 TempDB 和 MSDB 一样）。

服务器当前正在运行带有安全修复程序 (11.0.5343.0) 的 SP2，即使在集群故障转移之后，TempDB 的使用似乎仍然存在。我们没有尝试重新启动，因为这是一个生产系统，但我认为故障转移会产生相同的效果。

以前有没有人遇到过这个问题，如果有，你是怎么解决的？

谢谢，

今天我的tempdb推到了分配的磁盘边缘。目前，所述磁盘仅剩 10 MB。我很确定当天早些时候一位同事运行的一些不好的报告将其推高tempdb到这个大小。

但是，现在我的tempdb大小为 20932 MB，可用空间为 20373 MB。所以看起来我们有足够的空间可以使用。我宁愿等到周末重新启动并将其恢复到更合理的大小。只要不寻常的事情不再发生，我可以让这趟旅程吗？

在此处使用 SQL Server 2012。谢谢。

我完全理解这个错误意味着什么以及如何解决。

我的问题是这个数字（148643705716736）指的是什么？

日期 5/7/2018 1:36:58 AM

登录 SQL Server（当前 - 5/7/2018 2:31:00 AM）

源 spid125

信息

无法为数据库 'tempdb' 中的对象 'dbo.SORT 临时运行存储：148643705716736 '分配空间， 因为 'PRIMARY' 文件组已满。通过删除不需要的文件、删除文件组中的对象、向文件组添加其他文件或为文件组中的现有文件设置自动增长来创建磁盘空间。

检查 SQL Server 2019 CTP 2.5 (15.0.1500.28) 我发现了这个新的配置选项，并在它背后徘徊。到目前为止找不到任何信息，想知道您是否知道在哪里可以找到更多信息？