Oracle8i Administrator's Guide
Release 2 (8.1.6)

Part Number A76956-01

Library

Product

Contents

Index

Go to previous page Go to next page

12
Guidelines for Managing Schema Objects

This chapter describes guidelines for managing schema objects, and includes the following topics:

You should familiarize yourself with the concepts in this chapter before attempting to manage specific schema objects as described in Chapters 13-18.

Managing Space in Data Blocks

This section describes the various aspects of managing space in data blocks. The PCTFREE and PCTUSED parameters are discussed, which allow you to:

The following topics are included:

The PCTFREE Parameter

The PCTFREE parameter is used to set the percentage of a block to be reserved for possible updates to rows that already are contained in that block. For example, assume that you specify the following parameter within a CREATE TABLE statement:

PCTFREE 20 

This indicates that 20% of each data block used for this table's data segment will be kept free and available for possible updates to the existing rows already within each block. Figure 12-1 illustrates PCTFREE.

Figure 12-1 PCTFREE


Text description of schema4.gif follows.

Text description of the illustration schema4.gif.

Notice that before the block reaches PCTFREE, the free space of the data block is filled by both the insertion of new rows and by the growth of the data block header.

Specifying PCTFREE

The default for PCTFREE is 10 percent. You can use any integer between 0 and 99, inclusive, as long as the sum of PCTFREE and PCTUSED does not exceed 100.

A smaller PCTFREE has the following effects:

A small PCTFREE might be suitable, for example, for a segment that is rarely changed.

A larger PCTFREE has the following effects:

A large PCTFREE is suitable, for example, for segments that are frequently updated.

Ensure that you understand the nature of the table or index data before setting PCTFREE. Updates can cause rows to grow. New values might not be the same size as values they replace. If there are many updates in which data values get larger, PCTFREE should be increased. If updates to rows do not affect the total row width, PCTFREE can be low. Your goal is to find a satisfactory trade-off between densely packed data and good update performance.

PCTFREE for Nonclustered Tables If the data in the rows of a nonclustered table is likely to increase in size over time, reserve some space for these updates. Otherwise, updated rows are likely to be chained among blocks.

PCTFREE for Clustered Tables The discussion for nonclustered tables also applies to clustered tables. However, if PCTFREE is reached, new rows from any table contained in the same cluster key go into a new data block that is chained to the existing cluster key.

PCTFREE for Indexes You can specify PCTFREE only when initially creating an index.

The PCTUSED Parameter

After a data block becomes full as determined by PCTFREE, Oracle does not consider the block for the insertion of new rows until the percentage of the block being used falls below the parameter PCTUSED. Before this value is achieved, Oracle uses the free space of the data block only for updates to rows already contained in the data block. For example, assume that you specify the following parameter within a CREATE TABLE statement:

PCTUSED 40 

In this case, a data block used for this table's data segment is not considered for the insertion of any new rows until the amount of used space in the block falls to 39% or less (assuming that the block's used space has previously reached PCTFREE). Figure 12-2 illustrates this.

Figure 12-2 PCTUSED


Text description of schema3.gif follows.

Text description of the illustration schema3.gif.

Specifying PCTUSED

The default value for PCTUSED is 40 percent. After the free space in a data block reaches PCTFREE, no new rows are inserted in that block until the percentage of space used falls below PCTUSED. The percent value is for the block space available for data after overhead is subtracted from total space.

You can specify any integer between 0 and 99 (inclusive) for PCTUSED, as long as the sum of PCTUSED and PCTFREE does not exceed 100.

A smaller PCTUSED has the following effects:

A larger PCTUSED has the following effects:

Selecting Associated PCTUSED and PCTFREE Values

If you decide not to use the default values for PCTFREE or PCTUSED, keep the following guidelines in mind:

Examples of Choosing PCTFREE and PCTUSED Values

The following examples show how and why specific values for PCTFREE and PCTUSED are specified for tables.

Example 1 

Scenario: 

Common activity includes UPDATE statements that increase the size of the rows. 

 

Settings: 

PCTFREE = 20

PCTUSED = 40 

Example 2 

Scenario: 

