Using PL/SQL Function Cache

• Include the RESULT_CACHE option in the function

declaration section of a package or function definition
• Optionally include the RELIES_ON clause to specify any
tables or views on which the function results depend

CREATE OR REPLACE FUNCTION productName

(prod_id NUMBER, lang_id VARCHAR2)
RETURN NVARCHAR2
RESULT_CACHE RELIES_ON (product_descriptions)
IS
result VARCHAR2(50);
BEGIN
SELECT translated_name INTO result
FROM product_descriptions
WHERE product_id = prod_id AND language_id = lang_id;
RETURN result;
END;

16 - 30 Copyright © 2007, Oracle. All rights reserved.

Using PL/SQL Function Cache

In the example shown above, the function productName has result caching enabled through the
RESULT_CACHE option in the function declaration. In this example, the RELIES_ON clause is
used to identify the PRODUCT_DESCRIPTIONS table on which the function results depend.
Usage Notes:
• If function execution results in an unhandled exception, the exception result is not stored in
the cache
• The body of a result cached function executes:
- The first time a session on this database instance calls the function with these parameter
values.
- When the cached result for these parameter values is invalid. A cashed result becomes
invalid when any database object specified in the RELIES_ON clause of the function
definition changes.
- When the cached result for these parameter values has aged out. If the system needs
memory, it might discard the oldest cached values.
- When the function bypasses the cache.
• The function should not have any side effects
• The function should not not depend on session-specific settings
• The function should not depend on session-specific application contexts.

Oracle Database 11g: New Features for Administrators 16 - 30

 PL/SQL Function Cache Considerations

PL/SQL Function Cache cannot be used when:

• The function is defined in a module that has invoker's
rights or in an anonymous block.
• The function is a pipelined table function.
• The function has OUT or IN OUT parameters.
• The function has IN parameter of the following types:
BLOB, CLOB, NCLOB, REF CURSOR, collection, object, or
record.
• The function's return type is: BLOB, CLOB, NCLOB, REF
CURSOR, object, record or collection with one of the
preceding unsupported return types.

16 - 31 Copyright © 2007, Oracle. All rights reserved.

Oracle Database 11g: New Features for Administrators 16 - 31

 Bitmap join index for IOT

IOT A IOT B

16 - 32 Copyright © 2007, Oracle. All rights reserved.

Bitmap join index for IOT

Oracle Database 11g extends bitmap join index support to Index Organized Tables (IOTs). A join
index is an index on table T1 built for a column of a different table T2 via a join. Therefore, the
index provides access to rows of T1 based on columns of the table T2. Join indexes can be used to
avoid actual joins of tables or can reduce the volume of data to be joined by performing
restrictions in advance. Bitmap join indexes are space-efficient and can speed up queries via
bitwise operations.
As in the case of Bitmap Indexes, these IOTs have an associated Mapping Table. Since IOT rows
may change their position due to DML or index reorganization operations, the bitmap join index
cannot rely on the physical row identifiers of the IOT rows. Instead the row identifier of the
mapping table associated with the IOT will be used.

Oracle Database 11g: New Features for Administrators 16 - 32

 Automatic “Native” Compilation

• 100+% faster for pure PL/SQL or Java code

• 10% – 30% faster for typical transactions with SQL
• PL/SQL
– Just one parameter - On / Off
– No need for C compiler
– No file system DLLs
• Java
– Just one parameter – On / Off
– JIT “on the fly” compilation
– Transparent to user (asynchronous, in background)
– Code stored to avoid recompilations

16 - 33 Copyright © 2007, Oracle. All rights reserved.

Automatic “Native” Compilation

PL/SQL Native Compilation: The Oracle executable generates native dynamic linked lists
(DLL) directly from the PL/SQL source code without needing to use a third-party C compiler. In
Oracle Database 10g the DLL is stored canonically in the database catalog. In Oracle Database
11g, when it is needed, the Oracle executable loads it directly from the catalog without needing to
stage it first on the file system.
The execution speed of natively compiled PL/SQL programs will never be slower than in Oracle
Database 10g and may be improved in some cases by as much as an order of magnitude. The
PL/SQL native compilation is automatically available with Oracle Database 11g. No third-party
software (neither a C compiler nor a DLL loader) is needed.
Java Native Compilation: Enabled by default and similar to the JDK JIT, this feature compiles
Java in the database natively and transparently without the need of a C compiler.
The JIT runs as an independent session in a dedicated Oracle server process. There is at most one
compiler session per database instance; it is Oracle RAC-aware and amortized over all Java
sessions.
This feature brings two major benefits to Java in the database: increased performance of pure Java
execution in the database and ease of use as it is activated transparently, without the need of an
explicit command, when Java is executed in the database.
As this feature removes the need for a C compiler there is cost and license savings.

Oracle Database 11g: New Features for Administrators 16 - 33

 Adaptive Cursor Sharing

SELECT ……FROM..
WHERE Job = :B1

