Assume you have a fairly complex select statement operating on some serious tables (tens of millions of rows). The customer complains the SQL statement is to slow. What options would you consider for tuning such a select statement? If it matters assume it is an Oracle database.

Just in case you want to apply for a job at a LINEAS here is, what I would consider a damn good answer:

First I check if the SQL statement is really slow, for that I’ll execute the SQL statement with a low level tool (SQL Plus, SQL Developer …) on the database. I fetch the same amount of rows, as the customer (or his application) does. I do that on the DB machine or one a machine with very good connectivity to the database, in order to take network issues out of the loop. I measure the execution time. If this is as slow as described by the customer, the SQL statement plus DB seem to be the problem. If not probably something else is the problem (network, application logic …)

I establish a target performance, we need to meet the customer requirements.

I check the execution plan of the statement comparing it with the structure of the schema (tables, indexes, number of rows in tables compared to number of rows actually selected). Are there any obvious problems? For example;

• Full Table Scans that result only in a small percentage of the rows of that table
• Index accesses on a large percentage of rows
• Indexes that don’t get used, although one would expect them to
• Identical expensive pieces of the execution plan, on different places  of the execution plan
• Estimated number of rows in the execution plan that differ significantly from the actual number of rows returned

Depending on what I find I would try some of the following actions, to improve performance

• gather statistics
• create an additional index supporting the where clauses used in the statement
• add columns to an index, in order to remove the need for additional table accesses
• use hints to force certain execution plans
• exchange (not) in with (not) exists and vice versa
• rearrange the select statement (e.g. turn a union of  joins into a join of union)
• partitioning of tables and indexes
• use materialized views
• in very special cases use bitmap indexes or dimensions

With these options the performance of most of the ‘slow’ statements I encountered so far could get brought to acceptable levels. Often improving performance by multiple orders of magnitude. When I am able to identify the problem, but not the solution Ask Tom is what I would do next.

There is one answer I get very often, which I consider pretty bad, if it comes without further comment:

Replace outer joins with inner joins

Outer joins have a different meaning than inner joins. Normally you can’t replace one for the other. If you actually can, I’d consider using an outer join a bug, so replacing it with an inner join is bug fixing, not tuning.

So for those among you who haven’t studied informatics: “What is a Turing machine?”

A Turing machine is a theoretical, extremly simple computer. It consists of an endless array (often called tape), that can store a symbol on every position, and the ‘head’ that is positioned at a specific position of the tape. The Turing machine works as follows: The head reads the symbol in the array at its current position. Depending on the current state of the head, and the symbol read, it writes a new symbol in the array at the current position, and moves one step to the right or left. It continues to do so, until it reaches a final state.

Turing machines are interesting, because everything a computer can calculate, can be calculated using a Turing machine and vice versa. The fact that the memory of a real computer is limited can be ignored, as long as it is ‘big enough’.

Since there is no way to iterate in SQL, neither directly nor by means of recursion, it is hard to imagine, how such a machine could be implemented using SQL.

Enter the model clause. The model clause is a Oracle specific extension to SQL. It is supposed to allow Excel like manipulation on resultsets of a SQL statement. Basically you do a normal Select statement, add a model clause, and in the model clause you can adress any cell of your resultset, and you can even add rows or columns. This is done using a very limited iterative language. This feature exists since Oracle 10g (2004?), but I haven’t seen it used in a production system (thank godness), actually I haven’t found a person in real live that actualy knows this feature. One reason is probably that Oracle managed to create the worst language I have seen so far, and I have worked with XSLT, Visual Basic 5, Fortran 66 and 6502 Assembler.

So let’s implement the Turing machine. We need the tape and the definition of how the Turing machine should behave, it’s program. Since we are in a database this will get stored in tables:

In order to test our Turing machine we need an initial state and a program. Since I’m no expert on Turing machine programming I copied that from the german Wikipedia page. The initial state are just two 1s, and the program is supposed to copy all the continuous 1s it finds, with a separating 0 in between:

Now comes the actual work. If you are only interested in the final solution, scroll all the way to the end of the article. But if you follow along you can see how I developed the program. This should teach you a little about the model clause, and why you shouldn’t use it for anything real.

First step, get any model clause at all to work:

The first line selects the intial state from the tape. The second line starts the model clause. dimension by (position) allows us to access a row by its position value. Think of it as an array index or primary key. Measures defines the cells we are going to work with. A cell can be accessed with an array like syntax like symbol[23], where 23 it the position-value we use to specify the cell. The rules part is the actual program, it doesn’t do anything useful. It only multiplies every symbol with 2 and repeats this 3 times. any references all rows (that’s why it is called any), while cv() references the current value, i.e. the any/cv combination defines an implicit loop over all rows of the model.

Second Step: make the program or the machine accessible. In order to do that we make it a ‘model’ as well. Note that these reference models are read only.

Using the measures I also added two column to store the current state of the Turing machine, and the current position of the head. These cells are available for every row of my model, i.e. the tape, but I’m going to use only the one in position 0. Maybe just didn’t look hard enough but I couldn’t find a proper way to define variables.

Now we have all the data structures that we need, we can actually implement the workings of the Turing machine.

The real program part are the four lines after rules. The first line reads the current symbol, the second writes the new symbol, depending on the current symbol and the current state. The third line moves the head, and the fourth line sets the new current state. We are almost done.

What’s left is the implementation of stop states. Right now we just iterate 15 times (rules iterate(15)) the little challenge is: The model clause does not offer the equivalent of a while loop. It only knows for loops. Luckily you can exit from a loop with another condition, so when you need a while loop you define a number as being equal to inifinity, and put your exit condition in a until clause, like so:

The Turing machine is done and produces the intended output:

position	symbol	c.state	c.position	c.symbol

0		1	6	2		0

1		1	1	0		0

2		0

3		1

4		1

So, what do we learn from this?

• Oracle SQL is indeed Turing complete
• Oracle jumped the DSL band waggon already in 2004 and fell of the other side
• You definetly should learn and use the model clause if
  • You want to make your code unreadable
  • You are a masochist
  • You earn your money by betting: “I bet you can’t do this in SQL”
• Other then that the Oracle Clause is just another sign that Oracle doesn’t get anything right if it isn’t inside the database core engine

If you still want to explore the model clause further, I can recommend these links:

http://www.oreillynet.com/pub/a/network/2004/08/10/MODELclause.html

http://rwijk.blogspot.com/2007/10/sql-model-clause-tutorial-part-one.html

http://otn.oracle.com/pls/db10g/search?remark=quick_search&word=model+clause