v$session 每一个连接到数据库实例中的session都拥有一条记录。包括用户session及后台进程如DBWR,LGWR,arcchiver等等。
V$process 本视图包含当前系统oracle运行的所有进程信息。常被用于将oracle或服务进程的操作系统进程ID与数据库session之间建立联系。
show parameter sessions 查看当前session配置
show parameter processes 查看当前process配置
alter system set processes=1000 scope=spfile 更改配置,更改完后需要重启数据库。
修改oracle配置文件中process进行修改
这个里面说的非常详细。所以通过这篇文章,我理解的数据库连接数其实就是oracle中的session数量,而不是process数量,只是我们平时修改oracle配置时候一般都是去修改process,而session会根据process数量自动计算出来。
在修改processes时候,scope只能是spfile,我试了用memory和both都报错,后来google了一下发现应该是processes这个参数是不能直接在memory中修改。还有修改完processes后,如果有用pfile启动数据库的,就需要加上:create pfile from spfile,把spfile中修改的信息写到pfile文本文件中去。这样下次启动时候就能生效了。
http://blog.csdn.net/inthirties/archive/2009/10/01/4624760.aspx 写道
Shared Server Architecture
Shared server architecture eliminates the need for a dedicated server process for each connection. A dispatcher directs multiple incoming network session requests to a pool of shared server processes. An idle shared server process from a shared pool of server processes picks up a request from a common queue, which means a small number of shared servers can perform the same amount of processing as many dedicated servers.
Also, because the amount of memory required for each user is relatively small, less memory and process management are required, and more users can be supported.
A number of different processes are needed in a shared server system:
¡ö A network listener process that connects the user processes to dispatchers or dedicated servers (the listener process is part of Oracle Net Services, not Oracle).
¡ö One or more dispatcher processes
¡ö One or more shared server processes
When an instance starts, the network listener process opens and establishes a communication pathway through which users connect to Oracle. Then, each dispatcher process gives the listener process an address at which the dispatcher listens for connection requests. At least one dispatcher process must be configured and started for each network protocol that the database clients will use.
A request from a user is a single program interface call that is part of the user’s SQL statement. When a user makes a call, its dispatcher places the request on the request queue, where it is picked up by the next available shared server process.
The request queue is in the SGA and is common to all dispatcher processes of an instance. The shared server processes check the common request queue for new requests, picking up new requests on a first-in-first-out basis. One shared server process picks up one request in the queue and makes all necessary calls to the database
to complete that request.
When the server completes the request, it places the response on the calling dispatcher’s response queue. Each dispatcher has its own response queue in the SGA. The dispatcher then returns the completed request to the appropriate user process.
NOTE£ºThe listener process is not part of an Oracle instance; rather, it is part of the networking processes that work with Oracle.
Oracle dynamically adjusts the number of shared server processes based on the length of the request queue. The number of shared server processes that can be created ranges between the values of the initialization parameters SHARED_SERVERS and MAX_ SHARED_SERVERS.
Certain administrative activities cannot be performed while connected to a dispatcher process, including shutting down or starting an instance and media recovery. An error message is issued if you attempt to perform these activities while connected to a dispatcher process.
The user and server processes are separate, distinct processes. The separate server process created on behalf of each user process is called a dedicated server process (orshadow process), because this server process acts only on behalf of the associated user process.
This configuration maintains a one-to-one ratio between the number of user processes and server processes. Even when the user is not actively making a database request, the dedicated server process remains (though it is inactive and can be paged out on some operating systems).