Database query connection — oracle-tech

    Forum Stats

  • 3,702,035 Users
  • 2,239,551 Discussions
  • 7,835,727 Comments

Discussions

Database query connection

I have 4,000 points of sale with IPs in my network and these communicate with a socket server, to make queries to an Oracle database. This is so since 12 years ago, the points of sale were MS-DOS with Clipper development, currently they are Linux with GCC development.

With this new modality the points of sale are capable of connecting directly to the Oracle server and thus eliminating the socket server.

Is it correct to eliminate the socket server and for the 4,000 points of sale to consult the database directly?

Is there any inconvenience, problem or something to consider, to do this?


Who can I turn to to be sure that it is correct, eliminate the socket server and that the 4,000 points of sale consult directly, without going through an intermediary and that everything will be more fluid and better?


Your prompt response is already appreciated

Answers

  • Billy VerreynneBilly Verreynne Posts: 27,734 Red Diamond

    Yes.

    The Oracle Listener deals with client connections over TCP sockets.

    A client connection can be for a dedicated server - the Listener spawns a new Oracle server process for exclusively servicing this client connection. 4000 client connections, 4000 dedicated server processes. Each process requires system resources, and this does not scale as well as having a single process with multiple threads.

    A client connection can be for a shared server - the Listener hands of the client socket to a Dispatcher process. The Dispatcher services the client's network communication. When the Dispatcher receives a request from the client, it places that request on a virtual circuit, where an idle Shared Server process will pick up the request, service it, with the Dispatcher feeding back the response of the Shared Server to the client.

    4000 client connections. 4000 sockets on the server, with perhaps 10 Dispatcher processes and 200 Shared Server processes servicing these 4000 sockets.

    Both the Dispatcher Pool and Shared Server Pool are configurable. And the v$ (Virtual Performance) views can be used to query the effectiveness of these pools for tuning pool sizes.

    There is also other options like using Dedicated Server, but running the database with the Thread Model as oppose to the Fork Model. So instead of 4000 dedicated server processes with the Fork Model, 4000 posix threads with the Thread Model.

Sign In or Register to comment.