Oracle Parallel Server - any success stories
DBAsupport.com Forums - Powered by vBulletin
Results 1 to 5 of 5

Thread: Oracle Parallel Server - any success stories

  1. #1
    Join Date
    Jan 2002
    Posts
    2
    Hi All,

    My company is planning to implement Oracle Parallel Server 8.1.7 on Solaris across 2 machines.

    I've read some very helpful threads on OPS within this forum... most though, are very cautionary regarding OPS and few have been about successful implementations.

    QUESTION:
    Therefore, I'd just like to find out if anyone is successfully running OPS and if they have received the benefits that that they expected.

    Also, is the administration more or less difficult than they expected.

    Regards,
    Kwee

  2. #2
    Join Date
    Feb 2001
    Location
    Bombay,India
    Posts
    530
    Hi,
    In our company we have Oracle Parallel Server(OPS) on IBM HACMP cluster.We have got 2 nodes on which Oracle Parallel Server runs.
    The main benefit of OPS is in high availability database in which even if one instance abnormally terminates the other instance takes over the aborted instance and all the users get shifted to the other instance.This failover is done from application by giving the Global database name instead of the instance name at the client side.
    The administration of OPS is more difficult as compared to normal database administration as you have to manage both the instances and some parameters need to be the same when managing the instances.
    In case of any help please be free to ask me at rohitsn@altavista.com

    Regards,
    Rohit Nirkhe,Oracle DBA,OCP 8i
    rohitsn@altavista.com

  3. #3
    Join Date
    Jun 2001
    Location
    Helsinki. Finland
    Posts
    3,938
    This failover is done from application by giving the Global database name instead of the instance name at the client side.
    This is called CTF (Connect Time Failover) and is not the best choice. I have applied TAF (Transparent Application Failover) which is the proper way to switch to the other node.

    To leekwee: I suggest you study OPS in detail before you make decission on switching to it, it is a complicated enviroment and if you have not partitioned your applications, the word lock will become a nightmare :-)


  4. #4
    Join Date
    Jan 2002
    Posts
    2
    Hi Julian and Rohit,

    Thanks to both of you for your thoughts. It is very helpful and much appreciated.

    I have one followup question:

    <>

    Is there a good methodology or resource to determine "how to partition my application?" How do I determine the "best way" to partition my app.

    I've read that "well planned application partitioning" is 1 key to OPS success otherwise performance may actually degrade. I've read (and hopefully understood correctly) that OPS is best for applications where common data is NOT accessed simultaneously by concurrent users, because this will lead to PINGING which will slow down overall performance, and perhaps additional locking problems.

    Having said that, my company manages approx 50 content-heavy web sites, all which share common SignUp and Login Screens/database tables... everything is dynamic (JSP). We have Solaris 8 machines with dual processors.

    I'm concerned that our sites (as described above) may not be good candidates for OPS. For example, the homepage of 1 of our web sites may have 100 people concurrently hitting the homepage, all accessing the same data within our OPS database... or we might have 50 people logging in concurrently, all be authenticated against a single user table.

    Based on my overview, can you tell whether you think OPS would improve or degrade performance?

    Regards,
    Kwee

  5. #5
    Join Date
    Jun 2001
    Location
    Helsinki. Finland
    Posts
    3,938
    I have one followup question:

    Is there a good methodology or resource to determine "how to partition my application?" How do I determine the "best way" to partition my app.

    Well, that's two questions :-)

    1. Partitioning means the design of an application so that OPS instances access mutually exclusive sets of data. If you do not have such an application, you will see often or at times worse perforamnce than before. This is valid mainly for OPS, not for RAC. Partitioning an already existing application means rewring most of the code, which is often out-of-the-question operation. Now, although we do not have partitioned application, we use OPS in the following way: Node1 is the OLTP instance, all (well almost) DMLs take place there. Node 2 is a reporting instance: only selects are run there. Thus with take benefit of the 8i Cache Fusion, which means that blocks needed for reading (note for reading, not for writing as implemented on RAC 9i) are transfered via the Interconnect, not via disk.

    2. I do not know for I am not familiar with your applications.

    Based on my overview, can you tell whether you think OPS would improve or degrade performance?
    Hard to say, the guess is degrade, unless you tune the server almost perfectly which is very difficult. I am spending most of my time tuning the OPS server, it is a hard job. Many things do not works as in a single instance DB. I suggest again that first you get familiar with OPS, read all you find about it and then make up your mind.


Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  



Click Here to Expand Forum to Full Width