压测实验结束后，仅删除了编译源码与临时文件，未清理全局 LD_LIBRARY_PATH 变量、未删除残留安装目录，导致系统动态链接器每次执行 su 切换用户时，遍历无效库路径反复重试，最终造成命令卡死。sudo 具备安全净化机制，默认自动清空、过滤高危环境变量，主动丢弃错误的 LD_LIBRARY_PATH，不会遍历无效目录，因此仅轻微延迟、可以正常进入用户环境。依次重启 dbus、systemd

检查下面的misdb1_ora_7191494.trc，发现执行了一个pql/sql。这主要还是变量过多，由于bug导致实例宕机，根据alert日志跟踪的trc文件。中间有多个update，每个update绑定了多个变量，变量超过了65535。所以决绝方式可以减少变量数解决或者升级解决。

数据库性能问题未必是“数据库本身”的锅。当AWR显示集群等待事件突出时，需跳出“SQL调优”的惯性，向下穿透到操作系统、网络甚至硬件层，才能找到真正的根因。

检查应用端、服务器端、防火墙的MTU值是否一致，更改应用端、服务端的MTU值与防火墙一致，MTU默认值为1500，参考可调至9000（oracle原厂建议oracle服务器是 9000，同时参考了其他银行的MTU值），建议网络工程师可以用ping包的方式 测试出符合当前环境的最佳MTU。ORACLE官方针对这类错误明确：错误堆栈依次为TNS-12170/TNS-12535/TNS-12560/TN

导致解析混乱，另外传入参数异常也会导致解析出错。该问题主要在于查询语句的表名重复别名。建议修改别名，与本名区分开来。

这个问题首先想到了，基数反馈(Cardinality Feedback )问题导致的查询慢，由于并不确认是否真是这个问题造成，首先在会话级别调试，设置session级别"_optimizer_use_feedback"=FALSE。基数反馈是 Oracle 11.2 引入的关干 SQL性能优化的新特性，但是该参数存在不稳定因素，可能会带来执行效率的问题，所以建议关闭优化器反馈。同样一个sql查询视

使用q'[ ]' 避免单引号冲突，不使用q，单引号需要两个。在sqlplus下执行加密函数即可。使用自带的存储过程加密，在执行密文。

修改/etc/security/limits.conf中memlock为unlimited，重启实例恢复。limit配置：/etc/security/limits.conf。

然后我们就可以取到json串中任意节点的值。向数据库导入json相关jar包。要删除的话，删除指定jar。

如，执行一条 SQL 的时候，如果该 SQL 在共享池中不存在，这就是硬解析，需要首先分配共享池空间，创建父游标的结构，然后创建一个子游标。如果下一次再执行一条类似的 SQL，该 SQL 的父游标存在，经过检查发现子游标是可以共享的，而且这个子游标的所有关联对象在共享池中都存在，那么就可以马上执行了，这就是软软解析，也是软解析的一种。如果子游标是不可共享的，那么就需要创建一个新的子游标（对于 SQ