Welcome to Scribd. Sign in or start your free trial to enjoy unlimited e-books, audiobooks & documents.Find out more
Standard view
Full view
of .
Look up keyword
Like this
0 of .
Results for:
No results containing your search query
P. 1
Tune Join- Oracle

Tune Join- Oracle



|Views: 44|Likes:
Published by muku_ndan

More info:

Categories:Types, Brochures
Published by: muku_ndan on Feb 19, 2010
Copyright:Attribution Non-commercial


Read on Scribd mobile: iPhone, iPad and Android.
download as RTF, PDF, TXT or read online from Scribd
See more
See less





Tuning Joins
Roger Schrag
 Database Specialists, Inc.
A SQL statement involving two or more tables requires that Oracle
data from multiple sources in order to achieve thedesired result. The Oracle Server has several built in methods for performing joins, and each method has its own performance and resource usage qualities. While an application developer or DBA doesn’t need to explicitly tell Oraclewhich join method to use or the order in which different tables should be joined, a solid understanding of how Oracle processes joins allows you to design and build systems for optimal performance. In this presentation we’ll examine thedifferent methods Oracle uses for joining data from multiple sources, and we’ll see how this understanding can be used todesign better database schemas, tune SQL statements, and tune databases as a whole for better join performance. Sincemost SQL statements involve joins, tuning joins leads to improved overall system performance.
How Oracle Processes SQL Statements Involving Joins
Oracle’s optimizer must choose an execution plan for each SQL statement submitted. The plan will indicate how data will be accessed—which indexes will be used and so forth. If the SQL statement involves a join or a subquery, then theoptimizer must also choose the order in which tables will be joined together, and the method to be used for each joinoperation.
Join Order 
row source
is a logical set of rows from a partially complete query. The row source may be rows in an actual table or rows in a temporary segment stored on disk or in memory. Oracle always joins two row sources at a time. Therefore, if aSQL statement joins three tables, Oracle will actually join two tables together and then join the results with the third table.The order in which row sources are joined can have a significant impact on performance. The optimizer makes a list of all physically possible join orders and then chooses what it believes will be the best option. The cost-based optimizer makesthis decision by estimating the cost of each option and choosing the one with the lowest cost. The rule-based optimizer,meanwhile, scores each option based on a fixed set of rules and chooses the option with the best score.Outer joins limit the number of possible join orders because a table being outer joined must appear in the join order after the table it joins to.Let’s use the following query as an example:
SELECT E1.name “Employee Name”, D.deptname “Department”,E2.name “Manager Name”FROM emp E1, dept D, emp E2WHERE E1.empno = :empnoAND D.deptno = E1.deptnoAND E2.empno (+) = E1.mgr_empno;
Oracle could execute this SQL statement by joining emp table E1 to dept, and then joining the results to emp table E2.Alternatively, the order could be E1 - E2 - D. Note that the order D - E1 - E2 is also possible, but probably not tooefficient. Also note that the order D - E2 - E1 is not physically possible because E2 is being outer joined to E1 andtherefore must appear after E1 in the join order. And since D and E2 share no criteria in the WHERE clause, such a joinorder wouldn’t seem to make much sense anyway.
-- 1 --
Join Methods
Since the days of Oracle V6, the optimizer has used three different ways to join row sources together. These are the
nested loops join
, the
 sort-merge join
