本文相对较为简单，简单介绍一下ORACLE后台进程（ORACLE的INSTANCE主体是由内存+后台进程组成），其中部分也是备份与恢复的关键点，本文主要说一下ORACLE后台进程的工作原理，首要分类的是将ORACLE后台进程分为：独立模式、共享模式，我们一般采用独立模式，也就是会话的后台进程是独立的，共享模式相对来说有一个分配资源和并行处理的，所以用于MTS系统中，暂时不考虑这方面的问题，简单说下进程吧：
1、ORACLE进程查询介绍
2、核心进程PMON说明
3、核心进程SMON说明
4、核心进程DBWR说明
5、核心进程LGWR说明
6、CKPT说明
8、其它一些进程
正文（跟着操作一遍即可）：
1、ORACLE进程查询介绍
--首先登陆数据库：
SQL> connect / as sysdba;
已连接。
--查看SGA的信息，10g才有的视图
--ORACLE 10G后才可以使用的命令
SQL> select * from v$sgainfo;
NAME BYTES RES
-------------------------------- ---------- ---
Fixed SGA Size 1249992 No
Redo Buffers 7135232 No
Buffer Cache Size 398458880 Yes
Shared Pool Size 121634816 Yes
Large Pool Size 4194304 Yes
Java Pool Size 4194304 Yes
Streams Pool Size 0 Yes
Granule Size 4194304 No
Maximum SGA Size 536870912 No
Startup overhead in Shared Pool 50331648 No
Free SGA Memory Available 0
--看下SGA大小：
SQL> show parameter sga_t;
NAME TYPE VALUE
------------------------------------ ----------- -------------------
sga_target big integer 512M
--提取已经分配的后台进程：
SQL> select name,DESCRIPTION from v$bgprocess where paddr<>'00';
NAME DESCRIPTION
----- -----------------------------------------------------------
PMON process cleanup
PSP0 process spawner 0
MMAN Memory Manager
DBW0 db writer process 0
LGWR Redo etc.
CKPT checkpoint
SMON System Monitor Process
RECO distributed recovery
CJQ0 Job Queue Coordinator
QMNC AQ Coordinator
MMON Manageability Monitor Process
NAME DESCRIPTION
----- -----------------------------------------------------------
MMNL Manageability Monitor Process 2
在这里看到很多进程，红色标注部分全部为核心进程，CKPT虽然不是核心进程，但是也很重要，所谓核心进程是，实例中要是这些进程死掉了，实例只有重启，没法处理，其余非核心进程死掉，可以处理，通过ALTER SYSTEM REGISTER，即通过配置重新注册一次，有部分修改的配置信息，须立即生效的，也是通过这个命令完成，下面对核心进程和非核心进程说明一下。
2、核心进程PMON说明
全称为：process cleanup ，表示进程清理，负责将死掉的进程杀掉，如连接到数据库后，断掉网络这些进场将会被杀掉，如果是死锁掉的，需要人工干预后才能回收。
3、核心进程SMON说明
System Monitor Process：1、做资源回收、数据库崩溃时自我修复。回收资源包含：排序的、回退的、DROP掉的表，将资源合并；2、当数据库异常关闭时，启动中SMON后台进程通过控制文件发现日志文件和数据文件不一致，通过日志文件恢复数据文件，而动作由SMON执行。
4、核心进程DBWR说明
db writer process 0（db代表DATABASE）：带下标的，代表有一组后台进程，不带下标的，都是独立的一个进程运行；DBWR进程，最多20个，最少一个。一般和CPU有关系，根据CPU进行相应的设置。这类进程做一件事情就是写脏数据的过程。dirty buffer。
DBWR触发条件：
1、脏数据库太多，没有多余的缓冲区来存放了。
2、超时 3秒左右
3、CKPT，检查点触发
4、数据库备份
5、表空间离线或只读时
6、停止数据库
可以看出，没有说明COMMIT时会进程DBWR，那么如果COMMIT了，但是没有写数据，在断电、SHUTDOWN ABORT等情况下，数据不就没有了吗，后面说道LGWR和CKPT时会连套起来说明。
SQL> select name,DESCRIPTION from v$bgprocess where name like 'DBW%';
NAME DESCRIPTION
----- ----------------------------------------------------------------
DBW0 db writer process 0
DBW1 db writer process 1
DBW2 db writer process 2
DBW3 db writer process 3
DBW4 db writer process 4
DBW5 db writer process 5
DBW6 db writer process 6
DBW7 db writer process 7
DBW8 db writer process 8
DBW9 db writer process 9
DBWa db writer process 10 (a)
NAME DESCRIPTION
----- ----------------------------------------------------------------
DBWb db writer process 11 (b)
DBWc db writer process 12 (c)
DBWd db writer process 13 (d)
DBWe db writer process 14 (e)
DBWf db writer process 15 (f)
DBWg db writer process 16 (g)
DBWh db writer process 17 (h)
DBWi db writer process 18 (i)
DBWj db writer process 19 (j)
5、核心进程LGWR说明
LGWR Redo etc：写日志文件，将日志缓冲区的数据写入在线日志文件中。其写法为：循环写、顺序写，按组（GROUP）管理日志文件（在前面文章中有说明），一般默认三组，每个成员（GROUP下的一个日志文件）最少4M大小，默认50M，同组下多个成员一起使用过一次后成为孪生兄弟，即相互拷贝，相互备份，因为它是保护数据的，它自己只有自己保护自己，就想控制文件一样。
LGWR触发条件：
1、提交做COMMIT或ROLLBACK；
2、大于1M日志未写入磁盘
3、1/3日志缓冲区未写入磁盘
4、DBWR之前须先写LGWR，也就是LGWR写入的日志文件的SCN号码肯定是大于等于数据文件的
5、超时
LGWR会记录什么？
也就是做COMMIT的时候会将信息写入日志文件中，记录的大致是字段地址、字段值、事务标志。
很多人可能会问：既然这些信息都记录了所有的插入数据文件的信息干嘛还要写日志呢？
很简单的答案：
1、第一使用日志文件是轻量的，相对较为安全，若文件坏掉，绝大部分甚至全部数据可以找回。
2、日志文件写比数据文件写要快很多，大家会发现日志文件只有一个LGWR进程，而DBWR有20，但是20也没有LGWR一个快，主要有两个方面的原因：一个是日志文件是顺序写，循环写，它不用考虑下面的位置，而数据文件需要找到实际的位置去修改并且需要分配磁盘空间；其次，数据文件修改后牵涉相关视图的修改，若频繁使用DBWR，在高并发系统中会很容易就出现瓶颈了，所以你COMMIT的时候，如果ORACLE把成功写入在线日志文件，它就向客户反馈提交成功了。
6、CKPT说明
全称checkpoint：这个概念一直很模糊，因为有个命令是ALTER SYSTEM CHECKPOINT，这里的额CKPT是一个进程，而那个命令是调用这个进程来进程全局的磁盘写，而CHECKPOINT还有一个在中文上很多时候把他称为检查点的概念，这个检查点可以理解为一个已经被存盘的SCN号码，也就是一个特殊的SCN号码，他们都存在于数据文件头、控制文件头、日志文件内部，通过V$DATABASE视图以及表空间视图、数据文件视图、控制文件视图都可以查到（在前面文章已经说过），当日志文件进行增量或者全部存盘时，会将起始的CHECKPOINT_CHANGE#编号，与需要存盘的SCN号码对比（全量存盘以当前SCN号码为准），将这部分脏块写入数据文件，并修改数据文件头和控制文件头的检查点号码。
简单说下一下几个问题：
为什么用SCN号码，不用时间戳？
因为系统时间是可以被改变的，SCN号码永远向上增长。
SCN号码自动增长，会不会有上线？
是的，有的，不过很大，有这么大:
SQL> select to_number('ffffffffffff','xxxxxxxxxxxxx') from dual;
TO_NUMBER('FFFFFFFFFFFF','XXXXXXXXXXXXX')
-----------------------------------------
2.8147E+14
以数据库7*24不休息，每秒20万次业务操作，则查询一下40年使用多少：
SQL> select 40*365*24*3600*200000 FROM DUAL;
40*365*24*3600*200000
---------------------
2.5229E+14
即这样下去最少可以使用四十多年，到四十多年后，ORACLE再给升级一下就搞定这些事情了。
说到第一个问题，COMMIT不写数据文件，数据跑哪里去了？
在LGWR中，COMMIT时是通过LGWR写入在线日志文件后反馈提交成功的，也就是要写入数据文件的内容都在这里面可以找到。当你shutdown abort或者断电时，然后重启到MOUNT时，SMON进程通过控制文件发现检查点记录与日志文件不协调，此时，就通过日志文件增量构造DIRTY LIST，并进行存盘操作，然后启动，这个过程对外部没有任何效果，内部自动完成的。
同理，日志文件坏掉了，所谓的RESETLOGS就是通过这个SCN号码从新构造日志文件；
初始化参数文件坏掉了，编辑一个；
控制文件坏掉了可以提前做一个TRANCE，其实也就是控制文件的空壳创建语句，自己也可以编辑一个，不过记得将临时表空间引入（否则大SQL会报错），然后通过日志文件RECOVER一下。
关于数据文件坏掉不是一两句话可以说明白的，后面专门说这个，只是也会涉及SCN号码来回调用和介质恢复而已。
7、其它的一些进程说明：
ARCH进程：归档进程，在归档模式下，当所有在线日志组全部写满的时候，再进行切换时，就会自动启用ARCH进程，这些日志文件被复制到一个或多个主机上，复制后，被称为归档日志文件。
CJQ0 Job Queue Coordinator：队列进程，可以使用C000~C999的作业进程来运行。
Snnn：共享服务器进程，用于MTS系统。
Dnnn：共享服务器调度进程。
10g后的一些：
QMNn ：队列监控进程。
MMON Manageability Monitor Process、MMNL Manageability Monitor Process 2：为自动工作区（AWR）手机数据库的快照，根据调度将SGA的手机信息交给AWR。
MMAN：自动内存管理进程。
等等，如：RBAL、ASMB，11g中还有更多的进程。