Forum Stats

  • 3,840,360 Users
  • 2,262,592 Discussions
  • 7,901,243 Comments

Discussions

Naming convention for CDBs and PDBs

Max
Max Member Posts: 339 Bronze Badge
edited Oct 25, 2019 5:50PM in Multitenant

DB version : 19C

OS : OL 7.6/8 (Yet to finalize)

I work for an MNC bank. And all our new DBs will be using multitenant. Well, we are forced to do that

So, I am thinking of naming our CDBs and PDBs like below

CDB : <Business division Name>CDB<ascendingNumber>

PDB : <Business division Name><CDB's number><ApplicationName><Environment (like prod,UAT,SIT)>PDB

For example if the business Division name is FRM and application is TSM and if it is a production DB , and if it is 23rd CDB for this division,  I will name it like

CDB : FRMCDB23

PDB : FRM23TSMPRDPDB

What do you guys think of this naming convention ? Is it horrible ? Any comments ?

dbca1.png

Andris Perkons-OracleMaxyoonas

Best Answer

  • BPeaslandDBA
    BPeaslandDBA Member Posts: 4,615 Blue Diamond
    edited Oct 15, 2019 11:15AM Answer ✓

    Whatever naming scheme works for you and your fellow DBA's, use that. Just be consistent across your enterprise. It doesn't matter what you call your PDBs and CDBs just so long as everyone on the team knows the naming scheme and it works for all parties.

    Also keep in mind that your applications don't need to know what the naming scheme is. You can, and probably should, create services. Your applications connect to the service and the service points it to the correct PDB.

    If I could offer one suggestion it would be that I would not name a PDB to have the CDB name in it. The reason is simple...upgrades. I'm currently upgrading many PDBs from 12.1.0.2 to 19.3. To do that, I created a 19.3 CDB. I unplug the 12.1.0.2 PDB from the 12.1.0.2 CDB and plug it into the 19.3 CDB and upgrade the PDB. If I had the PDB named after its CDB, the PDB would be improperly named on plug-in. Upgrades is just one example. As you work with Multitenant more, you may come up with other reasons to move PDBs from one CDB to another. Remember that the P in PDB means Pluggable. They are designed to be unplugged and moved to other PDBs.

    And it is this moving of a PDB from one CDB to another that is a big reason why I use services. My applications know the service name, but as the DBA, I can move the PDB and even change the PDB name during the move (Yes...I know this PDB rename does negate my earlier point in the previous chapter) but the service name stays the same.

    To me, I would name the PDBs with something meaningful to the application(s) that PDB supports. I would name the CDB something meaningful. But I do not ties the PDB name to the CDB name or vice versa. Maybe that's just me.

    Cheers,
    Brian

    Andris Perkons-OracleyoonasChristyxo

Answers

  • BPeaslandDBA
    BPeaslandDBA Member Posts: 4,615 Blue Diamond
    edited Oct 15, 2019 11:15AM Answer ✓

    Whatever naming scheme works for you and your fellow DBA's, use that. Just be consistent across your enterprise. It doesn't matter what you call your PDBs and CDBs just so long as everyone on the team knows the naming scheme and it works for all parties.

    Also keep in mind that your applications don't need to know what the naming scheme is. You can, and probably should, create services. Your applications connect to the service and the service points it to the correct PDB.

    If I could offer one suggestion it would be that I would not name a PDB to have the CDB name in it. The reason is simple...upgrades. I'm currently upgrading many PDBs from 12.1.0.2 to 19.3. To do that, I created a 19.3 CDB. I unplug the 12.1.0.2 PDB from the 12.1.0.2 CDB and plug it into the 19.3 CDB and upgrade the PDB. If I had the PDB named after its CDB, the PDB would be improperly named on plug-in. Upgrades is just one example. As you work with Multitenant more, you may come up with other reasons to move PDBs from one CDB to another. Remember that the P in PDB means Pluggable. They are designed to be unplugged and moved to other PDBs.

    And it is this moving of a PDB from one CDB to another that is a big reason why I use services. My applications know the service name, but as the DBA, I can move the PDB and even change the PDB name during the move (Yes...I know this PDB rename does negate my earlier point in the previous chapter) but the service name stays the same.

    To me, I would name the PDBs with something meaningful to the application(s) that PDB supports. I would name the CDB something meaningful. But I do not ties the PDB name to the CDB name or vice versa. Maybe that's just me.

    Cheers,
    Brian

    Andris Perkons-OracleyoonasChristyxo
  • Max
    Max Member Posts: 339 Bronze Badge
    edited Oct 15, 2019 11:31AM

    Thank You very much for the suggestions Brian !

  • Franck Pachot
    Franck Pachot Member Posts: 912 Bronze Trophy
    edited Oct 25, 2019 5:50PM

    Hi,

    CDB name should be like a host name: not really about what is inside - just a container.  <Business division Name>CDB<ascendingNumber> looks good. You may differentiate prod.

    PDB name is not related to its location (the goal is to relocate or clone them) so no CDB name in it. Environment is good and a name that identifies the data as well. So maybe <Business division Name>PDB<ApplicationName><Environment (like prod,UAT,SIT)> but I would add a number because you may create many thin clones of the same in dev.

    The application will connect with a service name which will have the application  plus <Business division Name>APP<ApplicationName><Environment (like prod,UAT,SIT)><workload (liike reporting/batch/online)>

    MaxMax
  • Dhyanswaroop S
    Dhyanswaroop S Member Posts: 1 Green Ribbon

    This is how we do it. C(project name) 01 (number) P/D/Q (based on prod/Dev/QA environment) . Replace C with P for the pluggable database.

    flying_penguin