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 126.96.36.199 to 19.3. To do that, I created a 19.3 CDB. I unplug the 188.8.131.52 PDB from the 184.108.40.206 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.
Thank You very much for the suggestions Brian !
1 person found this helpful
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)>