recover过程只在redo日志中记录uncommitted的回滚过程?

[复制链接]
查看11 | 回复9 | 2005-10-30 17:05:33 | 显示全部楼层 |阅读模式
也请参照:http://www.itpub.net/showthread. ... 19&goto=newpost

我的执行过程:
1.备份操作表所在的数据文件[/COLOR]
SQL> alter tablespace users2 begin backup;
Tablespace altered.
备份数据文件......
SQL> alter tablespace users2 end backup;
Tablespace altered.

2.切换日志,在group2中记录3条insert操作,只提交第1条。[/COLOR]
SQL> alter system switch logfile;
System altered.
SQL> select * from v$log;
GROUP#THREAD#SEQUENCE#BYTESMEMBERS ARC STATUS
---------- ---------- ---------- ---------- ---------- --- ----------------
FIRST_CHANGE# FIRST_TIM
------------- ---------
1
1
7104857600
2 YES ACTIVE
3887713 10-JUN-04
2
1
8104857600
2 NOCURRENT
3888820 10-JUN-04
3
1
6104857600
2 YES INACTIVE
3855055 10-JUN-04

SQL> insert into donny.d values(1);
1 row created.
SQL> commit;
Commit complete.
SQL> insert into donny.d values(2);
1 row created.
SQL> insert into donny.d values(3);
1 row created.
3.模拟崩溃,然后restore and recover。可以发现恢复过程记录在group 3中[/COLOR]
SQL> shutdown abort;
ORACLE instance shut down.
restore backuped datafile...
SQL> startup
ORACLE instance started.
Total System Global Area131144544 bytes
Fixed Size
453472 bytes
Variable Size
104857600 bytes
Database Buffers 25165824 bytes
Redo Buffers
667648 bytes
Database mounted.
Database opened.
SQL> select * from v$log;
GROUP#THREAD#SEQUENCE#BYTESMEMBERS ARC STATUS
---------- ---------- ---------- ---------- ---------- --- ----------------
FIRST_CHANGE# FIRST_TIM
------------- ---------
1
1
7104857600
2 YES INACTIVE
3887713 10-JUN-04
2
1
8104857600
2 YES INACTIVE
3888820 10-JUN-04
3
1
9104857600
2 NOCURRENT
3908853 10-JUN-04

SQL> select * from donny.d;
ID
----------
1
SQL>

