下午开发人员反映，一个测试环境数据库访问非常慢，让我帮忙分析原因。
成都创新互联公司自成立以来，一直致力于为企业提供从网站策划、网站设计、成都网站设计、成都网站制作、外贸网站建设、电子商务、网站推广、网站优化到为企业提供个性化软件开发等基于互联网的全面整合营销服务。公司拥有丰富的网站建设和互联网应用系统开发管理经验、成熟的应用系统解决方案、优秀的网站开发工程师团队及专业的网站设计师团队。
正好刚装了 SQLBooster ，通过它来分析，顺便熟悉一下它的使用。
数据库慢的话首先看等待事件，在 SQLBooster 主界面点开“事件排行”，界面显示 TOP5 等待事件如下：
其中 row cache lock 排第一。
出现 session lock ，通过主界面的“阻塞树”，可以查看 session 阻塞的情况。
不过这些 session 阻塞在动态变化，且并没有执行 SQL 。
查看当前的 active session 如下， session 中可以灵活根据条件过滤：
对于 row cache lock 等待事件，我们要获取 session 的 P1 参数。
用 P1 参数去 v$rowcache 中去查询参数名称，发现是“ dc_users ”。
和 dc_users 相关的，通常是由于用户登录引发。从审计视图中，查看当天的登陆审计，发现错误码 ORA-1017 占了绝大部分。
这个错误是用户名密码错误。
那么问题至此就清楚了，一台客户端用 jdbc 连接数据库，但是由于配置文件中密码录错了，反复重连。
而且配置了连接池，所以一瞬间有多个连接请求连接数据库。进而引起数据库响应缓慢。
在 sqlnet.ora 中将该客户端的 IP 加入访问黑名单，性能问题消失。然后联系该客户端的开发人员，修改 jdbc 配置文件。
