DBWR进程
--查询dbwr进程号
select pname,spid from v$process where pname like 'DBW%';
PNAME SPID
----- ------------------------
DBW0 9776 ---查询的是操作系统的进程号
--linux 系统查询的进程号
[oracle@yang admin]$ ps -ef|grep ora_dbw |grep -v grep
UID PID PPID C STIME TTY TIME CMD
oracle 9776 1 0 Oct29 ? 00:00:02 ora_dbw0_yang
UID： 程序的用户所有者
PID ： 程序的ID号
PPID：则是其上级父程序的ID
C : cpu的使用百分比
linux命令： ps ( process status进程状态的缩写）
参数a 显示所有程序(比-a更详细）-a显示同一个终端的所有程序
-A 显示所有进程 = -e 两者相同
-f 显示所有进程之间的关系
|grep ora_ --过滤查询显示ora_开头的文件， -v 查询的结果过滤（除去） grep 的字段
应用： ps -ef|grep ora_ =》查询linux下，所有Oracle正在使用的进程
[oracle@yang ~]$ ps -l
F S UID PID PPID C PRI NI ADDR SZ WCHAN TTY TIME CMD
4 S 1001 13677 13676 0 80 0 - 16518 wait pts/5 00:00:00 bash
0 R 1001 14133 13677 0 80 0 - 15878 - pts/5 00:00:00 ps
F- 4 代表进程权限root: 1 表示只能查询
S- S可以唤醒使用，R正在运行，D不能使用，T停止状态，Z僵尸进程
UID/PID/PPID 代表进程的拥有者老板，进程的身份证，进程的父亲管理者
C CPU使用率，百分比；
PRI/NI 进程被CPU执行的顺序优先级，小高；
ADDR/SZ/WCHAN: 运行显示-，使用多少内存，-表示工作中
TIME：使用CPU时间，实际花费CPU时间
CMD，启用进程时间
uix: ps uix --查询
--知道进程号的作用，linux系统操作强制关闭数据库：
Kill -9 dbw0_pid --杀死了进程
--查询dbwr进程的描述：
select paddr,name,description from v$bgprocess where name like 'DBW%';
PADDR NAME DESCRIPTION
---------------- ----- ------------------------------
00000000B5510FB0 DBW0 db writer process 0 （数据写进程）
00 DBW1 db writer process 1
---
00 DBW9 db writer process 9
00 DBWa db writer process 10 (a)
--
00 DBWy db writer process 34 (y)
00 DBWz db writer process 35 (z)
36 rows selected. 11.2.0.4版本，dbwr进程最多36个进程；此时只使用了一个dbw0
SQL> show parameter writer --查询数据库写进程数量，与上分对比发现，未启用的DBWN进程PADDR=‘00’
NAME TYPE VALUE
-----------------------------------
db_writer_processes integer 1
SQL> show parameter count --查询CPU个数
cpu_count integer 1
SQL> alter system set db_writer_processes=5 scope=spfile;
SQL> startup force
SQL> show parameter writer
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
db_writer_processes integer 5
SQL> select paddr,name,description from v$bgprocess where name like 'DBW%' and paddr not in '00';
--只有四条记录：
DBWN进程，数量收到CPU个数的限制，本次操作虽然参数改为5个，但是实际启用的进程数量为4；
一个CPU支持4个dbwn写进程
DBWR-是什么，是数据写进程，写什么？ 将实例中的，buffer_cache中的脏块，写入database中的数据文件中，干活的是DBWR进程；
那么DBWR什么时候触发，什么时候写呢？
1.当数据库触发完全检查点的时候：
SQL> show parameter alert
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
log_checkpoints_to_alert boolean FALSE
SQL> alter system set log_checkpoints_to_alert=true; 修改参数后，生成的检查点会写入告警日志
System altered.
--触发检查点
alter system checkpoint;
show parameter dump=> tail -200f *.log
ALTER SYSTEM SET log_checkpoints_to_alert=TRUE SCOPE=BOTH;
Sun Oct 29 17:30:42 2017
Beginning global checkpoint up to RBA [0x33.c38.10], SCN: 1568364
Completed checkpoint up to RBA [0x33.c38.10], SCN: 1568364
疑问有个增量检查点，是什么呢？
SQL> alter system checkpoint;
Beginning global checkpoint up to RBA [0x33.c38.10], SCN: 1568364
Completed checkpoint up to RBA [0x33.c38.10], SCN: 1568364
SQL> alter system switch logfile;
Beginning log switch checkpoint up to RBA [0x34.2.10], SCN: 1568383
Thread 1 advanced to log sequence 52 (LGWR switch)
什么是实例恢复：从最近的一个完全检查点作为启始点，前滚走到数据库崩溃的最后一个日志记录的SCN；
然后回滚利用UNDO删除未提交的事务；
如果完全检查点半年触发，半年后数据库崩了，实例恢复，前滚应用半年日志吗？
是不是很傻，整理了一个增量检查点的概念，为啥要增量检查点，减少实例恢复的时间；
增量和完全的区别在哪？ 完全检查点一致性，Buffer_cache中的所有脏块，立刻马上全部写入磁盘，对磁盘IO压力山大；
而增量检查点的触发条件是，切换日志组，可能几个小时就切换一次；
增量的检查点做了哪些操作，第一，找到现在的SCN号，做一条红线，将SCN小的所有脏块，记录一下，放到Buffer_cache的脏块列表中（已数据对象为间隔的脏列表中，所以移动整理消耗不会太大），每隔3S时间，就去检查一下是不是有脏块写入数据文件了，写入了打个勾，红线越来越退后，直到没有这个红线，工作完成，只是记录，不主动触发写进程，实例崩溃也会找最近的增量检查点没有必要找完全检查点了；
2.buffer_cache空间不够，新的查询数据块在Buffer_cache中寻找空闲的数据块少，不够，触发写进程，空出内存；
3.脏块太多，溢出，空闲块太少
SQL> select kvittag,kvitval,kvitdsc from x$kvit where kvittag in('kcbldq','kcbfsp');
KVITTAG KVITVAL KVITDSC
---------- ------- ------------------------------------------------------------
kcbldq 25 large dirty queue if kcbclw reaches this ---如果脏块数量的百分比达到了25%，就会触发DBWN写进程
kcbfsp 40 Max percentage of LRU list foreground can scan for free---SERVER PROCESS进程拿着物理块，扫描了百分之40的LRU链还是没找到足够的空闲块，DBWR触发
4.dbwr规定内的间隔时间 3S
5.RAC节点释放空间
6.表空间OFFLINE.READ ONLY,热备份begin backup；
7表的DROP,TRUNCATE的操作都会触发DBWN进程，脏块写入数据文件
