?
用户报告前台业务响应缓慢，登陆至数据库获取awr报告。kill掉相关会话后系统恢复，杀会话可参考metalink id 786507.1
Load Profile 除了Rollback per transaction %比较高之外，达到了95%。其他指标似乎正常。
于是进一步查看事务回滚相关信息,可以看到每秒事务回滚数（transaction rollbacks）只有145.13，远远小于user rollbacks （2,454.12）
Statistic ??????????????????????????????????????????????? Total ? per Second per Trans
rollback changes - undo records applied ????????????????? 830,757 688.73 ??? 0.27
rollbacks only - consistent read gets ??????????????????? 152,722 126.61 ??? 0.05
transaction rollbacks?????????????????????????????????????? 175,061 145.13 ??? 0.06
transaction tables consistent read rollbacks ????????????? 322 ???? 0.27 ????? 0.00
transaction tables consistent reads - undo records applied 96,665 ?? 80.14 ????? 0.03???????????????????????????????????????????????????????????????????????????????????
user commits ????????????????????????????????????????????? 168,522 ? 139.71 ??? 0.05?????
user rollbacks ??????????????????????????????????????????? 2,960,222?? 2,454.12??? 0.95
这里需要注意的是在分布式事务中，如采用dblink获取数据，不论用户发出commit或者rollback，在会话统计中transaction rollbacks基数都会增加。即commit或者rollback一次
transaction rollbacks都会加1.
当用户发出rollback命令，不论有无事务user rollbacks都会增加。从数值上来看
Rollback per transaction %应该等于user rollbacks/(user commits+user rollbacks),所以回滚率高应该不会是引起性能问题的主要原因。
通过进一步研究可以发现 Rollback per transaction%计算方法可以$ORACLE_HOME/rdbms/admin/sprepins.sql找到
Rollback per transaction %:' dscr,? round(100*:urol/:tran,2) pctval
而urol，tran可以从$ORACLE_HOME/rdbms/admin/spcpkg.sql脚本中找到具体意思
urol?? := SYSDIF('user rollbacks');
tran?? := ucom + urol;
ucom?? := SYSDIF('user commits');
我们的猜测得到了证实。
于是进一步分析top 5等待事件，可以看到前3位都为mutex等待。
从经验来讲，出现mutex锁等待，且出现了共享和排他一起出现。在Oracle 10g mutex技术还不是非常成熟。
一般来说，出现这种等待八九不离十应该是bug引起的，可以通过_kks_use_mutex_pin将其关闭。在Oracle 10g中mutex等待一般都是shared pool引起的。而引起shared pool故障，
一般来说大量的parse或者ddl或者高版本SQL引起的，在本案例中可以看到soft parse指标还算正常。那么接下来查看SQL是否有高版本。
果然在高版本SQL列表中出现了：
接下来查询V$SQL_SHARED_CURSOR观察引起高版本SQL的原因：可以看到AUTH_CHECK_MISMATCH，TRANSLATION_MISMATCH等匹配发生问题
通过搜索metalink 果然是bug 11930680，其解决办法是设置参数optimizer_secure_view_merging=false
This problem is introduced in 10.2.0.5 and 11.2.0.2 .
If optimizer_secure_view_merging is enabled then some SQL statements may
not be shared due to AUTH_CHECK_MISMATCH / INSUFF_PRIVS even if the
SQL is issued repeatedly by the same user. This can cause excess shared
pool memory use and other contention issues due to the high child cursor
count.
There is also a security issue addressed within this fix and so
customers needing this fix have to go via the security process.
(Patches are restricted)
Workaround:
? The only workaround is to set optimizer_secure_view_merging=false
? which may not be acceptable in many cases.
Load Profile 除了Rollback per transaction %比较高之外，达到了95%。其他指标似乎正常。
于是进一步查看事务回滚相关信息,可以看到每秒事务回滚数（transaction rollbacks）只有145.13，远远小于user rollbacks （2,454.12）
Statistic ??????????????????????????????????????????????? Total ? per Second per Trans
rollback changes - undo records applied ????????????????? 830,757 688.73 ??? 0.27
rollbacks only - consistent read gets ??????????????????? 152,722 126.61 ??? 0.05
transaction rollbacks?????????????????????????????????????? 175,061 145.13 ??? 0.06
transaction tables consistent read rollbacks ????????????? 322 ???? 0.27 ????? 0.00
transaction tables consistent reads - undo records applied 96,665 ?? 80.14 ????? 0.03???????????????????????????????????????????????????????????????????????????????????
user commits ????????????????????????????????????????????? 168,522 ? 139.71 ??? 0.05?????
user rollbacks ??????????????????????????????????????????? 2,960,222?? 2,454.12??? 0.95
这里需要注意的是在分布式事务中，如采用dblink获取数据，不论用户发出commit或者rollback，在会话统计中transaction rollbacks基数都会增加。即commit或者rollback一次
transaction rollbacks都会加1.
当用户发出rollback命令，不论有无事务user rollbacks都会增加。从数值上来看
Rollback per transaction %应该等于user rollbacks/(user commits+user rollbacks),所以回滚率高应该不会是引起性能问题的主要原因。
通过进一步研究可以发现 Rollback per transaction%计算方法可以$ORACLE_HOME/rdbms/admin/sprepins.sql找到
Rollback per transaction %:' dscr,? round(100*:urol/:tran,2) pctval
而urol，tran可以从$ORACLE_HOME/rdbms/admin/spcpkg.sql脚本中找到具体意思
urol?? := SYSDIF('user rollbacks');
tran?? := ucom + urol;
ucom?? := SYSDIF('user commits');
我们的猜测得到了证实。
于是进一步分析top 5等待事件，可以看到前3位都为mutex等待。
从经验来讲，出现mutex锁等待，且出现了共享和排他一起出现。在Oracle 10g mutex技术还不是非常成熟。
一般来说，出现这种等待八九不离十应该是bug引起的，可以通过_kks_use_mutex_pin将其关闭。在Oracle 10g中mutex等待一般都是shared pool引起的。而引起shared pool故障，
一般来说大量的parse或者ddl或者高版本SQL引起的，在本案例中可以看到soft parse指标还算正常。那么接下来查看SQL是否有高版本。
果然在高版本SQL列表中出现了：
接下来查询V$SQL_SHARED_CURSOR观察引起高版本SQL的原因：可以看到AUTH_CHECK_MISMATCH，TRANSLATION_MISMATCH等匹配发生问题
通过搜索metalink 果然是bug 11930680，其解决办法是设置参数optimizer_secure_view_merging=false
This problem is introduced in 10.2.0.5 and 11.2.0.2 .
If optimizer_secure_view_merging is enabled then some SQL statements may
not be shared due to AUTH_CHECK_MISMATCH / INSUFF_PRIVS even if the
SQL is issued repeatedly by the same user. This can cause excess shared
pool memory use and other contention issues due to the high child cursor
count.
There is also a security issue addressed within this fix and so
customers needing this fix have to go via the security process.
(Patches are restricted)
Workaround:
? The only workaround is to set optimizer_secure_view_merging=false
? which may not be acceptable in many cases.
参考至:http://dbzone.iteye.com/blog/1007348
如有错误，欢迎指正
邮箱:[email protected]
如有错误，欢迎指正
邮箱:[email protected]