1、我看其它的帖子有回复是查询select * from DBA_HIST_ACTIVE_SESS_HISTORY where event like ‘%row cache objects%’
，能否进一步解释一下查询这个表后，应该关注那些内容才能知道如何去改正问题。
2、我尝试通过查询DBA_HIST_ACTIVE_SESS_HISTORY 这个表，通过TOP_level_SQL_ID查询v$sqlarea表，
抽查了几个，应该是索引条件不太理想，例如下面这个查询

这个结果内容和盖老师的文章
https://www.modb.pro/db/18894
提到的Cache order这些关键字都不匹配

如果你的系统存在高并发，考虑一下是否，缓存是否存在不够的问题，加大一下试一试。

这个直接查一下sequence的cache就可以，有没有低于10的，RAC环境下一般建议给100的cache。

附件1130.html是AWR日志
章老师 按照您的建议查询结果如下

纠结问题：
1、看查询结果99%都是oracle自己的sequence，如果批改成10或者100，是否会有冲突，是否需要重启oracle服务？
2、假如1的问题可以批改并且不用重启oracle服务，怎么进行批量修改，不能100多个都会影响系统的性能吧？
3、软件厂商在生产系统中建立了这个序列，

按照之前盖老师的文章中提到“RAC环境非必须的情况下不要使用ORDER，尤其要避免NOCACHE ORDER组合”。
看这个序列定义符合，但是不知道修改后的影响是什么？

针对系统的sequence也不需要调整，除非遇到明确的bug，只需要调整业务的序列过小问题，如果没有争用，20的cache足够了，修改不需要重启。
BTW，这个数据库负载非常低，如果应用没哟报错，其实可以暂时不用管。