Most activity includes INSERT and DELETE statements, and UPDATE statements that do not increase the size of affected rows. 

 

Settings: 

PCTFREE = 5

PCTUSED = 60 

 

Explanation: 

PCTFREE is set to 5 because most
UPDATE statements do not increase row
sizes. PCTUSED is set to 60 so that space
freed by DELETE statements is used soon,
yet processing is minimized. 

Example 3 

Scenario: 

The table is very large; therefore,
storage is a primary concern. Most activity includes read-only transactions. 

 

Settings: 

PCTFREE = 5

PCTUSED = 40 

 

Explanation: 

PCTFREE is set to 5 because this is a large table and you want to completely fill each block.  

Transaction Entry Settings (INITRANS and MAXTRANS)

The INITRANS and MAXTRANS transaction entry settings for the data blocks allocated for a table, cluster, or index should be set individually for each object based on the following criteria:

For example, if a table is very large and only a small number of users simultaneously access the table, the chances of multiple concurrent transactions requiring access to the same data block is low. Therefore, INITRANS can be set low, especially if space is at a premium in the database.

Alternatively, assume that a table is usually accessed by many users at the same time. In this case, you might consider preallocating transaction entry space by using a high INITRANS (to eliminate the overhead of having to allocate transaction entry space, as required when the object is in use) and allowing a higher MAXTRANS so that no user has to wait to access necessary data blocks.

See Also:

For syntax and specific details of the INITRANS and MAXTRANS parameters, refer to the Oracle8i SQL Reference. 

INITRANS

Specifies the number of DML transaction entries for which space should be initially reserved in the data block header. Space is reserved in the headers of all data blocks in the associated data or index segment. The default value is 1 for tables and 2 for clusters and indexes.

MAXTRANS

As multiple transactions concurrently access the rows of the same data block, space is allocated for each DML transaction's entry in the block. Once the space reserved by INITRANS is depleted, space for additional transaction entries is allocated out of the free space in a block, if available. Once allocated, this space effectively becomes a permanent part of the block header. The MAXTRANS parameter limits the number of transaction entries that can concurrently use data in a data block. Therefore, you can limit the amount of free space that can be allocated for transaction entries in a data block using MAXTRANS.

The default value is an operating system-specific function of block size, not exceeding 255.

Setting Storage Parameters

This section describes the storage parameters that you can set for various data structures. These storage parameters apply to the following types of structures and schema objects:

The following topics are discussed:

Identifying the Storage Parameters

Every database has default values for storage parameters. But, you can specify new defaults for a tablespace, which override the system defaults to become the defaults for objects created in that tablespace only. These default storage values are specified in the DEFAULT STORAGE clause of a CREATE or ALTER TABLESPACE statement.

Furthermore, you can specify storage settings for each individual schema object, which override any default storage settings. To do so, you use the STORAGE clause of the CREATE or ALTER statement for the individual object.

Storage parameters are specified when you create a schema object, and may later be altered. Not all storage parameters can be specified for every type of database object, and not all storage parameters can be specified in both the CREATE and ALTER statements. To set or change the value of a storage parameter, you must have the privileges necessary to use the appropriate CREATE or ALTER statement.

The following sections identify the storage parameters that you can specify.

See Also:

Detailed information about storage parameters, including information on how Oracle rounds values and usage restrictions, is contained in the Oracle8i SQL Reference.

The settings for some storage values are operating system specific. Refer to your operating system-specific documentation for information on those values. 

INITIAL

The size, in bytes, of the first extent allocated when a segment is created. This parameter can not be specified on an ALTER statement.

Default: 

5 data blocks 

Minimum: 

2 data blocks (nonbitmapped segments), 3 data blocks (bitmapped segments)  

Maximum: 

Operating system specific 

NEXT

The size, in bytes, of the next incremental extent to be allocated for a segment. The second extent is equal to the original setting for NEXT. From there forward, NEXT is set to the previous size of NEXT multiplied by (1 + PCTINCREASE/100).

Default: 

5 data blocks 

Minimum: 

1 data block 

Maximum: 

Operating system specific 

PCTINCREASE

