关于redo和undo的初识

本文涉及的产品
日志服务 SLS,月写入数据量 50GB 1个月
简介: oracle 的日志分3类:  警告日志-=Alert log files ;  跟踪日志--Trace files用户和进程);重做日志--redo log 录数据库的更改)。

oracle 的日志分3类:  警告日志-=Alert log files ;  跟踪日志--Trace files用户和进程);重做日志--redo log 录数据库的更改)。


redo log file 重做日志文件,包括:归档(archive)重做日志文件---------归档重做日志,简称归档日志,指当条件满足时,Oracle将在线重做日志以文件形式保存到硬盘(持久化)

                                                               在线(online)重做日志文件 -------又称联机重做日志,指Oracle以SQL脚本的形式实时记录数据库的数据更新,换句话说,实时保存已执行的SQL脚本到在线日志文件中(按特定的格式)。

Oracle 11g默认对于每个数据库实例,建立3个在线日志组,每组一个日志文件,文件名称为REDO01.LOG,REDO02.LOG和REDO03.LOG。(用户可以通过视图操作添加/修改/删除日志组和日志文件来自定义在线重做日志)
每组内的日志文件的内容完全相同,且保存在不同的位置,用于磁盘日志镜像,以做多次备份提高安全性。默认情况这3组通常只有一组处于活动状态,不断地同步写入已操作的脚本,当日志文件写满时(达到指定的空间配额),如果当前数据库处于归档模式,则将在线日志归档到硬盘,成为归档日志;若当前数据库处于非归档模式,则不进行归档操作,而当前在线日志的内容会被下一次重新写入覆盖而无法保存。因此,通常数据库在运行时,是处于归档模式下的,以保存数据更新的日志。
当前归档日志组写满后,Oracle会切换到下一日志组,继续写入,就这样循环切换;当处于归档模式下,切换至原已写满的日志组,若该日志组归档完毕则覆盖写入,若没有则只能使用日志缓冲区,等待归档完毕之后才能覆盖写入。当然,处于非归档模式下是直接覆盖写入的。

Oracle提供了2个视图用于维护在线重做日志:V$LOG 和 V$LOGFILE,我们可以通过这两个视图查看和修改在线日志。 

关于V$LOG视图的详细属性字段可Oracle 11g的官方文档:http://download.oracle.com/docs/cd/B28359_01/server.111/b28320/dynviews_2029.htm
关于V$LOGFILE视图的详细属性字段可Oracle 11g的官方文档:
http://download.oracle.com/docs/cd/B28359_01/server.111/b28320/dynviews_2031.htm

官方文档还是最给力的呀,不要忽视!!
过v$logfile视图查询在线日志文件信息: 
SQL> SELECT * FROM v$logfile ORDER BY group#; 

GROUP# TATUS TYPE MEMBER IS_RECOVERY_DEST_FILE

1 ONLINE E:\APP\ADMINISTRATOR\ORADATA\ORCL\REDO01.LOG NO
2 ONLINE E:\APP\ADMINISTRATOR\ORADATA\ORCL\REDO02.LOG NO
3 ONLINE E:\APP\ADMINISTRATOR\ORADATA\ORCL\REDO03.LOG NO
通过v$log视图查询在线日志的总体信息:
SQL> SELECT * FROM v$log;

GROUP# THREAD# SEQUENCE# BYTES MEMBERS ARCHIVED STATUS FIRST_CHANGE# FIRST_TIME 
1 1 49 52428800 1 NO CURRENT 1466615 07-1月 -11
2 1 47 52428800 1 YES INACTIVE 1434125 06-1月 -11
3 1 48 52428800 1 YES INACTIVE 1460403 07-1月 -11
当然,还可以通过ALTER DATABASE ADD 、delete等命令增加/修改/删除在线日志或日志组,具体操作可查看http://blog.csdn.net/robinson_0612/archive/2010/07/20/5749556.aspx


重做日志的简单原理:在数据更新操作commit前,将更改的SQL脚本写入重做日志。主要用于数据库的增量备份和增量恢复。 
       重做日志直接对应于硬盘的重做日志文件(有在线和归档二种),重做日志文件以组(Group)的形式组织,一个重做日志组包含一个或者多个日志文件。

