05.11.2015 Views

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

You also want an ePaper? Increase the reach of your titles

YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.

352<br />

CHAPTER 10 ■ DATABASE TABLES<br />

ops$tkyte@ORA10GR1> delete from t where a = 2 ;<br />

1 row deleted.<br />

ops$tkyte@ORA10GR1> insert into t (a) values ( 4);<br />

1 row created.<br />

ops$tkyte@ORA10GR1> select a from t;<br />

A<br />

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

1<br />

4<br />

3<br />

Adjust columns B <strong>and</strong> C to be appropriate for your blocksize if you would like to reproduce<br />

this. For example, if you have a 2KB blocksize, you do not need column C, <strong>and</strong> column B<br />

should be a VARCHAR2(1500) with a default of 1,500 asterisks. Since data is managed in a heap<br />

in a table like this, as space becomes available, it will be reused.<br />

■Note When using ASSM or MSSM, you’ll find rows end up in “different places.” The underlying space<br />

management routines are very different, <strong>and</strong> the same operations executed against a table in ASSM <strong>and</strong><br />

MSSM may well result in different physical order. The data will logically be the same, but it will be stored<br />

in different ways.<br />

A full scan of the table will retrieve the data as it hits it, never in the order of insertion.<br />

This is a key concept to underst<strong>and</strong> about database tables: in general, they are inherently<br />

unordered collections of data. You should also note that I do not need to use a DELETE in order<br />

to observe this effect; I could achieve the same results using only INSERTs. If I insert a small<br />

row, followed by a very large row that will not fit on the block with the small row, <strong>and</strong> then a<br />

small row again, I may very well observe that the rows come out by default in the order “small<br />

row, small row, large row.” They will not be retrieved in the order of insertion. <strong>Oracle</strong> will place<br />

the data where it fits, not in any order by date or transaction.<br />

If your query needs to retrieve data in order of insertion, you must add a column to the<br />

table that you can use to order the data when retrieving it. That column could be a number<br />

column, for example, maintained with an increasing sequence (using the <strong>Oracle</strong> SEQUENCE<br />

object). You could then approximate the insertion order using a SELECT that did an ORDER BY<br />

on this column. It will be an approximation because the row with sequence number 55 may<br />

very well have committed before the row with sequence 54, therefore it was officially “first” in<br />

the database.<br />

You should think of a heap organized table as a big unordered collection of rows. These<br />

rows will come out in a seemingly r<strong>and</strong>om order, <strong>and</strong> depending on other options being used<br />

(parallel query, different optimizer modes, <strong>and</strong> so on), they may come out in a different order<br />

with the same query. Do not ever count on the order of rows from a query unless you have an<br />

ORDER BY statement on your query!

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

Saved successfully!

Ooh no, something went wrong!