Improve Oracle database performance — Rules of Thumb, Part 2
By: Tosska Technologies
Tags: Oracle, Oracle Database, Database, MySQL, Sql

In today’s article, we continue to discuss some more thumb rules that are generally applicable in SQL development. These guidelines remain the same, no matter what the underlying DBMS is.

Here, we will talk about Rules 4, 5, and 6 that guide SQL development for DBAs and professional developers.

Rule 4: Fetch Only the Required Data

Although it’s as easy to follow as it sounds, surprisingly, it is violated more often than you can imagine. One thing you can do to reduce the amount of information that is returned by a SQL query is to mention the bare minimum quantity of columns in the SELECT list. In case a column is not required to fulfill certain criteria, it is simply not requested to be returned in the result set.

In short, mention the least number of columns possible in the SELECT statements.

Programmers often use Oracle query optimizer tool to replicate SQL queries that execute properly to utilize as templates for newer queries. At times, the developer might forget to reduce the result set by cutting down the number of columns for instances that only require a subset of columns from the original statement.

The greater the quantity of columns that has to be fetched by the Database Management System, the higher the processing overhead.

Unnecessary information requests are also a recurring issue. Take a look at the following SQL query -

SELECT post, last_name, empnumber

FROM emp

WHERE sir_name = ‘JONES’;

Here, we know there is no reason to specify the last_name column in the SELECT list of this SQL statement. We know that last_name must be ‘SMITH’ for the entire result set because of the WHERE clause.

Returning only what is needed does not apply only to columns. You should also minimize the number of rows to be returned by coding the proper WHERE clauses for every SQL statement. The more data that can be filtered out of the result set by the DBMS, the more efficient the query will be because less data must be returned to the requester.

Rule 5: Avoid Cartesian Products

Be sure to code predicates matching the columns of every table that will be joined within each SQL statement. Failure to do so will not help you improve Oracle database performance and may result in incorrect results.

Whenever predicates do not exist when you are joining two tables, the RDBMS must perform a Cartesian product. This is the combination of every row of one table with every row of the other table. Non-matching rows are not eliminated because there is nothing that can be matched. The results of a Cartesian product are difficult to interpret and contain no information other than a simple list of all rows of each table munged together.

Of course, there are exceptions to this rule where you are specifically coding a Cartesian product for a business or technical reason. When coding a Cartesian product on purpose always make sure that you have investigated other methods of producing the same results and tested each method for performance and accuracy… and be sure to specifically test any query with a Cartesian product using production volumes of data!

Rule 6: Judicious Use of OR

The OR logical operator can be troublesome for performance. If you can convert a SQL statement that uses OR to one that uses IN, it is likely that performance will improve. For example, consider changing this SQL statement:

SELECT e.position, e.last_name, e.empno, d.manager

FROM employee e,

department d

WHERE d.dept_id = e.dept_id

AND position = ‘MANAGER’

OR position = ‘DIRECTOR’

OR position = ‘VICE PRESIDENT’

ORDER BY position;

to this:

SELECT e.position, e.last_name, e.empno, d.manager

FROM employee e,

department d

WHERE d.dept_id = e.dept_id

AND position IN (‘MANAGER’, ‘DIRECTOR’, ‘VICE PRESIDENT’)

ORDER BY position;

Of course, your results may vary depending on the DBMS in use and the nature of the data.