DBWN

 

导致DBWN 写有一下几点

check point occurs(检查点发生)

检查的点发生的太频繁,会导致DBWN 写的很频繁,DBWN写的时候要CPU ,内存,IO资源,写的时候占用的资源是非常大的。

 

dirty buffer reach  threshold  (脏缓冲区达到了一个临界值),脏数据块达到了一个临界值,那么DBWN为什么要写呢?,

(把数据缓冲区的脏数据块写到数据文件当中就意味着他已经保存了。那么数据缓冲区的脏数据块就允许其他的数据块来时使用。

把数据块读到数据缓冲区中修改了,比如改的人很多,一下子就把数据缓冲区给占满了。别人就没有空间可用了。那么oracle就赶紧把你

修保存改下来,也就也就是用DBWN来写,保存好了,那么数据缓冲区里的数据块就可以被重新的使用。

所以但数据缓冲区的脏数据块达到一定的临界值的话,DBWN就会赶紧的去写。就把空间腾出来给新的数据块来使用)

 

从数据缓冲区写到数据文件。

 

there are no free buffers

 

time out occurs(超时)

oracle 8i 的时候提到 超时每隔3秒。

 

RAC PING request is made(以后会讲)

 

tablespace offline

tablespace read only

table drop of truncate(表被DROP了那么表中的数据就没有用了,就可以释放了)

tablespace begin backup

以上都会导致DBWN写(写有两种状态一种是写,一种是释放)

 

LGWR

LGWR

redo log buffer 里的日志条目经过LGWR 写到 redo log files

什么的时候写:

at commit (提交)

when one-third full(当三分之一满的时候)(日志条目占了日志缓冲区的三分之一满的时候)

when there is 1m of redo

每隔三秒的时候就要写

before DBWN writes

 

问题?检查点发生的时候会导致LGWR写么?

不会,检查点发生的时候不会直接的导致LGWR写,但是会间接的导致LGWR写,因为检查点工作的时候,DBWN要工作,在DBWN工作之前LGWR要先写一下

G

redo log buffer 里的日志条目写入 redo log file

 SMON

系统监视,监视实例

主要做 instance recovery 实例恢复

假如程序在运行当中不是正常关闭时断电了。会导致实例的奔溃,还有由于软件本身的BUG,导致实例的崩溃,由不是实例于正常的关闭所以

实例里保留了一些残余的信息,需要把它清理一下,所以下一次启动的时候oracle 需要做实例恢复,下面是实例恢复。

1rolls forward 前滚

 changes in online

 redo log file(把redo log 里所做的记录重做一遍)

2opens database

 for user access

3rolls 回滚(没有完成的就回滚)

 uncommitted

 transaction

4整合空间

 PMON

监视进程

进程失败之后 整理

1 rolling back the transaction (回滚事物)

2 releasing locks(释放锁)

3 releasing others resources(释放资源指的是,server 进程 PGA)

4 releasing dead dispatchers

 CKPT

oracle 的单独的进程,他的工作就是发个信号,

1 DBWN一个写的信号

2 check point 信息来更新数据文件头

3 check point 信息来更新控制文件

ARCN(归档进程)只有数据库运行在归档模式下才会启动该进程