Student Guide Performance

8/2/2019 Student Guide Performance

1/66

Oracle Database 11g:Performance

Student Guide

D52363GC10

Edition 1.0

October 2007

PRODUCTION


2/66

Copyright 2007, Oracle. All rights reserved.

This documentation contains proprietary information of Oracle Corporation. It is provided under a license agreement containingrestrictions on use and disclosure and is also protected by copyright law. Reverse engineering of the software is prohibited. If thisdocumentation is delivered to a U.S. Government Agency of the Department of Defense, then it is delivered with Restricted Rights andthe following legend is applicable:

Restricted Rights Legend

Use, duplication or disclosure by the Government is subject to restrictions for commercial computer software and shall be deemed to beRestricted Rights software under Federal law, as set forth in subparagraph (c)(1)(ii) of DFARS 252.227-7013, Rights in Technical Dataand Computer Software (October 1988).

This material or any portion of it may not be copied in any form or by any means without the express prior written permission of theEducation Products group of Oracle Corporation. Any other copying is a violation of copyright law and may result in civil and/or criminalpenalties.

If this documentation is delivered to a U.S. Government Agency not within the Department of Defense, then it is delivered withRestricted Rights, as defined in FAR 52.227-14, Rights in Data-General, including Alternate III (June 1987).

The information in this document is subject to change without notice. If you find any problems in the documentation, please report themin writing to Worldwide Education Services, Oracle Corporation, 500 Oracle Parkway, Box SB-6, Redwood Shores, CA 94065. OracleCorporation does not warrant that this document is error-free.

Oracle, JD Edwards, PeopleSoft, and Siebel are registered trademarks of Oracle Corporation and/or its affiliates. Other names may be

trademarks of their respective owners.

Author

Priya Vennapusa, Jean-Francois Verrier, Christine Jeal

Technical Contributors and Reviewers

This book was published using: oracletutor


3/66


Oracle Database 11g: Performance Table of Contentsi

Table of Contents

Performance New Features ............................................................................................................................1-2Chapter 1Performance New Features............................................................................................................1-2Objectives......................................................................................................................................................1-3

Foreground Statistics.....................................................................................................................................1-4Online Redefinition Enhancements...............................................................................................................1-5Minimizing Dependent Recompilations........................................................................................................1-6Locking Enhancements ...................................................... ........................................................... ................1-7Invisible Index: Overview.............................................................................................................................1-8Invisible Indexes: Examples..........................................................................................................................1-9PL/SQL and Java Native Compilation Enhancements ......................................................... .........................1-10Setting Up and Testing PL/SQL Native Compilation ......................................................... .........................1-11Recompiling the Entire Database for PL/SQL Native Compilation....................................................... ......1-12Adaptive Cursor Sharing: Overview ...................................................... ....................................................... 1-14Adaptive Cursor Sharing: Architecture ............................................................ ............................................. 1-15Adaptive Cursor Sharing Views....................................................................................................................1-17Interacting with Adaptive Cursor Sharing.....................................................................................................1-19

Temporary Tablespace Shrink.......................................................................................................................1-20DBA_TEMP_FREE_SPACE........................................................................................................................1-21 Tablespace Option for Creating Temporary Table........................................................................................1-22Easier Recovery from Loss of SPFILE ............................................................ ............................................. 1-23Summary ........................................................ ............................................................ ................................... 1-24

Using Result Caches ................................................... ............................................................ .........................2-2Chapter 2Using Result Caches ..................................................... ........................................................... ......2-2Objectives......................................................................................................................................................2-3 SQL Query Result Cache: Overview ..................................................... ....................................................... 2-4Setting Up SQL Query Result Cache..................................................... ....................................................... 2-5Managing the SQL Query Result Cache .......................................................... ............................................. 2-6Using the RESULT_CACHE Hint................................................................................................................2-7

In-Line View: Example ...................................................... ........................................................... ................2-8Using the DBMS_RESULT_CACHE Package ......................................................... ................................... 2-9Viewing SQL Query Result Cache Dictionary Information..........................................................................2-10SQL Query Result Cache: Considerations ....................................................... ............................................. 2-11OCI Client Query Cache .................................................... ........................................................... ................2-13Using Client-Side Query Cache ................................................... ........................................................... ......2-14PL/SQL Function Cache .................................................... ........................................................... ................2-15Using PL/SQL Function Cache.....................................................................................................................2-16PL/SQL Function Cache: Considerations......................................................................................................2-17Demonstration .......................................................... ............................................................ .........................2-18Summary ........................................................ ............................................................ ................................... 2-19

Oracle SecureFiles...........................................................................................................................................3-2Chapter 3Oracle SecureFiles ........................................................ ........................................................... ......3-2Objectives......................................................................................................................................................3-3 Managing Enterprise Information .......................................................... ....................................................... 3-4Problems with Existing LOB Implementation ........................................................... ................................... 3-5Oracle SecureFiles.........................................................................................................................................3-6Enabling SecureFiles Storage........................................................................................................................3-7SecureFiles Advanced Features.....................................................................................................................3-8SecureFiles Storage Options ........................................................ ........................................................... ......3-9Creating SecureFiles .......................................................... ........................................................... ................3-10Creating SecureFiles using Enterprise Manager............................................................................................3-11Altering SecureFiles ........................................................... ........................................................... ................3-12Accessing SecureFiles Metadata .................................................. ........................................................... ......3-13Migrating to SecureFiles .................................................... ........................................................... ................3-14SecureFiles Migration Example ................................................... ........................................................... ......3-15SecureFiles Monitoring ...................................................... ........................................................... ................3-16SecureFiles Demonstration............................................................................................................................3-17


4/66


Oracle Database 11g: Performance Table of Contentsii

Summary ........................................................ ............................................................ ................................... 3-18


5/66


Performance New FeaturesChapter 0 - Page 1

Performance New Features


6/66



Chapter 1Performance New Features

Performance New Features

Oracle Database 11g


7/66



Objectives

Objectives

After completing this lesson, you should be able to:

Describe enhancements to locking mechanisms

Use the enhanced PL/SQL recompilation mechanism

Create and use invisible indexes

Describe Adaptive Cursor Sharing

Manage your SPFILE


8/66



Foreground Statistics

Foreground Statistics

New columns report foreground-only statistics:

V$SYSTEM_EVENT:

TOTAL_WAITS_FG

TOTAL_TIMEOUTS_FG

TIME_WAITED_FG

AVERAGE_WAIT_FG

TIME_WAITED_MICRO_FG

V$SYSTEM_WAIT_CLASS:

TOTAL_WAITS_FG

TIME_WAITED_FG

New columns have been added to the V$SYSTEM_EVENT and the V$SYSTEM_WAIT_CLASS

views that allow you to easily identify event that are caused by foreground or background

processes.

V$SYSTEM_EVENT has five new NUMBER columns that represent the statistics from purely

foreground sessions:

TOTAL_WAITS_FG

TOTAL_TIMEOUTS_FG

TIME_WAITED_FG

AVERAGE_WAIT_FG

TIME_WAITED_MICRO_FG

V$SYSTEM_WAIT_CLASS has two new NUMBER columns that represent the statistics from

purely foreground sessions:

TOTAL_WAITS_FG

TIME_WAITED_FG


9/66



Online Redefinition Enhancements

Online Redefinition Enhancements

Online table redefinition supports the following:

