Student Guide Performance

Oracle Database 11g: Performance
Student Guide
D52363GC10 Edition 1.0 October 2007 PRODUCTION
Copyright 2007, Oracle. All rights reserved. This documentation contains proprietary information of Oracle Corporation. It is provided under a license agreement containing restrictions on use and disclosure and is also protected by copyright law. Reverse engineering of the software is prohibited. If this documentation is delivered to a U.S. Government Agency of the Department of Defense, then it is delivered with Restricted Rights and the 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 be Restricted Rights software under Federal law, as set forth in subparagraph (c)(1)(ii) of DFARS 252.227-7013, Rights in Technical Data and 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 the Education Products group of Oracle Corporation. Any other copying is a violation of copyright law and may result in civil and/or criminal penalties. If this documentation is delivered to a U.S. Government Agency not within the Department of Defense, then it is delivered with Restricted 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 them in writing to Worldwide Education Services, Oracle Corporation, 500 Oracle Parkway, Box SB-6, Redwood Shores, CA 94065. Oracle Corporation 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
Table of Contents
Performance New Features ............................................................................................................................1-2 Chapter 1Performance New Features ............................................................................................................1-2 Objectives......................................................................................................................................................1-3 Foreground Statistics.....................................................................................................................................1-4 Online Redefinition Enhancements ...............................................................................................................1-5 Minimizing Dependent Recompilations........................................................................................................1-6 Locking Enhancements .................................................................................................................................1-7 Invisible Index: Overview .............................................................................................................................1-8 Invisible Indexes: Examples..........................................................................................................................1-9 PL/SQL and Java Native Compilation Enhancements ..................................................................................1-10 Setting Up and Testing PL/SQL Native Compilation ..................................................................................1-11 Recompiling the Entire Database for PL/SQL Native Compilation.............................................................1-12 Adaptive Cursor Sharing: Overview .............................................................................................................1-14 Adaptive Cursor Sharing: Architecture .........................................................................................................1-15 Adaptive Cursor Sharing Views ....................................................................................................................1-17 Interacting with Adaptive Cursor Sharing.....................................................................................................1-19 Temporary Tablespace Shrink.......................................................................................................................1-20 DBA_TEMP_FREE_SPACE........................................................................................................................1-21 Tablespace Option for Creating Temporary Table........................................................................................1-22 Easier Recovery from Loss of SPFILE .........................................................................................................1-23 Summary .......................................................................................................................................................1-24 Using Result Caches ........................................................................................................................................2-2 Chapter 2Using Result Caches ......................................................................................................................2-2 Objectives......................................................................................................................................................2-3 SQL Query Result Cache: Overview ............................................................................................................2-4 Setting Up SQL Query Result Cache ............................................................................................................2-5 Managing the SQL Query Result Cache .......................................................................................................2-6 Using the RESULT_CACHE Hint ................................................................................................................2-7 In-Line View: Example .................................................................................................................................2-8 Using the DBMS_RESULT_CACHE Package ............................................................................................2-9 Viewing SQL Query Result Cache Dictionary Information..........................................................................2-10 SQL Query Result Cache: Considerations ....................................................................................................2-11 OCI Client Query Cache ...............................................................................................................................2-13 Using Client-Side Query Cache ....................................................................................................................2-14 PL/SQL Function Cache ...............................................................................................................................2-15 Using PL/SQL Function Cache .....................................................................................................................2-16 PL/SQL Function Cache: Considerations......................................................................................................2-17 Demonstration ...............................................................................................................................................2-18 Summary .......................................................................................................................................................2-19 Oracle SecureFiles...........................................................................................................................................3-2 Chapter 3Oracle SecureFiles .........................................................................................................................3-2 Objectives......................................................................................................................................................3-3 Managing Enterprise Information .................................................................................................................3-4 Problems with Existing LOB Implementation ..............................................................................................3-5 Oracle SecureFiles.........................................................................................................................................3-6 Enabling SecureFiles Storage........................................................................................................................3-7 SecureFiles Advanced Features.....................................................................................................................3-8 SecureFiles Storage Options .........................................................................................................................3-9 Creating SecureFiles .....................................................................................................................................3-10 Creating SecureFiles using Enterprise Manager............................................................................................3-11 Altering SecureFiles ......................................................................................................................................3-12 Accessing SecureFiles Metadata ...................................................................................................................3-13 Migrating to SecureFiles ...............................................................................................................................3-14 SecureFiles Migration Example ....................................................................................................................3-15 SecureFiles Monitoring .................................................................................................................................3-16 SecureFiles Demonstration............................................................................................................................3-17
Copyright 2007, Oracle. All rights reserved.
Table of Contents i
Summary .......................................................................................................................................................3-18
Table of Contents ii
Performance New Features
Performance New Features Chapter 0 - Page 1
Chapter 1Performance New Features
Performance New Features
Oracle Database 11g
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
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
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 invalidate dependent objects.
Oracle Database 11g supports online redefinition for tables with 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.
Minimizing Dependent Recompilations
Minimizing Dependent Recompilations

