SQL Server误区30日谈 第12天 TempDB的文件数和需要和CPU数目保持一致

误区 #12:TempDB的文件数和需要和CPU数目保持一致

错误

哎，由于上述误区是微软“官方”的建议，并且还有大量博文坚持这个观点，这个误区已经是老生常谈。

但让人困惑的是SQL CAT团队给出的建议就是1：1，但这个建议是源自扩展方面的原理来说,而不是一个通用法则。因为他们所面对的大型客户数据量服务器和IO子系统都是大部分人没有机会遇到的。

每个实例仅仅允许有一个TempDb,但需要用到TempDB的地方却有很多，所以TempDB很容易成为性能瓶颈，我想大家数人都了解这一点，而大多数人所不了解的应该是在什么情况下才需要额外的TempDB文件。

当你看到PAGELATCH类型的阻塞时，说明遇到内存中分配位图的争用问题了。而看到PAGEIOLATCH，说明遇到I/O子系统层面的争用问题了。对于闩锁（Latch）你可以将其看作和普通锁是一种东西，但更轻量,更短，并且只会被存储引擎内部使用。

MVP Glenn Berry 有一篇博文里有查看sys.dm_os_wait_stats的DMV。这篇博文中可以查到你的服务器造成阻塞最多的原因是什么。如果你发现是PAGELATCH型等待，你可以使用这段脚本来查看是由于FPS,GAM还是SGAM争用造成的问题。

如果你遇到闩锁争用，可以通过跟踪标记1118或是多建一个TempDB文件来缓和这个状况(原理可以在知识库KB 328551查到),我已经写了一篇关于为什么追踪标记1118依然被需要的长博文，链接：Misconceptions around TF 1118。

在SQL SERVER 2000时代，TempDB的文件数需要和CPU核数保持1：1的关系，在SQL SERVER 2005和2008版本这条建议也适用，但由于SQL SERVER 2005+后的优化措施(详细请看我的博文),你不再需要严格按照1：1的比例关系设置CPU核数和TempDB文件数，而是文件数和CPU核数的比例保持在1:2或是1:4就行了。

[题外话：在SQL PASS 2011我的好朋友Bob Ward,也是SQL CSS最牛的人。给出了一个新的公式:如果CPU核数小于等于8，使其比例保持在1:1,而如果CPU核数大于8，使用8个文件，当你发现闩锁争用现象时，每次额外加4个文件]

不过这也不能一概而论。上周我遇到一个问题，一个客户的TempDB负载大到需要32个CPU配上64个TempDB文件才能减轻闩锁争用。这是否意味着这是一个最佳实践呢？当然不是。

那你或许有疑问，为什么1:1的比例不好呢，那是因为太多的TempDB有可能引起另一个性能问题。如果你的一条查询中某些操作（比如排序）需要使用大量的内存，但内存不够时，就需要将这些内容分配到TempDB中。当存在多个TempDB文件时,由于TempDB的循环分配机制,这有可能导致性能被拖累，对于比较大的临时表也是如此。

那为什么循环分配机制对于TempDB存在大量文件时产生性能问题呢？有如下几种可能:

  • 循环分配算法是针对文件组而言，而对于TempDB只能存在一个文件组。当这个文件组包含16或32个文件时，由于循环分配算法的线程有限，但对于大量文件的TempDB依然需要做一些额外的同步工作，因此这部分工作会造成性能损失
  • TempDB的文件大小不一致，则有可能导致某个单独文件的自动增长，从而造成热点IO。
  • 当缓冲区需要通过LazyWriter释放一些空间时(TempDB的Checkpoint不会做写回操作)，多个TempDB文件有可能导致IO子系统的随机读写问题，这会导致IO方面的性能问题。

所以这个选择让你进亦忧，退亦忧。到底多少TempDB文件才是合适的呢？我也不能给你具体答案，但是基于我多年咨询经验以及出席各种大会的经验，我可以给你一个指导方针---当为了解决闩锁争用时为TempDB创建多个文件要小心，仅仅在必须情况下才额外增加TempDB文件。也就是你需要在可扩展性和性能之间取得一个平衡。