如果数据库所在主机掉电,导致实例失败,Oracle 会使用在线重做日志将系统恰好恢复到掉电之前的那个时间点。如果磁盘驱动器出现故障(这是一个介质失败),Oracle 会使用归档重做日志以及在线重日志将该驱动器上的数据备份恢复到适当的时间点。另外,如果你“无意地”截除了一个表,或者删除了某些重要的信息,然后提交了这个操作,那么可以恢复受影响数据的一个备份,并使用在线和归档重做日志文件把它恢复到这个“意外”发生前的时间点。

每个Oracle 数据库都至少有两个在线重做日志组,每个组中至少有一个成员(重做日志文件)。这些在线重做日志组以循环方式使用。Oracle 会写组1 中的日志文件,等写到组1 中文件的最后时,将切换到日志文件组2,开始写这个组中的文件。等到把日志文件组2 写满时,会再次切换回日志文件组1(假设只有两个重做日志文件组;如果有3 个重做日志文件组,Oracle 当然会继续写第3 个组)。


归档重做日志文件实际上就是已填满的“旧”在线重做日志文件的副本。系统将日志文件填满时,ARCH进程会在另一个位置建立在线重做日志文件的一个副本,也可以在本地和远程位置上建立多个另外的副本。如果由于磁盘驱动器损坏或者其他物理故障而导致失败,就会用这些归档重做日志文件来执行介质恢复。Oracle 拿到这些归档重做日志文件,并把它们应用于数据文件的备份,使这些数据文件能“赶上”数据库的其余部分。归档重做日志文件是数据库的事务历史。


要查看生成的redo 量相当简单,。我使用了SQL*Plus 的内置特性AUTOTRACE。不过AUTOTRACE 只能用于简单的DML,对其他操作就力所不能及了,例如,它无法查看一个存储过程调用做了什么。为此,我们需要访问两个动态性能视图:
V$MYSTAT,其中有会话的提交信息。
V$STATNAME,这个视图能告诉我们V$MYSTAT 中的每一行表示什么(所查看的统计名)。
因为我经常要做这种测量,所以使用了两个脚本,分别为mystat 和mystat2。mystat.sql 脚本把我感兴趣的统计初始值(如redo 大小)保存在一个SQL*Plus 变量中.

相关实践学习
日志服务之使用Nginx模式采集日志
本文介绍如何通过日志服务控制台创建Nginx模式的Logtail配置快速采集Nginx日志并进行多维度分析。
相关文章
|
存储 关系型数据库 MySQL
InnoDB存储引擎的redo log(重做日志)
InnoDB存储引擎的redo log(重做日志)
98 0
InnoDB存储引擎的redo log(重做日志)
|
存储 SQL 缓存
InnoDB之UNDO LOG介绍
undo log是InnoDB事务特性的重要组成部分。当对记录做增删改操作就会产生undo记录,undo记录会记录到单独的表空间中。 本文将从代码层面对undo log进行一个简单的介绍;主要从下面四个方面来介绍undo log:undo log组织形式与分配与记录,以及undo log的应用及其清理。从这四个方面出发,我们就可以基本了解undo log的整个生命周期。
697 1
|
存储 SQL 关系型数据库
redo日志和undo日志区别是什么?
redo日志和undo日志区别是什么?
|
AliSQL 关系型数据库 MySQL
Binlog In Redo
Introduce the feature which persists binlog into redo on RDS-8.0
385 0
Binlog In Redo
|
数据库
Undo日志文件的产生和使用
Undo 日志 比如A有200块钱, B有50 块钱,现在A要给B转100块” 。 (1)  开始事务 T1 (假设T1是个事务的内部编号) (2)  A余额 = A余额 -100 (3)  B余额 = B余额 + 100 (4)  提交事务 T1 会对此事务记录Undo的日志文件,记录下事务开始之前的他俩账号余额: [开始事务 T1] [事务T1, A原有余额,200] [事务T1, B原有余额,50]  如果事务执行到一半挂了,数据库重启以后我就根据undo的日志文件来恢复。
1245 0
|
关系型数据库 Oracle
|
Oracle 关系型数据库 数据库
|
存储 Oracle 关系型数据库
|
存储 SQL 关系型数据库
事务实现,redo,undo,锁
事务(Transaction)是数据库区别于文件系统的重要特性之一。在文件系统中,如果你正在写文件,但是操作系统突然崩溃了,这个文件就很有可能被破坏。当然,有一些机制可以把文件恢复到某个时间点。不过,如果需要保证两个文件同步,这些文件系统可能就显得无能为力了。
814 0