获取优化建议
可以调用
ANALYZE_WORKLOAD 以获取有关查询和数据库对象的优化建议。使用函数实参指定要分析哪些事件以及何时进行分析。
设置分析范围和时间范围
ANALYZE_WORKLOAD的 scope 实参确定要分析的内容：
可选 since‑time 实参用于指定从自 since‑time 开始的所有范围内事件返回值，并继续保持当前系统状态。如果省略 since_time，ANALYZE_WORKLOAD 将返回有关自记录的上次调用函数的时间以来的事件的建议。必须将 since‑time 字符串值显式转换为 TIMESTAMP 或 TIMESTAMPTZ。
以下示例显示了四种用不同格式表达 since‑time 实参的方法。对于自 2012 年 10 月 4 日以来表 t1 的工作负载，所有查询都返回相同的结果：
=> SELECT ANALYZE_WORKLOAD('t1', TIMESTAMP '2012-10-04 11:18:15');
=> SELECT ANALYZE_WORKLOAD('t1', '2012-10-04 11:18:15'::TIMESTAMPTZ);
=> SELECT ANALYZE_WORKLOAD('t1', 'October 4, 2012'::TIMESTAMP);
=> SELECT ANALYZE_WORKLOAD('t1', '10-04-12'::TIMESTAMPTZ);
保存函数结果
通过将 ANALYZE_WORKLOAD 的第二个实参设置为 true，可以保存该函数的结果，而无需分析自特定时间以来的事件。默认值为 false，且不保存任何结果。保存函数结果之后，ANALYZE_WORKLOAD 的随后调用仅分析自上次保存已返回的数据以来的事件，并忽略所有先前的事件。
例如，以下语句返回架构中所有数据库对象的建议，并记录此分析调用。
=> SELECT ANALYZE_WORKLOAD('', true);
下一次调用 ANALYZE_WORKLOAD 时，将分析自此点以后的事件。
观察值计数和时间
observation_count 列返回一个整数，表示工作负载分析器为此优化建议观察到的事件总数。对于上述每种情况，工作负载分析器都会提出第一项建议。observation_time 中的 Null 结果表示仅该建议来自当前系统状态，而不是来自之前的事件。
优化目标
tuning_parameter 列返回工作负载分析器建议您对其应用优化操作的对象。上述示例中的 release 参数通知 DBA 为用户版本设置密码。
优化建议和成本
工作负载分析器的输出将在 tuning_description 列返回您应当考虑的任务的简短描述并在适当时，在 tuning_command column 列返回可以运行的 SQL 命令。在上述记录 1 和 2 中，工作负载分析器建议您在两个表上运行
Database Designer，并建议在记录 3 中设置用户密码。注意，记录 3 还提供可运行的 ALTER USER 命令，因为优化操为 SQL 命令。
tuning_cost 列中的输出指示运行建议的优化命令所需的成本：
-
LOW：运行优化命令对资源的影响最小。可以随时执行优化操作，与上面的在 Record 3 中更改用户密码一样。 -
MEDIUM：运行优化命令对资源的影响适中。 -
HIGH：运行优化命令对资源的影响最大。根据数据库或表大小，考虑在非负载峰值时段执行开销较大的操作。
示例
以下语句要求工作负载分析器分析 locations 表的所有事件：
=> SELECT ANALYZE_WORKLOAD('locations');
工作负载分析器返回建议，建议您在表中运行 Database Designer。根据 locations 的大小，该操作可能会产生较高的成本：
-[ RECORD 1 ]----------+------------------------------------------------
observation_count | 1
first_observation_time |
last_observation_time |
tuning_parameter | public.locations
tuning_description | run database designer on table public.locations
tuning_command |
tuning_cost | HIGH
以下语句将分析今天之前一周以来 VMart 示例数据库中所有表上的工作负载：
=> SELECT ANALYZE_WORKLOAD('', NOW() - INTERVAL '1 week');
工作负载分析器返回以下结果：
-[ RECORD 1 ]----------+------------------------------------------------------
observation_count | 4
first_observation_time | 2012-02-17 13:57:17.799003-04
last_observation_time | 2011-04-22 12:05:26.856456-04
tuning_parameter | store.store_orders_fact.date_ordered
tuning_description | analyze statistics on table column store.store_orders_fact.date_ordered
tuning_command | select analyze_statistics('store.store_orders_fact.date_ordered');
tuning_cost | MEDIUM
-[ RECORD 2 ]---------+------------------------------------------------------
...
-[ RECORD 14 ]---------+-----------------------------------------------------
observation_count | 2
first_observation_time | 2012-02-19 17:52:03.022644-04
last_observation_time | 2012-02-19 17:52:03.02301-04
tuning_parameter | SELECT x FROM t WHERE x > (SELECT SUM(DISTINCT x) FROM
| t GROUP BY y) OR x < 9;
tuning_description | consider incremental design on query
tuning_command |
tuning_cost | HIGH
工作负载分析器发现两个问题：
-
在记录 1 中，
store.store_orders_fact table中的date_ordered列可能具有过时的统计信息，因此工作负载分析器建议对该列运行ANALYZE_STATISTICS。函数输出还会返回要运行的查询。例如：=> SELECT ANALYZE_STATISTICS('store.store_orders_fact.date_ordered'); -
在记录 14 中，工作负载分析器在
tuning_parameter列中识别出性能欠佳的查询。建议使用 Database Designer 运行增量设计。工作负载分析器将潜在成本评定为HIGH。
系统表建议
还可以通过查询系统表
TUNING_RECOMMENDATIONS 获取优化建议，这样将从上一次 ANALYZE_WORKLOAD 调用返回优化建议结果。
=> SELECT * FROM tuning_recommendations;
工作负载分析器用于其建议的系统信息保留在 SQL 系统表中，因此查询 TUNING_RECOMMENDATIONS 系统表不会运行工作负载分析器。