tempdb相关文章

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篇文章:
【推广】 免费学中医，健康全家人
原文地址：https://www.cnblogs.com/Amaranthus/p/3033214.html