Controlling Trace Output Generated by the Archivelog Process

Background processes always write to a trace file when appropriate. (See the discussion of this topic in "Monitoring Errors with Trace Files and the Alert Log".) In the case of the archivelog process, you can control the output that is generated to the trace file. You do this by setting the LOG_ARCHIVE_TRACE initialization parameter to specify a trace level. The following values can be specified:

Trace Level Meaning
0 Disable archivelog tracing. This is the default.
1 Track archival of redo log file.
2 Track archival status for each archivelog destination.
4 Track archival operational phase.
8 Track archivelog destination activity.
16 Track detailed archivelog destination activity.
32 Track archivelog destination parameter modifications.
64 Track ARCn process state activity.
128 Track FAL (fetch archived log) server related activities.
256 Supported in a future release.
512 Tracks asynchronous LGWR activity.
1024 RFS physical client tracking.
2048 ARCn/RFS heartbeat tracking.
4096 Track real-time apply
8192 Track redo apply activity (media recovery or physical standby)

You can combine tracing levels by specifying a value equal to the sum of the individual levels that you would like to trace. For example, setting LOG_ARCHIVE_TRACE=12, will generate trace level 8 and 4 output. You can set different values for the primary and any standby database.

The default value for the LOG_ARCHIVE_TRACE parameter is 0. At this level, the archivelog process generates appropriate alert and trace entries for error conditions.

You can change the value of this parameter dynamically using the ALTER SYSTEM statement. The database must be mounted but not open. For example:


Changes initiated in this manner will take effect at the start of the next archiving operation.

See Also:

Oracle Data Guard Concepts and Administration for information about using this parameter with a standby database