频繁变化的表无效索引造成的热点块争用

客户号码办理系统出现会话连接数超高告警,造成数据库性能问题,影响了全网业务办理。告警发生在11月7日20点--21点时间段,查询当时等待事件最高的buffer busy waits。

查询该等待事件对应的sql;

select sql_id, count(*)

from v$active_session_history

where sample_time >=

to_date(‘2016-11-07 20:00:00‘, ‘yyyy-mm-dd hh24:mi:ss‘)

and sample_time <=

to_date(‘2016-11-07 21:00:00‘, ‘yyyy-mm-dd hh24:mi:ss‘)

and event = ‘buffer busy waits‘

group by sql_id order by 2 desc ;

根据SQL_id查看对应时间点所产生的阻塞热点块

select a.BLOCKING_SESSION,count(*) from gv$active_session_history a where sql_id=‘5qhcs0sc47t5t‘ and  sample_time >=

to_date(‘2016-11-07 20:00:00‘, ‘yyyy-mm-dd hh24:mi:ss‘)

and sample_time <=

to_date(‘2016-11-07 21:00:00‘, ‘yyyy-mm-dd hh24:mi:ss‘)

and event = ‘buffer busy waits‘ group by a.BLOCKING_SESSION;

找出主要的BLOKING_SESSION为2830,3994,4252,4107.

根据找到的BLOKING_SESSION找到当时争用的热点块

select sql_id,p1,a.p1text,p2,p2text,p3,p3text,count(*) from v$active_session_history a where  sample_time >=

to_date(‘2016-11-07 20:00:00‘, ‘yyyy-mm-dd hh24:mi:ss‘)

and sample_time <=

to_date(‘2016-11-07 21:00:00‘, ‘yyyy-mm-dd hh24:mi:ss‘)

and a.SESSION_ID in (2830,3994,4252,4107)

group by sql_id,p1,a.p1text,p2,p2text,p3,p3text;

找出对应的热点块为:21463、16199、16215

根据热点块找到到底是表还是索引引起的争用

select * from DBA_EXTENTS where FILE_ID = &AFN and &BL between BLOCK_ID and BLOCK_ID + BLOCKS - 1;

&AFN$BL代入上面查到的值AFN=169,BL为21463、16199、16215是UCR_TRADE_03.IDX_SYNC_PHCODE_IDLE_1索引

通过抓取当时20点--21点AWR快照信息也印证了这一点;

查看此索引创建的列为‘ALTER_TYPE‘, ‘SERIAL_NUMBER‘查看该表的数据量信息怀疑该表变化特别频繁:

该表在7号22点已经收集过统计信息。但是实际上的表内数据为14行数据:

看见了吗,只有14行数据,但是统计信息收集后显示NUW_ROWS为11228。说明这个表变化还是特别频繁的。

随即决定删除该无用索引,一个表内仅有14条数据。且该表insert、delete特别频繁。走索引反而适得其反,删除该无效索引UCR_TRADE_03.IDX_SYNC_PHCODE_IDLE_1。

附录:ADDM建议信息:

SQL statements consuming significant database time were found.

RECOMMENDATION 1: SQL Tuning, 88% benefit (726535 seconds)

ACTION: Investigate the SQL statement with SQL_ID "5qhcs0sc47t5t" for

possible performance improvements.

RELEVANT OBJECT: SQL statement with SQL_ID 5qhcs0sc47t5t and

PLAN_HASH 2432174272

UPDATE  TF_R_PHCODE_IDLE R              SET     R.UPDATE_TIME =

SYSDATE,                     R.SALE_SYSTEM_TAG = ‘2‘

WHERE   R.SERIAL_NUMBER = :1             AND     R.PROVINCE_CODE = :2

RATIONALE: SQL statement with SQL_ID "5qhcs0sc47t5t" was executed 3887

times and had an average elapsed time of 186 seconds.

RATIONALE: Waiting for event "buffer busy waits" in wait class

"Concurrency" accounted for 92% of the database time spent in

processing the SQL statement with SQL_ID "5qhcs0sc47t5t".

RATIONALE: Waiting for event "enq: TX - row lock contention" in wait

class "Application" accounted for 5% of the database time spent in

processing the SQL statement with SQL_ID "5qhcs0sc47t5t".

RATIONALE: Waiting for event "enq: TX - contention" in wait class

