Pavan DBA's Blog

The DBA Knowledge Store

Resolving ORA-19588: archived log recid stamp is no longer valid

Posted by Pavan DBA on January 18, 2011

Sometimes you may find the following error in RMAN archive backup or online backup logfile

ORA-19588: archived log recid 24909 stamp 740658206 is no longer valid

This is not an error but a warning. The reason for this is archive logfile which this process is trying to take backup, is already been backed up by another process and file is deleted

This situation will occur if both archive backup job and full database backup (including archives) are executing at same time or two archive backup jobs executing at same time.

So to avoid this we have two ways

1. If you want to run a manual backup, just check whether any other RMAN backups are in execution phase. you can do this by

[oracle@viadbscph014 logs]$ ps -ef | grep rman

If any backup process is running, you will see a similar output as below

[oracle@viadbscph014 logs]$ ps -ef | grep rman
root      3022  3015  0 00:15 ?        00:00:00 su – oracle -c ?ORACLE_HOME=/opt/oracle/oracle/product/10.2.0?export ORACLE_HOME?ORACLE_SID=dwh2?export ORACLE_SID?/opt/oracle/oracle/product/10.2.0/bin/rman target / nocatalog msglog /opt/oracle/admin/DWH2/backup/logs/online_backup_20110118.out append << EOF?RUN {?ALLOCATE CHANNEL ch00 TYPE sbt PARMS=’ENV=(NB_ORA_SCHED=Default-Application-Backup,NB_ORA_CLIENT=viadbscph014)’;?ALLOCATE CHANNEL ch01 TYPE sbt PARMS=’ENV=(NB_ORA_SCHED=Default-Application-Backup,NB_ORA_CLIENT=viadbscph014)’;?BACKUP?    INCREMENTAL LEVEL=0?    SKIP INACCESSIBLE?    FILESPERSET 5?    # recommended format?    FORMAT ‘bk_%s_%p_%t_%U’?    DATABASE;?    sql ‘alter system archive log current’;?RELEASE CHANNEL ch00;?RELEASE CHANNEL ch01;?# backup all archive logs?ALLOCATE CHANNEL ch00 TYPE sbt PARMS=’ENV=(NB_ORA_SCHED=Default-Application-Backup,NB_ORA_CLIENT=viadbscph014)’;?ALLOCATE CHANNEL ch01 TYPE sbt PARMS=’ENV=(NB_ORA_SCHED=Default-Application-Backup,NB_ORA_CLIENT=viadbscph014)’;?BACKUP?   filesperset 20?   FORMAT ‘al_%s_%p_%t_%U’?   ARCHIVELOG ALL DELETE INPUT;?  # ARCHIVELOG ALL;?RELEASE CHANNEL ch00;?RELEASE CHANNEL ch01;?#?# Note: During the process of backing up the database, RMAN also backs up the?# control file.  This version of the control file does not contain the?# information about the current backup because nocatalog has been specified.?# To include the information about the current backup, the control file should?# be backed up as the last step of the RMAN section.  This step would not be?# necessary if we were using a recovery catalog.?#?ALLOCATE CHANNEL ch00 TYPE sbt PARMS=’ENV=(NB_ORA_SCHED=Default-Application-Backup,NB_ORA_CLIENT=viadbscph014)’;?BACKUP?    # recommended format?    FORMAT ‘cntrl_%s_%p_%t_%U’?    CURRENT CONTROLFILE;?    sql ‘alter database backup controlfile to trace’;?    sql “alter database backup controlfile to ”/opt/oracle/oracle/product/10.2.0/dbs/dwh2_backup_controlfile.ctl” reuse”;??RELEASE CHANNEL ch00;?}?EOF?
Note: Output may differ. In my case RMAN backup is initiated through Netbackup tool

2. Don’t schedule archive backup job during full database backup (including archivelog). Always make sure you have only one RMAN backup in process

8 Responses to “Resolving ORA-19588: archived log recid stamp is no longer valid”

  1. naresh kumar said

    Hi Pavan sir ,

    today i faced this issue while inc0 backup is running , but after that archive backup is success and inc2 backup is running currently , so how can i proceed further . can i wait for inc2 success or do i need to trigger inc0 as well .

    % ps -ef | grep rman
    oracle 689 662 0 21:15 ? 00:00:00 /bin/ksh /usr/software/oracle/rman/scripts/ -d pvt052 -t inc2
    oracle 730 689 0 21:15 ? 00:00:02 rman software/oracle/product/10.2.0/db/bin/rman
    oracle 13535 7429 0 22:59 pts/4 00:00:00 grep rman

    Best Regards ,

  2. Greg said

    While these are solutions for the ORA-19588, they don’t address the problem of meeting an SLA for recovery point objective (RPO). For example your database backup takes 3 hours and you have an SLA for RPO of 30 minutes. If you don’t make a backup of the logs during the database backup you will be in violation of your SLA for RPO. With many business systems being 24X7 an SLA for RPO is more common and something which must be considered when designing your backup strategy. Dataguarding the database removes this concern, but sometimes there are not resources to dataguard all your systems.

    • Pavan DBA said

      Hi Greg,

      totally agree with your point. when i say don’t take archivelog backup when full backup is going on i expect archivelog backup is included in full backup (i.e using backup database plus archivelog command)

      Thanks for highlighting this to me. I corrected the statement now.

  3. shape said

    Thanks for finally writing about >Resolving ORA-19588: archived log recid stamp
    is no longer valid Pavan DBA’s Blog <Liked it!

  4. Binoy said

    Thanks for providing the info, I stumped upon the exact issue.

  5. andreas said

    Hi Pavan
    to avoid full archive destinations, archlog backups must be able to run during level backups. Otherwise, the DB will hang if the archive destination gets full.
    Use v$session to update and query to get info about running level backups. By no means use ps to grep for rman sessions.

    –> Schedule Archlog Backups regardless of level Backups.
    –> use “set command id to ‘level ‘ ;” inside your rman code to update v$session. Query client_info from v$session at backup start. If level is found, exit backup script or fall in wait loop.
    hth, Andreas

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: