前言
最近客户在测试新系统A时，遭遇ORA28，回话被终止的问题。
先了解一下大致环境，系统A由系统B通过rman还原恢复，应用程序已经在系统B跑批通过，现在系统A上遇到下面问题。
应用程序报错如下
Oracle alert日志也有相关ORA 28报错
分析过程
Oracle 官网对ORA 28解释如下，很明显此错误产生是由于正在执行的回话被kill掉，准确点说就是被语句alter system kill session 'xx,xx'杀掉。
那么问题来了，操作时没有DBA对此回话进行kill操作，难道数据库有相关设置，开始检查数据库相关项。
[oracle@redhat3 ~]$ oerr ora 28
00028, 00000, "your session has been killed"
// *Cause: A privileged user has killed your session and you are no longer
// logged on to the database.
// *Action: Login again if you wish to continue working.
1、检查监听文件配置，sqlnet.ora，并没有特殊参数配置，明显不是此处的问题。
2、检查数据库资源配置，并没有配置resource_manager_plan参数，也不是此处的问题。
3、静下来想想，数据库肯定不会自己执行alter system kill session，既然数据库方面没有问题，那就从客户端应用方面开始查找问题。
4、检查客户端sqlnet.ora配置，无异常。
5、现在就剩下前台应用程序没有检查，由于前台应用程序为C++编写，生成了一个.exe执行程序，并不能直接看到其业务逻辑，好在可以通过其他方法查看
部分代码，首先将AAAA.exe单独复制出来，修改其后缀名AAAA.txt，这样用txt记事本的方式打开，就会出现下面代码，虽然是乱码，但还有部分可以查看，搜索
kill sesion相关语句，果然查到相关kill sesion语句，至此，问题来源基本查明，剩下的移交给应用商，检查业务逻辑就可以了。
6、最后的深思，为什么系统A由系统B还原恢复所得，而系统B确没有问题，后来听应用说明才知道，系统B后来是经过补丁升级，所以避开了kill session的
逻辑处理，并没有对测试系统A进行升级。。。。。。倒腾这么久，竟是应用的一不留神。
总结
虽说问题是由应用商大意所致，但是从此次问题的排查过程，可以收获一下几点：
1、在分析问题时，例如ORA报错，首先分析其报错触发原因，在分析谁能触发此报错
2、排查问题时，从多方面入手，数据库和应用都可能触发，不要一看ORA就把问题定位到数据库服务器
3、对应用不了解的情况下，可从其他方面探查。
下面附上ORA28报错的情景重现。
Session 1 ================ SQL> select SID, SERIAL# from v$session where sid=(select distinct sid from v$mystat); SID SERIAL# ---------- ---------- 63 7 SQL> declare 2 pp number; 3 begin 4 for i in 1..1000000 loop 5 select count(1) into pp from SYS_TEST; <<<<<<<<<<Runing the scripts then kill session in the session 2 6 end loop; 7 end; 8 / Session 2 ================ SQL> alter system kill session '63,7'; System altered. Alert log ============ Thu Apr 18 07:39:04 2019 opiodr aborting process unknown ospid (30547) as a result of ORA-28