The Undocumented Status “M” of an RMAN Backup

Apr 22, 2013 / By Rene Antunez

Tags: ,

It is not uncommon for Oracle to have something undocumented , and this is just another case of this ailment.

We have a database in which we have two copies of the same backup: one kept in the FRA and the other in an external disk, which from time to time gets deleted from this second disk. But what happens after you do a crosscheck and one of those 2 backups is expired? The one in the FRA is available and the one in the external disk is expired for RMAN, but how will you see it in your listing?

In the 11.2 documentation for the LIST command, it only tells you that the Status of a backup can be AVAILABLE, UNAVAILABLE, or EXPIRED, but as you can see below, that is not the case with our database. :)

RMAN> list backup summary;

using target database control file instead of recovery catalog

List of Backups
===============
Key     TY LV S Device Type Completion Time #Pieces #Copies Compressed Tag
------- -- -- - ----------- --------------- ------- ------- ---------- ---
1986    B  F  A DISK        17-APR-13       1       2       NO         *
1987    B  F  M DISK        17-APR-13       1       2       NO         *
1988    B  F  A DISK        17-APR-13       1       2       NO         *
1989    B  F  A DISK        19-APR-13       1       1       NO         TAG000661
1990    B  A  A DISK        19-APR-13       1       1       YES        BUP_ARCH_FRA

When I first faced this, the meaning of the M status got me curious (and I still don’t know the exact meaning, but I have my suspicions). If I did a trace of my list backup summary command, I could see exactly what I knew was happening:

pythian@oracleenespanol.local /home/pythian/working/antunez
pythian $ rman target / debug trace rman.trc
Recovery Manager: Release 11.2.0.3.0 - Production on Fri Apr 19 16:02:56 2013

Copyright (c) 1982, 2011, Oracle and/or its affiliates.  All rights reserved.

RMAN-06005: connected to target database: TESTDB (DBID=1834739652)

RMAN> list backup summary;

This is a small result of the trace done above:

DBGMISC: 339 BS (datafile) key=1987 recid=1987 stamp=812962808 setstamp=812962807 setcount=2021
DBGMISC: level=1 level_i=-1 piececount=1 keepopts=0, site_key=0 [16:03:27.544]
DBGMISC: site_key=0 [16:03:27.544]
DBGMISC: chid=NIL parm=NIL [16:03:27.544]
DBGMISC: flags= [16:03:27.544]
DBGMISC: valid backup set list is [16:03:27.544]
DBGMISC: 1 VBS copy#=1 tag=BACKUP_CONTROLFILE_FRA deviceType=DISK status=A
DBGMISC: 1 BPIECEX key=3502 recid=3502 stamp=812962808
DBGMISC: bskey=1987 set_stamp=812962807 set_count=2021 site_key=0
DBGMISC: pieceno=1 handle=+FRA/test/backupset/2013_04_17/ncnnf0_backup_controlfile_fra_0.297.812962809
DBGMISC: device=DISK krmkch { count=0 found=FALSE }
DBGMISC: 2 VBS copy#=2 tag=BACKUP_OF_BACKUPSET deviceType=DISK status=X
DBGMISC: 1 BPIECEX key=3538 recid=3538 stamp=813024283
DBGMISC: bskey=1987 set_stamp=812962807 set_count=2021 site_key=0
DBGMISC: pieceno=1 handle=/backupdisk/TEST_bck/db_bckset_backup_TEST2_04-18-2013_v5o79kvn_1_2.rman
DBGMISC: device=DISK krmkch { count=0 found=FALSE }
DBGMISC: restore target list is [16:03:27.545]
DBGMISC: 1 ACT type=full fromSCN=0 toSCN=307822519 fno=0
DBGMISC: CURCF

As you can see above, one copy is EXPIRED and the other one is AVAILABLE. And because each copy has a different tag name, you have an asterisk “*”  for a tag of the backup set with Key 1987 when you list them.

Both of these behaviours are perfectly normal, but you won’t find them anywhere in Oracle’s Documentation. Next time you see this in your list command, you will know the exact meaning of this status. Have you seen this before in your RMAN listings ?

P.S. For me it means Multiple or Mixed.

Leave a Reply

  • (will not be published)

XHTML: You can use these tags: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>