ALLOT019D - Performance Optimization

Documentation Header
Document Description Responsible ALL.OT.019D Oracle Performance Optimization Version 1.01
It deals with the basics of SQL processing, understanding and influencing of the optimizer behavior, problems relating to performance. Pratik Deshmukh Reviewer Sanjeev Sapre
Last Change Description

Version 1.00 Modified in --Responsible Unknown Modification Initial Document
1.01
04.Mar.2010
Pratik Deshmukh
Document Updated to ARTL standards
Documentation v1.00 1 Copyright 2008 Accenture All rights reserved. Accenture Proprietary and Confidential. This component, containing its documentation and code, is proprietary of Accenture and its use and distribution is restrict. For further information or new technical goods, access https://rtl.accenture.com
Table of Contents
1. Document Objective ........................................................................................................................ 3 2. Document Detail ............................................................................................ ..................................4 3. Version Change Log...................................................................................................................... 56
1. Document Objective
Describe the basic steps in processing SQL statements. Describe the causes of performance problems. Understand where SQL tuning fits in an overall tuning methodology. Use the diagnostic tools to gather information about SQL statement Processing. Understand Optimizer behavior. Influence the Optimizer behavior. Influence the physical data model so as to avoid performance problems.
2. Document Detail
Topics Planned Introduction Database Architecture overview Indexing Concepts Optimizer Joins Gathering Statistics Application tracing Interpreting Trace Hints Best Practices
Introduction - Performance Tuning
OVERVIEW PERFORMANCE OPTIMIZATION