Adding a column to a table does not invalidate its dependent objects. Adding a PL/SQL unit to a package does not invalidate dependent 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 T table 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.
Locking Enhancements
Locking Enhancements
DDL commands can now wait for DML locks to be released:
DDL_LOCK_TIMEOUT initialization parameter
New WAIT [<timeout>] clause for the LOCK TABLE command The following commands will no longer acquire exclusive 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 LOCK TABLE 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 lockfor example, 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.
Invisible Index: Overview
Invisible Index: Overview

Use index. Do not use index.
Optimizer view point

VISIBLE Index INVISIBLE Index
OPTIMIZER_USE_INVISIBLE_INDEXES=FALSE
Data view point
Update index. Update table.
Update index. Update table.
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.
Invisible Indexes: Examples
Invisible Indexes: Examples

Index is altered as not visible to the optimizer:
ALTER INDEX ind1 INVISIBLE;
Optimizer does not consider this index:

SELECT /*+ index(TAB1 IND1) */ COL1 FROM TAB1 WHERE ;
Optimizer will always consider the index:

ALTER INDEX ind1 VISIBLE;
Create an index as invisible initially:

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.
PL/SQL and Java Native Compilation Enhancements
PL/SQL and Java Native Compilation Enhancements

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.
Setting Up and Testing PL/SQL Native Compilation
Setting Up and Testing PL/SQL Native Compilation

1. Set PLSQL_CODE_TYPE to NATIVE:
ALTER SYSTEM | ALTER SESSION | ALTER COMPILE
2. Compile your PL/SQL units (example):

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;
3. Make sure you succeeded:

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 of PLSQL_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 ALTER <PL/SQL unit type> COMPILE 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 of NATIVE for program units that are compiled for native execution, and INTERPRETED otherwise.
Recompiling the Entire Database for PL/SQL Native Compilation
Recompiling the Entire Database for PL/SQL Native Compilation

1. 2. 3. 4. Shut down the database. Set PLSQL_CODE_TYPE to NATIVE. Start up the database in UPGRADE mode. 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 the compilation 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.
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.sql script 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.
Adaptive Cursor Sharing: Overview
Adaptive Cursor Sharing: Overview

Allows for intelligent cursor sharing only for statements that use bind variables Is used to compromise between cursor sharing and optimization Has the following benefits:
Automatically detects when different executions would benefit from different execution plans Limits the number of generated child cursors to a minimum 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 bind peeking, 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.
Adaptive Cursor Sharing: Architecture
Adaptive Cursor Sharing: Architecture

System observes statement for a while.
Bind-sensitive cursor
SELECT * FROM emp WHERE sal = :1 and dept = :2
Bind-aware cursor
Initial plan
GB HJ
Initial selectivity cube
Same selectivity cube

S o f t P a r s e
No need for new plan

