Apress.Expert.Oracle.Database.Architecture.9i.and.10g.Programming.Techniques.and.Solutions.Sep.2005
CHAPTER 10 ■ DATABASE TABLES 353 That aside, what is important to know about heap tables? Well, the CREATE TABLE syntax spans some 72 pages in the Oracle SQL Reference manual, so there are lots of options that go along with them. There are so many options that getting a hold on all of them is pretty difficult. The “wire diagrams” (or “train track” diagrams) alone take 18 pages to cover. One trick I use to see most of the options available to me in the CREATE TABLE statement for a given table is to create the table as simply as possible, for example: ops$tkyte@ORA10GR1> create table t 2 ( x int primary key, 3 y date, 4 z clob 5 ) 6 / Table created. Then, using the standard supplied package DBMS_METADATA, I query the definition of it and see the verbose syntax: ops$tkyte@ORA10GR1> select dbms_metadata.get_ddl( 'TABLE', 'T' ) from dual; DBMS_METADATA.GET_DDL('TABLE','T') ------------------------------------------------------------------------------- CREATE TABLE "OPS$TKYTE"."T" ( "X" NUMBER(*,0), "Y" DATE, "Z" CLOB, PRIMARY KEY ("X") USING INDEX PCTFREE 10 INITRANS 2 MAXTRANS 255 STORAGE(INITIAL 65536 NEXT 1048576 MINEXTENTS 1 MAXEXTENTS 2147483645 PCTINCREASE 0 FREELISTS 1 FREELIST GROUPS 1 BUFFER_POOL DEFAULT) TABLESPACE "USERS" ENABLE ) PCTFREE 10 PCTUSED 40 INITRANS 1 MAXTRANS 255 NOCOMPRESS LOGGING STORAGE(INITIAL 65536 NEXT 1048576 MINEXTENTS 1 MAXEXTENTS 2147483645 PCTINCREASE 0 FREELISTS 1 FREELIST GROUPS 1 BUFFER_POOL DEFAULT) TABLESPACE "USERS" LOB ("Z") STORE AS ( TABLESPACE "USERS" ENABLE STORAGE IN ROW CHUNK 8192 PCTVERSION 10 NOCACHE STORAGE(INITIAL 65536 NEXT 1048576 MINEXTENTS 1 MAXEXTENTS 2147483645 PCTINCREASE 0 FREELISTS 1 FREELIST GROUPS 1 BUFFER_POOL DEFAULT)) The nice thing about this trick is that it shows many of the options for my CREATE TABLE statement. I just have to pick data types and such, and Oracle will produce the verbose version for me. I can now customize this verbose version, perhaps changing the ENABLE STORAGE IN ROW to DISABLE STORAGE IN ROW, which would disable the storage of the LOB data in the row with the structured data, causing it to be stored in another segment. I use this trick all of the time to save the couple minutes of confusion I would otherwise have if I were trying to figure this all out from the huge wire diagrams. I can also use this technique to learn what options are available to me on the CREATE TABLE statement under different circumstances.
354 CHAPTER 10 ■ DATABASE TABLES Now that you know how to see most of the options available to you on a given CREATE TABLE statement, which are the important ones you need to be aware of for heap tables? In my opinion, there are two with ASSM and four with MSSM: • FREELISTS: MSSM only. Every table manages the blocks it has allocated in the heap on a freelist. A table may have more than one freelist. If you anticipate heavy insertion into a table by many concurrent users, configuring more than one freelist can have a major positive impact on performance (at the cost of possible additional storage). Refer to the previous discussion and example in the section “FREELISTS” for the sort of impact this setting can have on performance. • PCTFREE: Both ASSM and MSSM. A measure of how full a block can be is made during the INSERT process. As shown earlier, this is used to control whether a row may be added to a block or not based on how full the block currently is. This option is also used to control row migrations caused by subsequent updates and needs to be set based on how you use the table. • PCTUSED: MSSM only. A measure of how empty a block must become before it can be a candidate for insertion again. A block that has less than PCTUSED space used is a candidate for insertion of new rows. Again, like PCTFREE, you must consider how you will be using your table to set this option appropriately. • INITRANS: Both ASSM and MSSM. The number of transaction slots initially allocated to a block. If set too low (it defaults to and has a minimum of 2), this option can cause concurrency issues in a block that is accessed by many users. If a database block is nearly full and the transaction list cannot be dynamically expanded, sessions will queue up waiting for this block, as each concurrent transaction needs a transaction slot. If you believe you will have many concurrent updates to the same blocks, you should consider increasing this value ■Note LOB data that is stored out of line in the LOB segment does not make use of the PCTFREE/PCTUSED parameters set for the table. These LOB blocks are managed differently: they are always filled to capacity and returned to the freelist only when completely empty. These are the parameters you want to pay particularly close attention to. With the introduction of locally managed tablespaces, which are highly recommended, I find that the rest of the storage parameters (such as PCTINCREASE, NEXT, and so on) are simply not relevant anymore. Index Organized Tables Index organized tables (IOTs) are, quite simply, tables stored in an index structure. Whereas a table stored in a heap is unorganized (i.e., data goes wherever there is available space), data in an IOT is stored and sorted by primary key. IOTs behave just like “regular” tables do as far as your application is concerned; you use SQL to access them as normal. They are especially useful for information retrieval, spatial, and OLAP applications.
- Page 347 and 348: 302 CHAPTER 9 ■ REDO AND UNDO The
- Page 349 and 350: 304 CHAPTER 9 ■ REDO AND UNDO 41
- Page 351 and 352: 306 CHAPTER 9 ■ REDO AND UNDO ins
- Page 353 and 354: 308 CHAPTER 9 ■ REDO AND UNDO So,
- Page 355 and 356: 310 CHAPTER 9 ■ REDO AND UNDO ops
- Page 357 and 358: 312 CHAPTER 9 ■ REDO AND UNDO ops
- Page 359 and 360: 314 CHAPTER 9 ■ REDO AND UNDO •
- Page 361 and 362: 316 CHAPTER 9 ■ REDO AND UNDO ...
- Page 363 and 364: 318 CHAPTER 9 ■ REDO AND UNDO •
- Page 365 and 366: 320 CHAPTER 9 ■ REDO AND UNDO bac
- Page 367 and 368: 322 CHAPTER 9 ■ REDO AND UNDO As
- 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: 352 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 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
354<br />
CHAPTER 10 ■ DATABASE TABLES<br />
Now that you know how to see most of the options available to you on a given CREATE TABLE<br />
statement, which are the important ones you need to be aware of for heap tables? In my opinion,<br />
there are two with ASSM <strong>and</strong> four with MSSM:<br />
• FREELISTS: MSSM only. Every table manages the blocks it has allocated in the heap on a<br />
freelist. A table may have more than one freelist. If you anticipate heavy insertion into<br />
a table by many concurrent users, configuring more than one freelist can have a major<br />
positive impact on performance (at the cost of possible additional storage). Refer to the<br />
previous discussion <strong>and</strong> example in the section “FREELISTS” for the sort of impact this<br />
setting can have on performance.<br />
• PCTFREE: Both ASSM <strong>and</strong> MSSM. A measure of how full a block can be is made during<br />
the INSERT process. As shown earlier, this is used to control whether a row may be added<br />
to a block or not based on how full the block currently is. This option is also used to<br />
control row migrations caused by subsequent updates <strong>and</strong> needs to be set based on<br />
how you use the table.<br />
• PCTUSED: MSSM only. A measure of how empty a block must become before it can be a<br />
c<strong>and</strong>idate for insertion again. A block that has less than PCTUSED space used is a c<strong>and</strong>idate<br />
for insertion of new rows. Again, like PCTFREE, you must consider how you will be<br />
using your table to set this option appropriately.<br />
• INITRANS: Both ASSM <strong>and</strong> MSSM. The number of transaction slots initially allocated<br />
to a block. If set too low (it defaults to <strong>and</strong> has a minimum of 2), this option can cause<br />
concurrency issues in a block that is accessed by many users. If a database block is<br />
nearly full <strong>and</strong> the transaction list cannot be dynamically exp<strong>and</strong>ed, sessions will<br />
queue up waiting for this block, as each concurrent transaction needs a transaction<br />
slot. If you believe you will have many concurrent updates to the same blocks, you<br />
should consider increasing this value<br />
■Note LOB data that is stored out of line in the LOB segment does not make use of the PCTFREE/PCTUSED<br />
parameters set for the table. These LOB blocks are managed differently: they are always filled to capacity<br />
<strong>and</strong> returned to the freelist only when completely empty.<br />
These are the parameters you want to pay particularly close attention to. With the introduction<br />
of locally managed tablespaces, which are highly recommended, I find that the rest of<br />
the storage parameters (such as PCTINCREASE, NEXT, <strong>and</strong> so on) are simply not relevant anymore.<br />
Index Organized Tables<br />
Index organized tables (IOTs) are, quite simply, tables stored in an index structure. Whereas a<br />
table stored in a heap is unorganized (i.e., data goes wherever there is available space), data in<br />
an IOT is stored <strong>and</strong> sorted by primary key. IOTs behave just like “regular” tables do as far as<br />
your application is concerned; you use SQL to access them as normal. They are especially useful<br />
for information retrieval, spatial, <strong>and</strong> OLAP applications.