"Other" accounted for 1% of the database time spent in processing the

SQL statement with SQL_ID "5qhcs0sc47t5t".

RECOMMENDATION 2: SQL Tuning, 87% benefit (721075 seconds)

ACTION: Investigate the SQL statement with SQL_ID "b08xxahpxcak4" for

possible performance improvements.

RELEVANT OBJECT: SQL statement with SQL_ID b08xxahpxcak4

INSERT INTO SYNC_PHCODE_IDLE (CHNL_NO ,ROW_ID ,ALTER_TIME ,ALTER_TYPE

, SERIAL_NUMBER ,CODE_REVERSE ,NET_TYPE_CODE ,BRAND_CODE ,IMSI ,

SIM_CARD_NO ,CODE_STATE ,TRADE_CATE ,CODE_GRADE ,LIMIT_ID , NICE_RULE

,GROUP_ID ,PROVINCE_CODE ,EPARCHY_CODE ,CITY_CODE , DEPART_ID

,CHANNEL_ID ,STAFF_ID ,STOCK_ID ,STOCK_LEVEL , POOL_ID ,ECS_TAG

,BATCH_DEF_TAG ,BATCH_ID ,STAFF_IN ,TIME_IN , STAFF_UPSHELF

,TIME_UPSHELF ,STAFF_DOWNSHELF ,TIME_DOWNSHELF , OCCUPY_TIME

,REUSE_COUNT ,OPER_BATCH_ID ,OPER_DEPART_ID , OPER_STAFF_ID

,OPER_TIME ,ASSIGN_BATCH_ID ,ASSIGN_TAG , CONFIRM_TAG

,ASSIGN_STAFF_ID ,ASSIGN_TIME ,OPEN_DEPART_ID , OPEN_STAFF_ID

,BACK_STAFF_ID ,BACK_TIME ,UPDATE_STAFF , UPDATE_TIME ,RSVALUE1

,RSVALUE2 ,RSVALUE3 ,RSVALUE4 , RSVALUE5 ,RSVALUE6

,WIRELESS_CARD_TYPE ,RELEASE_TIME ,SYS_CODE , PROC_KEY ,PROC_KEY_MODE

,USE_TYPE) VALUES (SUBSTR(:B1 ,-2) ,:B2 ,TO_CHAR(SYSTIMESTAMP

,‘YYYYMMDDHH24MISSFF‘) ,‘UPD‘ , :B1 ,:B3 ,:B4 ,:B5 ,:B6 , :B7 ,:B8

,:B9 ,:B10 ,:B11 , :B12 ,:B13 ,:B14 ,:B15 ,:B16 , :B17 ,:B18 ,:B19

,:B20 ,:B21 , :B22 ,:B23 ,:B24 ,:B25 ,:B26 ,:B27 , :B28 ,:B29 ,:B30

,:B31 , :B32 ,:B33 ,:B34 ,:B35 , :B36 ,:B37 ,:B38 ,:B39 , :B40 ,:B41

,:B42 ,:B43 , :B44 ,:B45 ,:B46 ,:B47 , :B48 ,:B49 ,:B50 ,:B51 ,:B52 ,

:B53 ,:B54 ,:B55 ,:B56 ,:B57 , :B58 ,:B59 ,:B60 )

RATIONALE: SQL statement with SQL_ID "b08xxahpxcak4" was executed 9774

times and had an average elapsed time of 73 seconds.

时间: 2024-08-10 21:30:32

频繁变化的表无效索引造成的热点块争用的相关文章

处理无效索引ORA-20000的故障

处理无效索引ORA-20000的故障 作者:赵全文     网名:guestart 本周四上午,开发同学反馈,数据库Oracle链接过一段时间就会断掉,他问是不是因为IIS和数据库不在一个网段的原因,要长连接才可以吧?于是,登录这套数据库的EMCC 12C监控里发现 有2个SQL 执行了很长时间 都失败,如下图 查看alert日志文件,发现有以下报错,如下图, 查看上图所示的那个trc文件,如下图操作, 发现里面的报错 为ORA-20000,即用户对应的表下有一个索引不可用,见下图所示, Ale

Oracle索引碎片检查及定期重建常用表的索引

