The warning related the arch process!

Got some warnings from the alert log。

Tue Mar 8 13:45:26 2011
Starting control autobackup
Control autobackup written to DISK device
handle '/global/oracle3/ORADUMP/ARSPRD/backup/ARSPRD_rman_ctrl_c-909397006-20110308-01.bak'
Tue Mar 8 20:00:34 2011
Thread 1 advanced to log sequence 24677
Tue Mar 8 20:00:34 2011
ARC0: Evaluating archive log 1 thread 1 sequence 24676
Tue Mar 8 20:00:34 2011
Current log# 2 seq# 24677 mem# 0: /global/oracle/oradata1/ARSPRD/redo02.log
Tue Mar 8 20:00:34 2011
ARC0: Beginning to archive log 1 thread 1 sequence 24676
Creating archive destination LOG_ARCHIVE_DEST_1: '/global/oracle/oradump1/ARSPRD/archive/arch1_24676.dbf'
Tue Mar 8 20:00:36 2011
ARC1: Evaluating archive log 1 thread 1 sequence 24676
ARC1: Unable to archive log 1 thread 1 sequence 24676
Log actively being archived by another process
Tue Mar 8 20:00:43 2011
ARC0: Completed archiving log 1 thread 1 sequence 24676
Wed Mar 9 01:00:06 2011
Thread 1 advanced to log sequence 24678
Wed Mar 9 01:00:06 2011
Current log# 3 seq# 24678 mem# 0: /global/oracle/oradata1/ARSPRD/redo03.log
Wed Mar 9 01:00:06 2011
ARCH: Evaluating archive log 2 thread 1 sequence 24677
Wed Mar 9 01:00:06 2011
ARC0: Evaluating archive log 2 thread 1 sequence 24677
ARC0: Unable to archive log 2 thread 1 sequence 24677
Wed Mar 9 01:00:06 2011
ARCH: Beginning to archive log 2 thread 1 sequence 24677
Wed Mar 9 01:00:06 2011
Log actively being archived by another process
Wed Mar 9 01:00:06 2011
Creating archive destination LOG_ARCHIVE_DEST_1: '/global/oracle/oradump1/ARSPRD/archive/arch1_24677.dbf'
ARCH: Completed archiving log 2 thread 1 sequence 24677
Wed Mar 9 01:00:16 2011
Thread 1 advanced to log sequence 24679
Wed Mar 9 01:00:16 2011
ARCH: Evaluating archive log 3 thread 1 sequence 24678
Wed Mar 9 01:00:16 2011
Current log# 1 seq# 24679 mem# 0: /global/oracle/oradata1/ARSPRD/redo01.log
Wed Mar 9 01:00:16 2011
ARC1: Evaluating archive log 3 thread 1 sequence 24678
Wed Mar 9 01:00:16 2011
ARC1: Unable to archive log 3 thread 1 sequence 24678
Wed Mar 9 01:00:16 2011
ARCH: Beginning to archive log 3 thread 1 sequence 24678

Seems that there are two arch processes want to archive one archive logs.

The ARC0 has done it then ARC1 is unable to archive it again.

So we should cut off one if there are really two processes to archive logs.

Check it:

$ ps -ef|grep ora_arc
oracle 3463 1 0 May 26 ? 73:39 ora_arc0_ARSPRD
oracle 3465 1 0 May 26 ? 0:11 ora_arc1_ARSPRD
oracle 21125 20978 0 01:43:08 pts/1 0:00 grep ora_arc

SQL> show parameter log_archive_max_processes

NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
log_archive_max_processes integer 2
SQL>

Read the Note:

Purpose

When archiving locally and remotely using the ARCH process where the remote destination is across a saturated or slow network you can receive the following errors in the alert log:



ARC0: Evaluating archive log 2 thread 1 sequence 100

ARC0: Unable to archive log 2 thread 1 sequence 100

Log actively being archived by another process



If the ARCH process is unable to archive at the rate at which online logs are switched then it is possible for the primary database to suspend while waiting for archiving to complete.The following discussion describes how this can occur.


Default Behavior for 9iR2 and Below


The ARCH process sits in a very tight loop waiting for an update to the controlfile that states an online log needs to be archived.Once the update occurs the ARCH process builds a list of archive destinations that need to be serviced.Once this list is complete, the ARCH process will read a one megabyte chunk of data from the online log that is to be archived.This one megabyte chunk is then sent to the first destination in the list.When the write has completed, the same one megabyte chunk is written to the second destination.This continues until all of the data from the online log being archived has been written to all destinations.So it can be said that archiving is only as fast as the slowest destination.



A common misconception is that if the LOG_ARCHIVE_DEST_n parameter for a particular destination has the OPTIONAL attribute set, then that destination will not impede local archiving. This is true during error situations while archiving to that destination - e.g. a network disconnect error, but not during an archival over a slow network, which is not an error situation. In error situations, whether the destination is marked OPTIONAL or MANDATORY, Data Guard will close that destination and continue transmitting to all other valid destinations. Transmitting to the closed destination will be attempted again only after the time specified in the REOPEN attribute has expired and a log switch has occurred.This process will continue for the number of times specified by the MAX_FAILURE attribute. During this time, it is possible that the log writer process recycles through the available online redo log groups and tries to use the online redo log file which has not yet been transmitted successfully to the remote destination. If the destination is marked OPTIONAL, log writer will reuse the online redo log file for the next set of redo. If the destination is marked MANDATORY,log writer will not be able to reuse that online redo log file, and the primary database will delay processing until that online redo log file has been successfully transmitted to the remote destination.

However, the situation is very different if the transmission is being done over a slow network. In this case, no error is encountered and the destination is not closed. Transmission continues, but is very slow. Ultimately, with the unavailability of any more online redo log groups, Log writer may suspend because the archive process is taking a long time to complete its archival, including local archival.



Refining the Default Behavior


The following underscore parameter was introduced as of 9.2.0.5 to allow the DBA to change this default behavior:



_LOG_ARCHIVE_CALLOUT='LOCAL_FIRST=TRUE'



If the above parameter is set then the ARCH process will begin archiving to the local destination first.Once the redo log has been completely and successfully archived to at least one local destination, it will then be transmitted to the remote destination. This is the default behavior beginning with Oracle Database 10g Release 1.





Starting in 9.2.0.7 patchsets, one ARCH process will begin acting as a 'dedicated' archiver, handling only local archival duties. It will not perform remote log shipping or service FAL requests. This is a backport of behavior from 10gR1 to 9iR2.



From Metalink: 260040.1