The percentage by which each incremental extent grows over the last incremental extent allocated for a segment. If PCTINCREASE is 0, then all incremental extents are the same size. If PCTINCREASE is greater than zero, then each time NEXT is calculated, it grows by PCTINCREASE. PCTINCREASE cannot be negative.

The new NEXT equals 1 + PCTINCREASE/100, multiplied by the size of the last incremental extent (the old NEXT) and rounded up to the next multiple of a block size.

Default: 

50 (%) 

Minimum: 

0 (%) 

Maximum: 

Operating system specific 

MINEXTENTS

The total number of extents to be allocated when the segment is created. This allows for a large allocation of space at creation time, even if contiguous space is not available.

Default: 

1 (extent); 2(extents) for rollback segments 

Minimum: 

1 (extent); 2 (extents) for rollback segments 

Maximum: 

Operating system specific 

MAXEXTENTS

The total number of extents, including the first, that can ever be allocated for the segment.

Default: 

Depends on the data block size and operating system 

Minimum: 

1 (extent); 2(extents) for rollback segments 

Maximum: 

Unlimited 

FREELIST GROUPS

The number of groups of free lists for the database object you are creating. Oracle uses the instance number of Oracle Parallel Server instances to map each instance to one free list group.

Default: 

Minimum: 

Maximum: 

Depends on number of Oracle Parallel Server instances 

For information on the use of this parameter, see Oracle8i Parallel Server Administration, Deployment, and Performance.

FREELISTS

Specifies the number of free lists for each of the free list groups for the schema object. Not valid for tablespaces.

Default: 

Minimum: 

Maximum: 

Depends on data block size 

The use of this parameter is discussed in Oracle8i Designing and Tuning for Performance.

OPTIMAL

Relevant only to rollback segments. See Chapter 11, "Managing Rollback Segments" for information on the use of this parameter.

BUFFER_POOL

Defines a default buffer pool (cache) for a schema object. Not valid for tablespaces or rollback segments. For information on the use of this parameter, see Oracle8i Designing and Tuning for Performance.

Setting Default Storage Parameters for Segments in a Tablespace

You can set default storage parameters for each tablespace of a database. Any storage parameter that you do not explicitly set when creating or subsequently altering a segment in a tablespace automatically is set to the corresponding default storage parameter for the tablespace in which the segment resides.

When specifying MINEXTENTS at the tablespace level, any extent allocated in the tablespace is rounded to a multiple of the number of minimum extents. Basically, the number of extents is a multiple of the number of blocks.

Setting Storage Parameters for Data Segments

You set the storage parameters for the data segment of a nonclustered table, snapshot, or snapshot log using the STORAGE clause of the CREATE or ALTER statement for tables, snapshots, or snapshot logs.

In contrast, you set the storage parameters for the data segments of a cluster using the STORAGE clause of the CREATE CLUSTER or ALTER CLUSTER statement, rather than the individual CREATE or ALTER statements that put tables and snapshots into the cluster. Storage parameters specified when creating or altering a clustered table or snapshot are ignored. The storage parameters set for the cluster override the table's storage parameters.

With partitioned tables, you can set default storage parameters at the table level. When creating a new partition of the table, the default storage parameters are inherited from the table level (unless you specify them for the individual partition). If no storage parameters are specified at the table level, then they are inherited from the tablespace.

Setting Storage Parameters for Index Segments

Storage parameters for an index segment created for a table index can be set using the STORAGE clause of the CREATE INDEX or ALTER INDEX statement. Storage parameters of an index segment created for the index used to enforce a primary key or unique key constraint can be set in the ENABLE clause of the CREATE TABLE or ALTER TABLE statements or the STORAGE clause of the ALTER INDEX statement.

Setting Storage Parameters for LOBs, Varrays, and Nested Tables

A table or snapshot may contain LOB, varray, or nested table column types. These entities can be stored in their own segments. LOBs and varrays are stored in LOB segments, while a nested table is stored in a storage table. You can specify a STORAGE clause for these segments that will override storage parameters specified at the table level.

Information about creating tables containing LOBs, varrays, and nested tables can be found in Oracle8i Application Developer's Guide - Large Objects (LOBs), Oracle8i Application Developer's Guide - Fundamentals, and the Oracle8i SQL Reference.

