Tuning Session

8/8/2019 Tuning Session

1/34

Technology Focus - performance fine tuning in Oracle 1

IntroductionIntroduction

Performance tuning is an art which has lots of section like the below

Identifying which query takes much time, by the use of trace, TKPROF and execution plans atvarious load scenarios. Tuning the identified time taking query based on the existing scenario and with the knowledgebase. Tuning the DB parameters and hardware requirements.Monitoring the tuned query for quite some time at various load scenarios. Giving different solutions according to the load levels.

Scope:

Now we are going to see just the part Tuning the identified time taking query, based on theexisting scenario and with the knowledge base. This will say the donts in a query or PL/SQLcode and then it will explain you how to tune them.

Result after this session:

This session will help you to understand the oracle basic architecture anddo some basic tuningwhich can improve your query and PL/SQL code.


2/34


Oracle ArchitectureOracle Architecture

Instance

Library

Cache

Data

Dictionary

Cache

Shared Pool

SGA

Database Buffer

Cache

Redo Log

Buffer

Java Pool Large Pool

PMON SMON DBWR LGWR CKPT Others

Memory

Structures

Back-Ground

Processes


3/34



A system global area (SGA) is a group of shared memory structures that contain data andcontrol information for one Oracle database instance. If multiple users are concurrently

connected to the same instance, then the data in the instance's SGA is shared among the users.Consequently, the SGA is sometimes called the shared global area

The Oracle shared pool contains the following components:* The library cache* The dictionary cache* Control Structures

Oracle's library cache, which is responsible for collecting, parsing, interpreting, and executing

all of the SQL statements that go against the Oracle database. Hence, the shared pool is a keycomponent, so it's necessary for the Oracle database administrator to check for shared poolcontention.

Oracle's parsing algorithm ensures that identical SQL statements do not have to be parsed eachtime they're executed.

Control Structures - Common control structure information, for example, lock information

The dictionary cache stores metadata (data about your tables and indexes) and its alsoknown as the row cache. It is used to cache data dictionary related information in RAM for quickaccess.


4/34



Database Buffer cache:

The buffer cache is part of the SGA. It holds copies ofdata blocks so as they can be accessedquicker by oracle than by reading them offdisk. The purpose of the buffer cache is to minimizephysical io. When a block is read by Oracle, it places this block into the buffer cache, becausethere is a chance that this block is needed again. Reading a block from the buffer cache is lesscostly (in terms of time) than reading it from the disk.

Redo Log Buffer:

Each Oracle database has a redo log. This redo log records all changes made in datafiles. This

is to restore data back when failure happens. The redo log makes it possible to replay SQLstatements. Before Oracle changes data in a datafile it writes these changes to the redo log. Ifsomething happens to one of the datafiles, a backed up datafile can be restored and the redo,that was written since, replied, which brings the datafile to the state it had before it becameunavailable

Large Pool:

Oracle Large Pool is an optional memory component of the oracle database SGA. This area is

used for providing large memory allocations in many situations that arise during the operations ofan oracle database instance.


5/34


How your data get stored in databaseHow your data get stored in database

Actually the data is getting stored in Segments which Is made up of one or more Extents. EachExtent is made up of one or more data blocks.

Each and every table will be available in a single segment.

The data may or may not be available in consecutive blocks.


6/34


Basics Of an IndexBasics Of an Index

Basics of Index:

Indexes are optional structures associated with tables. Indexes can be created to increase theperformance ofdata retrieval. Just as the index in a manual helps you quickly locate specificinformation, an Oracle index provides an access path to table data.

Indexes are useful when applications frequently query a table for a range of rows (for example,all employees with a salary greater than 1000 dollars) or a specific row. Indexes are created onone or more columns of a table.Changes to table data (such as adding new rows, updating rows,ordeleting rows) are automatically incorporated into all relevant indexes. Indexes are the primarymeans of reducing disk I/O when properly used. However, the presence of many indexes on a

table decreases the performance of updates, deletes, and inserts, because Oracle must alsoupdate the indexes associated with the table.

