我想知道如何识别实际填充 TEMPDB 数据库事务日志的确切查询或存储过程。
sql-server-2005 sql-server-2008 sql-server tempdb transaction-log
我想我曾经在某处读到过写入 tempdb 比不在 tempdb 中的实际表更快。这在任何情况下都是真的吗？我想我记得它说了一些关于 tempdb 并将数据存储在内存中的特殊内容？
服务器 (SQL Server 2008) 的 tempdb 每月数次增加到 500GB+。是否可以找出导致此问题的 SQL 语句？问题通常不是由create table #temp...; insert into #temp...或select ... into #temp...复杂的连接引起的。
某些 tempdb 文件的初始大小每次也会自动设置为更大的值。如何预防？
有时缓存的计划会阻止调整/缩小文件的大小。如何找到哪一个持有tempdb？
在 SQL Server 2008 中缩小临时数据库时使用的最佳实践是什么？
使用以下方法有风险吗？
use tempdb
GO
DBCC FREEPROCCACHE -- clean cache
DBCC DROPCLEANBUFFERS -- clean buffers
DBCC FREESYSTEMCACHE ('ALL') -- clean system cache
DBCC FREESESSIONCACHE -- clean session cache
DBCC SHRINKDATABASE(tempdb, 10); -- shrink tempdb
dbcc shrinkfile ('tempdev') -- shrink db file
dbcc shrinkfile ('templog') -- shrink log file
GO
-- report the new file sizes
SELECT name, size
FROM sys.master_files
WHERE database_id = DB_ID(N'tempdb');
GO
我想知道两件事：
每个内核是 1 个文件吗？那么四核 = 4 个 tempdb 文件，创建三个新文件？
我们已启用 sp_configure 'tempdb metadata memory-optimized' = 1，现在 tempdb 元数据在我们的一台服务器上占用了 400 GB 以上，并且还在继续增长。内存使用量有所下降，但通常它的内存使用量会不断增加。我们已经有几次服务器实际上崩溃了，因为其他系统进程没有足够的内存来修改 tempdb，这导致整个服务器宕机。
如何防止 SQL Server 内存中优化的 tempdb 元数据不断增长并使我的服务器崩溃？如果有的话，我可以查看哪些其他信息来找到消耗如此多内存的内容？
以下查询当前返回 438 GB。
SELECT SUM(domc.pages_kb / 1024.0 / 1024.0) AS pages_gb
FROM sys.dm_os_memory_clerks AS domc
WHERE domc.type LIKE 'MEMORYCLERK_XTP'
以下查询提供的数据是内存的最大使用量（290 GB）是 memory_consumer_id 为 113 - 'LOB Page Allocator'。它没有object_id 或xtp_object_id，所以我猜它是一个数据库范围的对象。
SELECT ddxmc.memory_consumer_id
, ddxmc.memory_consumer_type_desc
, ddxmc.memory_consumer_desc
, ddxmc.object_id
, ddxmc.xtp_object_id
, ddxmc.used_bytes / 1024.0 / 1024.0 / 1024.0 AS used_gb
FROM sys.dm_db_xtp_memory_consumers AS ddxmc
ORDER BY ddxmc.allocated_bytes …sql-server memory tempdb memory-optimized-tables sql-server-2019
我们有一个 SQL Server 2005 数据库，临时数据库已满。通过进入 SQL Server Management Studio，我可以看到 tempdb 中的所有临时表。是否可以判断哪个会话持有哪个临时表？理想情况下，一个查询将列出每个会话使用的临时表。
谢谢，
在谷歌搜索时，我发现了一些相互矛盾的信息。
某些站点指出，当没有为数据留下物理内存时，SQL Server 会将现有数据移动到 TEMPDB（请参阅：SQL Server：揭秘 TempDb 和建议）。
但是其他站点声明，当没有足够的物理内存时，操作系统可以使用 PAGE FILE 并将数据从物理内存移到它（请参阅SQL Server 的页面文件）。
我想知道当 SQL Server 物理内存不足时，它会在哪里写入数据？到 tempdb 还是到 OS Page 文件？或者两者都有？
在最大内存设置为 25GB 的 SQL Server 2016 SP2 上，我们有一分钟执行大约 80 次的查询。该查询将大约 4000 页溢出到 tempdb。这会导致 tempdb 的磁盘上出现大量 IO。
当您查看查询计划（简化查询）时，您会看到估计行数等于实际行数，但仍然会发生溢出。所以过时的统计数据不能成为问题的原因。
我做了一些测试和以下查询溢出到 Tempdb：
select id --uniqueidentifier
from SortProblem
where [status] ='A'
order by SequenceNumber asc
option (maxdop 1)
但是，如果我选择不同的列，则不会发生溢出：
select startdate --datetime
from SortProblem
where [status] ='A'
order by SequenceNumber asc
option (maxdop 1)
所以我试图“放大” id 列的大小：
select CONVERT(nvarchar(512),id)
from SortProblem
where [status] ='A'
order by SequenceNumber asc
option (maxdop 1)
然后也不会发生溢出。
为什么 uniqueidentifier 不会溢出到 tempdb 和 datatime 列？当我删除大约 20000 条记录时，当我选择 id …
sql-server tempdb sorting sql-server-2016 cardinality-estimates
我们在 SQL Server 2014 SP1 上有一个活动的 OLTP 40GB 数据库。发现查询缓慢，IO_Completion 等待，磁盘队列长度上升到 900，SQL Server 停止响应。我们尝试了什么：
重新启动实例，一分钟后它开始以相同的方式运行。
第二次重启后，我们更改了每个 tempdb 数据文件的初始大小（创建了 16 个数据文件），它开始正常工作。
注意：我们将表变量用于中间结果集。这些结果集非常小。
一个月内发生了两次。每次我手动向数据文件添加一点空间时，它就会开始正常工作。更有趣的是，我们在 SQL Server 2008 R2 和 SQL Server 2012 上的相同设置（相同的硬件、相同的文件夹和文件设置、相同的工作负载）运行良好。
请帮助我们找到永久解决方案。
所有数据文件的初始大小都是 1000MB，当前每个是 1500MB。都是一样的。每个自动增长是 100MB。在此之前，我们面临 PFS 和 GAM 页面争用，我们增加到 16 个并解决了问题。跟踪标志 1117 和 1118 都已启用。2 个 NUMA 节点上的 24 个内核。所有数据文件都在同一卷上。简单的磁盘，没有 SAN。
实例位于物理机上。带有表变量的查询和带有哈希联接的查询最常产生 IO_Completion 等待。
wBob 的详细回答促使我们进行更详细的搜索。我们之前是怎么错过的：
数据库 'tempdb' 中文件 'templog' 的自动增长被用户取消或在 7704 毫秒后超时。使用 ALTER DATABASE 为此文件设置较小的 FILEGROWTH 值或显式设置新文件大小。
这是我们在发生此类问题时在日志中发现的。我们正在移动 TempDB 以分离快速驱动器。