Changing Values for Storage Parameters

You can alter default storage parameters for tablespaces and specific storage parameters for individual segments if you so choose. Default storage parameters can be reset for a tablespace. However, changes affect only new objects created in the tablespace, or new extents allocated for a segment.

The INITIAL and MINEXTENTS storage parameters cannot be altered for an existing table, cluster, index, or rollback segment. If only NEXT is altered for a segment, the next incremental extent is the size of the new NEXT, and subsequent extents can grow by PCTINCREASE as usual.

If both NEXT and PCTINCREASE are altered for a segment, the next extent is the new value of NEXT, and from that point forward, NEXT is calculated using PCTINCREASE as usual.

Understanding Precedence in Storage Parameters

The storage parameters in effect at a given time are determined by the following types of SQL statements, listed in order of precedence:

  1. ALTER TABLE/CLUSTER/SNAPSHOT/SNAPSHOT LOG/INDEX/ROLLBACK SEGMENT statement

  2. CREATE TABLE/CLUSTER/SNAPSHOT/SNAPSHOT LOG/CREATE INDEX/ROLLBACK SEGMENT statement

  3. ALTER TABLESPACE statement

  4. CREATE TABLESPACE statement

  5. Oracle default values

Any storage parameter specified at the object level overrides the corresponding option set at the tablespace level. When storage parameters are not explicitly set at the object level, they default to those at the tablespace level. When storage parameters are not set at the tablespace level, Oracle system defaults apply. If storage parameters are altered, the new options apply only to the extents not yet allocated.


Note:

The storage parameters for temporary segments always use the default storage parameters set for the associated tablespace. 


Storage Parameter Example

Assume the following statement has been executed:

CREATE TABLE test_storage
   ( . . . )
   STORAGE (INITIAL 100K   NEXT 100K
      MINEXTENTS 2   MAXEXTENTS 5
      PCTINCREASE 50);

Also assume that the initialization parameter DB_BLOCK_SIZE is set to 2K. The following table shows how extents are allocated for the TEST_STORAGE table. Also shown is the value for the incremental extent, as can be seen in the NEXT column of the USER_SEGMENTS or DBA_SEGMENTS data dictionary views:

Table 12-1 Extent Allocations
Extent#  Extent Size  Value for NEXT 

50 blocks or 102400 bytes 

50 blocks or 102400 bytes 

50 blocks or 102400 bytes 

75 blocks or153600 bytes 

75 blocks or 153600 bytes 

113 blocks or 231424 bytes 

115 blocks or 235520 bytes 

170 blocks or 348160 bytes 

170 blocks or 348160 bytes 

No next value, MAXEXTENTS=5 

If you change the NEXT or PCTINCREASE storage parameters with an ALTER statement (such as ALTER TABLE), the specified value replaces the current value stored in the data dictionary. For example, the following statement modifies the NEXT storage parameter of the TEST_STORAGE table before the third extent is allocated for the table:

ALTER TABLE test_storage STORAGE (NEXT 500K);

As a result, the third extent is 500K when allocated, the fourth is (500K*1.5)=750K, and so on.

Deallocating Space

It is not uncommon to allocate space to a segment, only to find out later that it is not being used. For example, you may set PCTINCREASE to a high value, which could create a large extent that is only partially used. Or you could explicitly overallocate space by issuing the ALTER TABLE...ALLOCATE EXTENT statement. If you find that you have unused or overallocated space, you can release it so that the unused space can be used by other segments.

This section describes aspects of deallocating unused space.

Viewing the High Water Mark

Prior to deallocation, you can use the DBMS_SPACE package, which contains a procedure (UNUSED_SPACE) that returns information about the position of the high water mark and the amount of unused space in a segment.

Within a segment, the high water mark indicates the amount of used space, or space that had been formatted to receive data.You cannot release space below the high water mark (even if there is no data in the space you wish to deallocate). However, if the segment is completely empty, you can release space using the TRUNCATE...DROP STORAGE statement.

See Also:

