PMON和SMON的功能

PMON:进程监控进程
进程负责在反常中断的连接之后的清理工作。例如,如果因某些原因专用服务“故障”或被kill掉,PMON就是负责处理(恢复或回滚工作)和释放你的资源。PMON将发出未提交工作的回滚,释放锁,和释放分配给故障进程的SGA资源。
除了在异常中断之后的清理外,PMON监控其他oracle后台进程,如果有必要(和有可能)重新启动他们。如果共享服务或一个分配器故障(崩溃),PMON将插手并且重启另一个(在清理故障进程之后)。PMON将观察所有Oracle进程,只要合适或重启他们或中止进程。例如,在数据库日志写进程事件中,LGWR故障,实例故障。这是一个严重的错误,最安全的处理方法就是去立即终止实例,让正常的恢复处理数据。(注意这是很少发生的事情,应该立即报告oracle支持)。
PMON为实例做的另一件事是去使用Oracle TNS监听器登记。当一个实例开启的时候,PMON进程投出众所周知的端口地址,除非指向其他,来看是否监听器正在开和运行着。众所周知/默认端口是使用1521。现在,如果监听器在一些不同端口开启会发生什么?这种情况,机制是相同的,除了监听器地址需要被LOCAL_LISTENER参数明确指定。如果监听器运行在库实例开启的时候,PMON和监听器通讯,传到它相关参数,譬如服务器名和实例的负载度量。如果监听器没被开启,PMON将周期性的试着和它联系来登记自己。

SMON:系统监控
SMON是负责做所有系统级的工作。相对于PMON对单个进程感兴趣,SMON是一个系统级别的观点,是一种用于库的“垃圾收集者”。它做的工作包括如下7件:
? 清理临时表空间:伴随这“真正”的临时表空间的出现,清理临时表空间的杂事已经减轻了,但它还没完全消失。例如,当建立一个索引,在创建期间分配给索引的扩展区被标志为TEMPORARY。如果Create Index会话因某些原因异常中断,SMON负责清理他们。其他操作创建的临时扩展区,SMON同样会负责。
? 接合空闲空间:如果你正使用数据字典管理表空间,SMON负责把那些在表空间中空闲的并且互相是邻近的extent接合成一个较大的空闲扩展区。这发生仅在带有默认的pctincrease设置为非零的存储子句的字典管理表空间。
? 把对于不可用文件的事务恢复成活动状态:它的角色类似在库启动期间。这时,因为文件不能用于恢复,SMON恢复在实例/崩溃恢复期间被跳过的故障事务。例如,文件可能已经在不可用或没装载的磁盘上。当文件变可用了,SMON将恢复它。
? 执行一个RAC中故障节点的实例恢复:在一个oracle RAC配置中,当群集中的一个库实例失败(例如,实例正执行的机器故障了),一些群集中的其他节点将开启故障的实例的重做日志文件,为故障实例执行所有数据的恢复。
? 清理OBJ$:OBJ$是一个包含库中几乎每一个对象(表,索引,触发器,视图等等)的记录的行级数据字典表。许多次,这儿存在的记录代表已删对象,或代表不在这儿的对象,在oracle的信赖机制中被使用。SMON是删除这些不在被需要的行的进程。
? 收缩回滚段:SMON将执行回滚段的自动收缩到它的optimal尺寸,如果它被设置。
? “脱机”回滚段:对于DBA来,让一个有active事务的回滚段,脱机或不可用,这事是可能的。Active事务正使用这脱机回滚段是可能的。在这情况下,回滚不是真正的脱机;它被标志为“悬挂offline”。在后台进程中,SMON将周期性尽力让它真正脱机,直到成功。
那应该给你一种SMON所做的味道。它做许多其他事情,譬如存在DBA_TAB_MONITORING视图中的监控统计数据的洗刷,在SMON_SCN_TIME表中发现的时间戳定位信息的SCN的洗刷,等等。SMON在期间能消耗很多CPU,这应该被认为是正常的。SMON周期性的苏醒(或被其他后台进程叫醒)来执行这些管家的家庭杂事。

转载:http://blog.chinaunix.net/uid-20124596-id-1734405.html

PMON和SMON的功能

时间: 2024-11-08 05:33:17

PMON和SMON的功能的相关文章

SMON进程、PMON进程、LGWR/ARCH

