rac系统某时段操作极慢或无法登陆问题

leonhat

提供系统awr报告如下（都选择的第一个节点）：

上午集中操作时间段：10点-11点的awr：
am_10_11.html (767.96 KB, 下载次数: 784)

2013-1-28 09:52 上传

点击文件名下载附件
上午10点到11点

下午集中操作时间段：15点-17点的awr：
pm_15_17.html (763.35 KB, 下载次数: 763)

2013-1-28 09:53 上传

点击文件名下载附件
下午15点到17点

中午空闲时间段（参考空闲时期）：12点-13点的awr：
m_12_13.html (699.86 KB, 下载次数: 694)

2013-1-28 09:52 上传

点击文件名下载附件
中午空闲时间

描述：
系统为双节点rac，FC连接存储，ASM方式。
在上下午两个集中操作时间的并发量峰值在2000左右，此时系统登录很慢或登录不上，操作也很慢。

请帮助分析原因，谢谢。

yehc@epsoft.com

建议做个时间段内的ASH(Active Session History）和ADDM快照，看看哪些块争用较高。
AWR中TOP 5显示“db file sequential read” 较高。

1. SQL> @?/rdbms/admin/ashrpt.sql

复制代码

1. SQL> @?/rdbms/admin/addmrpt.sql

复制代码

leonhat

告警日志：
alert_zxdb1.txt (685.9 KB, 下载次数: 762)

2013-1-28 10:24 上传

点击文件名下载附件
告警

leonhat

当前性能报告如下：
ashrpt_1_0128_1054.html (51.66 KB, 下载次数: 692)

2013-1-28 11:24 上传

点击文件名下载附件
当前性能

调整参考报告如下：
addmrpt_1_2391_2392.txt (21.54 KB, 下载次数: 847)

2013-1-28 11:24 上传

点击文件名下载附件
参考

leonhat

yehc@epsoft.com 发表于 2013-1-28 10:15
建议做个时间段内的ASH(Active Session History）和ADDM快照，看看哪些块争用较高。
AWR中TOP 5显示“db fi ...

两个报告已上传。

yehc@epsoft.com

leonhat 发表于 2013-1-28 11:25
当前性能报告如下：

就ADDM快照来看，业务高峰期，目前的I/O能力并不太能满足业务的需求，集中表现在DATA Diskgroup所在的磁盘请求都表现出较高的I/O 等待。单从这点看，可以考虑重点检查存储/阵列是否正常工作，或者说有没有故障情况。

ASH中对于db file sequential read 主要集中在10号文件 282950号块，可以参考如下sql 检查对象,

1. SQL> Select tablespace_name,segment_type,owner,segment_name
   
2. From dba_extents Where file_id=10 and  282950 between block_id and block_id+blocks-1;

复制代码

Maclean Liu(刘相兵

应用的特点似乎似乎 夜间凌晨数据加载，之后白天主要是查询操作

白天问题时段的特征是 物理读较多， 而且Io响应慢

Physical reads:         20,873.1         397.3                  
Physical reads:         14,823.6         362.9                  

物理读分别为 163MB/s ~ 115MB/s

Logons:         0.7         0.0                  实际每秒的logon不多， 排除logon storm的可能

Wait Class        Waits        %Time -outs        Total Wait Time (s)        Avg wait (ms)        %DB time
User I/O        2,530,285        0        43,262        17        88.78
DB CPU                          2,471                 5.07
Commit        51,577        0        1,736        34        3.56
Cluster        515,190        0        708        1        1.45

User I/O平均等待17ms，commit 34ms


一小时的快照中Direct Reads达到 553G，比Buffer cache read高很多
另一个快照中787G

Function/File Name	Reads: Data	Reqs per sec	Data per sec	Writes: Data	Reqs per sec	Data per sec	Waits: Count	Avg Tm(ms)
Direct Reads	553G	159.90	156.302	0M	0.00	0M	0
Direct Reads (Data File)	553G	159.90	156.302	0M	0.00	0M	0
Buffer Cache Reads	24.1G	648.93	6.81942	0M	0.00	0M	1966.6K	17.85
Buffer Cache Reads (Data File)	24.1G	648.93	6.81942	0M	0.00	0M	1966.6K	17.85
DBWR	0M	0.00	0M	225M	6.64	.062100	0
DBWR (Data File)	0M	0.00	0M	225M	6.64	.062100	0
Others	148M	2.62	.040848	25M	0.43	.006900	9480	29.63
Others (Control File)	148M	2.60	.040848	24M	0.43	.006624	9429	29.76
Others (Data File)	0M	0.01	0M	1M	0.00	.000276	51	5.39
LGWR	0M	0.00	0M	76M	14.23	.020976	0
LGWR (Log File)	0M	0.00	0M	76M	14.23	.020976	0
Direct Writes	0M	0.00	0M	1M	0.00	.000276	0
Direct Writes (Data File)	0M	0.00	0M	1M	0.00	.000276	0
TOTAL:	577.3G	811.45	163.162	327M	21.29	.090252	1976.1K	17.90

Function/File Name	Reads: Data	Reqs per sec	Data per sec	Writes: Data	Reqs per sec	Data per sec	Waits: Count	Avg Tm(ms)
Direct Reads	787G	114.81	111.949	0M	0.00	0M	0
Direct Reads (Data File)	787G	114.81	111.949	0M	0.00	0M	0
Buffer Cache Reads	27.1G	349.55	3.85717	0M	0.00	0M	2147.3K	6.57
Buffer Cache Reads (Data File)	27.1G	349.55	3.85717	0M	0.00	0M	2147.3K	6.57
Others	294M	2.61	.040838	48M	0.42	.006667	18.8K	7.36
Others (Control File)	293M	2.61	.040699	47M	0.42	.006528	18.8K	7.35
Others (Data File)	1M	0.01	.000138	1M	0.01	.000138	69	8.86
DBWR	0M	0.00	0M	330M	4.75	.045839	0
DBWR (Data File)	0M	0.00	0M	330M	4.75	.045839	0
LGWR	0M	0.00	0M	116M	11.27	.016113	0
LGWR (Log File)	0M	0.00	0M	116M	11.27	.016113	0
Direct Writes	0M	0.00	0M	1M	0.00	.000138	0
Direct Writes (Data File)	0M	0.00	0M	1M	0.00	.000138	0
Streams AQ	0M	0.00	0M	0M	0.00	0M	6	4.83
Streams AQ (Data File)	0M	0.00	0M	0M	0.00	0M	6	4.83
TOTAL:	814.4G	466.98	115.847	495M	16.45	.068759	2166.1K	6.57

Maclean Liu(刘相兵

table scans (long tables)        14,010        1.95        0.05
table scans (direct read)        13,941        1.94        0.05
table scans (long tables)较多说明存在较多的 全表扫描， 而且这些全表扫描都使用11g automatic direct read

关于11g automatic direct read  详见 http://www.askmaclean.com/archiv ... al_direct_read.html


建议：

1.优化SQL减少全表扫描的频率

2. 设置10949 event 避免direct serial read ，具体方法见http://www.askmaclean.com/archiv ... al_direct_read.html

leonhat

老大，我做了以下操作，查询速度提高了：

1、将case_infor表分区了，3500个，在另一个贴中
http://t.askmaclean.com/thread-2001-1-1.html

2、将原来sga_target=3546M改成8G


问题解决。。

lunar

虽然，你问题解决了，但是ML分析的好，细路清晰