Forum Stats

  • 3,851,949 Users
  • 2,264,053 Discussions
  • 7,904,914 Comments

Discussions

Advantages of having multiple CDBs in the same server/cluster

JOE_humble
JOE_humble Member Posts: 99
edited Oct 31, 2017 12:35PM in Multitenant

DB version: 12.2

GI version: 12.2

OS :   RHEL 7.4

In the internet , I have come across articles which mentions multiple CDBs in the same server.

Currently, I have a 2 node RAC cluster with three 11.2.0.4 RAC DBs running in it. Using RMAN, I want to migrate these 3 DBs to a 12.2 cluster and convert (consolidate) these DBs to PDBs . All these DBs are of the same version.

Question1. Having multiple CDBs in the same server/cluster is not helpful in the above case. Right ?

Question2. In what circumstance do we need to create multiple CDBs in the same server/cluster ?

Franck PachotJOE_humble

Answers

  • BPeaslandDBA
    BPeaslandDBA Member Posts: 4,615 Blue Diamond
    edited Oct 31, 2017 10:19AM
    Question1. Having multiple CDBs in the same server/cluster is not helpful in the above case. Right ?

    Not really helpful in the case you described. One CDB is capable of handling all of the PDBs.

    Question2. In what circumstance do we need to create multiple CDBs in the same server/cluster ?

    The only use case I've seen that makes sense to me (maybe there are others that I'm not aware of yet) is to have multiple CDBs to support multiple database versions. Maybe you need an 12.1.0.2 database and a 12.2.0.1 database, then create two CDB's, one of each version. Along those lines, lets say that you are at 12.1.0.2 today with your three PDBs. But tomorrow you want to upgrade. Create a 12.2.0.1 CDB than unplug the PDB from the 12.1.0.2 CDB and plug into the 12.2.0.1 CDB.

    Cheers,
    Brian

    JOE_humbleJOE_humble
  • Markus Flechtner
    Markus Flechtner Member Posts: 503 Bronze Trophy
    edited Oct 31, 2017 10:30AM
    BPeaslandDBA wrote:Question1. Having multiple CDBs in the same server/cluster is not helpful in the above case. Right ?Not really helpful in the case you described. One CDB is capable of handling all of the PDBs. Remember that you have to pay the Multitenant Option in this case.If you want to migrate to the Container Database Architecture (without Multitenant Option) you will end up with 3 CDBs with one PDB each ("single-tenant")Question2. In what circumstance do we need to create multiple CDBs in the same server/cluster ?The only use case I've seen that makes sense to me (maybe there are others that I'm not aware of yet) is to have multiple CDBs to support multiple database versions. Maybe you need an 12.1.0.2 database and a 12.2.0.1 database, then create two CDB's, one of each version. Along those lines, lets say that you are at 12.1.0.2 today with your three PDBs. But tomorrow you want to upgrade. Create a 12.2.0.1 CDB than unplug the PDB from the 12.1.0.2 CDB and plug into the 12.2.0.1 CDB. Beside database versions, there can be patches which have to be applied for one database (but not for the others) or specific instance parameters which have to be set on CDB level (and cannot be overridden on PDB level.HTHMarkus
    JOE_humble
  • FRivasF-Oracle
    FRivasF-Oracle Member Posts: 11 Employee
    edited Oct 31, 2017 10:42AM

    Hi Joe,

    Question1. Having multiple CDBs in the same server/cluster is not helpful in the above case. Right ?

    If your main goal is to consolidate into multitenant CDB, then one single CDB is enough.

    Question2. In what circumstance do we need to create multiple CDBs in the same server/cluster ?

    What are your needs?. How can you improve your current administration tasks?. Having multiple CDBs in the same cluster unlocks a lot of new options :

    - You can create a refreshable PDB in a different CDB and keep an updated copy of one, a subset or all the PDBs . You can then use that updated copy as a golden master to create clones for - lets say - preproduction or development purposes.

    - You can do the same thing but using snapshot clones - thin provisioning - instead of traditional clones.

    - You can have a CDB prepared for offline batch patch installation and perform then unplug/plug the PDB to the updated environment. You would only need to run datapatch afterwards and you are done.

    - You can have a different options subset installation on a new CDB and unplug/plug any of the PDBs into this new CDB if you need additional components.

    - You can create a different characterset CDB in the same binary subset and unplug/plug one or some PDBs to this new CDB and then use DMU to migrate the characterset without compromising the original datafiles.

    etc...

    I am sure this is not the full set of possible scenarios.

    Regards,

    JOE_humbleJOE_humble
  • vanpupi
    vanpupi Member Posts: 48
    edited Oct 31, 2017 11:06AM

    Hello,

    Q1: The way you describe it, there is no use for multiple cdb's

    Q2:

    • Licensing. Afaik you can use 1pdb per cdb without paying the multitenant option. If you consolidate them, you need the multitenant option.
    • Charactersets
    • versions
    • Different CDB settings needed...

    So the answer is a bit. It depends.

    Best regards

    Pieter

    Franck PachotJOE_humble
  • Unknown
    edited Oct 31, 2017 12:35PM
    In the internet , I have come across articles which mentions multiple CDBs in the same server.

    Ok - so post links to those articles and quotes from them so we can see what you are referring to.

    Currently, I have a 2 node RAC cluster with three 11.2.0.4 RAC DBs running in it. 
    Using RMAN, I want to migrate these 3 DBs to a 12.2 cluster and convert
    (consolidate) these DBs to PDBs . All these DBs are of the same version.Question1. Having multiple CDBs in the same server/cluster is not helpful in the above case. Right ?Question2. In what circumstance do we need to create multiple CDBs in the same server/cluster ?

    The STANDARD rule is 'do NOT make changes unless you have a good reason for doing so'.

    If you are using a cluster now why do you think you should change?


    Only YOU, and your org, know what your rationale was for adopting your current architecture. For whatever reasons you chose clusters.

    Has something changed? You said you want to 'migrate' to a 12.2 cluster so what are your reasons for NOT doing that?

    If you are reconsidering your use of clusters you might want to review the 'benefits of using a cluster' bullet list in the doc

    https://docs.oracle.com/database/122/CWADD/introduction-to-oracle-clusterware.htm#CWADD90950

    The benefits of using a cluster include:    Scalability of applications (including Oracle RAC and Oracle RAC One databases)    Reduce total cost of ownership for the infrastructure by providing a scalable system with low-cost commodity hardware    Ability to fail over    Increase throughput on demand for cluster-aware applications, by adding servers to a cluster to increase cluster resources    Increase throughput for cluster-aware applications by enabling the applications to run on all of the nodes in a cluster    Ability to program the startup of applications in a planned order that ensures dependent processes are started in the correct sequence    Ability to monitor processes and restart them if they stop    Eliminate unplanned downtime due to hardware or software malfunctions    Reduce or eliminate planned downtime for software maintenance

    You haven't indicated that you have ANY problem/issue that needs to be solved whose solution might require changing your architecture.

    1. identify a problem/issue and confirm that it REALLY exists

    2. determine  the cause of the problem/issue

    3. identify possible solutions that will eliminate/mitigate the problem/issue

    4. select a small number (2 or 3) of those 'solutions' for prototyping and testing

    5. select the 'best' solution from those tested

    Based on what you posted you haven't yet done ANY of those steps.

    Until you at least take step #1 there really isn't any other advice to offer except: follow the 5 steps above.

    JOE_humble
This discussion has been closed.