谁知道如何在硬盘上合理放置重做日志文件

数据文件存储着用户 *** 作数据库的最后结果。而重做日志文件还保存着数据中间修改的过程。为此可以利用重做日志文件用来修复任何时刻的数据，只要这个重做日志文件完整。另外，用户在更新数据的时候，会同时更新重做日志文件。所以这个重做日志文件又跟数据库的性能息息相关。故无论从哪个角度出发，给重做日志以足够多的关注，都是值得的。笔者这里以在硬盘上合理放置重做日志文件这个角度，来谈谈管理重做日志文件的一些技巧。

一、将重做日志成员放到不同的硬盘上。

如果Oracle数据库采用的是归档模式，即当覆盖下一个重做日志文件的时候需要对目标重做日志文件进行归档，此时最好将重做日志成员放置到不同的硬盘中去。因为在日志切换的过程中，LGWR进程需要向重做日志文件保存数据，而ARCH进程则需要对重做日志文件成员进行归档。为此在日志切换的过程中，如果他们在同一个硬盘上的话，就会发生对重做日志成员争夺的现象，从而降低数据库的性能。为此最好将重做日志成员与归档的日志文件放到不同的硬盘上。如在归档模式下，有三个重做日志成员，同时也会有归档的日志文件。此时如果有多快硬盘的话，那么就可以将重做日志成员与归档的日志文件分开来存放。如此LGWR进程(向重做日志成员中写入信息)与ARCH进程(向归档日志文件中写入信息)就不会产生争夺重做日志成员的现象了。这主要是从提高数据库性能的角度出发。

二、将同一组的成员存放在不同的硬盘上。

如果存放重做日志文件的硬盘发生了故障，重做日志文件无法读取，此时后续的恢复工作就无法进行。即使有数据库备份的话，数据库也只能够恢复到备份的那一点。而不能够恢复到故障的那一点上。所以说，如果重做日志文件出现了损坏，那对于数据库恢复来说，是一种灾难性的后果。为此数据库管理员的一大任务就是保障重做日志文件的安全性。在Oracle数据库中，通过重做日志文件复用可以提高重做日志文件的安全性。

在讲这个技术之前，各位读者可以先来回顾一下磁盘阵列(RAID5)的技术。几块硬盘可以组成一个磁盘这列。这几块硬盘之间相互为镜像。当其中某块硬盘损坏的话，则仍然可以通过可用的硬盘来修复数据。不过当同时损坏两块硬盘(这个几率可能同中500万的几率相当)则硬盘中的数据将无法修复。其实重做日志复用也是类似的道理。在系统中可能有四个重做日志文件，其中两个文件为一组。同一个组内的日志文件互为镜像。当同一个组内的某个重做日志文件(在多路复用重做日志文件中将这个重做日志文件叫做成员)发生故障时，数据库仍然可以向另外一个没有问题的重做日志成员写入信息，并利用其来恢复数据库。可见其可以在很大程度上保障重做日志文件的安全性。但是其有一个前提，就是同一个组内的成员(重做日志文件)要保存在不同的硬盘上。如此的话，某块硬盘发生故障时，也不会影响另外一块硬盘上的重做日志成员，数据库仍然可以正常运行、正常恢复等等。所以，如果采用了多路复用重做日志的话，最好将同一组中的成员存放到不同的硬盘上，以提高重做日志文件的安全性。可见，笔者建议这么做，主要是从数据库的安全性上蔽简考虑。来源：考试大

另外需要注意的是，在同一个组内的组成员(其实就是保存在硬盘上的两个独立文件)大小必须一致。即每个重做日志文件组中的成员必须有相同的大小。否则的话，就不能够进行同步的日志切换，也无法相互为镜像。不过不同组之间的成员大小可以不相同。此时LGWR进程往重做日志文件中写信息的话，是以组为单位，宏肆裤即同时往同一个组内的各个成员写入信息。此时，如果将各个成员都放置在不同的硬盘中，就可以降低硬盘的I/O冲突，从而提高数据库的性能。所以说，将同一个组的成员放置在不同的硬盘上，不但可以提高重做日志文件的安全性，而且还可以提高数据库的性能。一举两得，是一笔比较划算的买卖。

