Post on 10-Apr-2015
New performance features for Developers
<Insert Picture Here>
11g new performance features for DevelopersA Knowledge Transfer session
Nikos Plevris, Principal Service Delivery Manager, November 2009
New performance features for Developers
Agenda
• SQL and PL/SQL performance improvement and scalability• New and Enhanced
• Functionality
• Structures
• Objects
• The Developer’s approach
New performance features for Developers
Automatic “Native” PL/SQL Compilation
• Previous releases: PL/SQL interpreted to C code, then compiled by 3rd party compiler or DLL loader
• 11g: PL/SQL source code is directly translated to the DLL for the server, bypassing the file system directories by doing the linking and loading itself.
• Initialization parameter: plsql_code_type• [NATIVE | INTERPRETED]
• Dynamic change:• alter system | alter session• alter procedure <PROC> compile plsql_code_type=native;
• DBA_PLSQL_OBJECT_SETTINGS view
20% improved performance With native PL/SQL compilation:
The Whetstone Benchmark shows
that real native compilation is
two-and-a-half times faster than
C native compilation.
New performance features for Developers
Adaptive Cursor Sharing1
• Parameter cursor_sharing := [EXACT|SIMILAR|FORCE]
• Bind peeking – Optimizer evolves execution plan during first hard parse of bind variables
• 11g adaptive cursor sharing – Optimizer generates multiple execution plans for a statement that uses bind variables
New performance features for Developers
Adaptive Cursor Sharing2
• Allows for intelligent cursor sharing 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 plans
• The optimizer avoids expensive table scans and index searches based on selectivity criteria thus speeding up data retrieval
• Automated mechanism that cannot be turned off
New performance features for Developers
Adaptive Cursor Sharing3 - Architecture
New performance features for Developers
Adaptive Cursor Sharing4 – Dictionary Views
New performance features for Developers
Adaptive Cursor Sharing Demo
New performance features for Developers
SQL Query Result Cache1
• Cache the result of a query or query block for future use (SQL query and PL/SQL function results)
• Cache is used across sessions and statements unless it is stale
• Benefits:• Scalability
• Reduction of memory usage and I/O
• Good candidate statements:• Access many rows
• Return few rows
200% improved performance for read-intensive workload Part of SGA shared pool (~1% of shared_pool_size up to 75%) or(0.25% of memory_target) or(0.50% of sga_target)
New performance features for Developers
Setting Up SQL Query Result Cache2
• At the instance level using parameter RESULT_CACHE_MODE. Values are:
• AUTO: The optimizer decides to cache based on repetitive executions
• MANUAL: Use hint result_cache• FORCE: All results are stored in the cache
• At table level:
Three new init parameters result_cache_mode result_cache_max_size result_cache_max_result
Dynamic parameters:ALTER SYSTEM SET
result_cache_mode = ‘AUTO’;
New performance features for Developers
Setting Up SQL query result cache3
• At the session level:• ALTER SESSION SET result_cache_mode=FORCE;
• At the statement level – Queries, subqueries and inline views:
• Hints result_cache_mode and no_result_cache
Using the hint
PL/SQL code
New performance features for Developers
Administer SQL query result cache4
• Use DBMS_RESULT_CACHE package:
• View SQL Query cache dictionary information:
New performance features for Developers
Result Query Cache Demo
New performance features for Developers
Considerations on query result cache5
• The result cache is disabled for queries containing:
• Result cache does not release memory:
• Bind variables:
New performance features for Developers
Sequences in PLSQL
• Sequence calls directly into statements without first querying them from the dual pseudotable
• In 11g, the usage of the pseudocolumns CURRVAL and NEXTVAL make writing PL/SQL source code easier and improve run-time performance and scalability.
• The usage of sequence_name.CURRVAL and sequence_name.NEXTVAL can be utilized whenever a number expression is used.
CREATE TABLE seq_table (sequencing_id NUMBER);
CREATE SEQUENCE sequencing_s1;
-- In Oracle 10g you would use a sequence value in a PL/SQL block as follows:
DECLAREsequence_value NUMBER;BEGINSELECT sequencing_s1.nextval INTO sequence_value FROM dual;INSERT INTO seq_table VALUES (sequence_value);COMMIT;END;/
--While this syntax still works in Oracle 11g, you can now simplify it by using:
BEGININSERT INTO seq_table VALUES (sequencing_s1.nextval);COMMIT;END;/
New performance features for Developers
Next-Generation LOBs• 11g provides two storage implementations
for LOB columns:• BASICFILE = Pre-Oracle 11g CLOBs, BLOBs
• SECUREFILE = New LOB storage implementation
• Prerequisites• automatic segment space management
(compatible 11.0.0.0.0)
• Benefits• Faster LOB Retrieval
• ODP.NET now makes fewer round trips to the database server to retrieve LOB information. ODP.NET LOB retrieval performance is now faster
• Queries in SQL*Plus now support BLOB columns.
• Reduce space consumption
• Enhanced Security
create table secure_docs
( document_id number not null primary key,
name varchar2(255) not null,
edba_knowledgebase_category_id number not null,
mime_type varchar2(128),
doc_size number,
dad_charset varchar2(128),
last_updated date,
content_type varchar2(128),
blob_content blob)
tablespace tools
lob (blob_content) store as securefile (
tablespace tools enable storage in row chunk 8192 pctversion 10 nocache logging)
New performance features for Developers
Compound trigger1
• Easier to program one trigger to fire at various timing points instead of multiple simple triggers each fires at single timing point.
• Has a section for each of the BEFORE STATEMENT, BEFORE EACH ROW, AFTER EACH ROW, and AFTER STATEMENT timing points.
• Improved usability for the PL/SQL programmer and improved runtime performance and scalability:
• accumulate rows destined for a second table so that you can periodically bulk-insert them
• To avoid the mutating-table error (ORA-04091)
• Can be defined on either a table or a view
• Only DML statements trigger compound triggers
CREATE [OR REPLACE] TRIGGER trigger_name
FOR {INSERT | UPDATE | UPDATE OF column1
[, column2 [, column(n+1)]] | DELETE}
ON table_name
COMPOUND TRIGGER
[declaration_statement;]
BEFORE STATEMENT IS[declaration_statement;]BEGINexecution_statement;
END BEFORE STATEMENT;
BEFORE EACH ROW IS[declaration_statement;]BEGINexecution_statement;
END BEFORE EACH ROW;
AFTER EACH ROW IS[declaration_statement;]BEGINexecution_statement;
END AFTER EACH ROW;
AFTER STATEMENT IS[declaration_statement;]BEGINexecution_statement;END AFTER STATEMENT;
END [trigger_name];
/
New performance features for Developers
Compound trigger2
• They DO NOT fire when:• the DML statement doesn’t change any rows AND• the trigger hasn’t implemented at least a BEFORE
STATEMENT or AFTER STATEMENT block.
• The declaration section executes before any timing-point sections execute. Variables and subprograms declared in this section have firing-statement duration.
• Support filtering actions :• Instead of the WHEN clause, use the UPDATE OF
column name filter as a governing event in updates.• Implement EXCEPTION blocks in any of the subordinate
timing point blocks
• The :new and :old pseudo-records can be used in the row-level statement blocks
• Requires at least one timing-point block.
CREATE [OR REPLACE] TRIGGER trigger_name
FOR {INSERT | UPDATE | UPDATE OF column1
[, column2 [, column(n+1)]] | DELETE}
ON table_name
COMPOUND TRIGGER
[declaration_statement;]
BEFORE STATEMENT IS[declaration_statement;]BEGINexecution_statement;
END BEFORE STATEMENT;
BEFORE EACH ROW IS[declaration_statement;]BEGINexecution_statement;
END BEFORE EACH ROW;
AFTER EACH ROW IS[declaration_statement;]BEGINexecution_statement;
END AFTER EACH ROW;
AFTER STATEMENT IS[declaration_statement;]BEGINexecution_statement;END AFTER STATEMENT;
END [trigger_name];
/
New performance features for Developers
Compound Trigger Demo
New performance features for Developers
Additional PL/SQL enhancements
• Native dynamic SQL now supports statements bigger than 32K characters by allowing a CLOB argument
• Increased in functionality of string functions: REGEXP_INSTR, REGEXP_SUBSTR, REGEXP_COUNT
• CONTINUE statement
• Minimum need to recompile dependent PL/SQL packages or view after an online table redefinition. ONLY if logically affected
New performance features for Developers
Online Index creation-rebuild and Invisible indexes
• Online index creation and rebuild prior to this release (like 10g) required a DML-blocking exclusive lock at the beginning and end of the rebuild for a short period of time. This meant that there would be two points at which DML activity came to a halt.
• This DML-blocking lock is no longer required, making these online index operations fully transparent.
• Invisible index – Not being visible to the cost optimizer during execution plans
• test the usefulness of a new index without affecting execution plans
• Temporary purposes
The SHARED EXCLUSIVE locking strategy
applies to:
• create index online• rebuild index online• create materialized view log
Invisible index:• CREATE index <idx_name> invisible• ALTER index <idx_name> invisible;• DBA_INDEXES.visibility column
Use hint to force index use• Select /*+index ( <table> <idx> */ FROM ..
At the instance level – Init parameteroptimizer_use_invisible_indexes = FALSE
New performance features for Developers
Partitioning Enhancements1
• Extended Composite Partitioning• Range-Hash (available since 8i)
• Range-List (available since 9i)
• Range-Range
• List-Range
• List-Hash
• List-List
• Extended composite partitioning allows data to be partitioned along two dimensions
CREATE TABLE list_hash_tab ( id NUMBER, code VARCHAR2(10), description VARCHAR2(50), created_date DATE)PARTITION BY LIST (code)SUBPARTITION BY HASH (id)( PARTITION part_aa values ('AA') ( SUBPARTITION part_aa_01, SUBPARTITION part_aa_02 ), partition part_bb values ('BB') ( SUBPARTITION part_bb_01, SUBPARTITION part_bb_02 ));
New performance features for Developers
Extended Composite Partitioning Demo
New performance features for Developers
Partitioning Enhancements2
• Interval Partitioning• automate the creation of range partitions by
creating partitions on demand
• Considerations:• Restricted to a single partition key that must be
a numerical or date range
• At least one partition must be defined when the table is created
• A MAXVALUE partition cannot be defined for an interval partitioned table
• NULL values are not allowed in the partition column
CREATE TABLE interval_tab ( id NUMBER, code VARCHAR2(10), description VARCHAR2(50), created_date DATE)PARTITION BY RANGE (created_date)INTERVAL (NUMTOYMINTERVAL(1,'MONTH'))( PARTITION part_01 values LESS THAN (TO_DATE('01-NOV-2007','DD-MON-YYYY')));
New performance features for Developers
Interval Partitioning Demo
New performance features for Developers
Partitioning Enhancements3
• System Partitioning• Allows large tables to be broken down into
smaller partitions
• There are no partitioning keys, system partitions have no bounds for ranges or lists
• Explicitly specify the rows to the target table partition using partition-aware syntax
• Benefits• The application controls the data placement and
how it is retrieved
• Db has no control over row placement – No partition pruning
CREATE TABLE system_partitioned_tab (
id NUMBER, code VARCHAR2(10), description VARCHAR2(50), created_date DATE)PARTITION BY SYSTEM( PARTITION part_1, PARTITION part_2);
INSERT INTO system_partitioned_tab PARTITION (part_1) VALUES (1, 'ONE', 'One', SYSDATE);
DELETE FROM system_partitioned_tab PARTITION (part_2) WHERE id = 1;
UPDATE system_partitioned_tab PARTITION (part_1) SET code = 'TWO' WHERE id = 2;
New performance features for Developers
Partitioning Enhancements4
• Reference Partitioning• Relies on existing parent-child relationships and
is enforced by an active primary key and foreign key constraint
• The child table automatically inherits the partitioning key from the parent table without duplicating the key columns
• Use the keywords PARTITION BY REFERENCE (foreign_key name) as part of your create table statement
CREATE TABLE parent_tab (
id NUMBER NOT NULL,
code VARCHAR2(10) NOT NULL,
description VARCHAR2(50),
created_date DATE,
CONSTRAINT parent_tab_pk
PRIMARY KEY (id))
PARTITION BY RANGE (created_date)
( PARTITION part_2007 VALUES
LESS THAN (TO_DATE('01-JAN-2008',
'DD-MON-YYYY')),
PARTITION part_2008 VALUES
LESS THAN (TO_DATE('01-JAN-2009',
'DD-MON-YYYY')));
CREATE TABLE child_tab (
id NUMBER NOT NULL,
parent_tab_id NUMBER NOT NULL,
code VARCHAR2(10),
description VARCHAR2(50),
created_date DATE,
CONSTRAINT child_tab_pk PRIMARY KEY (id),
CONSTRAINT child_parent_tab_fk
FOREIGN KEY (parent_tab_id)
REFERENCES parent_tab (id))
PARTITION BY REFERENCE (child_parent_tab_fk);
New performance features for Developers
The other approach: DBA ‘s view
Session Details
Top Activity
SQL Details
Monitoring Details
Q U E S T I O N SQ U E S T I O N S
A N S W E R SA N S W E R S
Q&A
&&