An index is merely a fast access path to the data. It affects only the speed of execution. Given adata value that has been indexed, the index points directly to the location of the rows containingthat value. Indexes are logically and physically independent of the data in the associated table.You can create ordrop an index at any time without affecting the base tables or other indexes.

Oracle RDBMS accesss table data in one of the two ways

Full table scanUsing Indexes

Using Indexes is always preferrable to using a full table scan as it allows more immediate accessto just the desired rows.Full table scan is preferable when you know that more than about 25% of the records in thequeried tables will be selected;


7/34


Basics Of an IndexBasics Of an Index

Oracle RDBMS accesss table data in one of the two ways

Full table scan

Using Indexes

Using Indexes is always preferrable to using a full table scan as it allows more immediate accessto just the desired rows.Full table scan is preferable when you know that more than about 25% of the records in thequeried tables will be selected;

Index segment:

Each index has an index segment that stores all of its data.

Some basic types of index are

B-tree indexesBitmap indexesFunction-BasedIndexes


8/34


BB--Tree Index StructureTree Index Structure

What Is ROWID?

ROWID is an internal number Oracle uses to uniquely identify each row. NOT a primary key! Isthe actual location of a row on a disk. Very efficient for retrieval. Format specifies block, row, andfile (and object in 8). This is called pseudo-column since can be selected

Oracle 7: BBBBBBB.RRRR.FFFFF

Oracle 8: OOOOOO.FFF.BBBBBB.RRR

As given in the figure - below are the steps for searching Patrick:

In the root block, Rh is the smallest key >= Peter. Follow the link before Rh to branch block (N, P, Ph). In this block, Ph is the smallest key >= Peter. Follow the link before Ph to leaf block (Pablo, Patrick, Paula, Peter). In this block, search for key Peter = Peter. Found Peter = Peter, return (KEY, ROWID).


9/34


Bitmap Index StructureBitmap Index Structure

It maintain sparse matrix to handle the indexing.

Bitmap index

Fi ure 4-2. in Oracle Essentials 2001 . Greenwald et.al. OReill . 95

partno color size

12

34

GREENRED

REDBLUE

MEDMEDSMALLLARGE

color = BLUE

color = RED

color = GREEN

0 0 0 1

0 1 1 0

1 0 0 0

Parts table

Bitmapped index on color

Part number 1 2 3 4


10/34


What happens when you run a QueryWhat happens when you run a Query

This is what the Oracle SQL engine does in a nutshell:1. Create cursor

A cursor exists for every statement run. If you need programmatic control you can use anexplicit cursor that you define. Otherwise, an implicit cursor is built for you.

2. Parse statement

A lot of complicated stuff is going on. The goal is to get out of this step as quickly as possible.The quickest way to get out is to submit a DML statement that has already been submitted (asoft parse); otherwise Oracle will have to go thru the whole parsing process (a hard parse).

Here are the steps that happen during (hard) parsing:

-Translate the statement and verify the syntax is valid-check the data dictionary and make sure the referenced objects exist-get parsing locks on all required objects so the definitions don't change-check and make sure the executing user has privileges to the objects-figure out the best way (execution plan) to perform the request-load all this into a shared SQL area so others won't have to get this far-(route distributed statements)

3. Describeresults (Queries only)

4. Bindvariables

This is where your variables (like department_id) get attached. PLEASE use bind variables


11/34


What happens when you run a QueryWhat happens when you run a Query

5. Parallelize statement (optional)

If you want multiple processes to work on your statement, this is where Oracle splits it up foryou (more...uh...later)

6. Run

This is when Oracle takes a big breath and executes your statement. If you are running aDELETE or UPDATE statement, those rows will be locked fordata integrity until a commit orrollback.

7. Fetch rows (Queries only)

If you ran a SELECT, this is the step that gets your rows and sends them back to you(ordered if you requested them to be).

8. Close cursor

"The final stage of processing a SQL statement is closing the cursor."


12/34


Explain PlanExplain PlanAn Explain Plan is a tool that you can use to have Oracle explain to you how it plans onexecuting your query. This is useful in tuning queries to the database to get them to perform

better. Once you know how Oracle plans on executing your query, you can change yourenvironment to run the query faster.

