Chinaunix首页 | 论坛 | 博客
  • 博客访问: 643757
  • 博文数量: 70
  • 博客积分: 145
  • 博客等级: 入伍新兵
  • 技术积分: 1150
  • 用 户 组: 普通用户
  • 注册时间: 2012-10-11 08:15
个人简介

没有简介就是最好的简介

文章分类

全部博文(70)

文章存档

2020年(1)

2018年(2)

2017年(3)

2016年(11)

2015年(12)

2014年(16)

2013年(19)

2012年(6)

我的朋友

分类: Oracle

2014-04-10 14:48:13

重做日志文件

redo log file对于oracle数据库至关重要。它们是数据库的事务日志。通常只用于恢复,也可用于以下工作。
1.1系统崩溃后的实例恢复
1.2通过备份恢复数据文件之后恢复介质
1.3备用数据库处理
1.4Input into “Streams,” a redo log mining process for information sharing (a fancy
way of saying replication)
重做日志文件的主要目的是恢复实例或者介质失败后的恢复,或者可以作为一种维护备用数据库的方法来完成故障恢复。如果数据库所在主机掉电,导致实例失败,oracle会使用在线重做日志将系统恢复到掉电前的那一刻。如果包含数据的磁盘出现故障,oracle可以使用归档的重做日志文件和在线重做日志文件将数据恢复到某一个时间点。如果你不小心删除了一个表或者一些重要的信息并且做了commit操作,你可以恢复一个备份让oracle使用在线重做日志和归档日志文件来恢复到你操作之前的时刻。
实际上,你在oracle里面的每一个操作都会被写入到online redo log里面。你在表中插入一行数据时最终的结果则会被写入online redo log。

在线重做日志
每个oracle数据库都至少有两个在线重做日志文件组。每个重做日志组包含一个或多个重做日志成员。每个日志组里面成员是相互镜像的。重做日志文件的大小是固定的并且以循环的方式进行使用。当日志组1写满时它会覆盖日志组2中的数据并且重新开始向日志组2中写数据,当2满时再重新切换至1进行覆盖重写。如果有多个日志组则以此类推。
 
从一个日志组切换到另外一个日志组的时候叫做日志切换。在一个设计不是很合理的数据库中日志切换的过程中会出现短暂停。因为重组日志文件是用来错误发生后来恢复数据的,所以我们要保证日志切换的时候即将覆盖的日志已经被写到磁盘中。如果oracle不能确定即将覆盖的日志是否已经写入到磁盘中,它就会停下来将日志组中的数据写入到磁盘,然后再进行覆盖。
数据库缓冲区缓存是临时存储数据块的地方。这是oracle SGA中的一个结构。读取块时,会存储在这个缓存中,这样以后就不必物理地重新读取它们。缓冲区缓存首先是一个性能调优设备,其目的是让非常慢的IO过程看上去快点。修改块时这些修改会在内存中完成。oracle并不是访问SGA中修改的所有块,并把它们写到磁盘上。相反,它只是把重做日志缓冲区中的内容写到在线重做日志文件中。只要修改的块还在缓冲区中,而不在磁盘上,数据库失败时我们就会需要该在线重做日志中的内容。如果这种情况发生,数据的操作就只存在于重做日志文件中,当数据库重新启动的时候,oracle就会重新恢复那些未提交的事务,重新修改数据块并提交。所以,如果重做日志文件中的数据没有写入磁盘之前是不能进行覆盖的。会话通常不将数据写入磁盘,会话将数据写入数据库缓冲区缓存中,由数据库写入器(DBWn)负责在随后将缓冲区写入磁盘。一个实例可能有多个数据库写入器,依次称为DBW0和DBW1等。在缓冲区缓存写入到磁盘时会建立检查点,建立检查点就是把脏块从缓冲区缓存写至磁盘。在日志切换时会建立检查点。在填满日志文件组1并切换到日志文件组2时,oracle就会启动一个检查点。此时,DBWn开始将日志文件组1所保护的所有脏块写至磁盘,在DBWn把该日志文件保护的所有块刷新输出之前,oracle不能重用这个日志文件。如果在这之前想使用日志文件,就会在alert日志中得到下面的消息:
...
Thread 1 cannot allocate new log, sequence 66
Checkpoint not complete
Current log# 2 seq# 65 mem# 0: /home/ora11gr2/app/ora11gr2/oradata/orcl/redo01.log
...
出现这个消息时,数据库中的处理会挂起,因为DBWn正忙于完成它的检查点。此时,oracle会尽可能地把处理能力都交给DBWn,希望它更快地完成。这是我们就要分配足够的在线重做日志文件,这样就不会在检查点完成之前视图重用日志。如果经常看到这个消息,说明DBA未能为应用分配足够多的在线重做日志文件,或者要对DBWn进行调优才能更高效的完成工作。

在设置在线重做日志文件的大小和数目时,应考虑下面的信息:
高峰负载:你可能希望系统不必等待对未完成的消息建立检查点,不要在高峰时遇到瓶颈,不能针对平均的小时吞吐量来确定重做日志文件大小,而要针对高峰处理来确定。例如每天生成24G的日志量,但是其中10G都是在9:00到11:00这一段时间生成的,就要把重做日志的大小调整到足以放下那两个小时高峰期间生成的日志。如果只是针对每小时1G来确定是不够的。
大量用户修改相同的块:如果大量用户都要修改相同的块,你可能希望重做日志文件很大。因为每个人都在修改同样的块,最好尽可能多地更新之后才将其写入到磁盘。每个日志切换都会导致一个检查点,所以你不可能希望频繁地切换日志。不过,这样一来又会影响恢复时间。
平均恢复时间:如果必须确保恢复尽可能快地完成,即便是大量用户要修改相同的块,也可能倾向于使用较小的重做日志文件。如果只处理一两个小的重做日志文件,而不是一个巨大的日志文件,则所需的恢复时间会比较短。由于重做日志文件小,往往会会过多的建立检查点,时间长了,整个系统会越来越慢,但是恢复所花的时间确实会更短,要减少恢复时间,除了使用小的重做日志文件外,还可以使用其他的数据库参数。

阅读(12955) | 评论(0) | 转发(0) |
给主人留下些什么吧!~~