日志切换时的检查点

2019独角兽企业重金招聘Python工程师标准>>>

做一次日志切换

ALTER SYSTEM SWITCH LOGFILE;

-- 然后看看alert里面的记录

Mon Aug 4 22:31:39 2008

Beginning log switch checkpoint up to RBA [0x9.2.10], SCN: 534450

Thread 1 advanced to log sequence 9

Current log# 2 seq# 9 mem# 0: /u/app/oracle/oradata/orcl/redo02.log

Mon Aug 4 22:35:58 2008

Completed checkpoint up to RBA [0x9.2.10], SCN: 534450

-- 我们能看到checkpoint是在过了一段时间（这里是4分钟）之后才完成的

-- 接着我们来看下V$DATAFILE_HEADER中的结果

NO STATUS TABLESPACE_NAME CUR_SCN RST_DT RST_SCN CKPT_DT CKPT_SCN CKPT_CNT

--- ------- -------- -------- --------- ---------

1 ONLINE SYSTEM 534770 2008-01-12 16:51:53 446075 2008-08-04 22:31:44 534450 67

2 ONLINE UNDOTBS1 534770 2008-01-12 16:51:53 446075 2008-08-04 22:31:44 534450 30

3 ONLINE SYSAUX 534770 2008-01-12 16:51:53 446075 2008-08-04 22:31:44 534450 67

4 ONLINE USERS 534770 2008-01-12 16:51:53 446075 2008-08-04 22:31:44 534450 66

5 ONLINE EXAMPLE 534770 2008-01-12 16:51:53 446075 2008-08-04 22:31:44 534450 26

-- 在这里我们能发现下V$DATAFILE_HEADER里面记录的SCN和日志切换发生的checkpoint的SCN是一样的，

-- 这就证明了日志切换是会更新数据文件头的，同时日志切换的checkpoint是一个级别比较低的操作，

-- 它不会立即完成，这也是出于性能上考虑的。

增量checkpoint查看

当前所知只有在LOG_checkpoint_TIMEOUT设置了非0值之后触发的增量checkpoint会在alert文件中有记录，其他条件触发的增量checkpoint都不会记录在alert文件中。

-- 下面是当LOG_checkpoint_TIMEOUT设置为1800s的时候所产生的增量checkpoint记录

Sun Aug 3 19:08:56 2008

Incremental checkpoint up to RBA [0x8.e17.0], current log tail at RBA [0x8.1056.0]

Sun Aug 3 19:39:00 2008

Incremental checkpoint up to RBA [0x8.1be0.0], current log tail at RBA [0x8.1c6e.0]

Sun Aug 3 20:09:04 2008

Incremental checkpoint up to RBA [0x8.2af5.0], current log tail at RBA [0x8.2b6a.0]

Sun Aug 3 20:39:07 2008

Incremental checkpoint up to RBA [0x8.3798.0], current log tail at RBA [0x8.3851.0]

Sun Aug 3 21:09:10 2008

Incremental checkpoint up to RBA [0x8.47b9.0], current log tail at RBA [0x8.48bb.0]

Sun Aug 3 21:39:14 2008

Incremental checkpoint up to RBA [0x8.548d.0], current log tail at RBA [0x8.5522.0]

Mon Aug 4 21:05:18 2008

top查看fast_start_mttr_target

通过查看V$INSTANCE_RECOVERY动态性能视图可以查看一些MTTR相关的信息。

SELECT TARGET_MTTR,ESTIMATED_MTTR,CKPT_BLOCK_WRITES,CKPT_BLOCK_WRITES FROM V$INSTANCE_RECOVERY

TARGET_MTTR

用户设置的参数FAST_START_MTTR_TARGET的值.

ESTIMATED_MTTR

根据目前脏块数目和日志块数目,评估的现在进行恢复所需要的时间.

CKPT_BLOCK_WRITES

检查点写完的块数目.

CKPT_BLOCK_WRITES

额外的因为检查点引起的数据库写入操作 （因为不必要的检查点的产生,设置一个非常小的系统恢复时间将会对性能产生负面影响,为了帮助管理员监测这个参数设置较小时对数据库的影响,这个视图显示了这个列）

转载于:https://my.oschina.net/u/3635497/blog/3059686