GB HJ
0.0025
.
0.15
HJ
0.003
.
0.18
HJ
:1=A & :2=B S(:1)=0.15 S(:2)=0.0025
:1=C & :2=D S(:1)=0.18 S(:2)=0.003
Merged selectivity cubes

H a r d P a r s e
No need for new plan

GB GB HJ HJ
Second selectivity cube Need new plan

H a r d P a r s e
0.009
GB HJ HJ
GB HJ HJ
0.004
.
0.28
HJ HJ
Cubes merged
0.3 :1=E & :2=F S(:1)=0.3 S(:2)=0.009
:1=G & :2=H S(:1)=0.28 S(:2)=0.004
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.
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 new set 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.
Adaptive Cursor Sharing Views
Adaptive Cursor Sharing Views
The following views provide information about Adaptive Cursor Sharing usage:
V$SQL V$SQL_CS_HISTOGRAM
Two new columns show whether a cursor is bind-sensitive or bind-aware. Shows the distribution of the execution count across the execution history histogram Shows the selectivity cubes stored for every predicate containing a bind variable and whose selectivity is used in the cursor sharing checks Shows execution statistics of a cursor using different bind sets
V$SQL_CS_SELECTIVITY
V$SQL_CS_STATISTICS
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 bindsensitive. IS_BIND_AWARE: Indicates if a cursor is bind-aware; value YES | NO. A cursor in the cursor cache that has been marked to use 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, and CPU time.
The PEEKED column has the value YES if the bind set was used to build the cursor, and NO otherwise.
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 may apply to them.
SQL Plan Management (SPM):

If OPTIMIZER_CAPTURE_SQL_PLAN_BASELINES is set to TRUE, 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 cursor cache. Manually load the cursor cache into the corresponding plan 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.
Temporary Tablespace Shrink
Temporary Tablespace Shrink

Sort segment extents are managed in memory after being physically allocated. This method can be an issue after big sorts are done. To release physical space from your disks, you can shrink temporary tablespaces:
Locally managed temporary tablespaces Online operation
CREATE TEMPORARY TABLESPACE temp TEMPFILE 'tbs_temp.dbf' SIZE 600m REUSE AUTOEXTEND ON MAXSIZE UNLIMITED EXTENT MANAGEMENT LOCAL UNIFORM SIZE 1m; ALTER TABLESPACE temp SHRINK SPACE [KEEP 200m]; ALTER TABLESPACE temp SHRINK TEMPFILE 'tbs_temp.dbf';
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 ORA03297 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.
DBA_TEMP_FREE_SPACE
DBA_TEMP_FREE_SPACE
Lists temporary space usage information Central point for temporary tablespace space usage
Column name TABLESPACE_NAME TABLESPACE_SIZE ALLOCATED_SPACE Description Name of the tablespace Total size of the tablespace, in bytes Total allocated space, in bytes, including space that is currently allocated and used and space that is currently allocated and available for reuse Total free space available, in bytes, including space that is currently allocated and available for reuse and space that is currently unallocated
FREE_SPACE
This dictionary view reports temporary space usage information at the tablespace level. The information is derived from various existing views.
Tablespace Option for Creating Temporary Table
Tablespace Option for Creating Temporary Table
Specify which temporary tablespace to use for your global temporary tables. Decide a proper temporary extent size.
CREATE TEMPORARY TABLESPACE temp TEMPFILE 'tbs_temp.dbf' SIZE 600m REUSE AUTOEXTEND ON MAXSIZE UNLIMITED EXTENT MANAGEMENT LOCAL UNIFORM SIZE 1m; CREATE GLOBAL TEMPORARY TABLE temp_table (c varchar2(10)) ON COMMIT DELETE ROWS TABLESPACE temp;
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_TABLES which tablespace is used to store your global temporary tables.
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.
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
Using Result Caches
Using Result Caches Chapter 0 - Page 1
Chapter 2Using Result Caches
Using Result Caches
Oracle Database 11g
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 the SQL Query Result Cache for your database Use a hint to override database settings for caching results Improve performance by using client-side query cache, eliminating round-trips to the server Cache function results making them available to other sessions
SQL Query Result Cache: Overview
SQL Query Result Cache: Overview

