限制优化时间和事件数的最佳方法

简介: 下面给出了限制优化时间和事件数的建议: 对于单个查询和小型工作负荷(少于 100 个事件),请指定无限制的优化时间。如果指定不限制优化时间,数据库引擎优化顾问将给出最佳建议,并且在大多数情况下,优化会在相对较短的时间内完成。

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

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

目录
相关文章
|
25天前
|
运维 Java Serverless
函数计算产品使用问题之是否会受执行超时时间的限制
函数计算产品作为一种事件驱动的全托管计算服务,让用户能够专注于业务逻辑的编写,而无需关心底层服务器的管理与运维。你可以有效地利用函数计算产品来支撑各类应用场景,从简单的数据处理到复杂的业务逻辑,实现快速、高效、低成本的云上部署与运维。以下是一些关于使用函数计算产品的合集和要点,帮助你更好地理解和应用这一服务。
|
2月前
|
C语言
编写一个程序, 给出两个时间,计算出两个时间之差,如给出1120表示11:20,1330表示13:30, 将时间间隔以分钟为单位输出。
这是一个C语言程序,它接收两个时间(小时:分钟格式)作为输入,然后计算并输出两个时间之间的差值。代码包括输入处理、时间转换为分钟以及计算时间差。程序运行结果展示了一个具体的示例时间差。
22 0
|
11月前
wustojc2011计算终止时间
wustojc2011计算终止时间
31 0
|
12月前
|
Windows
连续时间系统的冲激响应和零状态响应
连续时间系统的冲激响应和零状态响应
182 0
|
算法 Python
通过初始时间和流逝的分钟数计算终止时间
通过初始时间和流逝的分钟数计算终止时间
69 0
|
Java
java判断当前时间是否在某个时间区间内(可精确到毫秒)
java判断当前时间是否在某个时间区间内(可精确到毫秒)
765 0
java判断当前时间是否在某个时间区间内(可精确到毫秒)
时间大小判断
大家可以根据自己的理解去使用 before 是在什么之前 after 是在什么之后 true 对 false 错
55 0
时间大小判断
|
数据采集 大数据 数据库
爬虫识别-小于自设值的次数-代码实现读取默认时间|学习笔记
快速学习爬虫识别-小于自设值的次数-代码实现读取默认时间。
101 0
爬虫识别-小于自设值的次数-代码实现读取默认时间|学习笔记
|
Arthas JSON 监控
项目中使用了这个属性赋值方法,接口耗时提升了几十毫秒
使用了这个属性赋值方法,接口耗时提升了几十毫秒
136 0
项目中使用了这个属性赋值方法,接口耗时提升了几十毫秒
|
监控 Java 应用服务中间件
系统gc后线程数增加原因分析过程
问题&现象1、由于系统过一段时间(四五天)commited old区会增大,我们应用中增加每天凌晨一次主动fullgc的任务,但是观察下来发现每天经过system.gc后线程数会增加几个,一直增加到接近300不会增加,并且增加的线程为守护线程。监控图如下:2、某些机器偶然出现线程数陡增情况:分析第一反应为fullgc时会新建gc线程去处理,但是通过jstack指令监控两天的线程变化发现,g