Tables with materialized views and view logs

Triggers with ordering dependency

Online redefinition does not systematically invalidatedependent objects.

Oracle Database 11g supports online redefinition for tableswith materialized views and view

logs. In addition, online redefinition supports triggers with the FOLLOWS or PRECEDES clause,

which establishes an ordering dependency between the triggers.

In previous database versions, all directly and indirectly dependent views and PL/SQL packages

would be invalidated after an online redefinition or other DDL operations. These views and

PL/SQL packages would automatically be recompiled whenever they are next invoked. If there

are a lot of dependent PL/SQL packages and views, the cost of the revalidation or recompilation

can be significant.

In Oracle Database 11g, views, synonyms, and other table-dependent objects (with the exception

of triggers) that are not logically affected by the redefinition, are not invalidated. So, for example,if referenced column names and types are the same after the redefinition, then they are not

invalidated.

This optimization is transparent, that is, it is turned on by default.

Another example: If the redefinition drops a column, only those procedures and views that

reference the column are invalidated. The other dependent procedures and views remain valid.

Note that all triggers on a table being redefined are invalidated (as the redefinition can potentially

change the internal column numbers and data types), but they are automatically revalidated with

the next DML execution to the table.


10/66



Minimizing Dependent Recompilations

Minimizing Dependent Recompilations

Adding a column to a table does not invalidate itsdependent objects.

Adding a PL/SQL unit to a package does not invalidatedependent objects.

Fine-grain dependencies are tracked automatically.

No configuration is required.

Starting with Oracle Database 11g, you have access to records that describe more precise

dependency metadata. This is called fine-grain dependencies and it is on automatically.

Earlier Oracle Database releases record dependency metadatafor example, that PL/SQL unit P

depends on PL/SQL unit F, or that the V view depends on the T tablewith the precision of the

whole object. This means that dependent objects are sometimes invalidated without logical

requirement. For example, if the V view depends only on the A and B columns in the T table, and

column D is added to the T table, the validity of the V view is not logically affected.

Nevertheless, before Oracle Database, Release 11.1, the V view is invalidated by the addition of

the D column to the T table. With Oracle Database, Release 11.1, adding the D column to the Ttable does not invalidate the V view. Similarly, if procedure P depends only on elements E1 and

E2 within a package, adding the E99 element (to the end of a package to avoid changing slot

numbers or entry point numbers of existing top-level elements) to the package does not invalidate

the P procedure.

Reducing the invalidation of dependent objects in response to changes to the objects on which

they depend increases application availability, both in the development environment and during

online application upgrade.


11/66



Locking Enhancements

Locking Enhancements

DDL commands can now wait for DML locks to bereleased:

DDL_LOCK_TIMEOUT initialization parameter

NewWAIT [] clause for the LOCK TABLE

command

The following commands will no longer acquireexclusive locks (X), but shared exclusive locks (SX):

CREATE INDEX ONLINE

CREATE MATERIALIZED VIEW LOG

ALTER TABLE ENABLE CONSTRAINT NOVALIDATE

You can limit the time that DDL commands wait for DML locks before failing by setting the

DDL_LOCK_TIMEOUT parameter at the system or session level. This initialization

parameter is set by default to 0, that is NOWAIT, which ensures backward compatibility.

The range of values is 01,000,000 (in seconds).

The LOCKTABLE command has new syntax that you can use to specify the maximum

number of seconds the statement should wait to obtain a DML lock on the table. Use the

WAIT clause to indicate that the LOCK TABLE statement should wait up to the specified

number of seconds to acquire a DML lock. There is no limit on the value of the integer.

In highly concurrent environments, the requirement of acquiring an exclusive lockforexample, at the end of an online index creation and rebuildcould lead to a spike of waiting

DML operations and, therefore, a short drop and spike of system usage. While this is not an

overall problem for the database, this anomaly in system usage could trigger operating

system alarm levels. The commands listed in the slide no longer require exclusive locks.


12/66



Invisible Index: Overview

Invisible Index: Overview

VISIBLE

Index

Optimizer view point

Data view point

Use index. Do not use index.

Update index. Update index.

Update table. Update table.

OPTIMIZER_USE_INVISIBLE_INDEXES=FALSE

INVISIBLE

Index

Beginning with Oracle Database 11g, you can create invisible indexes. An invisible index is an

index that is ignored by the optimizer unless you explicitly set the

OPTIMIZER_USE_INVISIBLE_INDEXES initialization parameter to TRUE at the session or

system level. The default value for this parameter is FALSE.

Making an index invisible is an alternative to making it unusable or dropping it. Using invisible

indexes, you can do the following:

Test the removal of an index before dropping it.

Use temporary index structures for certain operations or modules of an application without

affecting the overall application.Unlike unusable indexes, an invisible index is maintained during DML statements.


13/66



Invisible Indexes: Examples

Invisible Indexes: Examples

Index is altered as not visible to the optimizer:

Optimizer does notconsider this index:

Optimizer will always consider the index:

Create an index as invisible initially:

ALTER INDEX ind1 INVISIBLE;

SELECT /*+ index(TAB1 IND1) */ COL1 FROM TAB1 WHERE ;

ALTER INDEX ind1VISIBLE;

CREATE INDEX IND1 ON TAB1(COL1) INVISIBLE;

When an index is invisible, the optimizer generates plans that do not use the index. If there is no

discernible drop in performance, you can then drop the index. You can also create an index

initially as invisible, perform testing, and then determine whether to make the index visible.

You can query the VISIBILITY column of the *_INDEXES data dictionary views to determine

whether the index is VISIBLE or INVISIBLE.

Note: For all the statements given in the slide, it is assumed that

OPTIMIZER_USE_INVISIBLE_INDEXES is set to FALSE.


14/66



PL/SQL and Java Native Compilation Enhancements

PL/SQL and Java Native CompilationEnhancements

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

1030% 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

PL/SQL Native Compilation: The Oracle executable generates native dynamic linked lists

(DLLs) 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 (JAVA_JIT_ENABLED initialization parameter)and similar to the Java Development Kit JIT (just-in-time), 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 are cost and license savings.


15/66



Setting Up and Testing PL/SQL Native Compilation

Setting Up and Testing PL/SQLNative Compilation

1. Set PLSQL_CODE_TYPE toNATIVE:

ALTER SYSTEM|ALTER SESSION |ALTER COMPILE

2. Compile your PL/SQL units (example):

3. Make sure you succeeded:

CREATE OR REPLACE PROCEDURE hello_native AS

BEGIN

DBMS_OUTPUT.PUT_LINE('Hello world.');

END hello_native;

/

ALTER PROCEDURE hello_native COMPILE PLSQL_CODE_TYPE=NATIVE;

SELECT plsql_code_type

FROM all_plsql_object_settings

WHERE name = 'HELLO_NATIVE';

To set up and test one or more program units through native compilation:

1. Set up the PLSQL_CODE_TYPE initialization parameter. This parameter determines

whether PL/SQL code is natively compiled or interpreted. The default setting is

INTERPRETED, which is recommended during development. To enable PL/SQL native

compilation, set the value ofPLSQL_CODE_TYPE to NATIVE. Make sure that the

PLSQL_OPTIMIZE_LEVEL initialization parameter is not less than 2 (which is the

default). You can set PLSQL_CODE_TYPE at the system, session, or unit level. A package

