Apress.Expert.Oracle.Database.Architecture.9i.and.10g.Programming.Techniques.and.Solutions.Sep.2005
CHAPTER 5 ■ ORACLE PROCESSES 159 Figure 5-2. Typical shared server connection Here, we can see that the client applications, with the Oracle libraries linked in, will be physically connected to a dispatcher process. We may have many dispatchers configured for any given instance, but it is not uncommon to have just one dispatcher for hundreds—even thousands—of users. The dispatcher is simply responsible for receiving inbound requests from the client applications and putting them into a request queue in the SGA. The first available shared server process, which is basically the same as a dedicated server process, will pick up the request from the queue and attach the UGA of the associated session (the boxes labeled “S” in Figure 5-2). The shared server will process that request and place any output from it into the response queue. The dispatcher constantly monitors the response queue for results and transmits them back to the client application. As far as the client is concerned, it cannot really tell if it is connected via a dedicated server or a shared connection—they appear to be the same. Only at the database level is the difference apparent. Connections vs. Sessions It surprises many people to discover that a connection is not synonymous with a session. In most people’s eyes they are the same, but the reality is they do not have to be. A connection may have zero, one, or more sessions established on it. Each session is separate and independent, even though they all share the same physical connection to the database. A commit in one session does not affect any other session on that connection. In fact, each session using that connection could use different user identities!
160 CHAPTER 5 ■ ORACLE PROCESSES In Oracle, a connection is simply a physical circuit between your client process and the database instance—a network connection, most commonly. The connection may be to a dedicated server process or to a dispatcher. As previously stated, a connection may have zero or more sessions, meaning that a connection may exist with no corresponding sessions. Additionally, a session may or may not have a connection. Using advanced Oracle Net features such as connection pooling, a physical connection may be dropped by a client, leaving the session intact (but idle). When the client wants to perform some operation in that session, it would reestablish the physical connection. Let’s define these terms in more detail: • Connection: A connection is a physical path from a client to an Oracle instance. A connection is established either over a network or over an IPC mechanism. A connection is typically between a client process and either a dedicated server or a dispatcher. However, using Oracle’s Connection Manager (CMAN), a connection may be between a client and CMAN, and CMAN and the database. Coverage of CMAN is beyond the scope of this book, but Oracle Net Services Administrator’s Guide (freely available from http://otn.oracle.com) covers it in some detail. • Session: A session is a logical entity that exists in the instance. It is your session state, or a collection of data structures in memory that represents your unique session. It is what would come first to most people’s minds when thinking of a “database connection.” It is your session in the server, where you execute SQL, commit transactions, and run stored procedures. We can use SQL*Plus to see connections and sessions in action, and also to recognize that it could be a very common thing indeed for a connection to have more than one session. We’ll simply use the AUTOTRACE command and discover that we have two sessions. Over a single connection, using a single process, we’ll establish two sessions. Here is the first: ops$tkyte@ORA10G> select username, sid, serial#, server, paddr, status 2 from v$session 3 where username = USER 4 / USERNAME SID SERIAL# SERVER PADDR STATUS --------- ---- -------- --------- -------- -------- OPS$TKYTE 153 3196 DEDICATED AE4CF614 ACTIVE Now, that shows right now that we have one session: a single dedicated server–connected session. The PADDR column is the address of our sole dedicated server process. Now, we simply turn on AUTOTRACE to see the statistics of statements we execute in SQL*Plus: ops$tkyte@ORA10G> set autotrace on statistics ops$tkyte@ORA10G> select username, sid, serial#, server, paddr, status 2 from v$session 3 where username = USER 4 /
- Page 154 and 155: CHAPTER 3 ■ FILES 109 of the requ
- Page 156 and 157: CHAPTER 3 ■ FILES 111 IMPDP, howe
- Page 158 and 159: CHAPTER 3 ■ FILES 113 tkyte@ORA10
- Page 160 and 161: CHAPTER 4 ■ ■ ■ Memory Struct
- Page 162 and 163: CHAPTER 4 ■ MEMORY STRUCTURES 117
- Page 164 and 165: CHAPTER 4 ■ MEMORY STRUCTURES 119
- Page 166 and 167: CHAPTER 4 ■ MEMORY STRUCTURES 121
- Page 168 and 169: CHAPTER 4 ■ MEMORY STRUCTURES 123
- Page 170 and 171: CHAPTER 4 ■ MEMORY STRUCTURES 125
- Page 172 and 173: CHAPTER 4 ■ MEMORY STRUCTURES 127
- Page 174 and 175: CHAPTER 4 ■ MEMORY STRUCTURES 129
- Page 176 and 177: CHAPTER 4 ■ MEMORY STRUCTURES 131
- Page 178 and 179: CHAPTER 4 ■ MEMORY STRUCTURES 133
- Page 180 and 181: CHAPTER 4 ■ MEMORY STRUCTURES 135
- Page 182 and 183: CHAPTER 4 ■ MEMORY STRUCTURES 137
- Page 184 and 185: CHAPTER 4 ■ MEMORY STRUCTURES 139
- Page 186 and 187: CHAPTER 4 ■ MEMORY STRUCTURES 141
- Page 188 and 189: CHAPTER 4 ■ MEMORY STRUCTURES 143
- Page 190 and 191: CHAPTER 4 ■ MEMORY STRUCTURES 145
- Page 192 and 193: CHAPTER 4 ■ MEMORY STRUCTURES 147
- Page 194 and 195: CHAPTER 4 ■ MEMORY STRUCTURES 149
- Page 196 and 197: CHAPTER 4 ■ MEMORY STRUCTURES 151
- Page 198 and 199: CHAPTER 4 ■ MEMORY STRUCTURES 153
- Page 200 and 201: CHAPTER 5 ■ ■ ■ Oracle Proces
- Page 202 and 203: CHAPTER 5 ■ ORACLE PROCESSES 157
- Page 206 and 207: CHAPTER 5 ■ ORACLE PROCESSES 161
- Page 208 and 209: CHAPTER 5 ■ ORACLE PROCESSES 163
- Page 210 and 211: CHAPTER 5 ■ ORACLE PROCESSES 165
- Page 212 and 213: CHAPTER 5 ■ ORACLE PROCESSES 167
- Page 214 and 215: CHAPTER 5 ■ ORACLE PROCESSES 169
- Page 216 and 217: CHAPTER 5 ■ ORACLE PROCESSES 171
- Page 218 and 219: CHAPTER 5 ■ ORACLE PROCESSES 173
- Page 220 and 221: CHAPTER 5 ■ ORACLE PROCESSES 175
- Page 222 and 223: CHAPTER 5 ■ ORACLE PROCESSES 177
- Page 224 and 225: CHAPTER 5 ■ ORACLE PROCESSES 179
- Page 226 and 227: CHAPTER 5 ■ ORACLE PROCESSES 181
- Page 228 and 229: CHAPTER 6 ■ ■ ■ Locking and L
- Page 230 and 231: CHAPTER 6 ■ LOCKING AND LATCHING
- Page 232 and 233: CHAPTER 6 ■ LOCKING AND LATCHING
- Page 234 and 235: CHAPTER 6 ■ LOCKING AND LATCHING
- Page 236 and 237: CHAPTER 6 ■ LOCKING AND LATCHING
- Page 238 and 239: CHAPTER 6 ■ LOCKING AND LATCHING
- Page 240 and 241: CHAPTER 6 ■ LOCKING AND LATCHING
- Page 242 and 243: CHAPTER 6 ■ LOCKING AND LATCHING
- Page 244 and 245: CHAPTER 6 ■ LOCKING AND LATCHING
- Page 246 and 247: CHAPTER 6 ■ LOCKING AND LATCHING
- Page 248 and 249: CHAPTER 6 ■ LOCKING AND LATCHING
- Page 250 and 251: CHAPTER 6 ■ LOCKING AND LATCHING
- Page 252 and 253: CHAPTER 6 ■ LOCKING AND LATCHING
CHAPTER 5 ■ ORACLE PROCESSES 159<br />
Figure 5-2. Typical shared server connection<br />
Here, we can see that the client applications, with the <strong>Oracle</strong> libraries linked in, will be<br />
physically connected to a dispatcher process. We may have many dispatchers configured for<br />
any given instance, but it is not uncommon to have just one dispatcher for hundreds—even<br />
thous<strong>and</strong>s—of users. The dispatcher is simply responsible for receiving inbound requests<br />
from the client applications <strong>and</strong> putting them into a request queue in the SGA. The first available<br />
shared server process, which is basically the same as a dedicated server process, will<br />
pick up the request from the queue <strong>and</strong> attach the UGA of the associated session (the boxes<br />
labeled “S” in Figure 5-2). The shared server will process that request <strong>and</strong> place any output<br />
from it into the response queue. The dispatcher constantly monitors the response queue for<br />
results <strong>and</strong> transmits them back to the client application. As far as the client is concerned, it<br />
cannot really tell if it is connected via a dedicated server or a shared connection—they appear<br />
to be the same. Only at the database level is the difference apparent.<br />
Connections vs. Sessions<br />
It surprises many people to discover that a connection is not synonymous with a session. In<br />
most people’s eyes they are the same, but the reality is they do not have to be. A connection<br />
may have zero, one, or more sessions established on it. Each session is separate <strong>and</strong> independent,<br />
even though they all share the same physical connection to the database. A commit<br />
in one session does not affect any other session on that connection. In fact, each session using<br />
that connection could use different user identities!
Change language