标签: tempdb

我对 SQL Server 2012 还很陌生，如果有人可以提供帮助，我将不胜感激。我已将大型数据库的副本恢复到 SQL Server 2012，并尝试对其运行一些简单的查询。

我正在尝试对数据库136898115行表运行 SELECT 查询。这个SELECT查询只有一个简单的WHERE子句。每次运行这个查询都会失败，因为系统盘（安装Windows的分区- C:\）空间不足（这个分区只有6GB可用空间），我不明白为什么。我将 tempdb 定义为位于不同驱动器上，该驱动器具有超过 14 TB 的可用空间。当然，我的数据库也位于不同的驱动器上。

是什么让我的系统分区空间不足？是页面文件吗？

我们的企业应用程序使用 SQL Server 进行数据存储，主要是一个 OLTP 系统。但是，我们应用程序的一个重要组件会产生大量的 OLAP 工作负载。

我们对 tempdb 的写入延迟约为 100 毫秒。这种趋势发展随着时间的推移，和ALLOW_SNAPSHOT_ISOLATION关断。我们正在对此相关问题进行故障排除，到目前为止我们发现的唯一有趣的事情是有大量散列和排序溢出到 tempdb。我们推测这来自我们的 OLAP 工作负载。

题

泄漏的频率是多少？任何？多少次溢出/秒？我们的初步数据表明我们每秒大约有 2 次哈希溢出和每分钟 25 次排序溢出。

这种溢出频率是否可能是导致 tempdb 写入延迟高的罪魁祸首？

其他信息

我们按照每个内核数的建议为 tempdb 使用多个文件。tempdb 文件位于 RAID 1+0 SAN（具有高性能 SSD）上，但它与主数据库数据和日志文件位于同一设备上。tempdb 文件的大小足够大，它们很少增长。我们不使用跟踪标志 1117 或 1118。另一个变量是此设置为许多不同的数据库共享，这些数据库都经历中到高负载。

我们的 100 毫秒写入延迟远大于我们在 MSDN、SQL Skills 和其他站点上发现的 tempdb 写入延迟的可接受范围。但是，我们其他数据库的写入延迟很好（低于 10 毫秒）。根据其他统计数据，我们确实在大量使用 tempdb，尤其是对于内部对象。因此，我们正在深入研究以找出为什么我们的应用程序如此大量地使用内部对象。

我们的平台确实存在以不同方式表现出来的实际性能问题。我们一直在监控性能计数器、查看 DM 视图并分析我们的应用程序行为，以尝试深入了解我们系统的资源使用特征。我们现在专注于溢出，因为我们已经读到溢出具有巨大的负面影响，因为它们是在磁盘上而不是在内存中执行的。我们似乎有很多泄漏，但我想就人们认为的“高”获得一些意见。

我们的供应商应用程序数据库是 TempDB 密集型的。

该服务器是虚拟的 (VMWare)，具有 40 个内核和 768GB RAM，运行 SQL 2012 Enterprise SP3。

包括 TempDB 在内的所有数据库都位于 SAN 中的第 1 层 SSD 上。我们有 10 个 tempdb 数据文件，每个文件都预先增长到 1GB 并且它们永远不会自动增长。与 70GB 日志文件相同。跟踪标志 1117 和 1118 已经设置。

sys.dm_io_virtual_file_stats 显示过去一个月对 tempdb 数据和日志文件的读取/写入超过 50 TB，累计 io_stall 为 250 小时或 10 天。

在过去的 2 年中，我们已经调整了供应商的代码和 SP。

现在，我们正在考虑将 tempdb 文件放在 RAM 驱动器上，因为我们有大量内存。由于 tempdb 在服务器重新启动时被破坏/重新创建，因此它是放置在易失性内存中的理想候选者，该内存在服务器重新启动时也会被刷新。

我已经在较低的环境中对此进行了测试，它导致查询时间更快，但 CPU 使用率增加，因为 CPU 正在做更多的工作，而不是等待缓慢的 tempdb 驱动器。

有没有其他人将他们的 tempdb 放在高 oltp 生产系统的 RAM 上？有什么大的缺点吗？是否有任何供应商可以专门选择或避免？

读完这个问题让我想起了我不久前的一个问题。

我们有一个具有 512GB RAM 的 SQL Server，主数据库是 450GB。我们在 TempDB 中看到了很多动作（好吧，我认为这是“相当多的动作”——可能不是！）。我安装了 RamDisk Plus Server 的演示版，创建了一个 50GB 的 ramdrive，将 TempDB 指向它，但并没有看到性能有任何改善。

写入 TempDB 是否总是导致对磁盘的实际物理写入，或者 TempDB 写入是否由 SQL Server 缓存以便像在 Windows 文件系统缓存中那样延迟写入？

在这种情况下，ramdisk 毫无意义吗？

我知道 SQL Server 6.5 支持 TempDB-In-Ram，但我看到它很久以前就停产了！

我在这里和那里阅读了许多关于如何配置 tempdb 数据文件的博客，但我没有找到有关tempdb 日志文件的任何信息。

这是我目前在 tempdb 中使用的策略：

