Which two can be reasons for this?

You are administering a database that supports an OLTP workload.
TheCURSOR_SHARINGparameter is set toEXACTfor the instance. The performance of
queries issued by one of the modules has degraded. The queries executed by the module are
almost identical in syntax. To investigate, you analyze the latest AWR report and find a
large number oflatch:sharedpoolwait events and also a high percentage of the hard parse
elapsed time. Which two can be reasons for this?(Choose two.)

You are administering a database that supports an OLTP workload.
TheCURSOR_SHARINGparameter is set toEXACTfor the instance. The performance of
queries issued by one of the modules has degraded. The queries executed by the module are
almost identical in syntax. To investigate, you analyze the latest AWR report and find a
large number oflatch:sharedpoolwait events and also a high percentage of the hard parse
elapsed time. Which two can be reasons for this?(Choose two.)

A.
The I/O performance is slow.

B.
Bind variables are not used for similar queries, causing hard parses.

C.
Repeated access to a small number of blocks.

D.
Excessive time is spent on finding cached cursors in the library cache.

E.
TheCURSOR_SHARINGparameter is set toEXACT, which does not allow similar
queries to shareacursor.



Leave a Reply 7

Your email address will not be published. Required fields are marked *


vasya

vasya

imo B and D
B is obviously.
D because latches of the shared pool is caused by looking for appropriate child cursors

duong.ora

duong.ora

BE
E:CURSOR_SHARING=EXACT, SQL statements must be identical to share cusors

job

job

most latches have been replaced by mutexes by 12c. A lookup for a cursor in library cache could only produce a mutex wait event not latch.

besides, it mentions application runs almost identical in syntax.. so I go for B,E.

Fonx

Fonx

B E obviously imo