ORA-21561, ORA-15055, ORA-25253 causes the DG slave database to be unable to apply Archive

ORA-21561, ORA-15055, ORA-25253 causes the DG slave database to be unable to apply Archive
Yesterday I went to a customer to do inspection, by the way, to see whether the last build of the RAC-DG environment is normal, the last DG was run in August 20, and the DG slave database since August 31 the instance has not been started, later, I learned that I had a power outage that day and then restarted the machine. I started the instance until today. That is to say, the Standby database has been in unused state for nearly one month from January 1, August 31 to today. Next, check the backup database archive. The last log of tnread1 is 1661, And the last log of tnread2 is 1324, at this time, the earliest logs retained in the master database were in September 8. thread 1 was 2055 at the earliest and thread 2 was 1555 at the earliest. There are hundreds of archive errors between the master and slave databases (normal, it's almost a month before the instance is started) ASMCMD> release/2014_09_09/2014_09_10/release/2014_09_19/2014_09_20/2014_09_21/release cd 2014_09_08ASMCMD> quit (omitted) ...... Round (Omitted )...... ASMCMD> although the archive is deleted using delete input after the archive is backed up in the script to reduce the disk space occupied by the archive, you can see it in the backup log of the RMAN script, since August 31, there have been reports of RMAN-08137, prompt because the slave database has not been archived, resulting in the failure to delete: archive log file name = + DATA/sis/archivelog/2014_08_31/thread_eclipseq_1661.1208.85701_81 RECID = 3930 STAMP = 857020.81rman-08133: warning: the archive log has not been deleted, because the backup or upstream capture process requires that it archive the log file name = + DATA/sis/archivelog/2014_08_31/thread_eclipseq_1662.1212.857042297 thread = 1 Series = 1662rman-08133, because the backup or upstream capture process requires it to archive the log file name = + DATA/sis/arch Ivelog/2014_09_01/thread_2_seq_1325.1204.857122335 thread = 2 sequence = 1325rman-08133: warning: the archive log is not deleted because it is required by the backup or upstream capture process, but the FRA disk space is limited, when a certain percentage is used (with parameters adjustable), Oracle automatically clears the content to free up space. Therefore, archive logs in FRA are retained for about 18 days, from October 25 to October 25, September 8-9, and archive on October 25, August 31, the latest backup set is only available on October 25, September 15. So I decided to re-build the DG, shut down the slave database instance, delete all database files (data files, control files, log files), and only keep the password files, parameter files, and tnsnames. ora, listener. ora is ready for reconstruction. Use the 11g duplicate command to re-Synchronize. The command is as follows: rman target/auxiliary sys/oracle @ sisdgRMAN> run {
Allocate channel c1 device type disk; allocate auxiliary channel c2 device type disk; set newname for tempfile 1 to 'd: \ app \ administrator \ oradata \ sis \ temp.269.852648395 '; duplicate target database for standby from active database dorecover; release channel c1; release channel c2;} after the above operations are performed, the archive between the slave database and the master database synchronizes the master database: SQL> archive log list database log mode archive mode automatic archiving enable archiving end point USE_DB_RECOVERY_FILE_DEST oldest online log sequence 2617 next archive log sequence 2619 current log sequence 2619SQL> select thread #, max (sequence #) from v $ archived_log group by thread #; THREAD # MAX (SEQUENCE #) ---------- -------------- 1 2619 2 2556 slave database: SQL> archive log list database log mode automatic archiving mode enable archiving end point D: \ archivelog earliest online log sequence 0 next archived log sequence 0 current log sequence 0SQL> select thread #, max (sequence #) from v $ archived_log group by thread #; THREAD # MAX (SEQUENCE #) ---------- ------------ 1 2619 2 2556 check the Master/Slave database v $ archive_dest_status, the status columns on both sides are valid. Therefore, enable redo apply for the slave database and check that the log has been applied to SQL> select thread #, sequence #, applied from v $ archived_log; THREAD # SEQUENCE # APPLIED ---------- -------------------- 1 2617 YES 1 2618 YES 2 2556 YES 1 2619 NO 1 2620 NO because the lgwr async mode is used to transmit logs, create a standby redo logfile again. Each thread in the master database has three groups of logs. Therefore, the slave database creates seven groups of logs.
In addition, an error is reported in the alertlog of the standby database because it is from the primary database duplicate, and the configuration information of RMAN retains some parameters of the primary database: Starting control autobackupGot error: 19624 ******************** WARNING ****************** * ******** The errors during Server autobackup are not fatal, as itis attempted after sucessful completion of the command. however, it is recomended to take an RMAN control filebackup as soon as possible because the Autobackup failedwith the following Error: ORA-19624: operation failed, retry possibleORA-19504: failed to create file "C: \ ORABACKUP \ BACKUPSETS \ SIS1-C-3160648191-20140925-02.CTL" ORA-27040: file create error, unable to create fileOSD-04002: unable to open file O/S-Error: (OS 3) the system cannot find the specified path. * ****************** End of warning ***************** **

For more details, please continue to read the highlights on the next page:

 

Install Oracle 11gR2 (x64) in CentOS 6.4)

Steps for installing Oracle 11gR2 in vmwarevm

Install Oracle 11g XE R2 In Debian

Important configuration parameters of Oracle Data Guard

Configure Oracle 11g Data Guard based on the same host

Explore Oracle 11g elastic uard

Oracle Data Guard (RAC + DG) archive deletion policies and scripts

Role conversion for Oracle Data Guard

FAL gap in Oracle Data Guard logs

Oracle 11g Data Guard Error 16143 Heartbeat failed to connect to standby

1 2 Next Page