转载地址:http://www.cnblogs.com/zhaoguan_wang/p/5169821.html 背景说明: 今天查阅书籍时,偶然间发现"在对某个索引行执行删除操作时,只是为该行增加了一个删除标记,这个索引行并不会释放它的存储空间,Insert产生的新的索引行也不能被插入到该位置.索引列的修改过程其实是将对应的列值删除,然后再插入新的列值(与数据行本身的修改是不一致的,这也正是我们尽量不使用修改频繁的列来创建索引的原因).所以,无论是插入.修改.删除,都需要消耗存储空间,增大B-

Oracle索引总结(五)- Oracle索引种类之表簇索引(cluster index)

表簇索引(cluster index) 对于表簇索引而言,必须使用表簇. 由于簇索引与索引表簇关联紧密,无法单独拿出来总结,因此一并进行总结. 1.1 表簇的定义 表簇是一组通过相同公共列(簇键),构成的表的集合. 如上图,右侧独立的两张表,employees员工表与departments部门表,通过簇键department_id列,构成了左侧的一个表簇(cluster). 当构成表簇后,一个单独的数据块会包含多个表的数据行信息. 1.2 表簇的分类 对于oracle数据库,主要支持两种表簇:索

堆组织表,索引组织表和索引聚簇表

--- 堆组织表就不说了,其索引中记录了记录所在位置的rowid,查找的时候先找索引,然后再根据索引rowid找到块中的行数据 索引组织表,其行数据以索引形式存放,因此找到索引,就等于找到了行数据. -- 堆组织表的数据是散放的,索引和表的数据是分离的 索引组织表的索引和数据是在一起的 -- 堆组织表的存储速度因为不用考虑排序, 所以存储速度会比较快. 但是要查找符合某个条件的记录, 就必须得读取全部的记录以便筛选.而这个时候为了加快查询速度, 索引就出现了, 索引是针对少量特定字段的值拿出来进

ORACLE表、索引和分区

一.数据库表 每种类型的表都有不同的特性,分别应用与不同的领域 堆组织表 聚簇表(共三种) 索引组织表 嵌套表 临时表 外部表和对象表 1.行迁移 建表过程中可以指定以下两个参数:  PCTFREE:自由空间,默认值10 PCTUSED(只适用于MSSM):默认值40 设置这两个参数很重要:  一方面避免迁移过多的行,影响性能  一方面避免浪费太多的空间 当自由空间存不下更新后的某一行时,这一行将会发生行迁移,在两个块上存储这一行数据,如下图: 2.堆组织表 基本上我们使用的表都是堆组织表(he

[转帖]堆组织表,索引组织表和索引聚簇表

https://www.cnblogs.com/youngerger/p/8446399.html --- 堆组织表就不说了,其索引中记录了记录所在位置的rowid,查找的时候先找索引,然后再根据索引rowid找到块中的行数据 索引组织表,其行数据以索引形式存放,因此找到索引,就等于找到了行数据. -- 堆组织表的数据是散放的,索引和表的数据是分离的 索引组织表的索引和数据是在一起的 -- 堆组织表的存储速度因为不用考虑排序, 所以存储速度会比较快. 但是要查找符合某个条件的记录, 就必须得读取

Oracle表与索引的分析及索引重建

1.分析表与索引(analyze 不会重建索引) analyze table tablename compute statistics 等同于 analyze table tablename compute statistics for table for all indexes for all columns for table 的统计信息存在于视图:user_tables .all_tables.dba_tables for all indexes 的统计信息存在于视图: user_inde

Sybase数据库收集表及其索引的统计信息

更新表及其索引的统计信息: update table statistics 表名 go update index statistics 表名 go 建议此操作在闲时操作.

让你提前知道软件开发(27):创建数据库表和索引

文章2部分 数据库SQL语言 数据库表及索引的创建         数据表(或称表),是数据库最重要的组成部分之中的一个.数据库仅仅是一个框架.数据表才是事实上质的内容.举个样例来说,数据库就像是一座空旷的房子.而数据表是里面的家具,没有家具的房子仅仅是一个空壳而已.依据信息的分类情况,一个数据库中可能包括若干个不同用途的数据表. 表结构有简单.有复杂,这就对开发者提出了要求. 怎样设计一个表的字段才是最好的?表的字段怎样命名?怎样定义表字段的类型?怎样建立索引?等等. 1. 改动之前的建表脚本