|
副问题[/!--empirenews.page--]
概述
最近出产情形有这么个征象，平常的订单调治只必要2s内可以出功效，可是多小我私人调治就会卡住，高出15分钟都没有功效出来，偶然还会失败然后导致数据禁绝确。
下面记录一下出产情形卡即刻排查的进程。
1、获取ASH陈诉
- SQL> @?/rdbms/admin/ashrpt.sql
- --To specify absolute begin time:
- --[MM/DD/YY]] HH24:MI[:SS]
- --08/09/19 08:40:00
2、ASH说明
1、Top User Events
2、相干sql
Top SQL with Top Events
sql明细
3、存储进程
4、TOP sessions
从上面说明可以看到两个明明的守候变乱：wait for stopper event to be increased 守候变乱和wait for a undo record 守候变乱，这个应该是批量使命调治的时辰发生了大量的大事宜，发生了一些回滚造成了严峻的资源耗损
3、处理赏罚大事宜并发回滚
一样平常环境下wait for stopper event to be increased 守候变乱是跟wait for a undo record 守候变乱接洽起来的。
对付这个守候变乱metalink上面有一篇文档
- 464246.1
- Sometimes Parallel Rollback of Large Transaction may become very slow. After killing a large running transaction
- (either by killing the shadow process or aborting the database) then database seems to hang, or smon and parallel query servers
- taking all the available cpu.
- In fast-start parallel rollback, the background process Smon acts as a coordinator and rolls back a set of transactions in parallel
- using multiple server processes. Fast start parallel rollback is mainly useful when a system has transactions that run a long time
- before comitting, especially parallel Inserts, Updates, Deletes operations. When Smon discovers that the amount of recovery work is
- above a certain threshold, it automatically begins parallel rollback by dispersing the work among several parallel processes.
- There are cases where parallel transaction recovery is not as fast as serial transaction recovery, because the pq slaves are interfering
- with each other. It looks like the changes made by this transaction cannot be recovered in parallel without causing a performance problem.
- The parallel rollback slave processes are most likely contending for the same resource, which results in even worse rollback performance
- compared to a serial rollback.
（编辑：河北网）
【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!
|