, and the
cluster join
. With Oracle 7.3 the
hash join
was introduced, making for atotal of four join methods. Each has a unique set of features and limitations. Nested Loops JoinsSuppose somebody gave you a telephone book and a list of 20 names, and asked you to write down each person’s nameand telephone number on a fresh sheet of paper. You would probably go down the list of names, looking each up in thetelephone book one at a time. This would be pretty easy for you, because the telephone book is alphabetized by name.Moreover, somebody looking over your shoulder could begin calling the first few numbers you write down while you arestill looking up the rest. This scene describes a nested loops join.In a nested loops join, Oracle reads the first row from the first row source and then checks the second row source for matches. All matches are then placed in the result set and Oracle goes on to the next row from the first row source. Thiscontinues until all rows in the first row source have been processed. The first row source is often called the
table or 
table, while the second row source is called the
table. Nested loops joins are ideal when the driving row source is small and the joined columns of the inner row source areuniquely indexed or have a highly selective non-unique index. Nested loops joins have an advantage over other joinmethods in that they can quickly retrieve the first few rows of the result set without having to wait for the entire result setto be determined. This is ideal for query screens where an end-user can read the first few records retrieved while the restare being fetched. Nested loops joins are also flexible in that any two row sources can always be joined by nested loops— regardless of join condition and schema definition.However, nested loops joins can be very inefficient if the inner row source does not have an index on the joined columnsor if the index is not highly selective. Also, if the driving row source is quite large, other join methods may be moreefficient.Sort-Merge JoinsSuppose two salespeople attend a conference and each collects over 100 business cards from potential new customers.Each salesperson now has a pile of cards in random order, and they want to see how many cards are duplicated in both piles. So each salesperson alphabetizes their pile, and then they call off names one at a time. Since both piles of cards have been sorted, it becomes much easier to find the names that appear in both piles. This scene describes a sort-merge join.In a sort-merge join, Oracle sorts the first row source by its join columns, sorts 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.Sort-merge joins can be effective when lack of data selectivity or useful indexes render a nested loops join inefficient, or when both of the row sources are quite large. However, sort-merge joins can only be used for equijoins (WHERED.deptno = E1.deptno, as opposed to WHERE T.temperature >= D.daily_avg_temperature). Also, sort-merge joinsrequire temporary segments for sorting. This can lead to extra memory utilization and extra disk I/O in the temporarytablespace.
-- 2 --
Cluster JoinsImagine a filing cabinet full of personnel records. For each employee there is a separate folder containing a basicinformation sheet, a list of vacation days used, and other papers pertaining to the employee. If the boss wants to see areport that lists each employee’s name, social security number, and number of vacation days used this year, then youcould work through the filing cabinet one file at a time. When you pull out one employee’s file, you immediately haveaccess to the basic information sheet (which has the employee’s social security number on it) and the list of vacation daysused. If you imagine that the basic information is stored in one database table and the vacation days used in another, thenthis scene could describe a cluster join.A cluster join is really just a special case of the nested loops join. If the two row sources being joined are actually tablesthat are part of a cluster and if the join is an equijoin between the cluster keys of the two tables, then Oracle can use acluster join. In this case, Oracle reads each row from the first row source and finds all matches in the second row source by using the cluster index. In the personnel cabinet example, the filing cabinet is the cluster and the individual employeefolders are the cluster key.Cluster joins are extremely efficient, since the joining rows in the two row sources will actually be located in the same physical data block. However, clusters carry certain caveats of their own, and you can’t have a cluster join without acluster. Therefore, cluster joins are not very commonly used. In a later section we’ll look at the pros and cons of clusters.Hash JoinsIn a hash join, Oracle reads all of the join column values from the second row source, builds a hash table, and then probesthe hash table for each of the join column values from the first row source. This is like a nested loops join, except that firstOracle builds a hash table to facilitate the operation.Hash joins can be effective when the lack of a useful index renders nested loops joins inefficient. The hash join might befaster than a sort-merge join in this case because only one row source needs to be sorted, and could possibly be faster thana nested loops join because probing a hash table in memory can be faster than traversing a B-tree index. As with sort-merge joins and cluster joins, though, hash joins only work on equijoins. Also, as with sort-merge joins, hash joins usememory resources and can drive up I/O in the temporary tablespace. Finally, hash joins are only available in Oracle 7.3and later, and then only when cost-based optimization is used.
Effective Schema Design
The database schema plays an important role in tuning joins. Certain features in the schema, or the absence of thesefeatures, will limit the options available to the optimizer for joining tables efficiently. Also, poorly placed features in theschema can fool the optimizer into making a poor decision.
Indexing Keys
All primary and unique keys should be identified and appropriate constraints declared. This will cause the creation of unique indexes on the primary and unique key columns. Indexes should usually be created explicitly on foreign keycolumns to facilitate joins and to eliminate locking problems when Oracle enforces referential integrity constraints.Consider an orders table with primary key order_id, and an order_lines table with primary key order_line_id and foreignkey order_id referencing the orders table.
SELECT O.order_number, L.line_number, L.item_number, L.quantityFROM orders O, order_lines LWHERE O.order_id = :order_idAND L.order_id = O.order_idORDER BY O.order_number, L.line_number
If the database will contain many orders, then the order_id column in the order_lines table is very selective and should beindexed. This index, plus the unique index on the order_id column of the orders table will allow Oracle to execute thisquery extremely efficiently using a nested loops join.
-- 3 --

Activity (5)

You've already reviewed this. Edit your review.
1 hundred reads
sunny_dba liked this
dayasc liked this
dayasc liked this
spallihari liked this

You're Reading a Free Preview

/*********** DO NOT ALTER ANYTHING BELOW THIS LINE ! ************/ var s_code=s.t();if(s_code)document.write(s_code)//-->