4.Logmnr logfile group 2(崩溃前的日志)[/COLOR]
SCN
SQL Redo
3888825
set transaction read write;
3888825
insert into "DONNY"."D"("ID&quot

values ('1');
3888827
commit;
3888830
set transaction read write;
3888830
insert into "DONNY"."D"("ID&quot

values ('2');(没有提交,可是3888832的commit;代表什么?)[/COLOR]
3888831
set transaction read write;
3888831
Unsupported
3888831
Unsupported
3888832
commit;
....
3888851
insert into "DONNY"."D"("ID&quot

values ('3'); (最后一条,没有提交)

5.Logmnr logfile group 3(记录恢复过程)[/COLOR]
SCN
SQL Redo
........(全是对回滚段信息的更新,实际操作了什么?)[/COLOR]
3908856
update "SYS"."UNDO$" set "NAME" = '_SYSSMU1$', "USER#" = '1', "FILE#" = '2', "BLOCK#" = '9', "SCNBAS" = '3888842', "SCNWRP" = '0', "XACTSQN" = '1979', "UNDOSQN" = '142', "INST#" = '0', "STATUS$" = '2', "TS#" = '1', "SPARE1" = '1' where "NAME" = '_SYSSMU1$' and "USER#" = '1' and "FILE#" = '2' and "BLOCK#" = '9' and "SCNBAS" = '3867703' and "SCNWRP" = '0' and "XACTSQN" = '1978' and "UNDOSQN" = '142' and "INST#" = '0' and "STATUS$" = '3' and "TS#" = '1' and "SPARE1" = '1' and ROWID = 'AAAAAPAABAAAABqAAB';
3908857
commit;
......
3908906
set transaction read write;
3908906
update "SYS"."UNDO$" set "NAME" = '_SYSSMU10$', "USER#" = '1', "FILE#" = '2', "BLOCK#" = '153', "SCNBAS" = '3888840', "SCNWRP" = '0', "XACTSQN" = '1920', "UNDOSQN" = '94', "INST#" = '0', "STATUS$" = '3', "TS#" = '1', "SPARE1" = '1' where "NAME" = '_SYSSMU10$' and "USER#" = '1' and "FILE#" = '2' and "BLOCK#" = '153' and "SCNBAS" = '3888840' and "SCNWRP" = '0' and "XACTSQN" = '1920' and "UNDOSQN" = '94' and "INST#" = '0' and "STATUS$" = '2' and "TS#" = '1' and "SPARE1" = '1' and ROWID = 'AAAAAPAABAAAABqAAK';
3908907
commit;
3908908
delete from "DONNY"."D" where ROWID = 'AAAH05AAOAAABDcAAB';(只有这两条针对没有提交的事务的回滚操作)[/COLOR]
3908908
delete from "DONNY"."D" where ROWID = 'AAAH05AAOAAABDcAAC';
3908909
commit;
......
3908924
update "SYS"."LOB$" set "RETENTION" = '10800' where "OBJ#" = '173' and "INTCOL#" = '5' and "RETENTION" = '10800' and ROWID = 'AAAAACAABAAAAAjAAA';
......
update "SYS"."LOB$" set...这是什么操作?[/COLOR]
我的问题:
1.recover是先前滚,后回滚。但是为什么第5步记录恢复过程的日志中没有对已经提交的第一条插入语句的前滚记录呢,而只是回滚了没有提交的2、3条语句。
2.第4步中,第2条插入语句是没有提交的,那么3888832的commit;代表什么?
3.第5步中,记录恢复过程的日志中,开始全是对回滚段信息的更新,实际操作了什么?
4.第5步中,oracle是根据什么知道要回滚这两条的?我可以查找到吗?
5.第5步中,最后的update "SYS"."LOB$" set...这是什么操作?
非常感谢能把这么长的帖子看完,如果能解决我的疑问,就在感谢一次!


回复

使用道具 举报

千问 | 2005-10-30 17:05:33 | 显示全部楼层
加油!贴子虽长,但是很好理解的。


回复

使用道具 举报

千问 | 2005-10-30 17:05:33 | 显示全部楼层
新的一天了,希望我的问题能得到解决。
回复

使用道具 举报

千问 | 2005-10-30 17:05:33 | 显示全部楼层



大家周末的时候,是在无聊的时候看看我的贴子吧!
回复

使用道具 举报

千问 | 2005-10-30 17:05:33 | 显示全部楼层
1.recover是先前滚,后回滚。但是为什么第5步记录恢复过程的日志中没有对已经提交的第一条插入语句的前滚记录呢,而只是回滚了没有提交的2、3条语句
前滚的过程中,数据库并没有打开,是不会产生日志的,回滚是在数据库打开之后进行的,因为回滚需要以数据库逻辑处理方式读写 回滚段 数据文件,需要判断哪些事务要回滚,而前滚就不用去对数据块中数据做逻辑判断,只要根据日志中信息进行物理的更改就可以了
所以2/3 的回滚记录了,而1没有,因为不需要回滚

2.第4步中,第2条插入语句是没有提交的,那么3888832的commit;代表什么?
commit 是去修改回滚段头的事务表状态,但是实际上她对应了自己相关的dml ,位于某条语句后面的commit 并不代表就是提交的这条语句啊

3.第5步中,记录恢复过程的日志中,开始全是对回滚段信息的更新,实际操作了什么?
数据库打开前是先前滚,再统一把没有提交的事务回滚,实际就是做回滚操作啊,对 undo 的操作就是更改 回滚段头的事务表

4.第5步中,oracle是根据什么知道要回滚这两条的?我可以查找到吗?

通过回滚段事务表信息,也就是回滚段头的信息,也就是通常数据库打开的时候的 v$transaction 中的记录
5.第5步中,最后的update "SYS"."LOB$" set...这是什么操作?
系统自己的递归操作,运行的数据库总会产生大量的递归操作的
回复

使用道具 举报

千问 | 2005-10-30 17:05:33 | 显示全部楼层



恩,有一个初步的理解了。下一步对每个问题在深入研究一下。
对于第一个问题,我印象中好像:
5.Logmnr logfile group 3(记录恢复过程) 的sql_redo内容里有alter database open的日志的,而且是在回滚之后。
但是记不清楚了,也许跟其他的信息混了,手头又没有数据库。由于心急,先贴出来。


回复

使用道具 举报

千问 | 2005-10-30 17:05:33 | 显示全部楼层
最初由 grassbell 发布
[B]


恩,有一个初步的理解了。下一步对每个问题在深入研究一下。
对于第一个问题,我印象中好像:
5.Logmnr logfile group 3(记录恢复过程) 的sql_redo内容里有alter database open的日志的,而且是在回滚之后。
但是记不清楚了,也许跟其他的信息混了,手头又没有数据库。由于心急,先贴出来。

[/B]

不管结果怎样都是合理的
前滚再回滚,都完成之后数据库才真正地完全地 open 了
数据库打开是一个复杂的过程
你要把打开看做一个时间点还是一个过程 ,不同的看法描述起来就不一样
回复

使用道具 举报

千问 | 2005-10-30 17:05:33 | 显示全部楼层
是否可以说recover的时候前滚是不会产生日志的,但是后滚回产生日志
回复

使用道具 举报

千问 | 2005-10-30 17:05:33 | 显示全部楼层
最初由 grassbell 发布
[B]是否可以说recover的时候前滚是不会产生日志的,但是后滚回产生日志 [/B]

是的,因为 recover 的过程中根本就可以没有日志文件,又如何来产生日志?如果recover要产生日志,那这些日志不是又被归档了, 又要被应用?那不是产生一个死循环了!
回复

使用道具 举报

千问 | 2005-10-30 17:05:33 | 显示全部楼层
楼主,借帖子问下,是否验证过shutdown immediate的redolog记录情况,最近发现shutdown immediate或者事务异常终止时redolog中没有记录相应未提交事务的回滚记录?
回复

使用道具 举报

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

本版积分规则

主题

0

回帖

4882万

积分

论坛元老

Rank: 8Rank: 8

积分
48824836
热门排行