门前有条河

摘要： 1 --TempDB上的PAGELATCH2 3 4 --分清楚数据库里面的数据页面和系统页面5 6 --需要解释的是，SQL不仅在数据页修改的时候加latch，在数据文件的系统页面上，例如7 --SGAM、PFS、GAM页面发生修改的时候，也会加latch。这些latch在某些情况下也有可能8 --成为系统瓶颈9 10 --例如：当数据库创建一张新表的时候，SQL要为这张表分配存储页面，同时SQL也要11 --修改SGAM、PFS、GAM页面，把已经分配出去的页面标志成已使用。所以每创建一张12 --新表，SGAM、PFS、GAM页面都会有修改动作13 14 --这种行为对一般用户数据库不会 阅读全文

摘要： 1 --调整语句设计提高性能 2013-2-11 P449 2 3 --当一个问题语句，已经排除了系统资源瓶颈、阻塞与死锁、物理I/O、编译与重编译 4 --参数嗅探这些因素，也发现调整索引或使用计划指南不能达到要求，那怎么办？ 5 --不幸的是，我们已经基本上把SQL上常见的调优方法都介绍了。在有些情况下，一个语句 6 --的写法决定了他天生是一条复杂的语句，SQL很难使用最优的方法来运行他。这时候 7 --调整SQLSERVER，可能效果都不会很明显。用户要想想，如果这个问题更多的是由语句 8 --本身导致的话，那调整语句设计是不是更好的解决方法。有时候，可能是解决问题 9 --唯一的选. 阅读全文

摘要： 1 --内存压力分析 2 3 --表现特征 4 --SQL经常触发lazy writer 5 --SQL需要经常从硬盘里读数据，会有很多硬盘读 6 --执行计划经常被清除，所以buffer pool里的stolen内存部分应该不会很多 7 --由于数据页经常被清除，所以page life expectancy不会很高，而且会经常下降 8 9 --page life expectancy：缓存页面生存时间10 11 --如果数据页面 buffer pool内存有压力，SQL会优先清除内存里的执行计划12 13 --解决办法：14 --来自外部压力：Windows内存不够，SQL会压缩自己的内.. 阅读全文

摘要： http://www.cnblogs.com/lyhabc/articles/3219628.html 阅读全文

摘要： --如何在超大型数据库上运行DBCC CHECKDB2 --运行DBCC CHECKDB影响性能是难免的，影响正常应用运行也是难免的3 --许多数据库是无法修复的，或者在物理上的错误修复成功，但是在逻辑上4 --的错误是无法挽回的。5 6 --当发现用户访问数据库才发现数据库损坏，可能已经为时已晚，损失巨大。7 --所以DBA应该定期对每个数据库做CHECKDB工作。8 9 --两者平衡：比较合理的周期DBCC CHECKDB，不影响数据库应用性能10 11 --内部数据库快照12 --DBCC CHECKDB完全可以在多用户模式下正常使用DBCC CHECKDB(GPOSDB)，不需要等到一 阅读全文

摘要： http://www.cnblogs.com/lyhabc/articles/3219541.html 阅读全文

摘要： 轉自http://www.cnblogs.com/lyhabc/p/3219117.html 阅读全文