Which three statements are true when the listener handles connection requests to an Oracle 12c database instance with multithreaded architecture enabled In UNIX?

Which three statements are true when the listener handles connection requests to an Oracle 12c
database instance with multithreaded architecture enabled In UNIX?

Which three statements are true when the listener handles connection requests to an Oracle 12c
database instance with multithreaded architecture enabled In UNIX?

A.
Thread creation must be routed through a dispatcher process

B.
The local listener may spawn a now process and have that new process create a thread

C.
Each Oracle process runs an SCMN thread.

D.
Each multithreaded Oracle process has an SCMN thread.

E.
The local listener may pass the request to an existing process which in turn will create a thread.

Explanation:



Leave a Reply 2

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


picoman

picoman

A&B&E
THREADED_EXECUTION = FALSE and LOCAL CONNECTION
The client spawns directly an Oracle Server Process that attaches to the shared memory.

THREADED_EXECUTION = FALSE and REMOTE CONNECTION
The client contacts the listener. The listener spawns an Oracle Server Process that attaches to the shared memory.

THREADED_EXECUTION = TRUE and LOCAL CONNECTION
The client contacts a connection broker (Nnnn) that verifies the authentication with the passwordfile and then spawns a new THREAD in an existing OS process ((SCMN) in v$process or (Unnn) thgough a ps).
That’s why THREADED_EXECUTION automatically sets USE_DEDICATED_BROKER to TRUE: to have a connection broker active even if not using connection pooling.

THREADED_EXECUTION = TRUE and REMOTE CONNECTION
The client contacts the listener that forward the connection request to a connection broker (Nnnn).
Then the path is the same: The broker verifies the authentication with the passwordfile and then spawns a new THREAD in an existing OS process.
The listener requires that the parameter DEDICATED_THROUGH_BROKER_listener is enabled to allow the listener to forward the requests to a broker (if it exists!) instead of spawning a process directly.

One more information… the (LREG) is a new process that registers the instances and services to the listener, that’s what the PMON was doing up to release 11gR2… so the PMON has been demoted a little 🙂