zoukankan      html  css  js  c++  java
  • 限制优化时间和事件数的最佳方法

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

    • 对于单个查询和小型工作负荷(少于 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 数据库引擎优化顾问中,花同样的时间通常能给出与之相当或更好的建议。建议使用“彻底”模式的用户使用数据库引擎优化顾问,并指定不限制优化时间和工作负荷中要优化的事件数。

  • 相关阅读:
    OSCP Learning Notes Buffer Overflows(3)
    OSCP Learning Notes Buffer Overflows(5)
    OSCP Learning Notes Exploit(3)
    OSCP Learning Notes Exploit(4)
    OSCP Learning Notes Exploit(1)
    OSCP Learning Notes Netcat
    OSCP Learning Notes Buffer Overflows(4)
    OSCP Learning Notes Buffer Overflows(1)
    OSCP Learning Notes Exploit(2)
    C++格式化输出 Learner
  • 原文地址:https://www.cnblogs.com/Amaranthus/p/2174465.html
Copyright © 2011-2022 走看看