博客
关于我
强烈建议你试试无所不能的chatGPT,快点击我
限制优化时间和事件数的最佳方法
阅读量:6843 次
发布时间:2019-06-26

本文共 1297 字,大约阅读时间需要 4 分钟。

下面给出了限制优化时间和事件数的建议:

  • 对于单个查询和小型工作负荷(少于 100 个事件),请指定无限制的优化时间。如果指定不限制优化时间,数据库引擎优化顾问将给出最佳建议,并且在大多数情况下,优化会在相对较短的时间内完成。
  • 对于大型工作负荷(多于 100 个事件),请考虑以下方案,其优先级以其列出顺序为准。首先考虑方案 1 到方案 3,最后考虑方案 (4)。
    1. 如果用户在时间上有约束,请限制优化时间。
    2. 如果优化固定数量的事件就足够了(例如,前 10,000 个事件可以代表其余工作负荷),请使用 dta 命令行实用工具,并通过 –n 参数指定事件数。
    3. 如果使用的是 dta 命令行实用工具,并希望进一步限制优化时间,则可以使用 –A 和 –n 参数。例如,如果指定 -A 240 和 –n 1000,则数据库引擎优化顾问会在优化了 1000 个事件或进行了 4 个小时的优化(以先发生的为准)后立即停止优化。
    4. 优化所花的时间取决于查询的复杂性(引用表的数量)、选择的功能集(优化索引视图所花的时间比优化索引要多)以及数据(用于创建统计信息)大小。大多数情况下,数据库引擎优化顾问花在优化上的大部分时间都用在调用查询优化器上。以下是确定合适的数据库引擎优化顾问优化时间的一个简单经验法则:
      对于引用一到三个表的简单查询,如果只优化索引,则允许每个查询用时大约 1 秒,如果优化索引和索引视图,则允许每个查询用时大约 10 秒。对于引用三个以上表的复杂查询,如果只优化索引,则允许每个查询用时大约 10 秒,如果优化索引和索引视图,则允许每个查询用时大约 100 秒。
  • 如果数据库引擎优化顾问指示已处理 100% 的工作负荷,则表示已分析完全部工作负荷,但不一定进行了优化。若要确定是否优化整个工作负荷,请在优化日志的结尾搜索下列消息:
    “工作负荷中的所有事件均未优化。请考虑增大时间限制或者指定在输入 XML 中要考虑的事件数。”
    如果优化日志中存在这样一条消息,则表明数据库引擎优化顾问无法优化全部工作负荷。若要解决这种问题,请指定更长的优化时间。若要确保优化工作负荷中的所有事件,可以指定无限制的优化时间。如果选择不指定不限优化时间,数据库引擎优化顾问将设法在指定的优化时间内优化尽可能多的事件。

注意   Microsoft SQL Server 2000 索引优化向导中的“快”、“中”或“彻底”模式与数据库引擎优化顾问中的 -A 和 -n 参数之间没有直接的映射关系。通常,如果在 SQL Server 2000 中以特定模式(“快”、“中”或“彻底”)进行优化需要一定的时间,则在 SQL Server 2005 数据库引擎优化顾问中,花同样的时间通常能给出与之相当或更好的建议。建议使用“彻底”模式的用户使用数据库引擎优化顾问,并指定不限制优化时间和工作负荷中要优化的事件数。

    本文转自 Fanr_Zh 博客园博客,原文链接:http://www.cnblogs.com/Amaranthus/archive/2011/09/13/2174465.html,如需转载请自行联系原作者

你可能感兴趣的文章
用一生回味的经典语录
查看>>
你的命运不是一头骡子
查看>>
排序算法之鸽巢排序
查看>>
Appium移动自动化框架
查看>>
无线动态化解决方案总结:从WeApp到Weex
查看>>
CentOS上安装Bugzilla 4.5.2
查看>>
嵌入式 RTP通话:视频流(H.264)的传输
查看>>
参数的排列组合2
查看>>
struts2中ognl标签详解
查看>>
.NET中Flags枚举的使用
查看>>
【Python之旅】第八篇:开发监控软件的思想与流程
查看>>
KVM虚拟机克隆
查看>>
XenApp / XenDesktop 7.6 初体验二 配置计算机目录和交付组
查看>>
C#的换行符和回车符在程序语句中如何表示?
查看>>
【MySQL】ibdata文件增大的原因
查看>>
MS SQL 批量给存储过程/函数授权
查看>>
并发集合(九)使用原子 arrays
查看>>
上传应用
查看>>
Cocos2d-x-v3动作体系
查看>>
ChargeSystem——One,Two,Three
查看>>