By now, many of us have downloaded, installed and either played with or implemented the latest release of the Oracle Database.\u00a0 If you haven\u2019t downloaded the latest release, I would recommend that you do so and see what it has in store for not only your organization but also the industry as a whole.\u00a0 Oracle Database 12c is going to be an industry changer and a thought provoker with new and exciting opportunities.<\/p>\n
Long before the official release of Oracle Database 12c, the initial announcement was made at Oracle Open World 2012.\u00a0 This announcement started the buzz around pluggable databases and what exactly would it consist of.\u00a0 I was at the initial announcement at Oracle Open World where the new term Pluggable Database or PDB was announced.\u00a0 Initially, I was like how is this new architecture going to be different from Microsoft SQL Server?\u00a0 As more information was released over the course of a year, the picture be came clearer on the purpose of Pluggable Database and Oracles approach to consolidation.<\/p>\n
My opinion, the main driving factor behind Pluggable Database is the opportunity for consolidation.\u00a0 Over the last decade, organizations have been seeking out opportunities to consolidate their environments.\u00a0 Many of these consolidation efforts included moving to virtualized platforms like VMWare or Oracle Virtual Machines (OVM) at the operating system layer.\u00a0 This consolidation did nothing for the databases.\u00a0 Databases were still being resource intensive although hardware platforms were shrinking.<\/p>\n
The question has to be asked, if organizations are consolidating hardware resources to virtual environments, how are the associated databases effected?\u00a0 Organizations either move the databases as is to the virtual environments or opt to a single database with multiple schemas, hence database consolidation with security concerns.\u00a0 Database consolidation with multiple schemas is one approach that can be used to shrink database footprints; however, this type of consolidation often leads to many different complex solutions to implement.<\/p>\n
If database consolidation using multiple schemas is complex, what other options are there to consolidate a database environment?\u00a0 Lets take a look at a few items that Oracle Database 12c provides for consolidation.<\/p>\n
Consolidation of databases is one of the primary reasons to use the Pluggable Database option within Oracle Database 12c.\u00a0 Pluggable Databases is really the term used to describe a type of database within Oracle Database 12c.\u00a0 The concept however is really called Multi-Tenant databases.\u00a0 When we start using multi-tenant databases, organizations can start shrinking their database footprint while shrinking their hardware footprint.<\/p>\n
When talking about multi-tenant databases, we need to look at the architecture to understand how they work.\u00a0 In order to use multi-tenant database, there has to be a primary container for the databases to plug into.\u00a0 These container databases are called Container Databases or CDB for short.\u00a0 CDBs can house 0 to N+1 multi-tenant (PDB) databases up to 252 on a single server.\u00a0 Keep in mind; the 252 number is dependent on the size server the CDB and PDBs are running on. With the ability to now run N+1 PDBs on a single server, we can address the issues with database\/schema consolidation.<\/p>\n
As I mention earlier, database\/schema consolidation can lead to complex solutions being developed when implemented.\u00a0 With the use of PDBs, Oracle has removed these complex solutions by implementing a concept called Security by Separation.\u00a0 This is simply implemented by creating N+1 PDBs and the users associated with each PDB are separate from the CDB and any additional PDBs.\u00a0 By separating users between the CDB and PDBs, an organization can achieve a greater security centric approach to consolidation of databases while providing individual databases for applications.<\/p>\n
Separating users by CDB and PDB is achieved by the definition of Common User versus Local User.\u00a0 Within a CDB\/PDB configured database, a Common User resides at the CDB level.\u00a0 Common Users can access any PDB that is housed within the CDB.\u00a0 In short, think of Common Users as super administrators within the database framework.\u00a0 Oracle has made it easy to identify common users as well.\u00a0 Common Users are required to have a prefix associated with them.\u00a0 The default prefix for a Common User is C##.<\/p>\n
Local Users are users that are local to either the CDB or PDB.\u00a0 Local users do not have access to databases outside of the database where they are created.\u00a0 There is no special prefix or requirements to create a local user.<\/p>\n
In the example below, there are two commands for creating a user.\u00a0 The create user command has changed, slightly, depending on the user that is being created.\u00a0 A common user has to have the prefix discussed before along with the CONTAINER=ALL<\/em> option. This enables the user to access all the associated containers within the CDB.\u00a0 A local user also has the CONTAINER<\/em> option.\u00a0 Instead of using the ALL<\/em> option, just need to provide the CURRENT<\/em> option.<\/p>\n Processor groups are used primarily for consolidation efforts with CDB\/PDBs, Oracle has made it easier to assign processors to database instances.\u00a0 Within Oracle Database 12c, we can now integrate the database with operating system processor groups. Processor groups allow us to bind a database instance to subset of CPUs on the server.\u00a0\u00a0 We can assign a processor group to a database instance by using the PROCESSOR_GROUP_NAME<\/em> parameter in the spfile.<\/p>\n Within a Linux environment, a subset of CPUs can be created using a control group (cgroup).\u00a0 In a Solaris environment, this is also achieved using resource pools.<\/p>\n With any new release of the Oracle Database and\/or consolidation process, a single question is always asked and answered.\u00a0 How do we backup this new environment?\u00a0 With the introduction of multi-tenant databases in Oracle Database 12c, backing up and recovering a PDB is critical to the availability of the database.\u00a0 RMAN within Oracle Database 12c has introduced a new command to backup PDBs. This provided a new syntax option for RMAN; this option is PLUGGABLE DATABASE<\/em>.<\/p>\n With the new enhancements to RMAN in Oracle Database 12c, a PDB can be recovered.\u00a0 A point-in-time (P.I.T) \u00a0recovery of a PDB can be done from RMAN.<\/p>\n These enhancements to RMAN make RMAN still the best choice to backup and restore an Oracle Database.<\/p>\n In previous releases of Oracle, the resource plan have always been available.\u00a0 Not many organizations used them in the past though.\u00a0 With the advent of consolidated databases (CDB) and multi-tenant (PDB) databases, resource plans are going to be not only needed but also an essential to resource consolidation.<\/p>\n A resource plan can be created on the CDB level and on the PDB level.\u00a0\u00a0 Creating a resource plan at the CDB level, you can allocate resources as needed to PDBs or distribute resources evenly across PDBs.<\/p>\n The features, which I have highlighted here, are only a small fraction of what was added or improved features within Oracle Database 12c.\u00a0 The features discussed have a focus around what is available and used when looking at consolidating environments within the enterprise.\u00a0 As with any new release of a product, it is good to test the new functionality before moving into production.<\/p>\n Enjoy!<\/p>\nProcessor Groups<\/h2>\n
Backup and Recovery<\/h2>\n
Resource Plans<\/h2>\n