ENAME ID Job
Ename IDno Job
SMITH 6973 CLERK
SMITH 6973 CLERK
ALLEN 7499 CLERK
ALLEN 7499 CLERK
WARD 7521 CLERK 1 WARD 7521 CLERK
SCOTT 7788 CLERK KING 8739 VP
CLARK 7782 CLERK SCOTT 7788 CLERK
CLARK 7782 CLERK
Ename Empno Job

KING 8739 VP
2

16 - 34 Copyright © 2007, Oracle. All rights reserved.

Adaptive Cursor Sharing

In many cases one optimizer plan may not always be appropriate for all bind values. In Oracle
Database 11g cursor sharing has been enhanced so that the optimizer peeks at bind values during
plan selection and takes ranges of safe values into account when evaluating cursor shareability.
This enables you to leverage cursor sharing more commonly while preserving bind variable
specific plan optimizations for shared statements.
In the above example, assume that a query is retrieving information for EMPLOYEES based on a
bind variable. In case 1 if the the bind variable value at hard parse is "CLERK" five out of six
records will be selected. Therefore the execution plan will be a full table scan. In case 2 if "VP" is
the bind variable value at hard parse one out of the six records is selected and the execution plan
may be an index look-up. Therefore instead of the execution plan being reused for each value of
the bind variable the optimizer looks at the selectivity of the data and determines a different
execution plan to retrieve the data. The benefits of adaptive cursor sharing are:
• The optimizer shares the plan when binds variable values are “equivalent”.
• Plans are marked with a selectivity range. If current bind values fall within the range they use
the same plan.
• The optimizer creates a new plan if bind variable values are not equivalent.
• The optimizer generates a new plan for each selectivity range.
• The optimizer avoids expensive table scans and index searches based on selectivity criteria
thus speeding up data retrieval.

Oracle Database 11g: New Features for Administrators 16 - 34

 Adaptive Cursor Sharing Views

The following views provide information about Adaptive

Cursor Sharing usage:
V$SQL Two new columns show whether a
cursor is bind-sensitive or bind-
aware.
V$SQL_CS_HISTOGRAM Shows the distribution of the
execution count across the execution
history histogram.

V$SQL_CS_SELECTIVITY Shows the selectivity ranges stored

for every predicate containing a bind
variable and whose selectivity is used
in the cursor sharing checks.

V$SQL_CS_STATISTICS Shows execution statistics of a cursor

using different bind sets.

16 - 35 Copyright © 2007, Oracle. All rights reserved.

Adaptive Cursor Sharing Views

Determining whether a query is bind-aware, is all handled automatically, without any user input.
However, information about what is going on is exposed through V$ views so that the DBA can
diagnose any problems. Two new columns have been added to V$SQL:
• IS_BIND_SENSITIVE: Indicate if a cursor is bind sensitive, value YES | NO. A query for
which the optimizer peeked at bind variable values when computing predicate selectivities
and where a change in a bind variable value may lead to a different plan is called bind-
sensitive.
• IS_BIND_AWARE :Indicates if a cursor is bind aware, value YES | NO. A cursor in the
cursor cache that has been marked to use extended cursor sharing is called bind-aware.
V$SQL_CS_HISTOGRAM: Shows the distribution of the execution count across the three-bucket
execution history histogram.
V$SQL_CS_SELECTIVITY: Shows the selectivity ranges stored in a cursor for every predicate
containing a bind variable and whose selectivity is used in the cursor sharing checks. It contains
the text of the predicates and the selectivity range low and high values.
V$SQL_CS_STATISTICS:You use this view to find out whether executing the cursor with a
different bind set, other than the ones used to build it, hinders performance. This view is populated
with the information stored for the peeked bind set, and contains information for other bind sets
only when running under diagnostic mode. The column PEEKED contains values YES if the bind
set was used to build the cursor, and NO otherwise.

Oracle Database 11g: New Features for Administrators 16 - 35

 Temporary Tablespace Shrink

• Sort segment extents are managed in memory once

physically allocated.
• This method can be an issue after big sorts are done.
• To release physical space from your disks, you can
shrink temporary tablespaces:
– Locally-managed temporary tablespaces
– Online operation
CREATE TEMPORARY TABLESPACE temp
TEMPFILE 'tbs_temp.dbf' SIZE 600m REUSE AUTOEXTEND ON
MAXSIZE UNLIMITED
EXTENT MANAGEMENT LOCAL UNIFORM SIZE 1m;

ALTER TABLESPACE temp SHRINK SPACE [KEEP 200m];

ALTER TABLESPACE temp SHRINK TEMPFILE 'tbs_temp.dbf';

16 - 36 Copyright © 2007, Oracle. All rights reserved.

Temporary Tablespace Shrink

