FAQ
When we were on 32-bit hardware, for one of our databases we had to
implement shared servers due to hitting the 32-bit memory limit. Since
that time, we have migrated all of our systems to 64-bit hardware. My
question is, on 64-bit hardware is there ever a need for shared
servers?



Jeffrey Beckstrom
Database Administrator
Greater Cleveland Regional Transit Authority
Information Systems
1240 W. 6th Street
Cleveland, Ohio 44113

Search Discussions

  • Stefan Knecht at Aug 1, 2011 at 12:37 pm
    There are valid uses for it still... If you've got such a vast number of
    sessions that you're running out of memory, and you can't upgrade your iron.

    You have to be aware that there might be potential performance impacts vs
    dedicated servers, as well as hitting the occasional odd bug because you're
    using a "non-mainstream setup" (we've hit a rather nasty one with the
    dispatchers for instance).

    But particularly if a large chunk of your sessions are not concurrently
    active, but idle some of the time, you can really reduce the memory
    footprint of the private process memory on your system.

    Again, it's not something I'd ever setup out of the box (unless maybe you've
    got so many sessions that no box out there can handle it with ded. servers),
    but it's something that can help you (at least temporarily) resolve memory
    issues.

    Stefan

    Stefan P Knecht
    CEO & Founder
    s_at_10046.ch

    10046 Consulting GmbH
    Schwarzackerstrasse 29
    CH-8304 Wallisellen
    Switzerland

    Phone +41-(0)8400-10046
    Cell +41 (0) 79 571 36 27
    info_at_10046.ch
    http://www.10046.ch
    On Mon, Aug 1, 2011 at 2:22 PM, Jeffrey Beckstrom wrote:

    When we were on 32-bit hardware, for one of our databases we had to
    implement shared servers due to hitting the 32-bit memory limit. Since that
    time, we have migrated all of our systems to 64-bit hardware. My question
    is, on 64-bit hardware is there ever a need for shared servers?


    Jeffrey Beckstrom
    Database Administrator
    Greater Cleveland Regional Transit Authority
    Information Systems
    1240 W. 6th Street
    Cleveland, Ohio 44113
    --
    http://www.freelists.org/webpage/oracle-l
  • Anonymous at Aug 1, 2011 at 12:55 pm

    When we were on 32-bit hardware, for one of our databases we
    had to implement shared servers due to hitting the 32-bit
    memory limit. Since that time, we have migrated all of our
    systems to 64-bit hardware. My question is, on 64-bit
    hardware is there ever a need for shared servers?
    One of the ancient systems I used to work on a few years back had an
    "interesting" way of retrieving the data to fill in a few fields on a
    Visual Basic (yuk!) screen. For each field it would login, run a query
    and the log out again. Repeat for as many fields there were on screen!

    Given that it didn't take long for there to be no usable ports after a
    few users were up and running, as there is/was a timeout between a port
    being closed and when Windows (for it was a Windows server that the
    database ran on) could reuse the port for another connection. At that
    point, everyone would just hang waiting for a port. (Or possibly crash
    out, I can't quite remember!)

    The solution was to implement shared server. This worked excellently
    with 5 shared servers and the users were happy. The (off shored)
    developers were told to fix it PDQ. They did, but the shared server
    system remained in place.

    So, I'd hate to think that there are still any systems like that one out
    there in user land, but if so, shared server might be the only remedy -
    if you can't get the developers to fix it - even on 64 bit.

    Cheers,
    Norm.

    Norman Dunbar
    Contract Senior Oracle DBA
    Capgemini Database Team (EA)
    Internal : 7 28 2051
    External : 0113 231 2051

    Information in this message may be confidential and may be legally privileged. If you have received this message by mistake, please notify the sender immediately, delete it and do not copy it to anyone else.

    We have checked this email and its attachments for viruses. But you should still check any attachment before opening it.
    We may have to make this message and any reply to it public if asked to under the Freedom of Information Act, Data Protection Act or for litigation. Email messages and attachments sent to or from any Environment Agency address may also be accessed by someone other than the sender or recipient, for business purposes.

    If we have sent you information and you wish to use it please read our terms and conditions which you can get by calling us on 08708 506 506. Find out more about the Environment Agency at www.environment-agency.gov.uk
  • Goulet, Richard at Aug 1, 2011 at 1:29 pm
    Jeff,

    Is there a reason for Shared Server. Good question and one that should be answered on a case by case basis. I use it on a number of instances where we have between 1 and 2 K sessions at any time and 99% of them are idle 80% of the time. (web based Hibernate app that just wants to stay connected. It also gets around a firewall issue with ports.) Otherwise I do prefer dedicated mainly because it's easier to set up. As for bugs, Dispatchers have limits especially with the number of sessions they can safely handle which is OS specific. Don't let them get to 50% of that limit. Second they do become a bottleneck because if their sending data to one session they can't to a second at the same time. Large reports can cause problems. Lastly a "slow" performing query can get to be harder to troubleshoot, especially if all your servers are busy. And be ready for out of memory issues as the SS pga resides in the shared pool. But for web based, mega connection apps that run fairly simple queries and are idle most of the time they can be a life saver. Small pool I realize, but don't through it out of the tool box. OH, BTW they do have one more benefit, shorter login times. We have a voice app that needs to connect to the database before replying with its hello message. Dedicated causes problems when the db server is busy (backup times in particular). Shared solves that one too.

    Richard Goulet
    Senior Oracle DBA/Na Team Leader

    From: oracle-l-bounce_at_freelists.org On Behalf Of Jeffrey Beckstrom
    Sent: Monday, August 01, 2011 8:22 AM
    To: oracle-l-freelists; oracle-db-l
    Subject: Oracle Shared Server Implementation

    When we were on 32-bit hardware, for one of our databases we had to implement shared servers due to hitting the 32-bit memory limit. Since that time, we have migrated all of our systems to 64-bit hardware. My question is, on 64-bit hardware is there ever a need for shared servers?

    Jeffrey Beckstrom
    Database Administrator
    Greater Cleveland Regional Transit Authority
    Information Systems
    1240 W. 6th Street
    Cleveland, Ohio 44113
  • Vishal Gupta at Aug 1, 2011 at 9:35 pm
    Instead of shared servers, one could use connection pool on the application server or Database Resident connection pool (DRCP) ?

    http://download.oracle.com/docs/cd/E11882_01/server.112/e17120/manproc004.htm
    On 1 Aug 2011, at 14:29, Goulet, Richard wrote:

    Jeff,



    Is there a reason for Shared Server. Good question and one that should be answered on a case by case basis. I use it on a number of instances where we have between 1 and 2 K sessions at any time and 99% of them are idle 80% of the time. (web based Hibernate app that just wants to stay connected. It also gets around a firewall issue with ports.) Otherwise I do prefer dedicated mainly because it�s easier to set up. As for bugs, Dispatchers have limits especially with the number of sessions they can safely handle which is OS specific. Don�t let them get to 50% of that limit. Second they do become a bottleneck because if their sending data to one session they can�t to a second at the same time. Large reports can cause problems. Lastly a �slow� performing query can get to be harder to troubleshoot, especially if all your servers are busy. And be ready for out of memory issues as the SS pga resides in the shared pool. But for web based, mega connection apps that run fairly simple queries and are idle most of the time they can be a life saver. Small pool I realize, but don�t through it out of the tool box. OH, BTW they do have one more benefit, shorter login times. We have a voice app that needs to connect to the database before replying with its hello message. Dedicated causes problems when the db server is busy (backup times in particular). Shared solves that one too.



    Richard Goulet
    Senior Oracle DBA/Na Team Leader
    --
    http://www.freelists.org/webpage/oracle-l

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
grouporacle-l @
categoriesoracle
postedAug 1, '11 at 12:22p
activeAug 1, '11 at 9:35p
posts5
users5
websiteoracle.com

People

Translate

site design / logo © 2022 Grokbase