In Linux, Data Guard cannot apply the process of archiving logs.

Environment:
OS: Red Hat Linux As 5
DB: 11.2.0.1

Today, we found that the data was written to the table of the master database. After switching logs, we found that the data was not transmitted to the slave database. The following error is reported when you view the alert of the slave database:

Datafiles are recovered to a consistent state at change 2610390 but controlfile is ahead at change 2610391.
Database remains open for continuous queries. Please continue recovery.
Errors in file/u01/app/Oracle/diag/rdbms/oraclbak/trace/oraclbak_mrp0_4332.trc:
ORA-01237: cannot extend datafile 4
ORA-01110: data file 4: '/u01/app/oracle/oradata/L/users01.dbf'
ORA-19502: write error on file "/u01/app/oracle/oradata/maid/users01.dbf", block number 723584 (block size = 8192)
ORA-27072: File I/O error.
Linux Error: 25: Inappropriate ioctl for device
The above error should be caused by insufficient users tablespaces, but the data files in users tablespaces are automatically extended. How can I report that the data files cannot be extended, when df is used in the master and slave databases to view disk space, it is found that the directory of the data file user01.dbf is full. In this case, the files under this directory are cleaned up immediately to free up some space. the process is as follows.
 
1. view the disk usage of the master and slave Databases
[Oracle @ stdby oracl] $ df
Filesystem 1K-blocks Used Available Use % Mounted on
/Dev/sda1 6146832 4321584 1507968 75%/
Tmpfs 2097152 400408 1696744 20%/dev/shm
/Dev/sdb1 20635700 19525276 62188 100%/u01
/Dev/sdc1 8254240 6356052 1478896 82%/u02

We found that the directory/u01 for storing data files already uses 100%.
 
2. view log usage on the slave Database
Select Sequence #, Name, Applied From V $ archived_Log Order By Sequence #;
------------------------------------------------------------------------
SEQUENCE # NAME APPLIED
9/u02/archive_log/rj9_792174458.dbf YES
10/u02/archive_log/201710_792174458.dbf YES
11/u02/archive_log/201711_792174458.dbf YES
12/u02/archive_log/201712_792174458.dbf YES
13/u02/archive_log/41513_792174458.dbf YES
14/u02/archive_log/41514_792174458.dbf YES
15/u02/archive_log/41515_792174458.dbf YES
16/u02/archive_log/41516_792174458.dbf YES
17/u02/archive_log/41517_792174458.dbf YES
18/u02/archive_log/41518_792174458.dbf YES
19/u02/archive_log/1_19_792174458.dbf YES
20/u02/archive_log/201720_792174458.dbf YES
21/u02/archive_log/41521_792174458.dbf YES
22/u02/archive_log/41522_792174458.dbf YES
23/u02/archive_log/41523_792174458.dbf YES
24/u02/archive_log/41524_792174458.dbf YES
25/u02/archive_log/41525_792174458.dbf YES
26/u02/archive_log/41526_792174458.dbf YES
27/u02/archive_log/41527_792174458.dbf YES
28/u02/archive_log/41528_792174458.dbf YES
29/u02/archive_log/41529_792174458.dbf YES
30/u02/archive_log/41530_792174458.dbf YES
31/u02/archive_log/201731_792174458.dbf YES
32/u02/archive_log/41532_792174458.dbf YES
33/u02/archive_log/41533_792174458.dbf YES
34/u02/archive_log/201734_792174458.dbf NO
35/u02/archive_log/41535_792174458.dbf NO

No use found for 34 and 35
 
3. After the master and slave databases make up some space, use the following command on the slave database to apply logs:
Recover managed standby database disconnect from session;
 
4. view the log application process at this time
Select process, status, sequence # from v $ managed_standby;
--------------------------------------------------
Process status sequence #
Arch closing 34
Arch closing 35
Arch closing 31
Arch connected 0
MRP0 APPLYING_LOG 35
Rfs idle 0
Rfs idle 0
Rfs idle 36

5. query the log application status of the slave database again
Select Sequence #, Name, Applied
From V $ archived_Log Order By Sequence #;
-----------------------------------------
SEQUENCE # NAME APPLIED
9/u02/archive_log/rj9_792174458.dbf YES
10/u02/archive_log/201710_792174458.dbf YES
11/u02/archive_log/201711_792174458.dbf YES
12/u02/archive_log/201712_792174458.dbf YES
13/u02/archive_log/41513_792174458.dbf YES
14/u02/archive_log/41514_792174458.dbf YES
15/u02/archive_log/41515_792174458.dbf YES
16/u02/archive_log/41516_792174458.dbf YES
17/u02/archive_log/41517_792174458.dbf YES
18/u02/archive_log/41518_792174458.dbf YES
19/u02/archive_log/1_19_792174458.dbf YES
20/u02/archive_log/201720_792174458.dbf YES
21/u02/archive_log/41521_792174458.dbf YES
22/u02/archive_log/41522_792174458.dbf YES
23/u02/archive_log/41523_792174458.dbf YES
24/u02/archive_log/41524_792174458.dbf YES
25/u02/archive_log/41525_792174458.dbf YES
26/u02/archive_log/41526_792174458.dbf YES
27/u02/archive_log/41527_792174458.dbf YES
28/u02/archive_log/41528_792174458.dbf YES
29/u02/archive_log/41529_792174458.dbf YES
30/u02/archive_log/41530_792174458.dbf YES
31/u02/archive_log/201731_792174458.dbf YES
32/u02/archive_log/41532_792174458.dbf YES
33/u02/archive_log/41533_792174458.dbf YES
34/u02/archive_log/201734_792174458.dbf YES
35/u02/archive_log/41535_792174458.dbf YES
 
At this time, all 34 and 35 have been applied, and the data at the application layer, master database and slave database have been consistent.

-- The End --