客户日常运维执行强制终止会话后，遇到诡异现象：操作系统服务进程已经彻底消失，但gv$session中会话长期停留在KILLED状态：滞留1 小时以上无法自动清理KILLED仅为会话状态标记，资源回收由 PMON 异步执行，短时残留属于 Oracle 正常机制；进程消失、TADDR 为空、无锁、滞留超 1 小时的僵尸会话，两大核心诱因：RAC 集群 GES 全局同步阻塞 / XA 分布式事务多分支未

压测实验结束后，仅删除了编译源码与临时文件，未清理全局 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。