Simple Introduction of Oracle Multitenant Architecture

Oracle Multitenant Architecture:

Multitenant Database is one of the biggest architectural level changes in oracle database history from 12c (12.1) release. With this changes oracle introduced new concepts of CDB (container database) and PDB (pluggable database) which means unlike normal non-cdb(Normal Database), here we have option to create multiple pluggable databases using single instance to save time, storage, resource and administration cost.

Basic multitenant architecture contains root CDB(CDB$ROOT), seed PDB named as PDB$SEED and zero or more user created PDBs.

Container Database:

The root container is named CDB$ROOT– In multitenant architecture CDB is very similar to conventional oracle database, as it contains most of the working parts you will be already aware (Control files, Data files, Redo logs, Temp files and undo etc…). It also houses the data dictionary for those objects that are owned by the root container and those that are visible to all PDBs.

Seed PDB(PDB$SEED):

Every root container will have a default seed pluggable database. The seed PDB is a system supplied template that the CDB can use to create new PDB’s, you can add or modify objects in PDB$SEED.

PDB:

Pluggable Database is a user created entity that contains the data and code required for a specific set of features. Creating a new pdb is coping from seed pdb (peed$seed) template and it take time as simple as long as the files to take copy.

For example, a PDB can support a specific application, such as a human resources or sales application. No PDBs exist at creation of the CDB. You add PDBs based on your business requirements.

Benefits of the Multitenant Architecture:

• -        Cost Reduction
• -        Easier and more rapid movement of data and code
• -        Easier Management
• -        Easy to monitor of physical database.
• -        Simplify maintenance tasks like database patching and upgrading database
• -        Separation of data and code
• -        Reduce Administration, Operation, data center, Storage costs
• -        Benefits of data dictionary separation include the following:
• -        Easier migration of data and code

(For example, instead of upgrading a CDB from one database release to another, you can unplug a PDB from the existing CDB, and then plug it into a newly created CDB from a higher release.)

• -        Easier testing of applications

(You can develop an application on a test PDB and, when it is ready for deployment, plug this PDB into the production CDB.)

[root@192.168.1.121 SID=none ~]# su - oracle

[oracle@192.168.1.121 SID=proddb1 ~]$sqlplus '/as sysdba'

SQL> show con_name

CON_NAME

------------------------------

CDB$ROOT

 

SQL> show pdbs;

 CON_ID CON_NAME                       OPEN MODE RESTRICTED

---------- ------------------------------ ---------- ----------

         2 PDB$SEED                       READ ONLY NO

         3 SALES                          READ WRITE NO

         4 HR                             READ WRITE NO

 

SQL> SELECT SYS_CONTEXT ('USERENV', 'CON_NAME') FROM DUAL;

------------------------------------------------------------------CDB$ROOT

 

SQL> select NAME, CDB, CON_ID, OPEN_MODE from V$DATABASE;

 

NAME      CDB     CON_ID OPEN_MODE

--------- --- ---------- --------------------

PDBDB1    YES          0 READ WRITE

 

[oracle@192.168.1.121 SID=proddb1 ~]$lsnrctl status

 

LSNRCTL for Linux: Version 12.1.0.2.0 - Production on 27-JAN-2021 16:47:00

 

Copyright (c) 1991, 2014, Oracle.  All rights reserved.

 

Connecting to (ADDRESS=(PROTOCOL=tcp)(HOST=)(PORT=1521))

STATUS of the LISTENER

------------------------

Alias                     LISTENER

Version                   TNSLSNR for Linux: Version 12.1.0.2.0 - Production

Start Date                21-JAN-2021 16:57:09

Uptime                    1 days 23 hr. 49 min. 50 sec

Trace Level               off

Security                  ON: Local OS Authentication

SNMP                      OFF

Listener Parameter File   /u05/app/grid/12.1.0/network/admin/listener.ora

Listener Log File         /u05/app/oracle/diag/tnslsnr/192.168.1.121/listener/alert/log.xml

Listening Endpoints Summary...

  (DESCRIPTION=(ADDRESS=(PROTOCOL=ipc)(KEY=LISTENER)))

  (DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=192.168.1.121)(PORT=1521)))

  (DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=192.168.1.121)(PORT=1521)))

Services Summary...

Service "+ASM" has 1 instance(s).

  Instance "+ASM1", status READY, has 1 handler(s) for this service...

Service "proddb1" has 1 instance(s).

  Instance "proddb1", status READY, has 1 handler(s) for this service...

Service "proddb1XDB" has 1 instance(s).

  Instance "prodb1", status READY, has 1 handler(s) for this service...

Service "sales" has 1 instance(s).

  Instance "proddb1", status READY, has 1 handler(s) for this service...

Service "hr" has 1 instance(s).

The command completed successfully