Yes, I will dig into that a bit, and report back here if I find anything
interesting.
For the time being I want to finish the rest of this, and for now I can
just ignore those with a mismatch.
Most of what I want to work with will be in both v$sql and
v$db_object_cache.
However I may find some of interest in AWR, which is what this was to
address.
Of course, if they are periodically active, just scanning ASH for 'cursor:
pin S wait on X' ( the problem de jour) a few times a day should be
sufficient.
But now I am just 'thinking out loud'.
On Mon, Dec 7, 2020 at 12:16 PM Jonathan Lewis <jlewisoracle@xxxxxxxxx>
wrote:
I'd notice something similar - it might be a coincidence, of course - but
I was cross-checking against v$sql and found the parsing user was always
SYS (which fits with SYS recursive, of course).
Regards
Jonathan Lewis
On Mon, 7 Dec 2020 at 14:05, Jared Still <jkstill@xxxxxxxxx> wrote:
Thank you Jonathan, I did see your blog on that.
The shared_pool was flushed after the last time markhot was run.
Checking just now, there aren't any SQL marked as hot.
The SQL that get an incorrect hash value have so far all been system SQL
Here are two examples:
============================================================
sql len: 53
sql#: 2516
sql_id: g4y6nw3tts7cc
sql: BEGIN DBMS_APPLICATION_INFO.SET_MODULE(:1,NULL); END;
full_hash: c7d4ecb14863c535f278d4e0f39c1d8c
calc hash: 4feafe18f3031f89567263b189b174fe
==>> MISMATCH ==<<
============================================================
============================================================
sql len: 45
sql#: 2019
sql_id: c7fnaqcmbm0b5
sql: SELECT SUM(NUM_MAPPINGS+1) FROM smon_scn_time
full_hash: 14a86bc5696fafc4c3ba8ab326b98165
calc hash: 596c4eda631a007b1db10314f9641f97
==>> MISMATCH ==<<
============================================================
