通过操作系统的命令可以找到有问题的进程例如ps
然后找出查询出有问题的进程执行的操作,如下:
select /*+ordered */
sql_text,
spid,
v$session.program,
machine,
process,
sid,
v$session.SERIAL#
from v$process, v$session, v$sql
where v$sql.address = v$session.sql_address
and v$sql.hash_value = v$session.sql_hash_value
and v$session.paddr = v$process.addr
and v$process.spid = '&pid'
杀掉有问题的进程(参见liyugen的博客)
杀连接进程注意事项
当怀疑个别应用有问题:长时间执行不能结束,或者持有某种锁阻塞了其他应用并长时间不释放时,就考虑杀掉该连接进程。
得到session当前执行情况。
COLUMN operation FORMAT A40 Trunc
select substr(opname, 1, 40) operation,
SOFAR / TOTALWORK current_per,
to_char(START_TIME, 'MON dd HH24:MI:SS') start_time,
to_char(LAST_UPDATE_TIME, 'MON dd HH24:MI:SS') LAST_UPDATE_TIME,
TIME_REMAINING,
ELAPSED_SECONDS
from v$session_longops b
where b.sid = &sid
;
着重关注:current_per,当前完成工作的百分比,TIME_REMAINING,ELAPSED_SECONDS 预估完成时间,
以上信息反映了oracle预测的任务完成时间
得到session当前使用的undo情况
select a.sid, a.serial#, a.username, b.used_urec, b.used_ublk
from v$session a, v$transaction b
where a.saddr = b.ses_addr
and a.sid = &sid
注意:
b.used_urec--->Number of undo records used
b.used_ublk--->Number of undo blocks used
该信息反映了该session当前事务回滚段的使用情况,如果该session使用回滚段空间非常大,杀session回滚时就会需要很长时间。
因此应该结合上面的预估完成时间对比看是否应该选择杀session还是等待它自己执行结束。
杀连接进程的办法
1.从应用侧关闭问题应用
直接从AP机器找到并关闭应用程序
优点:对数据库影响较小
问题:如果是通过中间件连接数据库,查找定位应用程序较复杂,需要项目组配合。
2.在数据库主机kill oracle后台连接进程
根据sid找到该session的spid
select spid from v$process where addr in (select paddr from v$session where sid=&session_id);
在数据库主机kill -9 该spid。
可以在执行完该步骤后,再去sqlplus再次执行alter system kill session
优点:执行kill后,事务回滚完毕PMON会立即启动清除操作
问题:有很小概率可能会造成数据库crash
3.直接在sqlplus中alter session kill
Sqlplus中执行:
alter system kill session '&sid,&serial' immediate;
优点:直接从数据库操作
问题:这种方式下该session占用的一些资源会等待PMON清除,PMON清除的时机无法掌握,可能延时较长;有小概率可能会造成数据库crash