Init Parameters after patching

Question

Database version: 10.2.0.4 Patch 45 on Windows 2003
1. Documentation says to set "_first_spare_parameter" to resolve bug 6904068. What should be the value if we actually see this bug occuring after applying the patch. How can we determine that we need this parameter to be turned on?
2. How can we determine we need to set "_third_spare_parameter"? How can we check if there is a regression on log files?

Answer 1

No, the mentioned parameter "_first_spare_parameter" NOT suffice and NOT operative lonely. It will work as expected only when the Patch 6904068 applied.
Main Problem Description:
Excessive CPU consumption when mutexes for cursor pin was enabled. Testes done over this issue consisted of repeated execution of one
and and the same SQL statement by many sessions concurrently. They will all contend for the child cursor mutex in S mode. If the mutex cannot be gotten
after spinning a few times, kgx calls a client-provided wait function. For cursor S mutexes, the wait function (kksLockWait) was actually yielding the CPU
rather than waiting for a fixed time. For this particular testcase, given the number of CPUS available and the fact that processes had little else to do other
than run this SQL, the yield call apparently does not provide a long enough delay and the end result was that processes were constantly spinning and
consuming CPU, trying to get the mutex. This problem is a result of various factors in combination - repeated execution of the same simplistic SQL, high
number of concurrent sessions executing that SQL and not doing anything else, large number of CPUs on the machine and perhaps other factors as well. This
combination is probably unlikely to occur in any real life application scenario although this customer insisted that their testcase was representative of their
real app.
Fix Description: In kksLockWait(), Now wait for a fixed time instead of yielding when trying to obtain the mutex in S mode and there is no X holder.
By forcing a much longer duration wait time between mutex get attempts (as compared to "yield"), the testcase was found to consume much less CPU and
delivered higher throughput as compared to the old latch-based implementation
The amount of time to wait is controlled by a parameter. The parameter as delivered in one-offs is called "_first_spare_parameter" and takes an integer
value representing the time to wait in CENTIseconds(1cs = 10ms). The default value of 0 will retain current behavior (i.e yield the cPU). The value can be
adjusted dynamically at the SYSTEM level but not at the SESSION level.