RMAN-06900 followed by RMAN-08138

Last post 04-19-2019, 10:17 AM by pereirath. 9 replies.
Sort Posts: Previous Next
  • RMAN-06900 followed by RMAN-08138
    Posted: 04-03-2019, 9:37 AM

    The Simpana software considers these RMAN warnings as default:

    • RMAN-07529
    • RMAN-08138: WARNING: archived log not deleted - must create more backups
    • RMAN-08120
    • RMAN-08591
    • RMAN-08137
    • RMAN-06060
    Any updated article for Version 11? 
    Errors associated (18:53 / 72:151)
  • Re: RMAN-06900 followed by RMAN-08138
    Posted: 04-03-2019, 10:23 AM
    • efg is not online. Last active: 05-20-2019, 11:53 AM efg
    • Top 10 Contributor
    • Joined on 02-02-2010
    • CommVault Tinton Falls NJ
    • Expert
    • Points 1,655

    This can be found in the standard online documentation for V11.  Here is a link to the documentation for the latest service pack (SP15)

    In this link you will find the same information:

    The Commvault software considers these RMAN warnings as default:

    • RMAN-07529
    • RMAN-08138
    • RMAN-08120
    • RMAN-08591
    • RMAN-08137
    • RMAN-06060

    Let us know if this helps...



    Ernst F. Graeler
    Senior Engineer III
    Development
  • Re: RMAN-06900 followed by RMAN-08138
    Posted: 04-03-2019, 4:36 PM

    Thanks for respoding efg. Would you mind clarifying or helping me to understand while a backup that has been running for months without an issue now starts generating RMAN warnings and commvault recommends to ignore it? 

    RMAN output:

    • ##### Creating PARAMETER FILE BACKUP ##### 
    • create pfile='/oradb/abcde01/arch//initabcde01.ora' from spfile; 
    • create spfile='/oradb/abcde01/arch//spfileabcde01.ora' from pfile='/oradb/abcde01/arch//initabcde01.ora' ;
    • exit; 
    • ##### Running QuieceScript for instance abcde01 ##### 
    • Executing sql [alter database begin backup; 
    • exit; 
    • ##### SNAP THE DATA VOLUME(S) ##### 
    • ##### Run post-snap scripts on Instance abcde01 ##### 
    • Executing sql [alter database end backup; 
    • alter system archive log current; 
    • ALTER DATABASE BACKUP CONTROLFILE TO '/oradb/abcde01/arch//backup.ctl.galaxy' REUSE;
    • exit; 
    • ##### SNAP THE LOG VOLUME(S) ##### 
    • ##### Create Index - Data Phase ##### 
    • ##### Create Index - Log Phase ##### 
    • Rman Script: 
    • [run 
    • delete noprompt archivelog until time = 'sysdate-4' backed up 1 times to sbt ;
    • exit; 
    • Rman Log:[ 
    • Recovery Manager: Release 12.1.0.2.0 - Production on Wed Apr 3 06:23:07 2019 
    • Copyright (c) 1982, 2014, Oracle and/or its affiliates. All rights reserved. 
    • RMAN> 
    • connected to recovery catalog database 
    • recovery catalog schema release 12.02.00.01. is newer than RMAN release 
    • RMAN> 
    • connected to target database: ABCDE01 (DBID=1112365121) 
    • RMAN-06900: WARNING: unable to generate V$RMAN_STATUS or V$RMAN_OUTPUT row 
    • RMAN-06901: WARNING: disabling update of the V$RMAN_STATUS and V$RMAN_OUTPUT rows
    • ORACLE error from target database: 
    • ORA-04031: unable to allocate 36424 bytes of shared memory ("shared pool","unknown object","sga heap(2,0)","krbmror")
    • RMAN> 2> 3> 4> 
    • allocated channel: ORA_DISK_1 
    • channel ORA_DISK_1: SID=543 device type=DISK 
    • RMAN-08138: WARNING: archived log not deleted - must create more backups 
    • archived log file name=/oradb/abcde01/arch/abcde01_1_378_974207167.arc thread=1 sequence=378
    • RMAN-08138: WARNING: archived log not deleted - must create more backups 
    • archived log file name=/oradb/abcde01/arch/abcde01_1_379_974207167.arc thread=1 sequence=379
    • RMAN-08138: WARNING: archived log not deleted - must create more backups 
    • archived log file name=/oradb/abcde01/arch/abcde01_1_380_974207167.arc thread=1 sequence=380
  • Re: RMAN-06900 followed by RMAN-08138
    Posted: 04-03-2019, 5:13 PM
    • efg is not online. Last active: 05-20-2019, 11:53 AM efg
    • Top 10 Contributor
    • Joined on 02-02-2010
    • CommVault Tinton Falls NJ
    • Expert
    • Points 1,655

    hmm...   it looks like you are using intellisnap for BOTH the data and log volumes on your environment.   I'm guessing that you also have enabled advanced job options for the log backup for deleting the logs based on this line I'm seeing in the attached log:

    delete noprompt archivelog until time = 'sysdate-4' backed up 1 times to sbt ;

    When using intellisnap to protect the logs, they are not really backed up with RMAN (since they are captured in the snap) and hence are not backed up using SBT.  This will cause the warning you are seeing.  If you want to keep the logs on disk for 4 days why not use RMAN for the log backup (instead of snapping the entire log volume)?  Then the warning you are getting will not occur, as RMAN will then be used to protect the logs (writing them through the SBT layer) and thus recording the backup in the catalog/controlfile.  In the subclient properties go to the Log backup tab, and select "Use RMAN for Log backup"  This will stop the snaps for the log volume and instead stream the logs using the SBT API.

    Let us know if this helps.


    Ernst F. Graeler
    Senior Engineer III
    Development
  • Re: RMAN-06900 followed by RMAN-08138
    Posted: 04-04-2019, 4:47 PM

    Thanks for your response. I do have clients where RMAN is controling the logs and the scheduling is set to delete the logs as well, however we have the same error evey now and then regardless if the client is a intellisnap or rman.

    On the subclient level I have checked use rman for log backup as well as the scheduling Delete archive log Older than 4 days and Checked Backed Up 2 Times which in my case should apply perfectly since Im backing up Oracle every 4 hours. Yet I still think Logs arent being deleted as they should by commvault.

    Couple questions...

    1- in the scheduling there are two tabs Backup Archive Logs and Delete Archive Logs, which both have the delete settings, which one should be setup?

    2- Commvault recommendation is to run the crosscheck, however if the log verification/deletion isnt working properly that will never work.

     

    Keep getting "error identifying file <\pathtologfile\logfile.arc>" and commvault docs references the article: https://ma.commvault.com/Article/Details/45657 so bypassing the working as you mentioned and the crosscheck above doesnt really give you a ideal resolution.

     

    Thanks for your time again.

  • Re: RMAN-06900 followed by RMAN-08138
    Posted: 04-04-2019, 5:25 PM
    • efg is not online. Last active: 05-20-2019, 11:53 AM efg
    • Top 10 Contributor
    • Joined on 02-02-2010
    • CommVault Tinton Falls NJ
    • Expert
    • Points 1,655

    1- in the scheduling there are two tabs Backup Archive Logs and Delete Archive Logs, which both have the delete settings, which one should be setup?

    Actually the backup tab doesn't really have delete settings.   There is a "delete" setting in the subclient properties which get disabled when the advanced job options delete gets enabled.  So only the delete settings from the advanced job options (from the schedule) are then used. 

    2- Commvault recommendation is to run the crosscheck, however if the log verification/deletion isnt working properly that will never work.

    Crosscheck will alert RMAN if logs get deleted so it won't attempt to back up logs that are "missing"  There is also an option in the subclient to also skip missing log files (which will send a warning, but still run the backup)  But this still potentially leaves a "hole" in the recovery schema.  Typically if logs are lost its best to run an incremental asap to fill the gap.

    My one recommendation is when using the "delete" from advanced options is to make sure that you also have the "delete logs backed up X times" selected as well, to make sure at least X backups are run for the logs before they are deleted.

     

    Let us know if this helps


    Ernst F. Graeler
    Senior Engineer III
    Development
  • Re: RMAN-06900 followed by RMAN-08138
    Posted: 04-04-2019, 11:21 PM

    So just to validate my understanding, you recommend;

    1- Under the subclient properties select "Use RMAN for Log Backup

    2- Under the Scheduling / Advanced 

    - Backup archive logs  Tabs (in my case I want to backup every single day would select Older than 0 days)

            - Delete archive Logs -> Older than 4 days and Backed up 2 times (I backup Oracle every 4 hours) So in this case I should always have at least 2 archive logs backed up and deleting them every 4 days correct?

  • Re: RMAN-06900 followed by RMAN-08138
    Posted: 04-05-2019, 9:05 AM
    • efg is not online. Last active: 05-20-2019, 11:53 AM efg
    • Top 10 Contributor
    • Joined on 02-02-2010
    • CommVault Tinton Falls NJ
    • Expert
    • Points 1,655

    Based on this setting:

    2- Under the Scheduling / Advanced 

    - Backup archive logs Tabs (in my case I want to backup every single day would select Older than 0 days)

            - Delete archive Logs -> Older than 4 days and Backed up 2 times (I backup Oracle every 4 hours) So in this case I should always have at least 2 archive logs backed up and deleting them every 4 days correct?

    For any given log file you will have 48 backups of that file.  Why not also select “Not backed up 2 times” in the backup options to limit the # of times a log gets backed up.  Not sure why you would want 48 copies of the same log file backed up.  With the “not backed up X times” setting you can limit the # of copies backed up.   Especially if your DB generates a sufficient # of log files on a given day.  This way the logs will get backed up at least 2 times and qualify for deletion.  You can always increase that # to perhaps 3 or 4 to garantee that the logs will meet the deletion rule.


    Ernst F. Graeler
    Senior Engineer III
    Development
  • Re: RMAN-06900 followed by RMAN-08138
    Posted: 04-05-2019, 9:10 AM

    Thanks for helping me to understand the pieces and puzzle around oracle. I appreciate it.

  • Re: RMAN-06900 followed by RMAN-08138
    Posted: 04-19-2019, 10:17 AM

    Is there a way for me to force the delete archive logs selected on the subclient level rather than the granular one also configured on the schedule policy?

    I have some clients that works better with the archive delete option from the subclient level better than the one on the schedule. I know I could create a different schedule but trying to keep it clean.

The content of the forums, threads and posts reflects the thoughts and opinions of each author, and does not represent the thoughts, opinions, plans or strategies of Commvault Systems, Inc. ("Commvault") and Commvault undertakes no obligation to update, correct or modify any statements made in this forum. Any and all third party links, statements, comments, or feedback posted to, or otherwise provided by this forum, thread or post are not affiliated with, nor endorsed by, Commvault.
Commvault, Commvault and logo, the “CV” logo, Commvault Systems, Solving Forward, SIM, Singular Information Management, Simpana, Commvault Galaxy, Unified Data Management, QiNetix, Quick Recovery, QR, CommNet, GridStor, Vault Tracker, InnerVault, QuickSnap, QSnap, Recovery Director, CommServe, CommCell, SnapProtect, ROMS, and CommValue, are trademarks or registered trademarks of Commvault Systems, Inc. All other third party brands, products, service names, trademarks, or registered service marks are the property of and used to identify the products or services of their respective owners. All specifications are subject to change without notice.
Close
Copyright © 2019 Commvault | All Rights Reserved. | Legal | Privacy Policy