Pluggable Database

Around five years of development went into the new release of the Oracle database, and the current version, Oracle 12c [1], has been available for download from the Oracle Technology Network (OTN) [2] since June. The software was actually intended for earlier release, but more tests were required to make sure it was as bug-free as possible before it reached the markets.

The new release is available for Linux and Solaris, and versions for Windows, IBM AIX, and HPUX will follow shortly. A version is also planned for BS2000 platforms. The manufacturer intends to provide special upgrade wizards and will even support a direct step up from the legacy releases 8i and 9i to 12c. The condition for this is that the database must have the current patch level.

Beyond the known licensing models, Oracle also will offer a private cloud service with flexible prices. Whether this model will be adopted by customers, and how it will be received, is an interesting question: Many enterprise customers are rather skeptical about public cloud models and were so before the recent PRISM scares. In the future, however, along with the public cloud, there will be easy and flexible ways to consolidate the database landscape in-house with the new multitenant architecture [3]. The new multitenant architecture is thus a precondition for "Database as a Service."

New Paradigm

One of the most important new features is the multitenant capability [4] of the new architecture. This feature is designed to facilitate cloud computing at the enterprise level, whether in a public or private cloud. Additionally, it can reduce hardware resources and administrative overhead.

This architecture will primarily benefit those customers with numerous individual instances in use. Up to 253 databases can then be packaged into an instance. Thus, hardware capabilities such as memory, CPU capacity, and storage can be shared and are more efficient. This approach also facilitates the process of applying patches, upgrading, and backup and recovery (Figure 1).

Figure 1: The new Oracle release makes upgrading and patching the database easier for the administrator.

The pluggable database (PDB) concept sees a fundamental change to the previous Oracle paradigm, according to which an instance (or multiple instances of a cluster) could only open precisely one database. This limitation changes with the introduction of the pluggable database; an instance now can open and operate multiple databases. Oracle is thus targeting maximum database consolidation without the need for virtualization. In our opinion, the new architecture can make host-level virtualization superfluous in large environments.

To achieve this, Oracle has extended its database by adding another layer; in the future, there will be container databases (CDBs) that house up to 253 PDBs (Figure 2). To the user, these appear to be normal databases, and they behave that way, too. Modification of the application code is not necessary except in isolated cases because the namespace of each database is individual.

Figure 2: A container database houses several pluggable databases.

The CDB is itself an instance with associated memory and processes (e.g., the LGWR log writer, the DBWn database writer, the CKPT checkpoint, etc.). The PDBs, on the other hand, have no separate background processes; processing is done by the background processes of the container database.

The data dictionary, with the metadata, stores information such as users and permissions, information about tables, indexes, views, and all other database objects – as in earlier releases. The dictionary is saved in the CDB in a multitenant architecture. Internally, PDBs only store pointers to the corresponding regions in the container database. The container database defines the data dictionary objects. The actual data of the data dictionary, such as the rows in the OBJ$ table, are stored in the pluggable databases so it can be included when copying the database.

More Efficient Through Containers

This concept allows the separation of metadata (i.e., the description of the data dictionary) from the actual data and makes it possible to transport individual PDBs as required. The PDBs can be either installed within one container or distributed between multiple containers. Another benefit is that upgrades will be faster as of version 12c: Instead of upgrading the data dictionary with catproc, admins will just need to "plug" the PDB into a version 12c+1 container database to upgrade to the next version.

As described previously, individual PDBs do not have their own memory areas or processes. This design results in better utilization of resources because significantly fewer processes compete for the available CPU cores  – and thus fewer context switches are needed. Far more memory is available for the buffer cache or shared pool because the minimum 350MB of SGA applies to the operation of an instance of the CDB and not for the PDBs.

Some simple math can help clarify this concept: For example, 10 databases in version 11g need at least 10x350MB, or around 3.5GB, of memory to be able to start each instance. The buffer pool and the shared pool have very little space in which to fulfill their functions. As a result, at least 6x10 background processes are competing for the CPU. If you now use the concept of pluggable databases and allow the 10 databases to run as PDBs in a CDB, you have just six processes and need just 350MB of memory to operate the CDB. The extra 3.15GB, compared with the old architecture, can be used in the new concept for the buffer cache or shared pool.

Resource Management

Distribution of resources between different databases is handled by the Oracle Resource Manager [5], which is enabled by default. Also by default, each database has a fair share of the resources: Two databases each receive one half, three each have one third of the resources, four each a quarter, and so on. This distribution pattern can be adjusted if required, and these adjustments can be made within the PDBs. For example, guaranteed shares of the CPU or CPU load limits are configurable; however, a limitation of the I/O load is only possible with Oracle's own Exadata hardware.

The physical storage structure of the databases in storage has not changed to any great extent; thus, the control files, redo logs, flashback logs, and the UNDO tablespace are still at container level. The SYSTEM and SYSAUX tablespace in the database container provides the global data dictionary; the same tablespaces in the individual PDBs, however, only store the actual data dictionary payload. The temporary tablespace – which is comparable to the swap space at operating system level – can be created globally for all databases or locally. User tablespaces can be created at all levels for data storage.

Because the namespace for each database is individual, access across PDB boundaries is not possible except through database links – even if the data is in the same CDB. When using this technology, you should generally not store user objects in the container database, because they would have to be transferred manually in case of a migration. Oracle plans to disable this option completely some time in the future.

In terms of storage space management, it is possible to limit the maximum assignable space per database so that management by less experienced DBAs is possible within these constraints.