ALERT: Multitenant Database Crashes With Mulitple Internal Errors While Openi...

刘泽宇

描述：
A 19c (19.25 or below) multitenant database instance can demonstrate unpredictable behavior or crash with varying internal errors while opening or closing a PDB when parameter RESULT_CACHE_MAX_SIZE is explicitly set to zero in a CDB but set to a nonzero value in a PDB.

Also, if the PDB is actually successfully opened in this state, certain operations may cause various internal errors to be raised and crash the PDB. For example, in one occurrence of this problem, selecting from the DBA_DIRECTORIES view in the PDB triggered this behavior.

Note that even with this condition, it may be possible to open the PDB in restricted or read-only mode.

This issue often occurs when plugging in a PDB into a CDB when the CDB has RESULT_CACHE_MAX_SIZE is explicitly set to zero but the PDB has some other value set.

出现：
If RESULT_CACHE_MAX_SIZE is explicitly set to zero in the CDB, but set to some other value in a PDB, there is a very high probability that a memory corruption will occur in the fixed SGA. Due to the way a certain fixed SGA variable related to the result cache is set/initialized, having RESULT_CACHE_MAX_SIZE set to zero in a CDB but nonzero in a PDB can cause another such variable to contain a random value (whatever the uninitialized variable previously contained). and cause unpredictable behavior, including but not limited to the errors shown below.



现象：
A PDB or instance crash can occur with a wide variety of internal errors. The memory corruption introduced is random, so the symptoms can vary widely. Below is a list of documented errors known to be caused by this issue from past incidents:

ORA-600: [17149]
ORA-600: [kghichk:kghdsnex:unreadable]
ORA-600: [KGHALO4]
ORA-600: [ksl_invalid_latch_excl]
ORA-600: [kss_check_freelist]
ORA-600: [KSLFLUX_3]
ORA-600: [qesrcBlf_Tst]
ORA-600: [qesrc_CM_check]
ORA-602: internal programming exception
ORA-7445: [kghfnd_in_free_lists]
ORA-7445: [kghfrh_internal]
ORA-7445: [kghlru]
ORA-7445: [kghungex]
ORA-7445: [ksupdbsesinc]
ORA-7445: [ksu_proc_set_pdb]
ORA-7445: [kml_sess_ucb]
ORA-7445: [kss_get_type]
ORA-7445: [qesrcDO_New]

Note that the call stack may include functions specific to the Result Cache lower (earlier) in the stack such as shown below, but these functions also may not be present:

[16]: qesrcMM_NewChunk [Result_Cache]
[17]: qesrcMM_Alloc [Result_Cache]
[18]: qesrcEvent_qesrcMM_Alloc_ [Result_Cache]
[19]: qesrcRO_Publish [Result_Cache]
[20]: qesrcCM_Release [Result_Cache]


可用方法：
This issue is fixed in 19.26 and above, so applying a more recent DBRU will resolve the problem.

Oracle's recommendation is to reset the parameter in all containers if explicitly set. This lets it default to its derived value. When using ASMM (Automatic Shared Memory Management, meaning SGA_TARGET is nonzero and MEMORY_TARGET is zero), RESULT_CACHE_MAX_SIZE is derived from the settings of SGA_TARGET and SHARED_POOL_SIZE. This causes the situation shown in the note box below:

***NOTE***: even if RESULT_CACHE_MAX_SIZE is explicitly set to a nonzero value in memory and the spfile, if SHARED_POOL_SIZE=0 is also set explicitly, then at the next instance restart, RESULT_CACHE_MAX_SIZE will automatically be set to zero.
An easy workaround is to do the following:

Set SHARED_POOL_SIZE to nonzero value if it is explicitly set to zero. When using ASMM, SHARED_POOL_SIZE establishes a minimum value below which the pool will not shrink. It is not recommended to set SHARED_POOL_SIZE explicitly to zero, as this removes any size restrictions on how much the pool can shrink or grow.
Reset RESULT_CACHE_MAX_SIZE in both the CDB and the PDB, which allows it to default to its derived value:
alter system reset RESULT_CACHE_MAX_SIZE;

Restart the CDB.
Note also that if the problem PDB cannot be opened because of this issue, it may still be possible to open it in restricted or read-only mode.