The DBMS_SPACE package is described in Oracle8i Supplied PL/SQL Packages Reference. 

Issuing Space Deallocation Statements

The following statements deallocate unused space in a segment (table, index or cluster). The KEEP clause is optional.

ALTER TABLE table DEALLOCATE UNUSED KEEP integer;
ALTER INDEX index DEALLOCATE UNUSED KEEP integer;
ALTER CLUSTER cluster DEALLOCATE UNUSED KEEP integer;

When you explicitly identify an amount of unused space to KEEP, this space is retained while the remaining unused space is deallocated. If the remaining number of extents becomes smaller than MINEXTENTS, the MINEXTENTS value changes to reflect the new number. If the initial extent becomes smaller, the INITIAL value changes to reflect the new size of the initial extent.

If you do not specify the KEEP clause, all unused space (everything above the high water mark) is deallocated, as long as the size of the initial extent and MINEXTENTS are preserved. Thus, even if the high water mark occurs within the MINEXTENTS boundary, MINEXTENTS remains and the initial extent size is not reduced.

See Also:

For details on the syntax and options associated with deallocating unused space, see the Oracle8i SQL Reference.

You can verify that deallocated space is freed by looking at the DBA_FREE_SPACE view. For more information on this view, see the Oracle8i Reference. 

Deallocating Space Examples

This section provides some space deallocation examples.

Example 1:

A table consists of three extents. The first extent is 10K, the second is 20K, and the third is 30K. The high water mark is in the middle of the second extent, and there is 40K of unused space. Figure 12-3 illustrates the effect of issuing the following statement:

ALTER TABLE dquon DEALLOCATE UNUSED

All unused space is deallocated, leaving table DQUON with two remaining extents. The third extent disappears, and the second extent size is 10K.

Figure 12-3 Deallocating All Unused Space


Text description of schema2.gif follows.

Text description of the illustration schema2.gif.

But, if you had issued the following statement specifying the KEEP keyword, then 10K above the high water mark would be kept, and the rest of the unused space would be deallocated from DQUON.

ALTER TABLE dquon DEALLOCATE UNUSED KEEP 10K;

In effect, the third extent is deallocated and the second extent remains intact.

Figure 12-4 illustrates this situation.

Figure 12-4 Deallocating Unused Space, KEEP 10K


Text description of schemaa.gif follows.

Text description of the illustration schemaa.gif.

Further, if you deallocate all unused space from DQUON and keep 20K, as specified in the following statement, the third extent is cut to 10K, and the size of the second extent remains the same.

ALTER TABLE dquon DEALLOCATE UNUSED KEEP 20K;
Example 2:

Consider the situation illustrated by Figure 12-3. Extent 3 is completely deallocated, and the second extent is left with 10K. Further, the size of the next allocated extent defaults to the size of the last completely deallocated extent, which in this case, is 30K. If this is not what you want, you can explicitly set the size of the next extent using the ALTER TABLE statement, specifying a new value for NEXT in the storage clause.

The following statement sets the next extent size for table DQUON to 20K.

ALTER TABLE dquon STORAGE (NEXT 20K) 
Example 3:

To preserve the MINEXTENTS number of extents, DEALLOCATE can retain extents that were originally allocated to a segment. This capacity is influenced by the KEEP parameter and was explained earlier.

If table DQUON has a MINEXTENTS value of 2, the statements illustrated in Figure 12-3 and Figure 12-4 still yield the same results as shown, and further, the initial value of MINEXTENTS is preserved.

However, if the MINEXTENTS value is 3, then the statement illustrated in Figure 12-4 produces the same result as shown (the third extent is removed), but the value of MINEXTENTS is changed to 2. However, the statement illustrated in Figure 12-3 will not produce the same result. In this case, the statement has no effect.

Understanding Space Use of Datatypes

When creating tables and other data structures, you need to know how much space they will require. Each datatype has different space requirements. The PL/SQL User's Guide and Reference and Oracle8i SQL Reference contain extensive descriptions of datatypes and their space requirements.


Go to previous page Go to next page
Oracle
Copyright © 1996-2000, Oracle Corporation.

All Rights Reserved.

Library

Product

Contents

Index