Why does the buffer pool contain so many dirty tempdb pages?
本文大意：
对于tempdb来说，还原模式为简单模式也只能是简单模式，不需要从故障中恢复，tempdb只会重建，所以tempdb没有必要做恢复，不需要自动checkpoint。 所以说在一个比较繁忙的实例中，用户数据库的checkpoint比tempdb频繁，所以在tempdb中会有比较多的脏数据。
结论：
自动触发的checkpoint不会对tempdb影响脏数据没有写入，所以脏数据比较多。
本文大意：
dbcc checkdb错误离奇消失：主要可能存在的问题是当索引重建时在checkdb，导致一致性问题。
从2000升级到2008 tempdb上可能会遇到什么问题：有一下4点会产生比较打的行版本信息：
1.在线索引重建
2.DML触发器
3.MARS
4.快照隔离界别
填充因子是否可以减少分页，并可以实例级别的设置：填充因子确实可以减少分页，填充因子就是在页上保留了一定比例的空闲空间，以便于插入数据或者行记录扩展，以减少分页的发生。对于OLTP没有一个很好的答案，每个表可能因为负载的不同需要不同的填充因子。对于OLAP可以使用100%以提高IO效率。
FILESTREAM的性能问题：1.FILESTREAM是保存在windows的ntfs文件，因此调整ntfs簇大小（分配单元）很重要
2.确定文件的大小研究表明小于256KB，是放在sql server 中比较好。256kb-1mb性能差不多
3.FILESTREAM数据不能给修改只能被覆盖重写。
4.FILESTREAM不能和数据库镜像兼容（sql server 2008）
本文大意：
1.TF 1118标记打开之后原本是从SGAM分配前8个页的，代替为直接分配一个专用区。这样的好处就是减少了SGAM的冲突。
2.专区分配给了一个表并不是把8个页都分配给了这个表，只是这个分区为这个表保留，不能用与其他表。
3.在sql server 2005之后分配系统被优化，当创建用户对象时，先和以前一样创建一个IAM页，插入数据时分配数据页。单删除对象是并不是释放掉，而是缓存起来以便下次使用。
4.TF1118在sql server2005后的版本中还存在是为了提供方法减轻SGAM的使用，也可以使用多个文件的方式缓解冲突，SQLPASS2011上有人建议若内核数量少于8个使用8个文件，若有8个以上内核，先尝试使用8个文件，若还是有冲突再加4个文件
5.使用了标记后dbcc ind还是返回2页，但是来自专区不是混合区
本文大意：
在log文件到达70%时，和recovery interval时限到是会做checkpoint，但是在tempdb中只有log文件超过70%才会checkpoint，阻止了log文件可能的增长，因为在tempdb中简单恢复模式会截断日志。自动checkpoint在tempdb不会像所有用户数据库会写入所有的脏数据，当手动运行时也会写入脏数据
本文大意：
当使用动态游标打开时，会位结果集中的每行生成一个checksum，当读取下一行时会去基表中查询记录，因此就会在执行计划中有个key lookups操作
本文大意：
有时候会出现tempdb中日志文件和数据文件的巨大差异。在用户数数据库中是不可能出现的。这个是因为tempdb只记录undo日志，不会生成redo日志，减少的日志的写入量。从而导致日志文件和数据文件的巨大差异。作者使用了一个证明这个问题。在tempdb中使用2612B的日志空间记录了256kb的排序，并假设如果是90G的内容需要排序。在tempdb中只会生成90G/256K=368640,368640*2612B=~918M的日志。
本文大意：
dbcc checkdb会先生成叫做facts的东西并保存在很大的worktable中，dbcc checkdb使用按分配的顺序读取用户数据文件来生成fact（最快的方式）。读取任务是分散到很多线程进行的，所以dbcc checkdb很消耗io的原因。fact生成好之后查询处理器吧结果返回给dbcc checkdb让它去匹配，若某个fact匹配不到相关信息，那么可能就会报一致性错误。
现在能用WITH ESTIMATEONLY评估dbcc checkdb在tempdb中的空间使用。dbcc checkdb并不是一次性检查整个数据库（除非有tf 2562），检查是分批次的。使用2个条件来划分，1：出现512个或者更多的索引。2：这批的大小超过了32MB。fact的大小评估如下，1：分区上的所有页*2,2：聚集索引中hobt页数*3,3：表中LOB列数*2,4：若为heap，表行数*2,5：最大行大小*hobt页数。WITH ESTIMATEONLY输出其中最大的一个。
Are I/O latencies killing your performance?
本文大意：
到底什么样的延迟好，或者不好，可能每个人心中都有一个标准：
- Excellent: < 1ms
- Very good: < 5ms
- Good: 5 – 10ms
- Poor: 10 – 20ms
- Bad: 20 – 100ms
- Shockingly bad: 100 – 500ms
- WOW!: > 500ms
关键点是，是否到达了可以接受的边界，先不要管延迟，要先注意，性能是否在可以接受的范围内。
tempdb文件：如果真的不可以接受那么又以下4个方面：
1.增加一个比较快速的io子系统
2.查看tempdb所在的位置，如，a.网络或者路径问题，b.不正确的SAN设置，c.多用户共享，d.是否使用多个tempdb文件来增加性能
3.减少tempdb的使用，a.plan中的hash，sort，exchange，b.减少不必要的数据放入的临时表中，c.索引重建中SORT_IN_TEMPDB,d.快照隔离级别
4.综合2,3,然后再增加快速io子系统
tempdb log 文件:log文件的写入延迟，会影响日志提交，进而产生吞吐量的问题，对于log文件的读取，一般不会影响吞吐量，但是会影响log reader
同时作者推荐了3篇文章:
- Trimming the Transaction Log Fat - common problems that lead to poor transaction log performance.
- Trimming More Transaction Log Fat - more subtle problems that contribute to poor transaction log performance.
- Transaction Log Configuration Issues – self-explanatory.
本文转自 Fanr_Zh 博客园博客，原文链接：http://www.cnblogs.com/Amaranthus/archive/2013/04/20/3033214.html
，如需转载请自行联系原作者
