FYI
If your 19c database has sessions that leak cursors (check with: select inst_id, sid, value from gv$sesstat where statistic#=5 and value>[some high number] order by 3), watch out for disk space usage after applying 19.16 DBRU. The "enhancement" in this RU will quickly generate GBs of trace logging the SQLs of the sessions that have exceeded the value of your open_cursors setting. You can quickly stop generating these traces by setting event 32216841 dynamically, i.e.
alter system set events '32216841 trace name context forever, level 1';
according to
Large Trace File Generated On ORA-1000 After Applying 19.16 DBRU (Doc ID 2892879.1)
In case of RAC, setting the event in one instance seems to work for all instances.
The good intention of this enhancement is to alert you to the problem that the app has opened too many cursors, which of course you should bring to the app developers' attention to fix their bug. Unless they can quickly fix it or this new DBRU feature is amended with a trace throttle, it may be better to leave the event set by adding this parameter to spfile:
alter system set event='32216841 trace name context forever, level 1' scope=spfile;
so it takes effect on future instance startups. (Note the syntax difference from the earlier command; singular "event", equals sign, and the "scope" clause.) Technically, you shouldn't set an event without Support's approval. But this is emergency so explain it to the analyst if asked.
You don't need this alert to find this problem anyway. You can manually check the value of statistic# 5 (i.e. "opened cursors current" in 19c) for all sessions. Once you find incessant increase of this value for a specific session, give the app team a call.
[Update] Event 32216841 does not completely suppress the trace. After setting this event, the trace files still grow quickly although not as quickly as when we don't set it. The lines in the trace files no longer have the actual SQL statements. They are now
DDE rules only execution for: ORA 1000
----- START Event Driven Actions Dump ----
---- END Event Driven Actions Dump ----
----- START DDE Actions Dump -----
Executing SYNC actions
Executing ASYNC actions
----- END DDE Actions Dump (total 0 csec) -----
repeatedly tens of thousands of times. They're useless for any purpose. It's not clear why Oracle still records these lines instead of suppressing the trace altogether. [2023-07-05 Update] We may suppress this trace by “alter system set events '32216841 trace name context off'”.