Before you can use the EXPLAIN PLAN command, you need to have a PLAN_TABLE installed.This can be done by simply running the $ORACLE_HOME/rdbms/admin/utlxplan.sql script inyour schema. It creates the table for you. After you have the PLAN_TABLE created, you issue anEXPLAIN PLAN for the query you are interested in tuning. The command is of the form:

Example:

EXPLAIN PLAN FORselect min(actt_sk) from ed_actv_typ where actt_cd like '6%'/


13/34


HintsHintsWhy using hints

It is a perfect valid question to ask why hints should be used. Oracle comes with an optimizerthat promises to optimize a query's execution plan. When this optimizer is really doing a goodjob, no hints should be required at all. Sometimes, however, the characteristics of the data in thedatabase are changing rapidly, so that the optimizer (or more accuratly, its statistics) are out ofdate. In this case, a hint could help. It must also be noted, that Oracle allows to lock the statisticswhen they look ideal which should make the hints meaningless again.

All hints except /*+ rule */ cause the CBO to be used. Therefore, it is good practise to analyzethe underlying tables if hints are used (or the query is fully hinted).

There are many hints available. Some of them areFIRST_ROWSCHOOSERULEINDEXINDEX_FFSUSE_HASHUSE_NLPARALLELAPPENDORDERED


14/34


Performance tuning recommendationsPerformance tuning recommendationsAnalyze Statement

The ANALYZE statement can be used to gather statistics for a specific table, index or cluster.The statistics can be computed exactly, or estimated based on a specific number of rows, or apercentage of rows. If a table has not been analyzed, the cost-based optimizer can use only rule-based logic to select the best access path.

If the table has proper statistics then the CBO will decide easily that which is the optimal path totravel and retrieve the data, which will improve the performance.

ANALYZE TABLE employees COMPUTE STATISTICS;

AN

ALYZEIN

DEX employees_pk COMPUTE STATIST

ICS

;

ANALYZE TABLE employees ESTIMATE STATISTICS SAMPLE 100 ROWS;ANALYZE TABLE employees ESTIMATE STATISTICS SAMPLE 15 PERCENT;

Set OPTIMIZER_MODE = CHOOSE

By choosing this mode instead of either RULE / COST, DB will decide on the situation.


15/34


Performance tuning recommendationsPerformance tuning recommendationsIncorrect Driving Table

If the table driving a join is not optimal, there can be a significant increase in the amount of timerequired to execute a query. Consider the following example:SELECT COUNT(*) FROM acct a, trans bWHERE b.cost_center = 'MASS AND a.acct_name = 'MGA AND a.acct_name = b.acct_name;

In this example, if ACCT_NAME represents a unique key index and COST_CENTER representsa single column non-unique index, the unique key index would make the ACCT table the drivingtable.

If both COST_CENTER and ACCT_NAME were single column, non-unique indexes, the rule-

based optimizer would select the TRANS table as the driving table, because it is listed last in theFROM clause. Having the TRANS table as the driving table would likely mean a longer responsetime for a query, because there is usually only one ACCT row for a selected account name butthere are likely to be many transactions for a given cost center.

With the rule-based optimizer, if the index rankings are identical for both tables, Oracle simplyexecutes the statement in the order in which the tables are parsed. Because the parserprocesses table names from right to left, the table name that is specified last (e.g., DEPT in theexample above) is actually the first table processed (the driving table).

The response time following the re-ordering of the tables in the FROM clause is as follows:SELECT COUNT(*) FROM trans b, acct aWHERE b.cost_center= 'MASS AND a.acct_name = 'MGA AND a.acct_name = b.acct_name;

It is important that the table that is listed last in the FROM clause is going to return the fewestnumber of rows. There is also potential to adjust your indexing to force the driving table. Forexample, you may be able to make the COST_CENTER index a concatenated index, joined withanother column that is frequently used in SQL enquires with the column. This will avoid it ranking

so highly when joins take place.


16/34


Performance tuning recommendationsPerformance tuning recommendationsIncorrect Index