specification and its body can have different PLSQL_CODE_TYPE settings.

2. Compile one or more program units, using one of these methods:

- Use CREATE OR REPLACE to create or recompile the program unit.

- Use the various ALTERCOMPILE commands as shown in the

example in the slide.

- Run one of the SQL*Plus scripts that creates a set of Oracle-supplied packages.

- Create a database using a preconfigured initialization file with

PLSQL_CODE_TYPE=NATIVE.

3. To be sure that the process worked, query the data dictionary to see that a program unit is

compiled for native execution. You can use ALL|USER_PLSQL_OBJECT_SETTINGS

views. The PLSQL_CODE_TYPE column has a value ofNATIVE for program units that arecompiled for native execution, and INTERPRETED otherwise.


16/66



Recompiling the Entire Database for PL/SQL Native Compilation

Recompiling the Entire Database forPL/SQL Native Compilation

1. Shut down the database.

2. Set PLSQL_CODE_TYPE toNATIVE.

3. Start up the database in UPGRADE mode.

4. Execute the dbmsupgnv.sql script.

5. Shut down/start up your database in restricted mode.

6. Execute the utlrp.sql script.7. Disable restricted mode.

If you have DBA privileges, you can recompile all PL/SQL modules in an existing database to

NATIVE or INTERPRETED, using the dbmsupgnv.sql and dbmsupgin.sql scripts,

respectively. To recompile all PL/SQL modules to NATIVE, perform the following steps:

1. Shut down application services, the listener, and the database in normal or immediate mode.

The first two are used to make sure that all of the connections to the database have been

terminated.

2. Set PLSQL_CODE_TYPE to NATIVE in the initialization parameter file. The value of

PLSQL_CODE_TYPE does not affect the conversion of the PL/SQL units in these steps.

However, it does affect all subsequently compiled units and it should be explicitly set to thecompilation type that you want.

3. Start up the database in UPGRADE mode, using the UPGRADE option. It is assumed that there

are no invalid objects at this point.

4. Run the $ORACLE_HOME/rdbms/admin/dbmsupgnv.sql script as the SYS user to

update the plsql_code_type setting to NATIVE in the dictionary tables for all PL/SQL

units. This process also invalidates the units. Use TRUE with the script to exclude package

specifications; FALSE to include the package specifications. The script is guaranteed to

complete successfully or roll back all the changes. Package specifications seldom contain

executable code, so the run-time benefits of compiling to NATIVE are not measurable.


17/66



5. Shut down the database and restart in NORMAL mode. Oracle recommends that no other

sessions be connected to avoid possible problems. You can ensure this with the following

statement:

ALTER SYSTEM ENABLE RESTRICTED SESSION;

6. Run the $ORACLE_HOME/rdbms/admin/utlrp.sqlscript as the SYS user. This

script recompiles all the PL/SQL modules using a default degree of parallelism.

7. Disable the restricted session mode for the database, and then start the services that you

previously shut down. To disable restricted session mode, use the following statement:

ALTER SYSTEM DISABLE RESTRICTED SESSION;

Note: During the conversion to native compilation, TYPE specifications are not recompiled to

NATIVE because these specifications do not contain executable code.


18/66



Adaptive Cursor Sharing: Overview

Adaptive Cursor Sharing: Overview

Allows for intelligent cursor sharing only forstatements that use bind variables

Is used to compromise between cursor sharing andoptimization

Has the following benefits:

Automatically detects when different executions wouldbenefit from different execution plans

Limits the number of generated child cursors to aminimum

Automated mechanism that cannot be turned off

One plan not always appropriate for all bind values

Bind variables were designed to allow the Oracle database to share a single cursor for multiple

SQL statements to reduce the amount of shared memory used to parse SQL statements.

However, cursor sharing and SQL optimization are two conflicting goals. Writing a SQL

statement with literals provides more information for the optimizer and naturally leads to better

execution plans, while increasing memory and CPU overhead caused by excessive hard parses.

Oracle9i Database was the first attempt to introduce a compromising solution by allowing similar

SQL statements using different literal values to be shared. For statements using bind variables,

Oracle9i also introduced the concept of bind peeking. Using bind peeking, the optimizer looks at

the bind values the first time the statement is executed. It then uses these values to determine an

execution plan that will be shared by all other executions of that statement. To benefit from bindpeeking, it is assumed that cursor sharing is intended and that different invocations of the

statement are supposed to use the same execution plan. If different invocations of the statement

would significantly benefit from different execution plans, bind peeking is of no use in generating

good execution plans.

To address this issue as much as possible, Oracle Database 11g introduces Adaptive Cursor

Sharing. This feature is a more sophisticated strategy designed to not share the cursor blindly, but

generate multiple plans per SQL statement with bind variables if the benefit of using multiple

execution plans outweighs the parse time and memory usage overhead. However, because the

purpose of using bind variables is to share cursors in memory, a compromise must be found

regarding the number of child cursors that need to be generated.


19/66



Adaptive Cursor Sharing: Architecture

Adaptive Cursor Sharing: Architecture

Bind-sensitive cursor

SELECT * FROM emp WHERE sal = :1 and dept = :2

Bind-aware cursor

1Systemobservesstatementfor a while.

Initial selectivity cube

.

0.15

0.0025

:1=A & :2=B S(:1)=0.15 S(:2)=0.0025

.

0.18

0.003

:1=C & :2=D S(:1)=0.18 S(:2)=0.003

HJ

GB

HJ

Initial plan

HJ

GB

HJ

No needfor new plan

.

0.3

0.009

:1=E & :2=F S(:1)=0.3 S(:2)=0.009

HJ

GB

HJ

HJ

GB

HJ.

0.28

0.004

:1=G & :2=H S(:1)=0.28 S(:2)=0.004

HJ

GB

HJ

HJ

GB

HJ

Same selectivity cube

Second selectivity cubeNeed new plan

Merged selectivity cubes

Cubes merged

No needfor new plan

Soft

Parse

Hard

arse

P

2

34

Hard

arse

P

Using Adaptive Cursor Sharing, the following steps take place in the scenario illustrated in the

slide:

1. The cursor starts its life with a hard parse, as usual. If bind peeking takes place, and a

histogram is used to compute selectivity of the predicate containing the bind variable, then

the cursor is marked as a bind-sensitive cursor. In addition, some information is stored about

the predicate containing the bind variables, including the predicate selectivity. In the

example in the slide, the predicate selectivity that would be stored is a cube centered around

(0.15,0.0025). Because of the initial hard parse, an initial execution plan is determined using

the peeked binds. After the cursor is executed, the bind values and the execution statistics of

the cursor are stored in that cursor.

During the next execution of the statement when a new set of bind values is used, the system

performs a usual soft parse, and finds the matching cursor for execution. At the end of

execution, execution statistics are compared with the ones currently stored in the cursor. The

system then observes the pattern of the statistics over all previous runs (see V$SQL_CS_

views in the next slide) and decides whether or not to mark the cursor as bind-aware.

2. On the next soft parse of this query, if the cursor is now bind-aware, bind-aware cursor

matching is used. Suppose the selectivity of the predicate with the new set of bind values is

now (0.18,0.003). Because selectivity is used as part of bind-aware cursor matching, and

because the selectivity is within an existing cube, the statement uses the existing child

cursors execution plan to run.


20/66



3. On the next soft parse of this query, suppose that the selectivity of the predicate with the new

