View
219
Download
0
Category
Preview:
Citation preview
8/2/2019 Student Guide Performance
1/66
Oracle Database 11g:Performance
Student Guide
D52363GC10
Edition 1.0
October 2007
PRODUCTION
8/2/2019 Student Guide Performance
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
8/2/2019 Student Guide Performance
3/66
Copyright 2007, Oracle. All rights reserved.
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
8/2/2019 Student Guide Performance
4/66
Copyright 2007, Oracle. All rights reserved.
Oracle Database 11g: Performance Table of Contentsii
Summary ........................................................ ............................................................ ................................... 3-18
8/2/2019 Student Guide Performance
5/66
Copyright 2007, Oracle. All rights reserved.
Performance New FeaturesChapter 0 - Page 1
Performance New Features
8/2/2019 Student Guide Performance
6/66
Copyright 2007, Oracle. All rights reserved.
Performance New FeaturesChapter 1 - Page 2
Chapter 1Performance New Features
Performance New Features
Oracle Database 11g
8/2/2019 Student Guide Performance
7/66
Copyright 2007, Oracle. All rights reserved.
Performance New FeaturesChapter 1 - Page 3
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/2/2019 Student Guide Performance
8/66
Copyright 2007, Oracle. All rights reserved.
Performance New FeaturesChapter 1 - Page 4
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
8/2/2019 Student Guide Performance
9/66
Copyright 2007, Oracle. All rights reserved.
Performance New FeaturesChapter 1 - Page 5
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.
8/2/2019 Student Guide Performance
10/66
Copyright 2007, Oracle. All rights reserved.
Performance New FeaturesChapter 1 - Page 6
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.
8/2/2019 Student Guide Performance
11/66
Copyright 2007, Oracle. All rights reserved.
Performance New FeaturesChapter 1 - Page 7
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.
8/2/2019 Student Guide Performance
12/66
Copyright 2007, Oracle. All rights reserved.
Performance New FeaturesChapter 1 - Page 8
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.
8/2/2019 Student Guide Performance
13/66
Copyright 2007, Oracle. All rights reserved.
Performance New FeaturesChapter 1 - Page 9
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.
8/2/2019 Student Guide Performance
14/66
Copyright 2007, Oracle. All rights reserved.
Performance New FeaturesChapter 1 - Page 10
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.
8/2/2019 Student Guide Performance
15/66
Copyright 2007, Oracle. All rights reserved.
Performance New FeaturesChapter 1 - Page 11
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.
8/2/2019 Student Guide Performance
16/66
Copyright 2007, Oracle. All rights reserved.
Performance New FeaturesChapter 1 - Page 12
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.
8/2/2019 Student Guide Performance
17/66
Copyright 2007, Oracle. All rights reserved.
Performance New FeaturesChapter 1 - Page 13
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.
8/2/2019 Student Guide Performance
18/66
Copyright 2007, Oracle. All rights reserved.
Performance New FeaturesChapter 1 - Page 14
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.
8/2/2019 Student Guide Performance
19/66
Copyright 2007, Oracle. All rights reserved.
Performance New FeaturesChapter 1 - Page 15
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.
8/2/2019 Student Guide Performance
20/66
Copyright 2007, Oracle. All rights reserved.
Performance New FeaturesChapter 1 - Page 16
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.
8/2/2019 Student Guide Performance
21/66
Copyright 2007, Oracle. All rights reserved.
Performance New FeaturesChapter 1 - Page 17
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.
8/2/2019 Student Guide Performance
22/66
Copyright 2007, Oracle. All rights reserved.
Performance New FeaturesChapter 1 - Page 18
The PEEKED column has the value YES if the bind set was used to build the cursor, and NO
otherwise.
8/2/2019 Student Guide Performance
23/66
Copyright 2007, Oracle. All rights reserved.
Performance New FeaturesChapter 1 - Page 19
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.
8/2/2019 Student Guide Performance
24/66
Copyright 2007, Oracle. All rights reserved.
Performance New FeaturesChapter 1 - Page 20
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.
8/2/2019 Student Guide Performance
25/66
Copyright 2007, Oracle. All rights reserved.
Performance New FeaturesChapter 1 - Page 21
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.
8/2/2019 Student Guide Performance
26/66
Copyright 2007, Oracle. All rights reserved.
Performance New FeaturesChapter 1 - Page 22
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.
8/2/2019 Student Guide Performance
27/66
Copyright 2007, Oracle. All rights reserved.
Performance New FeaturesChapter 1 - Page 23
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.
8/2/2019 Student Guide Performance
28/66
Copyright 2007, Oracle. All rights reserved.
Performance New FeaturesChapter 1 - Page 24
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
8/2/2019 Student Guide Performance
29/66
Copyright 2007, Oracle. All rights reserved.
Using Result CachesChapter 0 - Page 1
Using Result Caches
8/2/2019 Student Guide Performance
30/66
Copyright 2007, Oracle. All rights reserved.
Using Result CachesChapter 2 - Page 2
Chapter 2Using Result Caches
Using Result Caches
Oracle Database 11g
8/2/2019 Student Guide Performance
31/66
Copyright 2007, Oracle. All rights reserved.
Using Result CachesChapter 2 - Page 3
Objectives
Objectives
After completing this lesson, you should be able to:
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
8/2/2019 Student Guide Performance
32/66
Copyright 2007, Oracle. All rights reserved.
Using Result CachesChapter 2 - Page 4
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.
8/2/2019 Student Guide Performance
33/66
Copyright 2007, Oracle. All rights reserved.
Using Result CachesChapter 2 - Page 5
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.
8/2/2019 Student Guide Performance
34/66
Copyright 2007, Oracle. All rights reserved.
Using Result CachesChapter 2 - Page 6
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.
8/2/2019 Student Guide Performance
35/66
Copyright 2007, Oracle. All rights reserved.
Using Result CachesChapter 2 - Page 7
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.
8/2/2019 Student Guide Performance
36/66
Copyright 2007, Oracle. All rights reserved.
Using Result CachesChapter 2 - Page 8
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.
8/2/2019 Student Guide Performance
37/66
Copyright 2007, Oracle. All rights reserved.
Using Result CachesChapter 2 - Page 9
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.
8/2/2019 Student Guide Performance
38/66
Copyright 2007, Oracle. All rights reserved.
Using Result CachesChapter 2 - Page 10
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.
8/2/2019 Student Guide Performance
39/66
Copyright 2007, Oracle. All rights reserved.
Using Result CachesChapter 2 - Page 11
SQL Query Result Cache: Considerations
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.
8/2/2019 Student Guide Performance
40/66
Copyright 2007, Oracle. All rights reserved.
Using Result CachesChapter 2 - Page 12
SQL Query Result Cache: Considerations
SQL Query Result Cache: Considerations
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.
8/2/2019 Student Guide Performance
41/66
Copyright 2007, Oracle. All rights reserved.
Using Result CachesChapter 2 - Page 13
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.
8/2/2019 Student Guide Performance
42/66
Copyright 2007, Oracle. All rights reserved.
Using Result CachesChapter 2 - Page 14
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.
8/2/2019 Student Guide Performance
43/66
Copyright 2007, Oracle. All rights reserved.
Using Result CachesChapter 2 - Page 15
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.
8/2/2019 Student Guide Performance
44/66
Copyright 2007, Oracle. All rights reserved.
Using Result CachesChapter 2 - Page 16
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.
8/2/2019 Student Guide Performance
45/66
Copyright 2007, Oracle. All rights reserved.
Using Result CachesChapter 2 - Page 17
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.
8/2/2019 Student Guide Performance
46/66
Copyright 2007, Oracle. All rights reserved.
Using Result CachesChapter 2 - Page 18
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.
8/2/2019 Student Guide Performance
47/66
Copyright 2007, Oracle. All rights reserved.
Using Result CachesChapter 2 - Page 19
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
8/2/2019 Student Guide Performance
48/66
Copyright 2007, Oracle. All rights reserved.
Using Result CachesChapter 2 - Page 20
8/2/2019 Student Guide Performance
49/66
Copyright 2007, Oracle. All rights reserved.
Oracle SecureFilesChapter 0 - Page 1
Oracle SecureFiles
8/2/2019 Student Guide Performance
50/66
Copyright 2007, Oracle. All rights reserved.
Oracle SecureFilesChapter 3 - Page 2
Chapter 3Oracle SecureFiles
Oracle SecureFiles
Consolidated Secure Management of Data
8/2/2019 Student Guide Performance
51/66
Copyright 2007, Oracle. All rights reserved.
Oracle SecureFilesChapter 3 - Page 3
Objectives
Objectives
After completing this lesson, you should be able to:
Discuss large object (LOB) improvements usingSecureFiles
Use SQL and PL/SQL APIs to access SecureFiles
8/2/2019 Student Guide Performance
52/66
Copyright 2007, Oracle. All rights reserved.
Oracle SecureFilesChapter 3 - Page 4
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.
8/2/2019 Student Guide Performance
53/66
Copyright 2007, Oracle. All rights reserved.
Oracle SecureFilesChapter 3 - Page 5
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.
8/2/2019 Student Guide Performance
54/66
Copyright 2007, Oracle. All rights reserved.
Oracle SecureFilesChapter 3 - Page 6
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.
8/2/2019 Student Guide Performance
55/66
Copyright 2007, Oracle. All rights reserved.
Oracle SecureFilesChapter 3 - Page 7
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.
8/2/2019 Student Guide Performance
56/66
Copyright 2007, Oracle. All rights reserved.
Oracle SecureFilesChapter 3 - Page 8
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.
8/2/2019 Student Guide Performance
57/66
Copyright 2007, Oracle. All rights reserved.
Oracle SecureFilesChapter 3 - Page 9
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.
8/2/2019 Student Guide Performance
58/66
Copyright 2007, Oracle. All rights reserved.
Oracle SecureFilesChapter 3 - Page 10
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.
8/2/2019 Student Guide Performance
59/66
Copyright 2007, Oracle. All rights reserved.
Oracle SecureFilesChapter 3 - Page 11
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.
8/2/2019 Student Guide Performance
60/66
Copyright 2007, Oracle. All rights reserved.
Oracle SecureFilesChapter 3 - Page 12
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
Recommended