SMON 进程:system monitor instance monitor 系统监控.实例监控进程 说明及作用:在实例关闭时,会清理临时段,整理空闲空间free space; 实例非正常关闭后,启动实例时,做instance recovery : SMON如何判断是否需要实例恢复: --在数据库mount状态,可以通过last_change#是否未Null; select name,checkpoint_change#,last_change# from v$datafile; --数据库在

InnoDB的后台线程和内存

InnoDB有多个内存块,你可以认为这些内存块组成了一个大的内存池,负责如下工作: 维护所有进程/线程需要访问的多个内部数据结构. 缓存磁盘上的数据,方便快速地读取,并且在对磁盘文件的数据进行修改之前在这里缓存. 重做日志(redo log)缓冲. .......... 后台线程的主要作用是负责刷新内存池中的数据,保证缓冲池中的内存缓存的是最近的数据.此外,将已修改的数据文件刷新到磁盘文件,同时保证在数据库发生异常情况下InnoDB能恢复到正常运行状态. 后台线程 由于Oracle是多进程的架构

Oracle 数据库的组成(instance+database)

Oracle服务器是一种对象关系数据库管理系统,它为信息管理提供开放.综合.集成的方法. Oracle服务器中有多种进进程.内存结构和文件: Oracle服务器由一个Oracle实例和一个Oracle数据库组成. Oracle服务器:Oracle实例+Oracle数据库 Oracle实例:后台进程+内存结构 (必须启动实例才能访问数据库中的数据,每次启动实例,都会分配系统全局去SGA并启动Oracle后台进程) SGA是用于村粗数据库信息的内存区,该信息为数据库进程所共享. 后台进程代表调用进程

MySQL Study案例之--MySQL体系和存储引擎

MySql Study案例之--MySql体系和存储引擎 1.数据库和实例     数据库:物理操作系统文件或其他形式文件类型的集合.在MySQL中,数据库文件可以是frm.myd.myi.ibd结尾的文件.当使用NDB引擎时,数据库文件可能不是操作系统上的文件,而是存放与内存之中的文件,但是定义仍然不变.      数据库实例:由数据库后台进程/线程以及一个共享内存区组成.共享内存可以被运行的后台进程/线程所共享.需要牢记的是,数据库实例才是真正用来操作数据库文件的. 在MySQL中,实例和数

SqLiter

1.去重 select *  from daydata where wtid||rectime in (select wtid||rectime from daydata group by wtid||rectime having count(wtid||rectime) > 1) and ctid not in (select min(ctid) from daydata group by wtid||rectime     having count(wtid||rectime)>1) (适

ocp 1Z0-043 131-205题解析

131. Which three methods can you use to run an Automatic Database Diagnostic Monitor (ADDM) analysis over a specific time period? (Choosethree.)A. Enterprise Manager GUIB. DBMS_TRACE package APIsC. DBMS_ADVISOR package APIsD. DBMS_MONITOR package API

oracle整体结构-内存结构、物理结构、逻辑结构、进程

Oracle的体系结构大体上分为两部分:Instance(实例)和Database(数据库). Instance(实例) :在Oracle Instance中主要包含了SGA以及一些进程(例如:PMON.SMON.DBWn.LGWR.CKPT等).如果一个用户的进程连接到Oracle Server时,其实就是连接到Oracle Instance.在SGA中又包含了5大部件:Share Pool.Database Buffer Cache.Redo Log Buffer.Java Pool.Lar

ORA-08104

https://blog.csdn.net/daiqiulong2 create index idx_p_merchant_detail_id on D_ORDER_DETAIL (merchant_detail_id) Online; 创建好长时间,没有反映:然后取消,结果删除索引的时候,报如下的错误: 错误:ORA-08104: this index object 67420 is being online built or rebuilt 通过 ONLINE 参数创建索引(或者重建索引),

undo回滚异常导致实例奔溃,无法正常open

接到地市反馈某一个数据库打不开了 1.登陆主机,查看数据库告警日志 最早数据库出现问题时的日志是在2014年6月7日 数据库在切换redo时异常关闭,之后数据库一直为开启使用 2.数据库在2014年6月8日 OPEN后,有recovery的进程报错 目前已经找不到这些文件,无法核实当时的异常信息源,接着往下看日志 3.数据库在2014年6月9日11:36:45时又异常关闭 4.同样的现象出现在2014年8月11日13:26:07,数据库异常关闭 5.数据库在2014年8月11日13:18:46再