数据库响应慢问题处理

最新推荐文章于 2024-08-02 09:27:18 发布
最新推荐文章于 2024-08-02 09:27:18 发布
阅读量745 收藏
点赞数
文章标签： 数据库 开发工具 操作系统

1. 客户环境

操作系统：HP

数据库版本：Oracle Database 10.2.0.5

2. 问题描述

用户数据库系统2015年3月19日1点到2015年3月19日1点22分，数据库响应非常缓慢。

3. 数据库检查

3.1 查询1点至2点每分钟的数据库事物数量


点击(此处)折叠或打开

  1. select to_char(SAMPLE_TIME, 'yyyy-mm-dd hh24:mi'), count(*)
  2.   from dba_hist_active_sess_history
  3.  where snap_id >= 34592
  4.    and snap_id <= 34593
  5.  group by to_char(SAMPLE_TIME, 'yyyy-mm-dd hh24:mi')
  6.  order by 1;

  8. 2015-03-18 23:59    7
  9. 2015-03-19 00:00    72
  10. 2015-03-19 00:01    161
  11. 2015-03-19 00:02    79
  12. 2015-03-19 00:03    78
  13. 2015-03-19 00:04    79
  14. 2015-03-19 00:05    105
  15. 2015-03-19 00:06    69
  16. 2015-03-19 00:07    74
  17. 2015-03-19 00:08    71
  18. 2015-03-19 00:09    75
  19. 2015-03-19 00:10    81
  20. 2015-03-19 00:11    158
  21. 2015-03-19 00:12    87
  22. 2015-03-19 00:13    69
  23. 2015-03-19 00:14    61
  24. 2015-03-19 00:15    64
  25. 2015-03-19 00:16    77
  26. 2015-03-19 00:17    67
  27. 2015-03-19 00:18    74
  28. 2015-03-19 00:19    90
  29. 2015-03-19 00:20    84
  30. 2015-03-19 00:21    106
  31. 2015-03-19 00:22    84
  32. 2015-03-19 00:23    79
  33. 2015-03-19 00:24    71
  34. 2015-03-19 00:25    120
  35. 2015-03-19 00:26    68
  36. 2015-03-19 00:27    96
  37. 2015-03-19 00:28    71
  38. 2015-03-19 00:29    67
  39. 2015-03-19 00:30    77
  40. 2015-03-19 00:31    75
  41. 2015-03-19 00:32    53
  42. 2015-03-19 00:33    72
  43. 2015-03-19 00:34    69
  44. 2015-03-19 00:35    88
  45. 2015-03-19 00:36    86
  46. 2015-03-19 00:37    98
  47. 2015-03-19 00:38    76
  48. 2015-03-19 00:39    83
  49. 2015-03-19 00:40    82
  50. 2015-03-19 00:41    108
  51. 2015-03-19 00:42    59
  52. 2015-03-19 00:43    65
  53. 2015-03-19 00:44    63
  54. 2015-03-19 00:45    49
  55. 2015-03-19 00:46    56
  56. 2015-03-19 00:47    114
  57. 2015-03-19 00:48    71
  58. 2015-03-19 00:49    89
  59. 2015-03-19 00:50    97
  60. 2015-03-19 00:51    55
  61. 2015-03-19 00:52    76
  62. 2015-03-19 00:53    80
  63. 2015-03-19 00:54    66
  64. 2015-03-19 00:55    89
  65. 2015-03-19 00:56    106
  66. 2015-03-19 00:57    75
  67. 2015-03-19 00:58    101
  68. 2015-03-19 00:59    99
  69. 2015-03-19 01:00    313
  70. 2015-03-19 01:01    296
  71. 2015-03-19 01:02    381
  72. 2015-03-19 01:03    496
  73. 2015-03-19 01:04    713
  74. 2015-03-19 01:05    929
  75. 2015-03-19 01:06    1074
  76. 2015-03-19 01:07    1146
  77. 2015-03-19 01:08    1317
  78. 2015-03-19 01:09    1399
  79. 2015-03-19 01:10    1649
  80. 2015-03-19 01:11    1827
  81. 2015-03-19 01:12    2031
  82. 2015-03-19 01:13    2133
  83. 2015-03-19 01:14    2281
  84. 2015-03-19 01:15    2421
  85. 2015-03-19 01:16    2117
  86. 2015-03-19 01:17    2637
  87. 2015-03-19 01:18    2880
  88. 2015-03-19 01:19    3072
  89. 2015-03-19 01:20    3203
  90. 2015-03-19 01:21    3319
  91. 2015-03-19 01:22    1746
  92. 2015-03-19 01:23    140
  93. 2015-03-19 01:24    170
  94. 2015-03-19 01:25    122
  95. 2015-03-19 01:26    97
  96. 2015-03-19 01:27    104
  97. 2015-03-19 01:28    133
  98. 2015-03-19 01:29    100
  99. 2015-03-19 01:30    119
  100. 2015-03-19 01:31    109
  101. 2015-03-19 01:32    93
  102. 2015-03-19 01:33    122
  103. 2015-03-19 01:34    95
  104. 2015-03-19 01:35    111
  105. 2015-03-19 01:36    96
  106. 2015-03-19 01:37    131
  107. 2015-03-19 01:38    261
  108. 2015-03-19 01:39    302
  109. 2015-03-19 01:40    293
  110. 2015-03-19 01:41    182
  111. 2015-03-19 01:42    101
  112. 2015-03-19 01:43    100
  113. 2015-03-19 01:44    105
  114. 2015-03-19 01:45    327
  115. 2015-03-19 01:46    108
  116. 2015-03-19 01:47    111
  117. 2015-03-19 01:48    104
  118. 2015-03-19 01:49    118
  119. 2015-03-19 01:50    118
  120. 2015-03-19 01:51    86
  121. 2015-03-19 01:52    119
  122. 2015-03-19 01:53    102
  123. 2015-03-19 01:54    119
  124. 2015-03-19 01:55    88
  125. 2015-03-19 01:56    109
  126. 2015-03-19 01:57    87
  127. 2015-03-19 01:58    80
  128. 2015-03-19 01:59    73