希望上面的指导方针对你有帮助。

PS:回应一些评论：TempDB的文件没有必要分布在多个存储器之间。如果你看到PAGELATCH类型的等待，即使你进行了分布也不会改善性能，而如果PAGEIOLATCH型的等待，或许你需要多个存储器，但这也不是必然-有可能你需要讲整个TempDB迁移到另一个存储系统，而不是仅仅为TempDB增加一个文件。这需要你仔细分析后再做定夺。

赞 (0)

相关推荐

  • SqlServer提示“列前缀tempdb.无效: 未指定表名”问题解决方案

    在查询凭证.审核凭证时出现"列前缀tempdb.无效: 未指定表名"的错误提示,怎么解决? 原因:是因为SQL2000无法识别计算机名称中"-"."."以及中文字等特殊字符, 只能使用英文字母及数字. 解决:右键我的电脑"属性"中"计算机名"点击修改,改为纯英文(最好8位以内),切记计算机名不能带".-"等字符.就可以解决了. 将这个问题改过来之后, 又有问题随之而来: 用友系统管理中注

  • SqlServer数据库提示 “tempdb” 的日志已满 问题解决方案

    执行sql 语句,中间没有用到临时表 提示服务器: 消息 9002,级别 17,状态 2,行 1 数据库 'tempdb' 的日志已满.请备份该数据库的事务日志以释放一些日志空间. 网上找了下解决方案,大体是扩大临时库的日志文件的大小解决的 解决过程: 查看了下数据库的属性,是自动增长,不指定文件大小上限. 在网上Google了很久,试了些方法都不行:数据库所在磁盘还有很大的可用空间,试着下重药了. 直接把tempdb的数据文件和日志文件的大小改为3000M, 问题解决. 记录一下清空日志的命令

  • 浅谈SQL Server 2016里TempDb的进步

    浅谈SQL Server 2016里TempDb的进步

    几个星期前,SQL Server 2016的最新CTP版本已经发布了:CTP 2.4(目前已经是CTP 3.0).这个预览版相比以前的CTP包含了很多不同的提升.在这篇文章里我会谈下对于SQL Server 2016,TempDb里的显著提升. TempDb定制 在SQL Server 2016安装期间,第一个你会碰到的改变是在安装过程中,现在你能配置TempDb的物理配置.我们可以详细看下面的截屏. 微软现在检测几个可用的CPU内核,基于这个数字安装程序自动配置TempDb文件个数.这个对克服

  • 更改SQL Server 2005数据库中tempdb位置的方法

    了解SQL Server 2005数据库的朋友可能都知道,tempdb系统数据库是一个全局资源,可供连接到SQL Server 2005实例的所有用户使用.我们有时候为了操作方便,常常会更改一下tempdb数据库的位置,那么该如何操作呢?本文我们就来介绍这一更改的过程. 获得tempdb的原始位置: select [name],[physical_name] from sys.master_files where database_id=db_id(N'tempdb') 更改tempdb数据库位

  • 谈谈Tempdb对SQL Server性能优化有何影响

    谈谈Tempdb对SQL Server性能优化有何影响

    先给大家巩固tempdb的基础知识 简介: tempdb是SQLServer的系统数据库一直都是SQLServer的重要组成部分,用来存储临时对象.可以简单理解tempdb是SQLServer的速写板.应用程序与数据库都可以使用tempdb作为临时的数据存储区.一个实例的所有用户都共享一个Tempdb.很明显,这样的设计不是很好.当多个应用程序的数据库部署在同一台服务器上的时候,应用程序共享tempdb,如果开发人员不注意对Tempdb的使用就会造成这些数据库相互影响从而影响应用程序. 特性:

  • SqlServer中tempdb的日志机制原理解析及示例分享

    SqlServer中tempdb的日志机制原理解析及示例分享

    测试用例 我们分别在用户数据库(testpage),tempdb中创建相似对象t1,#t1,并在tempdb中创建创建非临时表,然后执行相应的insert脚本(用以产生日志),并记录执行时间用以比较用以比较说明tempdb"快" Code 用户数据库testpage use testpage go create table t1 ( id int identity(1,1) not null, str1 char(8000) ) declare @t datetime2=sysutcd

  • 浅谈tempdb在SqlServer系统中的重要作用

    简介: tempdb是SQLServer的系统数据库一直都是SQLServer的重要组成部分,用来存储临时对象.可以简单理解tempdb是SQLServer的速写板.应用程序与数据库都可以使用tempdb作为临时的数据存储区.一个实例的所有用户都共享一个Tempdb.很明显,这样的设计不是很好.当多个应用程序的数据库部署在同一台服务器上的时候,应用程序共享tempdb,如果开发人员不注意对Tempdb的使用就会造成这些数据库相互影响从而影响应用程序. 特性: 1. tempdb中的任何数据在系统

  • SQL Server误区30日谈 第12天 TempDB的文件数和需要和CPU数目保持一致

    误区 #12:TempDB的文件数和需要和CPU数目保持一致 错误 哎,由于上述误区是微软"官方"的建议,并且还有大量博文坚持这个观点,这个误区已经是老生常谈. 但让人困惑的是SQL CAT团队给出的建议就是1:1,但这个建议是源自扩展方面的原理来说,而不是一个通用法则.因为他们所面对的大型客户数据量服务器和IO子系统都是大部分人没有机会遇到的. 每个实例仅仅允许有一个TempDb,但需要用到TempDB的地方却有很多,所以TempDB很容易成为性能瓶颈,我想大家数人都了解这一点,而大

  • SQL Server误区30日谈 第24天 26个有关还原(Restore)的误区

    本系列文章一直所没有触及的就是有关"还原(Restore)"的话题,因为一旦牵扯到这个话题就会涉及大量的误区,多到我无法通过一篇文章说完的地步.事实上,我希望用字母表的顺序为每一个误区进行编号,希望你看了不要昏昏欲睡.下面开始揭穿这26个误区. 误区 #24: 26个有关还原(Restore)的误区都是错误的 24 a)可以通过WITH STOPAT参数在完整备份和差异备份的基础上还原到特定时间点当然不能.虽然这个语法看上去貌似能的样子,但这个语法的最佳实践是你在进行日志还原到特定时间

  • SQL Server误区30日谈 第30天 有关备份的30个误区

    误区 #30:有关备份的30个误区全是错的在开始有关备份的误区之前,如果你对备份的基础没有了解,请看之前我在TechNet Magazine的文章:Understanding SQL Server Backups. 30-01)备份操作会导致阻塞不,备份不会导致对用户对象加锁,虽然备份对IO系统的负担导致看起来阻塞了,但实际上不会.唯一的特例是当备份包含到那些最小日志操作涉及到的数据区需要被加锁时,这个操作会阻塞CheckPoint,但DML操作永远不会受到备份操作的阻塞. 30-02)由完整恢

  • SQL Server误区30日谈 第14天 清除日志后会将相关的LSN填零初始化

    SQL Server误区30日谈 第14天 清除日志后会将相关的LSN填零初始化

    误区 #14.清除日志后会将相关的LSN填零初始化 错误     当日志文件在手动增长,自动增长和创建时都会进行填零初始化操作.但是请不要把这个过程和定期清除日志的过程搞混.日志截断仅仅意味着将一个或多个VLF标记为不活动以便被重复使用.在日志清除的过程中,并没有任何日志被清除或是填0."清除日志"和"截断日志"意思是一样的,但都属于用词不当,因为在这个过程中日志的大小不会有任何改变. 你可以在我的博客中看到有关日志文件填零初始化的博文:Search Engine

  • SQL Server误区30日谈 第5天 AWE在64位SQL SERVER中必须开启

    误区 #5: AWE在64位SQL SERVER中必须开启 错误!     在坊间流传的有关AWE的设置的各种版本让人非常困惑.比如说如何设置起作用,如何设置不起作用,在32位和64位上是否需要AWE等. 好吧,我来概括一下: 在64位系统(SQL SERVER 2005+版本) AWE是不需要的(即使是ON状态,也毫无影响) 开启"锁定内存页"使得缓冲池中的内存页不会被置换到虚拟内存中(实际上所有的Single Page Allocator分配和Stolen的内存都不会被置换) 当开

  • SQL Server误区30日谈 第3天 即时文件初始化特性可以在SQL Server中开启和关闭

    SQL Server误区30日谈 第3天 即时文件初始化特性可以在SQL Server中开启和关闭

    本系列文章是我在sqlskill.com的PAUL的博客看到的,很多误区都比较具有典型性和代表性,原文来自T-SQL Tuesday #11: Misconceptions about.... EVERYTHING!!,经过我们团队的翻译和整理发布在AgileSharp和博客园上.希望对大家有所帮助. 误区 #3: 即时文件初始化特性可以在SQL Server中 a)开启 和 b)关闭 a)是不允许的  b)是允许的 即时文件初始化是一个在SQL Server 2005以及之上的版本鲜为人知的特

  • SQL Server误区30日谈 第6天 有关NULL位图的三个误区

    这样还能减少CPU缓存命中失效的问题(点击这个链接来查看CPU的缓存是如何工作的以及MESI协议).下面让我们来揭穿三个有关NULL位图的普遍误区. 误区 #6a:NULL位图并不是任何时候都会用到 正确 就算表中不存在允许NULL的列,NULL位图对于数据行来说会一直存在(数据行指的是堆或是聚集索引的叶子节点).但对于索引行来说(所谓的索引行也就是聚集索引和非聚集索引的非叶子节点以及非聚集索引的叶子节点)NULL位图就不是一直有效了. 下面这条语句可以有效的证明这一点: 复制代码 代码如下:

  • SQL Server误区30日谈 第4天 DDL触发器就是INSTEAD OF触发器

    误区 #4: DDL触发器(SQL Server 2005之后被引入)就是INSTEAD OF触发器 这是错误的     DDL触发器的实现原理其实就是一个AFTER触发器.这个意思是先发生DDL操作,然后触发器再捕捉操作(当然如果你在触发器内写了Rollback,则也可能回滚). 存在Rollback也意味着这个触发器并不像你想象的那么轻量,来看下面的例子: ALTER TABLE MyBigTable ADD MyNewNonNullColumn VARCHAR (20) DEFAULT '

  • SQL Server误区30日谈 第2天 DBCC CHECKDB会导致阻塞

    误区 #2: DBCC CHECKDB会引起阻塞,因为这个命令默认会加锁 这是错误的! 在SQL Server 7.0以及之前的版本中,DBCC CHECKDB命令的本质是C语言实现的一个不断嵌套循环的代码并对表加表锁(循环嵌套算法时间复杂度是嵌套次数的N次方,作为程序员的你懂得),这种方式并不和谐,并且-.. 在SQL Server 2000时代,一个叫Steve Lindell的哥们(现在仍然在SQL Server Team)使用分析事务日志的方法来检查数据库的一致性的方式重写了DBCC C

  • SQL Server误区30日谈 第19天 Truncate表的操作不会被记录到日志

    SQL Server误区30日谈 第19天 Truncate表的操作不会被记录到日志

    误区 #19:Truncate表的操作不会被记录到日志 错误 在用户表中的操作都会被记录到日志.在SQL Server中唯一不会被记录到日志的操作是TempDB中的行版本控制. Truncate Table语句会将整个表中的所有数据删除.但删除的方式并不是一行一行的删除,而是将组成表的数据页释放,将组成表的相关页释放的操作交给一个后台的线程进行队列处理的过程被称为deferred-drop.使用后台线程处理deferred-drop的好处是这个操作不会使得其所在的事务需要执行很长时间,因此也就不

随机推荐