High Wait Times For Events 'library cache lock' and 'cursor: pin S wait on X' in Portal Metadata Repository Database when Oracle Access Management is Configured as Single Sign-On Solution

(Doc ID 2043833.1)

Last updated on APRIL 09, 2018

Applies to:

Portal - Version 11.1.1.1.0 to 11.1.1.6.0 [Release FMW11g]
Information in this document applies to any platform.

Symptoms

In a Fusion Middleware 11.1.1.7 environment with multiple Oracle Portal 11.1.1.6 middletier servers configured with OAM 11.1.2.2, performance degradation was observed while performing performance tests. The performance degradation was observed in the Portal metadata repository database. In the event of a performance drop, the wait events 'library cache lock' and  'cursor: pin S wait on X' accounted for the majority of the overall waiting time in the database. From the information in the ADDM report, the SQL statement 'select * from wwsso_ls_configuration_info$ where 0 = 1' could be associated with the performance drop:

Recommendation 2: SQL Tuning
Estimated benefit is 2.01 active sessions, 16.27% of total activity.
--------------------------------------------------------------------
Action
Investigate the SELECT statement with SQL_ID "9uhpt9ha5wurg" for
possible performance improvements. You can supplement the information
given here with an ASH report for this SQL_ID.
Related Object
SQL statement with SQL_ID 9uhpt9ha5wurg.

Rationale
The SQL spent only 0% of its database time on CPU, I/O and Cluster
waits. Therefore, the SQL Tuning Advisor is not applicable in this case.
Look at performance data for the SQL to find potential improvements.
Rationale
Database time for this SQL was divided as follows: 0% for SQL execution,
100% for parsing, 0% for PL/SQL execution and 0% for Java execution.
Rationale
Waiting for event "library cache lock" in wait class "Concurrency"
accounted for 65% of the database time spent in processing the SQL
statement with SQL_ID "9uhpt9ha5wurg".
Rationale
Waiting for event "cursor: pin S wait on X" in wait class "Concurrency"
accounted for 29% of the database time spent in processing the SQL
statement with SQL_ID "9uhpt9ha5wurg".
Rationale
Top level calls to execute the PL/SQL statement with SQL_ID
"7t7uj3cq28k7t" are responsible for 85% of the database time spent on
the SELECT statement with SQL_ID "9uhpt9ha5wurg".
Related Object
SQL statement with SQL_ID 7t7uj3cq28k7t.

SQL statement for SQL_ID 7t7uj3cq28k7t : SELECT * FROM WWSSO_LS_CONFIGURATION_INFO$ WHERE 0 = 1

  

Cause

Sign In with your My Oracle Support account

Don't have a My Oracle Support account? Click to get started

My Oracle Support provides customers with access to over a
Million Knowledge Articles and hundreds of Community platforms