Fanr

  博客园  :: 首页  :: 新随笔  :: 联系 :: 订阅 订阅  :: 管理

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篇文章:

posted on 2013-04-20 22:09  Fanr_Zh  阅读(504)  评论(2编辑  收藏  举报