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

名站网址导航为大家提供关于数据库教程相关的教程网站知识。

SQL Server误区30日谈第11天镜像在检测到故障后瞬间就能故障转
误区 #11:镜像在检测到故障后瞬间就能故障转移,错误网站数据库镜像的故障转移既可以自动发起，也可以手动发起。,在自动发起的情况下,是由镜像站点服务器执行故障转移操作办法（您没有看错，并不是由见证站点服务器来做故障转移的决定）,在见证站点服务器和镜像站点服务器都发现无法和主体站点服务器交换信息(这个过程被称为”形成仲裁”,译者注:也就,手动故障转移是由您发起的,手动发起可能是由于不存在见证站点服务器(以至于无法“形成仲裁”)，或是在主体站点服务器现在问题时镜像的运行模式不是“同步”。,当主体站点服务器发生故障时，镜像站点服务器在日志队列Redo完成之前不会上线(所谓的日志队列就是由主体站点服务器传送到镜像站点服务器的日志，但还没有在镜像站点服务器Replay)。即使您镜像的运行模式是同步,也仅仅只能说,在SQL Server标准版以及企业版所在的CPU低于5个内核，Roll Forward只有一个线程。对于企业版并且CPU多余5核，为每4个核分配一个Roll Forward线程。所以完全可以看出故障,由于大家都认为镜像工作在同步相关方式时可以迅速进行故障转移，所以很少有人检测日志Redo队列。但由于Redo队列的大小确定了故障转移时Downtime的大小，所以检测镜像站点服务器Redo队列变得十分重要。,有关这里更细节的文章，您可以参看:Estimating the Interruption of Service During Role Switching

误区 #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 后的网站seo优化措施(详细请看我的博文),您不再需要严格按照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增加一个网站网站文件。这需要您仔细分析后再做定夺。

关于数据库教程相关的教程网站知识今天我们就说到这里了，希望可以帮到大家。