当前位置：文档之家 › 一次TOP_SQL的性能调优经历

一次TOP_SQL的性能调优经历

  • 格式：pdf
  • 大小：614.22 KB
  • 文档页数：35

1.问题发现1.1一份AWR报告今天，收到一份100个并发用户访问下压力测试的AWR报告，并发事务数平均每秒只有6个不到。

在这个26.53分钟间隔的报告里，CPU TIME在整个TOP 事件中最突出占了近97.6%，在8个CPU系统中，数据库给CPU造成的压力为：(5740/(26.53*60*8)*100%=45.07%，这么小的压力下，CPU就能冲得这么高，说明系统中肯定是有问题的。

下面转向TOP SQL去确认下造成资源争用最明显的SQL语句。

1.2TOP SQL1.2.1SQL ordered by Elapsed Time1.2.2SQL ordered by CPU Time1.2.3SQL ordered by Gets1.3问题发现对一个OLTP系统来说，每一个语句的执行，都是要将其消耗的资源降到最低，这跟 OLAP系统是有差别的。

对于后者来说，它需要的是短的时间返回结果，不管中间你会拿多大的成本做代价。

从上面反映的问题来看，我们的性能，无疑就是葬送在了SQL_ID为4841ajtgh43qy、1hwqh7kvxn6yg、g295mubwupf52和anyty5rts5tzf这四个语句上面，下面将对这四个SQL语句一 一做出分析，并给出相应的调优建议。

2.SQL_ID为4841ajtgh43qy的语句 2.1调整前2.1.1语句SELECT *FROM (SELECT TT.*, ROWNUM AS ROWNOFROM (select to_char(c.cust_id), c.passwordfrom CUST_CERTIFICATION cwhere c.cust_id = :CUST_ID) TTWHERE ROWNUM <= 10) TABLE_ALIAS where TABLE_ALIAS.rowno > 0;2.1.2解释计划又见全表扫2.1.3统计信息每次执行，buffer gets居然达37190.80之多。

2.1.4数值分布2.2原因分析从上面的情况分析来看，原因已经非常明显了，也就是在列cust_id上面，没有索引，导致每次执行该语句时，进行的都是全表扫描操作，这种操作对于一个600万的大表，在一个OLTP 系统中，是很致命的。

2.3调整2.3.1创建索引，并收集统计信息create index crm551.IDX_CUST_CERTIFICATION oncrm551.CUST_CERTIFICATION(cust_id);execute dbms_stats.gather_table_stats(ownname => 'CRM551',tabname => 'CUST_CERTIFICATION',cascade => true);2.3.2语句与原语句一致2.4调整后2.4.1解释计划2.4.2统计信息平均执行一次SQL的一致性读从37,190.80降低到5个，这个优化的效果是相当明显的。

3.SQL_ID为1hwqh7kvxn6yg的语句3.1调整前3.1.1语句SELECT COUNT(*) PAGE_SIZEFROM (select *from (SELECT A.CUST_ORDER_ID,A.ORDER_ITEM_ID,A.OFFER_ID,(SELECT PROD_OFFER_NAMEFROM PROD_OFFERWHERE PROD_OFFER_ID = A.OFFER_IDAND ROWNUM = 1) OFFER_NAME,(SELECT ACC_NBRFROM PROD_INST_551 C, ORDER_ITEM_REL E, ORDER_ITEM FWHERE E.Z_ORDER_ITEM_ID = F.ORDER_ITEM_IDAND E.A_ORDER_ITEM_ID = A.ORDER_ITEM_IDAND F.ORDER_ITEM_OBJ_ID = C.PROD_INST_IDAND F.ORDER_ITEM_CD IN ('13')AND ROWNUM < 2) ACC_NBR,TO_CHAR(A.HANDLE_TIME, 'yyyy-mm-dd hh24:mi:ss') ACCEPT_DATE,A.STATUS_CD,(SELECT CODE_NAMEFROM MAP_CODEWHERE CODE = A.STATUS_CDAND TABLE_NAME = 'ORDER_ITEM'AND CODE_TYPE = 'SOS'AND ROWNUM = 1) STATUS_NAME,A.SERVICE_OFFER_ID,(SELECT SERVICE_OFFER_NAMEFROM SERVICE_OFFERWHERE SERVICE_OFFER_ID = A.SERVICE_OFFER_ID) SERVICE_OFFER_NAMEFROM ORDER_ITEM A, CUSTOMER_ORDER B,PROD_OFFER_INST_551 DWHERE A.CUST_ORDER_ID = B.CUST_ORDER_IDAND A.ORDER_ITEM_OBJ_ID = D.PROD_OFFER_INST_IDAND B.CUST_ID = :CUST_IDAND TN_ID = :LATN_IDAND A.MAIN_FLAG = '1'AND A.PRE_HANDLE_FLAG <> '1'AND A.CUST_ORDER_ID = :CUST_ORDER_IDUNIONSELECT DISTINCT A.CUST_ORDER_ID,A.ORDER_ITEM_ID,A.OFFER_ID,(SELECT PROD_OFFER_NAMEFROM PROD_OFFERWHERE PROD_OFFER_ID = A.OFFER_IDAND ROWNUM = 1) OFFER_NAME,D.CUST_NUMBER,TO_CHAR(A.HANDLE_TIME,'yyyy-mm-dd hh24:mi:ss') ACCEPT_DATE,A.STATUS_CD,(SELECT CODE_NAMEFROM MAP_CODEWHERE CODE = A.STATUS_CDAND TABLE_NAME = 'ORDER_ITEM'AND CODE_TYPE = 'SOS'AND R OWNUM = 1) STATUS_NAME,A.SERVICE_OFFER_ID,(SELECT SERVICE_OFFER_NAMEFROM SERVICE_OFFERWHERE SERVICE_OFFER_ID =A.SERVICE_OFFER_ID) SERVICE_OFFER_NAMEFROM ORDER_ITEM A, CUSTOMER_ORDER B, CUST_551 DWHERE A.CUST_ORDER_ID = B.CUST_ORDER_IDAND A.ORDER_ITEM_OBJ_ID = D.CUST_IDAND B.CUST_ID = :CUST_ID2AND TN_ID = :LATN_ID2AND A.MAIN_FLAG = '1'AND A.PRE_HANDLE_FLAG <> '1'AND A.CUST_ORDER_ID = :CUST_ORDER_ID2UNIONSELECT DISTINCT A.CUST_ORDER_ID,A.ORDER_ITEM_ID,A.OFFER_ID,(SELECT PROD_OFFER_NAMEFROM PROD_OFFERWHERE PROD_OFFER_ID = A.OFFER_IDAND ROWNUM = 1) OFFER_NAME,D.ACCOUNT_NUMBER,TO_CHAR(A.HANDLE_TIME,'yyyy-mm-dd hh24:mi:ss')ACCEPT_DATE,A.STATUS_CD,(SELECT CODE_NAMEFROM MAP_CODEWHERE CODE = A.STATUS_CDAND TABLE_NAME = 'ORDER_ITEM'AND CODE_TYPE = 'SOS'AND ROWNUM = 1) STATUS_NAME,A.SERVICE_OFFER_ID,(SELECT SERVICE_OFFER_NAMEFROM SERVICE_OFFERWHERE SERVICE_OFFER_ID =A.SERVICE_OFFER_ID) SERVICE_OFFER_NAMEFROM ORDER_ITEM A, CUSTOMER_ORDER B, ACCOUNT_551 DWHERE A.CUST_ORDER_ID = B.CUST_ORDER_IDAND A.ORDER_ITEM_OBJ_ID = D.ACCOUNT_IDAND B.CUST_ID = :CUST_ID3AND TN_ID = :LATN_ID3AND A.MAIN_FLAG = '1'AND A.PRE_HANDLE_FLAG <> '1'AND A.CUST_ORDER_ID = :CUST_ORDER_ID3) torder by t.ACCEPT_DATE desc) T3.1.2解释计划3.1.3统计信息每次执行，buffer gets居然达20218.44之多。

3.1.4数值分布3.2原因分析这个语句看起来很吓人，其实没那么可怕。

碰到这种长语句，我们第一步要做的，就是把这个语句拆分，确认性能瓶颈出在哪个模块。

第一步:我们通过union分隔进行拆分，三个子句的绑定变量分别替换成常量值，分别执行 第二步：对比其统计信息发现，第二、三部分统计信息中的一致性读加起来只有30来个，其余的都是第一部分占用的，因此，我们可以锁定UNION子句的第一部分就是“元凶”。

第三步：再次拆分第一部分语句的，最后发现是SQL语句中的黑粗体部分导致大量的一致性读。

查看这部分的解释计划：果然，这部分一方面ORDER_ITEM_REL表做了全表扫描，然后做HASH JOIN的驱动表也不对。

因为只有ORDER_ITEM_REL才与外面的驱动表有关联条件AND E.A_ORDER_ITEM_ID = A.ORDER_ITEM_ID，因此要做HASH JOIN或NESTED LOOP，驱动表都应该是它而不应该是ORDER_ITEM。

合集下载

oracle sql 优化技巧

oracle sql 优化技巧

oracle sql 优化技巧（实用版3篇）目录（篇1）1.Oracle SQL 简介2.优化技巧2.1 减少访问数据库次数2.2 选择最有效率的表名顺序2.3 避免使用 SELECT2.4 利用 DECODE 函数2.5 设置 ARRAYSIZE 参数2.6 使用 TRUNCATE 替代 DELETE2.7 多使用 COMMIT 命令2.8 合理使用索引正文（篇1）Oracle SQL 是一款广泛应用于各类大、中、小微机环境的高效、可靠的关系数据库管理系统。

为了提高 Oracle SQL 的性能，本文将为您介绍一些优化技巧。

首先，减少访问数据库的次数是最基本的优化方法。

Oracle 在内部执行了许多工作，如解析 SQL 语句、估算索引的利用率、读数据块等，这些都会大量耗费 Oracle 数据库的运行。

因此，尽量减少访问数据库的次数，可以有效提高系统性能。

其次，选择最有效率的表名顺序也可以明显提升 Oracle 的性能。

Oracle 解析器是按照从右到左的顺序处理 FROM 子句中的表名，因此，合理安排表名顺序，可以减少解析时间，提高查询效率。

在执行 SELECT 子句时，应尽量避免使用，因为 Oracle 在解析的过程中，会将依次转换成列名，这是通过查询数据字典完成的，耗费时间较长。

DECODE 函数也是一个很好的优化工具，它可以避免重复扫描相同记录，或者重复连接相同的表，提高查询效率。

在 SQLPlus 和 SQLForms 以及 ProC 中，可以重新设置 ARRAYSIZE 参数。

该参数可以明显增加每次数据库访问时的检索数据量，从而提高系统性能。

建议将该参数设置为 200。

当需要删除数据时，尽量使用 TRUNCATE 语句替代 DELETE 语句。

执行 TRUNCATE 命令时，回滚段不会存放任何可被恢复的信息，所有数据不能被恢复。

因此，TRUNCATE 命令执行时间短，且资源消耗少。

在使用 Oracle 时，尽量多使用 COMMIT 命令。

如何进行SQL调优

如何进行SQL调优

如何进行SQL调优SQL调优是优化数据库性能的一个重要步骤。

通常情况下，优化SQL查询的效率会使整个系统的性能得到提升。

在这篇文章中，我们将探讨如何进行SQL调优。

一、分析SQL语句首先，我们需要分析SQL查询语句。

如果SQL查询不正确或不充分，则不可能实现有效的调优。

我们需要了解查询的目的、查询的表、所需的数据以及查询的条件等等。

在分析查询语句时，我们需要关注以下几个方面：1.查询完成的时间是否满足需求；2.过滤条件是否合适；3.表之间的关系是否正确；4.是否使用了合适的索引；5.查询中使用了哪些函数；6.是否将复杂的查询分解为简单的查询；7.是否存在重复数据；8.是否使用了动态语句。

二、优化数据表结构第二个优化策略是优化数据表结构。

优化数据表结构可以使查询更快并减少查询时间。

以下是一些优化数据表结构的建议：1.将表拆分为更小的表；2.对于大型的表，可以使查询更快，更好地维护和管理；3.添加数据到表中时，使用批量插入而不是单独插入；4.为表的主键添加索引；5.使用适当的数据类型；6.删除不必要的列；7.标准化表设计。

三、使用优化查询技术第三个优化策略是使用优化查询技术。

以下是一些优化查询技术的建议：1.使用预编译语句；2.使用存储过程；3.将大的表拆分为小表；4.优化查询过程中使用的函数；5.范围查询的优化技术；6.优化复杂查询；7.熟悉查询缓存的工作原理；8.使用正确的JOIN语句。

四、使用合适的索引使用合适的索引是第四个优化策略。

索引是用于查找表中数据的一种结构。

以下是一些使用索引的建议：1.只有在需要时才使用索引；2.使用准确性为索引提供数据；3.使用索引可以使查询更快，但也会增加插入和修改的时间；4.对于大型表，使用索引可以显著提高性能；5.使用覆盖索引；6.避免使用不规范的索引；7.使用联合索引；8.使用优化查询缓存。

五、优化数据库服务器优化数据库服务器是第五个优化策略。

以下是一些优化服务器的建议：1.选择正确的硬件；2.选择正确的操作系统；3.使用正确的配置参数；4.配置正确的缓存大小；5.使用内存表代替磁盘表；6.合理设置自动增量字段；7.优化写和读的优化区域；8.备份和压缩数据。

数据库性能调优的整体流程与方法

数据库性能调优的整体流程与方法

数据库性能调优的整体流程与方法数据库性能调优是提高数据库系统性能的关键步骤之一。

当数据库系统出现性能问题时，通过调优可以帮助优化查询、提高响应速度、增加系统容量等，从而更好地满足业务需求和用户期望。

本文将介绍数据库性能调优的整体流程与方法，以帮助读者深入了解并掌握这一重要技能。

一、性能调优的整体流程数据库性能调优包含以下几个关键步骤：1. 收集性能指标：首先需要收集数据库系统的性能指标，如CPU利用率、内存利用率、磁盘I/O等。

这些指标反映了数据库系统的运行状况，帮助我们定位性能问题的根本原因。

2. 分析问题症结：根据收集到的性能指标，分析性能问题的症结所在。

可能会发现一些明显的性能瓶颈，如查询慢、连接数过高等。

这一步骤是深入了解问题所在的关键，可以采用数据库监控工具、性能剖析工具等来帮助分析。

3. 优化数据库设计：数据库设计是影响数据库性能的重要因素之一。

根据分析结果，考虑优化表结构、索引设计、数据模型等。

在表结构设计方面，可以进行分表、分区等优化；在索引设计方面，需要权衡索引的创建与维护成本。

4. 优化查询语句：查询语句是数据库性能调优的关键点之一。

通过检查查询语句是否合理、是否有优化空间，优化查询语句的执行计划、避免全表扫描等方式，提高查询效率和性能。

5. 调整系统参数：根据具体的数据库产品，调整相应的系统参数。

数据库产品通常提供了一些性能调优的参数，可以根据实际情况进行调整以达到最佳性能。

比如可以调整数据库缓存大小，设置并发连接数等。

6. 硬件升级与优化：当软件调优无法满足性能需求时，可以考虑进行硬件升级与优化。

这可能涉及增加内存、扩容磁盘空间、更换更高性能的存储设备等方面。

此外，优化网络架构、负载均衡等也可以改善数据库系统的性能。

7. 执行测试与监控：在完成调优后，需要进行系统测试和性能监控，以确保调优效果达到预期。

可以使用模拟负载、压力测试工具进行测试，同时监控性能指标来评估系统的性能状况。

SQLServer数据库性能调优技巧

SQLServer数据库性能调优技巧

SQLServer数据库性能调优技巧第一章：SQLServer数据库性能调优概述SQLServer是一种常用的关系型数据库管理系统，在大型企业和云计算环境中广泛应用。

为了确保数据库的高性能和可靠性，进行数据库性能调优非常重要。

本章将介绍SQLServer数据库性能调优的概念和目标。

1.1 数据库性能调优的概念数据库性能调优是指通过分析和优化数据库的结构、查询、索引、存储和配置等方面的问题，以提高数据库系统的效率和性能。

优化数据库性能可以显著提升数据的访问速度、减少系统响应时间和提高数据库的处理能力。

1.2 数据库性能调优的目标数据库性能调优的主要目标是提高数据库的运行效率和用户的体验，具体目标包括：- 提高数据的访问速度：通过合理的查询优化和索引设计，加快数据的检索速度。

- 减少系统响应时间：通过调整数据库配置、优化SQL 查询和提高硬件性能等措施，缩短系统响应时间。

- 提高数据库的处理能力：通过合理的分区设计、并行处理和负载均衡等措施，提高数据库的并发处理能力。

第二章：SQLServer数据库性能调优基础在进行SQLServer数据库性能调优之前，有几个基础概念需要了解，包括数据库的结构、查询执行计划和索引等。

2.1 数据库的结构SQLServer数据库由多个表组成，每个表由多个行和列组成。

表有一定的关系，通过主键和外键来建立关联。

了解数据库的结构对于进行性能调优非常重要。

2.2 查询执行计划查询执行计划是SQLServer数据库执行查询语句时的执行路径和操作过程的详细描述。

通过分析查询执行计划，可以找到潜在的性能问题，并进行相应的优化。

2.3 索引索引是一种特殊的数据库对象，用于加快查询速度。

常见的索引类型包括聚集索引、非聚集索引和全文索引等。

合理设计索引可以提高查询的性能。

第三章：SQLServer数据库性能调优技巧本章将介绍一些常用的SQLServer数据库性能调优技巧，包括查询优化、索引优化、配置优化和硬件优化等。