Cache the result of a query or query block for future reuse. Cache is used across statements and sessions unless it is stale. Benefits:
Scalability Reduction of memory usage
Good candidate statements:

Access many rows Return few rows
Session 1 SELECT SQL Query Result Cache
2 1
3
SELECT Session 2
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 the disks. 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.
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 results to 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.
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% of memory_target, or 0.5% of sga_target, or 1% of shared_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 remote database 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_EXPIRATION parameter 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.
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; -------------------------------------------------------------| Id | | | | | Operation | Name | | |Rows | | 11 11 -------------------------------------------------------------0 | SELECT STATEMENT 1 | 2 | 3 | RESULT CACHE HASH GROUP BY | 8fpza04gtwsfr6n595au15yj4y | | 107
TABLE ACCESS FULL| EMPLOYEES
-------------------------------------------------------------SELECT /*+ NO_RESULT_CACHE */ department_id, AVG(salary) FROM employees GROUP BY department_id;
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 in your 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.
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') and to_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.
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:
SELECT DBMS_RESULT_CACHE.STATUS FROM DUAL;
Retrieve statistics on the cache memory usage:

EXECUTE DBMS_RESULT_CACHE.MEMORY_REPORT;
Remove all existing results and clear cache memory:

EXECUTE DBMS_RESULT_CACHE.FLUSH;
Invalidate cached results depending on specified object: 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.
Viewing SQL Query Result Cache Dictionary Information
Viewing SQL Query Result Cache Dictionary Information

The following views provide information about the query result cache:
(G)V$RESULT_CACHE_STATISTICS
Lists the various cache settings and memory usage statistics Lists all the memory blocks and the corresponding statistics Lists all the objects (cached results and dependencies) along with their attributes Lists the dependency details between the cached results and dependencies
(G)V$RESULT_CACHE_MEMORY (G)V$RESULT_CACHE_OBJECTS
(G)V$RESULT_CACHE_DEPENDENCY
Note: See the Oracle Database Reference guide.
SQL Query Result Cache: Considerations

Result cache is disabled for queries containing:
Temporary or dictionary tables Nondeterministic PL/SQL functions Sequences CURRVAL and NEXTVAL SQL functions current_date, sysdate, sys_guid for example DML/DDL on remote database (does not expire cached results)
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.

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 variable values.
Cached result will not be built if:

