Apress.Expert.Oracle.Database.Architecture.9i.and.10g.Programming.Techniques.and.Solutions.Sep.2005

rekharaghuram
from rekharaghuram More from this publisher
05.11.2015 Views

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.

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.

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!