Re: SQL v$db_object_cache.full_hash_value

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_at_gmail.com> 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 ==<<
> ============================================================
>
>
>

--
http://www.freelists.org/webpage/oracle-l