RE: Locking issue

  • From: Dominic Brooks <dombrooks@xxxxxxxxxxx>
  • To: "jlewisoracle@xxxxxxxxx" <jlewisoracle@xxxxxxxxx>, "ORACLE-L (oracle-l@xxxxxxxxxxxxx)" <oracle-l@xxxxxxxxxxxxx>
  • Date: Thu, 17 Jun 2021 09:47:01 +0000

We have real-time statistics disabled (via _optimizer_use_stats_on_conventional 
& _dml_optimizer_gather_stats_on conventional_dml) for a specific bug we 
encountered 
(https://orastory.wordpress.com/2021/04/08/real-time-statistics-ora-00600s-integer-overflow/
 ) but still can observe significant row cache activity on dc_realtime_colst 
particularly in some code paths.

Cheers,
Dominic

Sent from Mail<https://go.microsoft.com/fwlink/?LinkId=550986> for Windows 10

From: Jonathan Lewis<mailto:jlewisoracle@xxxxxxxxx>
Sent: 17 June 2021 10:39
To: ORACLE-L (oracle-l@xxxxxxxxxxxxx)<mailto:oracle-l@xxxxxxxxxxxxx>
Subject: Re: Locking issue

Lok P,

The 19.10 RU backports a parameter optimizer_real_time_statistics according to 
this note ( 
https://blogs.oracle.com/optimizer/real-time-statistics-parameter<https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fblogs.oracle.com%2Foptimizer%2Freal-time-statistics-parameter&data=04%7C01%7C%7C19d1b4765beb452432dc08d93173d4a3%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637595195827436467%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=DsKPX6BzkBLFQxhXRZvij7gAL%2Bt4k4HhdCjBkCxZor4%3D&reserved=0>
 ) by Nigel Bayliss, with the default value of FALSE so on your next upgrade it 
seems likely that the feature will disable itself automatically - which 
suggests it would be safe to disable it manually.

I don't have access to a 19.9, so I assume that it is currently a hidden 
parameter but maybe it's more subtle than that.
There's also the problem that your query is reporting the use of real-time 
statisics, but the collection of the statistics is from DML, so maybe you have 
to find a way to disable the entire realtime statistics feature to bypass your 
dictionary cache activity.

Regards
Jonathan Lewis



On Thu, 17 Jun 2021 at 06:10, Lok P 
<loknath.73@xxxxxxxxx<mailto:loknath.73@xxxxxxxxx>> wrote:
Actually I am not sure if we can relate our issue to exactly the same one which 
you pointed above. Our Db version is 19.9.0.0.0. In our case it is a simple 
SELECT query ( SELECT /*+ FULL(P) +*/ * FROM P  ) doing FTS on a table (holding 
700million rows) from multiple sessions(20+ sessions) and were experiencing DC 
lock on 'dc_realtime_colst/tabst' and all the other new session accessing same 
object 'P' were gets locked in parse stage(cursor pin s wait on X) there after 
creating a big storm of concurrency. Support is pointing to the below bug and 
suggesting the patch to install to fix this bug.

32042352<https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsupport.oracle.com%2Fepmos%2Ffaces%2FPatchDetail%3FrequestId%3D24138539%26_afrLoop%3D252185249564103%26patchId%3D32042352%26_afrWindowMode%3D0%26_adf.ctrl-state%3D168q4vx617_93%23&data=04%7C01%7C%7C19d1b4765beb452432dc08d93173d4a3%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637595195827446458%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=dYwsix4fWRyKBIGJdWE4eYJNDvcOUs4YG%2B5TAPR8g0Q%3D&reserved=0>
HIGH ROW CACHE MUTEX WAITS ON 19.8 WITH HIGH 
CONCURRENCY<https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsupport.oracle.com%2Fepmos%2Ffaces%2FPatchDetail%3FrequestId%3D24138539%26_afrLoop%3D252185249564103%26patchId%3D32042352%26_afrWindowMode%3D0%26_adf.ctrl-state%3D168q4vx617_93%23&data=04%7C01%7C%7C19d1b4765beb452432dc08d93173d4a3%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637595195827446458%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=dYwsix4fWRyKBIGJdWE4eYJNDvcOUs4YG%2B5TAPR8g0Q%3D&reserved=0>