6 Ws ? - What ? Optimizing the system resources by Run time, Resource utilization (CPU, Memory, etc ). - Why ? To Speed up computing, Enable system to be at the speed of Business conduct, Optimum hardware usage... - When ? Tuning is an ongoing process starts during system sizing and goes on throughout the application life cycle. - Where ? Database Design, Application design, Memory design, Disk I/O design - Who ? Business Analyst, Application/ Database Designer, Application developer, Database Admin and Operating System Admin. - How? ????
Where the tuning effort should be directed?
Database Design (if it's not too late): - Poor system performance usually results from a poor database design. - One should generally normalize to the 3NF. - When designing, always keep the "data access path" in mind. - Also look at proper data partitioning, aggregation tables for decision support systems, etc.
Application Tuning: - Approx 80% of all Oracle system performance problems are resolved by coding optimal SQL . - Also consider proper scheduling of batch tasks after peak working hours.
Memory Tuning: - Properly size your database buffers (shared_pool, buffer cache, log buffer, etc) by looking at your wait events, buffer hit ratios, system swapping and paging, etc.
Disk I/O Tuning: - Look for frequent disk sorts, full table scans, missing indexes, row chaining, data fragmentation, etc.
Query Execution Architecture
Parsing: Whenever a statement is executed, Oracle follows a methodology to evaluate the statement in terms of syntax, validity of objects being referred , privileges to the user and also checks for identical statements that may have been fired (with the intention of reducing processing overheads). This is known as Parsing. Two Types of Parsing Hard Parsing - All parsing steps to be carried out Soft Parsing -Statement is already parsed and available in memory. Reducing hard parsing will improve the resource utilization and optimize the SQL code. Parsing Process 1. Syntactical check. The query fired is checked for its syntax. 2. Semantic check. Checks on the validity of the objects being referred in the statement and the privileges available to the user firing the statement. This is a data dictionary check. 3. Allocation of private SQL area in the memory for the statement. 4. Generating a parsed representation of the statement and allocating Shared SQL area. This involves finding an optimal execution path for the statement.In point four, Oracle first checks if the same statement is already parsed and existing in the memory. If found, the parsed representation will be picked up and the statement executed immediately (Soft parse). If not found, then the parsed representation is generated and stored in a shared SQL area (Part of shared pool memory in SGA), the statement is then executed (Hard parse). This step involves the optimization of the statement, the one that decides the performance. Query Transformer The input to the query transformer is a parsed query, which is represented by a set of query blocks. The query blocks are nested or interrelated to each other. The form of the query determines how the query blocks are interrelated to each other. The main objective of the query transformer is to determine if it is advantageous to change the form of the query so that it enables generation of a better query plan. Several different query transformation techniques are employed by the query transformer, including: View Merging Predicate Pushing Subquery Unnesting Query Rewrite with Materialized Views OR-expansion
Cost Engine : The cost represents units of work or resource used. The query optimizer uses disk I/O, CPU usage, and memory usage as units of work. So, the cost used by the query optimizer represents an estimate of the number of disk I/Os and the amount of CPU and memory used in performing an operation. The operation can be scanning a table, accessing rows from a table by using an index, joining two tables together, or sorting a row set. The cost of a query plan is the number of work units that are expected to be incurred when the query is executed and its result produced.
Plan Generator: The main function of the plan generator is to try out different possible plans for a given query and pick the one that has the lowest cost. Many different plans are possible because of the various combinations of different access paths, join methods, and join orders that can be used to access and process data in different ways and produce the same result.
COST BASED OPTIMIZER: Two types of Optimizer - Rule Based Optimizer ( From 10g No more) - Cost Based Optimizer The CBO takes an SQL statement and tries to weigh different ways (plan) to execute it. It assigns a cost to each plan and chooses the plan with the smallest cost. The cost for a statement is calculated like: physical IO + logical IO / 1000 + net IO. The most important task for the CBO is to design an execution plan for an SQL statement.
Some Terminology Total Cardinality Number of rows in the table. Computed or Estimated Cardinality Number of rows expected for a given row source. Selectivity A proportional ratio between 0 and 1 which reflects the ratio of returned rows given a predicate. Transitivity Implicit inference of an equality predicate based on other equality predicates. Cost The number of I/Os for a particular row source operation (access method, join method, etc..) Computed or Estimated Cardinality Number of rows expected for a given row source. Selectivity A proportional ratio between 0 and 1 which reflects the ratio of returned rows given a predicate Transitivity Implicit inference of an equality predicate based on other equality predicates. Cost The number of I/Os for a particular row source operation (access method, join method, etc..)
Gathering Statistics
CBO needs some statistics in order to assess the cost of the different access plans. These statistics include values such as - size of tables - size of indexes - number of rows in the tables - number of distinct keys in an index - number of levels in a B* index - average number of blocks for a value - average number of leaf blocks in an index Must use FND_STATS to gather statistics in Apps DO NOT use analyze or DBMS_STATS
In Pfizer this is scheduled in batch (every weekend). You might seen that your SQL may take different path from
Saturday after any major DML/DDL.
STATISTICS GENERATION Table statistics (ALL_TABLES) - Number of rows - Number of blocks - Average row length Column statistics (ALL_TAB_COLUMNS) - Number of distinct values (NDV) in column - Number of nulls in column - Data distribution (histogram) Index statistics (ALL_INDEXES) - Number of leaf blocks - Levels - Clustering factor System statistics - I/O performance and utilization - CPU performance and utilization Table statistics select owner, table_name, num_rows, blocks, avg_row_len , last_analyzed, partitioned, compression from ALL_TABLES where owner ='XXEFSS'; column Statistics select owner, table_name,column_name,num_distinct ,low_value,num_nulls,last_analyzed,histogram from all_TAB_COLUMNS wherE owner ='XXEFSS' AND TABLE_NAME ='XXEFSS Index statistics select OWNER ,INDEX_NAME ,INDEX_TYPE ,TABLE_OWNER ,TABLE_NAME ,UNIQUENESS ,COMPRESSION ,BLEVEL ,LEAF_BLOCKS ,DISTINCT_KEYS from ALL_INDEXES where owner ='XXEFSS'
AND INDEX_NAME LIKE '%XXEFSS%' AND TABLE_NAME ='XXEFSS_AP_INVOICE_A_ALL To get Bind Variables Value SELECT snap_id, dbid, instance_number, sql_id, NAME, POSITION, dup_position, datatype, datatype_string, character_sid, PRECISION, scale, max_length, was_captured, last_captured, value_string FROM dba_hist_sqlbind WHERE sql_id = '4bvjs1m1m4zhb' AND NAME = ':B2'
OPTIMIZER INDEX DETERMINATION CRITERIA
The optimizer uses the following criteria when determining which index to use: - Number of rows in the index (cardinality). - Number of distinct keys. These define the selectivity of the index. - Level or height of the index. This indicates how deeply the data probe must search in order to find the data. - Number of leaf blocks in the index. This is the number of I/Os needed to find the desired rows of data. - Clustering factor (CF). This is the collocation amount of the index block relative to data blocks. The higher the CF, the less likely the optimizer is to select this index. - Average leaf blocks for each key (ALFBKEY). Average number of leaf blocks in which each distinct value in the index appears, rounded to the nearest integer. For indexes that enforce UNIQUE and PRIMARY KEY constraints, this value is always one.
INDEXING CONCEPTS
BASICS INDEXES Oracle has two options when accessing data from the tables By reading every row full table scan By reading a single row by Row id. Indexes : An index is a performance-tuning method of allowing faster retrieval of records. An index creates an entry for each value that appears in the indexed columns. Building indexes on the restrictive columns is the first step towards better system performance. Bad indexes (including the wrong columns) can cause as much trouble as forgetting to use indexes on the correct columns. Indexes helps performance depends based on selectivity & data distributions on the block. When data scattered on large number of blocks go for full table scan. Oracle uses multi block read when going for full table scan. Various options available in Oracle, Partitions, parallel DML, Parallel query operations, and larger I/O using the db_file_multiblock_read_count. So balance point should be achieved between the full table scan and the Index.
Index storage techniques - B-Tree Indexes 1. Normal indexes 2. Concatenated indexes (multiple columns combined into a single index) 3. Function based ( Based on some functions e.g. Upper, truncate) 4. Descending - Bitmap Indexes * Are ideal for decision making system and Data warehouses. Should not be used transaction processing system. Use bitmap indexes for columns with a low cardinality (distinct value).
B-TREE INDEXES
Default index type. Can be single/composite Can have up to 32 columns. Value of the indexed columns plus row id stored When creating a Primary key or unique constraints, Oracle automatically creates unique/composite indexes.
Careful when selecting the order of the columns Make sure the leading columns is the most used in WHERE clause and most selective column of the set Index skip scan Introduced in 9i. Optimizer chooses the index even the leading index not exists in the WHERE clause. Fast full Scan - If all the index columns in the SELECT clause it will use the index instead of table.
Suppressing Index: Most common mistake among inexperienced developers. Few common mistakes 1. Using the not equal operators <> ,!= 2. Using the IS NULL or IS NOT NULL 3. Functions 4. Mismatched data types. Even Explain Plan will not help (only knowledge can help).
Dropping Index Analyze the poor index before drop (check for suppressing index). To get Index Details: SELECT table_name, index_name, column_name , column_position FROM user_ind_columns ORDER BY table_name,index_name,column_position;
OPTIMIZER JOINS
TABLE JOINS When More then one table, we need of Join. Types of Join 1. Nested Loops 2. Sort Merge 3. Hash Join Query Execution:
JOINS NESTED LOOP / SORT MERGE
Nested Loop Join Oracle reads the first row from the first row source ( table 1) and then checks the second row source (table 2) for matches. Nested loop join method is the fastest methods of receiving the first records back from a join. When to use Driving source should be small and joined column of the inner row source are uniquely indexed or have a highly selective non-unique index. Ideal for query screens where an end user can read the first few records retrieved while the rest are being fetched. Sort Merge Oracle sorts the first row source by its join columns, sort the second row source by its join columns, and then merges the sorted row sources together. As matches are found they are put into the result set. Effective when lack of data selectivity or useful indexes render a NESTED LOOPS join inefficient, OR when both the row sources are large. Can only used for equijoins.
JOINS - HASH JOIN HASH JOIN Usual choice when appropriate memory set up to accommodate. Optimizer uses the smaller of two tables or data sources to build a hash table on the join key in memory. The optimizer then scans the larger table, probing the hash table to find the joined rows PGA_AGGREGATE_TARGET parameter should set to enough value. Works only for equijoin
Application Tracing and Identifying High Load SQL
APPLICATION TRACING Explain Plan: - An execution plan defines how Oracle finds or writes the data. - General Syntax : explain plan [set statement_id = ] for sql-statement; -E.g. EXPLAIN PLAN SET STATEMENT_ID ='TEST' FOR SELECT * FROM PO_HEADERS_ALL - Inserts the plan to PLAN_TABLE. - SQL NOTexecuted. - It is a prediction, may not be always correct. - Read from innermost to outmost. - In Toad Click CTL+ E.
TOAD:
While a PLAN_TABLE table is automatically set up for each user, you can use the SQL script utlxplan.sql to manually create a local PLAN_TABLE in your
schema. PLAN_TABLE is automatically created as a global temporary table to hold the output of an EXPLAIN PLAN statement for all users. PLAN_TABLE is the default sample output table into which the EXPLAIN PLAN statement inserts rows describing execution plans.
APPLICATION TRACING-SQL*PLUS
SQL* TRACE : - Can automatically get a report on the execution path used by the SQL optimizer and the statement execution statistics. - The report is generated after successful SQL DML (that is, SELECT, DELETE, UPDATE and INSERT) statements. It is useful for monitoring and tuning the performance of these statements.
Recursive calls Number of recursive calls generated at both the user and system level. Oracle maintains tables used for internal processing. When Oracle needs to make a change to these tables, it internally generates an internal SQL statement, which in turn generates a recursive call. Sometimes, in order to execute a SQL statement issued by a user, Oracle must issue additional statements. Such statements are called recursive calls or recursive SQL statements. For example, if you insert a row into a table that does not have enough space to hold that row, then Oracle makes recursive calls to allocate the space dynamically. Recursive calls are also generated when data dictionary information is not available in the data dictionary cache and must be retrieved from disk. DB block gets Number of times a CURRENT block was requested. Consistent gets Number of times a consistent read was requested for a block. Physical reads Total number of data blocks read from disk. This number equals the value of "physical reads direct" plus all reads into buffer cache. Redo size Total amount of redo generated in bytes. Bytes sent via SQL*Net to client Total number of bytes sent to the client from the foreground processes. Bytes received via SQL*Net from client
Total number of bytes received from the client over Oracle Net. SQL*Net roundtrips to/from client Total number of Oracle Net messages sent to and received from the client. Sorts (memory) Number of sort operations that were performed completely in memory and did not require any disk writes. Sorts (disk) Number of sort operations that required at least one disk write. Rows processed Number of rows processed during the operation.
APPLICATION TRACING INTERPRETING AUTO TRACE

DB block gets
Number of times a CURRENT block was requested.

Consistent gets
Number of times a consistent read was requested for a block .

Physical reads
Total number of data blocks read from disk. This number equals the value of "physical reads direct" plus all reads into buffer cache.
Redo size
Total amount of redo generated in bytes.

Sorts (memory)
Number of sort operations that were performed completely in memory and did not require any disk writes.
Sorts (disk)
Number of sort operations that required at least one disk write.

Rows processed
Number of rows processed during the operation.
APPLICATION TRACING SQL TRACE

TO Set at the Instance Level - SQL_TRACE = TRUE - TIMED_STATISTICS = TRUE MAX_DUMP_FILE_SIZE should be set to unlimited or to a reasonable value to avoid trace truncation To Enable at session level - SQL> ALTER SESSION SET SQL_TRACE = TRUE; To Disable at session level
- SQL> ALTER SESSION SET SQL_TRACE = FALSE * Contains: - Actual execution plan - Performance statistics
TRACE FORM
TRACE FRAMEWORK
CONCURRENT MANAGER TRACING
DISCOVERER TRACING DESKTOP 1. Connect to Discoverer as the user who will run the report. 2. Identify the Discoverer session being used either by logging as the system user and finding the session using: - select * from Gv$session where module like 'Disco%; 3. Note down the sid and #serial numbers from GV$SESSION; 4. Run the following command: - exec dbms_system.set_sql_trace_in_session(<sid>,<serial>, true) 5. Run the Discoverer report to generate the trace and then logout to disconnect the session.
6. Identify the .trc file generated in the udump directory on the database server. 7. Get the process id using the session id from GV$Process. 8. Identify the Trace file with the process id. DISCOVERER TRACING VIEWER & PLUS 1. Only App.Server Admin can do. 2. Change a preference for the specific user. 3. Navigate to <ORACLE_HOME>/bin directory where ORACLE_HOME is the location of the middle tier Application Server software. 4. On UNIX execute the <ORACLE_HOME>/discoverer/discwb.sh script . 5. Type the following using the syntax: dis51pr -user <user> -setpref Database SQLTrace 1 where <user> is the name of the user, followed by the @ symbol, followed by the name of the database (e.g. jchan@salesdb). 6. Ensure that this entry is re-set to zero once testing is complete in order to turn SQL tracing back off.
IMPORTANT VIEWS Few important/Useful Views: GV$SESSION GV$PROCESS GV$SQL GV$SQL_PLAN GV$SESSION_WAIT GV$SQLAREA GV$LOCK GV$SQL_BIND_CAPTURE OEM :
URL: http://*******:4889/em/console/logon/logon AWR Reports
TKPROF What is TKPROF? TKPROF accepts as input a trace file produced by the SQL Trace facility, and it produces a formatted output file. Interpreting TKPROF
TFPROF
SYNTAX: tkprof tracefile outputfile [explain= ] [table= ] [print= ] [insert= ] [sys= ] [sort= ]
tkprof Ensure you have the right version !! tkprof output file contents / structure Header Version Timestamp Column Heading description Body One entry for each distinct SQL Resource Consumption Details Execution Plan Optional Explain Plan Optional wait information Summary Statistics Recursive Statements Non Recursive Statements Optional wait summary
Interpreting the output file SQL statement * Statistics - Parse, execute, and fetch counts - CPU and elapsed times Physical reads and logical reads Execution Plan (actual execution plan) Optional Explain Plan (theoretical) Number of rows processed Misses on the library cache (Hard/Soft parse) Interpreting Do the totals on the bottom of the trace reconcile with your execution experience. - Missing time may mean incomplete trace - Have we traced / TKPROFd the right thing? Sort options move the statements to focus on to top of output Tuning effort starts from here: - Is there a condition on a column in the where clause that is not indexed? Would an index help in this case? - Are indexes being disabled?
Interpreting watch out Read consistency Trap: Sometimes other transactions hold uncommitted changes against a table.This increases the number of blocks visits because additional blocks must be constructed and visited for read consistency. TimeTrap: if a particular DML statement shows high timing statistics, the explanation may be intereference from another transaction holding (shared) locks on the table. Look at the Waits. Trigger Trap: the resources reported for a statement include those for all of the SQL issued while the statement was being processed. Therefore, they include any resources used within a trigger, along with the resources used by another recursive SQL.
HINTS
HINTS Why using hints? - Oracle comes with an optimizer that promises to optimize a query's execution plan. When this optimizer is really doing a good job, no hints should be required at all. - Sometimes, however, the characteristics of the data in the database are changing rapidly, so that the optimizer (or more accurately, its statistics) are out of date. In this case, a hint could help. Some Points If you find you are using the same hints again and again fix the design rather then particular statement. Incorrectly specified hint, becomes comment and ignored, If you want all the union queries to use the hint, need to specify in each query Multiple hints are separate with a space. Specifying multiple hints those conflicts with each other causes the query to use none of the hints that are conflicting. If an alias is used, alias must be used in the hint or the hint will not work. Top Hints INDEX ORDERED PARELLEL FIRST_ROW FULL LEADING USE_NL APPEND USE_HASH First_ROWS hint: FIRST_ROW hint causes the optimizer to choose a path that retrieves the first row (or a specified number of rows) of a query fastest. Syntax: select /*+ FIRST_ROWS(n) */ columns1 . All_ROWS Hint: ALL_ROWS hint causes the optimizer to choose a path that will retrieve all the rows of a query fastest, at the cost of retrieving one single row slower. Syntax: select /* + ALL_ROWS */ columns1 . FULL Hint: Can use it to force a full table scan when a large portion of the table is being queried. Cost of retrieving the index and table may be larger then full scan the table. FULL hint may also lead to better performance, which attributable to causing a change in the driving table of the query and not the actual full table scan.
Syntax:
select /* + FULL(table) */ columns1
Index Hint Index hint causes the optimizer to choose the index specified in the hint. Multiple indexes for a single table can be specified. But better to specify the most specific one. If multiple specifies oracle choose the best among Index hint without the specified index also choose the best index or indexes for the query Syntax : Select /*+ INDEX ([table.]column1 [[table2.]column2]) */ columns1 .. NO_INDEX Hint : NO_INDEX hint disallows the optimizer from using a specific index. Great hint for tuning queries with multiple indexes. NO_INDEX hint is specified and no index specifies full scan will be performed. Think this hint before dropping any indexes. Syntax: select /* + NO_INDEX(table index1 , index2 ) columns1 INDEX_JOIN Hint: INDEX_JOIN hint merges separate indexes from a single table together so that only the indexes need to be accessed. INDEX_join hint not only allows to access only indexes on a table, which is a scan of fewer total blocks, but it is also five times faster then using an index and scanning the table by ROWID. Syntax: select /* + INDEX_JOIN (table index1, index2) */ column1 INDEX_COMBINE Hint: INDEX_COMBINE hint is used to specify multiple bitmap indexes when you want the optimizer to use all indexes that you specify. You can also specify for single indexes (but less preferred). For B-Tree indexes, use the INDEX hint instead of this one. Syntax: select /* + INDEX_COMBINE (table index1, index2 ) */ column1 INDEX_ASC Hint: INDEX_ASC does the exact of INDEX hint. But Oracle does not guarantee that INDEX hint will work as same in the future so we
can use this to confirm. Syntax: select /* + INDEX_ASC (table index1, indez2 ...) */ column1... INDEX_DESC Hint: INDEX_DESC hint causes indexes to be scanned in descending order. Hint is overridden when the query has multiple tables Does not work for bitmap indexes or for descending indexes Does not work across partition index boundaries but performs a descending index scan of each partition. Syntax: select /* + INDEX_DESC (table index1, index2 ) column1, INDEX_FFS Hint: Indicate the Fast full scan of the index should be performed. Only access the index and not the table Should only used when all the needed information available in the index. Give great performance improvement when there is a large number of columns in the table. Syntax: select /* + INDEX_FFS (table index) */ column1 ORDERED Hint: This is one of the powerful hint available. ORDERED hint guarantee the table access in the same order as in FROM clause (first table is the driving table) When this hint is not used oracle can internally change the driving table. Version of oracle, index on table, table which has been analyzed also make the optimizer work differently. Syntax: select /* + ORDERED*/ COLUMN1
LEADING Hint:
To guarantee only the first driving table we can use the LEADING hint. Remaining table will be taken care by the optimizer. More then one table with this hint will ignored ORDERED hint overrides LEADING hint. Syntax: select /* + LEADING (table1) */ column1,
USE_MERGE Hint:
USE_MERGE hint tells optimizer to use MERGE JOIN when performing join. May useful when queries perform set operations on large numbers of rows. In a join of three or more tables, the USE_MERGE hint causes the tables(s) specified in the hint to be sort-merge joined with the resulting row set from a join of the other tables in the join.
Retrieves rows that match the condition from each table and the merges them together. Syntax: select /* + USE_MERGE (table) */ column1
USE_NL Hint: USE_NL (use Nested loop) is the fastest way to retrieve single row. Cause the table to process the rows using nesting loops. First match rows from one table will be scanned in the second table. NO_USE_NL hint, instructs the optimizer not to use the nested loop join. Syntax: select /* USE_NL(table1, table2) */ column1, USE_HASH Hint: USE_HASH hint is usually the fastest way to join many rows together from multiple tables if you have adequate memory for this operation. Similar to USE_NL method. Difference here is second table will be is put in memory. USE_HASH hint usually provides the best response time for larger. Syntax: select /*+ USE_HASH (table1,table2 ) */ column1 PUSH_SUBQ Hint: Use this hint when sub query return a relative small number of rows (quickly); those rows can be subsequently used limits the rows in the outer query. Hint cannot be used when the query uses merge join and cannot be used with remote tables. Syntax: select /* + PUSH_SUBQ */ column1 PARALLEL Hint: PARALLEL hint cause the optimizer to break a query into pieces and process each piece with a different process. Degree of parallelism is applied to each parallelizable operation of a statement. Hint can be applied to INSERT, UPDATE, DELETE & SELECT. Commit should be issued immediately). Default degree of parallelism will be from the table creation. To use this hint table should be created with PARALLEL clause. Syntax:select /* + PARALLEL (table, DEGREE) */ APPEND Hint: APPEND hint improves the performance of INSERT. But with the potential cost in terms
of space. This hint does not check if there is a space in the current block, but append to new blocks. If you never delete rows in a table, you can use this hint. When using the PARALLEL hint this defaults. Can override by NO_APPEND hint. Syntax: insert /* + APPEND */
CACHE Hint: CACHE hint causes a full table scans to be cached in to memory, so future user can access from the memory instead of disk. Suitable only for small tables. To avoid use NOCACHE hint. Syntax: select /* CACHE(table) */ column1
HINTS SUMMARY
Reason for my hint not working Hint syntax is incorrect. Table's not analyzed. Conflict with another hint. Hint requires system parameter to be set for it work. Table name was aliased but you have used table name. You dont understand the hint properly. Indexes get suppressed.
BEST PRACTICES
BEST PRACTICES Do performance test at the instance which have almost similar volume of data. Consider Purging/ Archiving Creating a new index might have impact on other statement Avoid creating two indexes with same leading columns. Do Not join views Reconsider while writing LOV, Parameter queries.( I.E. do not get all the system values for a LOV). Various operators used directly affect how fast a query is run. Here are the key operators used in the WHERE clause, ordered by their performance. Those operators at the top will produce results faster than those listed at the bottom. = >, >=, <, <= LIKE <> If you use LIKE in your WHERE clause, try to use one or more leading character in the clause, if at all possible. Have a Look at the attached Excel.
3. Version Change Log

