Re: SQL v$db_object_cache.full_hash_value

From: Jared Still <jkstill_at_gmail.com>
Date: Mon, 7 Dec 2020 12:32:46 -0800
Message-ID: <CAORjz=M47dOCX=yk06yLkTv0iBmYSbp0xXDj=et9oBqj=cKueg_at_mail.gmail.com>



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_at_gmail.com> 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_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
Received on Mon Dec 07 2020 - 21:32:46 CET

Original text of this message