Oracle 12c represents a fairly dramatic departure from Oracle 11g in terms of setup and configuration of the server on personal workstations. The 12c release was released in 2013, but I had delayed its adoption due primarily to a lack of available reference texts. With that issue now rectified, it’s time to “take the plunge” with Oracle 12c. There is considerable material now available online to aid in the installation and configuration of an Oracle 12c instance; my goal in writing this article is to discuss Oracle 12c from the perspective of an undergraduate or graduate student who is installing their own copy of Oracle 12c for project work. I am working with Oracle Database 12c Enterprise Edition Release 12.1.0.1.0 – 64-bit on Windows 7.
In this article I’ll focus on Oracle’s new pluggable database architecture. In a subsequent article, I’ll discuss Oracle 12c’s server memory usage.
Server installation
The Enterprise Edition of 12c is large – the download for Windows 7 64-bit is two .zip files totalling 2.645GB in size. Once unzipped to an installation directory, one merely executes the “setup.exe” Windows installation executable and the server’s installation image is created in the directory of your choice, along with a number of Windows services: the server itself, TNS listener, batch mode listener, and so on. Aside: While the installation is relatively painless, Oracle’s uninstall of 12c is horrid. The “Oracle Universal Installer” uninstall is a mix of Windows programs firing off scripts executing in command shells, which in my case (just to try it) gave me an unintelligible error message and ended up not doing anything of substance – so that if I really did have to uninstall, I’d have to do it all manually, including updating the Windows registry.
Once the server is installed you can download and install two of the Oracle Developer clients, SQL Developer and SQL Modeler. I had been using SQL Developer 4.0.2 with Oracle 11g, but with 12c you will want to upgrade to the latest SQL Developer client – I am now using version 4.1.0. This newer release uses the Java 8 SDK and supports the new commands and security model implemented in the Oracle 12c server.
Container and pluggable databases
A very significant change from Oracle 11g is that Oracle 12c now implements a “pluggable” database architecture, also called a “multi-tenant architecture”. With Oracle 12c, a server can support multiple “container” databases, created with the CREATE DATABASE statement, and these in turn can support multiple “pluggable” databases with their own schemas and user accounts and authentication, which are created with the separate CREATE PLUGGABLE DATABASE statement. The idea is similar to the “master” database concept supported in Sybase ASE and Microsoft SQL Server, but differs in several respects, including security and authentication. The schematic below is taken from the Oracle 12c Complete Reference Manual, pp. 891:
With container database support, the security model has changed significantly from Oracle 11g. As part of the installation of an Oracle 12 Enterprise Edition server, you will have to create an administrative account for the default container database, also called a “CDB”. This default account can create additional accounts for the container database, but these CDB account names must begin with “C##_” as their prefix. One cannot create an “ordinary” table in a container database; rather, the DBA must first create one (or more) “pluggable” databases (PDBs) that are “plugged” into the CDB. Once a pluggable database is created, additional accounts can be created so that users can login to the pluggable database as would be expected with Oracle 11g. An advantage of multiple pluggable databases is that one can completely isolate the schemas and accounts for different, unrelated applications.
A CDB has two kinds of user accounts: common users and local users. A common user has the same identity in the root and all PDBs-both current and those created in the future. Common users may or may not have the same privileges in each container, however. Common users with administrative privileges can plug in, unplug, or drop PDBs.
Local users, in contrast, exist only in each PDB or in the CDB. They can have the same username but will have different credentials in each container. Having local users facilitates separation of duties across all containers within a CDB.
Oracle 12c Complete Reference, pp. 891.
One gotcha with Oracle 12c version 12.1 is that the server will not automatically start pluggable databases when the server is started; only the container database. If one tries to connect to a PDB in this case, one receives the slightly misleading message “ORA-01033 Oracle initialization or shutdown in progress”. The message is misleading because the Oracle server *has* started, and will accept connections to the container database. The issue is that the PDB the application is attempting to connect to has not been started. Starting PDB’s can be done by the administrator account when connected to the CDB using the statement
1 | ALTER PLUGGABLE DATABASE ALL OPEN; |
To have this occur automatically, one can write a database startup trigger within the container database to explicitly start the required PDB, or all of them:
2 3 4 5 6 | CREATE OR REPLACE TRIGGER open_pdbs AFTER STARTUP ON DATABASE BEGIN EXECUTE IMMEDIATE 'ALTER PLUGGABLE DATABASE ALL OPEN'; END open_pdbs; |
Beginning with version 12.2 this database startup trigger will no longer be required, as 12.2 will support syntax to permit the automatic starting of PDBs when they are created.
In doing the above it was advantageous to update my installed version of SQL Developer, from 4.0.2 to 4.1.0. While SQL Developer 4.0.2 worked well with 11g, it lacked support for some of the new commands supported by the 12c server, such as “SHOW PDBS”. Fortunately, the installation of SQL Developer is straightforward, and after being prompted for the location of the Java 8 JDK I’ve had no issues thus far with the new client. Thus far I’ve created two separate pluggable databases, one for academic examples and the other for SonarQube, to ensure that there is no contamination of the SonarQube schema after it has been installed.