Query is built on a noncurrent version of data (read consistency 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.
OCI Client Query Cache
OCI Client Query Cache

Extends server-side query caching to client-side memory Ensures better performance by eliminating round-trips to the server Leverages client-side memory Improves server scalability by saving server CPU resources Result cache automatically refreshed if the result set is changed 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 do not 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.
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 OCI_RESULT_CACHE_MAX_SIZE OCI_RESULT_CACHE_MAX_RSET_SIZE OCI_RESULT_CACHE_MAX_RSET_ROWS
Using the client configuration file:

Client result cache is used depending on RESULT CACHE 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 server initialization 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.
PL/SQL Function Cache
PL/SQL Function Cache
Stores function results in cache, making them available to other sessions Uses the Query Result Cache
exec Calculate();
Cached results
First query
BEGIN SELECT FROM table; END; exec Calculate(); exec Calculate();
Subsequent queries
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 systemmanaged 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 so that 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.
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 NVARCHAR2 RESULT_CACHE RELIES_ON (product_descriptions) IS result VARCHAR2(50); BEGIN SELECT translated_name INTO result FROM product_descriptions WHERE product_id = prod_id AND language_id = lang_id; RETURN result; END;
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 parameter values - When the cached result for these parameter values is invalid. A cashed result becomes invalid when any database object specified in the RELIES_ON clause of the function definition changes. - When the cached result for these parameter values has aged out. If the system needs memory, it might discard the oldest cached values. - When the function bypasses the cache The function should not have any side effects. The function should not depend on session-specific settings. The function should not depend on session-specific application contexts.
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 the invokers 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, REF CURSOR, object, record, or collection with one of the preceding unsupported return types.
Demonstration
Demonstration
Click the link in the notes below for Oracle By Example demonstration 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.
Summary
Summary
In this lesson, you should have learned how to: Improve memory usage by using SQL Query Result Cache to cache query result sets. Use initialization parameters to manage the SQL Query Result Cache for your database Use RESULT_CACHE hint to override database settings Improve performance by using OCI Client Query cache to eliminate round-trips to the server. Cache PL/SQL function results to make them available to other sessions
Oracle SecureFiles
Oracle SecureFiles Chapter 0 - Page 1
Chapter 3Oracle SecureFiles
Oracle SecureFiles
Consolidated Secure Management of Data
Objectives
Objectives
After completing this lesson, you should be able to: Discuss large object (LOB) improvements using SecureFiles Use SQL and PL/SQL APIs to access SecureFiles
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 processing documents Unstructured: Media, medical data, imaging
Structured
Semi-structured
Unstructured
Today, applications must deal with many kinds of data, broadly classified as structured, semistructured 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.
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.
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 as intelligent 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.
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:
The ALTER SESSION | SYSTEM command:

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 options If NEVER 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. If ALWAYS 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 ALTER SYSTEM command as shown above. You can also use Enterprise Manager to set the parameter from the Server tab > Initialization Parameters link.
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, and scalability 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 industrystandard 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.
SecureFiles Storage Options
SecureFiles Storage Options

MAXSIZE: Specifies the maximum LOB segment size RETENTION: Specifies the retention policy to use
MAX: Keeps old versions until MAXSIZE 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 to SecureFiles:

CHUNK, PCTVERSION, FREEPOOLS, FREELISTS, and FREELIST 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 ALTER TABLE 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.
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 LOB(doc) STORE AS SECUREFILE (ENCRYPT); CLOB)
CREATE TABLE design_spec (id number, doc CLOB ENCRYPT) LOB(doc) STORE AS SECUREFILE;
You create SecureFiles with the SECUREFILE storage keyword in the CREATE TABLE 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.
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.
Altering SecureFiles
Altering SecureFiles
ALTER TABLE t1 MODIFY LOB(a) ( KEEP_DUPLICATES ); ALTER TABLE t1 MODIFY LOB(a) ( DEDUPLICATE LOB );
Disable deduplication. Enable deduplication.
Enable partition ALTER TABLE t1 deduplication. MODIFY PARTITION p1 LOB(a) ( DEDUPLICATE LOB );
ALTER TABLE t1 MODIFY LOB(a) ( NOCOMPRESS );
Disable compression. Enable compression.
ALTER TABLE t1 MODIFY LOB(a) (COMPRESS HIGH); Enable compression on SecureFiles within a single partition. ALTER TABLE t1 MODIFY PARTITION p1 LOB(a) ( COMPRESS HIGH );
Enable encryption using 3DES168. ALTER TABLE t1 MODIFY ( a CLOB ENCRYPT USING '3DES168');
ALTER TABLE t1 MODIFY PARTITION p1 ( LOB(a) ( ENCRYPT );
Enable encryption on partition. Enable encryption and build the encryption key using a password.
ALTER TABLE t1 MODIFY ( a CLOB ENCRYPT IDENTIFIED BY ghYtp);
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 Encryption (TDE). All LOBs in the LOB segment are altered with the new setting. A LOB segment can be altered only to enable or disable LOB encryption. That is, ALTER cannot be used to update the encryption algorithm or the encryption key. The encryption algorithm or encryption key can be updated using the ALTER TABLE REKEY syntax. Encryption is done at the block level allowing for better performance (smallest encryption amount possible) when combined with other options. Note: For a full description of the options available for the CREATE TABLE statement, see the Oracle Database SQL Reference Guide.
Accessing SecureFiles Metadata
Accessing SecureFiles Metadata
The data layer interface is the same as with BasicFiles.
DBMS_LOB
GETOPTIONS() SETOPTIONS
SecureFiles
DBMS_SPACE.SPACE_USAGE
DBMS_LOB Package: LOBs inherit the LOB column settings for deduplication, encryption, and compression, which can also be configured on a per-LOB level using the LOB locator API. However, the LONG API cannot be used to configure these LOB settings. You must use the following DBMS_LOB package additions for these features: DBMS_LOB.GETOPTIONS: Settings can be obtained using this function. An integer corresponding to a pre-defined constant based on the option type is returned. DBMS_LOB.SETOPTIONS: This procedure sets features and allows the features to be set on a per-LOB basis, overriding the default LOB settings. Incurs a round trip to the server to make the changes persistent. DBMS_SPACE.SPACE_USAGE: The existing SPACE_USAGE procedure is overloaded to return information about LOB space usage. It returns the amount of disk space in blocks used by all the LOBs in the LOB segment. This procedure can only be used on tablespaces that are created with ASSM and does not treat LOB chunks belonging to BasicFiles as used space. Note: See the Oracle Database PL/SQL Packages and Types Reference Guide.
Migrating to SecureFiles
Migrating to SecureFiles
Use online redefinition.
SecureFiles
A superset of LOB interfaces allows easy migration from BasicFile LOBs. The two recommended methods for migration to SecureFiles are partition exchange and online redefinition. Partition Exchange: Needs additional space equal to the largest of the partitions in the table Can maintain indexes during the exchange Can spread the workload out over several smaller maintenance windows Requires that the table or partition needs to be offline to perform the exchange Online Redefinition (recommended practice): No need to take the table or partition offline Can be done in parallel Requires additional storage equal to the entire table and all LOB segments to be available Any global indexes must be rebuilt These solutions generally mean using twice the disk space used by the data in the input LOB column. However, using partitioning and taking these actions on a partition-by-partition basis may help lower the disk space required.
SecureFiles Migration Example
SecureFiles Migration Example
create table tab1 (id number not null, c clob) partition by range(id) (partition p1 values less than (100) tablespace tbs1 lob(c) store as lobp1, partition p2 values less than (200) tablespace tbs2 lob(c) store as lobp2, partition p3 values less than (300) tablespace tbs3 lob(c) store as lobp3);
Insert your data.

create table tab1_tmp (id partition by range(id) (partition p1 values less partition p2 values less partition p3 values less number not null, c clob) than (100) tablespace tbs1 lob(c) store as lobp1, than (200) tablespace tbs2 lob(c) store as lobp2, than (300) tablespace tbs3 lob(c) store as lobp3);
begin dbms_redefinition.start_redef_table('scott','tab1','tab1_tmp','id id, c c'); dbms_redefinition.copy_table_dependents('scott','tab1','tab1_tmp',1, true,true,true,false,error_count); dbms_redefinition.finish_redef_table('scott','tab1','tab1_tmp'); end;
The example above can be used to migrate BasicFile to SecureFile LOBs. First, you create your table using BasicFiles. The example uses a partitioned table. Then, you insert data in your table. Following that, you create a transient table that has the same number of partitions but this time using SecureFiles. Note that this transient table has the same columns and types. The last section demonstrates the redefinition of your table using the previously created transient table with the DBMS_REDEFINITION procedure.
SecureFiles Monitoring
SecureFiles Monitoring
The following views have been modified to show SecureFiles usage: *_SEGMENTS *_LOBS *_LOB_PARTITIONS *_PART_LOBS
SQL> 2 3 4 5 SELECT segment_name, segment_type, segment_subtype FROM dba_segments WHERE tablespace_name = 'SECF_TBS2' AND segment_type = 'LOBSEGMENT' / SEGMENT_SU ---------SECUREFILE
SEGMENT_NAME SEGMENT_TYPE ---------------------------- -----------------SYS_LOB0000071583C00004$$ LOBSEGMENT
SecureFiles Demonstration
SecureFiles Demonstration
For further understanding, you can click the link in the notes below for an Oracle By Example on the SecureFiles features: Using SecureFiles to Improve Performance, Maximize Storage, and Enhance Security
Click the following link to further understand: Using SecureFiles to Improve Performance, Maximize Storage, and Enhance Security[http://otnbeta.us.oracle.com/db11gr1/trng/obes/datamgmt/securefile/securefile.htm ] Note: This OBE was created under Oracle Database 11g, Beta 4.
Summary
Summary
In this lesson, you should have learned how to: Discuss LOB improvements using SecureFiles Use SQL and PL/SQL APIs to access SecureFiles

Student Guide Performance

Загружено:

Сведения о документе

Исходное описание:

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Student Guide Performance

Загружено:

Авторское право:

Доступные форматы

Oracle Database 11g: Performance

D52363GC10 Edition 1.0 October 2007 PRODUCTION

Oracle Database 11g: Performance

Copyright 2007, Oracle. All rights reserved.

Oracle Database 11g: Performance

Performance New Features

Copyright 2007, Oracle. All rights reserved.

Performance New Features Chapter 0 - Page 1

Chapter 1Performance New Features

Performance New Features

Oracle Database 11g

Copyright 2007, Oracle. All rights reserved.

Performance New Features Chapter 1 - Page 2

Copyright 2007, Oracle. All rights reserved.

Performance New Features Chapter 1 - Page 3

Copyright 2007, Oracle. All rights reserved.

Performance New Features Chapter 1 - Page 4

Online Redefinition Enhancements

Online Redefinition Enhancements

Online redefinition does not systematically invalidate dependent objects.

Copyright 2007, Oracle. All rights reserved.

Performance New Features Chapter 1 - Page 5

Minimizing Dependent Recompilations

Minimizing Dependent Recompilations

Copyright 2007, Oracle. All rights reserved.

Performance New Features Chapter 1 - Page 6

Copyright 2007, Oracle. All rights reserved.

Performance New Features Chapter 1 - Page 7

Invisible Index: Overview

Invisible Index: Overview

Optimizer view point

Data view point

Update index. Update table.

Update index. Update table.

Copyright 2007, Oracle. All rights reserved.

Performance New Features Chapter 1 - Page 8

Invisible Indexes: Examples

Invisible Indexes: Examples

Optimizer does not consider this index:

Optimizer will always consider the index:

Create an index as invisible initially:

Copyright 2007, Oracle. All rights reserved.

Performance New Features Chapter 1 - Page 9

PL/SQL and Java Native Compilation Enhancements

PL/SQL and Java Native Compilation Enhancements

Copyright 2007, Oracle. All rights reserved.

Performance New Features Chapter 1 - Page 10

Setting Up and Testing PL/SQL Native Compilation

Setting Up and Testing PL/SQL Native Compilation

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

3. Make sure you succeeded:

Performance New Features Chapter 1 - Page 11

Recompiling the Entire Database for PL/SQL Native Compilation

Recompiling the Entire Database for PL/SQL Native Compilation

Copyright 2007, Oracle. All rights reserved.

Performance New Features Chapter 1 - Page 12

Copyright 2007, Oracle. All rights reserved.

Performance New Features Chapter 1 - Page 13

Adaptive Cursor Sharing: Overview

Adaptive Cursor Sharing: Overview

Copyright 2007, Oracle. All rights reserved.

Performance New Features Chapter 1 - Page 14

Adaptive Cursor Sharing: Architecture

-------------------------------------------------------------SELECT /+ NO_RESULT_CACHE / department_id, AVG(salary) FROM employees GROUP BY department_id;