Messages
Please Leave Your Messsage Here!
请在此留言!
|
||||||
6 comments to MessagesLeave a Reply |
||||||
|
Copyright © 2010 OS & Oracle - All Rights Reserved |
||||||
|
||||||
MessagesPlease Leave Your Messsage Here! 请在此留言! 6 comments to MessagesLeave a Reply |
||||||
|
Copyright © 2010 OS & Oracle - All Rights Reserved |
||||||
Great site, keeping post good posts, ^_^
hi, let have a talk about a subject below.
consider a scene like this :
1)I configure oracle system with shared servers.
2)There are more than one thousand client systems that may offen have to connect to oracle in the same time.
3)All the client systems may share more than database schema(user).
My question is :
Which stategy should I use in order to acquire better database performances?
1)Keeping a long connection for each client system
2)Creating a new connection before a database operation and then releasing it after a database operation.
How shared server architecture work in each of the two choices?
sorry, omit words “one hundred” as below :
3)All the client systems may share more than one hundred database schema(user).
The shared server architecture uses a dispatcher process to direct client connections to a common request queue. An idle shared server process from a shared pool of server processes picks up a request from the common queue. This approach enables a small pool of server processes to serve a large number of clients. A significant advantage of the shared server model over the dedicated server model is reduced system resources, enabling support of an increased number of users. More info about the shared server architecture can be found in:
http://download.oracle.com/docs/cd/B19306_01/network.102/b14212/concepts.htm#i1045403
The term “long connection” I think is more related to “dedicated server”, it’s a usual way to save the system resource of connection creation and deallcation.
And it’s not a good idea to create and release a connection in order to issue a operation, in shared mode, the connection can remain idle, not necessary to deallcate.
Also,because of the common request queue and the fact that many uses may share a dispatcher response queue, shared servers do not perform well with operations that must deal with large sets of data, such as warehouse queries and batch processing, backup and recovery, administration tasks.
considering what you say : “And it’s not a good idea to create and release a connection in order to issue a operation, in shared mode, the connection can remain idle, not necessary to deallcate.”
I still have several questions:
To avoid always creating and releasing a connection, every client system has to keep at least one connection to the database system. It means that ,according to the scene,there will be always more than one thousand connections needed for more than one thousand client systems at the same time.Then how many shared server processes will be used and how many request will be included in the request queues? Do the answers concern the number of client connections or the number of operations issued by client systems? And what are the limited number of shared server processes and request queue elements of oracle system.
Yes, one dispatch process, for example, can support 1000 connections at the same time. The number of connections is OS dependent. The number of shared servers can be configured.
Besides shared server, Oracle provide “connection pooling” and “multiplexing session”, which is based on shared server. Connection pooling let you specify an timeout parameter to timeout the idle session. “Multiplexing session” enables multiple client sessions to funnel through a single protocol connection.
There is an configuration example at:
http://download.oracle.com/docs/cd/B19306_01/network.102/b14212/dispatcher.htm#sthref1164