Oracle Consulting Oracle Training Oracle Support Development
Home
Catalog
Oracle Books
SQL Server Books
IT Books
Job Interview Books
eBooks
Rampant Horse Books
911 Series
Pedagogue Books

Oracle Software
image
Write for Rampant
Publish with Rampant
Rampant News
Rampant Authors
Rampant Staff
 Phone
 800-766-1884
Oracle News
Oracle Forum
Oracle Tips
Articles by our Authors
Press Releases
SQL Server Books
image
image

Oracle 11g Books

Oracle tuning

Oracle training

Oracle support

Remote Oracle

STATSPACK Viewer

Privacy Policy

 

   
  SQL Server Tips by Burleson

Nasty Join Operations

There are several join operations that should be avoided in a query. Leading the pack is the Cartesian join. It normally appears only as a coding mistake on the part of the user who issued the query. A Cartesian join means there are two tables involved in a query that have not been properly joined together through some relational column pairing. For example:

select
patient_id
from
admission a,
patient b
where
patient_last_name like 'JUNG%'


The two tables in the above query have not been paired together through a common relational column that is present in both tables; therefore, SQL Server will have to utilize a Cartesian join. The Cartesian join multiplies the number of rows in the first table by the number of rows in the second table to arrive at the result set.

To guard against Cartesian joins, the standard rule of thumb is there must be (N – 1) number of join predicates, where N represents the number of tables in the FROM clause. A Cartesian product can be spotted easily in the EXPLAIN as there will be a larger signaled result set than expected.

Besides Cartesian joins, be on the lookout for other join operations that can contribute to excessive run times. The most common heavy-duty joins are hash and merge joins. These joins perform more in-memory processing than nested loop joins, and therefore, the DBA will see higher CPU and memory usage from these operations.

Often, indexing changes can transform the hash join into a nested loop join. Since each situation is different, keep a close eye on the performance execution metrics as different combinations are tried.


The above book excerpt is from:

High-Performance SQL Server DBA
Tuning & Optimization Secrets

ISBN: 0-9761573-6-5
Robin Schumacher

 http://www.rampant-books.com/book_2005_2_sql_server_dba.htm  

Linux Oracle commands syntax poster

ION Oracle tuning software

Oracle data dictionary reference poster



Oracle Forum

BC Oracle consulting support training

BC remote Oracle DBA   

 

   

 Copyright © 1996 -2016 by Burleson. All rights reserved.


Oracle® is the registered trademark of Oracle Corporation. SQL Server® is the registered trademark of Microsoft Corporation. 
Many of the designations used by computer vendors to distinguish their products are claimed as Trademarks
 

Hit Counter