Beginners Guide to Oracle Database 18c Multitenant Architecture – The Geek Diary

The Oracle Database 18c release is here, and it brings some big changes with it, which I will detail in this blog post. These include the introduction of the Multitenant architecture, which aims to simplify the management of multiple databases in one instance. It also includes several new features and enhancements that I hope everyone will enjoy.

As the number of database servers in enterprises continues to increase, the database administrator has to grapple with a new problem: how to manage the information for those servers. For example, companies often have several database servers with multiple applications, each with a different protocol to communicate with the database.

SQL databases are used by all kinds of organizations from government agencies to non-profits and even some of the largest companies in the world. The use of SQL databases has evolved over the years and you can find all kinds of new features and enhancements to the technology. But despite all the new features and more, there are still some best practices for setting up multitenant deployments that have been around since the early days.

calls

Starting with Oracle Database 12c, the multi-tenant architecture allows you to have multiple linkable databases in one Oracle Database instance. What is the advantage of using a multi-tenant architecture in Oracle Database 18c? Currently, many Oracle customers have a large number of departmental applications built on Oracle DBMS.

• These applications rarely use a significant percentage of the hardware they are deployed on. The large number of instances and the amount of dedicated storage for all these small databases make it impossible to host them on the same physical server and storage space.
• Moreover, they are usually not so complex as to require the full attention of a full-time administrator.
• To better utilize hardware and DBA resources, customers prefer to consolidate most of these departmental applications into a single Oracle DBMS.

The multi-tenant architecture allows DBAs to consolidate a large number of small departmental database applications into one larger RDBMS installation.

Architecture without CoB

In Oracle Database Release 11g, only the non-CDB type is supported. The old architecture is called the non-CBD architecture. The term non-CDB is an abbreviation for a database released before version 12.1Oracle. This type of database requires its own instance, which must have its own background processes and memory allocation for the SGA. It must store the Oracle metadata in its data directory. The DBA can still create non-CDB Oracle 18c with the same architecture as before 12.1. These databases are not multi-user container databases; they are non-CDBs. When managing small departmental database applications, it is necessary to create as many databases as there are applications, which leads to a multiplication of the number of instances. This increases the number of background processes and the memory allocation for the SGA. Thus, you need to ensure sufficient storage space for all data dictionaries in these databases. When applications need to be upgraded to a new version, each database needs to be updated, which is time consuming for the DBA.

Multi-user architecture: Benefits

Consolidating multiple non-DBMS databases on a single platform reduces instance costs, avoids redundant copies of data dictionaries, and thus spreads out storage. This allows for rapid deployment, saves time on upgrades and increases security by separating responsibilities and isolating applications. A new multi-user database that merges databases is a multi-user container database or MDC, and a database merged into an MDC is a plug-in database or PDB.

• No modification of applications and very fast initialization: A new database can be created quickly. You can quickly create a clone of the populated database. A populated database can be quickly disconnected from its CBD on one platform and quickly connected to a CBD on another platform. A non-CDB can be quickly connected to the CBD.
• Fast update and correction of the Oracle database version: The cost (time and human effort) of updating a large number of PDBs is equivalent to the cost of updating a single Oracle database site. You can also upgrade a PDB by disconnecting it and connecting it to a CDB with a different version of the Oracle database.
• Ensure separation of functions : The application manager can perform the required tasks by connecting to the PDB that implements its back-end. However, a user logged into one PDB cannot see the other PDBs. To manage PDBs as entities (for example, to create, reset, disconnect, or join one), the system administrator must log into the CDB. A user who connects to the CDB must have special rights.
• Application Insulation : This task cannot be performed manually unless you have B. Oracle Database Vault. for example. A good example of isolation is dictionary partitioning, which allows an Oracle database to manage multiple PDBs separately from each other and from the CDB itself.

Other benefits of a multi-tenant architecture

