Details contained in an "exception" message in Oracle database logs

Today, when I sorted out the server information, I found that a crontab job was not set for one server. Generally, some scheduled tasks may be required on the server to trigger some backups,

Today, when I sorted out the server information, I found that a crontab job was not set for one server. Generally, some scheduled tasks may be required on the server to trigger some backups,

Today, when I sorted out the server information, I found that a crontab job was not set for one server. Generally, some scheduled tasks may be required on the server to trigger backup and cleanup tasks.
Because this is a slave database machine with a slave database of 11gR2 on it, the primary task is to check whether logs are properly applied.
From the log point of view, archiving has been applied normally. However, some relatively unfamiliar operations appear in the log.
Archived Log entry 68735 added for thread 1 sequence 95373 ID 0x70141a28 dest 1:
Tue Aug 04 16:00:29 2015
Media Recovery Waiting for thread 1 sequence 95374 (in transit)
Recovery of Online Redo Log: Thread 1 Group 4 Seq 95374 Reading mem 0
Mem #0:/U01/app/Oracle/oradata/xxxxxx/std_redo04.log
Tue Aug 04 16:22:32 2015
RFS [6]: Selected log 5 for thread 1 sequence 95375 dbid 1880348712 branch 828552874
Tue Aug 04 16:22:32 2015
Deleted Oracle managed file/U01/app/oracle/fast_recovery_area/xxxxxx/archivelog/2015_07_15/o1_mf_000092947_btbdqpm3 _. arc
Tue Aug 04 16:22:32 2015
Media Recovery Waiting for thread 1 sequence 95375 (in transit)
Recovery of Online Redo Log: Thread 1 Group 5 Seq 95375 Reading mem 0
Mem #0:/U01/app/oracle/oradata/xxxxxx/std_redo05.log
Archived Log entry 68736 added for thread 1 sequence 95374 ID 0x70141a28 dest 1:
Tue Aug 04 16:45:30 2015
RFS [6]: Selected log 4 for thread 1 sequence 95376 dbid 1880348712 branch 828552874
Tue Aug 04 16:45:30 2015
Deleted Oracle managed file/U01/app/oracle/fast_recovery_area/xxxxxx/archivelog/2015_07_15/o1_mf_1_92948_btbdqwmt _. arc
Tue Aug 04 16:45:30 2015
Media Recovery Waiting for thread 1 sequence 95376 (in transit)
Recovery of Online Redo Log: Thread 1 Group 4 Seq 95376 Reading mem 0
Mem #0:/U01/app/oracle/oradata/xxxxxx/std_redo04.log
Archived Log entry 68737 added for thread 1 sequence 95375 ID 0x70141a28 dest 1:
According to this frequency, it seems that each time an archive is accepted, an automatic deletion will be triggered to archive the operation.
This operation is obviously not triggered in crontab, because crontab is not enabled, even if it is enabled, these operations will not be synchronized so closely, and the database log will not contain this information.
I checked some related posts with questions. One of the articles was written by Lao Xiong,
The article also provides a metalink link.
Files being deleted in the flash recovery area, messages in the alert log Deleted Oracle managed file (Documentation ID 1369341.1)
For this problem, Oracle will set a threshold value starting from 11gR2 based on the size of the flash recovery zone. The default value is 80%, that is, if the archive space usage exceeds 80%, the archive will be deleted automatically.
It can be verified in the current environment.
SQL> show parameter recover
NAME TYPE VALUE
-----------------------------------------------------------------------------
Db_recovery_file_dest string/U01/app/oracle/fast_recovery_area
Db_recovery_file_dest_size big integer 120G
View the usage of the flash back area as follows:
[Fast_recovery_area] $ du-sh ./*
18 M./hxxxx
96G./SHxxxxx
If you look at it carefully, you will find that a large number of archive files have been generated recently.
...
3.9G./2015_07_23
3.8G./2015_07_24
3.9G./2015_07_25
3.9G./2015_07_26
8.7G./2015_07_27
3.9G./2015_07_28
4.1G./2015_07_29
4.0G./2015_07_30
4.3G./2015_07_31
4.1G./2015_08_01
4.1G./2015_08_02
8.9G./2015_08_03
3.2G./2015_08_04
Of course, the system-level view does not seem clear enough. We can try to see it at a glance.
SQL> select * from V $ RECOVERY_AREA_USAGE;
FILE_TYPE PERCENT_SPACE_USED PERCENT_SPACE_RECLAIMABLE NUMBER_OF_FILES
------------------------------------------------------------------------------
Control file 0 0 0
Redo log 0 0 0
Archived log 79.98 79.92 2427
Backup piece 0 0 0
Image copy 0 0 0
Flashback log 0 0 0
Foreign archived log 0 0 0
We can see that the current usage has reached 79.98%, which is already at the trigger critical point.
I understand the cause and it is much easier to solve it. I am also glad that this database is a 11gR2 database. Otherwise, I may receive an alert message in the near future.
Delete the archive, or directly use rman. You can use the following script to simply delete the archive one day ago.
Rman target/< Configure archivelog deletion policy to applied on all standby;
Crosscheck archivelog all;
Delete noprompt expired archivelog all;
Delete noprompt archivelog until time "sysdate-1 ";
Exit
EOF