一起ORA-00028案例的处理过程

前言

　　最近客户在测试新系统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