tempdb在系统中的重要作用 - 数据库综合 - 次元立方网 - 电脑知识与技术互动交流平台
tempdb在系统中的重要作用
&&&&&& tempdb是SQLServer的系统数据库一直都是SQLServer的重要组成部分，用来存储临时对象。可以简单理解tempdb是SQLServer的速写板。应用程序与数据库都可以使用tempdb作为临时的数据存储区。一个实例的所有用户都共享一个Tempdb。很明显，这样的设计不是很好。当多个应用程序的数据库部署在同一台服务器上的时候，应用程序共享tempdb，如果开发人员不注意对Tempdb的使用就会造成这些数据库相互影响从而影响应用程序。
1、&tempdb中的任何数据在系统重新启动之后都不会持久存在。因为实际上每次SQLServer启动的时候都会重新创建tempdb。这个特性就说明tempdb不需要恢复。
2、&tempdb始终设置为&simple&的恢复模式，当你尝试修改时都会报错。也就是说已提交事务的事务日志记录在每个检查点后都标记为重用。
3、&tempdb也只能有一个filegroup，不能增加更多文件组。
4、&tempdb被用来存储三种类型的对象：用户对象，内部对象、版本存储区
以上是基础知识。
如果SQL Server对tempdb访问不频繁,
tempdb对数据库不会产生影响;相反如果访问很频繁,loading就会加重,
tempdb的性能就会对整个DB产生重要的影响
.优化tempdb的性能变的很重要的,尤其对于大型数据库。
注:在优化tempdb之前,请先考虑tempdb对SQL Server性能产生多大的影响,评估遇到的问题以及可行性。
1、最小化的使用tempdb
SQL Server中很多的活动都活发生在tempdb中,所以在某种情况可以减少多对tempdb的过度使用,以提高SQL Server的整体性能。
如下有几处用到tempdb的地方：
(1)用户建立的临时表.如果能够避免不用,就尽量避免. 如果使用临时表储存大量的数据且频繁访问,考虑添加index以增加查询效率。
(2)Schedule jobs.如DBCC CHECKDB会占用系统较多的资源,较多的使用tempdb.最好在SQL Server loading比较轻的时候做。
(3)Cursors.游标会严重影响性能应当尽量避免使用。
(4)CTE(Common Table Expression).也会在tempdb中执行。
(5)SORT_INT_TEMPDB.建立index时会有此选项。
(6)Index online rebuild。
(7)临时工作表及中间结果集.如JOIN时产生的。
(8)排序的结果。
(9)AFTER and INSTEAD OF triggers。
不可能避免使用tempdb,如果有tempdb的瓶颈或issue,就该返回来考虑这些问题了。
2、重新分配tempdb的空间大小
在SQL Server重启时会自动建立8MB大小的tempdb,自动增长默认为10%. 对于小型的数据库来说,8MB大小已经足够了.但是对于较大型的数据库来说,8MB远远不能满足SQL Server频繁活动的需要,因此会按照10%的比例增加,比如说需要1GB,则会需要较长的时间,此段时间会严重影响SQL Server的性能. 建议在SQL Server启动时设置tempdb的初始化的大小(如下图片设置为MDF:300MB,LDF:50MB),也可以通过ALTER DATABASE来实现. 这样在SQL Server在重启时tempdb就会有足够多的空间可利用,从而提高效率。
难点在于找到合理的初始化大小,在SQL Server活动频繁且tempdb不在增长时会是一个合适的值,可以设置此时的值为Initial S当然还会有更多的考量,此为一例。
3、不要收缩tempdb(如没有必要)
有时候我们会注意到tempdb占用很大的空间,但是可用的空间会比较低时,会想到shrink数据库来释放磁盘空间, 此时要小心了,可能会影响到性能。
4 、分派tempdb的文件和其他数据文件到不用的IO上
tempdb对IO的要求比较高,最好分配到高IO的磁盘上且与其他的数据文件分到不用的磁盘上,以提高读写效率.
tempdb也分成多个文件,一般会根据CPU来分,几个CPU就分几个tempdb的数据文件. 多个tempdb文件可以提高读写效率并且减少IO活动的冲突。
常用的脚本如下：
--查tempdb库的大小
select&a.name,&sum(size)*8.0/&as&[GB]
,&sum(size)*8.0/1024 as&[MB]
from&master.dbo.sysdatabases&a&inner&join&master.dbo.sysaltfiles&b&on&a.dbid=b.dbid
WHERE a.name='tempdb'
group&by&a.name
order&by&1
tempdb是SQL Server重要的一部分,今天发现数据的tempdb特别大,所以对tempdb的一些了解和总结,以后还需要进一步学习。&
延伸阅读：
上一篇讲解了如何在ABP中使用RedisCache，虽然能够正...
本教程为 李华明 编著的iOS-Cocos2d游戏开发系列教程：教程涵盖关于i......
专题主要学习DirectX的初级编程入门学习，对Directx11的入门及初学者有......
&面向对象的JavaScript&这一说法多少有些冗余，因为JavaScript 语言本......
Windows7系统专题 无论是升级操作系统、资料备份、加强资料的安全及管......带你轻松接触Sybase ASE15.0.2性能优化-学网-中国IT综合门户网站-提供健康,养生,留学,移民,创业,汽车等信息
带你轻松接触Sybase ASE15.0.2性能优化
来源：互联网 更新时间： 17:58:28 责任编辑：李志喜字体：
【赛迪网－IT技术报道】Sybase ASE15.0.2性能优化:
调整共享内存:
/sbin/sysctl -w kernel.shmmax=
shmmax是最大共享内存段，假如服务器上没有别的应用并且使用raw device可以将此参数调整到物理内存的90%，如果使用file system device 的话相应调小，因为file system buffer需要开销内存!修改后重新启动系统。
数据库的创建：
tempdb数据和日志分离：
USE master
DISK INIT name = 'tempdbdev01', physname = '/opt/sybase/data/tempdbdev01.dat' , size = '1G',dsync = 'false'
DISK INIT name = 'tempdblogdev01', physname = '/opt/sybase/data/tempdblogdev01.dat', size = '1G',dsync = 'false'
ALTER DATABASE tempdb ON tempdbdev01 = '1G' LOG ON tempdblogdev01 = '1G'
USE tempdb
删除tempdb上使用的master段：
EXEC sp_dropsegment 'logsegment', 'tempdb', 'master'
EXEC sp_dropsegment 'system', 'tempdb', 'master'
EXEC sp_dropsegment 'default', 'tempdb', 'master'
如果已针对 tempdb 建立了设备，则只需禁用 dsyncio，但需要重新启动 Adaptive Server：
EXEC sp_deviceattr 'tempdbdev01', 'dsync', 'false'
EXEC sp_deviceattr 'tempdblogdev01', 'dsync','false'
数据库设备最好设置Direct IO，获得的性能相信会让你满意。
Sybase ASE 15.0.2运行中的配置参数及调优
sp_configure “max memory”,0,”2600M” (设置为共享内存的75%,重启生效)
sp_configure “allocate max shared mem”,1 (启动的时候自动分配max memory指定的最大内存)
sp_cacheconfig “default data cache”,”1300m”(设置数据缓存为max memory的一半)
sp_cacheconfig “default data cache”,”cache_partition=2″ (在SMP的环境中还有一个问题就是螺旋锁的竞争，当用sp_sysmon观察到资源缓存螺旋锁争夺超过10%时就需要分区。)
sp_poolconfig “default data cache”,”128m”,”16k” (增加一个16K I/O缓存池,解决排序等大IO操作，需要在长期观察后才能使用性能最佳化.)
sp_configure “procedure cache size”,102400 (过程高速缓存,通常是Max mem20%,这里是200M)
sp_cacheconfig ‘tempdb_cache’,'200m’,'mixed’ (创建一个200M命名高速缓存tempdb_cache给temdpb使用)
sp_bindcache ‘tempdb_cache’,tempdb (将tempdb_cache绑定到tempdb)
2、CPU(默认值为1)
当服务器的CPU个数多于一个时，可以考虑多CPU进行并行处理。(并行查询、并行dbcc、并行建立索引、并行bcp)
可根据实际CPU数来修改，若CPU>1时，一般设置为N-1。实际上OS会自动调度。
sp_configure “max online engines”,8
sp_configure “number of engines at startup”,8
sp_configure “number of worker processes”,8 (并行度＊并发连接数＊1.5倍)
sp_configure “max parallel degree”,1 (允许CPU并行)
3、连接数(默认数为25，可根据应用需要来修改
sp_configure “number of user connections”,600
sp_configure “number of locks”,100000
5、索引对像
数据库空闲状态下运行：sp_countmetadata “open indexes”
正常运行时运行：sp_monitorconfig “open indexes”
来确定一个最佳值，增加10%左右。
sp_configure “number of open index
相关文章：
上一篇文章：下一篇文章：
最新添加资讯
24小时热门资讯
Copyright © 2004- All Rights Reserved. 学网 版权所有
京ICP备号-1 京公网安备02号博客访问： 234783
博文数量： 117
注册时间：
ITPUB论坛APP
ITPUB论坛APP
APP发帖 享双倍积分
IT168企业级官微
微信号：IT168qiye
系统架构师大会
微信号：SACC2013
分类： Linux
1.&&&& 前言
唉，这是我听到的最让人头疼的流言，因为有很多微软的“官方”信息以及很多博文都坚持这种观点。
最让人混淆的是SQL CAT小组也建议1:1，但是他们是从按比例缩放角度（scaling perspective），而不是从性能角度(perf perspective)得出的。他们接触的都是些拥有超级服务器和IO子系统的大客户，但我们普通人却没有。
每个数据库实例只有一个tempdb，有很多方面会用到它，所以它常常是性能的瓶颈。这些你们可能早就知道了，但是何时应该创建额外的数据文件来解决性能问题呢？
2.&&&& 何时需要创建额外的数据文件？
当你看到tempdb中有PAGELATCH时，说明你的分配位图已经开始有竞争了。当你看到tempdb中有PAGEIOLATCH时，说明你的IO子系统已经开始有竞争了。你可以将闩（LATCH）看作是一种事务锁，但是更轻、更短暂，由存储管理器内部用来存取内部结构（比如内存中的数据页）用的。
Glenn Berry有一篇介绍了几个使用sys.dm_os_wait_stats视图的脚本——第一个脚本可以列出服务器上最多的等待类型。如果你看到PAGELATCH等待，你可以使用Robert Davis（MCM、微软DBA）的。它是使用了sys.dm_os_waiting_tasks视图将各种等待资源分开，让你了解哪些是在tempdb上的。
如果你看到tempdb上有PAGELATCH等待，你可以使用跟踪标志TF1118（完整介绍见）以及创建更多的tempdb数据文件来缓解这种状况。我曾写过澄清一些关于这个跟踪标志的流言以及为什么这个标志在SQL 中还继续存在。
3.&&&& 需要增加多少文件？
对于SQL SERVER 2000，建议是CPU内核数和tempdb数据文件数是1:1。但是，这个建议还在，但是由于进行了优化（），所有就不需要1:1了——数据文件数和CPU内核数比例为1/4到1/2就可以了。
这是一个傻瓜式大概的结论（，并不是说一定就得按这个做）。上周我就听我的一个客户说，由于他们的tempdb负载很大，他们竟然在一个32核心的系统上建了64个tempdb文件——这是他们唯一可用来缓解竞争的方法。但是能说这种方法最实用的吗？绝对不。
4.&&&& 为什么不在需要1:1？
那为什么说1:1并不总是一个好方法呢？太多的tempdb数据文件会致性能问题还有另外一个原因。如果你有一个需要大量内存的查询计划操作（比如排序），但是你的服务器中没有那么多内存，那么就必须将部分脏页写到tempdb磁盘数据文件中。此时如果有太多的文件，因为分配系统需要循环（Round-robin）分配，所以实际上会降低速度。这种情况也会发生在tempdb上的超大临时表上。
为什么循环分配会降低写到多个tempdb文件上的速度呢？有下面几种可能性：
·&&&&&&& 循环分配发生于每个文件组，tempdb中只能有一个文件组。当tempdb文件组中有16、32或更多的文件，并从几个线程中进行非常大的分配时，额外的同步和进行循环分配的一些必要工作（比如，查看每个文件的分配加权值，然后决定是进行分配还是减少加权值，还会相当频繁（每8192个分配单元）地为每个文件重新计算加权值）开始增加并且不容小觑。这和从多个线程中进行多个小分配不同，这也和从单文件中分配不同——很显然，这将经过优化系统从而不进行循环分配。
·&&&&&&& 假如你的tempdb数据文件不一样大，这样自动增加将会只是增加单个文件（非常不幸算法就这样（the algorithm is unfortunately broken）），导致畸形使用和IO热点。
·&&&&&&& 当系统中缓冲区不大但是tempdb异常巨大，那么就会需要通过lazywriter来释放缓冲区时，此时拥有过多的文件是导致随机IO模式根本原因（tempdb的检查点是不会写数据脏页的）。如果IO子系统不能处理这种跨多个文件的加载，那么系统开始变慢了。
我真想写篇关于这方面性能测试文章来说明我的意思。但是，我已从我的多个客户（他们创建了大量tempdb文件）那儿听说了这些。而且我知道这些原因还因为我知道代码是如何工作的（我们开发小组曾经拥有分配系统的源码）。
5.&&&& 总结
如果你这样做也不对，不过也不对，是吗？可能是吧。这给你出了个难题，tempdb到底要有多少文件呢？呵呵，我不能给你一个准确答案，我只能基于我和多个客户的交谈及会议/课程给你一些指导。对于只是通过创建多个tempdb文件来缓解竞争一定要小心——除非你很清楚，否则不要创建太多文件——如果你真这样做了，你一定得知道它的缺点。你可以在扩展性和性能之间有个平衡点，以避免帮了一个而坏了另一个。
6.&&&& 附一篇评论
不，额外的文件不需要放到独立的存储上。如果你只是看到PAGELATCH竞争，那么放在独立的存储对内存分配位图竞争没有任何用。对于PAGEIOLATCH等待，你最好使用独立的存储，但是也不是必须的——你可以将tempdb数据库和其他数据库储存分开，而不是增加更多的数据文件。分析存储的东西从而选择正确的途径。
阅读(1137) | 评论(0) | 转发(0) |
相关热门文章
给主人留下些什么吧！~~
请登录后评论。