主页 / dba / 问题 / 14489
Accepted
Femme Fatale
Asked: 2012-03-07 09:55:03 +0800 CST

甲骨文灰报告

  • 772

最近，我收到了一份来自 DBA的ash report 。

对我来说，这份报告就像法语。我不知道它是关于什么的，也不知道这份报告里写的是什么。有人可以指导我阅读它并向我解释我应该采取哪些所有步骤来使我的查询稳定并减少 cpu 消耗。此外，哪个查询占用了更多的 CPU。
1. 请推荐我应该执行什么操作。
2. 哪个查询占用了我更多的 CPU，我应该如何改进它。

oracle database-design

1 个回答

  1. Best Answer

    我首先要说的是，Oracle DBA 应该通过查看 ASH 和 AWR 报告来了解问题所在。如果没有 AWR 报告，就很难知道这里真正的问题是什么。但是，我会帮助您解决第一个问题。

    图中最上面Top SQL with Top Row Sources的查询显示带有 sql_id 的查询8t441yd5bwygd正在执行表扫描。Complete List Of SQL Text您可以在该部分中看到查询的文本。

    这里的主要问题是LIKE查询中有一个子句，它也使用lower()函数将列数据转换为小写，然后与绑定变量进行比较，绑定变量:1是从应用程序传递到查询中的值。

    降低：

    select * from PERSON_CARD where lower(PERSON_ID) like :1;

    要正确回答这个问题，我们确实需要有关所涉及列的数据类型以及应用程序可以传递到 WHERE 子句中的可能值的更多信息，但有几种可能性。

    我担心的是这个 SQL（可能还有模式设计）是由 Hibernate 生成的，并且 PERSON_ID 是一个长的十六进制字符串 UDID 而不是整数。

    1）PERSON_ID列的数据为非数字字符串：

    如果（且仅当）输入值 :1 仅在字符串末尾包含一个通配符（例如LIKE "foo%"：），您可以在 PERSON_ID 列上创建功能索引：

    create index person_card_pid_idx on person_card(lower(person_id));

    这将导致索引范围扫描而不是表扫描（我希望如此！）。

    2）PERSON_ID列中的数据实际上是一个整数，与传入的值完全匹配：1

    这里有 2 种可能性。如果 PERSON_ID 尚未在数据库中建立索引，请添加一个索引。如果它已经编入索引，请让开发人员更改应用程序以使用PERSON_ID=:1LOWER() 调用而不是 LIKE。

    3) PERSON_ID列数据为非数字字符串&匹配的:1中的值在字符串开头包含通配符'%'

    您将不得不使用 Oracle 文本索引。

    • 4

相关问题