• 清理RMAN Catalog恢复目录


    有这样一个需求,用户使用RMAN Catalog恢复目录保存多台Database Server的备份信息。 由于每天都会执行大量的backup操作,而且所备份的DB的结构本身都已经十分复杂了,导致recovery catalog恢复目录占用空间迅速增长,且用户的磁盘空间较为紧张,可能在短期内无法扩disk space,这就让我们考虑到需要清理RMAN Recovery Catalog中一些不再需要的记录。 首先搞清楚在Catalog库中那些数据段占用了最多的空间Space:  
    这里 RMAN 用户是Catalog Schema 的拥有者
    
    SQL>  select bytes/1024/1024 "MB" ,segment_name,segment_type
    from dba_segments where owner='RMAN' order by bytes desc;
    
            MB SEGMENT_NAME         SEGMENT_TYPE
    ---------- -------------------- ------------------
            88 ROUT                 TABLE
            47 ROUT_U1              INDEX
            31 ROUT_I_RSR           INDEX
            23 ROUT_I_DB            INDEX
          .125 RSR                  TABLE
      可以看到是ROUT表占用了最多的空间,那么这张表是做什么用处的呢? ROUT表用于记录RMAN在执行backup等命令时的输出内容,实际上堆积了V$RMAN_OUTPUT视图中的内容,当目标数据库连接到CATALOG库执行操作或Resync Catalog时会将V$RMAN_OUTPUT中的信息同步到Catalog库的ROUT表中。  
    SQL> desc v$rman_output;
     Name                                      Null?    Type
     ----------------------------------------- -------- ----------------------------
     SID                                                NUMBER
     RECID                                              NUMBER
     STAMP                                              NUMBER
     SESSION_RECID                                      NUMBER
     SESSION_STAMP                                      NUMBER
     OUTPUT                                             VARCHAR2(130)
     RMAN_STATUS_RECID                                  NUMBER
     RMAN_STATUS_STAMP                                  NUMBER
     SESSION_KEY                                        NUMBER
    
    SQL> select output from v$rman_output where output is not null and rownum <3;
    
    OUTPUT
    --------------------------------------------------------------------------------
    connected to target database: VPROD (DBID=881465081)
    connected to recovery catalog database
      ROUT表的定义存放在$ORACLE_HOME/rdbms/admin/recover.sql 中,具体如下:  
    CREATE TABLE rout
    (
    db_key          NUMBER NOT NULL,        -- database output belongs to
    rsr_key         NUMBER NOT NULL,        -- command that generated the output
    rout_skey       NUMBER NOT NULL,        -- session that created the output
    rout_recid      NUMBER NOT NULL,        -- record id from server
    rout_stamp      NUMBER NOT NULL,        -- timestamp when row was added
    rout_text       VARCHAR2(130) NOT NULL, -- RMAN output
    CONSTRAINT rout_u1 UNIQUE(db_key, rout_skey, rsr_key, rout_recid, rout_stamp),
    CONSTRAINT rout_f1 FOREIGN KEY(db_key)
      REFERENCES db ON DELETE CASCADE,
    CONSTRAINT rout_f2 FOREIGN KEY(rsr_key)
      REFERENCES rsr ON DELETE CASCADE
    ) &tablespace&
      正是因为该Catalog恢复目录每天都会记录大量结构复杂(拥有众多数据文件、归档日志)的数据库的备份输出信息,导致ROUT表迅速膨胀,可能会存放几十万条记录,在我们的例子中:  
    SQL> select count(*) from rman.rout;
    
      COUNT(*)
    ----------
       1069485
      根据文档<Rman Catalog Resync Operation is Very slow at 10G [ID 378234.1]>的介绍ROUT表包含了所有RMAN会话的输出内容,且这些内容仅对 Enterprise Manager企业管理器有用。 默认情况下ROUT表也会在每次Resync Catalog操作时被清理(clean up),但是在版本10.2.0.1-10.2.0.3仍会保留最近60天来的记录,当RMAN被频繁使用时60天的ROUT数据也可能非常多。(The ROUT table contains the RMAN output generated during all rman sessions and is used only by Enterprise Manager. The ROUT table is cleaned up automatically during each resync operation leaving by default, the last 60 days worth of entries in ROUT.   However where RMAN is used  very frequently, 60 days of ROUT entries is still too much.)   而从版本10.2.0.4 开始清理ROUT的存储过程cleanupROUT默认仅保留最近7天的数据,这就保证了ROUT不会占用过多的空间。   这里实际控制ROUT表中数据如何清理的recovery.sql中定义的cleanupROUT存储过程,在版本10.2.0.1 中该过程的定义如下:  
    -- The procedure cleanupROUT (deletes) all RC_RMAN_OUTPUT rows corresponding
    -- to job older than 60 days.
    PROCEDURE cleanupROUT IS
      start_time       date;
      high_stamp       number;
      high_session_key number;
    BEGIN
      IF (this_db_key IS NULL) THEN
        raise_application_error(-20021, 'Database not set');
      END IF;
    
      start_time := SYSDATE;
      high_stamp := date2stamp(start_time-60);
    
      SELECT nvl(max(session_key), 0) into high_session_key
         from rc_rman_status where session_stamp < high_stamp;
    
      DELETE FROM rout
            WHERE rout_skey <= high_session_key
              AND this_db_key = rout.db_key;
    
      deb('cleanupROUT deleted ' || sql%rowcount || ' rows from rout table');
      deb('cleanupROUT took ' || ((sysdate - start_time) * 86400) || ' seconds');
    
    END cleanupROUT;
      实际我们只要修改这里high_stamp := date2stamp(start_time-60); 指定的60天的范围,就可以改变10.2.0.4前保留60天ROUT历史数据导致该表暴涨的问题。   首先备份recovery.sql 文件, 之后我们修改该cleanupROUT过程的定义如下:    
    cd $ORACLE_HOME/rdbms/admin
    cp  recover.bsq recover.bsq.bak
    
    PROCEDURE cleanupROUT IS
      start_time       date;
      high_stamp       number;
      high_session_key number;
    BEGIN
      IF (this_db_key IS NULL) THEN
        raise_application_error(-20021, 'Database not set');
      END IF;
    
      start_time      := SYSDATE;
      high_stamp      := date2stamp(start_time-7);
    
      SELECT max(rsr_key) into high_session_key
        FROM rsr, dbinc
       WHERE dbinc.db_key = this_db_key
         AND rsr.dbinc_key = dbinc.dbinc_key
         AND rsr.rsr_stamp < high_stamp;
    
      deb('cleanupROUT select took ' || ((sysdate - start_time) * 86400) ||
          ' seconds');
    
      -- Delete rows from rout table for jobs older than 7 days.
      If high_session_key IS NOT NULL THEN
         DELETE FROM rout
         WHERE  db_key     = this_db_key
           AND  rout_skey <= high_session_key;
         deb('cleanupROUT deleted ' || sql%rowcount || ' rows from rout table');
      END IF;
    
      deb('cleanupROUT took ' || ((sysdate - start_time) * 86400) || ' seconds');
    
    END cleanupROUT;
      完成上述定义修改后,需要使以上的定义生效,连接到catalog库并升级catalog:  
    [oracle@vrh8 admin]$ rman target / catalog rman/rman@VPROD
    
    Recovery Manager: Release 10.2.0.1.0 - Production on Mon Dec 5 00:37:35 2011
    
    Copyright (c) 1982, 2005, Oracle.  All rights reserved.
    
    connected to target database: G10R21 (DBID=2807279631)
    connected to recovery catalog database
    
    RMAN> upgrade catalog;
    
    recovery catalog owner is RMAN
    enter UPGRADE CATALOG command again to confirm catalog upgrade
    
    RMAN> upgrade catalog;
    
    recovery catalog upgraded to version 10.02.00.00
    DBMS_RCVMAN package upgraded to version 10.02.00.00
    DBMS_RCVCAT package upgraded to version 10.02.00.00
    
    RMAN> resync catalog;
    
    starting full resync of recovery catalog
    full resync complete
      完成上述resync后,ROUT会保留最近7天以来的记录,但是原本占用的空间不会释放,因为cleanupROUT仅仅是delete记录。  
    SQL> select count(*) from rman.rout;
    
      COUNT(*)
    ----------
            55
    
    SQL>  select bytes/1024/1024 "MB" ,segment_name,segment_type from dba_segments where segment_name='ROUT';
    
            MB SEGMENT_NAME         SEGMENT_TYPE
    ---------- -------------------- ------------------
            88 ROUT                 TABLE
      这里存在2种方案: 1. 直接truncate rout表,因为本身rman output的数据只对Enterprise Manager有用,对于很多没有部署EM的环境,ROUT上的这些记录实际没有太大的意义,直接truncate rout 可以回收其原占有的空间:  
    stop any rman catalog operation 停止任何RMAN操作
    
    SQL> truncate table rman.rout;
    
    Table truncated.
      2. 利用10g以后出现的shrink space功能收缩空间,这样既保留了ROUT中的少量记录,又回收了必要的空间:  
    stop any rman catalog operation 停止任何RMAN操作
    
    SQL>  alter table rman.rout enable row movement;
    
    Table altered.
    
    SQL> alter table rman.rout shrink space;
    
    Table altered.
    
    SQL> select bytes/1024/1024 "MB" ,segment_name,segment_type from dba_segments where segment_name='ROUT';
    
            MB SEGMENT_NAME         SEGMENT_TYPE
    ---------- -------------------- ------------------
         .0625 ROUT                 TABLE
  • 相关阅读:
    bean依赖注入三种方式
    bean实例化三种方式
    记录aop失效问题
    解决通配符的匹配很全面, 但无法找到元素 'aop:config' 的声明
    手动实现IOC
    KAL1 LINUX 官方文档之虚拟机版本 在 Kali(主机)上安装 VMware(更新于2022)
    KAL1 LINUX 官方文档之arm板版本 CubieBoard2(更新于2022)
    KAL1 LINUX 官方文档之arm板版本 CubieTruck (CubieBoard3)(更新于2022)
    KAL1 LINUX 官方文档之虚拟机版本 带有 virtmanager 的 QEMU/LibVirt 中的 Kali(来宾 VM)(更新于2022)
    KAL1 LINUX 官方文档之虚拟机版本 安装 VMware Tools(来宾工具)(更新于2022)
  • 原文地址:https://www.cnblogs.com/macleanoracle/p/2968104.html
Copyright © 2020-2023  润新知