标签: tempdb

这篇文章的SQL Server的tempdb最佳实践提高性能建议我应该拆分tempdb成若干文件等于内核的数量。因此，对于 4 个内核，您将获得 4 个文件。

通过拥有更多数量的文件，您可以增加 SQL Server 可以随时推送到磁盘的物理 I/O 操作的数量。SQL Server 可以下推到磁盘级别的 I/O 越多，数据库运行的速度就越快。使用标准数据库，SQL Server 可以将其需要的大量数据缓存到内存中。由于 tempdb 的高写入特性，数据需要先写入磁盘，然后才能缓存到内存中。

虽然理论上听起来不错，但它真的像一般优化一样好吗？它是否可能仅适用于 IO 非常高的特定系统？

我们的监控解决方案 (SCOM) 当前标记 tempdb 日志空间不足。但是，我们将日志的自动增长设置为 1GB 块，并且驱动器上还有 25GB 的空间。

我看了看那是什么log_reuse_wait_desc，发现它是ACTIVE_TRANSACTION

我开始怀疑是否出于某种原因日志文件被填满并且自动增长没有启动，经过一些研究我发现即使在ACTIVE_TRANSACTION.

我找到了一篇关于 tempdb 日志空间不足的类似问题的文章：

http://sqltimes.wordpress.com/2014/07/05/sql-server-error-messages-the-transaction-log-for-database-tempdb-is-full-due-to-active_transaction/

他们在这里发布了一个CHECKPOINT解决问题的关于tempdb. 我知道CHECKPOINT将脏页刷新到磁盘，但是我不明白这将如何解决ACTIVE_TRANSACTION问题？

此外，我也不知道为什么在有足够空间时我们会收到此警报。是否存在tempdb罐头填充和自动增长由于某种原因不起作用的情况？

[SQL Server 2012 SP2 EE]

为什么以下脚本给我一个与 tempdb 相关的错误？

    exec sp_MSForEachDB '
    IF ( (select database_id from sys.databases where name = ''?'') > 4)
    BEGIN 
    ALTER AUTHORIZATION ON DATABASE::? TO [sa];
    ALTER DATABASE [?] SET RECOVERY SIMPLE;
    END'

这是我得到的错误：

  Msg 5058, Level 16, State 1, Line 5
  Option 'RECOVERY' cannot be set in database 'tempdb'.

它完成了它应该做的工作。但我想不出错误的原因。我知道 tempdb 的 databaseID 是 2，那么至少它不应该尝试为 tempdb 设置选项。

我们的生产服务器平均每秒运行 4,000 个事务。在过去几天中，平均每秒事务数跃升至 175,000 次。这不是打字错误，它是每秒 175K。
查看交易的 DMV，我们无法将其直接链接到用户会话，但我们确实看到了这一点：

SELECT NAME,
       COUNT(*)
FROM   sys.dm_tran_active_transactions
GROUP  BY NAME
ORDER  BY 2 DESC 

——

+------------------------------+-------+
|             Name             | Count |
+------------------------------+-------+
| WorkFileGroup_fake_worktable |   627 |
| LobStorageProviderSession    |   217 |
| workfile                     |   171 |
+------------------------------+-------+

任何人都可以阐明这些类型的交易吗？还是我在这里追鬼？

将一个 quickie proc 放在一起以帮助调试，我遇到了一个似乎是编译器错误的地方。

create proc spFoo
    @param bit
as
begin
    if @param = 0
    begin 
        select * 
        into #bar
        from [master].dbo.spt_values
        -- where number between ...
    end
    else
    begin
        select top 10 * 
        into #bar
        from [master].dbo.spt_values
        order by newid();
    end;
end;

尝试上述返回以下错误

消息 2714，级别 16，状态 1，过程 spFoo，第 19 行
数据库中已经有一个名为“#bar”的对象。

在人类可读的意义上，proc 似乎很好：select into由于它们被包裹在if-else块中，因此只会执行一个语句。不过很好，SQL Server 无法确认这些语句在逻辑上是否相互排斥。也许更令人困惑的是，当将drop table #foo放在 if-else 块中时错误仍然存​​在（假设它会告诉编译器取消分配对象名称），如下所示。

create proc spFoo
    @param bit
as
begin
    select top 1 * 
    into #bar …

DBCC CHECKDB 返回：

无法为数据库 'tempdb' 中的对象 'dbo.SORT 临时运行存储：140737951236096' 分配空间，因为 'PRIMARY' 文件组已满。

通过删除不需要的文件、删除文件组中的对象、向文件组添加其他文件或为文件组中的现有文件设置自动增长来创建磁盘空间。

