数据库勒索病毒故障处理

问题描述：

2017-10-18 13:41:52应用反馈测试库连不上。

排查思路：

1，远程登录测试数据库服务器，sqlplus连接数据库，发现报错：

ORA-00604: error occurred at recursive SQL level 1

ORA-00018: maximum number of sessions exceeded

数据库连接数满了，这个库连接数是1000个，正常情况下还是有很空余的连接。肯定是有非正常连接导致。（这里怀疑是应用程序连接池设置太大没回收导致）

lsnrctl stop 停用监听。

通过ps -ef|grep LOCAL=NO查出不是本地连接的连接进程编号。

批量kill -9查询到的进程编号，释放部分空闲连接，

Sqlplus / as sysdba连接到数据库。

通过SQL>select count(*),program,machine from v$session group by program,machine order by 1 asc;查出连接数最多的程序，让开发重启程序。

重启之后，过一会发现连接还是进程数满，这时怀疑应该是其他问题，进一步检查连接的程序发现如下问题：

库中竟然有168个job进程在运行，这个似乎不合常理，这个时候怀疑是否是job异常或者job的bug造成的。

查看库中可并行执行job的个数：

SQL>show parameter job_queue_processes

NAME                                 TYPE        VALUE

------------------------------------ ----------- ------------------------------

job_queue_processes                  integer     1000

修改成为20，看库是否正常：

SQL>alter system set job_queue_processes=20 scope=both;

重启数据库，释放部分连接：

SQL>shutdown abort; --这里最好不要用immediate;

SQL>startup mount;

SQL>alter database open;

这个时候查询会话数，只有100多是正常范围。

打开监听，用plsqldev测试能否正常连接

lsnrctl start

这时用客户端plsql dev工具连接，登陆数据库。发现连接无响应，plsql dev卡死。

客户端tnsping  Ip地址/orcl返回正常

远程连接到服务器，

服务端sqlplus / as sysdba --正常

切换应用账号conn syerp/*** --卡死

3，这时肯定是其他问题造成的，检查alert日志，查看是否有明显报错：

结合以前的经验发现，这个报错应该和盗版软件携带病毒有关。

解决办法：

手解决问题：

A，修改job_queue_process为0，禁止job的运行。

SQL>alter system set job_queue_process=0 scope=both ;

B，重启数据库

SQL>shutdowm abort;

SQL>startup mount;

SQL>alter database open;

C，找到最近新建的对象

Select *  from dba_objects  where  to_char(created,’yyyymmdd’)=’20171018’;

D，删除这些对象

drop trigger syerp."DBMS_CORE_INTERNAL         " ;

drop trigger syerp."DBMS_SUPPORT_INTERNAL         " ;

drop trigger syerp."DBMS_SYSTEM_INTERNAL         " ;

drop PROCEDURE syerp."DBMS_CORE_INTERNAL         " ;

drop PROCEDURE syerp."DBMS_SUPPORT_INTERNAL         " ;

drop PROCEDURE syerp."DBMS_SYSTEM_INTERNAL         " ;

drop PROCEDURE syerp."DBMS_STANDARD_FUN9         " ;

F，删除创建的大量JOB：

select count(*) from  dba_jobs

where schema_user='SYERP'

 and what  like 'DBMS_STANDARD_FUN9(%';

结果大概有8W多个。

分批批量删除：

select 'exec dbms_job.remove('||job||');' 

from dba_jobs

where schema_user='SYERP'

 and what  like 'DBMS_STANDARD_FUN9(%' and rownum<5000;

E，确认被job truncate的表：

select * from dba_objects

where to_char(last_ddl_Time,'yyyymmdd')='20171018' and owner='SYERP'

还好并没有表被清理。

F，测试连接，一切正常

G，开启job数：

H：检查alert日志是否正常：

后续：

通过数据库的listener日志，检查在12:07左右有哪些人用plsql dev工具连接数据库。发现如下：（数据库没有开审计，只能从监听日志排查）

通过和该同事沟通，发现确实是使用不良的软件导致：