• The multi-tenant architecture offers the principle of backward compatibility. An example would be the display of data dictionaries. The DBA_OBJECTS view shows the same results in the PDB as in the non-CDB for a given application.
• The multi-user architecture is designed to be fully interoperable with RAC. Each Oracle RAC instance opens the CDB as a single entity. The session only sees the PDB it connects to.
• Enterprise Manager integrates the CDB and simulates the separation of responsibilities of CDB and PDB administrators.
  • The CBD can be defined as a target. An Enterprise Manager user may be authorized to act as a CDB administrator for this purpose.
  • PDB can be defined as a sub-objective of the CBD target. An Enterprise Manager user may be authorized to act as a PDB administrator for this purpose. An Enterprise Manager user with PDB administrator rights for a particular PDB can log in to that PDB and ignore the existence of similar PDBs in the same CDB. Furthermore, this Enterprise Manager user does not know that the environment is a CDB and not a non-CDB if his or her intention is to perform application administration tasks.
• A new feature has been added to the inter-PDB resource manager, allowing you to manage resources between PDBs within a CDB. The principle of backward compatibility means that the resource manager should operate in the same way in PDBs as in non-PDBs.
• Updating an entire CDB with n PDBs achieves the effect of updating n non-CDBs at the expense of updating one non-CDB.

Oracle Multitenant Container Database

The image above shows the combination of three applications deployed in three different non-CDBs into one. This image shows a multi-user containerized database with four containers: a root CDB and three plugin databases. Each linkable database has its own specific application and is managed by its own DBA or by the container administrator, who is the SYS user of the root CDB container, a shared user. This shared SYS user can manage the CDB root container and any pluggable database. A pluggable database is a set of database schemas that is logically presented to users and applications as a separate database. But at the physical level, a multi-user container database has a database instance and database files, just like a non-containerized database. Nothing changes: neither the client code nor the database objects. Linking a non-CDB to a CDB is very simple. CBD avoids redundancy:

• Basic process
• Memory allocation
• Oracle metadata in multiple data dictionaries

A CDB in which several applications are grouped together ends up with a single instance. This instance has a set of background processes, an APG distribution, and a data dictionary in the CDB root container that is common to all PDBs. Each PDB maintains its own application data dictionary. If you need to install a patch or update an application, the maintenance operation can be performed only once on the CDB. Therefore, all CBD-related applications are patched or updated at the same time.

ConfigurationsConfigurations

What are the options for database configuration?

• Each database instance can be connected to one and only one non-CDB or multi-tenant container database.
• In an Oracle RAC environment, multiple instances can be connected to a non-CDB or multi-tenant container database.
• An instance is associated with an entire CBD.

If there are multiple databases on the same server, there is a separate instance for each non-CDB or CDB database. An instance cannot be shared between a non-CDB and a CDB. There are three possible configurations:

Multi-user configuration

Typically, there is more than one PDB per CDB, but it can contain zero, one or more PDBs at a time, taking advantage of all the features of the multi-tenant architecture, which requires the Oracle Multitenant Option license.

Single tenant configuration

A special case of a multi-tenant architecture that does not require a license option.

not KDB

Oracle Database 11g Architecture

Database objects in non-CDB

How is Oracle metadata shared across multiple applications in non-CDB? Immediately after the creation of a non-CDB, only the objects provided by Oracle are in the data dictionary. No user data is available at this time. The only schemas in the database are those required by the database system.

User-added objects in non-BCD

The non-CDB adds users and user data. It is preferable to add this data to the tablespaces dedicated to user data. By storing data in separate tablespaces, data can be more easily protected, backed up, and transported even though the user’s metadata is in the data dictionary with the Oracle system’s metadata:

• Object definitions
• User definitions
• PL/SQL code
• Other user-created objects

System objects in USER container

In a multi-user containerized database, the container concept is used to separate Oracle-provided objects and user data, including metadata, into separate containers. Each container has a SYSTEM tablespace where the data dictionary is stored.

• The Oracle-only metadata container has a dictionary that contains metadata for Oracle-provided objects.
• The user container has a dictionary that contains the user’s metadata.

One of the goals of a multi-tenant architecture is that each container has an individual relationship with the application. Sharing the metadata is the first step, the second is to give the application or user container access to the objects provided by Oracle. The user’s container is called a plug-in database (PDB). Oracle objects could be duplicated in each PDB, but this takes up a lot of space and requires each PDB to be updated when an Oracle-provided object is changed, e.g., “I’m not going to duplicate any of the objects”. The objects provided by Oracle reside in a container called the CDB root container and named CDB$ROOT. PDB pointers to Oracle objects provide access to system objects without duplicating them in the PDB. PDB has all the necessary components to become a complete environment for database applications. The application can work in the PDB in the same way as in other databases.

Provision of a plug-in database

To create a new PDB, use the original PDB. This boot CDB container is called PDB$SEED and is part of every CDB. If you create a new PDB, the CDB of the original PDB is cloned and the new PDB is named as you specified. This process is very fast. It’s measured in seconds. The time it takes to copy the files. There are several ways to deploy plug-in databases:

• Create a new PDB from the PDB$SEED plug-in database: This scenario is z. This is useful for example when implementing a new application.
• Creating a new PDB from a non-CDB : Connect non-CDBs to CDBs as PDBs as part of the migration strategy. It is also a good way to consolidate non-BDCs into BDCs.
• Non-CDB cloning : Clone non-CDBs into CDBs as PDBs as part of the migration strategy. This is a good way to keep the non-PDB and be able to compare performance between the new PDB and the original non-PDB, or at least wait until you are sure the PDB can work properly.
• Clone a PDB from another PDB to the same or another CDB: An example of such a method is application testing. Move the PDB to another CDB to send sources.
• Connecting an unconnected PDB to another CDB : For example, instead of upgrading a multi-tenant container database from one version to another, you can disconnect a plug-in database from one version of Oracle Database and then connect it to a newly created multi-tenant container database from a higher version.
• Proxy PDB : The PDB proxy provides full access to another PDB in the external CDB. This feature allows you to create location-transparent applications that can combine data from multiple sources located in the same data center or spread across multiple data centers.

Multi-tenant containerized database architecture

The image above shows a CDB with four containers: a root CDB, a seed CDB and two PDBs. Both applications use a single instance and are maintained separately. At the physical level, a CDB has a database instance and database files, just like a non-CDB.

• The redo log files are common to the entire CDB. The information contained therein shall be annotated with the identifier of the PDB in which the change occurs. Oracle GoldenGate can include the redo log format for CDB. All PDBs in the CDB share the ARCHIVELOG mode of this CDB.
• The control files are the same for the entire CBD. The control files are updated with any additional tablespaces and data files from the connected PDBs.
• The default UNDO tablespace is local to each container. You can have a common UNDO tablespace for all containers. In this case, there is one UNDO tablespace per RAC database instance.
• A CDB or PDB root can have only one default temporary tablespace or group of tablespaces. Each PDB can have temporary tablespaces for use by local or shared PDB users.
• Each container has its own data dictionary stored in the corresponding SYSTEM tablespace with its own metadata and in the SYSAUX tablespace.
• PDBs can create tablespaces within a PDB based on application requirements.
• Each data file is associated with a specific container called CON_ID.

Container

In summary, a CDB is an Oracle database that contains the CDB root, the CDB seed, and possibly several pluggable databases (PDBs). What does PDB mean in CDB? PDB is the bottom part of the horizontally partitioned data dictionary plus the user data that consumes quotas. A non-CDB cannot contain a PDB. The multi-tenant architecture allows an Oracle database to contain a portable collection of schema, schema, and non-schema objects, which are presented to the Oracle Net client as a separate database. In order for a PDB to exist and function, a CDB needs a container of sorts, the CDB root, which is created when the CDB is created. The CDB root directory is a system container that stores shared users – users who can log into multiple containers – as well as metadata and system data. The source code of the PL/SQL packages provided by the system is stored in the root of the CDB. There is only one seed PDO in the CBD. CDB-Seed-PDB is a system template used to create new PDBs. A CDB can contain a maximum of 4,096 PDBs, including the start CDB, and the number of services is limited to 10,000. The V$CONTAINERS view displays all VOBs, including the root of the CDB and the seeds of the CDB. Summary,

