Apress.Expert.Oracle.Database.Architecture.9i.and.10g.Programming.Techniques.and.Solutions.Sep.2005
CHAPTER 10 ■ DATABASE TABLES 387 Rows Row Source Operation ------- --------------------------------------------------- 48178 TABLE ACCESS BY INDEX ROWID T_HEAP (cr=144534 pr=0 pw=0 time=1331049 us) 48178 INDEX UNIQUE SCAN T_HEAP_PK (cr=96356 pr=0 pw=0 time=710295 us)(object... Hash Clustered Tables Wrap-Up That is the nuts and bolts of a hash cluster. Hash clusters are similar in concept to index clusters, except a cluster index is not used. The data is the index in this case. The cluster key is hashed into a block address and the data is expected to be there. The important things to understand about hash clusters are as follows: • The hash cluster is allocated right from the beginning. Oracle will take your HASHKEYS/ trunc(blocksize/SIZE) and allocate and format that space right away. As soon as the first table is put in that cluster, any full scan will hit every allocated block. This is different from every other table in this respect. • The number of HASHKEYs in a hash cluster is a fixed size. You cannot change the size of the hash table without a rebuild of the cluster. This does not in any way limit the amount of data you can store in this cluster; it simply limits the number of unique hash keys that can be generated for this cluster. That may affect performance due to unintended hash collisions if the value was set too low. • Range scanning on the cluster key is not available. Predicates such as WHERE cluster_ key BETWEEN 50 AND 60 cannot use the hashing algorithm. There are an infinite number of possible values between 50 and 60, and the server would have to generate them all to hash each one and see if there was any data there. This is not possible. The cluster will be full scanned if you use a range on a cluster key and have not indexed it using a conventional index. Hash clusters are suitable in the following situations: • You know with a good degree of accuracy how many rows the table will have over its life, or you have some reasonable upper bound. Getting the size of the HASHKEYs and SIZE parameters right is crucial to avoid a rebuild. • DML, especially inserts, is light with respect to retrieval. This means you have to balance optimizing data retrieval with new data creation. Light inserts might be 100,000 per unit of time for one person and 100 per unit of time for another—all depending on their data retrieval patterns. Updates do not introduce significant overhead, unless you update the HASHKEY, which would not be a good idea, as it would cause the row to migrate. • You access the data by the HASHKEY value constantly. For example, say you have a table of parts, and these parts are accessed by part number. Lookup tables are especially appropriate for hash clusters.
388 CHAPTER 10 ■ DATABASE TABLES Sorted Hash Clustered Tables Sorted hash clusters are new in Oracle 10g. They combine the qualities of the hash cluster just described with those of an IOT. They are most appropriate when you constantly retrieve data using a query similar to this: Select * From t Where KEY=:x Order by SORTED_COLUMN That is, you retrieve the data by some key and need that data ordered by some other column. Using a sorted hash cluster, Oracle can return the data without performing a sort at all. It accomplishes this by storing the data upon insert in sorted order physically—by key. Suppose you have a customer order table: ops$tkyte@ORA10G> select cust_id, order_dt, order_number 2 from cust_orders 3 order by cust_id, order_dt; CUST_ID ORDER_DT ORDER_NUMBER ------- ---------------------------- ------------ 1 31-MAR-05 09.13.57.000000 PM 21453 11-APR-05 08.30.45.000000 AM 21454 28-APR-05 06.21.09.000000 AM 21455 2 08-APR-05 03.42.45.000000 AM 21456 19-APR-05 08.59.33.000000 AM 21457 27-APR-05 06.35.34.000000 AM 21458 30-APR-05 01.47.34.000000 AM 21459 7 rows selected. The table is stored in a sorted hash cluster, whereby the HASH key is CUST_ID and the field to sort on is ORDER_DT. Graphically, it might look like Figure 10-10, where 1, 2, 3, 4, . . . represent the records stored sorted on each block. Figure 10-10. Sorted hash cluster depiction
- Page 381 and 382: 336 CHAPTER 9 ■ REDO AND UNDO tou
- Page 383 and 384: 338 CHAPTER 10 ■ DATABASE TABLES
- Page 385 and 386: 340 CHAPTER 10 ■ DATABASE TABLES
- Page 387 and 388: 342 CHAPTER 10 ■ DATABASE TABLES
- Page 389 and 390: 344 CHAPTER 10 ■ DATABASE TABLES
- Page 391 and 392: 346 CHAPTER 10 ■ DATABASE TABLES
- Page 393 and 394: 348 CHAPTER 10 ■ DATABASE TABLES
- Page 395 and 396: 350 CHAPTER 10 ■ DATABASE TABLES
- Page 397 and 398: 352 CHAPTER 10 ■ DATABASE TABLES
- Page 399 and 400: 354 CHAPTER 10 ■ DATABASE TABLES
- Page 401 and 402: 356 CHAPTER 10 ■ DATABASE TABLES
- Page 403 and 404: 358 CHAPTER 10 ■ DATABASE TABLES
- Page 405 and 406: 360 CHAPTER 10 ■ DATABASE TABLES
- Page 407 and 408: 362 CHAPTER 10 ■ DATABASE TABLES
- Page 409 and 410: 364 CHAPTER 10 ■ DATABASE TABLES
- Page 411 and 412: 366 CHAPTER 10 ■ DATABASE TABLES
- Page 413 and 414: 368 CHAPTER 10 ■ DATABASE TABLES
- Page 415 and 416: 370 CHAPTER 10 ■ DATABASE TABLES
- Page 417 and 418: 372 CHAPTER 10 ■ DATABASE TABLES
- Page 419 and 420: 374 CHAPTER 10 ■ DATABASE TABLES
- Page 421 and 422: 376 CHAPTER 10 ■ DATABASE TABLES
- Page 423 and 424: 378 CHAPTER 10 ■ DATABASE TABLES
- Page 425 and 426: 380 CHAPTER 10 ■ DATABASE TABLES
- Page 427 and 428: 382 CHAPTER 10 ■ DATABASE TABLES
- Page 429 and 430: 384 CHAPTER 10 ■ DATABASE TABLES
- Page 431: 386 CHAPTER 10 ■ DATABASE TABLES
- Page 435 and 436: 390 CHAPTER 10 ■ DATABASE TABLES
- Page 437 and 438: 392 CHAPTER 10 ■ DATABASE TABLES
- Page 439 and 440: 394 CHAPTER 10 ■ DATABASE TABLES
- Page 441 and 442: 396 CHAPTER 10 ■ DATABASE TABLES
- Page 443 and 444: 398 CHAPTER 10 ■ DATABASE TABLES
- Page 445 and 446: 400 CHAPTER 10 ■ DATABASE TABLES
- Page 447 and 448: 402 CHAPTER 10 ■ DATABASE TABLES
- Page 449 and 450: 404 CHAPTER 10 ■ DATABASE TABLES
- Page 451 and 452: 406 CHAPTER 10 ■ DATABASE TABLES
- Page 453 and 454: 408 CHAPTER 10 ■ DATABASE TABLES
- Page 455 and 456: 410 CHAPTER 10 ■ DATABASE TABLES
- Page 457 and 458: 412 CHAPTER 10 ■ DATABASE TABLES
- Page 459 and 460: 414 CHAPTER 10 ■ DATABASE TABLES
- Page 461 and 462: 416 CHAPTER 10 ■ DATABASE TABLES
- Page 463 and 464: 418 CHAPTER 10 ■ DATABASE TABLES
- Page 466 and 467: CHAPTER 11 ■ ■ ■ Indexes Inde
- Page 468 and 469: CHAPTER 11 ■ INDEXES 423 value of
- Page 470 and 471: CHAPTER 11 ■ INDEXES 425 One of t
- Page 472 and 473: CHAPTER 11 ■ INDEXES 427 We then
- Page 474 and 475: CHAPTER 11 ■ INDEXES 429 we ended
- Page 476 and 477: CHAPTER 11 ■ INDEXES 431 The data
- Page 478 and 479: CHAPTER 11 ■ INDEXES 433 if ( (++
- Page 480 and 481: CHAPTER 11 ■ INDEXES 435 Table 11
388<br />
CHAPTER 10 ■ DATABASE TABLES<br />
Sorted Hash Clustered Tables<br />
Sorted hash clusters are new in <strong>Oracle</strong> 10g. They combine the qualities of the hash cluster just<br />
described with those of an IOT. They are most appropriate when you constantly retrieve data<br />
using a query similar to this:<br />
Select *<br />
From t<br />
Where KEY=:x<br />
Order by SORTED_COLUMN<br />
That is, you retrieve the data by some key <strong>and</strong> need that data ordered by some other column.<br />
Using a sorted hash cluster, <strong>Oracle</strong> can return the data without performing a sort at all. It<br />
accomplishes this by storing the data upon insert in sorted order physically—by key. Suppose<br />
you have a customer order table:<br />
ops$tkyte@ORA10G> select cust_id, order_dt, order_number<br />
2 from cust_orders<br />
3 order by cust_id, order_dt;<br />
CUST_ID ORDER_DT<br />
ORDER_NUMBER<br />
------- ---------------------------- ------------<br />
1 31-MAR-05 09.13.57.000000 PM 21453<br />
11-APR-05 08.30.45.000000 AM 21454<br />
28-APR-05 06.21.09.000000 AM 21455<br />
2 08-APR-05 03.42.45.000000 AM 21456<br />
19-APR-05 08.59.33.000000 AM 21457<br />
27-APR-05 06.35.34.000000 AM 21458<br />
30-APR-05 01.47.34.000000 AM 21459<br />
7 rows selected.<br />
The table is stored in a sorted hash cluster, whereby the HASH key is CUST_ID <strong>and</strong> the field<br />
to sort on is ORDER_DT. Graphically, it might look like Figure 10-10, where 1, 2, 3, 4, . . . represent<br />
the records stored sorted on each block.<br />
Figure 10-10. Sorted hash cluster depiction