三、不要将重做日志文件与比较活跃雹租的表空间放置在一起。

只要涉及到数据库的更新 *** 作，包括数据更新与数据库结构的更新，数据库系统都需要往重做日志成员中写入相关的信息。所以说，这个重做日志成员所在的硬盘，其读写 *** 作非常的频繁。如果其所在的硬盘，还存放在其他经常需要读取的数据，那么这个硬盘的I/O争用现象就会比较突出，从而降低数据库的性能。

为此不要将重做日志文件与比较活跃的表空间放置在一起。如在Oracle数据库中，索引表空间就是一个很活跃的表空间。在查询、更改时都需要用到这个表空间。为此最好不要将重做日志文件与索引表空间放置在同一个硬盘上，以避免硬盘I/O冲突而降低数据库的性能。只要有足够的硬盘，将他们放置在不同的硬盘上，就可以明显降低硬盘的冲突，从而提高数据库的性能。如可以将重做日志文件放置在一块单独的硬盘上，那么就可以最大限度的提高重做日志文件的吞吐量，从而提高数据库的性能。在一些大型的数据库应用上，硬件上的投资是有限的。或者说，想比性能的提升来说，硬件上的投资是廉价，或者说是优化数据库性能的一个捷径。另外对于一些事务性的数据库系统来说，撤销表空间也是一个很活跃的表空间，重做日志文件最好也不要跟撤销表空间放在同一块硬盘上。

四、数据文件与重做日志文件要放到不同的硬盘上。

一般情况下需要将数据文件与重做日志文件分开存放到不同的硬盘。这有两个原因。一方面是出于安全的考虑，即鸡蛋不要放在一个篮子里的原因。如果将他们放在同一块硬盘上，当这块硬盘损坏的话，重做日志文件与数据文件同时无法读取，那么数据库中的数据就无法读取，从而给企业带来巨大的损失。相反，如果将数据文件与重做日志文件放在不同的硬盘上，即使数据文件所在的硬盘发生了故障，数据库无法读取这块硬盘中的文件。那么数据库系统仍然可以通过另一块硬盘上的重做日志文件来恢复数据。所以说，将重组日志文件与数据文件保存在不同的硬盘上，可以提高数据库的安全性。

另一方面，也可以避免他们之间的磁盘争用。当数据库运行满足某个条件时， LGWR进程会像重做日志文件中写入记录，同时数据库也会像数据文件中写入信息。此时如果数据文件与重做日志文件都在同一块硬盘上，那么无疑他们之间就会发生一种硬盘资源的争用。要知道内存虽然没有硬盘那么大，但是硬盘与外界通信的口子很小，在这个口子上进程会发生I/O冲突。为此在同一时间同时更新同一块硬盘中的两个文件，那么就很容易造成竞争。也就是说，另一个进程需要等待这进程完成后才能够向硬盘中写入文件，这就好像车站买票。虽然票足够，但是售票的窗口就那么几个，必须要排队。如果这种竞争现象比较严重的话，那么就会在枕大程度上给数据库的性能带来负面的影响。所以说，将重做日志文件与数据文件存放在不同的硬盘上，以减少向数据文件写入数据库块和向重做日志文件写入重做记录之间出现的竞争。

可见，在合适的硬盘上存放重做日志文件，主要是提高数据库的安全和优化数据库的性能。说句实话，跟其他一些数据库优化的手段，特别是SQL优化相比，这多硬盘的策略，可以说是最简单的、也是最便捷的方式之一。即使数据库管理员不了解其幕后的真正原理，只要按照上面的建议做，也可以很明显的优化数据库的性能，同时也提高了数据库的安全。故对于数据库优化来说，这是笔者推荐的优选策略。

Oracle数据库能运行在 种模式下:归档模式(archivelog)和非归档模式(noarchivelog) 归档模式能提高Oracle数据库的可恢复性 生产数据库都应该运行在此模式下 归档模式应该和相应的备份策略相结合 只有归档模式没有相应的备份策略只会带来麻烦

检查归档模式命令

