Oracle Database 19c Overview And New Features
Multitenant Architecture
Every CDB has the following containers:
- Exactly one CDB root container (also called simply the root)
- The CDB root is a collection of schemas, schema objects, and nonschema objects to which all PDBs belong . The root stores Oracle-supplied metadata and common users. . A common user is a database user known in every container . The root container is named CDB$ROOT.
- Exactly one system container
- The system container includes the root CDB and all PDBs in the CDB. Thus, the system container is the logical container for the CDB itself.
- Zero or more application containers
- An application container consists of exactly one application root, and the PDBs plugged in to this root. Whereas the system container contains the CDB root and all the PDBs within the CDB, an application container includes only the PDBs plugged into the application root. An application root belongs to the CDB root and no other container.
- Zero or more user-created PDBs
- You can define a set of application-specific PDBs as a single component, called an application container. You can then define one or more applications within this container. Each application is a named, versioned set of common metadata and data shared within this application container.
- For example, each customer of a SaaS vendor could have its own application PDB. Each application PDB might have identically defined tables named sales_mlt, with different data in each PDB. The PDBs could share a data-linked common object named countries_olt, which has identical data in each PDB. As an application administrator, you could manage the master application definition so that every new customer gets a PDB with the same objects, and every change to existing schemas (for example, the addition of a new table, or a change in the definition of a table) applies to all PDBs that share the application definition.
- A PDB contains the data and code required for a specific set of features ( 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.
- A PDB belongs to exactly zero or one application container. If a PDB belongs to an application container, then it is an application PDB. For example, the cust1_pdb and cust2_pdb application PDBs might belong to the saas_sales_ac application container, in which case they belong to no other application containers. An application seed is an optional application PDB that acts as a user-created PDB template, enabling you to create new application PDBs rapidly.
- Exactly one seed PDB
- The seed PDB is a system-supplied template that the CDB can use to create new PDBs. The seed PDB is named PDB$SEED. You cannot add or modify objects in PDB$SEED.
- Seed: The seed, named PDB$SEED, is a template that you can use to create new PDBs. You cannot add objects to or modify objects in the seed. A CDB has exactly one seed.
- PDBs: A PDB appears to users and applications as if it were a non-CDB. For example, a PDB can contain the data and code required to support a specific application. A PDB is fully backward compatible with Oracle Database releases before Oracle Database 12c.
- Each of these components is called a container. Therefore, the root is a container, the seed is a container, and each PDB is a container. Each container has a unique container ID and name within a CDB.
- The multitenant architecture enables an Oracle database to function as a multitenant container database (CDB) that includes zero, one, or many customer-created Pluggable Databases (PDBs). A PDB is a portable collection of schemas, schema objects, and nonschema objects that appears to an Oracle Net client as a non-CDB. All Oracle databases before Oracle Database 12 were non-CDBs.
- A container is logical collection of data or metadata within the multitenant architecture
A CDB includes the following components:
- Root: The root, named CDB$ROOT, stores Oracle-supplied metadata and common users. Exactly one system container. The CDB root is a collection of schemas, schema objects, and nonschema objects to which all PDBs belong. The root container is named CDB$ROOT.
- In multitenant Architecture ,Memory and processes require at mutlitenant container only . It support upto 252 PDBS
- Components of a Multitenant Architecure is CDB,ROOT and PDB
- The container database (CDB) is the database that is capable of supporting multitenancy.
- The noncontainer database (non-CDB) is used to identify the databases as we know them from previous releases. These databases do not support the Oracle 12c multitenancy architecture.
- CDB is a normal database with additional capability of storing one or more non CDB
- A CDB has a root container that is used to manage CDBs and to maintain system metadata and objects only. The root container is also referred to as CDB$ROOT.
- Oracle supplied container is called root container
- non CDB's within CDB are called PDB(Pluggable Database) .It share common SGA and Background processes
- The application databases that contain user data and metadata are called pluggable databases (PDBs).
- PDB's can be plugged and unplugged easily from one container to another container.
- Each PDB has its own set of tablespaces including system and sysaux
- PDB share UNDO ,REDO and CONTROL FILES,(s)pfile
- By Default the CDB has a single TEMP tablespace but PDBs may create their own.
- The resources under the CDB that are common and shared across all the PDBs go beyond just physical CPU and memory.
- Most of the background processes are shared.
- The memory structures associated with the system global area (SGA) are shared by the PDBs. The SGA for each PDB is a logically virtualized view of the SGA managed by the CDB.
- The V$ or GV$ views are based primarily on the contents of the SGA and therefore now contain a CON_ID field, which identifies the database context for the information.
- The internal structures and objects that any database requires to function are managed and maintained at the CDB level. These include SPFILEs, control files, online redo logs, standby redo logs, and undo tablespace.
- Users and privileges can be maintained at the CDB layer or can flow down to an individual PDB from the CDB.
New features and Advantage
Oracle 12c is significantly cost savings ,reduced risk and increased flexibility and also provide many technical benefits and business value
1 ) Multitenant and Pluggable Database feature allows to reduce costs by consolidating multiple databases and isolating applications while still sharing the same memory structures and clouding of databases into IaaS, PaaS, and DBaaS deployments. Oracle see multitenant databases as the first step to the cloud, As they allow to move databases between on-premise and the cloud, between cloud providers, or between different parts of a high-availability cloud design.
a) Cloning is fast as only user metadata/data needs to be cloned
b) Upgrades/patch can just unplug from old version and plug into new version
c) Reduces total db usage by not having repeated all the CDB resources.(Less disk space and memory usages)
2) Automatic Data Optimization feature monitors database read/write activity enabling DBAs to easily identify the data that is hot/warm/cold in terms of access frequency. Also smart compression and storage tiering automatically compress and tier data based on the activity and age of the data.
3) In-Memory Caching, Compression, and Column Store
It is a new set of features which allow for large amounts of memory-based data caching beyond the traditional buffer caches, and the cached data is stored in a compressed columnar format. This can dramatically improve performance and optimize server resources, and is surprisingly easy to implement since it is built into the database kernel and transparent to the application.
4) Recovery Manager (RMAN) Compression
Data is compressed before it is written to disk or tape, and doesn’t need to be uncompressed before recovery, leading to a reduction in storage costs of up to five times for backups.
5) Database Compression Technologies for all Data Types
Oracle 12c Database provides a comprehensive set of compression capabilities across all types of data without changes to your application to help customers improve query performance while reducing storage costs
6) Data Guard Network Compression
Redo log data is compressed before it is sent over the network to standby databases, which can double redo transport speed.
Creation of a CDB
- The CREATE DATABASE ... ENABLE PLUGGABLE DATABASE SQL statement creates a new CDB.If you do not specify the ENABLE PLUGGABLE DATABASE clause, then the newly created database is a non-CDB. In this case, the non-CDB can never contain PDBs.When you create a CDB, Oracle Database automatically creates a root container (CDB$ROOT) and a seed PDB (PDB$SEED).
SQL> SELECT NAME, CDB, CON_ID FROM V$DATABASE;
NAME CDB CON_ID
-- ------------ --- ----------
CDB1 YES 0
- The CREATE PLUGGABLE DATABASE SQL statement creates a PDB.The created PDB automatically includes a full data dictionary including metadata and internal links to system-supplied objects in the CDB root. You must define every PDB from a single root: either the CDB root or an application root.
- Each PDB has a globally unique identifier (GUID). The PDB GUID is primarily used to generate names for directories that store the PDB's files, including both Oracle Managed Files directories and non-Oracle Managed Files directories.
There are four methods to provision pluggable databases
1) Create a new PDB from PDB$SEED pluggable database:
for example, for a brand new application implementation.
2) Create a new PDB from a non-CDB: plug the non-CDBs in a CDB as PDBs, as part of migration strategy. It is also a good way to consolidate the non-CDBs into a CDB.
3) Clone a PDB from another PDB into the same or another CDB:
an example of this method is application testing.
4) Plug an unplugged PDB into a CDB, for example, instead of upgrading a multitenant container database from one release to another,
you can unplug a pluggable database from one Oracle Database release, and then plug it in to a newly created multitenant container database from a higher release.
Creation of a PDB
- Creation of a PDB from PDB$SEED or a Seed
- You can use the CREATE PLUGGABLE DATABASE statement to create a PDB from a seed.
A seed is a PDB that serves as a template for creation of another PDB. Creating a PDB from a seed copies some or all of the contents of a PDB, and then assigns a new unique identifier.
A seed PDB is either of the following:
- The PDB seed (PDB$SEED), which is a system-supplied template for creating PDBs
- Every CDB has exactly one PDB$SEED, which cannot be modified or dropped.
- An application seed, which is a user-created PDB for a specified application root
There are four methods to provision pluggable databases
1) Create a new PDB from PDB$SEED pluggable database:
for example, for a brand new application implementation.
2) Create a new PDB from a non-CDB: plug the non-CDBs in a CDB as PDBs, as part of migration strategy. It is also a good way to consolidate the non-CDBs into a CDB.
3) Clone a PDB from another PDB into the same or another CDB:
an example of this method is application testing.
4) Plug an unplugged PDB into a CDB, for example, instead of upgrading a multitenant container database from one release to another,
you can unplug a pluggable database from one Oracle Database release, and then plug it in to a newly created multitenant container database from a higher release.
Creation of a PDB by Cloning a PDB or a Non-CDB
- To clone a PDB or non-CDB, use the CREATE PLUGGABLE DATABASE statement with the FROM clause.
- In this technique, the source is either a non-CDB, or a PDB in a local or remote CDB. The target is the PDB copied from the source. The cloning operation copies the files associated with the source to a new location, and then assigns a new GUID to create the PDB.
- This technique is useful for quickly creating PDBs for testing and development. If a PDB is in local undo mode, then the source PDB can be open in read/write mode during the operation, referred to as hot cloning.
Note:
If you clone a PDB from a remote CDB, then you must use a database link.
If you run CREATE PLUGGABLE DATABASE statement in an application root, then the cloned PDB is created in the application container. In this case, the application name and version of the source PDB must be compatible with the application name and version of the application container.
Cloning a PDB
The following SQL statement clones a PDB named salespdb from the plugged-in PDB named hrpdb:
CREATE PLUGGABLE DATABASE salespdb FROM hrpd
Clones from PDB Snapshots
- Create a clone from a PDB snapshot by specifying USING SNAPSHOT clause of the CREATE PLUGGABLE DATABASE command.
- Creation of PDB Snapshots with the SNAPSHOT Clause
- A PDB snapshot is a point-in-time copy of a PDB. The source PDB can be open read-only or read/write while the snapshot is created. A PDB snapshot taken while the source PDB is open is called a hot clone. You can create clones from PDB snapshots. These clone PDBs are useful in development and testing.
- You can create snapshots manually using the SNAPSHOT clause of CREATE PLUGGABLE DATABASE (or ALTER PLUGGABLE DATABASE), or automatically using the EVERY interval clause.
- The following statement creates a PDB snapshot with the name pdb1_wed_4_1201:
ALTER PLUGGABLE DATABASE SNAPSHOT pdb1_wed_4_1201;
Creation of a PDB Clone with the USING SNAPSHOT Clause
- A clone from a PDB snapshot is a full, standalone PDB. Unlike a snapshot copy PDB, which is based on a storage-managed snapshot, you do not need to materialize a clone created from a PDB snapshot.
- To create a clone from a PDB snapshot, specify the USING SNAPSHOT clause of the CREATE PLUGGABLE DATABASE statement.
For example, the following statement clones a PDB named pdb1_copy from the PDB-level snapshot named pdb1_wed_4_1201:
CREATE PLUGGABLE DATABASE pdb1_copy FROM pdb1 USING SNAPSHOT pdb1_wed_4_1201;
Snapshot Copy PDBs
- A snapshot copy PDB is based on a copy of the underlying storage system. Snapshot copy PDBs reduce the amount of storage required for testing purposes and reduce creation time significantly.
- If the file system supports storage snapshots, then CREATE PLUGGABLE DATABASE ... FROM ... SNAPSHOT COPY copies a PDB from a source PDB, which can be read/write during the operation. The snapshot copy PDB files use copy-on-write technology. Only modified blocks require extra storage on disk. If the file system does not support storage snapshots or use Oracle Exadata sparse files, then the CLONEDB initialization parameter must be true, and the source PDB must be read-only for as long as the snapshot copy PDB exists.
- Because a snapshot copy PDB depends on storage-managed snapshots, you cannot unplug a snapshot copy PDB from the CDB root or application root. You cannot drop the storage snapshot on which a snapshot copy PDB is based.
- You can transform a snapshot copy PDB, which uses sparse files, into a full PDB. This process is known as materializing the snapshot copy PDB. Because a materialized PDB does not depend on the source PDB, you can drop it. Materialize a PDB by running the ALTER PLUGGABLE DATABASE MATERIALIZE command.
Refreshable Clone PDBs
- A refreshable clone PDB is a read-only clone that can periodically synchronize with its source PDB.
- Depending on the value specified in the REFRESH MODE clause, synchronization occurs automatically or manually. For example, if hrpdb_re_clone is a clone of hrpdb, then every month you could manually refresh hrpdb_re_clone with changes from hrpdb. Alternatively, you could configure hrpdb to propagate changes to hrpdb_re_clone automatically every 24 hours.
- You can switch the roles of a source PDB and its refreshable clone. This switchover can be useful for load balancing between CDBs, and when the source PDB suffers a failure.
Creation of a PDB by Plugging In
- We can create a PDB by plugging in an unplugged PDB, or plugging in a non-CDB as a PDB.
- Creation of a PDB by Plugging in an Unplugged PDB
- An unplugged PDB is a self-contained set of data files, and an XML metadata file that specifies the locations of the PDB files. To plug in an unplugged PDB, use the CREATE PLUGGABLE DATABASE statement with the USING clause.
- Specify the XML metadata file that describes the PDB and the files associated with the PDB.
- Specify a PDB archive file, which is a compressed file that contains both the XML file and PDB data files. You can create a PDB by specifying the archive file, and thereby avoid copying the XML file and the data files separately.
Creation of a PDB from a Non-CDB
- You can move a non-CDB into a PDB.
- Executing DBMS_PDB.DESCRIBE on a non-CDB in Oracle Database 12c
- You place a non-CDB in a transactionally consistent state, and then run the DBMS_PDB.DESCRIBE function to generate XML metadata about this database. While connected to the root in the CDB, you execute the CREATE PLUGGABLE DATABASE statement to create a PDB from the existing non-CDB. Finally, to convert the definitions in the PDB data dictionary to references to objects in CDB$ROOT, log in to the PDB and run the noncdb_to_pdb.sql script.
- Using Oracle Data Pump with or without transportable tablespaces
- You can define a data set on a non-CDB using Oracle Data Pump. This non-CDB can be in the current or a previous Oracle Database release, for example, Oracle Database 10g. You create an empty PDB in an existing CDB, and then use Oracle Data Pump to import the data set into the PDB.
- A Full Transportable Export using Oracle Data Pump exports all objects and data necessary to create a complete copy of the database. Oracle Data Pump exports objects using direct path unload and external tables, and then imports objects using direct path INSERT and external tables. The Full Transportable dump file contains all objects in the database, not only table-related objects. Full Transportable Export is available starting in Oracle Database 11g Release 2 (11.2.0.3) for import into Oracle Database 12c and later.
- Using Oracle GoldenGate replication
- You replicate the data from the non-CDB to a PDB. When the PDB becomes current with the non-CDB, you switch over to the PDB.
Creation of a PDB by Relocating
- To relocate a PDB from one CDB to another, use either the CREATE PLUGGABLE DATABASE ... RELOCATE statement or DBCA.
This technique has the following advantages:
- The relocation occurs with minimal downtime.
- The technique keeps the PDB being relocated open in read/write mode during the relocation, and then brings the PDB online in its new location.
- You must create a database link at the target CDB, which is the CDB that will contain the relocated PDB. Also, the source PDB must use local undo data.
Containers
Two types of containers in V$CONTAINERS:
1) The root container
- The first container created at CDB creation
- It is Mandatory
- It contain Oracle system-supplied common objects and metadata
- Oracle system-supplied common users and roles
2) Pluggable database containers (PDBs)
– A container for an application:
- Tablespaces (permanent and temporary)
- Schemas / objects / privileges
- Created / cloned / unplugged / plugged ibm
- Particular seed PDB
- PDB$SEED provides fast provisioning
– Limit of 253 PDBs in a g CDB
No comments:
Post a Comment