Re: Concurrency - Cursor Pin:S

  • From: Ravi Teja Bellamkonda <raviteja.bellamkonda7@xxxxxxxxx>
  • To: gogala.mladen@xxxxxxxxx
  • Date: Sun, 18 Jun 2017 09:57:22 -0700

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>
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




-- 
Thanks & Regards,
Ravi Teja Bellamkonda
Ph: (816)-905-7577.

Other related posts: