flipping performance

Recently I had a request to check "if there is any problem with the database at <specific times>".
You can imagine, there was no problem. Nothing in alert.log, no tracefiles, no locks or oddities in ASH/AWR.

I had to ask back & forth to get some more information about the issue. The information I got was:
"we use a statement SELECT * FROM table(some_function('P1', 'P2')) - and it took longer than 10 sec at the given times". Of course there were no bind variables used but constants every time.
This situation helps a lot as obviously there is nothing to do with SQL_IDs now, and the real issue is (probably) within the function.
The function just generated 1 SELECT (no BINDs again - but PL/SQL did the "auto-binding").
With this SQL it's easy to identify the SQL_ID.
This SQL_ID has 3 childs with different plans. That is sufficient to check, if the specific times somehow match a flip of plans. This was done by a simle query:

with gash as (
select sql_id, sql_child_number, sample_time, LAG(sql_child_number, 1, 0) OVER (ORDER BY sample_time) AS prev_child
from gv$active_session_history
where sql_id='&sql_id'
order by sample_time
)
select *
from gash
where sql_child_number != prev_child
order by sample_time

For a longer observation dba_hist_active_sess_history can be used as well.

The result easily showed a flip between childs/plans at the given times.

(solution was to generate "outline-hints" with dbms_xplan.display_cursor for the good plan and so hint the SQL inside of some_function).

This was no complex task to analyze or big deal to execute. Just a small example where GUIs might not help so much. By the (little) information given it would have been pure luck to see the problematic pattern in a ASH-graph. As ther was nothing to filter, all the other "noise" in the DB would have wiped the information out.

Sometimes it's good to know the architecture and views, not only the GUI.

PS: The statement above is ugly. A MATCH_RECOGNIZE would be more elegant. Unfortunately this DB is 11.2

enabling Database Vault is complicated

Enabling Database Vault in a already running system can be laborious.

I recently tried to enable DV in a (copy of a ) production Oracle EBS DB.
The Documentation is pretty lear and easy:
https://docs.oracle.com/database/121/DVADM/getting_started.htm#DVADM002
But I fail at

BEGIN 
DVSYS.CONFIGURE_DV ( 
dvowner_uname => 'DBV_OWNER', 
dvacctmgr_uname => 'DBV_ACCTMGR'); 
END; 
/ 

with

ERROR at line 1: 
ORA-47500: Database Vault cannot be configured. 
ORA-06512: at "DVSYS.CONFIGURE_DV", line 23 
ORA-06512: at "DVSYS.CONFIGURE_DV", line 72 
ORA-06512: at line 2 

That's not very helpful and ORA-47500 suggests:

If this happens, deinstall and then reinstall Oracle Database Vault

Even after removal and re-installation, the symptoms still stay.

The problem here are some invalid objects in the database!

As it's unclear to my which objects are the problem, I asked Oracle.
Unfortunately the answer is not helping a lot:

It is possible that not all [objects] need to be valid before you can configure DV successfully but you definitely need to work on fixing these invalid object at this point because that is the reason for the error.
If this happens, deinstall and then reinstall Oracle Database Vault.

Of course the suggestion doesn't help, utlrp did not change anything.
As all the invalid objects doesn't belong to the DBA but some developed code, it will take some time until DV is enabled.

I don't have any solution right now than laborious wading through all invalid objects and fixing them.