Oracle技术服务|系统集成|技术开发

 找回密码
 立即注册

QQ登录

只需一步,快速开始

查看: 6407|回复: 17

[讨论] redo的inactive状态和active状态的区别

[复制链接]

7

主题

0

好友

121

积分

注册会员

Rank: 2

发表于 2013-12-25 15:47:27 |显示全部楼层
redo的inactive状态和active状态的区别

关于redo的inactive状态和active状态的区别,我在群里做了提问,也有了相关讨论,但我还是有疑惑,特发到论坛中。

下面是QQ群中的讨论
+++++++++++++++++++++++++++++++++++++++++++
+++++++++++++++++++++++++++++++++++++++++++
北国风光-河北(850447997) 13:50:47
重做日志文件组的inactive和active状态所代表的含义一直很模糊,
active表示相对应的数据库缓冲区的脏数据还没有进入数据文件
inactive表示相对应的数据库缓冲区的脏数据已经写入到数据文件了
active状态或inactive状态跟是否已经完成归档没有任何关系
我上面的理解正确吗?

sunshine-北京(1561416409) 14:02:21
不正确

北国风光-河北(850447997) 14:03:28
给解释下,谢谢

sunshine-北京(1561416409) 14:04:29
inactive已经归档,可以覆盖
active redo使用完毕,但未归档
current redo正在使用

北国风光-河北(850447997) 14:05:19
和脏数据是否写入数据文件是没有关系的了?

sunshine-北京(1561416409) 14:05:37
那是buffer里的事情

北国风光-河北(850447997) 14:10:20
我之前也是认为active或inactive的状态主要取决于是否完成归档,但好像有一本书上是讲redo的状态要取决于脏数据是否写入数据文件。所以我懵了。
这次谢谢sunshine的解释

sunshine-北京(1561416409) 14:11:08
太深奥了,解释不了

sunshine-北京(1561416409) 14:11:29
我记得有个是日志先写入原则

北国风光-河北(850447997) 14:12:04
如果是在unarchive模式下,inactive 和active的状态是怎么样的?

sunshine-北京(1561416409) 14:12:04
所以redo的这个状态和脏块写入不写入数据文件没必要关联,我是这样认为的
sunshine-北京(1561416409) 14:12:17
试试咯

lmalds_北京(1078924319) 14:19:20
inactive代表恢复时不再需要此日志文件;active说明如果此时实例down掉,还得需要此日志文件进行实例恢复;
当日志切换时,触发检查点,CKPT进程会把database buffer cache中的“dirty list”中的块写到磁盘,写完active日志文件中涉及的数据块后,日志文件状态就变为inactive,因此这时即使数据库down掉,也不再需要这个日志文件进行实例恢复(它里边的数据已经写到磁盘)。我是这么理解的,不知道是否正确

北国风光-河北(850447997) 14:20:42
@lmalds_北京 我跟你的理解类似,如果按照这种观点,sunshine的说法就是错的了

lmalds_北京(1078924319) 14:22:22
看看官方文档吧,记得好像是这么解释的。跟是否完成归档没关系吧?因为归档是瞬间完成的事,那为什么我们查询v$log中,总能看到active的状态?

北国风光-河北(850447997) 14:23:17
@lmalds_北京 我跟你的观点是一致的

lmalds_北京(1078924319) 14:24:50
但是往往归档完成了,dirty list中的块也写完了。所以active变成inactive,现象上看除了dirty list意写完,还有就是归档也完成了。这两步几乎同步。

北国风光-河北(850447997) 14:32:02
@sunshine-北京 @lmalds_北京
我倾向于inactive或active的状态取决于脏块是否写入数据文件,跟是否完成归档没有关系,有一本书上这样写的,但我又不敢尽信书


sunshine-北京(1561416409) 14:38:11
不认同
sunshine-北京(1561416409) 14:38:35
日志先写入,不一定脏块就写入数据文件了
sunshine-北京(1561416409) 14:39:06
如果不先写入日志,要这干嘛

北国风光-河北(850447997) 14:41:07
我也在网上看到其他人说过redo的inactive或active状态主要跟是否归档有关系,但我也又不完全赞同,所以一直搞不清inactive或active状态的区别


sunshine-北京(1561416409) 14:42:06
(按照你的截图)这不就是日志先写入的原则吗

fornext_深圳(540587562) 14:44:34
active的在实例恢复的时候要读取的吧。

北国风光-河北(850447997) 14:44:57
@sunshine-北京 我太理解你说的意思,
书上的说法是这样,如果是active状态,那就代表有相对应的脏块还没有被DBWR写入数据文件,这时可能已经完成归档,也可能还没有完成归档

