What is a Container Database?

A container database (CDB) is a database architecture concept introduced by Oracle in its Multitenant option, designed to simplify database management and improve resource utilization. In a CDB architecture, a single container database can host multiple pluggable databases (PDBs), each functioning as a separate, independent database. Overall, pluggable databases provide a modern, efficient, and flexible approach to database management, particularly suited to environments that require high levels of resource utilization, security, and operational agility.

Key Features of a Container Database

  1. Root Container (CDB$ROOT) – The root container holds common system metadata and shared components. It contains the data dictionary for the entire CDB, which includes metadata for all the PDBs.
  2. Seed Container (PDB$SEED) – This is a template for creating new PDBs. The seed container cannot be modified and serves as a starting point for creating new pluggable databases quickly.
  3. Pluggable Databases (PDBs) – PDBs are individual databases within the CDB. Each PDB has its own set of schemas, users, and data, and they operate independently of each other. PDBs share the system resources of the CDB but are otherwise isolated from one another.

Benefits of a Container Database

  1. Cloud Readiness – The architecture is well-suited for cloud environments, enabling easy migration of PDBs to and from cloud platforms. Multi-tenancy is ideal for Software-as-a-Service (SaaS) applications where multiple tenants share the same database infrastructure while maintaining isolation.
  2. Resource Efficiency – Multiple PDBs can share the same hardware resources (CPU, memory, storage), reducing the need for additional servers and improving overall resource utilization efficiently across different databases.
  3. Simplified Management – Centralized management allows administrators to perform tasks such as patching, backup, and recovery at the CDB level, which automatically applies to all PDBs. Database administrators can manage the CDB, while application administrators can manage individual PDBs.
  4. Flexibility and Agility – PDBs can be easily created, cloned, unplugged, and plugged into different CDBs, enhancing flexibility and reducing the time needed for database provisioning and management. Cloning PDBs for development and testing purposes is straightforward, allowing for faster iteration and development cycles.
  5. Cost Savings – Consolidation of multiple databases into a single CDB can lead to lower licensing costs and reduced operational expenses due to shared resources and simplified administration. Shared infrastructure and centralized management can reduce the overall cost of operations.
  6. Enhanced Security – Each PDB is isolated from others within the CDB, providing strong security boundaries between applications/tenants. Fine-grained security policies can be implemented via access control at both the CDB and PDB levels, ensuring that users and applications only have access to their specific databases.
  7. Scalability and Performance – The architecture allows for easy scaling by adding or removing PDBs as needed, making it suitable for dynamic and growing environments. Horizontal scalability is achieved in this manner. Resource management features within the CDB can ensure that PDBs receive appropriate levels of resources based on their priority and workload.
  8. Maintenance – PDBs can be upgraded or patched individually without affecting other PDBs within the same CDB. Downtime is reduced for maintenance activities, as operations can be performed on individual PDBs rather than the entire CDB.

Use Cases for Container Databases

  1. Database Consolidation – Organizations can consolidate multiple standalone databases into a single CDB, reducing hardware and management overhead.
  2. SaaS Applications – SaaS providers can host multiple customer databases within a single CDB while maintaining isolation and efficient resource usage.
  3. Development and Testing – Developers can quickly provision and manage multiple environments for different stages of the software development lifecycle, such as development, testing, and production.

Considerations

Container or pluggable database architecture offers significant benefits in terms of resource efficiency, management simplicity, and operational agility. However, it also introduces complexity, potential resource contention, and costs that need to be carefully managed. Organizations should weigh these considerations in the context of their specific needs and resources to determine if this architecture is the right fit.

  1. Complexity- The architecture introduces new concepts and components that administrators need to learn and manage. Initial setup and configuration can be complex, requiring a deep understanding of the technology. Oracle Consulting can assist with understanding and planning. A Cloud-enabled solution can be considered to off-load this complexity to the provider – one option is Oracle Cloud Infrastructure, which has several offerings in the Platform-as-a-Service (PaaS) or Infrastructure-as-a-Service models, as well as traditional Software-as-a-Service (SaaS) model.
  2. Resource Contention – While resource sharing can be efficient, it can also lead to contention if not properly managed. Misconfigured resource allocations can result in performance degradation for some PDBs.
  3. Licensing Costs – Although consolidation can reduce licensing costs, the initial investment in the Multitenant architecture and required licenses can be high. Organizations need to evaluate if the long-term savings justify the initial expenditure.
  4. Isolation Limits – While PDBs are isolated, they are not completely independent. Certain operations at the CDB level can affect all PDBs, potentially leading to unexpected downtime or issues.
  5. Backup and Recovery Complexity – While centralized backups are a benefit, they can also be a drawback if not properly managed. A failure in the CDB can impact all PDBs, making it crucial to have robust backup and recovery strategies.
  6. Vendor Lock-in – Adopting a specific multitenant architecture like Oracle’s can lead to vendor lock-in. Migrating away from this architecture in the future could be challenging and costly.
  7. Performance Overhead – The additional layer of the CDB can introduce some performance overhead. While generally manageable, it is an important consideration for performance-critical applications.

Impact on Documaker

The aforementioned benefits and drawbacks must be considered for any architecture, and Documaker is no different. However it is important to keep in mind the future direction of the Documaker system, and the business applications it supports. For example, if separate business applications have different performance, scaling, or isolation requirements, consider how the container database architecture impacts those requirements, and the downstream effect on the Documaker system.

If a Documaker Enterprise system has multiple assembly lines, then each of those assembly lines has a separate DocFactory processing layer, separate managed servers and applications deployed into a WebLogic domain, and a separate assembly line schema. In order to efficiently administer the Documaker environment, a single administration schema is used. This means that the administration and assembly line schemas must be available to the applications deployed in WebLogic, and the underlying databases supporting those schemas must be available to the applications. If independent scalability of assembly lines is required, then the design of the database must take that into account so that the individual databases (pluggable or otherwise) containing assembly line schemas can be tuned independently, or have isolation controls to silo the performance effectively.