Each process in Oracle wants to complete a specific task or set of tasks, and each process allocates internal memory (PGA memory) to complete its task.
There are three main types of processes in an Oracle instance:
A server process server process
To complete the work according to the client's request. Dedicated/shared server, which is the server processB background process background process
It starts with the database and completes various maintenance tasks, such as writing blocks to disk, maintaining online redo logs, cleaning up aborted processes, etc.C slave process slave process
Similar to background processes, but they do some additional work on behalf of a background or server process.
A server process
A process that does work on behalf of a client session. The SQL statements sent by the application to the database are finally received and executed by these processes.
A dedicated server connection
gets a dedicated process on the server for that connection. There is a one-to-one mapping between a database connection and a process on the server.
Shared server
Multiple sessions can share a server process pool, in which the processes are generated and managed by the Oracle instance.
What you are connecting to is a database dispatcher (dispatcher), not a dedicated server process created specifically for the connection.
The task of a dedicated or shared server process is the same: to process all the SQL you submit. When you submit a SELECT * FROM EMP query to the database, an Oracle dedicated/shared server process parses the query and puts it in the shared pool (or preferably finds out that the query is already in the shared pool). The process has to come up with a query plan , and if necessary, execute the query plan , possibly finding the necessary data in the buffer cache, or reading the data from disk into the buffer cache . These server processes are heavy-duty processes. In many cases, you'll find that these processes take up the most CPU time on your system because it's these processes that do the sorting, summarizing, joining, and so on, and it's these processes that do almost all of the work.
-------------------------------------------------- ----------------------Private server
1. remote execution: the client application may execute on another machine (instead of the machine where the database is located)
2. address space isolation: the server process can read Write SGA. If the client and server processes are physically linked together, a wrong pointer in the client process can easily corrupt the data structures in the SGA.
The creation of this parent/child process can be clearly seen by running the client and server on the same machine
scott@ORCL>select a.spid dedicated_server, 2 b.process clientpid 3 from v$process a, v$session b 4 where a.addr = b.paddr 5 and b.sid = (select sid from v$mystat where rownum=1) 6 / DEDICATED_SERVER CLIENTPID ------------------------ ------------------------ 5748 1408:3388
Query the process ID (PID) associated with the dedicated server, the SPID obtained from V$PROCESS is the operating system PID of the process used to execute the query
shared server
Shared server connections mandate the use of Oracle Net, even if the client and server are on the same machine. You cannot use a shared server without using the Oracle TNS listener. The client application will connect to the Oracle TNS listener and be redirected or forwarded to a scheduler. The scheduler acts as a "conduit" between client applications and shared server processes.
Here it can be seen that the client application (where the Oracle library is linked) is physically connected to a scheduler process. The scheduler is only responsible for receiving inbound requests from client applications and placing them in a request queue in the SGA . The first available shared server process selects the request from the queue and attaches the UGA of the associated session . The shared server processes the request and places the resulting output in the response queue . The scheduler keeps monitoring the response queue for results and passes them back to the client application . As far as the client is concerned, it is unclear whether it is connecting through a dedicated or shared server connection, both appear to be the same, only at the database level the difference becomes apparent.
connection and session
Zero, one or more sessions can be established on a connection . Sessions are separate and independent , even if they share the same physical connection to the database. Commits in one session do not affect any other sessions on that connection. In fact, individual sessions on a connection can use different user identities !
In Oracle, a connection is just a special line between a client process and a database instance , the most common being a network connection. This connection may be to a dedicated server process or to a scheduler. As mentioned earlier, there can be 0 or more sessions on a connection, which means there can be a connection without a corresponding session. Additionally, a session may or may not be connected. When using advanced Oracle Net features such as connection pooling, a client can drop a physical connection and the session remains (but the session is idle). When the client performs an operation on this session, it re-establishes the physical connection.
connection
A physical path (eg, a network connection between the client and the instance) from the client process to the Oracle instance can be established over the network, or through the IPC mechanism. A connection is usually established between the client process and a dedicated server or a scheduler.
session
A session is a logical entity that exists within an instance . This is your session state,
That is , a set of in-memory data structures that represent a particular session . The client process executes SQL, commits transactions, and runs stored procedures on sessions in the server. Multiple independent sessions can be associated with a connection, and these sessions can even exist independently of the connection.
Here the AUTOTRACE command is used and two sessions are found. We created two sessions with one process on one connection. Here is the first session of it:
scott@ORCL>select username, sid, serial#, server, paddr, status 2 from v$session 3 where username = USER 4 / USERNAME SID SERIAL# SERVER PADDR STATUS ------------------------------ ---------- ---------- --------- ---------------- -------- SCOTT 67 434 DEDICATED 000007FF634DF010 ACTIVEThis means that there is now one session: this is a session connected to a single dedicated server. The PADDR column above is the address of this dedicated server process
Next, just open AUTOTRACE to view the statistics of the executed statements in SQL*Plus:
scott@ORCL>set autotrace on statistics
scott@ORCL>select username, sid, serial#, server, paddr, status
2 from v$session
3 where username = USER
4 /
USERNAME SID SERIAL# SERVER PADDR STATUS
------------------------------ ---------- ---------- --------- ---------------- --------
SCOTT 63 535 DEDICATED 000007FF634DF010 INACTIVE
SCOTT 67 434 DEDICATED 000007FF634DF010 ACTIVE
Statistics
----------------------------------------------------------
0 recursive calls
0 db block gets
0 consistent gets
0 physical reads
0 redo size
992 bytes sent via SQL*Net to client
519 bytes received via SQL*Net from client
2 SQL*Net roundtrips to/from client
0 sorts (memory)
0 sorts (disk)
2 rows processed
This gives us two sessions, but both are using the same dedicated server process, which is evident from the fact that they both have the same PADDR value. It can also be confirmed from the operating system that only one process (one connection) is used for both sessions since no new process is created. Note that one of the sessions (the original session) is ACTIVE, which is running a query to display this information. That INACTIVE session is the AUTOTRACE session, and its job is to "watch" our actual session and report what it does.
When AUTOTRACE is enabled in SQL*Plus, if a DML operation (INSERT, UPDATE, DELETE, SELECT, and MERGE) is performed, SQL*Plus does the following:(1) If a secondary session does not already exist, it creates a secondary session using the current connection new session.
(2) Ask the new session to query the V$SESSTAT view to remember the initial statistics for the actual session (ie the session running the DML).
(3) Run DML operations in the original session.
(4) After the execution of the DML statement, SQL*Plus will request another session (ie, the "monitoring" session) to query V$SESSTAT again, and generate the report shown above, showing the statistics of the original session (the session that executed DML) poor results.
If AUTOTRACE is turned off, SQL*Plus will terminate this extra session, which will not be visible in V$SESSION.
The reason why SQL*Plus will create another session to perform monitoring is because if the same session is used to monitor memory usage, the monitoring itself will also use memory , which will affect the statistical results (resulting in the modification of statistical results) .
So far, we've seen that a connection can have one or two sessions. Now, we want to use SQL*Plus to view a connection without any sessions. In the same SQL*Plus window used in the example above, just type DISCONNECT :
scott@ORCL>disconnect 从 Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - 64bit Production With the Partitioning, OLAP, Data Mining and Real Application Testing options 断 openTechnically, this command should be more appropriately called DESTROY_ALL_SESSIONS, not DISCONNECT, since we're not actually physically disconnecting.
To actually disconnect in SQL*Plus, you should execute the "exit" command, which must be exited to completely cancel the connection.
We have closed all sessions. If you open another session with another user account system, and query. It can be seen that there is no session under the account scott before, but there is still a process, which has a corresponding physical connection (using the previous ADDR value):
system@ORCL>select * from v$session where username = 'scott@ORCL';
row not selected
system@ORCL>select username, program
2 from v$process
3 where addr = hextoraw('000007FF634DF010');
USERNAME PROGRAM
--------------- ----------------------------------------------------------------
SYSTEM ORACLE.EXE (SHAD)
So, there is a "connection" with no associated session. You can use SQL*Plus's CONNECT command (which is also inappropriately named) to create a new session in this existing process (the CONNECT command is better called CREATE_SESSION):
scott@ORCL>conn scott/123456 connected. scott@ORCL>select username, sid, serial#, server, paddr, status 2 from v$session 3 where username = USER 4 / USERNAME SID SERIAL# SERVER PADDR STATUS ------------------------------ ---------- ---------- --------- ---------------- ------- SCOTT 67 470 DEDICATED 000007FF634DF010 ACTIVE
Notice that the PADDR is still the same, so we're still using the same physical connection, but (probably) have a different SID, and maybe the same SID is assigned, depending on whether someone else is logged in when we log out, and Is our original SID available.
So far, these tests have been performed with a dedicated server connection, so PADDR is the process address of the dedicated server process.
-------------------------------------------------- ---------------------- Shared server
For details on shared server mode settings, see https://blog.csdn.net/A0001AA/article/details/79915439
Log in using the shared server below and query in this session:
sys@ORCL>select username, sid, serial#, server, paddr, status from v$session where username = USER ; USERNAME SID SERIAL# SERVER PADDR STATUS -------------------- ---------- ---------- --------- ---------------- -------- SYS 9 87 SHARED 000007FF634DDFA0 ACTIVEZero, one, or more sessions can be established on a connection (a physical path from a client to a database instance). We saw a use case where SQL*Plus's AUTOTRACE tool was used. There are many other tools that take advantage of this. For example, Oracle Forms uses multiple sessions on a single connection for its scheduling functionality. Oracle's n-tier proxy authentication feature can be used to provide end-to-end user authentication from the browser to the database. This feature also makes heavy use of the single-connection concept with multiple sessions, but each session may use a different user account . Over time, sessions may use multiple processes, especially in shared server environments. Also, if Oracle Net's connection pooling is used, the session may not be associated with any process at all; after a connection has been idle for a while, the client will drop it and then transparently recreate the connection based on detected activity (whether a connection is needed).
There is a many-to-many relationship between connections and sessions. Most common, though, is a one-to-one relationship between a dedicated server and a single session.
-------------------------------------------------- ---------------------------- Dedicated or Shared Server
1. When to use a dedicated server
There is a one-to-one mapping between client connections and server processes . For all current SQL-based applications, this is the most common method for applications to connect to an Oracle database. It's easiest to set up a dedicated server, and it's also the easiest way to establish a connection, requiring little configuration.
Because there is a one-to-one mapping, there is no need to worry about long-running transactions blocking other transactions. Other transactions are handled only by its own dedicated process. Therefore, this mode should only be considered in non-OLTP environments, where there may be long-running transactions . A dedicated server is the recommended configuration for Oracle and it scales well. Dedicated servers can even be used for thousands of concurrent connections, as long as the server has enough hardware (CPU and RAM) to handle the number of dedicated server processes required by the system.
Certain operations must be performed in dedicated server mode, such as database startup and shutdown , so there may be both dedicated and shared servers in each database, or only one dedicated server may be set up.
2. When to use a shared server
Multiple clients correspond to a shared server . When using a shared resource, do not monopolize the resource for too long . Make sure that the duration of the transaction is as short as possible . Transactions can be executed frequently, but must be executed in a short time (this is the characteristics of OLTP systems) . If the transaction duration is very long, it appears that the entire system will slow down because the shared resource is monopolized by a few processes. There may also be artificial deadlocks when using shared servers .
You have 5 shared servers and established 100 user sessions. Now, up to 5 user sessions can be active at a point in time. Suppose one of the user sessions updated a row, but did not commit. While this user is sitting there hesitating to make changes, there may be five other user sessions trying to lock this row. Of course, these 5 sessions will be blocked and can only wait patiently for this line to become available. Now, the original user session (which holds the lock on this row) attempts to commit the transaction, releasing the lock on the row accordingly. This user session finds that all shared servers are already monopolized by those 5 waiting sessions. This creates an artificial deadlock situation: the lock holder never gets the shared server to complete the commit unless a waiting session relinquishes its shared server . However, unless the waiting session is waiting for a lock with a timeout, they will never relinquish their shared server (unless the administrator gets out of this predicament by having a dedicated server "kill" (revoke) the waiting session ).
Shared servers are only suitable for OLTP systems where transactions are short and frequent . In an OLTP system, transactions are executed in milliseconds, and the execution of any transaction will complete within a moment of 1 second. Shared servers are not suitable for data warehouses where queries that take 1 minute, 2 minutes, 5 minutes or even longer may be executed. If 90% of your system is OLTP and only 10% is "not so OLTP", then there's an appropriate mix of dedicated and shared servers on the same instance. In this way, the number of server processes for OLTP users on the machine can be greatly reduced, and users who are "not so OLTP" won't monopolize the shared server. In addition, DBAs can use the built-in Resource Manager (Resource Manager) to further control resource utilization.Of course, there is another important reason to use a shared server, and many advanced connectivity features require the use of a shared server . If you want to use Oracle Net connection pooling or database link concentration between databases , you must use a shared server for these connections.
Potential Benefits of Shared Servers
1. Reduce the number of OS processes/threads
2. Deliberately limit concurrency
3. Reduce the memory required by the system