数据库勒索病毒故障处理
问题描述：
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工具连接数据库。发现如下：（数据库没有开审计，只能从监听日志排查）
通过和该同事沟通，发现确实是使用不良的软件导致：
