The following is a brief description of the functions of the Kglic function:
The code is as follows |
Copy Code |
1. Kglic means Kernel Generic Library cache iterate Chain (AFAIK), it's the function which is executed when your Access MoS T X$KGL tables. 2. Kglic is the code which goes through the library cache and row cache to answer queries on various dictionary fixed VI EWS and tables. This are the function which returns data for the "fixed" views and tables of that scan the SQL area. Therefore, it is highly possible that such queries could also is coming from monitoring tools used by DBAs and they are Not restricted to the two views specifically mentioned the bug by Joan. Any monitoring job which looks in v$open_cursor would also use the Kglic iterator. |
The bug associated with this, still exists in 10g, and finally confirms that the customer has a more frequent query access V$sql view, resulting in a serious competition for the library cache.
The following bugs have an impact version of 10.2.0.4,10.2.0.5,11.2.0.2:
code is as follows |
copy code |
bug 9287616- accessing [G]v$sql or [G]v$sqltext_with_newlines May is slow/takes a long time/latch contention (Doc ID 9287616.8) |