root CDB

• The first mandatory container created when a CDB is created.
• Common objects and metadata provided by Oracle
• Common users and roles of Oracle

Plug-in databases (PDBs)

• Tabular spaces (permanent and temporary)
• Schemes / Objects / Privileges
• Created / Cloned / Disconnected / Connected / Proxy
• Specific PDB : The CDB seed (PDB$SEED) is used to quickly create a new PDB.

Tools

There are several tools for creating and updating container databases. As the following table shows, you can create new CDBs or PDBs using SQL*Plus or Database Configuration Assistant (DBCA) or during the installation of the Oracle 18c database. SQL Developer and EM Cloud Control allow you to create plug-in databases.

After a CDB is created, you can use views to explore the CDB instance, database architecture, files, and databases to be connected. Search views directly with SELECT statements using SQL*Plus or indirectly with GUI tools such as Enterprise Manager or SQL Developer. You can upgrade from Oracle Database Release 12c CDB to Oracle Database 18c CDB using Enterprise Manager or Database Upgrade Assistant (DBUA). Message: Oracle Enterprise Manager Database Express cannot be used to create a CDB, but it can be used to create a PDB and examine the PDB architecture or CDB structure with different port configurations.

Data dictionary and dynamic views

For the sake of backward compatibility, DBA views in the PDB have the same results as in the non-CDB: DBA_OBJECTS returns the objects that exist in the PDB from which the query is executed. This means that although PDB and CDB Root have separate data dictionaries, any data dictionary view in PDB will show results from both data dictionaries. Even in a populated KDB, the DBA_xxx view in the root of the KDB shows only the Oracle-supplied system, as in the newly created non-KDB. A family of data dictionary views with names like CDB_xxx is maintained to support the tasks of the CDB administrator. Each DBA_xxx view has a counterpart to the CDB_xxx view with an additional Con_ID column indicating which container the listed facts come from. Query the CDB_xxx views from the root of the CDB and from each PDB. The results of a given CDB_xxx view are the union of the results of the DBA_xxx view on the root of the CDB and all currently open PDBs. When the CDB_xxx view is requested by the PDB, it only displays the information shown in its counterpart in the DBA_xxx view. If you connect to the CDB root directory and query CDB_USERS, you get a list of public and local users for each container. If you make a query for DBA_USERS, you get a list of validated users. When you connect to the PDB and query CDB_USERS or DBA_USERS, you get the same list of PDB users, public and local. The same principle of backward compatibility applies to all known representations of V$. For example: SQL> select OBJECT_ID, ORACLE_USERNAME, LOCKED_MODE, CON_ID from V$LOCKED_OBJECT ; OBJECT_ID ORACLE_USERNAME LOCKED_MODE CON_ID ———- —————- ———– ——- 83711 SYS 3 3

Terminology

There are different types of DBAs.

• Apart from the database, the DBA is responsible for all administrative tasks at database level.
• There are different levels of management within the SAB:
  • DBA responsible for managing the CDB instance, the CDB root and all PDBs.
  • DBAs responsible for the management of the respective PDBs

The terminology of entities in the CBD and PDB is as follows:

• Common users, roles and profiles exist in all Containers and have the same name in all Containers. Local users, roles and profiles have a unique name for the container (PDB) they reside in.
• Shared permissions are permissions that are normally granted to all containers in the CDB, not permissions granted locally in the PDB.
• Common objects exist in the schemas provided by Oracle. Local objects are created in the PDB in local schemas.
• CBD resource management functions at the CBD level and CBD resource management functions at the CBD level.
• Audit rules can be created in the root directory of the CDB and in each PDB. The same concept applies to master encryption keys and to fields of database vaults and control rules.
• XStream Out is only available at the CDB level and XStream In is only available at the PDB level. XStream consists of Oracle database components and application programming interfaces (APIs) that allow client applications to receive data changes from the Oracle database and send data changes to the Oracle database. XStream Out provides components and APIs for Oracle databases that can be used to exchange changes in Oracle databases with other systems. XStream In provides components and APIs for the Oracle database that allow data changes made in other systems to be exchanged with the Oracle database.

Exhibition

– If the CDB has a Unicode AL32UTF8 database character set, the CDB can contain PDBs with different database character sets, since all character sets can be converted to AL32UTF8. The character set of an existing PDB can be replaced with a compatible character set by following the character set migration steps of the existing database. There is only one sp file for the CBD. The PDB parameter values are stored in a dictionary table. – Use a database reference to access an object in another PDB. – If you use Oracle Active Dataguard to create reports, you do not need to replicate the PDB. Oracle Database Release 12c allows you to implement a subset of the PDB in a standby database by using the STANDBYS proposal with a PDB list for replication. When a user uses the ALTER DATABASE SWITCHOVER TO … When executing the VERIFY command to switch the backup database with a subset of the BOP to the primary database, an error message is displayed. However, these backup databases can become the primary databases. In the following statement, PDB1 is created on the backup databases stdby1 and stdby2 : SQL> CREATE PLUGGABLE DATABASE pdb1 … STANDBYS=(stdby1,stdby2) ; – In Oracle Database Vault, each PDB has its own Database Vault metadata. Database Vault constructs, such as. B., are isolated in the PDB. Oracle Database 12.2 introduces protection for shared objects with shared scopes and control rules. – Each PDB has its own master key that is used to encrypt the PDB’s data. The TDE master key must be moved from the source database key repository to the target database key repository when the PDB is moved from one node to another. For column coding, each PDB maintains its own ENC$, which is not an object associated with metadata. – Only one audit configuration is visible and is applied to all PDBs. This allows administrators to not configure monitoring on a per-container basis. This allows for the creation of not only audit policies used by all PDBs, but also audit policies used exclusively for each PDB. An audit configuration that does not apply to all PDBs means that it applies only within the PDB and is not visible outside the PDB. – Heat Map and Automatic Data Optimization (ADO) allow you to automate Information Lifecycle Management (ILM) activities by automating the movement of data to the appropriate storage format using compression and tiered storage. ADO relies on statistics reported and collected by Heat Map, which tracks activity at the segment and block level. Heat Map and ADO are included in CDBs as of Oracle Database 12c version 2. – XStream is a software interface that allows a client application to access changes to the database, known as the XStream outbound server. With XStream Inbound Server, a client application can propagate changes to the database and use the application process available in the database. Oracle GoldenGate is a logical replication, and XStream is licensed by Oracle GoldenGate (OGG). Changes to the database must always be entered from the root of the CDB. The XStream output can be configured to capture changes to the PDB or the entire CDB. The transfer of changes via Oracle GoldenGate is performed for each PDB. The incoming XStream server is configured to apply changes to a specific PDB and do all its work in the context of that PDB. Support in XStream and Oracle GoldenGate is applied without major limitations. – The special Logminer queries (V$LOGMNR_CONTENTS, DBMS_LOGMNR) support common client objects in the PDB in the same way as local objects in the PDB. – In general, all user-created Scheduler objects can be exported or imported through the data pump in the PDB. Predefined planner objects cannot be exported, i.e. any changes made to these objects by the user must be reapplied when importing the database into the PDB. A task defined in the APB is only executed when the APB is open.Not all developers get the chance to work with multi-tenant databases. It’s not just about learning about the new features, but also about how to use them properly in your projects. This article aims to provide a beginners guide to the new multi-tenant architecture in Oracle Database 18c, and the changes that are required for you to use them correctly.. Read more about what is a container database in oracle 19c and let us know what you think.

Related Tags:

oracle 12c multitenant architecture pdforacle multitenant architectureoracle 19c multitenant architectureoracle multitenant architecture diagramoracle pluggable databaseoracle 12c pluggable database tutorial,People also search for,Privacy settings,How Search works,oracle multitenant architecture diagram,oracle multitenant architecture interview questions,oracle pluggable database,what is a container database in oracle 19c,oracle 12c pluggable database tutorial,which is a container for other database objects,benefits of pluggable database,difference between cdb and pdb in oracle 12c