Apress.Expert.Oracle.Database.Architecture.9i.and.10g.Programming.Techniques.and.Solutions.Sep.2005
CHAPTER 10 ■ DATABASE TABLES 339 • A table can have a virtually unlimited number of rows, although you will hit other limits that prevent this from happening. For example, typically a tablespace can have at most 1,022 files (although there are new BIGFILE tablespaces in Oracle 10g that will get you beyond these file size limits, too). Say you have 32GB files—that is to say, 32,704GB per tablespace. This would be 2,143,289,344 blocks, each of which is 16KB in size. You might be able to fit 160 rows of between 80 to 100 bytes per block. This would give you 342,926,295,040 rows. If you partition the table, though, you can easily multiply this number many times. For example, consider a table with 1,024 hash partitions—that would be 1024 ✕ 342,926,295,040 rows. There are limits, but you’ll hit other practical limitations before even coming close to these figures. • A table can have as many indexes as there are permutations of columns (and permutations of functions on those columns). With the advent of function-based indexes, the true number of indexes you could create theoretically becomes infinite! Once again, however, practical restrictions will limit the actual number of indexes you will create and maintain. • There is no limit to the number of tables you may have, even within a single database. Yet again, practical limits will keep this number within reasonable bounds. You will not have millions of tables (this many is impracticable to create and manage), but you may have thousands of tables. In the next section, we’ll look at some of the parameters and terminology relevant to tables. After that, we’ll jump into a discussion of the basic heap-organized table, and then move on to examine the other types. Terminology In this section, we will cover the various storage parameters and terminology associated with tables. Not all parameters are used for every table type. For example, the PCTUSED parameter is not meaningful in the context of an IOT. We’ll cover the relevant parameters as part of the discussion of each individual table type. The goal is to introduce the terms and define them. As appropriate, more information on using specific parameters is covered in subsequent sections. Segment A segment in Oracle is an object that consumes storage on disk. While there are many segment types, the most popular are as follows: • Cluster: This segment type is capable of storing tables. There are two types of clusters: B*Tree and hash. Clusters are commonly used to store related data from multiple tables “prejoined” on the same database block and to store related information from a single table together. The term “cluster” refers to this segment’s ability to cluster related information physically together. • Table: A table segment holds data for a database table and is perhaps the most common segment type used in conjunction with an index segment.
340 CHAPTER 10 ■ DATABASE TABLES • Table partition or subpartition: This segment type is used in partitioning and is very similar to a table segment. A table partition or subpartition segment holds just a slice of the data from a table. A partitioned table is made up of one or more table partition segments, and a composite partitioned table is made up of one or more table subpartition segments. • Index: This segment type holds an index structure. • Index partition: Similar to a table partition, this segment type contains some slice of an index. A partitioned index consists of one or more index partition segments. • Lob partition, lob subpartition, lobindex, and lobsegment: The lobindex and lobsegment segments hold the structure of a large object, or LOB. When a table containing a LOB is partitioned, the lobsegment will be partitioned as well—the lob partition segment is used for that. It is interesting to note that there is not a lobindex partition segment type— for whatever reason, Oracle marks the partitioned lobindex as an index partition (one wonders why a lobindex is given a special name!). • Nested table: This is the segment type assigned to nested tables, a special kind of “child” table in a master/detail relationship that we’ll discuss later. • Rollback and Type2 undo: This is where undo data is stored. Rollback segments are those manually created by the DBA. Type2 undo segments are automatically created and managed by Oracle. So, for example, a table may be a segment. An index may be a segment. I stress the words “may be” because we can partition an index into separate segments. So, the index object itself would just be a definition, not a physical segment—and the index would be made up of many index partitions, and each index partition would be a segment. A table may be a segment or not. For the same reason, we might have many table segments due to partitioning, or we might create a table in a segment called a cluster. Here the table will reside, perhaps with other tables in the same cluster segment. The most common case, however, is that a table will be a segment and an index will be a segment. That is the easiest way to think of it for now. When you create a table, you are normally creating a new table segment and, as discussed in Chapter 3, that segment consists of extents, and extents consist of blocks. That is the normal storage hierarchy. But it is important to note that only the “common” case has this one-to-one relationship. For example, consider this simple CREATE TABLE statement: Create table t ( x int primary key, y clob, z blob ); This statement creates six segments. If you issue this CREATE TABLE statement in a schema that owns nothing, you’ll observe the following: ops$tkyte@ORA10G> select segment_name, segment_type 2 from user_segments; no rows selected ops$tkyte@ORA10G> create table t ( x int primary key, y clob, z blob ); Table created.
- Page 333 and 334: 288 CHAPTER 9 ■ REDO AND UNDO The
- 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: 338 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 and 432: 386 CHAPTER 10 ■ DATABASE TABLES
- Page 433 and 434: 388 CHAPTER 10 ■ DATABASE TABLES
CHAPTER 10 ■ DATABASE TABLES 339<br />
• A table can have a virtually unlimited number of rows, although you will hit other limits<br />
that prevent this from happening. For example, typically a tablespace can have at most<br />
1,022 files (although there are new BIGFILE tablespaces in <strong>Oracle</strong> 10g that will get you<br />
beyond these file size limits, too). Say you have 32GB files—that is to say, 32,704GB<br />
per tablespace. This would be 2,143,289,344 blocks, each of which is 16KB in size. You<br />
might be able to fit 160 rows of between 80 to 100 bytes per block. This would give you<br />
342,926,295,040 rows. If you partition the table, though, you can easily multiply this<br />
number many times. For example, consider a table with 1,024 hash partitions—that<br />
would be 1024 ✕ 342,926,295,040 rows. There are limits, but you’ll hit other practical<br />
limitations before even coming close to these figures.<br />
• A table can have as many indexes as there are permutations of columns (<strong>and</strong> permutations<br />
of functions on those columns). With the advent of function-based indexes, the<br />
true number of indexes you could create theoretically becomes infinite! Once again,<br />
however, practical restrictions will limit the actual number of indexes you will create<br />
<strong>and</strong> maintain.<br />
• There is no limit to the number of tables you may have, even within a single database.<br />
Yet again, practical limits will keep this number within reasonable bounds. You will not<br />
have millions of tables (this many is impracticable to create <strong>and</strong> manage), but you<br />
may have thous<strong>and</strong>s of tables.<br />
In the next section, we’ll look at some of the parameters <strong>and</strong> terminology relevant to<br />
tables. After that, we’ll jump into a discussion of the basic heap-organized table, <strong>and</strong> then<br />
move on to examine the other types.<br />
Terminology<br />
In this section, we will cover the various storage parameters <strong>and</strong> terminology associated with<br />
tables. Not all parameters are used for every table type. For example, the PCTUSED parameter is<br />
not meaningful in the context of an IOT. We’ll cover the relevant parameters as part of the discussion<br />
of each individual table type. The goal is to introduce the terms <strong>and</strong> define them. As<br />
appropriate, more information on using specific parameters is covered in subsequent sections.<br />
Segment<br />
A segment in <strong>Oracle</strong> is an object that consumes storage on disk. While there are many segment<br />
types, the most popular are as follows:<br />
• Cluster: This segment type is capable of storing tables. There are two types of clusters:<br />
B*Tree <strong>and</strong> hash. Clusters are commonly used to store related data from multiple tables<br />
“prejoined” on the same database block <strong>and</strong> to store related information from a single<br />
table together. The term “cluster” refers to this segment’s ability to cluster related information<br />
physically together.<br />
• Table: A table segment holds data for a database table <strong>and</strong> is perhaps the most common<br />
segment type used in conjunction with an index segment.