PL/SQL applications consist – generally – of many procedures, functions and packages. A group of them can be invoked directly by applications as entry points of their user requirements while others are invoked by other packages as part of application business design.
Before Oracle 12c – in terms of database security – there was no difference between these two groups, and a granted user was able to execute any of these many units irrestrictively.
Oracle 12c introduces a new optional ACCESSIBLE BY clause that enables you to prevent package executions from outside the business logic, specifying a whitelist of predefined known elements that can only access a specific PL/SQL unit.
Until Oracle Database 12c, Oracle processes did not run as threads on UNIX and Linux systems. Every dedicated connection was represented by an operating system process and, in systems where high workload was an issue, the only way to reduce CPU and memory usage was to switch from dedicated connections to shared connections using the multithreaded server (MTS) feature.
A very common request for every DBA is to clone databases between environments. In the following post we will address the steps required to clone a pluggable database (PDB) very easily. This post would be very useful in diverse scenarios, such as creating new development or QA scenarios. Cloning environments quickly is one of the foundation ideas of any given DBaaS (database-as-a-service) project
Very often and for several diverse reasons, information should be considered as “inactive” instead of “deleted.” One of the new functionalities introduced in 12c release is the “In-Database Archiving” feature, allowing this type of functionality as a standard component of Oracle Database Information Lifecycle Management (ILM) strategy. Using this new feature you can store “deleted rows” online (inactive information) for a long time without compromising application performance.
DBMS_COMPRESSION is a package used to manage the Oracle Database table compression feature. This feature lets you compresses data by eliminating duplicate values in disk pages. As database grows in size, table compression saves resources, not only disk storage but also reduces memory use in the buffer cache. First introduced in 11g R2, this package has been evolving, and some very useful enhancements were introduced now in 12c release.