Today I visited a customer, who deleted a Data Guard configuration (i.e. a temporary Data Guard setup through the broker was deleted). The LOG_ARCHIVE_DEST_STATE_2 on the primary database was set to DEFER temporarily. That resulted in trace-files with name *tt*.trc to become huge (GBytes after a couple of days). Analysis showed that this was caused by bug 23300142 in 12.1.0.2. See My Oracle Support Note

Bug 23300142 - TT background process trace file message: async ignored current log: kcclenal clear thread open (Doc ID 23300142.8)

for details.
Unfortunately the bug does not have a workaround.
Due to the fact that the affected development-databases (which were now normal single instances without Data Guard) could not be restarted, I searched for a temporary workaround to stop the trace-files from growing further. Limiting the trace-file size on the database with

alter system set max_dump_file_size='100M';

did actually not always work to limit the file size. Here an example of a huge trace file (over 5GB):


$ find . -name "*tt*.trc" -ls | tr -s " " | cut -d " " -f7-11 | sort -n
...
5437814195 Apr 7 10:46 ./xxxxxx_site1/XXXXXX/trace/XXXXXX_tt00_28304.trc

However, what came in handy was the uts-trace-segmentation feature of 12c. See Jonathan Lewis’ blog here:

Trace file size

I.e. I left all DBs on max_dump_file_size=unlimited and set


SQL> alter system set "_uts_first_segment_size" = 52428800 scope=memory;
SQL> alter system set "_uts_trace_segment_size" = 52428800 scope=memory;

Unfortunately setting the limit to the tt-background-process alone does not work:


SQL> exec dbms_system.set_int_param_in_session(sid => 199, serial# => 44511, parnam => '_uts_trace_segment_size', intval => 52428800);
BEGIN dbms_system.set_int_param_in_session(sid => 199, serial# => 44511, parnam => '_uts_trace_segment_size', intval => 52428800); END;
 
*
ERROR at line 1:
ORA-44737: Parameter _uts_trace_segment_size did not exist.
ORA-06512: at "SYS.DBMS_SYSTEM", line 117
ORA-06512: at line 1

With the default setting of “_uts_trace_segments” (Maximum number of trace segments) = 5 I could limit the maximum size of the trace of 1 DB to 250MB (50MB * 5). Below you can see only 4 files, because of 2 tests with earlier splittings of the trace-file:


$ ls -ltr *_tt00_28304*.trc
-rw-r----- 1 oracle dba 52428964 Apr 7 14:14 XXXXXX_tt00_28304_3.trc
-rw-r----- 1 oracle dba 52428925 Apr 7 16:07 XXXXXX_tt00_28304_4.trc
-rw-r----- 1 oracle dba 52428968 Apr 7 17:12 XXXXXX_tt00_28304_5.trc
-rw-r----- 1 oracle dba 43887950 Apr 7 18:50 XXXXXX_tt00_28304.trc

The feature of segmented trace-files may help a lot in situations like bug 23300142.

REMARK: Do not use underscore parameters in production environments without agreement from Oracle Support.