Oracle 19c on Windows may flood your trace file directory

Oh … it’s Windows week here. And all this even though since I didn’t install Oracle on Windows for quite a while. But of course I’m fully aware that many of you out there operate Oracle on Windows. In this particular case thanks to Joël for the pointer to this issue. Oracle 19c on Windows may flood your trace file directory.

What happens?

In every release of Oracle 19c, at least until 19.10.0 BP, you may find out that every few minutes a trace file gets written into the %ORACLE_BASE%\diag\..\..\trace directory. And all of these files contain messages like these:

Required IPC RDMAV_FORK_SAFE environment not set
Required IPC RDMAV_HUGEPAGES_SAFE environment not set

Of course, you could easily delete them.

Why is this happening?

This happens because Linux environment variable checks have slipped into the generic codeline – and hence will error out under certain circumstances on Windows. This is not dangerous – but if you don’t pay attention, you may end up with 10-thousands of trace files.

You can find more information in MOS Note: 2588705.1 – 19c Database On Windows – ADR Is Flooded By Linux-related Trace Files.

Is there a Workaround?

The MOS Note: 2588705.1 proposes a workaround. You should set RDMAV_FORK_SAFE and RDMAV_HUGEPAGES_SAFE to 0. I guess, you should set it in addition to the user’s environment which runs the Oracle Service.

Another workaround coming to my mind and not in the note may be to change the ADRCI retention for less important traces.

Enter ADRCI:

$ adrci

ADRCI: Release - Production on Thu Mar 11 16:17:49 2021

Copyright (c) 1982, 2019, Oracle and/or its affiliates.  All rights reserved.

ADR base = "/u01/app/oracle"

adrci> show homes
ADR Homes: 

adrci> set home diag/rdbms/cdb2/CDB2

adrci> show control

ADR Home = /u01/app/oracle/diag/rdbms/cdb2/CDB2:
ADRID                SHORTP_POLICY        LONGP_POLICY         LAST_MOD_TIME                            LAST_AUTOPRG_TIME                        LAST_MANUPRG_TIME                        ADRDIR_VERSION       ADRSCHM_VERSION      ADRSCHMV_SUMMARY     ADRALERT_VERSION     CREATE_TIME                              SIZEP_POLICY         PURGE_PERIOD         FLAGS                PURGE_THRESHOLD      
-------------------- -------------------- -------------------- ---------------------------------------- ---------------------------------------- ---------------------------------------- -------------------- -------------------- -------------------- -------------------- ---------------------------------------- -------------------- -------------------- -------------------- -------------------- 
2334187521           720                  8760                 2019-04-28 00:18:35.957176 +02:00        2019-05-20 21:33:48.508472 +02:00                                                 1                    2                    110                  1                    2019-04-28 00:18:35.957176 +02:00        18446744073709551615 0                    0                    95                  
1 row fetched

adrci> set control (SHORTP_POLICY = 72)

I changed the retention for trace files which are not incident related to 72 hours (3 days). The default is 720 hours (30 days).

Of course you could do an immediate rescue as well and trigger a purge:

adrci> purge -age 4320 -type trace

This will cleanup all traces older than 72 hours or 3 days. Well, now I remember how strange I found the idea of having the control setting in hours but the purging on minutes. Actually 4320 minutes are 72 hours are 3 days. In case you wonder about the strange number.

Is there a fix available yet?

You won’t get one-off or interim fixes on Windows. And to make things a bit worse, Bug 30284751 – Trace File With Messages “Required IPC RDMAV_FORK_SAFE / RDMAV_HUGEPAGES_SAFE” Is Generated In Windows Platform has been fixed already for the next release but has been filed as a P4 bug. This is a low priority issue. And hence, the request for inclusion has been slipped through the cracks so far. Now the right people are checking it. No guarantee that it will be in the next Windows BP but we are trying our best.

Further Links and Information


Share this: