判断Oracle10gRACredo日志大小是否存在问题

判断Oracle 10G RAC redo日志大小是否存在问题

在此我们将提到两个可能出现的问题。

首先提到的就是批处理任务，该任务可能没有足够的完整重做空间来完成，或是因为速度快，以致联机重做日志在归档到脱机重做日志前即已切换(使用了所有的重做日志，并且开始再次写入第一个重做日志)。联机重做日志只有在归档(启用归档时)后才可以被重写，因此DML 和 DDL 活动必须等待，直到有可用的联机日志。在操作系统级别上，按它们最近的更新日期和时间列出联机重做日志，您可以判断它们切换的是否频繁。还可以用查询 V$LOG_HISTORY 来得到最近的日志交换记录（ 以前是100个，现在增加了 ）。如果增加了联机重做日志的大小，就可以为那些执行大型的 INSERT、UPDATE 和 DELETE 操作的批处理任务提供足够的空间。较好的解决办法是增加联机重做日志的数目，这样就可以在有很频繁的日志切换(很小但却非常多的联机重做日志)时提供足够的空间。

第二个要考虑的问题就是那些要长时间运行的任务，这些任务可能要花大量的时间来切换联机重做日志。当整个任务正好只需用到一个联机重做日志时，这种长时间运行的任务可能非常快。对于联机事务处理(OLTP)类型的环境来说，最好使用较小的重做日志。我的经验是每半个小时(不考虑可以缩短这段时间的一些长时间运行的批处理操作)就切换一次联机重做日志。通过在操作系统级别上监控联机重做日志发生的日期和时间(或查询 v$log_history，也可以查询)，就可以确定增加联机重做日志的大小或数目，从而设置一个优化的切换时间间隔。

下面的查询显示了两个日志切换的间隔时间，这样我们可以方便地判断系统是否存在问题。

1、对于单实例

2、对于集群 上面这个是对于节点1的联机日志切换（a.thread#=b.thread# and a.thread#=1），如果对于节点2的也很简单（a.thread#=b.thread# and a.thread#=2）即可

可以在操作系统级别上检查联机重做日志文件的大小或查询 V$LOG 和 V$LOGFILE 表，以此来确定这些文件的大小。下面列出的查询中显示了关于重做日志的显示信息：

select a.member, b.* from v$logfile a, v$log b where a.group# = b.group#;

3、 其他有帮助的重做日志命令

使用 ALTER DATABASE ADD LOGFILE. . .命令创建较大的日志，然后删除较小的日志，以此来增加额外的日志。需要注意的是，基于在 init.ora 文件中为 CHECKPOINT_INTERVAL 指定的块数量，检查点的时间间隔会强加一个检查点。因此，如果增加联机重做日志文件的尺寸，则要确保也增加检查点的时间间隔。为了多路复用联机重做日志文件(创建一个镜像副本)，，可以使用如下的命令将日志文件添加到已有的组：

alter database add logfile member '+RAC/jscn/onlinelog/redo011.dbf' to group 4;
alter database add logfile member '+RAC/jscn/onlinelog/redo021.dbf' to group 5;

可以用下面的命令删除某个联机重做日志成员：

alter database drop logfile member '+RAC/jscn/onlinelog/redo021.dbf';

如果要添加一个新的联机重做日志组，可使用下面的命令：

alter database add logfile thread 1 group 5 '+RAC/jscn/onlinelog/redo01.dbf' size 512m;