I had one related question, as this all seems to be related to 'dynamic 
statistics/stats on conventional DML option' as that is visible in the note 
section in the SELECT query plan. So is it advisable to switch that off for 
this sql/table someway without negatively impacting it anything?



On Wed, Jun 9, 2021 at 9:21 PM Dominic Brooks 
<dombrooks@xxxxxxxxxxx<mailto:dombrooks@xxxxxxxxxxx>> wrote:
Out of interest, but off on a tangent from original thread, I am also hitting 
what seems to be some oddities around this dc_realtime_colst.

Trying to drop a 230GB partitioned table it’s taking hours with notable waits 
on DLM cross inst call completion and notable row cache lock waits on 
dc_realtime_colst (and dc_histogram_defs).
For my issue, investigation is pointing towards two notes which point at same 
bug:
Drop User Cascade Command Hang On "DLM cross inst call completion" (Doc ID 
2671064.1)
Bug 31208287 - Deleting Enqueues For A Large Partitioned Table Hangs In 
KJCI_WAIT/KJCI_PROCESSCRQ (Doc ID 31208287.8)

WORKAROUND:
Drop in smaller portions. For instance first remove stats/histograms from the
columns.


Sent from 
Mail<https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgo.microsoft.com%2Ffwlink%2F%3FLinkId%3D550986&data=04%7C01%7C%7C19d1b4765beb452432dc08d93173d4a3%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637595195827456459%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=4ggICPXnEXCHOeb2f14hIny4Qr7%2BBeNu0vLcqWdY%2FhU%3D&reserved=0>
 for Windows 10

From: Noveljic Nenad<mailto:nenad.noveljic@xxxxxxxxxxxx>
Sent: 28 May 2021 08:57
To: Lok P<mailto:loknath.73@xxxxxxxxx>
Cc: ORACLE-L (oracle-l@xxxxxxxxxxxxx)<mailto:oracle-l@xxxxxxxxxxxxx>
Subject: RE: Locking issue

Yes, this bug should be fixed in 19.9 in the base release. I can tell from my 
installation that it’s definitely fixed in 19.9.0.0.201020.

You can verify it for your patch level:

$ORACLE_HOME/OPatch/opatch lsinventory | grep 31414023

We still don’t know the reason for row cache lock id=62/63 allocations. 
Unfortunately, the 10222 trace doesn’t spool the call stacks for cid=62/63, 
only for cid=16/8.

We’d need to capture the call stacks for 62 or 63 to find out more.

If you want to go down that rabbit hole, I can prepare a DTrace script if 
you’re on Solaris or gdb if you’re on Linux. The later would be better to run 
on a test system if you’re unexperienced with gdb.

Let me know.

Best regards,

Nenad


From: Lok P <loknath.73@xxxxxxxxx<mailto:loknath.73@xxxxxxxxx>>
Sent: Freitag, 28. Mai 2021 06:05
To: Noveljic Nenad 
<nenad.noveljic@xxxxxxxxxxxx<mailto:nenad.noveljic@xxxxxxxxxxxx>>
Cc: ORACLE-L (oracle-l@xxxxxxxxxxxxx<mailto:oracle-l@xxxxxxxxxxxxx>) 
<oracle-l@xxxxxxxxxxxxx<mailto:oracle-l@xxxxxxxxxxxxx>>
Subject: Re: Locking issue

Thank you Nenad. We have oracle version 19.9.0.0. Need to check patch details. 
But it seems from the bug details , this bug should have been fixed by this 
version. correct me if wrong.

____________________________________________________
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<https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.vontobel.com%2F&data=04%7C01%7C%7C19d1b4765beb452432dc08d93173d4a3%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637595195827466463%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=JhjHcspEelYC2W1%2BIkDKtLCrbMotWp%2FZ4IVJgXXjhbk%3D&reserved=0>.


Other related posts: