数据库优化方法 (一)
2009-09-23 00:00:00 来源:WEB开发网探索性分析的两种模式
可以使用数据库引擎优化顾问以下列两种模式之一执行探索性分析:
1) 评估模式
在评估模式中,数据库引擎优化顾问将相同工作负荷下当前配置的成本 (C) 和用户指定的配置的成本 (U) 进行比较。因为 C 由数据库中当前存在的物理设计结构组成,所以 C 始终是实际配置。相比较而言,U 是由实际和假设的物理设计结构组成的配置。如果数据库引擎优化顾问报告 U 的成本低于 C 的成本,则 U 的物理设计性能可能优于 C。
例如,对于下列情况,评估模式是有用的:
数据库管理员要确定向表中添加非聚集索引对性能的影响。
数据库管理员刚刚完成了使用数据库引擎优化顾问优化数据库并接受了建议 (R)。查看 R 后,管理员可能会通过修改 R 对其进行微调。
例如,
数据库管理员想要添加两个非聚集索引并删除 R 中的一个非聚集索引。修改 R 后,该管理员将修改的 R 作为输入发送给数据库引擎优化顾问,并再次优化以衡量修改后的 R 对性能的影响。
2) 优化模式
在优化模式中,数据库管理员已经知道应该对数据库物理设计的一部分进行修改,但是希望数据库引擎优化顾问能够为其余配置提供最佳物理设计结构方面的建议。
例如,优化模式在以下情况下非常有用:
数据库管理员了解由于事实数据表过大,因此必须对其进行分区。管理员必须选择是按月还是按季度分区。可以使用其中任意一种方式对表进行分区,但管理员希望选择在给定的工作负荷下能提供最佳性能的分区方法。若要确定最佳分区方法,管理员可以使用数据库引擎优化顾问两次化工作负荷。
首先,管理员通过用户指定的配置和按月假设分区的表来优化工作负荷。
然后,使用按季度假设分区的表来优化工作负荷。
使用两种假设配置优化工作负荷后,管理员可以通过比较提高的百分比来确定能提供最佳性能的分区方法。
例如:
Orders 表必须包含 ship_date 列的聚集索引。数据库管理员想要确定 Orders 表的一组最佳非聚集索引。通过指定用户指定的配置(该配置包含 Orders 表中 ship_date 列的聚集索引),数据库管理员可以部分修改物理数据库设计。然后可以在优化模式下使用数据库引擎优化顾问确定用户指定的配置对性能的影响。
数据库引擎优化顾问未优化事件的最常见原因包括:
1)工作负荷引用了用户未选择优化的表。
2)工作负荷引用的表过小,例如包含的数据页少于 10 页的表。
3)数据库引擎优化顾问无法在指定时间范围内优化工作负荷。
说明:工作负荷是数据库引擎优化顾问的分析对象,它由要优化的一个或多个数据库执行的一组T-SQL语句构成。
更多精彩
赞助商链接