|
|
 |
Blogs
Toad and Database Commentaries |
Toad World blogs are a mix of insightful how-tos from Quest experts as well as their commentary on experiences with new database technologies. Have some views of your own to share? Post your comments! Note: Comments are restricted to registered Toad World users.
 Do you have a topic that you'd like discussed? We'd love to hear from you. Send us your idea for a blog topic.
|
|
|
|
|
|
|
Author: |
RichardTo |
Created: |
Monday, October 30, 2006 2:28 PM |
 |
 |
Richard To is chief technologist and designer of Quest SQL Tuning products. Richard specializes in using AI technique to solve database performance problems.
Richard's blog helps solve problems in your SQL code, tune queries, and shares new tips, tricks, and techniques on SQL tuning.
Recent postings on SQL tuning:
|
|
|
How to control many table join |
|
RichardTo
|
Wednesday, January 03, 2007 3:42 PM
|
|
|
|
In my last blog, I use two tables join to illustrate the simple path control, now let’s use a three table join SQL statement to demonstrate a more complicated scenario. Let’s assume that A.key, B.key and C.key are all indexed.
|
 |
|
|
Read More...
|
|
|
How to Control Two Tables Join Path? |
|
RichardTo
|
Thursday, December 07, 2006 3:06 PM
|
|
|
|
In old version of Oracle database, it is easy to control the join path by reordering the tables in table list after the FROM clause, but it is getting difficult to control the join path in today’s cost based SQL optimizer, I am going to introduce method that is applicable in most databases such as Oracle, Sybase, DB2 and SQL Server in the following:
To control a join path, we cannot tell the database SQL optimizer which path is the best one to select. Instead, we add something to the syntax of the SQL statement that causes an increase to the cost of the current join path selected by database SQL optimizer. Let’s take a look at the following example of two table join scenarios.
|
|
|
|
|
Read More...
|
|
|
Why Join Path Matters |
|
RichardTo
|
Monday, November 13, 2006 12:28 PM
|
|
|
|
The Nested Loop join operation is the basic join operation which is supported by most RDBMS, since it requires less memory and less temporary space. Normally, it can provide faster data response time than other join operations. But, the path of a Nested Loop join will significantly affect the speed of the join operation. Let’s use a two table join as an example to understand how this works.
|
|
|
|
|
Read More...
|
|
|
Why SQL Tuning? |
|
RichardTo
|
Monday, October 30, 2006 2:28 PM
|
|
|
|
For years, commercial database manufacturers have fought an endless battle to improve the performance of inserting, updating, deleting, and retrieving information stored in the database. Despite their continual efforts and hard work, we have not seen a significant improvement in the performance of most Relational Database Management Systems (RDBMS). Users still suffer from under-performing SQL statements and database expe ...
|
|
|
|
|
Read More...
|
|
|
|
|
|
|
|
|
|
|