22 Apr The undocumented status “M” of an RMAN backup
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 we keep in the FRA, the other one 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?
Looking at 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, it got me curious as to what the meaning of the M status meant (and I still don’t know the exact meaning, but I have my supposition) . If I did a trace of my list backup summary command , I could see exactly what I knew it 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, also because each copy has a different tag name, when you list them, you have an asterisk “*” for a tag of the backupset with Key 1987.
Both of these behaviours are perfectly normal, but you won’t find them anywhere in Oracle’s Documentation, so the 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.
Sorry, the comment form is closed at this time.