消息 9002，级别 17，状态 4，第 1 行

我们最近将我们的 tempdb 文件分离到一个新的 SSD 并开始看到：

在文件 [T:\tempdb\tempdb4.ndf] 上发生了 5348 次 I/O 请求需要超过 15 秒才能完成。

我们多次出现此错误。当 tempdb 回到其原始 RAID 5 主目录时，我们没有看到错误。我遵循了 SQLIO 教程，我认为 SSD 在进行 8kb 随机读/写时应该比以前的 RAID 5 磁盘快得多。那么为什么我们会看到这些错误呢？

此外，为了证明并非一切都很好，我们通宵运行的批处理文件（发生这些错误的时间）需要 7 个小时。在旧磁盘上花费了 6.25 小时。

磁盘位于直接连接的阵列中。用于数据的 RAID5、用于日志的 RAID 10 和我们用于 SSD 的备用插槽。RAID 5 和 SSD 被格式化为 64kb 块大小。日志被错误地设置为 4KB 块大小（我知道 - 有机会时会修复）。

这些是 SQLIO 的结果：

T盘(ssd)
Ios=8KB随机写入,IOs/sec=31847.48,MBs/sec=248.8
Ios=8KB随机读取,IOs/sec=76391.66,MBs/sec=596.8

S盘(RAID 5)
Ios= 8KB随机写入,IOs/sec=2601.3,MBs/sec=20.32
Ios= 8KB随机读取,IOs/sec=3138.45,MBs/sec=24.51

对于 64K 顺序读/写，它们大致相同。

Tempdb 被拆分为 4 个 1.5Gb 文件（移动前后相同）。

SQL Server 2012 已修补到 SP3。

您知道是什么原因导致 SQL Server …

#LocalDB 实例是否支持SQL Server 临时表（以 为前缀）？

据我所知，版本存储只会清理比最旧的活动事务旧的版本。问题：最旧的事务数据库是特定的还是 SQL Server 将保留所有版本，无论数据库如何，如果有一个较旧的事务仍然处于活动状态，期间？

Backstory - SQL Server 2005 SP4 Enterprise 托管大约 40 个数据库。TempDB 当前为 102 GB，版本存储约为 98 GB。数据库实例上托管的应用程序之一有一个基于 sys.dm...database_transactions 的 40 天前的打开事务。两个独立的大型数据库在上个月的使用量非常大，我们看到与这些操作一致的 TempDB 增长。我们预计会有一些增长。我们没想到它会继续增长。 问题：存储在 TempDB 版本存储中的来自这两个独立数据库的版本是否仍然存在，因为第三个独立数据库具有 40 天前的连接并显示打开的事务状态？

Perfmon 计数器：在我今天早上跟踪它的几个小时内，版本存储不断增长。版本生成速率 AVG 约为 30 kb/s，版本清理速率为 0 kb/s。

为 TempDB 留下了大量空间，所有用户数据库的数据文件总数约为 300 GB，自上次重新启动以来，TempDB 的 8 个数据文件中的每一个每天平均增长 350 MB。此行为异常，调查发现大版本存储

对评论问题的回答，以免出现长时间运行的评论部分：

问：为什么在 tempdb 上自动增长？答：TempDB 设置为以我们认为适合大多数时间的大小进行初始化。我们允许自动增长以处理异常的数据库活动。我们也监控自动增长。

问：你怎么知道事务是活跃的，而不仅仅是一个活跃的连接？A：transaction_state 表示在 sys.dm_tran_active_snapshot_database_transactions 和其他东西中处于活动状态。活动监视器说每个连接有 1 个打开的事务。

问：为什么你的应用程序如此愚蠢？A：第三方。此实例中的众多实例之一。我不知道这种行为是否异常，或者很容易修复。

解析度

开放交易（或多个），其中防止任何版本存储清理，乔恩是正确的，版本存储清理是数据库地独立。关闭违规事务允许开始版本存储清理。原因背后的当前理论来自 Jon Seigel

版本存储只能根据整个实例内最旧的活动事务清除版本，以支持同时跨多个数据库使用事务级快照隔离。

如果有人确切知道或可以证明这一点，请这样做

参考问题：find-transactions-that-are-filling-up-the-version-store

参考文档：
TempDB 2005 WP
Teratrax tuning tempDB …

是否有任何边缘情况建议在存储过程开始时显式检查、删除和创建临时表，而不是仅仅创建它们？

同样，是否存在在存储过程结束时显式删除它们比让 SQL Server 清理它们更可取的情况？