分析： 2015-03-19 01:00  至 2015-03-19 01:22 发生等待次数较多SQL_ID


3.2 进一步分析1点至1点22分等待事件


点击(此处)折叠或打开

  1. select * from (select sql_id,event, count(*) cnt
  2.   from dba_hist_active_sess_history
  3.  where snap_id >= 34592
  4.    and snap_id <= 34593
  5.    and to_char(SAMPLE_TIME, 'yyyy-mm-dd hh24:mi')>'2015-03-19 01:00'
  6.    and to_char(SAMPLE_TIME, 'yyyy-mm-dd hh24:mi')<'2015-03-19 01:22'
  7.  group by sql_id,event
  8.  order by 3 desc) where rownum<30;
  9.  
  10. SQL_ID EVENT CNT
  11. ------------- ---------------------------------------------------------------- ----------
  12. 0ggty2d2d96qn enq: TX - row lock contention 14319
  13. fkjwrr2ax004g latch: cache buffers chains 8851
  14. fkjwrr2ax004g gc buffer busy 7076
  15. fkjwrr2ax004g wait list latch free 735
  16. fkjwrr2ax004g latch: row cache objects 587
  17. fkjwrr2ax004g 224
  18.               log file sync 210
  19.               Backup: sbtwrite2 167
  20.                                                                                       123
  21. 7g3xvq43j0rns 86
  22.               log file parallel write 72
  23. 79t4hx5nx9bu6 db file sequential read 68
  24. grwfx6xbcnh39 55
  25.               SQL*Net message from dblink 42
  26. 520mkxqpf15q8 38
  27. 1u209u2t2d7fd db file scattered read 36
  28. 7xbdhjbn3x96q 35
  29. d7g1p6925bps5 db file scattered read 30
  30. 2m7w0gv9v0hpb 28
  31. fkjwrr2ax004g buffer busy waits 27
  32. 55hk4qa068nku 24
  33. 1t5mrg4njz5jj 23
  34.               cursor: pin S 20
  35. 520mkxqpf15q8 cursor: pin S 14
  36. bqju3yc59quzb 14
  37. fkjwrr2ax004g gc current block 2-way 14
  38. 1nwwqwc0qay94 enq: TX - row lock contention 14
  39. 3j66afaz3n3s9 gc current block 2-way 14
  40. dgkwa1zp9fxwk SQL*Net message from dblink 13

