17,377
社区成员
发帖
与我相关
我的任务
分享在线等，ORACLE运行一段时间以后变慢
各位高手，最近公司上了一套系统，数据库用ORACLE，环境如下：
XEON 8CPU
64G RAM
800G SSD
ORACLE启动后，资源占用如下：
top - 16:29:49 up 1:16, 2 users, load average: 0.00, 0.00, 0.00
Tasks: 315 total, 1 running, 314 sleeping, 0 stopped, 0 zombie
Cpu(s): 0.4%us, 0.0%sy, 0.0%ni, 99.6%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
Mem: 66109924k total, 65744392k used, 365532k free, 5048k buffers
Swap: 33554428k total, 3168016k used, 30386412k free, 1988304k cached
数据库里面几个数据库在运行，数据记录不算大，最大的表也不过1000万，把所有的连接都断开以后，执行一下SELECT COUNT(1) FROM TABLE大概需要1.67s，数据记录66W+条，如果把所有的都列出来，是个无尽的等待，请问有该如果查起，在线等，小弟感激不尽！
XEON 8CPU
64G RAM
800G SSD
ORACLE启动后，资源占用如下：
top - 16:29:49 up 1:16, 2 users, load average: 0.00, 0.00, 0.00
Tasks: 315 total, 1 running, 314 sleeping, 0 stopped, 0 zombie
Cpu(s): 0.4%us, 0.0%sy, 0.0%ni, 99.6%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
Mem: 66109924k total, 65744392k used, 365532k free, 5048k buffers
Swap: 33554428k total, 3168016k used, 30386412k free, 1988304k cached
数据库里面几个数据库在运行，数据记录不算大，最大的表也不过1000万，把所有的连接都断开以后，执行一下SELECT COUNT(1) FROM TABLE大概需要1.67s，数据记录66W+条，如果把所有的都列出来，是个无尽的等待，请问有该如果查起，在线等，小弟感激不尽！
...全文
请发表友善的回复…
发表回复
Walex 2018-04-20
- 打赏
- 举报
org.quartz.JobExecutionException: Could not write submit segment exec: ORA-01403: no data found
ORA-06512: at "RGZPRDM.UIQ_JOB_PKG", line 111
ORA-06512: at "RGZPRDM.UIQ_JOB_PKG", line 192
ORA-06512: at "RGZPRDM.UIQ_JOB_PKG", line 6046
ORA-06512: at line 1
[See nested exception: java.sql.SQLException: ORA-01403: no data found
ORA-06512: at "RGZPRDM.UIQ_JOB_PKG", line 111
ORA-06512: at "RGZPRDM.UIQ_JOB_PKG", line 192
ORA-06512: at "RGZPRDM.UIQ_JOB_PKG", line 6046
ORA-06512: at line 1
]
at com.ssn.job.SegmentJob.completeSegment(SegmentJob.java:305)
at com.ssn.job.types.helpers.AdvancedMeterReadExport.exportData(AdvancedMeterReadExport.java:278)
at com.ssn.job.types.segment.SegmentExportJob.executeAMRExport(SegmentExportJob.java:81)
at com.ssn.job.types.segment.SegmentExportJob.executeJobInternal(SegmentExportJob.java:47)
at com.ssn.job.types.segment.SegmentExportJob.executeJob(SegmentExportJob.java:33)
at com.ssn.job.SegmentJob.execute(SegmentJob.java:114)
at org.quartz.core.JobRunShell.run(JobRunShell.java:202)
at org.quartz.simpl.SimpleThreadPool$WorkerThread.run(SimpleThreadPool.java:529)
Caused by: java.sql.SQLException: ORA-01403: no data found
见到程序LOG里面抛出很多出错提示，还是数据库有问题
Walex 2018-04-20
- 打赏
- 举报
确认过了，是100
Walex 2018-04-19
- 打赏
- 举报
----------------------------------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Cost (%CPU)| Time | Pstart| Pstop |
----------------------------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | | 328 (100)| | | |
| 1 | SORT AGGREGATE | | 1 | | | | |
| 2 | PARTITION RANGE ALL | | 332K| 328 (1)| 00:00:01 | 1 | 5 |
| 3 | INDEX FAST FULL SCAN| UIQ_JOB_GROUP_MEMBER_ID | 332K| 328 (1)| 00:00:01 | 1 | 5 |
----------------------------------------------------------------------------------------------------------
刚执行完，今晚看看效果，先谢谢了！
另外，除了这个问题应该还有别的问题，发现ORACLE会偷停，已经发生过两次了，不知道有没有什么经验可以参考一下？[/quote]
这个可以看看alert日志，停掉的时候报啥错了之类的，是情况而定，大多是BUG之类导致的，通常生产库是需要打补丁的。[/quote]
效果出来了，执行24W条记录，3条语句中：
COUNT(*)效果有明显好转，大概第一次4秒左右，第二次2.9秒，
第二条查询执行计划ID第一次超过120秒，第二次41秒，以前大致是1秒内
第三条第一次3秒多，第二次0.4秒
感觉好像好了一个问题，新问题又来了
Walex 2018-04-19
- 打赏
- 举报
谢谢指点！
Walex 2018-04-19
- 打赏
- 举报
----------------------------------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Cost (%CPU)| Time | Pstart| Pstop |
----------------------------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | | 328 (100)| | | |
| 1 | SORT AGGREGATE | | 1 | | | | |
| 2 | PARTITION RANGE ALL | | 332K| 328 (1)| 00:00:01 | 1 | 5 |
| 3 | INDEX FAST FULL SCAN| UIQ_JOB_GROUP_MEMBER_ID | 332K| 328 (1)| 00:00:01 | 1 | 5 |
----------------------------------------------------------------------------------------------------------
刚执行完，今晚看看效果，先谢谢了！
另外，除了这个问题应该还有别的问题，发现ORACLE会偷停，已经发生过两次了，不知道有没有什么经验可以参考一下？[/quote]
这个可以看看alert日志，停掉的时候报啥错了之类的，是情况而定，大多是BUG之类导致的，通常生产库是需要打补丁的。[/quote]
效果出来了，执行24W条记录，3条语句中：
COUNT(*)效果有明显好转，大概第一次4秒左右，第二次2.9秒，
第二条查询执行计划ID第一次超过120秒，第二次41秒，以前大致是1秒内
第三条第一次3秒多，第二次0.4秒
感觉好像好了一个问题，新问题又来了[/quote]
没看懂你的回复，上面说count一张表60万+的，已经在秒级以下，这里count 20万+的为什么4秒都觉得是正常现象？[/quote]
上面66W的表，COUNT用时20.69秒，后来实在慢得没办法，我把表清空了，又产生了20W的数据，忙时COUNT用时4秒，闲时1.46秒，只是说感觉好一点，稳定一点了，但比起别的低配的MYSQL，还是不在一个数量级，不知道是它本身就是这样，还是需要优化？
minsic78 2018-04-19
- 打赏
- 举报
----------------------------------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Cost (%CPU)| Time | Pstart| Pstop |
----------------------------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | | 328 (100)| | | |
| 1 | SORT AGGREGATE | | 1 | | | | |
| 2 | PARTITION RANGE ALL | | 332K| 328 (1)| 00:00:01 | 1 | 5 |
| 3 | INDEX FAST FULL SCAN| UIQ_JOB_GROUP_MEMBER_ID | 332K| 328 (1)| 00:00:01 | 1 | 5 |
----------------------------------------------------------------------------------------------------------
刚执行完，今晚看看效果，先谢谢了！
另外，除了这个问题应该还有别的问题，发现ORACLE会偷停，已经发生过两次了，不知道有没有什么经验可以参考一下？[/quote]
这个可以看看alert日志，停掉的时候报啥错了之类的，是情况而定，大多是BUG之类导致的，通常生产库是需要打补丁的。[/quote]
效果出来了，执行24W条记录，3条语句中：
COUNT(*)效果有明显好转，大概第一次4秒左右，第二次2.9秒，
第二条查询执行计划ID第一次超过120秒，第二次41秒，以前大致是1秒内
第三条第一次3秒多，第二次0.4秒
感觉好像好了一个问题，新问题又来了[/quote]
没看懂你的回复，上面说count一张表60万+的，已经在秒级以下，这里count 20万+的为什么4秒都觉得是正常现象？
minsic78 2018-04-19
- 打赏
- 举报
确认下：
1、select name , value from v$parameter where name='optimizer_index_cost_adj';
2、拿出现在count时候的执行计划
Walex 2018-04-19
- 打赏
- 举报
----------------------------------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Cost (%CPU)| Time | Pstart| Pstop |
----------------------------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | | 328 (100)| | | |
| 1 | SORT AGGREGATE | | 1 | | | | |
| 2 | PARTITION RANGE ALL | | 332K| 328 (1)| 00:00:01 | 1 | 5 |
| 3 | INDEX FAST FULL SCAN| UIQ_JOB_GROUP_MEMBER_ID | 332K| 328 (1)| 00:00:01 | 1 | 5 |
----------------------------------------------------------------------------------------------------------
刚执行完，今晚看看效果，先谢谢了！
另外，除了这个问题应该还有别的问题，发现ORACLE会偷停，已经发生过两次了，不知道有没有什么经验可以参考一下？[/quote]
这个可以看看alert日志，停掉的时候报啥错了之类的，是情况而定，大多是BUG之类导致的，通常生产库是需要打补丁的。[/quote]
效果出来了，执行24W条记录，3条语句中：
COUNT(*)效果有明显好转，大概第一次4秒左右，第二次2.9秒，
第二条查询执行计划ID第一次超过120秒，第二次41秒，以前大致是1秒内
第三条第一次3秒多，第二次0.4秒
感觉好像好了一个问题，新问题又来了[/quote]
没看懂你的回复，上面说count一张表60万+的，已经在秒级以下，这里count 20万+的为什么4秒都觉得是正常现象？[/quote]
上面66W的表，COUNT用时20.69秒，后来实在慢得没办法，我把表清空了，又产生了20W的数据，忙时COUNT用时4秒，闲时1.46秒，只是说感觉好一点，稳定一点了，但比起别的低配的MYSQL，还是不在一个数量级，不知道是它本身就是这样，还是需要优化？[/quote]
你系统级的参数optimizer_index_cost_adj改到100了？[/quote]
是的，已经调到100了
minsic78 2018-04-19
- 打赏
- 举报
----------------------------------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Cost (%CPU)| Time | Pstart| Pstop |
----------------------------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | | 328 (100)| | | |
| 1 | SORT AGGREGATE | | 1 | | | | |
| 2 | PARTITION RANGE ALL | | 332K| 328 (1)| 00:00:01 | 1 | 5 |
| 3 | INDEX FAST FULL SCAN| UIQ_JOB_GROUP_MEMBER_ID | 332K| 328 (1)| 00:00:01 | 1 | 5 |
----------------------------------------------------------------------------------------------------------
刚执行完，今晚看看效果，先谢谢了！
另外，除了这个问题应该还有别的问题，发现ORACLE会偷停，已经发生过两次了，不知道有没有什么经验可以参考一下？[/quote]
这个可以看看alert日志，停掉的时候报啥错了之类的，是情况而定，大多是BUG之类导致的，通常生产库是需要打补丁的。[/quote]
效果出来了，执行24W条记录，3条语句中：
COUNT(*)效果有明显好转，大概第一次4秒左右，第二次2.9秒，
第二条查询执行计划ID第一次超过120秒，第二次41秒，以前大致是1秒内
第三条第一次3秒多，第二次0.4秒
感觉好像好了一个问题，新问题又来了[/quote]
没看懂你的回复，上面说count一张表60万+的，已经在秒级以下，这里count 20万+的为什么4秒都觉得是正常现象？[/quote]
上面66W的表，COUNT用时20.69秒，后来实在慢得没办法，我把表清空了，又产生了20W的数据，忙时COUNT用时4秒，闲时1.46秒，只是说感觉好一点，稳定一点了，但比起别的低配的MYSQL，还是不在一个数量级，不知道是它本身就是这样，还是需要优化？[/quote]
你系统级的参数optimizer_index_cost_adj改到100了？
Walex 2018-04-18
- 打赏
- 举报
----------------------------------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Cost (%CPU)| Time | Pstart| Pstop |
----------------------------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | | 328 (100)| | | |
| 1 | SORT AGGREGATE | | 1 | | | | |
| 2 | PARTITION RANGE ALL | | 332K| 328 (1)| 00:00:01 | 1 | 5 |
| 3 | INDEX FAST FULL SCAN| UIQ_JOB_GROUP_MEMBER_ID | 332K| 328 (1)| 00:00:01 | 1 | 5 |
----------------------------------------------------------------------------------------------------------
刚执行完，今晚看看效果，先谢谢了！
另外，除了这个问题应该还有别的问题，发现ORACLE会偷停，已经发生过两次了，不知道有没有什么经验可以参考一下？
sych888 2018-04-18
- 打赏
- 举报
正常的COUNT应该走快速索引扫描才对（多数表都有主键），因为统计不需要排序
minsic78 2018-04-18
- 打赏
- 举报
我都差点忘了当时让你查参数文件和执行计划的初衷。
你的实例参数里有个非常重要的CBO参数被修改了：*.optimizer_index_cost_adj=20，这个参数如此设置意味着CBO更容易去选择索引扫描，甚至在这个count的场景下选择了INDEX FULL SCAN，你把这个参数设置会原来的100就应该没问题了： alter system set optimizer_index_cost_adj=100;
minsic78 2018-04-18
- 打赏
- 举报
----------------------------------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Cost (%CPU)| Time | Pstart| Pstop |
----------------------------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | | 328 (100)| | | |
| 1 | SORT AGGREGATE | | 1 | | | | |
| 2 | PARTITION RANGE ALL | | 332K| 328 (1)| 00:00:01 | 1 | 5 |
| 3 | INDEX FAST FULL SCAN| UIQ_JOB_GROUP_MEMBER_ID | 332K| 328 (1)| 00:00:01 | 1 | 5 |
----------------------------------------------------------------------------------------------------------
刚执行完，今晚看看效果，先谢谢了！
另外，除了这个问题应该还有别的问题，发现ORACLE会偷停，已经发生过两次了，不知道有没有什么经验可以参考一下？[/quote]
这个可以看看alert日志，停掉的时候报啥错了之类的，是情况而定，大多是BUG之类导致的，通常生产库是需要打补丁的。
Walex 2018-04-17
- 打赏
- 举报
系统繁忙时的资源占用情况：
top - 23:34:56 up 21:45, 1 user, load average: 3.25, 2.28, 2.14
Tasks: 431 total, 1 running, 430 sleeping, 0 stopped, 0 zombie
Cpu(s): 0.7%us, 1.2%sy, 0.0%ni, 72.2%id, 25.9%wa, 0.0%hi, 0.0%si, 0.0%st
Mem: 66109924k total, 65715448k used, 394476k free, 3092k buffers
Swap: 33554428k total, 14622412k used, 18932016k free, 1333696k cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
125 root 20 0 0 0 0 D 9.0 0.0 27:44.70 kswapd0
14991 oracle 20 0 67.1g 387m 385m S 0.9 0.6 1:01.24 oracle_14991_or
3352 oracle -2 0 67.1g 784 668 S 0.6 0.0 7:55.83 ora_vktm_orcl
3368 oracle 20 0 67.1g 62m 47m S 0.6 0.1 6:12.82 ora_dia0_orcl
15806 oracle 20 0 67.1g 327m 325m S 0.6 0.5 0:37.32 oracle_15806_or
16938 oracle 20 0 67.1g 154m 153m S 0.6 0.2 0:07.65 oracle_16938_or
17634 romantic 20 0 17344 1468 892 R 0.6 0.0 0:00.07 top
85 root 20 0 0 0 0 S 0.3 0.0 0:02.42 kblockd/3
2242 root 20 0 507m 1380 892 S 0.3 0.0 0:29.96 ManagementAgent
3364 oracle 20 0 67.1g 52m 51m S 0.3 0.1 0:30.73 ora_dbrm_orcl
3374 oracle 20 0 67.1g 43m 43m S 0.3 0.1 0:27.58 ora_lgwr_orcl
3392 oracle 20 0 67.1g 125m 124m S 0.3 0.2 4:20.05 ora_mmnl_orcl
3462 oracle 20 0 67.1g 876 732 S 0.3 0.0 0:01.27 ora_p002_orcl
14453 oracle 20 0 67.1g 350m 345m S 0.3 0.5 0:38.32 oracle_14453_or
14459 oracle 20 0 67.1g 306m 301m S 0.3 0.5 0:37.25 oracle_14459_or
15163 oracle 20 0 67.1g 317m 312m S 0.3 0.5 0:25.24 oracle_15163_or
17275 oracle 20 0 67.1g 240m 236m S 0.3 0.4 0:04.43 oracle_17275_or
CPU很闲，同期22万条记录，select count(*) from uiq_job_group;需要41.37秒，这效率我也是醉了
minsic78 2018-04-17
- 打赏
- 举报
这个计划走的有点奇葩，先用提示看看走表扫描需要多长时间？
select /*+full(uiq_job_group)*/count(*) from uiq_job_group;[/quote]
上面有我的QQ，能不能加我QQ指导一下。
select count(*) from uiq_job_group;
第一次执行1秒以上，第二次0.5~0.05秒不等
select /*+full(uiq_job_group)*/count(*) from uiq_job_group;
第一次执行1.38秒，第二次0.06秒左右
select /*+index_ffs(uiq_job_group UIQ_JOB_GROUP_MEMBER_ID)*/count(*) from uiq_job_group;
第一次执行0.27秒，第二次0.04~0.07秒左右
[/quote]
这样的执行时间是正常的，第一次跑是因为多次执行后有缓存的关系，如果你找张更大点的表，会发现使用FULL提示，可能会每次执行都比较稳定，因为表大小大于一定程度，Oracle每次都会使用物理读来完成表扫描，该特性由隐藏参数_serial_direct_read控制。
不解的是：为什么CBO一开始选择了INDEX FULL SCAN这种奇葩的执行计划，在12c下，排除统计信息等环境问题，有什么参数会导致这样的问题？ @惜分飞
qq_35403043 2018-04-17
- 打赏
- 举报
麻烦检查下服务器cpu使用率，当前数据库连接的会话数是不是资源消耗完了？
minsic78 2018-04-16
- 打赏
- 举报
另外还有走INDEX FAST FULL SCAN的也来一个：
select /*+index_ffs(uiq_job_group UIQ_JOB_GROUP_MEMBER_ID)*/count(*) from uiq_job_group;
minsic78 2018-04-16
- 打赏
- 举报
这个计划走的有点奇葩，先用提示看看走表扫描需要多长时间？
select /*+full(uiq_job_group)*/count(*) from uiq_job_group;
Walex 2018-04-16
- 打赏
- 举报
这个计划走的有点奇葩，先用提示看看走表扫描需要多长时间？
select /*+full(uiq_job_group)*/count(*) from uiq_job_group;[/quote]
上面有我的QQ，能不能加我QQ指导一下。
select count(*) from uiq_job_group;
第一次执行1秒以上，第二次0.5~0.05秒不等
select /*+full(uiq_job_group)*/count(*) from uiq_job_group;
第一次执行1.38秒，第二次0.06秒左右
select /*+index_ffs(uiq_job_group UIQ_JOB_GROUP_MEMBER_ID)*/count(*) from uiq_job_group;
第一次执行0.27秒，第二次0.04~0.07秒左右
Walex 2018-04-14
- 打赏
- 举报
具体哪些参数需要屏蔽，能不能提示一下？
加载更多回复（20）
