Fanr

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

2011年3月23日

摘要: SQL Server中事务日志自动增长对性能的影响(上)SQL Server中事务日志自动增长对性能的影响(下) 阅读全文
posted @ 2011-03-23 20:23 Fanr_Zh 阅读(487) 评论(0) 推荐(0) 编辑

摘要: 创建并管理SQL Server Analysis Services分区(一)创建并管理SQL Server Analysis Services分区(二)创建并管理SQL Server Analysis Services分区(三) 阅读全文
posted @ 2011-03-23 20:15 Fanr_Zh 阅读(273) 评论(0) 推荐(0) 编辑

摘要: 本文详细介绍了优化SQL Server数据库查询方法。 SQL Server数据库查询速度慢的原因有很多,常见的有以下几种: 1、没有索引或者没有用到索引(这是查询慢最常见的问题,是程序设计的缺陷) 2、I/O吞吐量小,形成了瓶颈效应。 3、没有创建计算列导致查询不优化。 4、内存不足 5、网络速度慢 6、查询出的数据量过大(可以采用多次查询,其他的方法降低数据量) 7、锁或者死锁(这也是查询慢最常见的问题,是程序设计的缺陷) 8、sp_lock,sp_who,活动的用户查看,原因是读写竞争资源。 9、返回了不必要的行和列 10、查询语句不好,没有优化 ●可以通过以下方... 阅读全文
posted @ 2011-03-23 20:03 Fanr_Zh 阅读(244) 评论(0) 推荐(0) 编辑

摘要: http://www.searchdatabase.com.cn/showcontent_28790.htm 阅读全文
posted @ 2011-03-23 18:59 Fanr_Zh 阅读(272) 评论(0) 推荐(0) 编辑

摘要: SQL语句优化的原则: 1 .使用索引来更快地遍历表 缺省情况下建立的索引是非群集索引,但有时它并不是最佳的。在非群集索引下,数据在物理上随机存放在数据页上。合理的索引设计要建立在对各种查询的分析和预测上。一般来说:①.有大量重复值、且经常有范围查询(between, > ,< ,> =,< =)和order by、group by发生的列,可考虑建立群集索引;②.经常同时存取多列,且每列都含有重复值可考虑建立组合索引;③.组合索引要尽量使关键查询形成索引覆盖,其前导列一定是使用最频繁的列。索引虽有助于提高性能但不是索引越多越好,恰好相反过多的索引会导致系统低效。用户在 阅读全文
posted @ 2011-03-23 18:52 Fanr_Zh 阅读(277) 评论(0) 推荐(0) 编辑

摘要: 大家都用过企业管理器中的--“收缩数据库”,里面的功能的确可以收缩数据库的日志文件(.ldf)和数据文件(.mdf),但都会发现同样的问题,在收缩“数据文件”(.mdf)时根本收缩不了多少。最多截段自动增长部份的,没有根本释放在日常操作中删除数据库的沉冗空间。 上述应该是很多人遇到过的,笔者也千试万试试出来的方法,为了确定您的数据库安全,在执行下例的操作前,请先备份你的数据库。 1.首先你要找到你的数据库最大的表,一般是数目最大的表,如果不清楚,请在查询分析器查询: DBCC SHOWCONTIG 接着用 sp_spaceused 表 来查询reserved 的值和 data 的值 的差异可看 阅读全文
posted @ 2011-03-23 13:26 Fanr_Zh 阅读(316) 评论(0) 推荐(0) 编辑

摘要: 索引重建任务的时间间隔要相对一致。 如果索引较小,就没有必要去调整填充因子。 在索引级别上进行监控和更新,而不是表级别上。 保存填充一直在0,或者75和100之间。如果你要将填充因子设置为低于75,那么你必须自信你在做什么。保持较低的Scan Density和较低的平均Page Density是十分重要的情形。做一些观察,在将填充因子取值降低前,找出表被读取的频繁程度。 如果Scan Density高于或等于90%,别去改变填充因子,或者调整任务中填充因子至少不应该是首先被调整的。 如果Scan Density在60%到90%之间,小小地降低一下填充因子,例如降低幅度2%。 如果Scan De 阅读全文
posted @ 2011-03-23 12:45 Fanr_Zh 阅读(445) 评论(0) 推荐(0) 编辑