05.11.2015 Views

Apress.Expert.Oracle.Database.Architecture.9i.and.10g.Programming.Techniques.and.Solutions.Sep.2005

Create successful ePaper yourself

Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.

390<br />

CHAPTER 10 ■ DATABASE TABLES<br />

Execution Plan<br />

----------------------------------------------------------<br />

0 SELECT STATEMENT Optimizer=ALL_ROWS (Cost=0 Card=4 Bytes=76)<br />

1 0 TABLE ACCESS (HASH) OF 'CUST_ORDERS' (CLUSTER (HASH))<br />

ops$tkyte@ORA10G> select job, hiredate, empno<br />

2 from scott.emp<br />

3 where job = 'CLERK'<br />

4 order by hiredate;<br />

Execution Plan<br />

----------------------------------------------------------<br />

0 SELECT STATEMENT Optimizer=ALL_ROWS (Cost=3 Card=3 Bytes=60)<br />

1 0 SORT (ORDER BY) (Cost=3 Card=3 Bytes=60)<br />

2 1 TABLE ACCESS (BY INDEX ROWID) OF 'EMP' (TABLE) (Cost=2 Card=3 ...<br />

3 2 INDEX (RANGE SCAN) OF 'JOB_IDX' (INDEX) (Cost=1 Card=3)<br />

ops$tkyte@ORA10G> set autotrace off<br />

I added the query against the normal SCOTT.EMP table (after indexing the JOB column for<br />

this demonstration) to compare what we normally expect to see: the SCOTT.EMP query plan<br />

versus what the sorted hash cluster can do for us when we want to access the data in a FIFO<br />

mode (like a queue). As you can see, the sorted hash cluster has one step: it takes the CUST_ID=:X,<br />

hashes the input, finds the first row, <strong>and</strong> just starts reading the rows, as they are in order<br />

already. The regular table is much different: it finds all the JOB='CLERK' rows (which could be<br />

anywhere in that heap table), sorts them, <strong>and</strong> then returns the first one.<br />

So, the sorted hash cluster has all the retrieval aspects of the hash cluster, in that it can get<br />

to the data without having to traverse an index, <strong>and</strong> many of the features of the IOT, in that the<br />

data will be sorted within that key by some field of your choice. This data structure works well<br />

when the input data arrives “in order” by the sort field, by key. That is, over time the data<br />

arrives in increasing sort order for any given key value. Stock information fits this requirement<br />

as an example. Every night you get a new file full of stock symbols, the date (the date would be<br />

the sort key <strong>and</strong> the stock symbol would be the hash key), <strong>and</strong> related information. You receive<br />

<strong>and</strong> load this data in sort key order. The stock data for stock symbol ORCL for yesterday does<br />

not arrive after today—you would load yesterday’s value, <strong>and</strong> then today’s value, <strong>and</strong> later<br />

tomorrow’s value. If the information arrives r<strong>and</strong>omly (not in sort order), this data structure<br />

quickly breaks down during the insert process, as much data has to be moved to put the rows<br />

physically in order on disk. A sorted hash cluster is not recommended in that case (an IOT, on<br />

the other h<strong>and</strong>, could well be useful for that data).<br />

When considering using this structure, you should employ the same considerations from<br />

the hash cluster section, in addition to the constraint that the data should arrive sorted for<br />

each key value over time.<br />

Nested Tables<br />

Nested tables are part of the object-relational extensions to <strong>Oracle</strong>. A nested table, one of the<br />

two collection types in <strong>Oracle</strong>, is very similar to a child table in a traditional parent/child table

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!