Re: Locking issue

  Thank you so much. Will try to trace that.

Btw that same SELECT query is running normally now without any 'row cache lock'. But ASH entries look a bit odd because the plan shows a simple FULL SCAN on the table but still I notice the current_obj# is pointing to the primary key index of that table. And another sys object i.e. sys.LINK_LOGONS$_SRCID_IDX.
Is it DB link related? Now, we do have DB link calls from/to this database but I am not able to relate logically how a DB link call to this database object from others can cause such row cache lock? And also i don't see any mechanism to see if this select query is really part of a Db link call from another database. Another thing I see all these times is the ASH for this application SELECT query is showing TOP_LEVL_CALL_NAME as "DESCRIBE_INDEXES" . Can this all be related somehow?

Additionally as i mentioned the stats gather session was on "row cache lock" with P1(cache id=62) as "dc_realtime_colst" , P2(mode) as 0 i.e. 'null mode - not locked' and P3(request) as 5 i.e. 'exclusive mode'. So here , request mode is exclusive , does that mean it wont allow others to have access on that DC/dictionary cache object?

Regards
Lok

On Thu, May 20, 2021 at 12:37 PM Noveljic Nenad <nenad.noveljic_at_vontobel.com> wrote:

> I traced the row cache locks (event 10222, level 4) for both a select with
> dynamic sampling and the statistic job:
>
>
>
> --select with dynamic sampling
>
> SQL> !grep cid
> /u00/oracle/orabase/diag/rdbms/db_site1/DB/trace/DB_ora_15329_0001.trc |
> grep 'kqrpre:' | awk '{print $4}' | sort -u
>
> cid=0
>
> cid=10
>
> cid=16
>
> cid=2
>
> cid=8
>
>
>
> --gather_table_stats
>
> SQL> !grep cid
> /u00/oracle/orabase/diag/rdbms/db_site1/DB/trace/DB_ora_15329_0002.trc |
> grep 'kqrpre:' | awk '{print $4}' | sort -u
>
> cid=0
>
> cid=10
>
> cid=11
>
> cid=13
>
> cid=16
>
> cid=17
>
> cid=2
>
> cid=3
>
> cid=61
>
> cid=63
>
> cid=8
>
>
>
> (cid is the rowcache id.)
>
>
>
> Only the statistic job acquired the rowcache lock id 63.It’s therefore
> still unclear what boundary condition caused acquiring the rowcache lock
> for select.
>
>
>
> Lok, you could try to capture the stack trace for the event 10222. Sayan
> has just published the article on how to do that:
> http://orasql.org/2021/05/20/oracle-diagnostic-events-cheat-sheet/
>
>
>
> Best regards,
>
>
>
> Nenad
>
>
>
> ____________________________________________________
>
> Please consider the environment before printing this e-mail.
>
> Bitte denken Sie an die Umwelt, bevor Sie dieses E-Mail drucken.
>
>
> Important Notice
>
> This message is intended only for the individual named. It may contain
> confidential or privileged information. If you are not the named addressee
> you should in particular not disseminate, distribute, modify or copy this
> e-mail. Please notify the sender immediately by e-mail, if you have
> received this message by mistake and delete it from your system.
> Without prejudice to any contractual agreements between you and us which
> shall prevail in any case, we take it as your authorization to correspond
> with you by e-mail if you send us messages by e-mail. However, we reserve
> the right not to execute orders and instructions transmitted by e-mail at
> any time and without further explanation.
> E-mail transmission may not be secure or error-free as information could
> be intercepted, corrupted, lost, destroyed, arrive late or incomplete. Also
> processing of incoming e-mails cannot be guaranteed. All liability of
> Vontobel Holding Ltd. and any of its affiliates (hereinafter collectively
> referred to as "Vontobel Group") for any damages resulting from e-mail use
> is excluded. You are advised that urgent and time sensitive messages should
> not be sent by e-mail and if verification is required please request a
> printed version.
> Please note that all e-mail communications to and from the Vontobel Group
> are subject to electronic storage and review by Vontobel Group. Unless
> stated to the contrary and without prejudice to any contractual agreements
> between you and Vontobel Group which shall prevail in any case,
> e-mail-communication is for informational purposes only and is not intended
> as an offer or solicitation for the purchase or sale of any financial
> instrument or as an official confirmation of any transaction.
> The legal basis for the processing of your personal data is the legitimate
> interest to develop a commercial relationship with you, as well as your
> consent to forward you commercial communications. You can exercise, at any
> time and under the terms established under current regulation, your rights.
> If you prefer not to receive any further communications, please contact
> your client relationship manager if you are a client of Vontobel Group or
> notify the sender. Please note for an exact reference to the affected group
> entity the corporate e-mail signature. For further information about data
> privacy at Vontobel Group please consult www.vontobel.com.
>

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