昨天遇到一个数据库运行缓慢的问题，awr报告部分信息如下：
看到硬解析并不多，但是从等待事件来看的是在等待硬解析，直接登录数据库查看一下当前等待事件。
与awr报告一样cursor：pin S wait on X和library cache lock 等待，查看当前的阻塞情况，阻塞进程也是在执行grfvv7n41241w语句，
这个sql每次执行都要硬解析，应该是sql子游标不能共享造成硬解析，grfvv7n41241w是一个查询语句，业务操作中频繁调用，这样来看符合业务现在的状况，
都在等待硬解析，但完成后不能共享又要再次解析，进而造成系统运行缓慢。查看了执行计划版本，没有变化。为什么会这么多硬解析呢？
查看了一下v$sql_shared_cursor视图，该SQL的bind_equiv_failure 为Y，查看文档中bind_equiv_failure意思
BIND_EQUIV_FAILURE VARCHAR2(1) (Y|N) The bind value's selectivity does not match that used to
optimize the existing child cursor
绑定值的选择性与用于优化现有子游标的选择性不匹配，不太好理解。
查看sql的绑定变量
查看对应表中字段的数据类型为NVARCHAR2，这样原因就明确了，绑定变量数据类型与字段类型不一致导致子游标不能共享。
怎么会类型不一致呢？查看了一下执行计划，其中有一些SYS_OP_C2C函数比较特别。谓词信息中有SYS_OP_C2C函数，SYS_OP_C2C 是一个内部函数，功能是将VARCHAR2的数据类型转换成国家字符集的NVARCHAR2类型，内部通过TO_NCHAR函数实现。
网上找到了一篇潇湘隐者的博文，解释了这个问题，ORACLE中内部函数SYS_OP_C2C和隐式类型转换，并且给出了解决方案，
SOLUTION
1. Create a function based index on the column.
e.g create index <index_name> on <table_name> (SYS_OP_C2C(<column>));
OR
2. Ensure that your bind "string" datatype and column datatype are the same.
A java example where this can occurs is when defaultNChar=TRUE. This will cause strings to bind as NVARCHAR2 causing the predicate that are subset datatypes to be converted to NVARCHAR2.
e.g. -Doracle.jdbc.defaultNChar=true
<connection-property name="defaultNChar">true</connection-property>
应用是JDBC连接，用第二种方案解决了。再次查询看到数据类型一致了。
有两个疑问， 对JAVA不太了解应该与应用程序有关。
1、绑定变量的数据类型不匹配为什么是BIND_EQUIV_FAILURE而不是SQL_TYPE_MISMATCH？
2、应用已上线运行半年多了，怎么会现在才出现这个问题呢？