The disk space of the DG slave database is full, leading to the failure to create an archive.

The disk space of the DG slave database is full, leading to the failure to create an archive.
Last Friday, I went to a customer to perform database inspection. It was the database of a 10 Gb NC System on Windows 2008 and configured with DG. However, I found the database error during inspection:
Tue Nov 11 10:13:57 2014LNS: Standby redo logfile selected for thread 1 sequence 3945 for destination LOG_ARCHIVE_DEST_2Tue Nov 11 10:14:29 2014 Errors in file d: \ oracle \ product \ 10.2.0 \ admin \ nc \ bdump \ nc_arc0_177356.trc: ORA-16401: archivelog rejected by RFS
FAL [server, ARC0]: FAL archive failed, see trace file. sun Nov 16 04:05:12 2014 Errors in file d: \ oracle \ product \ 10.2.0 \ admin \ nc \ bdump \ nc_arc0_177356.trc: ORA-16055: FAL request rejected
ARCH: FAL archive failed. Archiver continuingSun Nov 16 04:05:15 2014 Errors in file d: \ oracle \ product \ 10.2.0 \ admin \ nc \ bdump \ nc_arc0_177356.trc: ORA-00270: error creating archive log
The system prompts that the archive log is rejected by the RFS process, and the FAL process request is rejected.
* ** 10:14:29. 806 tkcrrsarc: (WARN) Failed to find ARCH for message (message: 0x2) tkcrrpa: (WARN) Failed initial attempt to send ARCH message (message: 0x2) error 16401 creating standby archive log file at host 'cdg' ORA-16401: archivelog rejected by RFS *** 10:15:29. 900 tkcrrsarc: (WARN) Failed to find ARCH for message (message: 0x2) tkcrrpa: (WARN) Failed initial attempt to send ARCH message (message: 0x2) error 16401 creating standby archive log file at host 'cdg' ORA-16401: archivelog rejected by RFS *** 10:16:29. 962 tkcrrsarc: (WARN) Failed to find ARCH for message (message: 0x2) tkcrrpa: (WARN) Failed initial attempt to send ARCH message (message: 0x2) error 16401 creating standby archive log file at host 'cdg' ORA-16401: archivelog rejected by RFS *** 10:17:30. 025 tkcrrsarc: (WARN) Failed to find ARCH for message (message: 0x2) tkcrrpa: (WARN) Failed initial attempt to send ARCH message (message: 0x2) error 16401 creating standby archive log file at host 'cdg' ORA-16401: archivelog rejected by RFS *** 10:18:30. 088 tkcrrsarc: (WARN) Failed to find ARCH for message (message: 0x2) tkcrrpa: (WARN) Failed initial attempt to send ARCH message (message: 0x2) error 16401 creating standby archive log file at host 'cdg' ORA-16401: archivelog rejected by RFS
Check the trace file nc_arc0_177356.trc. It is reported that an error has been reported since 10:14 A.M., January 1, November 11. If the target host cannot create an archive log file, an error is reported once every one minute. view it in the slave database, it was found that because the archive logs passed by the master database were not cleared regularly, the disk space was exhausted!



70 GB space is used up, because the customer's disk is relatively small, some of them are also used to store data files, it will occupy 47 GB.


The last archived log was generated at on July 25, November 11, and will not be available later. This is also consistent with the error reported in the trace file, because the last space of the disk is exhausted at this time, in this case, the error of remote archiving cannot be created in the alarm log of the master database. Now that the problem is found, it is easy to handle it. First, the archive applied by the slave database is deleted, release disk space.
Due to the GAP in the backup database archive, and these gaps are no longer available in the archive of the master database, the master database does not keep a lot of archives, and the archive log is not used as a backup set separately, therefore, you can only reconfigure the DG Configuration.
Today, the customer re-configured the DG. The procedure is actually very simple, because it has been configured once before. This time, you only need to synchronize it. You do not need to modify the parameters, copy the parameter file, password file, and tnsnames. ora, listener. ora, etc. You only need to create a slave Database Control file in the master database, and then take the RMAN backup set of the master database to the slave database for recovery. The specific process will not be written here. After configuring the DG, check the archiving path status on both sides. If no error is found, enable redo apply. Then, the slave database synchronizes data with the master database.
Because the available disk space is still relatively small, this time we have configured a script for the customer to automatically delete the archive logs of the standby database. The script mainly uses three files, which are roughly as follows:
-- Delete_dg_archivelogCd D: \ archivelogdeld: sqlplus/as sysdba @ delete_archive. SQL echo rman target/partition file = rman_checkcross.rman> delete_archivelog.bat> interval _ % DATE :~ 0, 4% % DATE :~ 5, 2% % DATE :~ 8, 2% ". log exit
-- Delete_archive. SQLSet lines 150 col name for a150 set pagesize 0 feedback off verify off heading off echo off spool deletdelete_archivelog.bat select 'del '| name from v $ archived_log where APPLIED = 'yes' AND NAME IS not null and DEST_ID = 1; spool off exit;
-- Rman_checkcross.rmanCrosscheck archivelog all; delete noprompt expired archivelog all; exit
The following describes the script. The first bat script calls the delte_archive. SQL and rman_checkcross.rman command files. The most important one is the execution content of the delete_archive. SQL script, use SQL concatenation to find archive files that have been applied, generate del commands, delete them at the OS level, and then call the rman command for cross-validation, finally, delete the expired archive logs (OS-level deletion also notifies the control file that these archives do not exist and need to be deleted). If the logs have not been applied in the slave database, the previous select statement will not query travel records.
When the select statement in delete_archivelog. SQL used DEST_ID = 1 for the first time today, no data rows were found and the result was obtained only when DEST_ID = 2 was used, however, when DEST_ID = 2 is used, the result is not returned, so DEST_ID = 1 is returned. In fact, the most important thing is to pay attention to the running results of SQL scripts. Otherwise, the previous commands will not work. If there is no result, the OS commands will not go to the del files, if these files are not del-deleted at the OS level, RMAN will not check whether the files are expired, so the archived records will not be deleted from the control files.
Finally, add the script to the windows Task Plan for regular operation. Because the customer's log switching frequency is not high, it is tentatively set to clear the archive once a week.