An Oracle database server consists of many different components. These include internal memory structures, processes that execute the database server’s tasks, the physical structures that include resources for storing application data and special resources that are designed to allow for recovering data from problems ranging from incorrect entry to disk failure. All three structures of the Oracle database server running together to allow users to read and modify data are referred to as an Oracle instance. Figure 1 demonstrates the various memory, process, and physical storage components of a typical Oracle instance.

Figure 1 : Architecture of an Oracle database server

More recent versions of Oracle come with a 'Multi-tenant' option. The multitenant architecture enables an Oracle database to function as a multitenant container database (CDB). A CDB 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 12c were non-CDBs.

A container is either a PDB or the root. The root container is a collection of schemas, schema objects, and nonschema objects to which all PDBs belong.

Every CDB has the following containers:

  • Exactly one root

    The root stores Oracle-supplied metadata and common users. An example of metadata is the source code for Oracle-supplied PL/SQL packages. A common user is a database user known in every container. The root container is named CDB$ROOT.

  • 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.

  • Zero or more user-created PDBs

    A PDB is a user-created entity that 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.

The following figure shows a CDB with four containers: the root, seed, and two PDBs. Each PDB has its own dedicated application. A different PDB administrator manages each PDB. A common user exists across a CDB with a single identity. In this example, common user SYS can manage the root and every PDB. At the physical level, this CDB has a database instance and database files, just as a non-CDB does.

Figure 2 : Oracle Multi-tenant Architecture

The eG Enterprise Oracle Monitor includes extensive monitoring capabilities for Oracle databases - both CDB and non-CDB databases. A single eG agent is capable of monitoring all of the Oracle database instances being executed on a system. Monitoring of the Oracle database instances is performed non-intrusively, with administrators having the option of configuring whether the monitoring is to be performed in an agent-based or agentless manner. eG Enterprise’s 100% web-based architecture, allows geographically distributed database servers to be managed from a central manager. Administrators can view and analyze the performance of their database servers in real-time over the web. To avoid overwhelming the administrator with a ton of performance data, the eG Oracle Monitor includes a specialized model for an Oracle database server. By viewing the layer model of a database server, an administrator can quickly determine which layer(s) of the database server is causing a problem.