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进程，脏块写入数据文件