Re: Concurrency - Cursor Pin:S

  • From: Jonathan Lewis <jonathan@xxxxxxxxxxxxxxxxxx>
  • To: "gogala.mladen@xxxxxxxxx" <gogala.mladen@xxxxxxxxx>, "raviteja.bellamkonda7@xxxxxxxxx" <raviteja.bellamkonda7@xxxxxxxxx>
  • Date: Sun, 18 Jun 2017 17:28:21 +0000


For an idea of the actual impact you could compare (with an interval) the 
number of executions of the cursor with the number of waits for the pin - 
multiply the average wait time by (pin waits / cursor executions).  Of course 
you can't guarantee that all the waits are for the same cursor, but it's a 
ballpark figure.  You've also got the elapsed time for cursor execution (from 
v$sql or the AWR/statspack) so you can compare that with the pin time.

Have you looked at dbms_shared_pool.markhot ?  This will make Oracle generate 
multiple copies of a single cursor, hashing to different library cache hash 
buckets, and may be an easy way to bypass the pin waits.

I have some notes to write up of a recent experience of using this, but haven't 
got around to it yet, but the blog Mladen referenced before has an article on 
it: 
http://andreynikolaev.wordpress.com/2011/05/01/divide-and-conquer-the-true-mutex-contention/


Regards
Jonathan Lewis



________________________________________
From: oracle-l-bounce@xxxxxxxxxxxxx <oracle-l-bounce@xxxxxxxxxxxxx> on behalf 
of Ravi Teja Bellamkonda <raviteja.bellamkonda7@xxxxxxxxx>
Sent: 18 June 2017 17:57:22
To: gogala.mladen@xxxxxxxxx
Cc: oracle-l
Subject: Re: Concurrency - Cursor Pin:S

Hi All,

Thank you for inputs. Unfortunately I cannot go ahead with the test scenario in 
the page as this database is an AWS RDS (which I already hate for obvious 
reasons) and I cannot access the x$ views.

Can someone help me provide an insight on how much the performance is being 
impacted as the average wait caused by cursor pin : S is 14 ms while we are in 
parallel trying to reduce the number of calls (App side).

Any help is very appreciated.

On Sun, Jun 18, 2017 at 9:45 AM, Mladen Gogala 
<gogala.mladen@xxxxxxxxx<mailto:gogala.mladen@xxxxxxxxx>> wrote:
On 06/18/2017 11:52 AM, GG wrote:
W dniu 2017-06-18 o 17:41, Ravi Teja Bellamkonda pisze:
Hi All,

We have a 11.2.0.4 database and recently we are facing a performance issue. 
Wait event is cursor pin:s. A particular sql query is executed multiple times

Executions - 31,173,028
Total Elapsed Time - 2033.64 s


Can some provide some input a way to diagnose the root issue. I see that the no 
of executions are very high.

--
Thanks & Regards,
Ravi Teja Bellamkonda



Hi,

 start here :

https://andreynikolaev.wordpress.com/2011/04/22/cursor-pin-s-mutex-contention-testcase-and-diagnostics-tools/


Regards .

G



Nice page, however not very useful to find a medication. Pin:S is waiting for a 
pin in the shared mode on the cursor. I have played with another pin, "buffer 
busy wait",  deliberately starting 10 threads from a Perl script, all modifying 
the same blocks in the table and performing rollback at the end. The table was 
SCOTT.EMP, so that the entire PK index fitted into a single block. I got my 
buffer busy waits all right, but the question is what to do about them? The 
solution I have found is to use multi-threaded version of Oracle 12c on Linux. 
Pins are much cheaper on the multi-threaded version then on the multi-process 
version. I have not yet had time to verify the reason I suspect, I am flying to 
the customer this afternoon and will probably not be able to verify it until 
mid-July, but I suspect that the multi-process pin mechanism is using 
semaphores, while multi-threaded does not. It will take a session with strace 
to verify that. I have already written about multi-threaded execution here:

https://dbwhisperer.wordpress.com/2013/10/04/multi-threaded-oracle-12c-architecture-on-linux-2/

However, I have not yet verified the details of the pin mechanism. It is my 
ASSUMPTION that multi-threaded version doesn't use semaphores, as opposed to 
the multi-process mechanism. That remains for me to do.

Regards




--
Mladen Gogala
Oracle DBA
Tel: (347) 321-1217<tel:(347)%20321-1217>




--
Thanks & Regards,
Ravi Teja Bellamkonda
Ph: (816)-905-7577.
--
http://www.freelists.org/webpage/oracle-l


Other related posts: