How does Oracle read a file?

A CDB database container contains the following Components:

The ROOT component, also known as CDB$ROOT, stores Oracle provided metadata and Common User, which is the User that exists in each container. An example of metadata is the source code for PL/SQL packages provided by Oracle.

The SEED component is also called PDB$Seed. This is a template for creating a PDBS database. You cannot add or modify an object in the SEED. There can be one and only one SEED in a CDB.

PDBs can have one or more PDBs in a CDB, and PDBs are backward compatible and can operate PDBs as they used to in a database, here referring to most normal operations.

Each of these components can be called a container. Thus, ROOT is a container, Seed is a container, and each PDB is a container. Each container has a unique ID and name in the CDB.

Note:

A CDB can contain 253 PDBs (removing a seed can create 252 PDBs).

file

Data files: The ROOT, SEED, and data files for each PDB are independent.

REDO: A single instance CDB has a REDO log; There is one redo log per instance in the RAC environment.

Control file: A CDB also has only one control file (which can be multiplexed).

A CDB uses an SPFILE or a PFILE, where the value of the parameter set for ROOT can be inherited by the PDB. Alternatively, you can use the ALTER SYSTEM statement to set the parameters of the PDB. When performing operations on parameter files, you must use common user and connect to the database using AS SYSDBA, ASSYSOPER, AND AS SYSBACKUP. To create a CDB, you must set the initialization parameter ENABLE_PLuggable_DATABASE to TRUE.

Processes: There is only a set of background processes that are shared by ROOT and all PDBs.

Database setup

Character Set: All PDB character sets use the CDB character set.

Time zone: You can set the time zone for all PDBs to be the same as the CDB, or you can set the time zone for PDBs individually.

DB_SIZE: The block size is applied to the entire CDB.

Db_name: www.cungun.comROOT global database name is the global database name of CDB; The global database name of the PDB is defined by the PDB name and DB_DOMAIN parameter.

Table Spaces:

ROOT and each PDB have their own SYSAUX and SYSTEM tablespaces. You can set the default tablespace for ROOT and for each PDB. The default temporary tablespace is only one for the entire CDB, but temporary tablespaces can be created for each PDB.

Undo tablespaces are unique to CDBs. In CDB, the initialization parameter UNDO_MANAGEMENT must be set to AUTO. When the current container is a PDB, the UNDO tablespace cannot be viewed from the data dictionary view, only from the dynamic performance view.

The advantages of the new features of PDB allow multiple PDBs to be integrated into one platform.

You can quickly provide a new PDB or a clone of an existing PDB.

Plugging allows you to quickly redeploy existing databases to a new platform.

Multiple PDB database patches or upgrades are done at once.

A PDB can be patched or upgraded by plugging a single PDB into a different CDB on a higher version.

Separate the game content of a PDB from many PDBs within the same CDB.

Separate the responsibilities of these PDB application administrators.

In a CDB, you can have many PDBs.

PDB and regular databases prior to 12.1 are backward compatible.

The PDB is transparent to the application – you don’t need to change the client code or database objects.

Each instance in the RAC opens the CDB as a whole (so the CDB and the PDB database version within it are the same).

The session only sees the PDB to which it is connected.

You can pull out a PDB from a CDB and insert another CDB.

You can clone PDB within the same CDB or between different CDBs.

The resource manager is expanded with the capabilities of the PDB.

Through SQL statements to achieve entity PDB operations (create, unplug, insert, clone, clear, set open mode).

The CDB administrator performs these operations when connecting to the so-called “ROOT.”

All PDBs can be backed up at once, but can be restored separately.

Each PDB has its own private data dictionary for user-created database objects; On the other hand, the CDB as a whole also contains the Oracle supplied system’s data dictionaries, where each data dictionary defines its own namespace. In other words, there are global data dictionaries (CDB level) and local data dictionaries (PDB level).

There is a new separate data dictionary architecture that allows a PDB to be quickly pulled from a CDB and inserted into a different CDB.

Each PDB sees only a read-only definition of the system provided by Oracle.

There are global database parameters and local database parameters. The PDB parameters belong only to the specific PDB and will remain the same after the pull-out.

The database user can be global (CDB) or local (PDB). The SYS and SYSTEM users start out in two levels of DB. If you create a new user in the CDB, you will also see the user in the PDB. Users created in a PDB can only be used in that PDB.

Temporary table Spaces can be global or local.

Both the Redo log and Undo tablespaces are global (CDB level).

Data Guard works as a unit at the CDB level; Backups scheduled by RMAN are also done as a whole at the CDB level; You can backup only one PDB at any time.

No code changes are required when applying PDB connections; System administrators can connect to CDB; The service name in the connection string identifies the target PDB.

PDB allows clearer declarations to define an application; A PDB knows nothing about other PDBs in the same CDB; Each PDB is an airtight container. This ensures the independence and security of the new layer DB.