利用PMON清除标记为Killed的Session

用于恢复失败的数据库用户的强制性进程，它先获取失败用户的标识，释放该用户占有的所有数据库资源。PMON有规律地被呼醒，检查是否需要，或者其它进程发现需要时可以被调用。

 

       PMON进程负责在反常中断的连接之后的清理工作。例如，如果因某些原因专用服务“故障”或被kill掉，PMON就是负责处理（恢复或回滚工作）和释放你的资源。       PMON将发出未提交工作的回滚，释放锁，和释放分配给故障进程的SGA资源。除了在异常中断之后的清理外，PMON监控其他oracle后台进程，如果有必要（和有可能）重新启动他们。如果共享服务或一个分配器故障（崩溃），PMON将插手并且重启另一个（在清理故障进程之后）。

       PMON将观察所有Oracle进程，只要合适或重启他们或中止进程。例如，在数据库日志写进程事件中，LGWR故障，实例故障。这是一个严重的错误，最安全的处理方法就是去立即终止实例，让正常的恢复处理数据。

       PMON为实例做的另一件事是去使用Oracle TNS监听器登记。当一个实例开启的时候，PMON进程投出众所周知的端口地址，除非指向其他，来看是否监听器正在开和运行着。众所周知/默认端口是使用1521。

       现在，如果监听器在一些不同端口开启会发生什么？这种情况，机制是相同的，除了监听器地址需要被LOCAL_LISTENER参数明确指定。如果监听器运行在库实例开启的时候，PMON和监听器通讯，传到它相关参数，譬如服务器名和实例的负载度量。如果监听器没被开启，PMON将周期性的试着和它联系来登记自己。

从下面参数我们可以看到 PMON进程是在第二个启动

Starting up ORACLE RDBMS Version: 9.2.0.1.0.
System parameters with non-default values:
  processes                = 150
  timed_statistics         = TRUE
  shared_pool_size         = 50331648
  large_pool_size          = 8388608
  java_pool_size           = 33554432
  control_files            = d:\oracle\oradata\orcl\control01.ctl, d:\oracle\oradata\orcl\control02.ctl, d:\oracle\oradata\orcl\control03.ctl
  db_block_size            = 8192
  db_cache_size            = 25165824
  compatible               = 9.2.0.0.0
  log_archive_start        = TRUE
  log_archive_dest_1       = LOCATION=d:\oracle\oradata\orcl\archive

log_archive_format       = %t_%s.dbf
  db_file_multiblock_read_count= 16
  fast_start_mttr_target   = 300
  undo_management          = AUTO
  undo_tablespace          = UNDOTBS1
  undo_retention           = 10800
  remote_login_passwordfile= EXCLUSIVE
  db_domain                =
  instance_name            = orcl
  dispatchers              = (PROTOCOL=TCP) (SERVICE=orclXDB)
  local_listener           = LISTENER_ORCL
  hash_join_enabled        = TRUE
  background_dump_dest     = d:\oracle\admin\orcl\bdump
  user_dump_dest           = d:\oracle\admin\orcl\udump
  core_dump_dest           = d:\oracle\admin\orcl\cdump
  sort_area_size           = 524288
  db_name                  = orcl
  open_cursors             = 300
  star_transformation_enabled= FALSE
  query_rewrite_enabled    = FALSE
  pga_aggregate_target     = 25165824
PMON started with pid=2
DBW0 started with pid=3
LGWR started with pid=4
CKPT started with pid=5
SMON started with pid=6
RECO started with pid=7
从启动过程来看，说明，在startup nomount过程中，后台进程已经启动了！

终止用户进程必须知道PMON进程相关，很多时候用户被终止后，pmon进程并没有释放相关进程（当在Oracle中kill session以后, Oracle只是简单的把相关session的paddr指向同一个虚拟地址.此时v$process和v$session失去关联,进程就此中断.然后Oracle就等待PMON去清除这些Session.所以通常等待一个被标记为Killed的Session退出需要花费很长的时间.如果此时被Kill的process，重新尝试执行任务，那么马上会收到进程中断的提示，process退出，此时Oracle会立即启动PMON来清除该session.这被作为一次异常中断处理），这时我们只有两种办法来解决

一是：我们可以查看并修改_pkt_pmon_interval（启动周期）这个隐形参数，通过缩短PMON的启动周期来清楚标记为Killed的Session

查询隐形参数命令如下：

select a.ksppinmname,b.ksppstvlvalue,a.ksppdescdescription

from x$ksppi a,x$ksppcv b

where a.inst_id=USERENV('Instance')

and b.inst_id=USERENV('Instance')

and a.indx= b.indx

orderbyname;

查询结果：

_pkt_pmon_interval            50         PMON process clean-up interval (cs) 

修改命令：

ALTERSYSTEMSET "_pkt_pmon_interval"=5;

_pkt_pmon_interval   5          PMON process clean-up interval (cs)

二是：通过手工触发PMON执行

首先确认PMON进程是who
SQL> select pid,spid from v$process p,v$bgprocess b
where b.paddr=p.addr
and name='PMON';

查询结果

触发进程：

SQL> oradebug wakeup 2