Oracle之redo分析

    作为一名开发人员，应该能够测量你的操作生成了多少redo，这往往很重要。生成的redo越多，你的操作花费的时间就越长，整个系统也会越慢。你不光在影响你自己的会话，还会影响每一个会话。redo管理是数据库中的一个串行点。任何Oracle实例都只有一个LGWR，最终所有事务都会归于LGWR，要求这个进程管理它们的redo，并BOMMIT其事务，LGWR要做的越多，系统就会越慢。通过查看一个操作会生成多少redo，并对一个问题的多种解决方法进行测试，可以从中找出最佳的方法。

 

 

    1. 测量redo

    以下示例只是测试简单的sql语句。

 

    a. 建立两个脚本mystat.sql与mystat2.sql

 Mystat.sql内容如下：

 set verify off

 column value new_val V

 define S="&1"

 set autotrace off

 select a.name, b.value

 from v$statname a, v$mystat b

 where a.statistic# = b.statistic#

 and lower(a.name) like '%' || lower('&S')||'%'

 / 

 Mystat2.sql内容如下：

 set verify off

 select a.name, b.value V, to_char(b.value-&V,'999,999,999,999') diff

 from v$statname a, v$mystat b

 where a.statistic# = b.statistic#

 and lower(a.name) like '%' || lower('&S')||'%'

 /

<!--EndFragment-->

 

 

<!--EndFragment--><!--EndFragment-->

<!--EndFragment-->

 

 

       b.  以dba身份登录数据库，比如：ob37/ob37 as sysdba

 

    c. 创建一个测试表T：

    create table t

    as

    select a.*

    from all_objects a

    where a.data_object_id=258 （258能够唯一区分出a表里面的一条记录，这里只是为了创建一个和a表字段完全一样的表，先插入一条记录。）

 

    d. 运行如下命令：@mystat “redo size”(注意在用命令sqlplus登录数据库的时候，cmd的路径需要切换到mystat.sql与mystat2.sql的目录下面)

 

    e. 运行如下命令：insert into t select * from all_objects

 

    f. 运行如下命令：@mystat2 ，总体运行结果如下：

  
  

<!--EndFragment-->

     2. 我能关掉重做日志文件吗

    这个问题经常被问到。答案很简单：不能。因为重做日志对于数据库至关重要；它不是开销，不是浪费。不论你是否相信，重做日志对你来说确确实实必不可少。这是无法改变的事实，也是数据库采用的工作方式。如果你真的“关闭了redo”，那么磁盘驱动器的任何暂时失败、掉电或每个软件崩溃都会导致整个数据库不可用，而且不可恢复。不过需要指出，有些情况下执行某些操作时确实可以不生成重做日志。

    

     a. 在SQL语句中设置NOLOGGING

     有些SQL语句和操作支持使用NOLOGGING子句。这并不是说：这个对象的所有操作在执行时都不生成重做日志，而是说有些特定操作生成的redo会比平常（即不使用NOLOGGING子句时）少得多。

      比如这两条创建表SQL语句：

      create table t as select * from all_objects;

      create table t nologging as select * from all_objects;

      第一条语句会生成5.5M左右的redo信息，而第二条语句只会生成80KB左右（在我的电脑上测试的结果）

      看起来redo信息少多了，但是必须非常谨慎使用这种模式。因为你一旦以这种模式创建了一个表，那么对这个表的修改，删除，更新操作虽然会计入重做日志文件，但是初始数据没有记录在里面。一旦数据发生崩溃，无法从归档的重做日志文件恢复这个表的所有数据。

 

     b. 在索引上设置NOLOGGING

     可以把一个索引或表修改为默认采用NOLOGGING模式。这说明，以后重建这个索引不会生成日志。

     比如：

     create index t_idx on t(object_name);

     alter index t_idx rebuild;  //这条语句生成了2.2Mredo

    

     alter index t_idx nologging;

     alter index t_idx rebuild; //这条语句生成61KBredo

但是，现在这个索引没有得到保护（unprotected），如果它所在的数据文件失败而必须从一个备份恢复，我们就会丢失这个索引数据。

 

     c. NOLOGGING总结

     可以采用NOLOGGING模式执行以下操作：

     1. 索引的创建和ALTER（重建）。

     2. LOB操作（对大对象的更新不必生成日志）。

     3. 通过CREATE TABLE AS SELECT创建表。

     4. 各种ALTER TABLE操作，如MOVE和SPLIT。

     在一个ARCHIVELOG模式的数据库上，如果NOLOGGING使用得当，可以加快许多操作的速度，因为它能显著减少生成的重做日志量。假设你有一个表，需要从一个表空间移到另一个表空间。可以适当地调度这个操作，让它在备份之后紧接着发生，这样就能把表ALTER为NOLOGGING模式，移到表，创建索引（也不生成日志），然后再把表ALTER回LOGGING模式。当然，要想适当地使用这个特性，需要DBA的参与，或者必须与负责数据库备份和恢复（或任何备用数据库）的人沟通。

   

 

<!--EndFragment--><!--EndFragment-->