WHERE clauses often provide the rule-based optimizer with a number of indexes that it couldutilize. The rule-based optimizer is totally unaware of how many rows each index will be requiredto scan and the potential impact on the response time. A poor index selection will provide aresponse time much greater than it would be if a more effective index was selected.

The rule-based optimizer has simple rules for selecting which index to use. These rules andscenarios are described earlier in the various "What the RBO rules don't tell you" sections.Let's consider an example.

An ERP package has been developed in a generic fashion to allow a site to use columns for

reporting purposes in any way its users please. There is a column called BUSINESS_UNIT thathas a single-column index on it. Most sites have hundreds of business units. Other sites haveonly one business unit.

Our JOURNAL table has an index on (BUSINESS_UNIT), and another on

(BUSINESS_UNIT, ACCOUNT, JOURNAL_DATE). The WHERE clause of a query is as follows:WHERE business_unit ='A203'AND account = 801919 AND journal_date between '01-DEC-2001' and '31-DEC-2001

The single-column index will be used in preference to the three-column index, despite the factthat the three-column index returns the result in a fraction of the time of the single-column index.This is because all columns in the single-column index are used in the query. In such a situation,the only options open to us are to drop the index or use the cost-based optimizer. If you're notusing packaged software, you may also be able to use hints.


17/34


Performance tuning recommendationsPerformance tuning recommendationsIncorrect Driving Index

The way you specify conditions in the WHERE clause(s) of your SELECT statements has amajor impact on the performance of your SQL, because the order in which you specify conditionsimpacts the indexes the optimizer choose to use.If two index rankings are equal -- for example, two single-column indexes both have theircolumns in the WHERE clause -- Oracle will merge the indexes. The merge (AND-EQUAL) orderhas the potential to have a significant impact on runtime. If the index that drives the query returnsmore rowsthan the other index, query performance will be suboptimal. The effect is very similar to that fromthe ordering of tables in the FROM clause. Consider the following example:SELECT COUNT(*) FROM trans

WHERE cost_center = 'MASS AND bmark_id = 9;Response Time = 4.255 secondsThe index that has the column that is listed first in the WHERE CLAUSE will drive the query. Inthis statement, the indexed entries for COST_CENTER = `MASS' will return significantly morerows than those for BMARK_ID=9, which will return at most only one or two rows.The following query reverses the order of the conditions in the WHERE clause, resulting in amuch faster execution time.SELECT COUNT(*) FROM transWHERE bmark_id = 9 AND cost_center = 'MASS';


18/34


Performance tuning recommendationsPerformance tuning recommendations

WHEREEXISTSsub-queries can be better than join if can you reduce drastically the number

of records in driver query. Otherwise, join is better.

WHERE EXISTS can be better than join when driving from parent records and want to makesure that at least on child exists. Optimizer knows to bail out as soon as finds one record. Joinwould get all records and then distinct them!

Query before tuning:

SELECT *FROM suppliers, ordersWHERE suppliers.supplier_id = orders.supplier_id;

Query after tuning:

SELECT *FROM suppliersWHERE EXISTS(select *from orders

where suppliers.supplier_id = orders.supplier_id);

Exists returns TRUE whenever the subquery gives a row count > 1.

In this case once the where clause gets the true condition from EXISTS, it will select all rowsfrom the table.


19/34



Consider NOTEXISTS instead of NOTIN.

When using N

OT IN

, the query performs nested full table scans, whereas for N

OT EXISTS,query can use an index within the sub-query.

Avoid NOT in or NOT= on indexed columns. They prevent the optimizer from using indexes.

Use where amount > 0 instead of where amount! = 0.

Avoid writing where project category is not null. Nulls can prevent the optimizer from using an

index.

Consider usingIN or UNION in place of ORon indexed columns. ORs on indexed columns

causes the optimizer to perform a full table scan.

Avoid calculations on indexed columns. Write WHEREapproved_amt > 26000/3 instead ofWHEREapproved_amt/3 > 26000.

Avoid this: SUBSTR(haou.attribute1,1,LENGTH(':p_otc')) = :p_otc). Consider this:

WHERE haou.attribute1 like :p_otc||'%'