set of bind values is now (0.3,0.009). Because that selectivity is not within an existing cube,

no child cursor match is found. So the system does a hard parse, which generates a new child

cursor with a second execution plan in that case. In addition, the new selectivity cube is

stored as part of the new child cursor. After the new child cursor executes, the system stores

the bind values and execution statistics in the cursor.

4. On the next soft parse of this query, suppose that the selectivity of the predicate with the newset of bind values is now (0.28,0.004). Because that selectivity is not within one of the

existing cubes, the system does a hard parse. Suppose that this time, the hard parse generates

the same execution plan as the first one. Because the plan is the same as the first child cursor,

both child cursors are merged. That is, both cubes are merged into a new bigger cube, and

one of the child cursor is deleted. The next time there is a soft parse, if the selectivity falls

within the new cube, the child cursor will match.


21/66



Adaptive Cursor Sharing Views

Adaptive Cursor Sharing Views

The following views provide information about AdaptiveCursor Sharing usage:

Two new columns show whether a cursor isbind-sensitive or bind-aware.

V$SQL

Shows the selectivity cubes stored for everypredicate containing a bind variable andwhose selectivity is used in the cursor sharing

checks

V$SQL_CS_SELECTIVITY

Shows execution statistics of a cursor using

different bind setsV$SQL_CS_STATISTICS

V$SQL_CS_HISTOGRAM Shows the distribution of the execution count

across the execution history histogram

These views determine whether a query is bind-aware or not, and is 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: Indicates 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 thecursor cache that has been marked to use bind-aware cursor sharing is called bind-aware.

V$SQL_CS_HISTOGRAM: Shows the distribution of the execution count across a three-bucket

execution history histogram.

V$SQL_CS_SELECTIVITY: Shows the selectivity cubes or 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: Adaptive Cursor Sharing monitors execution of a query and collects

information about it for a while, and uses this information to decide whether to switch to using

bind-aware cursor sharing for the query. This view summarizes the information that it collects to

make this decision: for a sample of executions, it keeps track of rows processed, buffer gets, andCPU time.


22/66



The PEEKED column has the value YES if the bind set was used to build the cursor, and NO

otherwise.


23/66



Interacting with Adaptive Cursor Sharing

Interacting with Adaptive Cursor Sharing

CURSOR_SHARING:

If CURSOR_SHARING EXACT, statements containing

literals may be rewritten using bind variables.

If statements are rewritten, Adaptive Cursor Sharing mayapply to them.

SQL Plan Management (SPM):

If OPTIMIZER_CAPTURE_SQL_PLAN_BASELINES is set toTRUE, only the first generated plan is used.

As a workaround, set this parameter to FALSE, and run

your application until all plans are loaded in the cursorcache.

Manually load the cursor cache into the correspondingplan baseline.

Adaptive Cursor Sharing is independent of the CURSOR_SHARING parameter. The setting

of this parameter determines whether literals are replaced by system-generated bind

variables. If they are, Adaptive Cursor Sharing behaves just as it would if the user supplied

binds to begin with.

When using the SPM automatic plan capture, the first plan captured for a SQL statement

with bind variables is marked as the corresponding SQL plan baseline. If another plan is

found for that same SQL statement (which maybe the case with Adaptive Cursor Sharing), it

is added to the SQL statements plan history and marked for verification. It will not be used.

So even though Adaptive Cursor Sharing has come up with a new plan based on a new set of

bind values, SPM does not let it be used until the plan has been verified. Thus reverting back

to 10g behavior, only the plan generated based on the first set of bind values will be used by

all subsequent executions of the statement. One possible workaround is to run the system for

some time with automatic plan capture set to FALSE, and after the cursor cache has been

populated with all the plans a SQL statement with bind will have, load the entire plan

directly from the cursor cache into the corresponding SQL plan baseline. By doing this, all

the plans for a single SQL statement are marked as SQL baseline plans by default.


24/66



Temporary Tablespace Shrink

Temporary Tablespace Shrink

Sort segment extents are managed in memory afterbeing physically allocated.

This method can be an issue after big sorts are done.

To release physical space from your disks, you canshrink 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';

Huge sorting operations can cause temporary tablespace to grow a lot. For performance reasons,

after a sort extent is physically allocated, it is managed in memory to avoid physical deallocation

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 a 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 attempts 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 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

ALTER TABLESPACE SHRINK, the ALTER DATABASE command does not try to deallocate

sort extents after they are allocated.


25/66



DBA_TEMP_FREE_SPACE

DBA_TEMP_FREE_SPACE

Lists temporary space usage information

Central point for temporary tablespace space usage

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

FREE_SPACE

Total allocated space, in bytes, including space that iscurrently allocated and used and space that iscurrently allocated and available for reuse

ALLOCATED_SPACE

Total size of the tablespace, in bytesTABLESPACE_SIZE

Name of the tablespaceTABLESPACE_NAME

DescriptionColumn name

This dictionary view reports temporary space usage information at the tablespace level. The

information is derived from various existing views.


26/66



Tablespace Option for Creating Temporary Table

Tablespace Option for Creating Temporary Table

Specify which temporary tablespace to use for yourglobal temporary tables.

Decide a proper temporary extent size.

CREATE TEMPORARY TABLESPACE temp

TEMPFILE 'tbs_temp.dbf' SIZE 600m REUSE AUTOEXTEND ON

MAXSIZE UNLIMITEDEXTENT MANAGEMENT LOCAL UNIFORM SIZE 1m;

CREATE GLOBAL TEMPORARY TABLE temp_table (c

varchar2(10))

ON COMMIT DELETE ROWS TABLESPACE temp;

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 a proper extent size that reflects your sort-specific usage,

especially when you have several types of temporary space usage.

Note: You can find in DBA_TABLESwhich tablespace is used to store your global temporary

tables.


27/66



Easier Recovery from Loss of SPFILE

Easier Recovery from Loss of SPFILE

The FROM MEMORY clause allows the creation of current

systemwide parameter settings.

CREATE PFILE [= 'pfile_name' ]

FROM{ { SPFILE [= 'spfile_name'] } |MEMORY } ;

CREATE SPFILE [= 'spfile_name' ]

FROM{ { PFILE [= 'pfile_name' ] } |MEMORY } ;

In Oracle Database 11g, the FROM MEMORY clause creates a pfile or spfile using the

current systemwide parameter settings. In a RAC environment, the created file contains the

parameter settings from each instance.

During instance startup, all parameter settings are logged to the alert.log file. As of Oracle

Database 11g, the alert.log parameter dump text is written in valid parameter syntax. This

facilitates cutting and pasting of parameters into a separate file, and then using as a pfile for a

subsequent instance. The name of the pfile or spfile is written to the alert.log at

instance startup time. In cases when an unknown client-side pfile is used, the alert log

indicates this as well.To support this additional functionality, the COMPATIBLE initialization parameter must be set to

11.0.0.0 or higher.


28/66



Summary

Summary

In this lesson, you should have learned how to:

Describe enhancements to locking mechanisms

Use the enhanced PL/SQL recompilation mechanism

Create and use invisible indexes

Describe Adaptive Cursor Sharing

Manage your SPFILE


29/66


Using Result CachesChapter 0 - Page 1

Using Result Caches


30/66



Chapter 2Using Result Caches

Using Result Caches

Oracle Database 11g


