【问题标题】:How to describe performance issue in relational database?如何描述关系数据库中的性能问题?
【发布时间】:2016-04-30 17:56:18
【问题描述】:

我有一个在关系数据库中运行的查询不符合用户的期望。

我应该提供哪些信息以及应该避免哪些信息,以便在本网站上获得有效的帮助?

【问题讨论】:

  • 发布这个问题的动机是,我没有为关系数据库找到一个类似于this 的页面[r]。我自己为 Oracle 数据库回答了这个问题,希望其他人扩展/更正信息并为其他数据库添加答案。
  • 这不是博客。决定用户的期望是一个好的开始。 (例如吞吐量、响应能力)

标签: oracle performance relational-database query-optimization


【解决方案1】:

对于 Oracle 数据库,请提供以下信息:

描述问题的症状

描述导致问题的行为。查询的行为是稳定的还是仅出现问题 有时,带有特定参数或简单随机。您可以在 IDE(例如 SQL Developer)中重现此行为吗?

描述环境

定义准确的 Oracle 版本

 select * from v$version

描述您如何连接到数据库:驱动程序、ORM、编程语言。提供名称和/或版本号。

描述查询

发布查询文本。尝试简化 - 展示一个可重现的最小示例

示例 - 您有问题的查询连接了 10 个表。检查您是否在具有 9 个或 8 个连接的查询中看到相同的症状。 下级,直到您看到问题并仅显示缩减后的查询。

是的,这很昂贵,但它大大增加了您获得支持的机会! 查询越小,它吸引的人数就越高 支持者。

描述执行计划

要获得执行计划,请运行此语句(替换您的查询文本)

 EXPLAIN PLAN  SET STATEMENT_ID = '<some_id>' into   plan_table  FOR
     select * from ....   -- your query here 
 ;

执行计划存储在PLAN_TABLE,查看它运行这个查询

 SELECT * FROM table(DBMS_XPLAN.DISPLAY('plan_table', '<some_id>','ALL')); 

显示完整结果(不仅是带有执行计划的表格)。 非常重要的可能是谓词部分和下面的注释。

select * from dual where dummy = :1; 的示例

Plan hash value: 272002086

--------------------------------------------------------------------------
| Id  | Operation         | Name | Rows  | Bytes | Cost (%CPU)| Time     |
--------------------------------------------------------------------------
|   0 | SELECT STATEMENT  |      |     1 |     2 |     2   (0)| 00:00:01 |
|*  1 |  TABLE ACCESS FULL| DUAL |     1 |     2 |     2   (0)| 00:00:01 |
--------------------------------------------------------------------------

Query Block Name / Object Alias (identified by operation id):
-------------------------------------------------------------

   1 - SEL$1 / DUAL@SEL$1

Predicate Information (identified by operation id):
---------------------------------------------------

   1 - filter("DUMMY"=:1)

Column Projection Information (identified by operation id):
-----------------------------------------------------------

   1 - "DUMMY"[VARCHAR2,1]

不要剪切和粘贴 IDE 解释计划的图形结果

这个执行计划是真正执行的吗?

不幸的是,并非总是如此。 解释执行计划可能有几个原因differ from the real one

如果您有疑问(尤其是当您看到一个好的计划,但查询运行不佳),您可以 从提供SQL_ID 的数据库缓存中提取计划。

 SELECT t.* FROM  table(DBMS_XPLAN.DISPLAY_CURSOR('<SQL_ID>',null,'ALL')) t; 

当前正在运行的查询的 SQL_ID(或正在运行但仍在缓存中)可以通过以下方式找到 文本匹配和/或数据库用户:

select sql_id, sql_fulltext from v$sql a where 
 lower(sql_text) like lower('%<some identifying part of the query text>%') 
  and parsing_schema_name = '<user running the query>';

如果您拥有 AWR 许可证,您可以从那里获得执行计划,即使是在历史中运行的查询。

SELECT t.*
FROM  table(DBMS_XPLAN.DISPLAY_AWR('10u2rj016s96k'  )) t;

可以使用 SQL_ID 找到

select sql_id, sql_text 
from dba_hist_sqltext a 
where lower(sql_text) like lower('%<some identifying part of the query text>%')

描述数据

显示表的 DDL 和这些表上的索引。

提及是否最近收集了优化器统计信息并显示使用的dbms_statsgather 语句。

对于关键表,请提供有关段大小、行号、分区等信息...

对于访问或连接中使用的列,提供有关不同值数量的信息。 值是否均匀分布或倾斜(例如,经常出现的少量值和大量 稀有值)。 你定义直方图吗?

还有什么?

当然,这只是基本信息,可能还需要其他信息,例如系统统计信息或优化器参数。 但是再次尝试提供(您的东西)可以识别问题的最少信息。 根据要求发布更多信息。

祝你好运!

【讨论】:

  • Do you define histograms 纠正我如果我错了,在执行收集统计时创建直方图(如果 mehtod_opt 是默认值)。所以实际上你并没有像默认创建的那样定义直方图,但是你可以删除它们。
  • @APC 欢迎您;仍在等待 MySQL 或 Postgress 的帖子。这个问题会更切题;)
  • 获取 SQL 监视器报告。它是诊断 SQL 性能问题时使用的 工具。它有方式比一个简单的解释计划更多的信息
  • @APC 这里有很多涉及分区的问题,这也是需要 EE 的成本选项。所以我不会断言每个人都在那条船上...... :)
  • 仅供参考 - SQL Monitor 报告仅适用于使用企业版且已获得诊断和调优选项许可的组织。
猜你喜欢
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2019-05-07
  • 2012-06-23
  • 1970-01-01
  • 2021-01-07
相关资源
最近更新 更多