Talk to your DBA. If you think that a column used in a WHEREclause should have an index,

don't assume that an index was defined. Check and talk to your DBA if you don't find any.

Consider replacing outer joins on indexed columns with UNIONs. A nested loop outer takes

more time than a nested loop unioned with another table access by index.

Consider adding small frequently accessed columns (not frequently updated) to an existing

index. This will enable some queries to work only with the index, not the table.

If a query is going to read most of the records in a table (more than 60%), use a full table

scan.

Try to group multiple sub queries into one.


20/34



Consider NOTEXISTS instead of NOTIN.

When using N

OT IN

, the query performs nested full table scans, whereas for N

OT EXISTS,query can use an index within the sub-query.

Avoid NOT in or NOT= on indexed columns. They prevent the optimizer from using indexes.

Use where amount > 0 instead of where amount! = 0.

Avoid writing where project category is not null. Nulls can prevent the optimizer from using an

index.

Consider usingIN or UNION in place of ORon indexed columns. ORs on indexed columns

causes the optimizer to perform a full table scan.

Avoid calculations on indexed columns. Write WHEREapproved_amt > 26000/3 instead ofWHEREapproved_amt/3 > 26000.

Avoid this: SUBSTR(haou.attribute1,1,LENGTH(':p_otc')) = :p_otc). Consider this:

WHERE haou.attribute1 like :p_otc||'%'

Talk to your DBA. If you think that a column used in a WHEREclause should have an index,

don't assume that an index was defined. Check and talk to your DBA if you don't find any.

Consider replacing outer joins on indexed columns with UNIONs. A nested loop outer takes

more time than a nested loop unioned with another table access by index.

Consider adding small frequently accessed columns (not frequently updated) to an existing

index. This will enable some queries to work only with the index, not the table.

If a query is going to read most of the records in a table (more than 60%), use a full table

scan.

Try to group multiple sub queries into one.


21/34



Order of the tables in Joins:

If you specify 2 or more tables in the FROM clause of a SELECT statement, then Oracle parserwill process the tables from right to left, so the table name you specify last will be processed first.In this case you have to choose one table as driving table.Always choose the table with less number of records as the driving table.

Name the Columns in a Query:

There are three good reasons why it is better to name the columns in a query rather than to use"select * from ...".

1. Network traffic is reduced. This can have a significant impact on performance if the table has alarge number of columns, or the table has a long or long raw column (both of which can be up to2 GB in length). These types of columns will take a long time to transfer over the network and sothey should not be fetched from the database unless they are specifically required.2. The code is easier to understand.3. It could save the need for changes in the future. If any columns is added to or removed fromthe base table/view, then select * statement can produce wrong results set and statement mayfail.

Use table alias:

Always use table alias and prefix all column names with the aliases when you are using morethan one table.

Never compare NULL to anything else:

All expressions return NULL if one of the operands is NULL. This is applicable for all operatorsexcept Concatenation operator (||).


22/34



Use Bind Variables:

It is also better to use bind variables in queries. That way the query becomes generic andtherefore re-usable. For example, instead of writing a query like -

SELECT ename, sal FROM emp WHERE deptno = 20;

Change it to -

SELECT ename, sal FROM emp WHERE deptno = :deptno;

The first query can be re-used fordeptno number 20 only, whereas the second query can bereused for any otherdeptno also.

Use EXISTS instead of DISTINCT:

Use EXISTS in place of DISTINCT if you want the result set to contain distinct values whilejoining tables.

For example:

SELECT DISTINCT d.deptno, d.dname FROM dept d, emp e WHERE d.deptno = e.deptno;

The following SQL statement is a better alternative.

SELECT d.deptno, d.dname FROM dept d WHERE EXISTS(SELECT e.deptno FROM emp e WHERE d.deptno = e.deptno);


23/34



Any computation of constants is performed only once when the statement is optimized ratherthan each time the statement is executed. Consider these conditions that test for salaries greater

than $2000.sal > 24000/12sal > 2000sal*12 > 24000

