Below are some interesting conceptual points regarding Oracle Multitenant CD-PDB Architecture which can prove useful for DBA who is new to Oracle multi-tenant architecture. This is not an exhaustive list and there are will be many more points to keep in mind when you are working with CDB-PDB database architecture.
1. Multiple CDBs can run on same server
2. Multiple CDBs can run out of same ORACLE_HOME
3. Common user name in cdb and pdb starts with c##
4. There is one set of background processes shared by the CDB root and all PDBs.
5. There is a single set of redo logs and a single set of control files for an entire CDB and all its PDBs.
6. There are single SGA shared by all pluggable databases. However, you can control SGA consumptions by PDBs by using DB parameters
7. You can have a separate undo tablespace for PDBs (preferred) or share the one from CDB.
8. There is a separate SYSTEM tablespace for the root and for each PDB.
9. There is a separate SYSAUX tablespace for the root and for each PDB.
10. A Single copy of the Alert log is generated which contains warnings and alert information for all PDBs.
11. All traces generated from all PDBs are currently found in the “Diag Trace” of the container database.
12. One way to connect to PDB is sqlplus username/password@//<server_name>/<pdb_name>
13. There is one default temporary tablespace for the entire CDB. However, you can create additional temporary tablespaces in individual PDBs.
14. You can specify a separate default tablespace for the root and for each PDB
15. There are separate data files for the root, the seed, and each PDB.
16. In a CDB, most user data is in the PDBs. The root contains no user data or minimal user data.
17. A CDB uses a single character set. All of the PDBs in the CDB use this character set. Oracle strongly recommends AL32UTF8 for the CDB database character set and AL16UTF16 for the CDB national character set.
18. There is a single listener.ora, tnsnames.ora, and sqlnet.ora file for an entire CDB. All of the PDBs in the CDB use these files.
19. In Oracle Standard Edition you may only create one PDB, per CDB
20. NO transaction can span across PDBS
21. Database timezone can be set on a per-PDB basis.
22. PDBs do not have an init.ora file or SPFILE, only the root’s CDB has one. Parameters for the PDBs are stored in the DB’s dictionary, in the PDB_SPFILE$ table.
23. Also, adding to the above point, all the information about the modified parameters for a PDB are stored in the PDB_SPFILE$ table in the ROOT CDB. The only time, TEMPORARILY, when parameters are copied into the PDB’s own pdb_spfile$ table is during PDB UNPLUG, and this is done as a fallback in case the XML is lost.
24. Not all parameters are PDB modifiable. To identify which parameters can be modified for a PDB, the ISPDB_MODIFIABLE column in the V$SYSTEM_PARAMETER or V$PARAMETER views must be TRUE.
25. PDBs inherit parameter values from the root CDB unless they are overridden at the PDB level.
26. Another interesting point is SPFILE in PDBs is always enabled, as long as the root’s CDB is open. This is true even if the CDB is not using an SPFILE, Oracle allows PDB to use SPFILE because PDBs do not have any other means for persistent parameters, (PDBs do not support PFILE or init.ora file).
27. In order to modify parameters at PDB level you need to be connected to the PDB container for which you want to make the modification. If you are connected at ROOT container the parameter modification will take place for entire CDB.
28. Every time when you open a PDB, if that particular PDB has its own values for some of the init parameters the values from the CDB’s SPFILE are overwritten with the values from PDB_SPFILE$.
29. All initialization parameters can be set for the root CDB DB. For any initialization parameter that is not set explicitly for a PDB, the PDB inherits the root’s parameter value.
30. Since the PDB’s spfile parameters are stored in a dictionary table in the ROOT CDB, after executing ‘ALTER SYSTEM RESET’ command, the row exists in PDB_SPFILE$ but it is marked as DELETED parameter. This is equivalent to removing the parameter from the regular spfile in a non CDB.
31. There is no current support for resetting in-memory parameters for regular non-multitenant databases, and hence that is not supported for PDB either.
32. Setting parameters for a RAC PDB is the same as setting parameters for a non-Multitenant database with the difference that if you want to set a parameter to a specific instance of a RAC PDB database the SID provided needs to be from the CDB’s instance name.
- Building a Scalable and Secure AI Infrastructure in the Cloud - May 12, 2024
- Harnessing the Power of AI in the Cloud for Business Transformation - March 2, 2024
- Building a Resilient Cybersecurity Framework in the Oracle Cloud - January 16, 2024