Using available documentation for Oracle 12c and one other database of your choi

Question

Using available documentation for Oracle 12c and one other database of your choice, research and provide a unique comparison of the architecture (physical, logical, processes, memory, application, network and other areas as appropriate). Be sure to create summary presentation tables and diagrams to enhance your descriptions. The document should be based on referenced readings using your own words. In your description be sure to discuss your reasons for selecting the database you used for comparison.

Your document should be strongly technical in nature (i.e., it should not read like a Vendor’s product brochure) However; It should be well-organized, well-written and provide all references used for your research. There should be minimal spelling and grammatical errors. Your document should be double-spaced, using a 12-point font of your choice. It is envisioned the document will be between 8 and 20 pages in length. A well organized, efficiently written paper that covers the topics is recommended.

Assigned Readings:

http://docs.oracle.com/database/121/CNCPT/process.htm#CNCPT9847

http://docs.oracle.com/database/121/CNCPT/dist_pro.htm#CNCPT1266

http://www.oracle.com/webfolder/technetwork/tutorials/obe/db/12c/r1/poster/OUTPUT_poster/poster.html#

http://www.aosabook.org/en/nosql.html

Comparing the Use of Amazon DynamoDB and Apache HBase for NoSQL - By: Wangechi Doble - September 2014

Explanation / Answer

magine a situation where you have to create two different schemas in the same databases; but both with the same name. A typical example is in the case of Peoplesoft applications which have a specific schema name - SYSADM, that can't be changed. So if you want to install two Peoplesoft applications in the same database, you will soon discover that it's not possible since you can't have two schemas named SYSADM in the same database. So, what are your choices?

Well, you could create two different databases. In fact, prior to Oracle Database 12c that was your only choice. But with two different databases comes two different sets of overheads - two Oracle instances (the memory areas such as SGA and the processes such as pmon and smon) which consume memory and CPU cycles in the host. The more databases you have, the more the CPU and memory usage - all because you want to create multiple schemas in the same name.

Not any more, in the multi-tenancy option in Oracle Database 12c. Instead of creating a physical database for each SYSADM schema you want to create, you can a virtual database for each schema. Each virtual database behaves like an independent database; but runs on the top of a real, physical database which may be hidden from the end users. These virtual databases are called Containers. The physical database that houses these containers, is in effect a database of containers, and is known as a Container Database (CDB). You can pull out (or "unplug") a container from one CDB and place it (or, "plug" it) into another CDB. This is why a container is also known as a Pluggable Database (PDB). For all practical purposes from the perspective of the clients, the PDBs are just regular databases.

Please note a very important point: It is NOT necessary that the database be created as a CDB with PDBs inside it. You can also create a database exactly how it was (non- CDB) in the prior versions. The multi-tenancy option to the Oracle Database 12c is required to create s. That is an extra cost option; but there is no cost to create exactly one PDB inside a CDB. Later in this article you will see how to create a database as a PDB. To find out if the database has been created as a CDB or not, just check the column called CDB in the view V$DATABASE.

What is a Container Database

So, what is the big advantage in this setup, you may ask? Couldn't we just have created multiple plain vanilla databases instead of multiple PDBs? Yes, we could have; but then each of these plain "vanilla" databases would have has its own instance (processes and memory) overhead. PDBs do not have an instance associated with them, eliminating this overhead. Let's examine the setup with an example. Suppose you have a CDB (container database - the real database that houses other PDBs) called CONA which has a PDB calledPDB1. If you check the Oracle instance, you will see that there is only one - that of the CDB. Let's check the ORACLE_SID first:

That's it. There is just one SID; not one for each PDB. Next, let's check for the processes, specifically the very important one known as "pmon":

As you can see, the only instance running is CONA (the CDB) beside,of course, the ASM instance. There is no instance for the PDB namedPDB1. You can create as many of these PDBs on this CDB called CONA; there will be no additional instance. PDBs are simply hosted on the CDBs. So in effect these PDBs are like virtual machines running on a physical machine (akin to the CDB) in a virtual machine context.

Since the CDB is the only real database, all the physical database components such as the Automatic Diagnostic Repository (ADR) is associated with it. Let's check the ADR using the ADRCI command line utility:

As you see from the output, there is only one ADR home - that for CONA (the CDB). There is no separate ADR for the PDBs.

You can check the containers (or PDBs) created in a database in a view named V$PDBS, which is brand new in Oracle Database 12c.

Note how the DBIDs are also different for each PDB. There are two striking oddities in this output:

There are new built-in functions to identify PDBs from their details without querying the V$PDBS view. Here is an example how to identify the container ID from the name:

And, here is how you can get the container ID from the DBID:

Operating on Specific PDBs

The next big question you may have is considering the unusual nature of the PDBs (they are virtual inside a real database) how you can operate on a specific PDB. There are several approaches. Let's examine them one by one.

Now all commands in this session will be executed in the context of the PDB called PDB1. For instance suppose you want to shutdown the PDB named PDB1, you would issue:

Only the PDB called PDB1 will be shut down; other PDBs will not be affected.

The service "pdb1" actually points to the PDB called PDB1. It's very important to note that that this is not a service name in initialization parameter of the database, as you can see from the service_names parameter of the database.

You can place that service name in an entry in the TNSNAMES.ORA file:

Now you can connect to PDB1 using the connect string:

And, then you can connect as usual without giving a connect string:

I prefer this last approach because it simulates a database connection prior to introduction of the PDB. If you connect to a specific PDB the majority of the time, all you have to do is to set this variable in the shell initialization file (e.g. .profile in case of bourne shell) of the user so that the variable is automatically set when you log in. If you need to know which PDB you are connected right now in SQL*Plus, just use the following command: To show which container (or, the PDB) you are connected to:

Related Questions

Navigate

• Browse (All)
• Browse U
• Subjects

Integrity-first tutoring: explanations and feedback only — we do not complete graded work. Learn more.