If a SQL statement contains the first condition, the optimizer simplifies it into the secondcondition. Please note that optimizerdoes not simplify expressions across comparison operators.The optimizerdoes not simplify the third expression into the second. For this reason, we shouldwrite conditions that compare columns with constants whenever possible, rather than conditions

with expressions involving columns.

The Optimizerdoes not use index for the following statement:

SELECT *FROM empWHERE sal*12 > 24000 ;

Instead of this use the following statement:

SELECT *FROM empWHERE sal > 24000/12 ;


24/34



Use ofNOT operator on indexed columns:

Never use NOT operator on an indexed column. Whenever Oracle encounters a NOT on anindex column, it will perform full-table scan.

For Example:SELECT * FROM emp WHERENOT deptno = 0;Instead use the following:SELECT * FROM emp WHERE deptno > 0;

Function or Calculation on indexed columns:

Never use a function or calculation on an indexed column. If there is any function is used on anindex column, optimizer will not use index.For Example:

Do not use until need exactly match string:SELECT * FROM emp WHERE SUBSTR (ename, 1, 3) = 'MIL';Use following instead:SELECT * FROM emp WHERE ename LIKE 'MIL%';


25/34



Do not use the following as || is the concatenate function.

Like other functions and it disables index.

SELECT * FROM emp WHERE ename || job = 'MILLERCLERK';Use the following insteadSELECT * FROM emp WHERE ename = 'MILLER' AND job = 'CLERK';.

Avoid Transformed Columns in the WHERE Clause:

Use untransformed column values.

For example, use:WHERE a.order_no = b.order_noRather thanWHERE TO_NUMBER (SUBSTR(a.order_no, INSTR(b.order_no, '.') - 1))= TO_NUMBER (SUBSTR(a.order_no, INSTR(b.order_no, '.') - 1))


26/34



Combine Multiples Scans with CASEStatements:

Often, it is necessary to calculate different aggregates on various sets of tables. Usually, this isdone with multiple scans on the table, but it is easy to calculate all the aggregates with onesingle scan. Eliminating n-1 scans can greatly improve performance.

Combining multiple scans into one scan can be done by moving the WHERE condition of eachscan into a CASE statement, which filters the data for the aggregation. For each aggregation,there could be another column that retrieves the data.

The following example has count of all employees who earn less then 2000, between 2000 and

4000, and more than 4000 each month. This can be done with three separate queries.

SELECT COUNT (*) FROM emp WHERE sal < 2000;SELECT COUNT (*) FROM emp WHERE sal BETWEEN 2000 AND 4000;SELECT COUNT (*) FROM emp WHERE sal>4000;

However, it is more efficient to run the entire query in a single statement. Each number iscalculated as one column. The count uses a filter with the CASE statement to count only therows where the condition is valid. For example:

SELECT COUNT (CASE WHEN sal < 2000THEN 1 ELSE null END) count1,

COUNT (CASE WHEN sal BETWEEN 2001 AND 4000THEN 1 ELSE null END) count2,

COUNT (CASE WHEN sal > 4000THEN 1 ELSE null END) count3

FROM emp;


27/34


28/34



PROCEDURE calc_m ISm NUMBER; --no constraint

a NUMBER;b NUMBER;BEGIN...m := a + b;IF m IS NULL THEN-- raise errorEND IF;END;

Conditional control statements

In logical expressions, PL/SQL stops evaluating the expression as soon as the result isDetermined. Performance can be improved by tuning conditional constructs carefully.

Scenario 1IF (sal < 1500) OR (comm IS NULL) THEN...END IF;

Scenario 2IF credit_ok(cust_id) AND (loan < 5000) THEN...END IF;


29/34



Example 1:

IF (sal < 1500) OR (comm IS NULL) THEN

...END IF;In this example, when the value of sal is less than 1,500 the left operand yields TRUE, soPL/SQL need not evaluate the right operand (because OR returns TRUE if either of its operandsis true).Example 2:IF credit_ok(cust_id) AND (loan < 5000) THEN...END IF;

In this example, the Boolean function CREDIT_OK is always called. However, if youswitch the operands of AND as follows, the function is called only when the expressionloan < 5000 is true (because AND returns TRUE only if both its operands are true):IF (loan < 5000) AND credit_ok(cust_id) THEN...END IF;


