Database Tutorials MSSQL, Oracle, PostgreSQL, MySQL, MariaDB, DB2, Sybase, Teradata, Big Data, NOSQL, MongoDB, Couchbase, Cassandra, Windows, Linux 
When the Exadata database is upgraded to version 12.2, “gc cr request” and “gc buffer busy acquire” wait events occur in many operations in the database. At the same time, when users try to login, it can be seen that queries such as the following cause the “library cache lock” wait event.
1 | select spare6 from user$ where user#=:1 |
or
1 | SELECT privilege# FROM sysauth$ WHERE (grantee# = 1 OR grantee# = 1) AND privilege# > 0 |
It has been found that there is a query like below which causes login operations to wait. The problem will be solved when session trying to do this update is killed. However, in heavily used databases, “gc cr request and gc buffer busy acquire” wait events make the database unresponsive.
1 | update user$ set spare6=DECODE(to_char(:2, ‘YYYY-MM-DD’), ‘0000-00-00’, to_date(NULL), :2) where user#=:1 |
The root cause of the problem is the following bugs. The database patch 25163866 should be applied to solve the problem completely, and if this patch does not resolve, the patch UEK4 kernel 25730857 should be applied. You can apply the patch for the kernel by following the document 2207063.1. To apply the database patch, the database must be closed. When you apply a node on RAC systems, the instance on the node that is applied does not open. Close the database, apply the patch to all nodes, and then open it.
Internal Bug 25163866 – SAGEASM-E DB HANG AT ‘GC CR REQUEST'<=’LIBRARY CACHE LOAD LOCK’
Internal Bug 25730857 – UEK4: Cache Fusion Fails Because of Data Corruption in LWIPC
It is also solved in databases with version 18.1.