Huge sorting operations can cause temporary tablespace to grow a lot. For performance reasons,
once a sort extent is physically allocated, it is then managed in memory to avoid physical de-
allocation later. As a result, you can end up with a huge tempfile that stays on disk until it is
dropped. One possible workaround is to create a new temporary tablespace with smaller size, set
this new tablespace as default temporary tablespace for users, and then drop the old tablespace.
However, there is disadvantage that the procedure requires no active sort operations happening at
the time of dropping old temporary tablespace.
Starting with Oracle Database 11g Release 1, you can use the ALTER TABLESPACE SHRINK
SPACE command to shrink a temporary tablespace, or you can use the ALTER TABLESPACE
SHRINK TEMPFILE command to shrink one tempfile. For both commands, you can specify the
optional KEEP clause that defines the lower bound that the tablespace/tempfile can be shrunk to.
If you omit the KEEP clause, then the database will attempt to shrink the tablespace/tempfile as
much as possible (total space of all currently used extents) as long as other storage attributes are
satisfied. This operation is done online. However, if some currently used extents are allocated
above the the shrink estimation, the system waits until they are released to finish the shrink
operation.
Note: The ALTER DATABASE TEMPFILE RESIZE command generally fails with ORA-03297
because the tempfile contains used data beyond requested RESIZE value. As opposed to the
ALTER TABLESPACE SHRINK, the ALTER DATABASE command does not try to de-allocate
sort extents once they are allocated.
Oracle Database 11g: New Features for Administrators 16 - 36
 DBA_TEMP_FREE_SPACE

• Lists temporary space usage information.

• Central point for temporary tablespace space usage

Column name Description

TABLESPACE_NAME Name of the tablespace

TABLESPACE_SIZE Total size of the tablespace, in bytes

ALLOCATED_SPACE Total allocated space, in bytes, including space that is currently

allocated and used and space that is currently allocated and
available for reuse
FREE_SPACE Total free space available, in bytes, including space that is
currently allocated and available for reuse and space that is
currently unallocated

16 - 37 Copyright © 2007, Oracle. All rights reserved.

DBA_TEMP_FREE_SPACE
This dictionary view reports temporary space usage information at tablespace level. The
information is derived from various existing views.

Oracle Database 11g: New Features for Administrators 16 - 37

 Tablespace Option for Creating Temporary Table

• Specify which temporary tablespace to use for your

global temporary tables.
• Decide proper temporary extent size.

CREATE TEMPORARY TABLESPACE temp

TEMPFILE 'tbs_temp.dbf' SIZE 600m REUSE AUTOEXTEND ON
MAXSIZE UNLIMITED
EXTENT MANAGEMENT LOCAL UNIFORM SIZE 1m;

CREATE GLOBAL TEMPORARY TABLE temp_table (c varchar2(10))

ON COMMIT DELETE ROWS TABLESPACE temp;

16 - 38 Copyright © 2007, Oracle. All rights reserved.

Tablespace Option for Creating Temporary Table

Starting with Oracle Database 11g Release 1, it becomes possible to specify a TABLESPACE
clause when you create a global temporary table. If no tablespace is specified, the global
temporary table is created in your default temporary tablespace. In addition, indexes created on
the temporary table are also created in the same temporary tablespace as the temporary table.
This possibility allows you to decide proper extent size that reflects your sort-specific usage,
especially when you have several types of temporary space usage.

Oracle Database 11g: New Features for Administrators 16 - 38

 Real-Time Query and Physical Standby Databases

Redo Redo
transport apply

Redo
Primary stream Physical standby Queries
database database

16 - 39 Copyright © 2007, Oracle. All rights reserved.

Real-Time Query and Physical Standby Databases

In previous database releases, when you opened the physical standby database for read-only, redo
application stopped. Oracle Database 11g allows you to use a physical standby database for
queries while redo is applied to the physical standby database. This enables you to use a physical
standby database for disaster recovery and to offload work from the primary database during
normal operation.
In addition, this feature provides a loosely coupled read-write clustering mechanism for OLTP
workloads when configured as follows:
• Primary database: Recipient of all update traffic
• Several readable standby databases: Used to distribute the query workload
The physical standby database can be opened read-only only if all the files have been recovered
up to the same system change number (SCN), otherwise the open will fail.

Oracle Database 11g: New Features for Administrators 16 - 39

 Summary

In this lesson, you should have learned how to:

• Describe and use the enhanced online table
redefinition and materialized views
• Describe finer grained dependency management
• Use enhanced DDL
– Apply the improved table lock mechanism
– Create and use invisible indexes
• Use PL/SQL result cache
• Create Bitmap join indexes for IOT
• Describe System Managed Domain Indexes
• Use automatic Native PL/SQL and Java Compilation
• Use Client query Cache

16 - 40 Copyright © 2007, Oracle. All rights reserved.

Oracle Database 11g: New Features for Administrators 16 - 40

 Practice 16 Overview

• Perform online redefinition on MV

• Use Client result cache
• Use PL/SQL result cache
• Create bitmap join index on IOT

16 - 41 Copyright © 2007, Oracle. All rights reserved.

Oracle Database 11g: New Features for Administrators 16 - 41