Oracle 12c introduced a new utility which replaces the need to run post installation SQL scripts after a database patch is applied.
This new utility is called “Datapatch” and it is shipped with 12c binaries as a component of OPatch distribution.
“Datapatch” is very useful in multitenant environments where multiple PDBs (Pluggable Databases) must be patched together.
Oracle Database 12c provides a set of security features that can be used to manage several and diverse topics such as authentication, privileges and roles, application security, encryption, network traffic, and auditing. This blog post will address the new READ and READ ANY TABLE object privileges introduced in Oracle database 12c.
JSON support was introduced in Oracle Database Release 2 (12.1.0.2) allowing you to store and retrieve data between the applications and the database engine. This post expands upon a previous post about basic JSON support by detailing the performance effects of different JSON notations. In production scenarios, large JSON documents or large numbers of JSON documents can challenge a database’s ability to perform.
With Database 12c, Oracle has provided a handy feature, Queryable Patch Inventory, which allows for a SQL and PL/SQL interface to the product patch inventory. Previously, this information was only accessible through the OS command: OPatch. Now, with the DBMS_QOPATCH package, you can monitor distributed Opatch repositories from a central location.
OPatch now supports inventory in XML format and inventory data is stored in database tables. So as data is stored in database tables, you can view installed database patches performing interactive queries using SQL*Plus. Oracle database 12c provides DBMS_QOPATCH package to manage this interface. It is installed by default during instance creation or by executing “dbmsqopi.sql” SQL script.
Written by Daniel Vukasovich on January 10, 2015
In 12c, Oracle has improved the DBMS_SCHEDULER package functionality adding some interesting and useful new features. One of this new features is the capability to run external scripts as part of our job action or even better the capability to write our own custom scripts and run them by invoking the shell interpreter (in case of unix environments) or the command prompt (in windows environments). This custom script can be directly writed inside the job definition.