31/66



Objectives

Objectives


Improve memory usage by caching query result sets

Use initialization parameters settings to manage theSQL Query Result Cache for your database

Use a hint to override database settings for cachingresults

Improve performance by using client-side query cache,eliminating round-trips to the server

Cache function results making them available to othersessions


32/66



SQL Query Result Cache: Overview

SQL Query Result Cache: Overview

Cache the result of a query or query block for futurereuse.

Cache is used across statements and sessions unlessit is stale.

Benefits:

Scalability

Reduction of memory usage

Good candidate statements:

Access many rows

Return few rows

SELECT

SQL

Query ResultCache

Session 1 Session 2

1

2 3SELECT

The SQL query result cache enables explicit caching of query result sets and query fragments in

database memory. A dedicated memory buffer stored in the shared pool can be used for storing

and retrieving the cached results. The query results stored in this cache become invalid when data

in the database objects being accessed by the query is modified.

Although the SQL query cache can be used for any query, good candidate statements are the ones

that need to access a very high number of rows to return only a fraction of them. This is mostly

the case for data warehousing applications.

In the graphic shown in the slide, if the first session executes a query, it retrieves the data from

the database and then caches the result in the SQL query result cache. If a second session

executes the exact same query, it retrieves the result directly from the cache instead of using thedisks.

Note:

Each node in a RAC configuration has a private result cache. Results cached on one instance

cannot be used by another instance. However, invalidations work across instances. To handle

all synchronization operations between RAC instances related to the SQL query result cache,

the special RCBG process is used on each instance.

With parallel query, entire result can be cached (in RAC it is cached on query coordinator

instance) but individual parallel query processes cannot use the cache.


33/66



Setting Up SQL Query Result Cache

Setting Up SQL Query Result Cache

Set at database level using the RESULT_CACHE_MODE

initialization parameter. Values:

MANUAL: Use the result_cache hint to specify resultsto be stored in the cache.

FORCE: All results are stored in the cache.

The query optimizer manages the result cache mechanism depending on the settings of the

RESULT_CACHE_MODE parameter in the initialization parameter file.

You can use this parameter to determine whether or not the optimizer automatically sends the

results of queries to the result cache. You can set the RESULT_CACHE_MODE parameter at the

system, session, and table level. The possible parameter values are MANUAL, and FORCE:

When set to MANUAL (the default), you must specify, by using the RESULT_CACHE hint,

that a particular result is to be stored in the cache.

When set to FORCE, all results are stored in the cache.


34/66



Managing the SQL Query Result Cache

Managing the SQL Query Result Cache

Use the following initialization parameters:

RESULT_CACHE_MAX_SIZE:

It sets the memory allocated to the result cache.

Result cache is disabled if you set the value to 0.

Default is dependent on other memory settings (0.25% ofmemory_target, or 0.5% of sga_target, or 1% ofshared_pool_size)

Cannot be greater than 75% of shared pool

RESULT_CACHE_MAX_RESULT:

Sets maximum cache memory for a single result

Defaults to 5%

RESULT_CACHE_REMOTE_EXPIRATION :

Sets the expiry time for cached results depending on remotedatabase objects

Defaults to 0

You can alter various parameter settings in the initialization parameter file to manage the SQL

query result cache of your database.

By default, the database allocates memory for the result cache in the shared pool inside the SGA.

The memory size allocated to the result cache depends on the memory size of the SGA as well as

the memory management system. You can change the memory allocated to the result cache by

setting the RESULT_CACHE_MAX_SIZE parameter. The result cache is disabled if you set its

value to 0. The value of this parameter is rounded to the largest multiple of 32 KB that is not

greater than the specified value. If the rounded value is 0, then the feature is disabled.

Use the RESULT_CACHE_MAX_RESULT parameter to specify the maximum amount of cache

memory that can be used by any single result. The default value is 5%, but you can specify any

percentage value between 1 and 100. This parameter can be implemented at the system and

session level.

Use the RESULT_CACHE_REMOTE_EXPIRATIONparameter to specify the time (in number of

minutes) for which a result that depends on remote database objects remains valid. The default

value is 0, which implies that results using remote objects should not be cached. Setting this

parameter to a nonzero value can produce stale answers. For example, if the remote table used by

a result is modified at the remote database.


35/66



Using the RESULT_CACHE Hint

Using the RESULT_CACHE Hint

EXPLAIN PLAN FOR

SELECT /*+ RESULT_CACHE */ department_id, AVG(salary)

FROM employees

GROUP BY department_id;

SELECT /*+NO_RESULT_CACHE */ department_id, AVG(salary)

FROM employees

GROUP BY department_id;

--------------------------------------------------------------

| Id | Operation | Name |Rows

--------------------------------------------------------------

| 0 | SELECT STATEMENT | | 11

| 1 | RESULT CACHE | 8fpza04gtwsfr6n595au15yj4y |

| 2 | HASH GROUP BY | | 11

| 3 | TABLE ACCESS FULL| EMPLOYEES | 107

--------------------------------------------------------------

If you want to use the query result cache and the RESULT_CACHE_MODE initialization

parameter is set to MANUAL, you must explicitly specify the RESULT_CACHE hint in your query.

This introduces the ResultCache operator into the execution plan for the query. When you

execute the query, the ResultCache operator looks up the result cache memory to check

whether the result for the query already exists in the cache. If it exists, the result is retrieved

directly out of the cache. If it does not yet exist in the cache, the query is executed, the result is

returned as output, and is also stored in the result cache memory.

If the RESULT_CACHE_MODE initialization parameter is set to FORCE, and you do not want to

store the result of a query in the result cache, you must then use the NO_RESULT_CACHE hint inyour query. For example, when the RESULT_CACHE_MODE value equals FORCE in the

initialization parameter file, and you do not want to use the result cache for the EMPLOYEES

table, then use the NO_RESULT_CACHE hint.

Note: Use of the [NO_]RESULT_CACHE hint takes precedence over the parameter settings.


36/66



In-Line View: Example

In-Line View: Example

SELECT prod_subcategory, revenue

FROM (SELECT /*+ RESULT_CACHE */ p.prod_category,

p.prod_subcategory,

sum(s.amount_sold) revenue

FROM products p, sales s

WHERE s.prod_id = p.prod_id and

s.time_id BETWEEN to_date('01-JAN-2006','dd-MON-yyyy')

andto_date('31-DEC-2006','dd-MON-yyyy')

GROUP BY ROLLUP(p.prod_category, p.prod_subcategory))

WHERE prod_category = 'Women';

In the example given in the slide, the RESULT_CACHE hint is used in the in-line view. In this

case, the following optimizations are disabled: view merging, predicate push-down, and column

projection. This is at the expense of the initial query, which might take a longer time to execute.

However, subsequent executions will be much faster because of the SQL query cache. The other

benefit in this case is that similar queries (queries using a different predicate value for

prod_category in the last WHERE clause) will also be much faster.


37/66



Using the DBMS_RESULT_CACHE Package

Using the DBMS_RESULT_CACHE Package

Use the DBMS_RESULT_CACHE package to:

Manage memory allocation for the query result cache

View the status of the cache:

Retrieve statistics on the cache memory usage:

Remove all existing results and clear cache memory:

Invalidate cached results depending on specifiedobject:

EXECUTE DBMS_RESULT_CACHE.MEMORY_REPORT;

