Re: RMAN - Query on V$BACKUP_SET inconsistency

From: Sreejith Nair <sreejithsna_at_gmail.com>
Date: Thu, 01 Sep 2011 06:53:00 +0530
Message-ID: <9876412190.999327180_at_gmail.com>

Hi,

But as per documentation
V$BACKUP_SET.BACKUP_TYPE holds the Type of files that are in this backup. If the
backup contains archived redo logs, the value is L. If this is a datafile full backup, the value is D. If this is an incremental backup, the value is I."

So, I suppose even if it is a control file backup backup_type is updated as "D" , which as per documentation will only come for a full datafile backup. This looks like misleading or incomplete.

Sreejith
~Sent from my samsung phone

Original message -------
> From: D'Hooge Freek <Freek.DHooge_at_uptime.be>
> To: sreejithsna_at_gmail.com, oracle-l_at_freelists.org
> Sent: 31/8/'11, 20:14
>
> Hi,
>
> Possible these are control file (auto) backups.
> You can verify what is in the backupset by looking at v$backup_file or by
> using rman (list backupset <backupset key>)
>
>
> Regards,
>
>
> Freek D'Hooge
> Uptime
> Oracle Database Administrator
> email: freek.dhooge_at_uptime.be
> tel +32(0)3 451 23 82
> http://www.uptime.be
> disclaimer: www.uptime.be/disclaimer
>
> -----Original Message-----
> From: oracle-l-bounce_at_freelists.org
> [mailto:oracle-l-bounce_at_freelists.org] On Behalf Of Sreejith Nair
> Sent: woensdag 31 augustus 2011 16:25
> To: Oracle L
> Subject: RMAN - Query on V$BACKUP_SET inconsistency
>
> Hi friends,
> Oracle Database EE 11.2.0.2 on Solaris 10...
> We have incremental level 0 backups which runs on Sunday using command
> backup as compressed backupset incremental level 0 .....
> We have incremental level 1 backups which runs everyday other than Sunday
>
> using command
> backup as compressed backupset incremental level 1 database....
> After the backup ran for today, what I see is as shown below..
> SQL> select BACKUP_TYPE,INCREMENTAL_LEVEL,START_
> TIME,COMPLETION_TIME from v$backup_set where START_TIME >
> sysdate -4 and BACKUP_TYPE'L';
> B INCREMENTAL_LEVEL START_TIME COMPLETION_TIME
> - ----------------- ----------------- -----------------
> D 0 28-AUG-2011 04:30 28-AUG-2011 04:33
> D 0 28-AUG-2011 04:30 28-AUG-2011 04:33
> I 1 29-AUG-2011 04:30 29-AUG-2011 04:33
> I 1 29-AUG-2011 04:30 29-AUG-2011 04:35
> I 1 30-AUG-2011 04:30 30-AUG-2011 04:33
> I 1 30-AUG-2011 04:30 30-AUG-2011 04:35
> I 1 31-AUG-2011 04:30 31-AUG-2011 04:33
> I 1 31-AUG-2011 04:30 31-AUG-2011 04:35
> D 31-AUG-2011 04:35 31-AUG-2011 04:35
> D 31-AUG-2011 06:30 31-AUG-2011 06:30
> D 31-AUG-2011 08:30 31-AUG-2011 08:30
> As per Oracle documentation V$BACKUP_SET,BACKUP_TYPE holds
> "BACKUP_TYPE VARCHAR2(1) Type of files that are in this backup. If the
> backup contains archived redo logs, the value is L. If this is a datafile
>
> full
> backup, the value is D. If this is an incremental backup, the value is
> I."
> "INCREMENTAL_LEVEL NUMBER Location where this backup set fits into
> the database's backup strategy. Set to zero for full datafile backups,
> nonzero for incremental datafile backups, and NULL for archivelog
> backups."
> So the above query shows an entry with "D" which means a full datafile
> backup did run today, but you can see INCREMENTAL_LEVEL is null which
> means it is not a full datafile backup. My questions is, why is BACKUP_
> TYPE field showing not as per the documentation -Why it is showing a
> "D" ?
> Listing the backup also does not show a full backup.
> Thanks in Advance.
> 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
> ------- -- -- - ----------- --------------- ------- ------- ----------
> ---
> 1722 B 0 A DISK 28-AUG-11 1 1 YES
> DB_FULL_
> BACKUP
> 1723 B 0 A DISK 28-AUG-11 1 1 YES
> DB_FULL_
> BACKUP
> 1724 B A A DISK 28-AUG-11 1 1 YES
> TAG20110828T043338
> 1727 B A A DISK 28-AUG-11 1 1 YES
> TAG20110828T063036
> 1729 B A A DISK 28-AUG-11 1 1 YES
> TAG20110828T083025
> 1731 B A A DISK 28-AUG-11 1 1 YES
> TAG20110828T103015
> 1733 B A A DISK 28-AUG-11 1 1 YES
> TAG20110828T123050
> 1735 B A A DISK 28-AUG-11 1 1 YES
> TAG20110828T143026
> 1737 B A A DISK 28-AUG-11 1 1 YES
> TAG20110828T163025
> 1739 B A A DISK 28-AUG-11 1 1 YES
> TAG20110828T183025
> 1741 B A A DISK 28-AUG-11 1 1 YES
> TAG20110828T203029
> 1743 B A A DISK 28-AUG-11 1 1 YES
> TAG20110828T223027
> 1745 B A A DISK 29-AUG-11 1 1 YES
> TAG20110829T003025
> 1747 B A A DISK 29-AUG-11 1 1 YES
> TAG20110829T023043
> 1749 B 1 A DISK 29-AUG-11 1 1 YES
> DB_
> INCR_BACKUP
> 1750 B 1 A DISK 29-AUG-11 1 1 YES
> DB_
> INCR_BACKUP
> 1751 B A A DISK 29-AUG-11 1 1 YES
> TAG20110829T043543
> 1752 B A A DISK 29-AUG-11 1 1 YES
> TAG20110829T043543
> 1754 B A A DISK 29-AUG-11 1 1 YES
> TAG20110829T063027
> 1756 B A A DISK 29-AUG-11 1 1 YES
> TAG20110829T083027
> 1758 B A A DISK 29-AUG-11 1 1 YES
> TAG20110829T103035
> 1760 B A A DISK 29-AUG-11 1 1 YES
> TAG20110829T123054
> 1762 B A A DISK 29-AUG-11 1 1 YES
> TAG20110829T143043
> 1764 B A A DISK 29-AUG-11 1 1 YES
> TAG20110829T163029
> 1766 B A A DISK 29-AUG-11 1 1 YES
> TAG20110829T183036
> 1768 B A A DISK 29-AUG-11 1 1 YES
> TAG20110829T203026
> 1770 B A A DISK 29-AUG-11 1 1 YES
> TAG20110829T223029
> 1772 B A A DISK 30-AUG-11 1 1 YES
> TAG20110830T003021
> 1774 B A A DISK 30-AUG-11 1 1 YES
> TAG20110830T023042
> 1776 B 1 A DISK 30-AUG-11 1 1 YES
> DB_
> INCR_BACKUP
> 1777 B 1 A DISK 30-AUG-11 1 1 YES
> DB_
> INCR_BACKUP
> 1778 B A A DISK 30-AUG-11 1 1 YES
> TAG20110830T043517
> 1779 B A A DISK 30-AUG-11 1 1 YES
> TAG20110830T043517
> 1781 B A A DISK 30-AUG-11 1 1 YES
> TAG20110830T063031
> 1783 B A A DISK 30-AUG-11 1 1 YES
> TAG20110830T083027
> 1785 B A A DISK 30-AUG-11 1 1 YES
> TAG20110830T103026
> 1787 B A A DISK 30-AUG-11 1 1 YES
> TAG20110830T123041
> 1789 B A A DISK 30-AUG-11 1 1 YES
> TAG20110830T143021
> 1791 B A A DISK 30-AUG-11 1 1 YES
> TAG20110830T163030
> 1793 B A A DISK 30-AUG-11 1 1 YES
> TAG20110830T183033
> 1795 B A A DISK 30-AUG-11 1 1 YES
> TAG20110830T203026
> 1797 B A A DISK 30-AUG-11 1 1 YES
> TAG20110830T223027
> 1799 B A A DISK 31-AUG-11 1 1 YES
> TAG20110831T003027
> 1801 B A A DISK 31-AUG-11 1 1 YES
> TAG20110831T023048
> 1803 B 1 A DISK 31-AUG-11 1 1 YES
> DB_
> INCR_BACKUP
> 1804 B 1 A DISK 31-AUG-11 1 1 YES
> DB_
> INCR_BACKUP
> 1805 B A A DISK 31-AUG-11 1 1 YES
> TAG20110831T043513
> 1806 B A A DISK 31-AUG-11 1 1 YES
> TAG20110831T043513
> 1807 B F A DISK 31-AUG-11 1 1 NO
> TAG20110831T043518
> 1808 B A A DISK 31-AUG-11 1 1 YES
> TAG20110831T063015
> 1809 B F A DISK 31-AUG-11 1 1 NO
> TAG20110831T063024
> 1810 B A A DISK 31-AUG-11 1 1 YES
> TAG20110831T083026
> 1811 B F A DISK 31-AUG-11 1 1 NO
> TAG20110831T083034
>
> Thanks in Advance,
> Sreejith
> --
> http://www.freelists.org/webpage/oracle-l
>
>

--
http://www.freelists.org/webpage/oracle-l

Received on Wed Aug 31 2011 - 20:23:00 CDT

This message: [ Message body ]
Next message: Jeremy Schneider: "Re: ouch"
Previous message: Jack van Zanen: "Re: Rman backup errors"
Maybe in reply to: Sreejith Nair: "RMAN - Query on V$BACKUP_SET inconsistency"

Contemporary messages sorted: [ by date ] [ by thread ] [ by subject ] [ by author ]

Original text of this message