下午开发人员反映，一个测试环境数据库访问非常慢，让我帮忙分析原因。
目前创新互联已为成百上千家的企业提供了网站建设、域名、雅安服务器托管、网站托管、服务器租用、企业网站设计、港闸网站维护等服务，公司将坚持客户导向、应用为本的策略，正道将秉承"和谐、参与、激情"的文化，与客户和合作伙伴齐心协力一起成长，共同发展。正好刚装了 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 配置文件。