EXECUTE DBMS_RESULT_CACHE.FLUSH;

SELECT DBMS_RESULT_CACHE.STATUS FROM DUAL;

EXEC DBMS_RESULT_CACHE.INVALIDATE('JFV','MYTAB');

The DBMS_RESULT_CACHE package provides statistics, information, and operators that enable

you to manage memory allocation for the query result cache. You can use the

DBMS_RESULT_CACHE package to perform various operations such as viewing the status of the

cache (OPEN or CLOSED), retrieving statistics on the cache memory usage, and flushing the

cache. For example, to view the memory allocation statistics, use the following SQL procedure:SQL> set serveroutput on

SQL> execute dbms_result_cache.memory_report

R e s u l t C a c h e M e m o r y R e p o r t

[Parameters]

Block Size = 1024 bytes

Maximum Cache Size = 720896 bytes (704 blocks)

Maximum Result Size = 35840 bytes (35 blocks)

[Memory]

Total Memory = 46284 bytes [0.036% of the Shared Pool]

... Fixed Memory = 10640 bytes [0.008% of the Shared Pool]

... State Object Pool = 2852 bytes [0.002% of the Shared Pool]

... Cache Memory = 32792 bytes (32 blocks) [0.025% of the Shared Pool]

....... Unused Memory = 30 blocks

....... Used Memory = 2 blocks

........... Dependencies = 1 blocks

........... Results = 1 blocks

............... SQL = 1 blocks

Note: Refer to the PL/SQL Packages and Types Reference Guide.


38/66



Viewing SQL Query Result Cache Dictionary Information

Viewing SQL Query Result Cache DictionaryInformation

The following views provide information about the queryresult cache:

Lists all the memory blocks and the

corresponding statistics

(G)V$RESULT_CACHE_MEMORY

Lists all the objects (cached resultsand dependencies) along with theirattributes

(G)V$RESULT_CACHE_OBJECTS

Lists the dependency details betweenthe cached results and dependencies

(G)V$RESULT_CACHE_DEPENDENCY

(G)V$RESULT_CACHE_STATISTICS Lists the various cache settings andmemory usage statistics

Note: See the Oracle Database Reference guide.


39/66



SQL Query Result Cache: Considerations


Result cache is disabled for queries containing:

Temporary or dictionary tables

Nondeterministic PL/SQL functions

Sequences CURRVAL andNEXTVAL

SQL functions current_date, sysdate, sys_guid forexample

DML/DDL on remote database (does not expire cachedresults)

Flashback queries can be cached.

Note: Any user-written function used in a function-based index must have been declared with the

DETERMINISTIC keyword to indicate that the function always returns the same output value

for any given set of input argument values.


40/66





Result cache does not automatically release memory:

It grows until maximum size is reached.

DBMS_RESULT_CACHE.FLUSH purges memory.

Bind variables:

Cached result is parameterized with variable values.

Cached results can only be found for the same variablevalues.

Cached result will not be built if:

Query is built on a noncurrent version of data (readconsistency enforcement)

Current session has outstanding transaction on table(s)in query

Note:

The purge works only if the cache is not in use; disable (close) the cache for flush to

succeed.

With bind variables, cached result is parameterized with variable values. Cached results can

be found only for the same variable values. That is, different values or bind variable names

cause cache miss.


41/66



OCI Client Query Cache

OCI Client Query Cache

Extends server-side query caching to client-sidememory

Ensures better performance by eliminating round-tripsto the server

Leverages client-side memory

Improves server scalability by saving server CPUresources

Result cache automatically refreshed if the result set ischanged on the server

Good for lookup tables

You can enable caching of query result sets in client memory with Oracle Call Interface (OCI)

Client Query Cache in Oracle Database 11g.

The cached result set data is transparently kept consistent with any changes done on the server

side. Applications leveraging this feature see improved performance for queries that have a cache

hit. Additionally, a query serviced by the cache avoids round trips to the server for sending the

query and fetching the results. Server CPU, which would have been consumed for processing the

query, is reduced thus improving server scalability.

Before using client-side query cache, determine whether your application will benefit from this

feature. Client-side caching is useful when you have applications that produce repeatable result

sets, small result sets, static result sets, or frequently executed queries on database objects that donot change often. Client and server result caches are autonomous; each can be enabled/disabled

independently.

Note: You can monitor the client query cache using the client_result_cache_stats$

view.


42/66



Using Client-Side Query Cache

Using Client-Side Query Cache

You can use client-side query caching by:

Setting initialization parameters:

CLIENT_RESULT_CACHE_SIZE

CLIENT_RESULT_CACHE_LAG

Using the client configuration file:

OCI_RESULT_CACHE_MAX_SIZE

OCI_RESULT_CACHE_MAX_RSET_SIZE OCI_RESULT_CACHE_MAX_RSET_ROWS

Client result cache is used depending on RESULTCACHE hints in your SQL statements

The following two parameters can be set in your initialization parameter file:

CLIENT_RESULT_CACHE_SIZE: A nonzero value enables the client result cache. This is

the maximum size of the client per-process result set cache in bytes. All OCI client processes

get this maximum size and can be overridden by the OCI_RESULT_CACHE_MAX_SIZE

parameter.

CLIENT_RESULT_CACHE_LAG: Maximum time (in milliseconds) since the last round-trip

to the server, before which the OCI client query executes a round-trip to get any database

changes related to the queries cached on client.

A client configuration file is optional and overrides the cache parameters set in the serverinitialization parameter file. Parameter values can be part of a sqlnet.ora file. When

parameter values shown in the slide are specified, OCI client caching is enabled for OCI client

processes using the configuration file. OCI_RESULT_CACHE_MAX_RSET_SIZE/ROWS

denotes the maximum size of any result set in bytes/rows in the per-process query cache. OCI

applications can use application hints to force result cache storage. The application hints can be

SQL hints:

/*+ result_cache */

/*+ no_result_cache */

Note: To use this feature, your applications must be relinked with Release 11.1 or higher client

libraries and be connected to a Release 11.1 or higher server.


43/66



PL/SQL Function Cache

PL/SQL Function Cache

Stores function results in cache, making them availableto other sessions

Uses the Query Result Cache

exec Calculate();Cachedresults

Firstquery

Subsequentqueries

exec Calculate(); exec Calculate();BEGIN

SELECT

FROM table;

END;

Starting in Oracle Database 11g, you can use the PL/SQL cross-section function result caching

mechanism. This caching mechanism provides you with a language-supported and system-

managed means for storing the results of PL/SQL functions in a System Global Area (SGA),

which is available to every session that runs your application. The caching mechanism is both

efficient and easy to use, and it relieves you of the burden of designing and developing your own

caches and cache management policies.

Oracle Database 11g provides the ability to mark a PL/SQL function to indicate that its result

should be cached to allow lookup, rather than recalculation, on the next access when the same

parameter values are called. This function result cache saves significant space and time. This is

done transparently using the input parameters as the lookup key. The cache is instancewide sothat all distinct sessions invoking the function benefit. If the result for a given set of parameters

changes, you can use constructs to invalidate the cache entry so that it will be properly

recalculated on the next access. This feature is especially useful when the function returns a value

that is calculated from data selected from schema-level tables. For such uses, the invalidation

constructs are simple and declarative. You can include syntax in the source text of a PL/SQL