分析： 等待事件较高sql为0ggty2d2d96qn(select for update)/ fkjwrr2ax004g(insert into porthistory)

3.3  进一步分析awr报告



点击(此处)折叠或打开

  1. Sql_id 79t4hx5nx9bu6
  2. DELETE FROM PORTHISTORY WHERE TIMEKEY < TO_CHAR(TRUNC(SYSDATE) - 120, 'YYYYMMDDHH24MISS')

分析： 单次执行时间1307.13秒，接近22分钟

3.4 抓取执行计划分析


点击(此处)折叠或打开

  1. SQL> select * from table(dbms_xplan.display_awr('79t4hx5nx9bu6'));
  2.                                                                                                                                      
  3. PLAN_TABLE_OUTPUT
  4. --------------------------------------------------------------------------------------------
  5. SQL_ID 79t4hx5nx9bu6
  6. --------------------
  7. DELETE FROM PORTHISTORY WHERE TIMEKEY < TO_CHAR(TRUNC(SYSDATE) - 120,
  8. 'YYYYMMDDHH24MISS')
  9.                                                                                                                                  
  10. Plan hash value: 1650323717                                                                                                          
  11. ---------------------------------------------------------------------------------
  12. | Id |        Operation |           Name | Rows | Bytes | Cost (%CPU)|     Time |
  13. ---------------------------------------------------------------------------------
  14. |  0 | DELETE STATEMENT |                |      |       | 85528 (100)|          |
  15. |  1 |  DELETE          |    PORTHISTORY |      |       |            |          |
  16. |  2 |   INDEX SKIP SCAN| PORTHISTORY_PK | 426K |   13M |   85528 (1)| 00:17:07 |
  17. ---------------------------------------------------------------------------------
  18.                                                                                                                                    
  19. SQL_ID 79t4hx5nx9bu6
  20. --------------------
  21. DELETE FROM PORTHISTORY WHERE TIMEKEY < TO_CHAR(TRUNC(SYSDATE) - 120,
  22. 'YYYYMMDDHH24MISS')
  23.                                                                                                                                     
  24. Plan hash value: 3989602834
  25.                                                                                                                                      
  26. ----------------------------------------------------------------------------------
  27. | Id |         Operation |           Name | Rows | Bytes | Cost (%CPU)|     Time |
  28. ----------------------------------------------------------------------------------
  29. |  0 | DELETE STATEMENT  |                |      |       | 49551 (100)|          |
  30. |  1 |  DELETE           |    PORTHISTORY |      |       |            |          |
  31. |  2 |   INDEX FULL SCAN | PORTHISTORY_PK | 568K |   17M |   49551 (1)| 00:09:55 |
  32. ----------------------------------------------------------------------------------
  33.                                                                                                                                
  34. 30 rows selected.

分析： 有多个版本执行计划

3.5 查看sql执行计划版本变化时间