SQL>archive log list Database log mode No Archive Mode Automatic archival Disabled Archive destination USE_DB_RECOVERY_FILE_DEST Oldest online log sequence Current log sequence

设置归档模式

SQL>shutdown immediateDatabase closed Database di *** ounted ORACLE instance shut down SQL>startup mount ORACLE instance started Total System Global Area bytes Fixed Size bytes Variable Size bytes Database Buffers bytes Redo Buffers bytes Database mounted SQL>alter database archivelogDatabase altered SQL>alter database openDatabase altered SQL>archive log listDatabase log mode Archive Mode Automatic archival Enabled Archive destination USE_DB_RECOVERY_FILE_DEST Oldest online log sequence Next log sequence to archive Current log sequence

如果需要停止归档模式 使用 alter database noarchivelog 命令 Oracle g之前 你还需要修改初始化参数使数据库处于自动归档模式 在pfile/spfile中设置如下参数

log_archive_start = true

重启数据库此参数生效 此时数据库处于自动归档模式 也能在数据库启动过程中 手工执行

archive log start

使数据库启用自动归档 不过重启后数据库仍然处于手工归档模式 g使用db_recovery_file_dest来作为归档日志的存放地

SQL>show parameter db_recovery NAME TYPE VALUE db_recovery_file_dest string /home/oracle/ora g/flash_reco very_area/ db_recovery_file_dest_size big integer G

能修改db_recovery_file_dest_size参数的大小

alter system set db_recovery_file_dest_size=

一

重做日志文件把对数据文件的修改在写入悉卜数据文件之前记录下来 日志文件以一种循环的方式被写入信息 当一个日志组被写满时 回自动向另一个日志组写入 管理员可以手工切换当前日志组 alter system switch logfile 可以切换当前的日志组 当日志组发生切换时 oracle向新的重做日志组分配一个日志序列号 当存在大量的事务时必须调整重做日志睁胡穗文件的大小 以避免频繁的日志切换发生 重做日志文件被顺序的写在磁盘上 如果磁盘没有其他活动 I/O将会很快 应该把重做日志文件保存在单独的磁盘上 以获取良好的性能做配 尤其不要把经常处于活动状态的SYSTEM UNDOTBS SYSAUX的表空间或索引表空间文件保存到同一块磁盘上 因为只有在事务的请求被写到重做日志后 请求才能被完成 最大限度的提高重做日志的吞吐量是oracle性能优化首先考虑的因素 当发生重做日志切换而生成一个新的检查点时 DBWn就会写脏缓冲器块 这样会影响oracle的性能 可以通过fast_start_mttr_target初始化参数来调整检查点

每个数据库都有自己的联机重做日志组 一个联机重做日志组有多个重做日志成员 每个日志成员有单独的 *** 作系统文件 在一个rac配置（这种配置中单个数据库装有多个实例） 每个实例有一个联机重做日志线程 每个实例的lgwr进程都写到相同的联机重做日志文件 因此oracle必须跟踪数据库实例修改来自那个实例

当多路复用重做日志文件时 应该把一个组的成员保存在不同的磁盘上 以避免单点故障的发生 如果重做日志文件组的所有成员都无法写入数据 oracle将被挂起 Dba可以在创建数据库时创建多个联机重做日志文件的副本

对日志的 *** 作如下

a 创建新的重做日志组

Alter database add logfile

Group ( /ora /oradata/mydb /redo log

/ora /oradata/mdb /redo log ) size m

如果省略group子句 oracle分配一个有效的编号 如下

Alter database add logfile

b 添加新的组成员

alter database add logfile member

/ora /oradata/mydb /redo log to group (向第二组中添加新的成员)

c 重命名日志成员

在重命名日志组成员之前新的目标必须已经存在 Oracle的sql命令只是把控制文件中的内部指针指向新的日志文件 Dba需要用 *** 作系统命令来重命名此日志文件 步骤如下

．关闭数据库

．使用 *** 作系统命令重命名或移动日志文件

启动数据库实例（start mount） 重命名控制文件中的日志文        件成员 Alter database rename file         old_redo_file_name to new_redo_file_name

