欢迎您访问程序员文章站本站旨在为大家提供分享程序员计算机编程知识!
您现在的位置是: 首页  >  数据库

tempdb相关文章

程序员文章站 2022-04-24 10:53:17
...

Why does the buffer pool contain so many dirty tempdb pages? 本文大意: 对于tempdb来说,还原模式为简单模式也只能是简单模式,不需要从故障中恢复,tempdb只会重建,所以tempdb没有必要做恢复,不需要自动checkpoint。所以说在一个比较繁忙的实例中,

Why does the buffer pool contain so many dirty tempdb pages?

本文大意:

对于tempdb来说,还原模式为简单模式也只能是简单模式,不需要从故障中恢复,tempdb只会重建,美国空间,所以tempdb没有必要做恢复,不需要自动checkpoint。 所以说在一个比较繁忙的实例中,用户数据库的checkpoint比tempdb频繁,所以在tempdb中会有比较多的脏数据。

结论:

自动触发的checkpoint不会对tempdb影响脏数据没有写入,所以脏数据比较多。

TechNet Magazine: April 2009 SQL Q&A column

本文大意:

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)

Misconceptions around TF 1118

本文大意:

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页,但是来自专区不是混合区

What does checkpoint do for tempdb?

本文大意:

在log文件到达70%时,和recovery interval时限到是会做checkpoint,但是在tempdb中只有log文件超过70%才会checkpoint,香港服务器,阻止了log文件可能的增长,因为在tempdb中简单恢复模式会截断日志。自动checkpoint在tempdb不会像所有用户数据库会写入所有的脏数据,当手动运行时也会写入脏数据

Adventures in query tuning: unexpected key lookups

本文大意:

当使用动态游标打开时,会位结果集中的每行生成一个checksum,当读取下一行时会去基表中查询记录,因此就会在执行计划中有个key lookups操作

Understanding data vs log usage for spills in tempdb

本文大意:

有时候会出现tempdb中日志文件和数据文件的巨大差异。在用户数数据库中是不可能出现的。这个是因为tempdb只记录undo日志,不会生成redo日志,减少的日志的写入量。从而导致日志文件和数据文件的巨大差异。作者使用了一个证明这个问题。在tempdb中使用2612B的日志空间记录了256kb的排序,并假设如果是90G的内容需要排序。在tempdb中只会生成90G/256K=368640,368640*2612B=~918M的日志。

How does DBCC CHECKDB WITH ESTIMATEONLY work?

本文大意:

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输出其中最大的一个。