转 oracle catalog 库常用脚本

 

#########sample 1

 

To BottomTo Bottom


PURPOSE
-------

The following note gives examples of how to find information on a 
RMAN backup from the RC views that are available in the Recovery Catalog 
schema.

SCOPE & APPLICATION
-------------------

This note is intended for DBAs and Support Personnel.

NOTE: In the images and/or the document content below, the user information and environment data used 
represents fictitious data from the Oracle sample schema(s),Public Documentation delivered with an Oracle 
database product or other training material. Any similarity to actual environments, actual persons, living or 
dead, is purely coincidental and not intended in any manner.


For the purposes of this document, the following fictitious environment is used as an example to describe 
the procedure:



database names = TESTV817, RCAT917
catalog database:  RCAT1
tablespace=CATTBS,TEMP,ROLLBACK
schema=RMAN
rectory = /spare/RMAN and all subdirectories


USEFUL INFORMATION FROM RC VIEWS
--------------------------------------

1) In this example TESTV817 is the target database with the  
   associated datafiles and controlfile: 
   Query of the views v$datafile and v$controlfile in the target
   database TESTV817.
 
SVRMGR> select file#, name, bytes from v$datafile;
FILE#      NAME
            BYTES
---------- ---------------------------------------
----------- ----------
         1 /spare/RMAN/TARGET/system.dbs
              62914560
         2 /spare/RMAN/TARGET/rbs01.dbf
              15728640
         3 /spare/RMAN/TARGET/temp01.dbf
               3145728
         4 /spare/RMAN/TARGET/tools01.dbf
               1048576
         5 /spare/RMAN/TARGET/users01.dbf
               5242880
5 rows selected.

SVRMGR> select * from v$controlfile;
STATUS  NAME

------- --------------------------------------------
--------
        /spare/RMAN/TARGET/control1.ctl

        /spare/RMAN/TARGET/control2.ctl

2)  The name of the recovery catalog database is RCAT917. A typical cold
    backup of TESTV817 is taken using the following RMAN script:

RMAN> run {
2> allocate channel dev1 type disk;
3> backup
4> full
5> format '/spare/RMAN/RMANBACKUPS/db_t%t_s%s_p%p'
6> (database);
10> backup
11> format '/spare/RMAN/RMANBACKUPS/cf_t%t_s%s_p%p'
12> (current controlfile);
13> release channel dev1;
14>  }

3) The backup has produced 2 files (or backup pieces as explained later) 
   when viewed at the OS level i.e. in /spare/RMAN/RMANBACKUPS directory:

$ ls -alt
total 122436
drwxrwxrwx   2 usupport dba          512 Oct 15 17:00 ./
-rw-rw----   1 usupport dba       686592 Oct 15 17:00 cf_t443206820_s15_p1
-rw-rw----   1 usupport dba      61942272 Oct 15 17:00 db_t443206793_s14_p1
drwxrwxrwx   9 usupport dba          512 Aug 23 14:48 ../

4) We can now connect to the Recovery Catalog to find out more information 
   about these backup pieces using some RC views:

$  sqlplus rman/<password>@<Tns_Alias_Catalog>
                                     
5) The view RC_DATABASE simply gives information about the TESTV817 database 
   that is registered in the Recovery Catalog. The DBID column indicates a 
   unique identifier for the database obtained from v$database.

SQL> select db_key, dbinc_key, dbid, name from rc_database;

    DB_KEY  DBINC_KEY       DBID NAME
---------- ---------- ---------- --------
         1       1185 1549738258 TESTV817

6) The RC_BACKUP_SET view lists information about backup sets for all 
   incarnations of the database. A backup set, which is a logical construction,
   contains one or more physical backup pieces. Backup pieces are O/S files 
   that can contain backup datafiles, control files, or archived redo logs.

SQL> select db_key, db_id, bs_key, pieces, start_time, status
  2  from rc_backup_set;

DB_KEY      DB_ID     BS_KEY     PIECES     START_TIM S
---------- ---------- ---------- ---------- --------- -
         1 1549738258       1234          1 03-AUG-01 A
         1 1549738258       1270          1 15-OCT-01 A
         1 1549738258       1279          1 15-OCT-01 A

The query shows that a backup was taken on 15 October 2001 and has subsequently
created 2 backup sets. All backup sets are referenced uniquely by the primary 
key BS_KEY. In this case, we have backup sets 1270 and 1279. Each backup set 
contains one backup piece as indicated by the ‘pieces’ column.  A status 
of ‘A’ indicates they are available for recovery.