• 我已经使用了Paul Randal关于如何拆分我的 tempdb 数据文件的建议
• 我已将 tempdb 数据文件的大小设置为最大值并禁用自动增长。例如，我有 100gb 的可用磁盘空间并将我的 8 个 tempdb 数据文件的大小设置为每个 10gb。这可以防止Brent Ozar 推荐的磁盘碎片，而且我的日志文件还有 20gb 可用空间。

但就像我说的，没有人在谈论tempdb 日志文件。我该怎么办？在我的设置中，此文件与 tempdb 数据文件位于同一位置。我应该与 tempdb 日志文件一起使用的大小和自动增长值是多少？

简单的试验台：

USE tempdb;
GO

/*
    This DROP TABLE should not be necessary, since the DROP SCHEMA
    should drop the table if it is contained within the schema, as
    I'd expect it to be.
*/
IF COALESCE(OBJECT_ID('tempdb..#MyTempTable'), 0) <> 0 
    DROP TABLE #MyTempTable;

IF EXISTS (SELECT 1 FROM sys.schemas s WHERE s.name = 'SomeSchema') 
    DROP SCHEMA SomeSchema;
GO

CREATE SCHEMA SomeSchema AUTHORIZATION [dbo]
CREATE TABLE SomeSchema.#MyTempTable /* specifying the schema
                                        should not be necesssary since
                                        this statement is executed inside
                                        the …

SQL Server 缓存在存储过程中创建的临时表，并且仅在过程结束和随后执行时重命名它们。我的问题与 tempdb 空间何时被释放有关。我读到该表在程序结束时被截断。我在评论中读到这是在每个会话的基础上处理的，并且在 MSDN上看到了一个关于是否需要清理的问题。但是如果它从来没有被同一个会话执行过两次呢？

我还听说有一个后台垃圾收集进程，一旦表超出范围，就会释放该空间。

在创建它的存储过程结束时截断临时表似乎会导致表在 tempdb 中用于数据的空间比不使用 truncate 语句时释放的空间更快，尽管与预期相反。为什么？

使用或不使用这种截断语句的相对性能影响是什么？使用 SNAPSHOT 隔离时，tempdb 经常受到压力，我认为尽快从大型临时表中释放 tempdb 中使用的空间将防止 tempdb 不必要的增长。这种潜在的空间节省是否会以性能为代价？

这是一些重现问题的代码（主要来自@TheGameiswar，有一些更改）：

SET NOCOUNT ON;
GO
ALTER PROC usp_test
AS
BEGIN
    IF object_id('tempdb..#temp') IS NOT NULL
        DROP TABLE #temp

    SELECT *
    INTO #temp
    FROM [dbo].[Event_28] -- This is a table with 15313 rows, using 35648 KB according to sp_spaceused

    --SELECT SUM(user_object_reserved_page_count) AS [user object pages used]
    --  ,(SUM(user_object_reserved_page_count) * 1.0 / 128) …

我试图找出是否可以将 tempdb 文件添加到 SQL Server 而不必重新启动 SQL Server 服务。我在数据库管理员上看到了这个答案：

• Tempdb 添加文件需要重启

一个答案指出：

添加 - 无需停机。尽管正如 Microsoft 的 Sean 指出的那样，SQL 更喜欢使用填充较低的文件。如果您要从 1 个数据文件开始并添加更多数据，那么 SQL 将使用新的数据文件一段时间，但您的性能不会比只有一个文件差。但是，如果您已经有 2+ 个并再添加一个，那么它会在新的一个上产生热点并降低性能。

但是，评论警告以下几点：

我会在“添加”部分添加一个附录：“添加：不，但你很可能会不平衡，所以你会成为热点，这可能会使事情变得更糟。”

我对该评论有以下问题，但被指示在我自己的一个新问题（这个问题）中提出这些问题，而不是通过该问题答案中的评论来询问评论者。

具体来说：

1. 什么是热点？（我通过谷歌得到了一些信息，但没有详细说明添加文件后在 tempdb 上热点会发生什么）
2. 热点如何使 tempdb 中的事情变得更糟？
3. 数据库中的哪些具体事情会变得更糟？

我最近在收到日志驱动器已满的警报后，不小心将 tempdb 日志缩小到几乎 0。我被告知这会导致缓慢。有人可以解释为什么它会导致缓慢吗？

在 32GB 的服务器上，我们运行 SQL Server 2014 SP2，最大内存为 25GB，我们有两个表，在这里您可以找到两个表的简化结构：

CREATE TABLE [dbo].[Settings](
    [id] [int] IDENTITY(1,1) NOT NULL,
    [resourceId] [int] NULL,
    [typeID] [int] NULL,
    [remark] [varchar](max) NULL,
    CONSTRAINT [PK_Settings] PRIMARY KEY CLUSTERED ([id] ASC)
) ON [PRIMARY]
GO

CREATE TABLE [dbo].[Resources](
    [id] [int] IDENTITY(1,1) NOT NULL,
    [resourceUID] [int] NULL,
 CONSTRAINT [PK_Resources] PRIMARY KEY CLUSTERED ([id] ASC)
) ON [PRIMARY]
GO

具有以下非聚集索引：

CREATE NONCLUSTERED INDEX [IX_UID] ON [dbo].[Resources]
(
    [resourceUID] ASC
)

CREATE NONCLUSTERED INDEX [IX_Test] ON [dbo].[Settings]
(
    [resourceId] ASC,
    [typeID] ASC …