function to request that its results be cached and, to ensure correctness, that the cache be purged

when any of a list of tables experiences DML. When a particular invocation of the result-cached

function is a cache hit, then the function body is not executed; instead, the cached value is

returned immediately.


44/66



Using PL/SQL Function Cache

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 NVARCHAR2RESULT_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;

In the example shown in the slide, the productName function 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 parametervalues

- 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 depend on session-specific settings.

The function should not depend on session-specific application contexts.


45/66



PL/SQL Function Cache: Considerations

PL/SQL Function Cache: Considerations

PL/SQL Function Cache cannot be used when:

The function is defined in a module that has theinvokers 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 functions return type is: BLOB, CLOB,NCLOB, REFCURSOR, object, record, or collection with one of the

preceding unsupported return types.


46/66



Demonstration

Demonstration

Click the link in the notes below for Oracle By Exampledemonstration on the following functionality:

Improving Application Performance using Result Cache

Click the following link for a demonstration on:

Improving Application Performance using Result Cache

[http://otnbeta.us.oracle.com/db11gr1/trng/obes/perform/rescache/results_cache.htm]

Note: This OBE was created under Oracle Database 11g, Beta 4.


47/66



Summary

Summary

In this lesson, you should have learned how to:

Improve memory usage by using SQL Query ResultCache to cache query result sets.

Use initialization parameters to manage the SQL QueryResult Cache for your database

Use RESULT_CACHE hint to override database settings

Improve performance by using OCI Client Query cacheto eliminate round-trips to the server.

Cache PL/SQL function results to make them availableto other sessions


48/66




49/66


Oracle SecureFilesChapter 0 - Page 1

Oracle SecureFiles


50/66



Chapter 3Oracle SecureFiles

Oracle SecureFiles

Consolidated Secure Management of Data


51/66



Objectives

Objectives


Discuss large object (LOB) improvements usingSecureFiles

Use SQL and PL/SQL APIs to access SecureFiles


52/66



Managing Enterprise Information

Managing Enterprise Information

Organizations need to efficiently and securely manage

many types of data:

Structured: Simple data, object-relational data

Semi-structured: XML documents, Word processingdocuments

Unstructured: Media, medical data, imaging

Structured Semi-structured Unstructured

Today, applications must deal with many kinds of data, broadly classified as structured, semi-

structured and unstructured data. The features of large objects (LOBs) allow you to store these

data in the database and in operating system files that are accessed from the database. The

simplicity and performance of file systems have made it attractive to store file data in file

systems, while keeping object-relational data in a relational database.


53/66



Problems with Existing LOB Implementation

Problems with Existing LOB Implementation

Limitations in LOB sizing

Considered mostly write once, read many times data

Offered low concurrency of DMLs

User-defined version control

Uniform CHUNK size:

Affecting fragmentation Upper size limit

Scalability issues with Oracle Real Application Clusters(RAC)

In Oracle8i LOB design decisions were made with the following assumptions:

LOBs instantiation was several megabytes in size.

LOBs were mostly write once and read many times type of data. Updates were rare,

therefore you could version entire chunks for all kinds of updateslarge or small.

Few batch processes were expected to stream data. An OLTP kind of workload was not

anticipated.

The amount of undo retained is user-controlled with two parameters PCTVERSION and

RETENTION. This is an additional management burden.

The CHUNK size is a static parameter under the assumption that LOB sizes are typically

uniform. There is an upper limit of 32KB on chunk size.

High concurrency writes in Oracle RAC was not anticipated.

Since their initial implementation, business requirements have dramatically changed. LOBs are

now being used in a manner similar to that of relational data, storing semi- and unstructured data

of all possible sizes. The size of the data can vary from a few kilobytes for an HTML link to

several terabytes for streaming video. Oracle File Systems that store all the file system data in

LOBs, experience OLTP-like high concurrency access. As Oracle RAC is being more widely

adopted, the scalability issues of Oracle RAC must be addressed. The existing design of LOB

space structures does not cater to these new requirements.


54/66



Oracle SecureFiles

Oracle SecureFiles

Oracle SecureFiles is a major re-architecture of the

handling of unstructured (file) data, offering entirely new:

Disk format

Variable chunk size

Network protocol

Improved input/output (I/O)

Versioning and sharing mechanisms

Redo and undo algorithms

No user-configuration

Space and memory enhancements

Oracle Database 11g completely reengineers the LOB data type as Oracle SecureFiles,

dramatically improving the performance, manageability, and ease of application development.

The new implementation also offers advanced, next-generation functionality such asintelligent compression and transparent encryption.With SecureFiles, chunks vary in size from the Oracle data block size up to 64 MB. Oracle will

make the best effort to co-locate data in physically adjacent locations on disk, thereby minimizing

internal fragmentation. By using variable chunk sizes, SecureFiles avoids versioning of large,

unnecessary blocks of LOB data.

SecureFiles also offer a new client/server network layer allowing for high-speed data transfer

between the client and server supporting significantly higher read and write performance.SecureFiles automatically determines the most efficient way for generating redo and undo,

eliminating user-defined parameters. SecureFiles automatically determines whether to generate

redo and undo for only the change, or create a new version by generating a full redo record.

SecureFiles is designed to be intelligent and self-adaptable as it maintains different in-memory

statistics that help in efficient memory and space allocation. This provides for easier

manageability due to lower number of tunable parameters, which are harder to tune with

unpredictable loads.


55/66



Enabling SecureFiles Storage

Enabling SecureFiles Storage

SecureFiles storage can be enabled using:

The DB_SECUREFILE initialization parameter with

values:

ALWAYS | FORCE | PERMITTED |NEVER| IGNORE

Enterprise Manager:

TheALTER SESSION | SYSTEMcommand:

SQL> ALTER SYSTEM SET db_securefile = 'ALWAYS';

The DB_SECUREFILE initialization parameter allows DBAs to determine the usage of

SecureFiles, where valid values are:

ALWAYS: Attempts to create all LOBs as SecureFile LOBs

FORCE: Forces all LOBs created going forward to be SecureFile LOBs

PERMITTED: Allows SecureFiles to be created (default)

NEVER: Disallows SecureFiles from being created going forward

IGNORE: Disallows SecureFiles and ignores any errors that would otherwise be caused by

forcing BasicFiles with SecureFiles optionsIfNEVER is specified, any LOBs that are specified as SecureFiles are created as BasicFiles. All

storage options and features (for example: compression, encryption, deduplication) that are

specific to SecureFiles cause an exception if used against BasicFiles. BasicFile defaults are used

for any storage options not specified. IfALWAYS is specified, all LOBs created in the system are

created as SecureFiles. The LOB must be created in an Automatic Segment Space Management

(ASSM) tablespace, else an error occurs. Any BasicFile storage options specified are ignored.

The SecureFiles defaults for all storage can be changed using the ALTERSYSTEM command as

shown above.

You can also use Enterprise Manager to set the parameter from the Server tab > Initialization

Parameters link.


56/66



SecureFiles Advanced Features

SecureFiles Advanced Features

Oracle SecureFiles offers the following advanced

capabilities:

Intelligent LOB compression

Deduplication

Transparent encryption

These capabilities leverage the security, reliability, andscalability of the database.

Oracle SecureFiles implementation also offers advanced, next-generation functionality such as

intelligent compression and transparent encryption. Compression enables you to explicitly

compress SecureFiles. SecureFiles transparently decompresses only the required set of data

blocks for random read or write access, automatically maintaining the mapping between

decompressed and compressed offsets. If the compression level is changed from MEDIUM to

HIGH, the mapping is automatically updated to reflect the new compression algorithm.

Deduplication automatically detects duplicate SecureFiles LOB data and conserves space by

storing only one copyimplementing disk storage, I/O, and redo logging savings. Deduplication

can be specified at the table level or partition level and does not span partitioned LOBs.

Deduplication requires the Advanced Compression Option.

Encrypted LOB data is now stored in place and is available for random reads and writes offering

enhanced data security. SecureFile LOBs can be encrypted only on a per-column basis (same as

Transparent Data Encryption). All partitions within a LOB column are encrypted using the same

encryption algorithm. BasicFiles data cannot be encrypted. SecureFiles supports the industry-

standard encryption algorithms: 3DES168, AES128, AES192 (default), and AES256. Encryption

is part of the Advanced Security Option.

Note: The COMPATIBLE initialization parameter must be set to 11.0.0.0.0 or later to use

SecureFiles. The BasicFile (previous LOB) format is still supported under 11.1.0.0.0

compatibility. There is no downgrade capability after 11.0.0.0.0 is set.


57/66



SecureFiles Storage Options

SecureFiles Storage Options

MAXSIZE: Specifies the maximum LOB segment size

RETENTION: Specifies the retention policy to use

MAX: Keeps old versions untilMAXSIZE is reached

MIN: Keeps old versions at least for the specified MIN

seconds

AUTO: Default

NONE: Reuse old versions as much as possible

The following storage clauses do not apply toSecureFiles:

CHUNK, PCTVERSION, FREEPOOLS, FREELISTS, andFREELIST GROUPS

The MAXSIZE is a new storage clause governing the physical storage attribute for SecureFiles.

MAXSIZE specifies the maximum segment size related to the storage clause level.

RETENTION signifies the following for SecureFiles:

MAX is used to start reclaiming old versions after segment MAXSIZE is reached.

MIN keeps old version for the specified least amount of time.

AUTO is the default setting, which is basically a tradeoff between space and time. This is

automatically determined.

NONE reuses old versions as much as possible.

Altering the RETENTION with the ALTERTABLE statement only affects space created after

statement was executed.

For SecureFiles, you no longer need to specify CHUNK, PCTVERSION, FREEPOOLS,

FREELIST, and FREELIST GROUPS. For compatibility with existing scripts, these clauses are

parsed but not interpreted.


58/66



Creating SecureFiles

Creating SecureFiles

CREATE TABLE func_spec(

id number, doc CLOB ENCRYPT USING 'AES128' )

LOB(doc) STORE AS SECUREFILE

(DEDUPLICATE LOB CACHE NOLOGGING);

CREATE TABLE test_spec (

id number, doc CLOB)

LOB(doc) STORE AS SECUREFILE(COMPRESS HIGH KEEP_DUPLICATES CACHE NOLOGGING);

CREATE TABLE design_spec (id number, doc CLOB)

LOB(doc) STORE AS SECUREFILE (ENCRYPT);

CREATE TABLE design_spec (id number,

doc CLOB ENCRYPT)

LOB(doc) STORE AS SECUREFILE;

You create SecureFiles with the SECUREFILE storage keyword in the CREATETABLE

statement with a LOB column. The LOB implementation available in prior database versions is

still supported for backward compatibility and is now referred to as BasicFiles. If you add a LOB

column to a table, you can specify whether it should be created as SecureFiles or BasicFiles. If

you do not specify the storage type, the LOB is created as BasicFiles to ensure backward

compatibility.

In the first example above, you create a table called FUNC_SPEC to store documents as

SecureFiles. Here you are specifying that you do not want duplicates stored for the LOB, that the

LOB should be cached when read, and redo should not be generated when updates are performed

to the LOB. In addition you are specifying that the documents stored in the doc column should be

encrypted using AES128 encryption algorithm. KEEP_DUPLICATE is the opposite of

DEDUPLICATE, and can be used in an ALTER statement.

In the second example above, you create a table called DESIGN_SPEC, which stores documents

as SecureFiles. For this table you have specified that duplicates may be stored, the LOBs should

be stored in compressed format and should be cached but not logged. Default compression is

MEDIUM, which is the default. The compression algorithm is implemented on the server-side,

which allows for random reads and writes to LOB data, which can be changed via ALTER

statements.

The third and fourth examples above effect the same result: Create a table with a SecureFiles

LOB column using the default AES192 encryption.


59/66



Creating SecureFiles using Enterprise Manager

Creating SecureFiles using Enterprise Manager

You can use Enterprise Manager to create SecureFiles from the Schema tab > Tables link. After

you click the Create button you can click the Advanced Attributes button against the column you

are storing as a SecureFile, to enter any SecureFiles options.

The LOB implementation available in prior versions is still supported for backward compatibility

reasons and is now referred as BasicFiles. If you add a LOB column to a table, you can specify

whether it should be created as a SecureFile or BasicFile. If you do not specify the storage type,

the LOB is created as a BasicFile to ensure backward compatibility.

You can select the following as values for the Cache option:

CACHE: Oracle places LOB pages in the buffer cache for faster access.

NOCACHE: As a parameter in the STORE AS clause, NOCACHE specifies that LOB values

are not brought into the buffer cache.

CACHE READS: LOB values are brought into the buffer cache only during read and not

during write operations.

NOCACHE is the default for both SecureFile and BasicFile LOBs.


60/66



Altering SecureFiles

Altering SecureFilesALTER TABLE t1

MODIFY LOB(a) ( KEEP_DUPLICATES );

ALTER TABLE t1

MODIFY LOB(a) ( DEDUPLICATE LOB );

ALTER TABLE t1

MODIFY PARTITION p1 LOB(a) ( DEDUPLICATE LOB );

Disable deduplication.

Enable deduplication.

Enable partition

deduplication.

ALTER TABLE t1

MODIFY LOB(a) (NOCOMPRESS );

ALTER TABLE t1

MODIFY LOB(a) (COMPRESS HIGH);ALTER TABLE t1

MODIFY PARTITION p1 LOB(a) ( COMPRESS HIGH );

Disable compression.

Enable compression.

Enable compression on SecureFileswithin a single partition.

ALTER TABLE t1 MODIFY

( a CLOB ENCRYPT USING '3DES168');

ALTER TABLE t1 MODIFY PARTITION p1

( LOB(a) ( ENCRYPT );

ALTER TABLE t1 MODIFY

( a CLOB ENCRYPT IDENTIFIED BY ghYtp);

Enable encryption using 3DES168.

Enable encryption on partition.

Enable encryption and build

the encryption key using apassword.

The DEDUPLICATE option allows you to specify that LOB data that is identical in two or more

rows in a LOB column should all share the same data blocks. The opposite of this is

KEEP_DUPLICATES. Oracle uses a secure hash index to detect duplication and combines LOBs

with identical content into a single copy, reducing storage and simplifying storage management.

The LOB keyword is optional and is for syntactic clarity only.

The COMPRESS or NOCOMPRESS keywords enable or disable LOB compression. All LOBs in

the LOB segment are altered with the new compression setting.

The ENCRYPT or DECRYPT keywords turns on or off LOB encryption using Transparent Data

Documents

Student Guide Performance