点击(此处)折叠或打开

  1. select sql_id,plan_hash_value,to_char(timestamp,\'yyyy-mm-dd hh24:mi:ss\') from dba_hist_sql_plan where sql_id=\'79t4hx5nx9bu6\'
  2.  
  3.      79t4hx5nx9bu6    1650323717    2015-02-14 17:38:45
  4.      79t4hx5nx9bu6    1650323717    2015-02-14 17:38:45
  5.      79t4hx5nx9bu6    1650323717    2015-02-14 17:38:45
  6.      79t4hx5nx9bu6    3989602834    2015-02-15 16:39:31
  7.      79t4hx5nx9bu6    3989602834    2015-02-15 16:39:31
  8.      79t4hx5nx9bu6    3989602834    2015-02-15 16:39:31

分析： sql执行计划最新版本为3989602834

4. 操作过程

4.1分析所用到索引


点击(此处)折叠或打开

  1. SQL> analyze index fabadm.porthistory_pk validate structure;

  3. Index analyzed.

  5. SQL> select t.name,
  6.   2 t.lf_rows, --number of leaf rows (values in the index)
  7.   3 t.lf_blks,
  8.   4 t.del_lf_rows, --number of deleted leaf rows in the index
  9.   5 (t.del_lf_rows / t.lf_rows)*100 ratio
  10.   6 from index_stats t
  11.   7 where t.name=\'PORTHISTORY_PK\';

  13. NAME LF_ROWS LF_BLKS DEL_LF_ROWS RATIO
  14. ------------------------------ ---------- ---------- ----------- ----------
  15. PORTHISTORY_PK 18031455 251171 51533 .285795018

分析： 索引不存在碎片化

4.1 重新收集统计信息，保证执行计划准确性

点击(此处)折叠或打开

  1. BEGIN
  2.   DBMS_STATS.GATHER_TABLE_STATS(ownname => 'FABADM',
  3.                                 tabname => 'PORTHISTORY',
  4.                                 estimate_percent => 60,
  5.                                 method_opt => 'for all columns size repeat',
  6.                                 no_invalidate => FALSE,
  7.                                 degree => 4,
  8.                                 granularity => 'ALL',
  9.                                 cascade => TRUE);
  10. END;
  11. /

5. 总结

1.  分析
1点至2点每分钟的等待事件，主要在01:00  至  01:22  产生大量等待

2     2、进一步分析，查询1点至1点22产生等待sql_id为0ggty2d2d96qn/ fkjwrr2ax004g

3、了解业务进一步分析，首先select for update锁定数据,inert 到porthistory并成功提交后释放锁

4.    综合awr分析可能由于delete删除造成此次响应较慢问题, SQL_ID: 79t4hx5nx9bu6 DELETE FROM PORTHISTORY WHERE TIMEKEY < TO_CHAR(TRUNC(SYSDATE) - 120,'YYYYMMDDHH24MISS')，执行时间为1307秒,正好接近22分钟,也就是业务缓慢时间段

已经对表收集统计信息，并把索引rebuild








来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/29990276/viewspace-1471380/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/29990276/viewspace-1471380/

cmbpr28628
关注
记一次Django响应超慢的解决过程
09-24
总结来说，当遇到Django应用响应慢的问题时，应从多方面进行排查，包括但不限于Python环境、数据库连接、中间件、性能监控以及网络通信。通过深入分析和调试，最终可以找到问题的症结，并采取相应的优化措施。在本...
如何能提高数据库的性能和响应速度
yu15338397549的博客
02-21 414
MYSQL语句的优化办法
oracle单表数据量不大，但是查询很慢
weixin_42801059的博客
05-06 2516
oracle单表数据量不大，但查询很慢
MySQL 过慢的 3 种解决方案
最新发布
乌南竹的博客
08-02 891
MySQL 是一个强大的数据库管理系统，但在某些情况下，性能问题可能会导致查询和操作变得缓慢。
【Oracle】数据库执行慢问题排查
热门推荐
Kida 的技术小屋（CSDN 版）
10-13 1万+
一次Oracle的执行慢排查记录，本记录记录提到的解法仅代表个人的处理思路，旨在将经验分享给各位，与君互勉
oracle查询慢的原因
Borths的专栏
06-29 2918
1.查看后台是否有锁： SELECT sq.INST_ID, SQ.SQL_TEXT, /*SQL文本*/ SE.SID, /*会话的唯一标识，通常要对某个会话进行分析前，首先就需要获得该会话的SID。*/ SE.BLOCKING_SESSION, SQ.OPTIMIZER_COST AS COST_, /* COST值*/ SE.LAST_CALL_ET CONTINUE_TIME, /*执行时间*/ ...
oracle数据库查询慢sql profile解决
lmxx2020的博客
01-30 921
该问题，主要是查询的sql未按正常的执行计划查询，查询超级慢，导致应用一直卡在那边。对“union all”的子查询挨个查了一遍，发现第一个和第二个子查询不能出结果，通过整个试图查看发现“TJ_TIJIANDZHXM”表是全表扫描，该表有700多万数据。后台不能跟踪出执行计划，检查发现“MZ_SHOURU_RB_CB”是个同义词，最终是个由多个试图查询做“union all”连接，查询数据库内的几个试图，都能很快出来。应用某个功能模块访问数据库卡住没反应，这个模块以前也慢，但都能正常访问，现在查询出不来。
数据库慢与卡解决思路
02-07
然而，在实际应用过程中，经常会遇到数据库响应缓慢或卡顿的问题，这不仅会影响用户体验，还可能对业务连续性和系统稳定性造成威胁。因此，本文将集中阐述数据库业务运行相关的慢与卡问题的解决思路，旨在从全局角度...
如何判断数据库IO是否慢
11-19
本月远程支持的一个项目中出现了数据库响应缓慢的问题，最终发现这是由于操作系统层面的IO性能不佳所致。为了确保解释充分、具有说服力，本文将深入探讨如何利用Oracle自带的工具来判断数据库IO是否过慢，从而为后续...
8大数据库性能优化方案，YYDS！
石杉的架构笔记
04-14 2215
文章来源：https://c1n.cn/dLkfg目录前言为什么数据库会慢？应该站在哪个层面思考优化？八大方案总结结束前言毫不夸张的说咱们后端工程师，无论在哪家公司，呆在哪个团队，做哪个系统，遇到的第一个让人头疼的问题绝对是数据库性能问题。如果我们有一套成熟的方法论，能让大家快速、准确的去选择出合适的优化方案，我相信能够快速准备解决咱么日常遇到的 80% 甚至 90% 的...
提高ORACLE数据库的查询统计速度
10-17
提高ORACLE数据库的查询统计速度,非常实用
Mysql第三篇---响应太慢？数据库卡顿？如何优化？
xzy的博客
10-23 3197
一条SQL查询语句在执行前需要确定查询执行计划，如果存在多种执行计划的话，MySQL会计算每个执行计划所需要的成本，从中选择成本最小的一个作为最终执行的执行计划。如果想要查看某条SQL语句的查询成本，可以在执行完这条SQL语句之后，通过查看当前会话中的last_query_cost变量值来得到当前查询的成本。它通常也是评价一个查询的执行效率的一个常用指标。这个查询成本对应的是SQL语句所需要读取的页的数量。然后我们使用存储过程往表里面存储100多万条数据；
Oracle-数据库性能变慢问题分析
sinat_36757755的博客
01-14 3936
应用运维报障说最近两天业务数据入库和表查询都变得很慢，需要排查一下数据库的性能问题
oracle sysdate方法列表
enthan809882的博客
01-16 307
SYSDATE 2018/2/8 14:38:52   TRUNC(SYSDATE) 2018/2/8   TO_CHAR(SYSDATE,'YYYYMMDD') 20180208 到日 TO_CHAR(SYSDATE,'YYYYMMDD HH24:MI:SS') 20180208 14:42:18 到秒 TO_CHAR(SYSTIMESTAMP,'Y...
解决数据库慢的方法论
DoubleJing的博客
04-05 2990
数据库慢一般有三种情况： 1.逐渐变慢 2.然变慢 3.不定时变慢 第一种情况 “逐渐变慢”，要建立一个长期的监控机制。比如，写脚本每天的忙时定时收集os,network,database的信息， 每个星期出report,对收集到的信息进行分析。 这些数据的积累，可以决定后期的优化决策，并且可以是DBA说服MANAGER采用自己决策的重要数据。DBA的价值，就在每个星期的report中体现。 第二...
【SQL SERVER】 处理百万级以上的数据提高查询速度的方法
07-08 444
1.应尽量避免在 where 子句中使用!=或<>操作符，否则将引擎放弃使用索引而进行全表扫描。 2.对查询进行优化，应尽量避免全表扫描，首先应考虑在 where 及 order by 涉及的列上建立索引。 3.应尽量避免在 where 子句中对字段进行 null 值判断，否则将导...
oracle 数据库响应慢,数据库响应慢问题处理
weixin_34281191的博客
04-03 979
select * from (select sql_id,event, count(*) cntfrom dba_hist_active_sess_historywhere snap_id >= 34592and snap_id <= 34593and to_char(SAMPLE_TIME, 'yyyy-mm-dd hh24:mi')>'2015-03-19 01:00'and...
优化Navicat：解决远程数据库表响应慢问题
"本文主要介绍如何解决Navicat在打开数据库表时响应速度慢的问题，问题源于MySQL服务器对长时间不活动的连接进行清理，而Navicat的默认保持连接间隔设置可能导致连接超时，从而造成访问延迟。解决方案在于调整...
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值