标签: tempdb

我们为一些 SQL Server 2005 数据库启用了“READ_COMMITTED_SNAPSHOT”。

现在我们不时看到我们的 TempDB 正在填满硬盘，我们怀疑版本存储是罪魁祸首。

我们监视 TempDB 的使用情况sys.dm_db_file_space_usage，一旦我们看到版本存储在增加（如 所报告的那样 version_store_reserved_page_count），我们希望识别正在使用版本存储的事务。

我正在使用以下语句来查找使用版本存储的事务：

SELECT db_name(spu.database_id) as database_name,
       at.transaction_begin_time as begin_time,
       case 
         when at.transaction_state in (0,1) then 'init'
         when at.transaction_state = 2 then 'active'
         when at.transaction_state = 3 then 'ended'
         when at.transaction_state = 4 then 'committing'
         when at.transaction_state = 6 then 'comitted'
         when at.transaction_state = 7 then 'rolling back'
         when at.transaction_state = 6 then 'rolled back'
         else 'other'
       end as transaction_state,
       ast.elapsed_time_seconds as elapsed_seconds,
       ses.program_name, …

我有一个 tempdb 增长问题。让我通过提供我的 tempdb 设置来开始一切。

即使没有在数据库/服务器上运行查询，tempdb 的大小也会不断增加，开始迅速，然后缓慢而没有停止。我运行了许多查询来找出正在运行的内容，下面是查询的结果，它实际上给了我可以使用的结果。

可以看出，它们都是内部 spid 的，有什么方法可以找出 tempdb 继续失控的原因以及如何缓解它？对这个问题的任何帮助将不胜感激。

--Query that returned the result set
SELECT session_id,
       SUM(internal_objects_alloc_page_count)   AS task_internal_objects_alloc_page_count,
       SUM(internal_objects_dealloc_page_count) AS task_internal_objects_dealloc_page_count
FROM   sys.dm_db_task_space_usage
GROUP  BY session_id
HAVING SUM(internal_objects_alloc_page_count) > 0 

我正在一个新的 SSD 阵列上进行计时试验，该阵列同时运行 SQLIO 测试和 DB 还原和 DBCC CHECKDB 调用的实际工作负载。我发现我的 SQLIO 批处理生成的 IOPS 和吞吐量与我观察到的工作负载之间存在重大差异，工作负载仅请求我使用 SQLIO 能够观察到的一小部分，通常在 5,000 IOPS 范围内并产生不超过 400 MB/s 的吞吐量。

如果硬件有足够的容量来处理负载，那么 DBCC CHECKDB 将消耗多少资源事件是否存在固有限制？我可以尝试哪些设置来扩展 DBCC CHECKDB 对 CPU 和磁盘资源的使用？

以下是具体...

从 systeminfo

OS Name: Microsoft Windows Server 2012 R2 Standard OS Version: 6.3.9600 N/A Build 9600 System Manufacturer: HP System Model: ProLiant DL580 G7 System Type: x64-based PC Processor(s): 4 Processor(s) Installed. [01]: Intel64 Family 6 Model 46 Stepping 6 GenuineIntel ~1042 Mhz Total Physical Memory: 131,062 MB …

我们有一个 SQL Server 2012 Enterprise 设置，具有大量 RAM (256 GB)，此时数据库相当小（大约 17 GB）。现在，由于各种编码问题，我们遇到了性能问题，希望通过一些代码审查和优化来解决。与此同时，有一种尝试通过为tempDBLUN获得更快的磁盘来提高性能，例如使用 FusionIO PCIe 闪存卡。

我担心的是，鉴于 SQL Server 仍然有足够的 RAM 可以利用，我们不会看到添加更快的磁盘带来任何真正的性能改进。我认为大多数tempDB操作将发生在 RAM 中，或者发生在磁盘上但最终缓存在 RAM 中（在主机、HBA 或 SAN 上）。

有谁知道当 SQL Server 2012tempDB有足够的 RAM 可供使用时，它是否仍会等待磁盘操作上的 IO 阻塞，或者tempDB我们看到的磁盘活动是否只是为了提供持久性或持久性？

如何配置 SQL Server 以便“数据库 A”中的活动对“数据库 B”中的用户影响最小

