IT Operations Management (ITOM)

The smart way to standardize Oracle 12c Pluggable Databases

The smart way to standardize Oracle 12c Pluggable Databases


By Isaiah Reardon, Oracle Subject Matter Expert, HP Database and Middleware Automation R&D


In the lead up to Oracle Open World 2013 on Sept. 22, DBAs are now getting their hands on Oracle 12c and its “Multitenant Architecture”. As you’ve likely read, this allows you to run multiple databases in a single 12c instance through the use of Pluggable Databases (PDBs).


To help DBAs and your teams as you learn how to make the most of this new architecture and its unique SQL syntax function, HP Database and Middleware Automation now has a new automated workflow that makes it easy to manage PDB.


Here is a quick walkthrough of how simply you can provision a PDB in HP Database and Middleware Automation (DMA).


Workflows (and why they’re smarter than scripts)

DMA automates processes through pre-set workflows, which execute series of sequential steps necessary for database provisioning, database patching or database upgrading. Figure 1 shows the workflow for provisioning a PDB, which includes gathering parameters, validating, building, verifying and performing cleanup where necessary.


DMA PDB Workflow.png


Fig. 1: HP DMA screenshot of Oracle Pluggable Database workflow


The validation and verification steps are two of the primary benefits of using a Database Automation workflow instead of a script, which typically requires a lot of manual pre-validation of parameters as well as post-provisioning verification. Just one example is that in 12c, PDBs must target what Oracle calls a Container Database (CDB). So the first thing that occurs when you run this workflow is a query to that it is, in fact, a CDB.


There are many such automated validation queries in all DMA workflows, such as making sure the database you’re trying to provision doesn’t already exist. All of these queries provide you with the assurance that everything is validated before building or patching a database. The workflows gather the steps, validate the parameters as set by the DBA and the environment you want to run against, execute the build or patch, and then finally verify to make sure everything is kosher.


Pre-setting parameters and policies

To run this workflow, you will work within the Deployments page to select the target location that you want to run against (Fig 2). You also choose from a number of parameters, including Admin name, Password and Pluggable DB Name (if it’s a new instance—if it is a clone of an existing instance, you select which PDB you will clone).


DMA PDB Deployment Targets.png


Fig 2. Viewing targets for Pluggable Database in HP DMA


Another big plus to provisioning databases within DMA is that parameters can be preset with standardized information and locked down by a DBA prior to anyone provisioning a PDB. Any time you build a pluggable database, it’s going to have the same Admin User and the same password across your enterprise, so you don’t have to guess what password DBA Joe decided to set it to.


The other option is to create a policy, with pre-set values and attributes that can establish company-wide standards in your enterprise IT environment——what the admin name will be, for example, and the password, or max size for PDBs. Policies allow you to quickly and automatically update standards for database provisioning across your enterprise.


Monitoring progress on the Console and History pages

After clicking “Run Workflow”, you can monitor the progress of the provisioning workflow (and others) on the Console page (Figure 3). In this case, it is printing out debug details, although you can choose to hide those details.

 DMA PDB Console.png


Fig. 3: HP DMA Console page for Build Pluggable Database


The History page (Figure 4) provides a complete searchable audit trail of all workflows that have been run, including when it was built, by whom and the output of each step in the workflow to see how it ran in the event that something did fail. It offers a nice sanity check to confirm exactly what was executed, and it’s a fast way to pull up details about any Pluggable Database that was provisioned, for example.

 DMA PDB History.png

Fig. 4: HP DMA History page for Pluggable Databases



Making the jump to 12c, and beyond

For all the opportunities that Oracle’s new Multitenant Architecture offers, 12c presents a big learning curve, with all the potential inconsistencies and bugs that crop up when first discovering a new way of working. As a DBA, DMA workflows lets you avoid having to memorize all the different ways you can bend and twist a PDB—including the different set of commands for cloning from a different database, or provisioning from an XML file. Instead, you just use the UI and some runtime parameters and you can easily build the databases you need.


HP DMA also ensures that once a database is provisioned, you can automate patching of the inventory of PDBs and other databases. It automates a lot of hands-on work, but also coordinates ongoing lifecycle management.


Learn more

Getting the most out of Oracle 12c is just one of the benefits of HP Database and Middleware Automation. Find out all the details about how it provides end-to-end lifecycle management, including the automation of patching and provisioning, compliance and migration:


> Visit the HP Database and Middleware Automation product page





  • infrastructure management
0 Kudos
About the Author


This account is for guest bloggers. The blog post will identify the blogger.