7) The view RC_BACKUP_DATAFILE lists information about datafiles in backup sets. 
   The query shows that we have backed up the TESTV817 datafiles - as can be 
   seen from the file# column (same as file# from v$datafile on the target
   database TESTV817 shown earlier): 

SQL>  select bs_key, db_key, db_name, completion_time, file#, status
  2  from rc_backup_datafile where bs_key = 1270;

    BS_KEY     DB_KEY DB_NAME  COMPLETIO      FILE# S
---------- ---------- -------- --------- ---------- -
      1270          1 TESTV817 15-OCT-01          1 A
      1270          1 TESTV817 15-OCT-01          2 A
      1270          1 TESTV817 15-OCT-01          5 A
      1270          1 TESTV817 15-OCT-01          3 A
      1270          1 TESTV817 15-OCT-01          4 A

8) The view RC_BACKUP_CONTROLFILE lists information about controlfiles in backup
   sets. The query shows that we have backed up the TESTV817 controlfile into 
   backup set 1279.

SQL> select bs_key, db_key, db_name, status from rc_backup_controlfile
  2  where bs_key = 1279;

    BS_KEY     DB_KEY DB_NAME  S
---------- ---------- -------- -
      1279          1 TESTV817 A

9) The view RC_BACKUP_PIECE lists information about backup pieces. Each backup 
   set contains one or more backup pieces. In the following query we can see 
   that 2 backup pieces have been created (corresponding to bs_key 1270 and 1279
   ). They are both referenced at the OS level (see point 3) by the ‘handle’ 
   field.

SQL> select bs_key, db_key, db_id, piece#, handle, status
  2  from rc_backup_piece where bs_key in (1270, 1279);

    BS_KEY     DB_KEY      DB_ID     PIECE#
---------- ---------- ---------- ----------
HANDLE
-------------------
S
-
      1279          1 1549738258          1
/spare/RMAN/RMANBACKUPS/cf_t443206820_s15_p1
A

      1270          1 1549738258          1
/spare/RMAN/RMANBACKUPS/db_t443206793_s14_p1

A

Although these examples do not include archived redo logs - similar information 
can be obtained from the RC_ARCHIVED_LOG view.

References:
------------

Oracle8i/9i Recovery Manager User's Guide and Reference
Note 98342.1
Note 1054528.6

The Oracle documentation is available online at http://otn.oracle.com 
and http://tahiti

 

 

 

#########sample 2

-- Use SQLplus and connect to rman Catalog Schema

sqlplus <username>@<catalog_tns>
SQL*Plus: Release 11.2.0.3.0 Production on Mon Oct 22 16:23:09 2012
Copyright (c) 1982, 2011, Oracle.  All rights reserved.
Enter password:

SQL> select count(*) from RC_ARCHIVED_LOG;

 COUNT(*)
----------
        0

# Re-register Target Database
# After re-registering the database in the catalog:
# The resync did not move all records from  v$archived_log  to recovery catalog.

RMAN> register database;

database registered in recovery catalog
starting full resync of recovery catalog
full resync complete

RMAN> resync catalog;
starting full resync of recovery catalog
full resync complete

RMAN> exit
Recovery Manager complete.

 

-- Connect to rman catalog schema using sqlplus.

sqlplus <username>@<catalog_tns>
SQL*Plus: Release 11.2.0.3.0 Production on Mon Oct 22 16:47:41 2012
Copyright (c) 1982, 2011, Oracle.  All rights reserved.
Enter password:
...

SQL> select count(*) from RC_ARCHIVED_LOG;

 COUNT(*)
----------
       70        <<---
 

-- Connect to target database using sqlplus.

sqlplus / as sysdba
SQL*Plus: Release 11.2.0.3.0 Production on Mon Oct 22 16:48:05 2012
Copyright (c) 1982, 2011, Oracle.  All rights reserved.


SQL>  select count(*) from V$ARCHIVED_LOG ;

 COUNT(*)
----------
     2954        <<--- this is different


CAUSE

Not all the archivelogs are resynced with the recovery catalog. Only the archivelogs that are 'not' deleted are resynced. ie status != 'D' and standby_dest = 'NO':

SOLUTION

To verify the amount of archivelogs which are resynced with the recovery catalog and that are not deleted
(ie status != 'D' and standby_dest = 'NO' ) , you can query V$ARCHIVED_LOG in target database

Example:

SQL> select count(*) from v$archived_log where status != 'D' and standby_dest = 'NO';

or

SQL> select count(*) from V$ARCHIVED_LOG where name is not null ;

-- The result based on this example:

 COUNT(*)
----------
       70        <<---

posted @ 2020-12-17 17:19  feiyun8616  阅读(238)  评论(0编辑  收藏  举报