Apress.Expert.Oracle.Database.Architecture.9i.and.10g.Programming.Techniques.and.Solutions.Sep.2005
CHAPTER 10 ■ DATABASE TABLES 375 7 dept.deptno 8 from emp, dept 9 where emp.deptno = dept.deptno 10 ) 11 order by deptno 12 / DEPT_BLK EMP_BLK F DEPTNO ---------- ---------- - ---------- 12 12 10 12 12 10 12 12 10 11 11 20 11 11 20 11 11 20 11 12 * 20 11 11 20 10 10 30 10 10 30 10 10 30 10 10 30 10 10 30 10 11 * 30 14 rows selected. ■Note Your mileage may vary here, as the order in which the rows are fetched from the SCOTT.DEPT table can and will change the results, and the use of ASSM versus MSSM may as well. The concept should be clear, however: if you put the row for DEPTNO=n on a given block, and then the employee rows for DEPTNO=n, you should achieve the best clustering possible. Most of the EMP rows are on the same block as the DEPT rows. This example is somewhat contrived in that I woefully undersized the SIZE parameter on the cluster to make a point, but the approach suggested is correct for an initial load of a cluster. It will ensure that if for some of the cluster keys, you exceed the estimated SIZE, you will still end up with most of the data clustered on the same block. If you load a table at a time, you will not. This technique applies only to the initial load of a cluster—after that, you would use it as your transactions deem necessary. You will not adapt your application to work specifically with a cluster. Here is a bit of puzzle to amaze and astound your friends with. Many people mistakenly believe a rowid uniquely identifies a row in a database, and that given a rowid you can tell what table the row came from. In fact, you cannot. You can and will get duplicate rowids from a cluster. For example, after executing the preceding code you should find
376 CHAPTER 10 ■ DATABASE TABLES ops$tkyte@ORA10GR1> select rowid from emp 2 intersect 3 select rowid from dept; ROWID ------------------ AAAOniAAJAAAAAKAAA AAAOniAAJAAAAAKAAB AAAOniAAJAAAAALAAA AAAOniAAJAAAAAMAAA Every rowid assigned to the rows in DEPT has been assigned to the rows in EMP as well. That is because it takes a table and row ID to uniquely identify a row. The rowid pseudo-column is unique only within a table. I also find that many people believe the cluster object to be an esoteric object that no one really uses—everyone just uses normal tables. The fact is, you use clusters every time you use Oracle. Much of the data dictionary is stored in various clusters, for example: sys@ORA10GR1> break on cluster_name sys@ORA10GR1> select cluster_name, table_name 2 from user_tables 3 where cluster_name is not null 4 order by 1; CLUSTER_NAME TABLE_NAME ------------------------------ ------------------------------ C_COBJ# CCOL$ CDEF$ C_FILE#_BLOCK# UET$ SEG$ C_MLOG# MLOG$ SLOG$ C_OBJ# ICOL$ CLU$ COL$ TYPE_MISC$ VIEWTRCOL$ ATTRCOL$ SUBCOLTYPE$ COLTYPE$ LOB$ TAB$ IND$ ICOLDEP$ OPQTYPE$ REFCON$
- Page 369 and 370: 324 CHAPTER 9 ■ REDO AND UNDO ops
- Page 371 and 372: 326 CHAPTER 9 ■ REDO AND UNDO wil
- Page 373 and 374: 328 CHAPTER 9 ■ REDO AND UNDO Thi
- Page 375 and 376: 330 CHAPTER 9 ■ REDO AND UNDO ops
- Page 377 and 378: 332 CHAPTER 9 ■ REDO AND UNDO Whe
- Page 379 and 380: 334 CHAPTER 9 ■ REDO AND UNDO Tha
- 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: 374 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 and 432: 386 CHAPTER 10 ■ DATABASE TABLES
- Page 433 and 434: 388 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
376<br />
CHAPTER 10 ■ DATABASE TABLES<br />
ops$tkyte@ORA10GR1> select rowid from emp<br />
2 intersect<br />
3 select rowid from dept;<br />
ROWID<br />
------------------<br />
AAAOniAAJAAAAAKAAA<br />
AAAOniAAJAAAAAKAAB<br />
AAAOniAAJAAAAALAAA<br />
AAAOniAAJAAAAAMAAA<br />
Every rowid assigned to the rows in DEPT has been assigned to the rows in EMP as well. That<br />
is because it takes a table <strong>and</strong> row ID to uniquely identify a row. The rowid pseudo-column is<br />
unique only within a table.<br />
I also find that many people believe the cluster object to be an esoteric object that no one<br />
really uses—everyone just uses normal tables. The fact is, you use clusters every time you use<br />
<strong>Oracle</strong>. Much of the data dictionary is stored in various clusters, for example:<br />
sys@ORA10GR1> break on cluster_name<br />
sys@ORA10GR1> select cluster_name, table_name<br />
2 from user_tables<br />
3 where cluster_name is not null<br />
4 order by 1;<br />
CLUSTER_NAME<br />
TABLE_NAME<br />
------------------------------ ------------------------------<br />
C_COBJ#<br />
CCOL$<br />
CDEF$<br />
C_FILE#_BLOCK#<br />
UET$<br />
SEG$<br />
C_MLOG#<br />
MLOG$<br />
SLOG$<br />
C_OBJ#<br />
ICOL$<br />
CLU$<br />
COL$<br />
TYPE_MISC$<br />
VIEWTRCOL$<br />
ATTRCOL$<br />
SUBCOLTYPE$<br />
COLTYPE$<br />
LOB$<br />
TAB$<br />
IND$<br />
ICOLDEP$<br />
OPQTYPE$<br />
REFCON$