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.

380<br />

CHAPTER 10 ■ DATABASE TABLES<br />

Now if we issue a CREATE CLUSTER statement such as the following, we can see the storage it<br />

allocated:<br />

ops$tkyte@ORA10GR1> create cluster hash_cluster<br />

2 ( hash_key number )<br />

3 hashkeys 1000<br />

4 size 8192<br />

5 tablespace mssm<br />

6 /<br />

Cluster created.<br />

ops$tkyte@ORA10GR1> exec show_space( 'HASH_CLUSTER', user, 'CLUSTER' )<br />

Free Blocks............................. 0<br />

Total Blocks............................ 1,024<br />

Total Bytes............................. 8,388,608<br />

Total MBytes............................ 8<br />

Unused Blocks........................... 14<br />

Unused Bytes............................ 114,688<br />

Last Used Ext FileId.................... 9<br />

Last Used Ext BlockId................... 1,033<br />

Last Used Block......................... 114<br />

PL/SQL procedure successfully completed.<br />

We can see that the total number of blocks allocated to the table is 1,024. Fourteen of<br />

these blocks are unused (free). One block goes to table overhead, to manage the extents.<br />

Therefore, 1,009 blocks are under the HWM of this object, <strong>and</strong> these are used by the cluster.<br />

The prime 1,009 just happens to be the next largest prime over 1,000, <strong>and</strong> since the blocksize<br />

is 8KB, we can see that <strong>Oracle</strong> did in fact allocate (8192 ✕ 1009) blocks. The figure is a little<br />

higher than this, due to the way extents are rounded <strong>and</strong>/or by using locally managed tablespaces<br />

with uniformly sized extents.<br />

This example points out one of the issues with hash clusters you need to be aware of.<br />

Normally, if you create an empty table, the number of blocks under the HWM for that table is 0.<br />

If you full scan it, it reaches the HWM <strong>and</strong> stops. With a hash cluster, the tables will start out<br />

big <strong>and</strong> will take longer to create, as <strong>Oracle</strong> must initialize each block, an action that normally<br />

takes place as data is added to the table. They have the potential to have data in their first<br />

block <strong>and</strong> their last block, with nothing in between. Full scanning a virtually empty hash cluster<br />

will take as long as full scanning a full hash cluster. This is not necessarily a bad thing; you<br />

built the hash cluster to have very fast access to the data by a hash key lookup. You did not<br />

build it to full scan it frequently.<br />

Now we can start placing tables into the hash cluster in the same fashion we did with<br />

index clusters:<br />

Ops$tkyte@ORA10GR1> create table hashed_table<br />

2 ( x number, data1 varchar2(4000), data2 varchar2(4000) )<br />

3 cluster hash_cluster(x);<br />

Table created.

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

Saved successfully!

Ooh no, something went wrong!