sunshine-北京(1561416409) 14:45:19
我绕晕了,不讨论了

北国风光-河北(850447997) 14:45:57
恢复的时候确是需要active的,我主要是不理解在什么情况下active才会转为inactive

fornext_深圳(540587562) 14:46:10
我记得删除active的日志时会提示不能删除,因为需要实例恢复时要用到。
fornext_深圳(540587562) 14:46:49
我也不知道,呵呵。
fornext_深圳(540587562) 14:46:59
打酱油。。。。

北国风光-河北(850447997) 14:48:36
@fornext_深圳 ,对的,确是不能删除。
我主要是不理解这个active状态的redo在什么情况下才会变为inactive,是完成归档了就变为inactive,还是相对应的脏块写入数据文件了就变为inactive?

lmalds_北京(1078924319) 14:49:25
做个实验:
查询v$log和v$archivelog中max sequence#.
然后alter system switch logfile;
再次查询v$log和max(sequence#) from v$archivelog.
看看归档已经完成,但是状态是否有active的。

多情剑客 广州(962602626) 14:49:29
前者
多情剑客 广州(962602626) 14:49:48
redo的产生早于数据写入

张狂-南京(429113084) 14:59:51
active的日志是实例恢复要用到的,实例恢复用的在线日志吧,不用归档日志
张狂-南京(429113084) 15:03:15
所以active和归不归档应该没关系
+++++++++++++++++++++++++++++++++++++++++++
+++++++++++++++++++++++++++++++++++++++++++



我的一点看法
关于redo的inactive和active状态的区别,书上的和网上的有两种观点,
一种观点是:redo的inactive和active状态主要取决于是否完成归档,如果是inactive状态这时就表示已经完成了归档,这个重做日志可以被覆盖重写,如果是active状态,那么就代表还没有完成归档,这时是不可以进行日志切换的。
另一种观点是:redo的inactive和active状态跟是否完成归档没有太大关系,主要取决于相对应的脏块是否写入数据文件,如果相对应的脏块已经被DBWR写入数据文件,那么redo由active变为inactive。另外,在active状态下redo,可能已经完成了归档(仍在等待脏块的写入,所以还未变为inactive),也可能还没有完成归档。

关于lmalds所说的做个实验,似乎这个坏境不是太好模拟,因为redo所对应的脏块可能先于归档而完成,也可能在归档完成后仍没完成。

结论:关于redo的inactive和active状态的区别,有疑惑的人似乎还很多,特整理成帖子,以备大家查阅。

我赞成上面所说的第二种观点,即:redo的inactive和active状态主要取决于相对应的脏块是否已经写入数据文件,跟是否完成归档没有必然关系,由于redo相对应的脏块的写入和归档的写入几乎同步完成,所以才有相应的观点分歧。
希望大家继续讨论。

本帖子中包含更多资源

您需要 登录 才可以下载或查看,没有帐号?立即注册

回复

使用道具 举报

7

主题

0

好友

121

积分

注册会员

Rank: 2

发表于 2013-12-25 16:03:19 |显示全部楼层
我再做下补充,我上面说了我的观点,即:redo的inactive和active状态主要取决于相对应的脏块是否已经写入数据文件,跟是否完成归档没有必然关系。
这样的话就意味着如果redo中相对应的脏块一直没有写入到数据文件,那就一直不能从active变为inactive,也就一直不能进行日志切换了。
回复

使用道具 举报

7

主题

0

好友

121

积分

注册会员

Rank: 2

发表于 2013-12-25 16:58:09 |显示全部楼层
我再做下补充,张狂在QQ群里对这个问题发表了看法,为了方便大家更好的探讨这个问题,我特意整理在这里:


张狂-南京(429113084) 16:13:14
个人认为做实验先切换日志文件,这时候肯定有active记录。然后再做checkpoint,这时候应该就没active了
张狂-南京(429113084) 16:13:44
刚做的实验也是这样的,电脑上不了网,不发结果了

北国风光-河北(850447997) 16:15:57
我同意你的观点
回复

使用道具 举报

71

主题

2

好友

1022

积分

版主

Rank: 7Rank: 7Rank: 7

发表于 2013-12-26 08:56:11 来自手机 |显示全部楼层
大家的讨论精辟入理。
我个人同张狂持相同的见解,即active与dirty buffer有关,与是否归档无关。我记得存在dirty buffer未写出但日志已归档的情形,曾碰到过alter system switch logflie无法将active转换为inactive的情形,在此时,alter system checkpoint 实施检查点进程,状态发生变化。也就是当前日志组中包含的buffer cache 中的dirty buffer已写入数据文件,实例恢复不再需要。
回复

使用道具 举报

71

主题

2

好友

1022

积分

版主

Rank: 7Rank: 7Rank: 7

发表于 2013-12-26 08:58:31 来自手机 |显示全部楼层
数据库是否处于归档模式,不影响日志组之间几种状态之间的变化。
回复

使用道具 举报

71

主题

2

好友

1022

积分

版主

Rank: 7Rank: 7Rank: 7

发表于 2013-12-26 09:00:42 来自手机 |显示全部楼层
北国风光 发表于 2013-12-25 16:03
我再做下补充,我上面说了我的观点,即:redo的inactive和active状态主要取决于相对应的脏块是否已经写入数 ...

日志可以进行切换,只不过状态不会发生变化。
回复

使用道具 举报

0

主题

0

好友

22

积分

新手上路

Rank: 1

发表于 2013-12-26 10:26:43 |显示全部楼层
日志切换需要做增量检查点,增量检查点是把fast_start_mttr_target之内的脏块写入数据文件,之外的并没有完全把脏块写入数据文件,
增量检查点的时候,不会记录增量检查点到数据文件,但是会记录增量检查点到控制文件,
数据库恢复的时候就是从控制文件的增量检查点开始恢复的,之后应用redo,同步数据文件
查看alert_orcl.log会发现
MTTR advisory is disabled because FAST_START_MTTR_TARGET is not set
我这里并没有设置FAST_START_MTTR_TARGET,一般建议设置FAST_START_MTTR_TARGET,
回复

使用道具 举报

0

主题

0

好友

18

积分

新手上路

Rank: 1

发表于 2013-12-26 10:57:34 |显示全部楼层
取决日志的RBA指针到哪里了。
回复

使用道具 举报

1

主题

0

好友

87

积分

注册会员

Rank: 2

发表于 2013-12-26 14:52:23 |显示全部楼层
看了大家关于redo的inactive和active状态 的讨论,我也觉得inactive与active状态的区别在于DBWn是否完成脏块的写入。
但是又看到有人说,inactive表示这个redolog在实例恢复时是 不需要的,active则表示需要。

active在实例恢复时是需要的,这一点我也造成。
inactive在实例恢复时是不需要的,这一点我觉得未必。

现在假定 “inactive在实例恢复时是不需要的”的观点是成立的,那设想一下以下情况:
开session 1:
begin
insert into testtab values(99);
--不提交也不回滚

开session 2:
begin
insert into testtab values(88);
commit;
alter system checkpoint;

如果session 1 一直不断开连接,且既不提交也不回滚,那么,为了保证“inactive在实例恢复时是不需要的”的观点成立,从session 1 begin insert 操作之后,数据库中的redolog group的在切换之后,一直都保持在 active 状态,因为session 2中的checkpoint已经将session 1 中的修改写到了数据文件中,所以实例恢复必须用到session 1 操作所对应的redolog 文件。

很显然,通过“inactive在实例恢复时是不需要的”推导出来的结论是错的。

另外,实例恢复是可能会用到已经归档的redolog的(非归档模式的话,就直接被覆盖了)。


总结:
redo的inactive与active状态的区别在于DBWn是否完成脏块的写入。
redo的inactive与active与实例恢复时是否需要此redo没有必然的联系。
回复

使用道具 举报

7

主题

0

好友

121

积分

注册会员

Rank: 2

发表于 2013-12-27 08:44:12 |显示全部楼层
Leshami 发表于 2013-12-26 09:00
日志可以进行切换,只不过状态不会发生变化。

如果redo中相对应的脏块一直没有写入到数据文件,那就一直不能从active变为inactive,也就一直不能进行日志切换了

我这里所说的不能进行日志切换,是指这个active状态的redo不可以进行覆盖重写。如果只有两个重做日志文件组,一个是current,一个是active,那么如果active状态的redo相对应的脏块还未写入数据文件,这时就不会变为inactive状态,也就不能进行日志切换。
沙弥兄,这样理解正确吗?
回复

使用道具 举报

您需要登录后才可以回帖 登录 | 立即注册

QQ|手机版|DB Support 技术联盟 ( 粤ICP备13057501号-1 )

GMT+8, 2018-4-23 13:20 , Processed in 0.194546 second(s), 21 queries .

Powered by Discuz! X2.5

© 2001-2012 Comsenz Inc.

回顶部