惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

Help Net Security
Help Net Security
G
Google Developers Blog
雷峰网
雷峰网
WordPress大学
WordPress大学
Threat Intelligence Blog | Flashpoint
Threat Intelligence Blog | Flashpoint
Engineering at Meta
Engineering at Meta
Security Latest
Security Latest
T
Threat Research - Cisco Blogs
AWS News Blog
AWS News Blog
F
Full Disclosure
C
Cybersecurity and Infrastructure Security Agency CISA
T
The Exploit Database - CXSecurity.com
J
Java Code Geeks
U
Unit 42
C
Cyber Attacks, Cyber Crime and Cyber Security
V
V2EX
C
Cisco Blogs
博客园 - 司徒正美
Project Zero
Project Zero
L
LINUX DO - 热门话题
阮一峰的网络日志
阮一峰的网络日志
Blog — PlanetScale
Blog — PlanetScale
Scott Helme
Scott Helme
A
About on SuperTechFans
Hugging Face - Blog
Hugging Face - Blog
S
Securelist
小众软件
小众软件
aimingoo的专栏
aimingoo的专栏
S
Schneier on Security
G
GRAHAM CLULEY
酷 壳 – CoolShell
酷 壳 – CoolShell
Cyberwarzone
Cyberwarzone
MongoDB | Blog
MongoDB | Blog
钛媒体:引领未来商业与生活新知
钛媒体:引领未来商业与生活新知
博客园 - 叶小钗
T
Threatpost
Recorded Future
Recorded Future
C
CXSECURITY Database RSS Feed - CXSecurity.com
宝玉的分享
宝玉的分享
N
News and Events Feed by Topic
人人都是产品经理
人人都是产品经理
The Register - Security
The Register - Security
S
Security Archives - TechRepublic
博客园 - Franky
N
News | PayPal Newsroom
Simon Willison's Weblog
Simon Willison's Weblog
S
SegmentFault 最新的问题
W
WeLiveSecurity
A
Arctic Wolf
B
Blog

博客园 - 一江水

什么时候使用绑定变量性能反而更差 模拟登录新浪微博(Python) Oracle ASM 详解 Oracle OS Block Header 物化视图日志没有清除 Oracle如何根据物化视图日志快速刷新物化视图 物化视图注册信息的清除 Oracle RAC 常用维护工具和命令 - 一江水 RAC Debug开关修改工具 Java连接Sybase ASE数据库的一个简单例子 中文图解Python脚本 解决sybase中文以及大小写问题(服务器端)(utf8 乱码) 如何使Sybase ASE中对象名不区分大小写? 使用 Oracle 数据库 10g内部的 ETL 基础架构 Oracle代理用户(Proxy User) Android系统手机端抓包方法 RAC中如何更改对外网卡和内部互联网卡的IP及VIP ORA-12545: 因目标主机或对象不存在, 连接失败 Oracle数据块损坏恢复总结[转]
Oracle RAC 碰到 gc buffer busy
一江水 · 2012-11-16 · via 博客园 - 一江水

数据库版本:Oracle 10.2.0.5-64
节点数:2
操作系统版本:centos 5.6 -64

今天做awr报告发现gc buffer busy等待时间

gc buffer busy
  This wait event, also known as global cache buffer busy prior to Oracle 10g, specifies the time the remote instance locally spends accessing the requested data block. This wait event is very similar to the buffer busy waits wait event in asingle-instance database and are often the result of:

1. Hot Blocks - multiple sessions may be requesting a block that is either not in buffer cache or is in an incompatible mode. Deleting some of the hot rows and re-inserting them back into the table may alleviate the problem. Most of the time the rows will be placed into a different block and reduce contention on the block. The DBA may also need to adjust the pctfree and/or pctused parameters for the table to ensure the rows are placed into a different block.

2. Inefficient Queries ˆ as with the gc cr request wait event, the more blocks requested from the buffer cache the more likelihood of a session having to wait for other sessions.Tuning queries to access fewer blocks will often result in less contention for the same block.

第一点应该基本排除:我刚刚整理完表,我们首先找到造成次问题的sql
1、首先查看上次所有的等待事件种类

  1. SQL> select min(begin_interval_time) minmax(end_interval_time) max from dba_hist_snapshot where snap_id between 204 and 228;  
  2. SQL> select wait_class_id, wait_class, count(*) cnt  
  3. from dba_hist_active_sess_history  
  4. where snap_id between 204 and 228  
  5. group by wait_class_id, wait_class  
  6. order by 3;  
  7. 结果如下:  
  8. WAIT_CLASS_ID WAIT_CLASS                            CNT  
  9. ------------- ------------------------------ ----------   
  10.    4217450380 Application                             1  
  11.    1740759767 User I/O                                3  
  12.    2000153315 Network                                 7  
  13.    3875070507 Concurrency                             8  
  14.    3386400367 Commit                                 24  
  15.    4108307767 System I/O                             54  
  16.    1893977003 Other                                  66  
  17.    3871361733 Cluster                               104  
  18.                                                    3543  

2、查看上次所有的等待事件

  1. SQL> SELECT event_id, event, COUNT (*) cnt  
  2.     FROM dba_hist_active_sess_history  
  3.    WHERE snap_id BETWEEN 204 AND 228 AND wait_class_id = 3871361733  
  4. GROUP BY event_id, event  
  5. ORDER BY 3;  
  6. 结果如下:                                             
  7.   EVENT_ID EVENT                                 CNT  
  8. ---------- ------------------------------ ----------   
  9. 2277737081 gc current grant busy                   1  
  10.  512320954 gc cr request                           1  
  11. 3897775868 gc current multi block request          4  
  12.  737661873 gc cr block 2-way                       5  
  13.  111015833 gc current block 2-way                  6  
  14. 2701629120 gc current block busy                   7  
  15. 1520064534 gc cr block busy                        9  
  16. 1478861578 gc buffer busy                         71  

3、查询造成等待事件的sql

  1. SQL> SELECT sql_id, COUNT (*) cnt  
  2.     FROM dba_hist_active_sess_history  
  3.    WHERE snap_id BETWEEN 204 AND 228 AND event_id IN (1520064534, 1478861578)  
  4. GROUP BY sql_id  
  5.   HAVING COUNT (*) > 1  
  6. ORDER BY 2;  
  7. 结果如下:  
  8. SQL_ID               CNT  
  9. ------------- ----------   
  10. fuzy096ka7sca          2  
  11. 9mdnmqu9vhht6          4  
  12. btb1g900q18u3          5  
  13. 1y4rsrmg1m8u9          5  
  14. g42h7cxm2jsmb          8  
  15. 8knuwvx47gdsz         16  
  16. bp92nqubvbpdq         40  

4、查询具体的sql

  1. SELECT *  
  2.   FROM dba_hist_sqltext d  
  3.  WHERE sql_id IN  
  4.           ('bp92nqubvbpdq',  
  5.            '8knuwvx47gdsz',  
  6.            'g42h7cxm2jsmb',  
  7.            '1y4rsrmg1m8u9',  
  8.            'btb1g900q18u3',  
  9.            '9mdnmqu9vhht6',  
  10.            'fuzy096ka7sca');  

最后看到,主要是因为一个插入的sql产生的原因,下面就是和开发商量怎么解决这个问题了。