Oracle 12c New Features - Expert Consolidation in Oracle Database 12c - page 54

As requested the data has been compressed with basic compression.
Automatic storage tiering is the second option you have in ADO. It works slightly differently as it is not based on
access but rather on the amount of free space on the tablespace. The ILM engine reviews a tablespace and compares
the free space with what it finds in dba_ilmparameters . If the tablespace on which the segment is stored falls below
the free space threshold a job will be started moving the data from the higher tier storage to the storage defined in the
ILM policy. An example for an ILM policy to change the storage tier is shown here:
SQL> alter table t1
2 ilm add policy
3 tier to ARCH segment;
Table altered.
During the next maintenance window—the time when the ILM policies are evaluated—jobs will be started to
move the partitions to the low cost storage. As with the compression you can see the results of the operation in
dba_ilmresults .
Infrastructure Changes
Changes to the way the Oracle database interacts or touches the infrastructure it executes on are of particular interest
to the consolidation project. Some features in the 12c release are very relevant, and have been moved into their
respective chapters. One of the best features added has been semi-officially introduced with 11.2.0.2 as “clonedb.” But
there are others you should know about.
Database Resident Connection Pool Exposed to Middle Tier
The usefulness of exposing the connection pool to the middle tier is not immediately visible to everyone, including
the author when he first read about it. Why would anyone create a (Database Resident) connection pool for
another connection pool (in the middle tier)? Before explaining the finer details of the feature lets recap on what
the Database Resident Connection Pool (DRCP) was intended for. When it was introduced in Oracle 11.2, DRCP
allowed programming languages without support for connection pooling in the middle-tier to reduce the cost of
establishing connections. At the time DRCP was introduced the popular programming language was PHP, a HyperText
Preprocessor. Perl Common Gateway Interface scripts using the popular DBI module could equally have benefitted
from the feature but Perl's importance as a web development language at the time was diminishing quickly.
In short, all (web) applications that are not really modular do not use connection pools, and instead establish a
session to the Oracle database as the first thing in their code. These applications were ideal candidates for the DRCP.
The idea was to create a connection pool in the database, rather than in the middle tier where such a feature did not
exist. The DRCP is somewhere in between a shared server and a dedicated server, but with a lot less code path to go
through than MTS. More importantly it is a database feature, unlike the traditional connection pool which exists on
the middleware exclusively.
With Oracle 12c the DRCP has been opened up for Java Database Connectivity JDBC. The immediate question
that comes to mind is:
JDBC allows you to use connection pooling already in form of the Universal Connection Pool
(UCP). Why then should you add a connection pool for the connection pool?
The answer is: scalability! Many connection pools are (inappropriately) designed to use a minimum number of
connections set to a value less than the maximum pool size. This is a bad idea since sudden plan changes can cause
real havoc or even downtime with the application. Imagine a configuration when 10 middle-tier servers establish 10
sessions each, initially. The increment is another 10 sessions until the maximum size of 100 sessions per pool