Apress.Expert.Oracle.Database.Architecture.9i.and.10g.Programming.Techniques.and.Solutions.Sep.2005
CHAPTER 10 ■ DATABASE TABLES 347 ops$tkyte@ORA10GR1> create tablespace assm 2 datafile size 1m autoextend on next 1m 3 segment space management auto; Tablespace created. ops$tkyte@ORA10GR1> create table t ( x int, y char(50) ) tablespace ASSM; Table created. you’ll find the buffer busy waits, CPU time, and elapsed time to have decreased for this case as well—without having to figure out the optimum number of required freelists: Snap Id Snap Time Sessions Curs/Sess Comment --------- ------------------ -------- --------- ------------------- Begin Snap: 812 29-Apr-05 14:12:37 15 3.9 End Snap: 813 29-Apr-05 14:13:07 15 5.6 Elapsed: 0.50 (mins) Top 5 Timed Events ~~~~~~~~~~~~~~~~~~ % Total Event Waits Time (s) Call Time -------------------------------------------- ------------ ----------- --------- CPU time 107 78.54 log file parallel write 705 12 9.13 buffer busy waits 12,485 12 8.52 latch: library cache 68 1 .70 LGWR wait for redo copy 3,794 1 .47 This is one of ASSM’s main purposes: to remove the need to manually determine the correct settings for many key storage parameters. PCTFREE and PCTUSED In general, the PCTFREE parameter tells Oracle how much space should be reserved on a block for future updates. By default, this is 10 percent. If there is a higher percentage of free space than the value specified in PCTFREE, then the block is considered to be “free.” PCTUSED tells Oracle the percentage of free space that needs to be present on a block that is not currently “free” in order for it to become free again. The default value is 40 percent. As noted earlier, when used with a table (but not an IOT, as we’ll see), PCTFREE tells Oracle how much space should be reserved on a block for future updates. This means if we use an 8KB blocksize, as soon as the addition of a new row onto a block causes the free space on the block to drop below about 800 bytes, Oracle will use another block from the FREELIST instead of the existing block. This 10 percent of the data space on the block is set aside for updates to the rows on that block.
348 CHAPTER 10 ■ DATABASE TABLES ■Note PCTFREE and PCTUSED are implemented differently for different table types. Some table types employ both, whereas others only use PCTFREE, and even then only when the object is created. IOTs use PCTFREE upon creation to set aside space in the table for future updates, but do not use PCTFREE to decide when to stop inserting rows into a given block, for example. The exact effect of these two parameters varies depending on whether you are using ASSM or MSSM tablespaces. When you are using MSSM, these parameter settings control when the block will be put on and taken off the freelist. If you are using the default values for PCTFREE (10) and PCTUSED (40), then a block will remain on the freelist until it is 90 percent full (10 percent free space). Once it hits 90 percent, it will be taken off the freelist and remain off the freelist until the free space on the block exceeds 60 percent of the block. When you are using ASSM, PCTFREE still limits if a new row may be inserted into a block, but it does not control whether a block is on a freelist or not, as ASSM does not use freelists at all. In ASSM, PCTUSED is simply ignored. There are three settings for PCTFREE: too high, too low, and just about right. If you set PCTFREE for blocks too high, you will waste space. If you set PCTFREE to 50 percent and you never update the data, you have just wasted 50 percent of every block. On another table, however, 50 percent may be very reasonable. If the rows start out small and tend to double in size, setting PCTFREE too small will cause row migration as you update the rows. Row Migration What exactly is row migration? Row migration is when a row is forced to leave the block it was created on because it grew too large to fit on that block with the rest of the rows. I’ll illustrate a row migration in this section. We’ll start with a block that looks like Figure 10-3. Figure 10-3. Data block before update Approximately one-seventh of the block is free space. However, we would like to more than double the amount of space used by row 4 via an UPDATE (it currently consumes oneseventh of the block). In this case, even if Oracle coalesced the space on the block as shown in Figure 10-4, there is still insufficient room double the size of row 4 because the size of the free space is less than the current size of row 4.
- Page 341 and 342: 296 CHAPTER 9 ■ REDO AND UNDO If
- Page 343 and 344: 298 CHAPTER 9 ■ REDO AND UNDO ops
- Page 345 and 346: 300 CHAPTER 9 ■ REDO AND UNDO Inv
- 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: 346 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 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
348<br />
CHAPTER 10 ■ DATABASE TABLES<br />
■Note PCTFREE <strong>and</strong> PCTUSED are implemented differently for different table types. Some table types<br />
employ both, whereas others only use PCTFREE, <strong>and</strong> even then only when the object is created. IOTs use<br />
PCTFREE upon creation to set aside space in the table for future updates, but do not use PCTFREE to decide<br />
when to stop inserting rows into a given block, for example.<br />
The exact effect of these two parameters varies depending on whether you are using<br />
ASSM or MSSM tablespaces. When you are using MSSM, these parameter settings control<br />
when the block will be put on <strong>and</strong> taken off the freelist. If you are using the default values for<br />
PCTFREE (10) <strong>and</strong> PCTUSED (40), then a block will remain on the freelist until it is 90 percent full<br />
(10 percent free space). Once it hits 90 percent, it will be taken off the freelist <strong>and</strong> remain off<br />
the freelist until the free space on the block exceeds 60 percent of the block.<br />
When you are using ASSM, PCTFREE still limits if a new row may be inserted into a block,<br />
but it does not control whether a block is on a freelist or not, as ASSM does not use freelists at<br />
all. In ASSM, PCTUSED is simply ignored.<br />
There are three settings for PCTFREE: too high, too low, <strong>and</strong> just about right. If you set<br />
PCTFREE for blocks too high, you will waste space. If you set PCTFREE to 50 percent <strong>and</strong> you<br />
never update the data, you have just wasted 50 percent of every block. On another table, however,<br />
50 percent may be very reasonable. If the rows start out small <strong>and</strong> tend to double in size,<br />
setting PCTFREE too small will cause row migration as you update the rows.<br />
Row Migration<br />
What exactly is row migration? Row migration is when a row is forced to leave the block it was<br />
created on because it grew too large to fit on that block with the rest of the rows. I’ll illustrate a<br />
row migration in this section. We’ll start with a block that looks like Figure 10-3.<br />
Figure 10-3. Data block before update<br />
Approximately one-seventh of the block is free space. However, we would like to more<br />
than double the amount of space used by row 4 via an UPDATE (it currently consumes oneseventh<br />
of the block). In this case, even if <strong>Oracle</strong> coalesced the space on the block as shown<br />
in Figure 10-4, there is still insufficient room double the size of row 4 because the size of the<br />
free space is less than the current size of row 4.