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

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

目录
相关文章
|
3月前
|
运维 Serverless 网络安全
函数计算产品使用问题之函数运行时间大于24小时该如何解决
函数计算产品作为一种事件驱动的全托管计算服务,让用户能够专注于业务逻辑的编写,而无需关心底层服务器的管理与运维。你可以有效地利用函数计算产品来支撑各类应用场景,从简单的数据处理到复杂的业务逻辑,实现快速、高效、低成本的云上部署与运维。以下是一些关于使用函数计算产品的合集和要点,帮助你更好地理解和应用这一服务。
|
3月前
|
运维 监控 Serverless
函数计算产品使用问题之超时时间最大是多少
函数计算产品作为一种事件驱动的全托管计算服务,让用户能够专注于业务逻辑的编写,而无需关心底层服务器的管理与运维。你可以有效地利用函数计算产品来支撑各类应用场景,从简单的数据处理到复杂的业务逻辑,实现快速、高效、低成本的云上部署与运维。以下是一些关于使用函数计算产品的合集和要点,帮助你更好地理解和应用这一服务。
|
3月前
|
运维 监控 Serverless
函数计算产品使用问题之怎么查询在特定时间段内应用的调用次数
函数计算产品作为一种事件驱动的全托管计算服务,让用户能够专注于业务逻辑的编写,而无需关心底层服务器的管理与运维。你可以有效地利用函数计算产品来支撑各类应用场景,从简单的数据处理到复杂的业务逻辑,实现快速、高效、低成本的云上部署与运维。以下是一些关于使用函数计算产品的合集和要点,帮助你更好地理解和应用这一服务。
|
4月前
|
域名解析 运维 Serverless
函数计算产品使用问题之设置最大实例数为1和最大并发数为20,当请求数量超过20时,系统会如何处理
阿里云Serverless 应用引擎(SAE)提供了完整的微服务应用生命周期管理能力,包括应用部署、服务治理、开发运维、资源管理等功能,并通过扩展功能支持多环境管理、API Gateway、事件驱动等高级应用场景,帮助企业快速构建、部署、运维和扩展微服务架构,实现Serverless化的应用部署与运维模式。以下是对SAE产品使用合集的概述,包括应用管理、服务治理、开发运维、资源管理等方面。
|
4月前
|
存储 Java Serverless
函数计算产品使用问题之执行一个比较耗时的操作导致请求超时时,该怎么办
函数计算产品作为一种事件驱动的全托管计算服务,让用户能够专注于业务逻辑的编写,而无需关心底层服务器的管理与运维。你可以有效地利用函数计算产品来支撑各类应用场景,从简单的数据处理到复杂的业务逻辑,实现快速、高效、低成本的云上部署与运维。以下是一些关于使用函数计算产品的合集和要点,帮助你更好地理解和应用这一服务。
|
5月前
|
运维 Java Serverless
函数计算产品使用问题之是否会受执行超时时间的限制
函数计算产品作为一种事件驱动的全托管计算服务,让用户能够专注于业务逻辑的编写,而无需关心底层服务器的管理与运维。你可以有效地利用函数计算产品来支撑各类应用场景,从简单的数据处理到复杂的业务逻辑,实现快速、高效、低成本的云上部署与运维。以下是一些关于使用函数计算产品的合集和要点,帮助你更好地理解和应用这一服务。
|
Windows
连续时间系统的冲激响应和零状态响应
连续时间系统的冲激响应和零状态响应
229 0
|
算法 Python
通过初始时间和流逝的分钟数计算终止时间
通过初始时间和流逝的分钟数计算终止时间
99 0
时间大小判断
大家可以根据自己的理解去使用 before 是在什么之前 after 是在什么之后 true 对 false 错
71 0
时间大小判断
|
监控 Java 应用服务中间件
系统gc后线程数增加原因分析过程
问题&现象1、由于系统过一段时间(四五天)commited old区会增大,我们应用中增加每天凌晨一次主动fullgc的任务,但是观察下来发现每天经过system.gc后线程数会增加几个,一直增加到接近300不会增加,并且增加的线程为守护线程。监控图如下:2、某些机器偶然出现线程数陡增情况:分析第一反应为fullgc时会新建gc线程去处理,但是通过jstack指令监控两天的线程变化发现,g