．打开数据库 alter database open

．备份控制文件

D．删除重做日志组

将要被删除的重做日志组不能是活动的日志组 Alter database drop logfile group 当重做日志文件被删除后 相关的 *** 作系统文件也被删除 相关的数据库控制文件也给更新

E．使用和删除重做日志组相同的方式 dba可以只删除一个非活动的重做日志组的成员

Alter database drop logfile member /ora /oradata/mydb /redo log

f 创建联机重做日志文件

当重做日志组成员遭到破坏时 可以删除并重新添加这个重做日志组或组成员

二

档案重做日志文件

它是联机重做日志文件的一个副本 Lgwr和arcn进程的故障都会引起数据库的挂起 只有当arcn进程把联机重做日志写到归档地后 才可以向此重做日志组成员写入数据

设置归档目的地

可以在参数初始化文件中的log_archive_dest_n来定义归档目的地 归档目的地可以在本地计算机上 也可在远程的数据库服务器上 定义语法如下

LOG_ARCHIVE_DEST_n= null_string |

(service=tnsnames_name |

LOCATION= directory_name )

[MANDATORY | OPTIONAL]

[REOPEN[=integer]]

例

LOG_ARCHIVE_DEST_ =((LOCATION= /archive/MYDB ) MANDATORU REOPEN= )定义归档日志的位置为/archive/MYDB mandatory子句的定义向这个位置写日志的 *** 作必须的成功的 Reopen子句定义在日志写入失败时 下次尝试写入 *** 作的时间间隔 缺省是 秒

例

LOG_ARCHIVE_DEST_@=(SERVICE=STDBY ) OPTIONAL REOPEN语句中的stdby 的连接到远程数据库的oracle net连接串 由于写 *** 作是可选的 所以数据库活动继续 当arcn进程不能写档案日志文件时 进程将立即尝试重新写入（这个动作有reopen子句来定义）

Log_archive_min_succeed_dest:定义最少归档日志的副本数量

Log_archive_format:定义归档日志文件采用的名称和使用的格式 可以使用预定义变量来构造每个归档日志文件的名称 变量如下

%s      日志序列号

%t      线程号

%r      复位日志id

%d      数据库id

lishixinzhi/Article/program/Oracle/201311/17689

Log File物理结构

从 ib_logfile0和 ib_logfile1这两个文件的物理结构可以看出，在Log Header部分还是有些许差异的， ib_logfile0会多一耐并些额外的信息，主要是checkpoint信息。

并且每个Block的单位是512字节，对应到磁盘每个扇区也是512字节，因此redo log写磁盘是原子写，保证能够写成功，而不像index page一样需要double write来保证安全写入。

我们依次从上到下来看每个Block的结构

Log File Header Block

Log Goup ID，可能会配置多个redo组，每个组对应一个id，当前都是0，占用4字节

Start LSN，这个redo log文件开始日志的lsn，占用8字节

Log File Number，总是为0，占用4字节

Created By，备份程序所占用的字节数，占用32字节

另外在ib_logfile0中会有两个checkpoint block，分别是 LOG_CHECKPOINT_1/ LOG_CHECKPOINT_2，两个记录InnoDB Checkpoint信息的字段，分别从文件头的第二个和第四个block开始记录，并且只在每组log的第一个文件中存在，组内其他文件虽然没有checkpoint相关信息，但是也会预留相应的空间出来。这里为什么有两个checkpoint的呢？原因是设计为交替写入，避免因为介质失败而导致无法找到可用的checkpoint的情况。

Log blocks

请点击输入图片描述

log block结构分为日志头段、日志记录、日志尾部

Block Header，占用12字节

Data部分

Block tailer，占用4字节

Block Header

这个部分是每个Block的头部，主要记录的块的信息

Block Number，表示这是第几个block，占用4字节，是通过LSN计算得来的，占用4字节

Block data len，表示该block中有多少昌改迹字节已经被使用歼备了，占用2字节

First Rec offet，表示该block中作为第一个新的mtr开始的偏移量，占用2字节

Checkpoint number，表示该log block最后被写入时的检查点的值，占用4字节

---