Apress.Expert.Oracle.Database.Architecture.9i.and.10g.Programming.Techniques.and.Solutions.Sep.2005
CHAPTER 10 ■ DATABASE TABLES 341 ops$tkyte@ORA10G> select segment_name, segment_type 2 from user_segments; SEGMENT_NAME SEGMENT_TYPE ------------------------------ ------------------ SYS_IL0000063631C00002$$ LOBINDEX SYS_LOB0000063631C00003$$ LOBSEGMENT SYS_C009783 INDEX SYS_IL0000063631C00003$$ LOBINDEX SYS_LOB0000063631C00002$$ LOBSEGMENT T TABLE 6 rows selected. The table itself created a segment in this example: the last row in the output. The primary key constraint created an index segment in this case in order to enforce uniqueness. ■Note A unique or primary key constraint may or may not create a new index. If there is an existing index on the constrained columns, and these columns are on the leading edge of the index, the constraint can and will use them. Additionally, each of the LOB columns created two segments: one segment to store the actual chunks of data pointed to by the character large object (CLOB) or binary large object (BLOB) pointer, and one segment to “organize” them. LOBs provide support for very large chunks of information, up to many gigabytes in size. They are stored in chunks in the lobsegment, and the lobindex is used to keep track of where the LOB chunks are and the order in which they should be accessed. Segment Space Management Starting in Oracle9i, there are two methods for managing space in segments: • Manual Segment Space Management: You set various parameters such as FREELISTS, FREELIST GROUPS, PCTUSED, and others to control how space is allocated, used, and reused in a segment over time. I will refer to this space management method in this chapter as MSSM, but bear in mind that that is a made-up abbreviation that you will not find in the Oracle documentation. • Automatic Segment Space Management (ASSM): You control one parameter relating to how space is used: PCTFREE. The others are accepted when the segment is created, but they are ignored. MSSM is the legacy implementation in Oracle. It has been around for many years, over many versions. ASSM was first introduced in Oracle9i Release 1 and its design intention was to eliminate the need to fine-tune the myriad parameters used to control space allocation and provide high concurrency. For example, by having the FREELISTS parameter set to the default
342 CHAPTER 10 ■ DATABASE TABLES of 1, you might find that your insert/update-intensive segments may be suffering from contention on free space allocation. When Oracle goes to insert a row into a table, or update an index key entry, or update a row causing the row to migrate (more on that in a moment as well), it may need to get a block from the list of free blocks associated with the segment. If there is only one list, only one transaction at a time may review and modify this list—they would have to wait for each other. Multiple FREELISTS and FREELIST GROUPS serve the purpose of increasing concurrency in such a case, as the transactions may each be looking at different lists and not contending with each other. When I discuss the storage settings shortly, I will mention which are for manual and which are for automatic segment space management, but in the area of storage/segment characteristics, the only storage settings that apply to ASSM segments are as follows: • BUFFER_POOL • PCTFREE • INITRANS • MAXTRANS (only in 9i; in 10g this is ignored for all segments) The remaining storage and physical attribute parameters do not apply to ASSM segments. Segment space management is an attribute inherited from the tablespace in which a segment is contained (and segments never span tablespaces). For a segment to use ASSM, it would have to reside in a tablespace that supported that method of space management. High-Water Mark This is a term used with table segments stored in the database. If you envision a table, for example, as a “flat” structure or as a series of blocks laid one after the other in a line from left to right, the high-water mark (HWM) would be the rightmost block that ever contained data, as illustrated in Figure 10-1. Figure 10-1 shows that the HWM starts at the first block of a newly created table. As data is placed into the table over time and more blocks get used, the HWM rises. If we delete some (or even all) of the rows in the table, we might have many blocks that no longer contain data, but they are still under the HWM, and they will remain under the HWM until the object is rebuilt, truncated, or shrunk (shrinking of a segment is a new Oracle 10g feature that is supported only if the segment is in an ASSM tablespace). The HWM is relevant since Oracle will scan all blocks under the HWM, even when they contain no data, during a full scan. This will impact the performance of a full scan—especially if most of the blocks under the HWM are empty. To see this, just create a table with 1,000,000 rows (or create any table with a large number of rows), and then execute a SELECT COUNT(*) from this table. Now, DELETE every row in it and you will find that the SELECT COUNT(*) takes just as long (or longer, if you need to clean out the block; refer to the “Block Cleanout” section of Chapter 9) to count 0 rows as it did to count 1,000,000. This is because Oracle is busy reading all of the blocks below the HWM to see if they contain data. You should compare this to what happens if you used TRUNCATE on the table instead of deleting each individual row. TRUNCATE will reset the HWM of a table back to “zero” and will truncate the associated indexes on the table as well. If you plan on deleting every row in a table, TRUNCATE—if it can be used— would be the method of choice for this reason.
- Page 335 and 336: 290 CHAPTER 9 ■ REDO AND UNDO We
- Page 337 and 338: 292 CHAPTER 9 ■ REDO AND UNDO Wha
- Page 339 and 340: 294 CHAPTER 9 ■ REDO AND UNDO row
- 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: 340 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 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
CHAPTER 10 ■ DATABASE TABLES 341<br />
ops$tkyte@ORA10G> select segment_name, segment_type<br />
2 from user_segments;<br />
SEGMENT_NAME<br />
SEGMENT_TYPE<br />
------------------------------ ------------------<br />
SYS_IL0000063631C00002$$ LOBINDEX<br />
SYS_LOB0000063631C00003$$ LOBSEGMENT<br />
SYS_C009783<br />
INDEX<br />
SYS_IL0000063631C00003$$ LOBINDEX<br />
SYS_LOB0000063631C00002$$ LOBSEGMENT<br />
T<br />
TABLE<br />
6 rows selected.<br />
The table itself created a segment in this example: the last row in the output. The primary<br />
key constraint created an index segment in this case in order to enforce uniqueness.<br />
■Note A unique or primary key constraint may or may not create a new index. If there is an existing index<br />
on the constrained columns, <strong>and</strong> these columns are on the leading edge of the index, the constraint can <strong>and</strong><br />
will use them.<br />
Additionally, each of the LOB columns created two segments: one segment to store the<br />
actual chunks of data pointed to by the character large object (CLOB) or binary large object<br />
(BLOB) pointer, <strong>and</strong> one segment to “organize” them. LOBs provide support for very large<br />
chunks of information, up to many gigabytes in size. They are stored in chunks in the lobsegment,<br />
<strong>and</strong> the lobindex is used to keep track of where the LOB chunks are <strong>and</strong> the order in<br />
which they should be accessed.<br />
Segment Space Management<br />
Starting in <strong>Oracle</strong>9i, there are two methods for managing space in segments:<br />
• Manual Segment Space Management: You set various parameters such as FREELISTS,<br />
FREELIST GROUPS, PCTUSED, <strong>and</strong> others to control how space is allocated, used, <strong>and</strong><br />
reused in a segment over time. I will refer to this space management method in this<br />
chapter as MSSM, but bear in mind that that is a made-up abbreviation that you will<br />
not find in the <strong>Oracle</strong> documentation.<br />
• Automatic Segment Space Management (ASSM): You control one parameter relating to<br />
how space is used: PCTFREE. The others are accepted when the segment is created, but<br />
they are ignored.<br />
MSSM is the legacy implementation in <strong>Oracle</strong>. It has been around for many years, over<br />
many versions. ASSM was first introduced in <strong>Oracle</strong>9i Release 1 <strong>and</strong> its design intention was<br />
to eliminate the need to fine-tune the myriad parameters used to control space allocation <strong>and</strong><br />
provide high concurrency. For example, by having the FREELISTS parameter set to the default