30/34



Pinning Packages

One way to improve performance is to pin frequently used packages in the shared pool.

When a package is pinned, it is not aged out with the normal least recently used (LRU)mechanism that Oracle otherwise uses to flush out a least recently used package. The packageremains in memory no matter how full the shared pool gets or how frequently you access thepackage.

You pin packages with the help of the DBMS_SHARED_POOL package.

Example:

SYS.DBMS_SHARED_POOL.KEEP('SYS.STANDARD','P');

To remove the same from pinning

SYS.DBMS_SHARED_POOL.UNKEEP('SYS.STANDARD','P');


31/34



Subquery Factoring

Subquery factoring, also known as the WITH clause, provides a convenient and flexible way forus to define subqueries and in-line views in Oracle 9i. The primary purpose of subquery factoringis to reduce repeated table accesses by generating temporary datasets during query execution.However, even if we do not take advantage of this internal query optimisation, we can usesubquery factoring to structure our complex SQL statements in a more logical andunderstandable format.

The following syntax example is possibly more common in everyday use. We define two namedsubqueries, but the second builds on the first.

WITH subquery_name AS ( SELECT ... FROM table ) ,another_subquery_name AS ( SELECT ... FROM subquery_name )

SELECT ... FROM another_subquery_name WHERE ...

This form of subquery factoring is the semantic equivalent of the following pseudo-SQL.

SELECT ... FROM (SELECT ... FROM (

SELECT ...))


32/34



Use NOCOPY Clause:

When a parameter is passed as an IN variable, it is passed by reference. Since it will notchange, PL/SQL uses the passed variable in the procedure/function. When variables are passedin OUT orINOUT mode, a new variable is define, and the value is copied to the passed variablewhen the procedure ends. If the variable is a large structure such as a PL/SQL table or an array,the application could see a performance degradation cause by copying this structure.

The NOCOPY clause tells to PL/SQL engine to pass the variable by reference, thus avoiding thecost of copying the variable at the end of the procedure. The PL/SQL engine has requirementsthat must be met before passing the variable by reference and if those requirements are not met,

the NOCOPY clause will simply be ignored by the PL/SQL engine.

Example:

PROCEDURE in_out_nocopy (p_tab IN OUT NOCOPY t_tab) ISBEGINNULL;

END;

in_out_nocopy(l_tab) ; -- pass IN OUT NOCOPY parameter


33/34



Use BULK COLLECT:

1. BULK COLLECT avoids context switching. context switching is nothing but movement ofdatabetween PLSQL engine and SQL Engine.

A bulk collect is a method of fetching data where the PL/SQL engine tells the SQL engine tocollect many rows at once and place them in a collection. The SQL engine retrieves all the rowsand loads them into the collection and switches back to the PL/SQL engine. All the rows areretrieved with only 2 context switches.

The tradeoff with BULK COLLECT, like so many other performance-enhancing features, is "Run

faster but consume more memory." Specifically, memory for collections is stored in the ProgramGlobal Area (PGA), not the System Global Area (SGA). SGA memory is shared by all sessionsconnected to Oracle Database, but PGA memory is allocated for each session


34/34


Performance tuning recommendationsPerformance tuning recommendationsNormal code:

DECLARE

CURSOR major_pollutersISSELECT name, mileage

FROM cars_and_trucksWHERE vehicle_type IN ('SUV', 'PICKUP');

BEGINFOR bad_carIN major_pollutersLOOP

names.EXTEND;names (major_polluters%ROWCOUNT) := bad_car.name;mileages.EXTEND;mileages (major_polluters%ROWCOUNT) := bad_car.mileage;

END LOOP;

... now work with data in the arrays ...END;BULK COLLECT Code:

DECLAREnames name_varray;mileages number_varray;

BEGINSELECT name, mileage

FROM cars_and_trucksBULK COLLECT INTO names, mileagesWHERE vehicle_type IN ('SUV', 'PICKUP');

... now work with data in the arrays ...END;

Tuning Session

Documents

Transcript of Tuning Session