上下文

我们的（非常大的）生产 SQL Server 上有很多运行各种“遗留应用程序”的数据库，每个数据库用于特定客户的应用程序实例。

问题

如果“流氓用户”运行非常昂贵的查询——有时来自报告，有时来自应用程序——它会导致“其他数据库”缓慢爬行。

[我知道“根本问题”是昂贵的查询；程序员不应该让它们运行。密集报告应该运行一个单独的报告数据库。程序员应该在大数据集等上进行测试。我的问题与“隔离”数据库对彼此的影响有关。]

我怀疑，但我还没有确认问题出在“tempdb”中，SQL Server 用于排序的临时区域/数据库无法放入内存中。

我看过帖子指出将 tempdb 传播到多个文件。这会有帮助吗？

/sf/ask/50390861/ http://logicalread.solarwinds.com/sql-server-tempdb-best-practices-multiple-files-w01 /#.VdzGxrNv4Uw

我在其中一台服务器（SQL Server 2008 R2）上有 tempdb 争用（我猜，至少）。

拦截器和服务员（其中 10 个）在数据库 tempdb 上都具有 PAGELATCH_EX 等待类型，并且所有会话（拦截器和服务员）的等待资源都是“2:1:122”。

我检查了 SQL 代码，发现在大多数会话中都创建了表变量，我怀疑这可能是罪魁祸首。

任何有关如何进一步诊断和缓解此问题的建议表示赞赏。

我是一名 DBA，对从 UNIX/Informix 转过来的 SQL Server 相当陌生。

我有一个关于 tempdb 增长的问题：

从我在常规数据库上看到的情况来看，如果我从一个 10 GB 的数据库开始，然后将一堆数据放入其中以使其成为 100 GB，然后从中删除 50 GB 我必须执行收缩才能回收硬盘上的空间。直到我将空间分配给数据库

tempdb 是如何工作的？

如果初始大小为 10 GB，然后某个查询将 tempdb 增长到 100 GB，然后终止，该空间是否可用于未来的 tempdb 查询/临时表等......？

或者它是否将空间释放给操作系统？

我正在运行从 INT 到 BIGINT 的更改列，我的表大小为 250 GB，1 小时后我收到版本存储错误，因为 tempdb 已满。

据我所知，它只需要您的内存页和日志文件，但我不确定 Tempdb。有人可以解释一下这个内部结构吗？

我正在使用读提交隔离。

select 
    name, 
    snapshot_isolation_state_desc, 
    is_read_committed_snapshot_on 
from sys.databases

...对于这个数据库返回：

名称：数据库名称 
Snapshot_isolation_state_desc ：关闭
is_read_committed_snapshot_on : 0

为了帮助调试一批 SQL（在事务中运行），在事务中我将一些数据转储到全局临时表中。全局临时表是在事务内部创建的（由于我不打算在这里讨论的原因，我别无选择）。

我想我可以通过使用“with(nolock)”从事务外部（即在不同的连接下）从临时表中进行选择。但是，选择被阻止完成。

有没有办法从事务外部的临时表中进行选择？

在 SQL Server 安装过程中，我“认为”我将 tempdb 的位置指定在“F:”而不是“C:”上，但我可以看到，虽然 tempdb.mdf 和 templog.ldf 位于“F:”上，但 3 。 ndf 辅助数据文件位于“C:”上。

我正在考虑通过执行以下步骤来移动 .ndf 文件：

1.

    ALTER DATABASE tempdb MODIFY FILE ( NAME = temp2 , FILENAME = 'F:\MSSQLData\temp2' )
    ALTER DATABASE tempdb MODIFY FILE ( NAME = temp3 , FILENAME = 'F:\MSSQLData\temp3' )
    ALTER DATABASE tempdb MODIFY FILE ( NAME = temp4 , FILENAME = 'F:\MSSQLData\temp4' )

2. 停止 SQL Server（该实例当前未执行任何操作）。
3. 将 3 个 .ndf 文件从当前 C: 位置复制/粘贴到新的 F:\MSSQLData\ 位置
4. 重新启动 SQL Server。
5. 检查它是否有效：

    SELECT name, physical_name AS …