Version 1.00 1.01 Modified in --04.Mar.2010 Responsible Unknown Pratik Deshmukh Modification Initial Document Document Updated to ARTL standards

ALLOT019D - Performance Optimization

Transféré par

Informations du document

Description originale:

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

ALLOT019D - Performance Optimization

Transféré par

Droits d'auteur :

Formats disponibles

Documentation Header

Document Description Responsible ALL.OT.019D Oracle Performance Optimization Version 1.01

Last Change Description

Document Updated to ARTL standards

Introduction - Performance Tuning

OVERVIEW PERFORMANCE OPTIMIZATION

Where the tuning effort should be directed?

Query Execution Architecture

OPTIMIZER INDEX DETERMINATION CRITERIA

JOINS NESTED LOOP / SORT MERGE

Application Tracing and Identifying High Load SQL

APPLICATION TRACING INTERPRETING AUTO TRACE

Number of times a CURRENT block was requested.

Number of times a consistent read was requested for a block .

Total amount of redo generated in bytes.

Number of sort operations that required at least one disk write.

Number of rows processed during the operation.

APPLICATION TRACING SQL TRACE

CONCURRENT MANAGER TRACING

URL: http://*******:4889/em/console/logon/logon AWR Reports

3. Version Change Log

Vous aimerez peut-être aussi