6 Managing Database Storage Structures

This chapter discusses using Oracle Enterprise Manager Database Control (Database Control) to view and manage the storage structures of your database. This chapter contains the following sections:

About Database Storage Structures

An Oracle database is made up of physical and logical structures. Physical structures are those that can be seen and operated on from the operating system, such as the physical files that store data on a disk.

Logical structures are created and recognized by Oracle Database and are not known to the operating system. The primary logical structure in a database, a tablespace, contains physical files. The applications developer or user may be aware of the logical structure, but is not usually aware of this physical structure. The DBA must understand the relationship between the physical and logical structures of a database.

Figure 6-1 shows the relationships between logical and physical structures. This figure also shows recovery-related structures that are optionally kept in the flash recovery area. See "Flash Recovery Area" for more information.

Figure 6-1 Oracle Database Storage Structures

Description of Figure 6-1 follows
Description of "Figure 6-1 Oracle Database Storage Structures"

Oracle Database can automate much of the management of its structure. Oracle Enterprise Manager Database Control (Database Control) provides a Web-based graphical user interface (GUI) to enable easier management and monitoring of your database.

To view a database storage structure, go to the Storage section of the Server subpage. You can click the links shown in Figure 6-2 to access the storage pages.

Figure 6-2 Storage Options

Description of Figure 6-2 follows
Description of "Figure 6-2 Storage Options"

This section provides background information about the various database storage structures. It contains the following topics:

See Also:

About Control Files

A control file tracks the physical components of the database. It is the root file that the database uses to find all the other files used by the database. Because of the importance of the control file, Oracle recommends that the control file be multiplexed. In other words, the control file should have multiple identical copies. For databases created with Oracle Database Configuration Assistant (DBCA), three copies of the control file are automatically created and kept synchronized with each other.

If any control file fails, then your database becomes unavailable. As long as you have a control file copy, however, you can shut down your database and re-create the failed control file from the copy, then restart your database. Another option is to delete the failed control file from the CONTROL_FILES initialization parameter and restart your database using the remaining control files.

See Also:

About Online Redo Log Files

Every Oracle database has a set of two or more online redo log files. The set of redo log files is collectively known as the redo log for the database. A redo log is made up of redo entries, which are also called redo records.

The redo log stores a copy of the changes made to data. If a failure requires a datafile to be restored from backup, then the recent data changes that are missing from the restored datafile can be obtained from the redo log, so work is never lost. The redo log is used to recover a database after hardware, software, or media failure. To protect against a failure involving the redo log itself, Oracle Database can multiplex the redo log so that two or more identical copies of the online redo log can be maintained on different disks.

The redo log for a database consists of groups of redo log files. A group consists of a redo log file and its multiplexed copies. Each identical copy is considered to be a member of that group. Each group is defined by a number, such as Group 1.

Figure 6-3 shows the configuration of a database that has three redo log groups and two members in each group. For each group, the members are stored on separate disks for maximum availability. For example, the members of Group 1 are the redo log files A_LOG1 and B_LOG1.

Figure 6-3 Online Redo Log Groups and Their Members

Description of Figure 6-3 follows
Description of "Figure 6-3 Online Redo Log Groups and Their Members"

The database log writer process (LGWR) writes redo records from the memory buffer to a redo log group until the log files in that group reach their storage size limit, or until you request a log switch operation. The LGWR process then writes to the next log group. The LGWR process performs this action in a circular fashion so that the oldest group is overwritten by the most recent redo records.

See Also:

About Archived Redo Log Files

When you archive your redo log, you copy the redo log files to another location before they are overwritten. These copied files are referred to as archived redo log files. You can archive to multiple locations, including a standby database.

These archived redo log files extend the amount of redo data that can be saved and are used for recovery. Archived redo log files are required to recover a backup of the database from the time of the backup to the current time. Archiving can be either enabled or disabled for the database, but Oracle strongly recommends that you enable archiving. Oracle also recommends that you configure the database to write archived redo log files to the flash recovery area.

See Also:

About Rollback Segments

Rollback segments were database structures used to track undo information for the database in earlier releases of Oracle Database. Now, the preferred way of managing undo information is with the undo tablespace. For more information, see "Managing Undo Data".

Note:

Oracle Database uses a SYSTEM rollback segment for performing system transactions. It is created automatically when the database is created, and is always brought online at instance startup. It is located in the SYSTEM tablespace. You are not required to perform any operations to manage the SYSTEM rollback segment.

About Datafiles

Datafiles are the operating system files that store the data within the database. The data is written to these files in an Oracle proprietary format that cannot be read by other programs. Tempfiles are a special class of datafiles that are associated only with temporary tablespaces.

Datafiles can be broken down into the following components:

  • Segment

    A segment contains a specific type of database object. For example, a table is stored in a table segment, and an index is stored in an index segment. A datafile can contain many segments.

  • Extent

    An extent is a contiguous set of data blocks within a segment. Oracle Database allocates space for segments in units of one extent. When the existing extents of a segment are full, the database allocates another extent for that segment.

  • Data block

    A data block, also called a database block, is the smallest unit of I/O to database storage. An extent consists of several contiguous data blocks. The database uses a default block size at database creation.

    After the database has been created, it is not possible to change the default block size without re-creating the database. It is possible, however, to create a tablespace with a block size different than the default block size.

See Also:

About Tablespaces

A database is divided into logical storage units called tablespaces, which group together related logical structures (such as tables, views, and other database objects). For example, all application objects can be grouped into a single tablespace to simplify maintenance operations.

A tablespace consists of one or more physical datafiles. Database objects assigned to a tablespace are stored in the physical datafiles of that tablespace.

When you create an Oracle database, some tablespaces already exist, such as SYSTEM and USERS.

Tablespaces provide a means to physically locate data on storage. When you define the datafiles that make up a tablespace, you specify a storage location for these files. For example, you might specify a datafile location for a certain tablespace as a designated host directory (implying a certain disk volume) or designated Automatic Storage Management disk group. Any schema objects assigned to that tablespace then get located in the specified storage location. Tablespaces also provide a unit of backup and recovery. The backup and recovery features of Oracle Database enable you to back up or recover at the tablespace level.

Table 6-1 describes some of the tablespaces included in the database.

Table 6-1 Tablespaces and Descriptions

Tablespace Description

EXAMPLE

This tablespace contains the sample schemas that are included with Oracle Database. The sample schemas provide a common platform for examples. Oracle documentation and educational materials contain examples based on the sample schemas.

SYSTEM

This tablespace is automatically created at database creation. Oracle Database uses it to manage the database. It contains the data dictionary, which is the central set of tables and views used as a read-only reference for a particular database. It also contains various tables and views that contain administrative information about the database. These are all contained in the SYS schema, and can be accessed only by the SYS user or other administrative users with the required privilege.

SYSAUX

This is an auxiliary tablespace to the SYSTEM tablespace.

Some components and products that used the SYSTEM tablespace or their own tablespaces in releases prior to Oracle Database 10g now use the SYSAUX tablespace. Using SYSAUX reduces the load on the SYSTEM tablespace and reduces maintenance because there are fewer tablespaces to monitor and maintain. Every Oracle Database 10g or later database release must have a SYSAUX tablespace.

Components that use SYSAUX as their default tablespace during installation include Automatic Workload Repository, Oracle Streams, Oracle Text, and Database Control Repository. For more information, see Oracle Database Administrator's Guide.

TEMP

This tablespace stores temporary data generated when processing SQL statements. For example, this tablespace would be used for query sorting. Every database should have a temporary tablespace that is assigned to users as their temporary tablespace. In the preconfigured database, the TEMP tablespace is specified as the default temporary tablespace. If no temporary tablespace is specified when a user account is created, then Oracle Database assigns this tablespace to the user.

UNDOTBS1

This is the undo tablespace used by the database to store undo information. See "Managing Undo Data" to understand how an Oracle database uses the undo tablespace. Every database must have an undo tablespace.

USERS

This tablespace is used to store permanent user objects and data. Similar to the TEMP tablespace, every database should have a tablespace for permanent user data that is assigned to users. Otherwise, user objects will be created in the SYSTEM tablespace, which is not good practice. In the preconfigured database, USERS is designated as the default tablespace for all new users.

You can create new tablespaces to support your user and application data requirements. During tablespace creation, you set the following parameters:

Locally Managed Tablespaces Compared to Dictionary-Managed Tablespaces

Space management within a tablespace involves keeping track of available (free) and used space, so that space is allocated efficiently during data insertion and deletion. Oracle recommends creating locally managed tablespaces rather than dictionary-managed tablespaces. Dictionary-managed tablespaces is an older space management technique and not as efficient as locally managed tablespaces.

Locally managed tablespaces keep the space allocation information within the tablespace, not in the data dictionary, thus offering better performance. By default, Oracle Database sets all newly created tablespaces to be locally managed with automatic segment management, a feature that further improves performance.

Tablespace Type

There are three types of tablespaces:

  • Permanent

    Oracle Database uses permanent tablespaces to store permanent data, such as system data. You use permanent tablespaces to store your user and application data. Each user is assigned a default permanent tablespace.

  • Undo

    A database running in automatic undo management mode transparently creates and manages undo data in the undo tablespace. Oracle Database uses undo data to roll back transactions, to provide read consistency, to help with database recovery, and to enable features such as Oracle Flashback Query.

    Even though you can create more than one undo tablespace, only one can be active. If you want to switch the undo tablespace used by the database instance, then you can create a new one and instruct the database to use it instead. The undo tablespace no longer in use can then be removed from the database (or dropped).

  • Temporary

    Temporary tablespaces are used for storing temporary data, as would be created when SQL statements perform sort operations. An Oracle database gets a temporary tablespace when the database is created. You would create another temporary tablespace if you were creating a temporary tablespace group. Under typical circumstances, you do not need to create additional temporary tablespaces. If you have an extremely large database, then you might configure additional temporary tablespaces.

    The physical files that make up a temporary tablespace are called tempfiles, as opposed to datafiles.

    The TEMP tablespace is typically used as the default temporary tablespace for users who are not explicitly assigned a temporary tablespace.

See Also:

Tablespace Status

You can set tablespace status as follows:

  • Read Write

    Users can read and write to the tablespace after it is created. This is the default.

  • Read Only

    If the tablespace is created Read Only, then the tablespace cannot be written to until its status is changed to Read Write. It is unlikely that you would create a Read Only tablespace, but you might change it to that status after you have written data to it that you do not want modified.

  • Offline

    If the tablespace is created Offline, then no users can access it. It is unlikely that you will create an Offline tablespace, but later you might change its status to Offline to perform maintenance on its datafiles.

Autoextend Tablespace

You can set a tablespace to automatically extend itself by a specified amount when it reaches its size limit. If you do not enable autoextend, you are alerted when the tablespace reaches its critical or warning threshold size. The critical and warning threshold parameters have default values that you can change at any time. These parameters also cause alerts to be generated for autoextending tablespaces that are approaching their specified size limit. You can respond to size alerts by manually increasing the tablespace size. You do so by increasing the size of one or more of the tablespace datafiles or by adding another datafile to the tablespace.

Note:

Although it is common to refer to tablespaces as autoextending, automatic extension is a datafile property, not a tablespace property. That is, when you create the datafiles that make up a tablespace, you indicate whether or not these datafiles automatically extend. A tablespace that has autoextending datafiles is considered to be an autoextending tablespace. You can specify a maximum size for an autoextending datafile.

About Other Storage Structures

Other storage structures that can exist in an Oracle database include the initialization parameter file, the password file, and backup files.

This section contains the following topics:

Initialization Parameter File

Initialization parameters are used by the Oracle instance at startup to determine the run-time properties and resources for the database. Some parameters can be set or modified while the database is running. Other initialization parameters require the database to be restarted for the changes to take effect.

See Also:

Password File

A database can use a password file to authenticate administrative users with SYSDBA or SYSOPER connection privileges. These privileges enable a DBA to start up and shut down the database and perform other high-level administrative tasks. This password file is outside of the database itself, thereby enabling the authentication of a DBA when the database is not yet started. (A DBA must authenticate before starting the database.)

When you invoke DBCA as part of the Oracle Database installation process, DBCA creates a password file with one entry: the SYS user. Granting SYSDBA to a user adds that user to the password file automatically.

Note:

Oracle Database can also use operating system authentication to authenticate users with the SYSDBA or SYSOPER privileges.

See Also:

Backup Files

Backup files are not technically database files, but are copies of the database in some form that can be used to recover the database if a failure causes loss of data.

See Also:

Viewing Database Storage Structure Information

This section provides instructions about viewing information about the various database storage structures with Oracle Enterprise Manager Database Control (Database Control). It contains the following topics:

See Also:

Viewing Control File Information

You use Database Control to view location and status information about control files.

To view control file information:

  1. Go to the Database Home page.

    See "Accessing the Database Home Page".

  2. At the top of the page, click the Server link to view the Server subpage.

  3. In the Storage section, click Control Files.

    The Control Files page appears, showing the General subpage. This page shows whether or not your database has a multiplexed control file. The Advanced and Record Section subpages give you more detailed information about your control files.

    For more information about a page, at any time, click Help.

Viewing Online Redo Log File Information

You use Database Control to view status and multiplexing information about online redo log files.

To view redo log file information:

  1. Go to the Database Home page.

    See "Accessing the Database Home Page".

  2. At the top of the page, click the Server link to view the Server subpage.

  3. In the Storage section, click Redo Log Groups.

    The Redo Log Groups page appears. This page shows the attributes of the redo log groups for your database.

    When a redo log group contains only one member, it is not multiplexed. Note the Status attribute for the redo log groups. The group with status Current is the one currently being written to disk by the log writer.

    For more information about a page, at any time, click Help.

  4. (Optional) In the Group column, click a group number to view information about redo log group members.

Viewing Archive Log Information

You use Database Control to view status information about archived redo log files.

Note:

Archived redo log files do not exist until you set the database in ARCHIVELOG mode.

To view archive log information:

  1. Go to the Database Home page.

    See "Accessing the Database Home Page".

  2. At the top of the page, click the Server link to view the Server subpage.

  3. In the Storage section, click Archive Logs.

    The Archive Logs page appears.

    For more information about a page, at any time, click Help.

Viewing Datafile Information

You use Database Control to view status and location information about datafiles.

To view datafile information:

  1. Go to the Database Home page.

    See "Accessing the Database Home Page".

  2. At the top of the page, click the Server link to view the Server subpage.

  3. In the Storage section, click Datafiles.

    The Datafiles page appears.

    For more information about a page, at any time, click Help.

  4. (Optional) Select a datafile, and then click View to display more attributes for the datafile. You can also click the name of a tablespace in the Tablespace column to display the attributes of the tablespace associated with the datafile.

Viewing Tablespace Information

You use Database Control to view configuration, size, and status information about tablespaces.

To view tablespace information:

  1. Go to the Database Home page.

    See "Accessing the Database Home Page".

  2. At the top of the page, click the Server link to view the Server subpage.

  3. In the Storage section, click Tablespaces.

    The Tablespaces page appears.

    For more information about a page, at any time, click Help.

Performing Common Database Storage Tasks

As data is added to your database, the tablespace requirements for your database change. As a DBA, you must understand how to perform the following tasks to effectively manage the tablespaces and database storage:

Creating a Tablespace

You can create additional tablespaces to store user data, so that not all data is stored in the USERS tablespace. The following are some reasons to create additional tablespaces:

  • For certain users, groups of users, or applications, it may be convenient to keep all application data in a separate tablespace or set of tablespaces for backup and recovery or maintenance reasons. For example, suppose you must recover all application data from backup due to a hardware or software failure, and you want to perform an offline recovery. If the application data is kept in a separate tablespace, you can take just that tablespace offline and recover it, without affecting the operation of other database applications.

  • Some applications, such as those with large partitioned tables, may benefit from distributing data across multiple tablespaces. This approach allows the optimal use of the available storage because frequently accessed data can be placed on high performance disks, and infrequently retrieved data can be placed on less expensive storage.

To create a tablespace:

  1. Go to the Database Home page.

    See "Accessing the Database Home Page".

  2. At the top of the page, click the Server link to view the Server subpage.

  3. In the Storage section, click Tablespaces.

    The Tablespaces page appears, as shown in Figure 6-4.

    Figure 6-4 Tablespaces Page

    Description of Figure 6-4 follows
    Description of "Figure 6-4 Tablespaces Page"

    For more information about a page, at any time, click Help.

  4. Do one of the following:

    1. To create a new tablespace, click Create (not shown in the screenshot).

    2. To create a tablespace that is similar to an existing tablespace, in the Select column, select the tablespace whose attributes you want to reproduce. In the Actions list, select Create Like and then click Go.

    The Create Tablespace page appears, showing the General subpage.

    Description of create_tablespace.gif follows
    Description of the illustration create_tablespace.gif

  5. In the Name field, enter a name for the tablespace.

  6. In the Extent Management section, select Locally Managed.

    See "Locally Managed Tablespaces Compared to Dictionary-Managed Tablespaces".

  7. In the Type section, select Permanent.

    See "Tablespace Type".

  8. In the Status section, select Read Write.

    See "Tablespace Status".

  9. In the Datafiles section, click Add to add one or more datafiles to the tablespace.

    The Add Datafile page appears.

    Note:

    If you select Use bigfile tablespace, then the tablespace can have only one datafile. Bigfile tablespaces are used with very large databases that use Automatic Storage Management or other logical volume managers that support striping, RAID, and dynamically extensible logical volumes.

  10. In the File Name field, enter a file name. Accept the File Directory and File Size defaults.

  11. In the Storage section, complete the following steps:

    1. Select Automatically extend datafile when full (AUTOEXTEND).

    2. Set a suitable increment, such as 10 MB.

      This is the amount of disk space that is added to the datafile when it needs more storage space.

    3. For Maximum File Size, do one of the following, depending on available storage:

      • Select Unlimited to permit the file to increase without limits.

      • Select Value, and then enter a value in KB, MB, GB, or TB.

  12. Click Continue.

    The Create Tablespace page returns.

  13. (Optional) Toward the top of the page, click the Storage link to view the Storage subpage. Examine all of the default settings on this subpage.

    See the online Help for more information about these settings.

  14. Click OK to add the tablespace.

    The Tablespaces page returns, showing the newly created tablespace.

See Also:

Modifying a Tablespace

You can use Oracle Enterprise Manager Database Control (Database Control), to modify a tablespace. For example, you can extend it (by increasing datafile sizes or adding another datafile), set it to automatically extend, change its space usage alert thresholds, or change its status to Offline. When you get a critical or warning alert, you might need to extend a tablespace (if the alert is related to space available) or take it offline to recover it (if the alert is related to corrupted data or other serious errors).

This section contains the following topics:

See Also:

Setting a Tablespace to Automatically Extend

This section explains how to set a tablespace to automatically extend when it reaches its size limit. The following instructions assume that the tablespace was previously not an autoextending tablespace.

To set a tablespace to automatically extend:

  1. Go to the Database Home page.

    See "Accessing the Database Home Page".

  2. At the top of the page, click the Server link to view the Server subpage.

  3. In the Storage section, click Tablespaces.

    The Tablespaces page appears.

    See Figure 6-4.

    For more information about a page, at any time, click Help.

  4. Select the tablespace for which you want to enable autoextend, and then click Edit.

    The Edit Tablespace page appears.

  5. Select the first datafile associated with the tablespace, and then click Edit.

    The Edit Datafile page appears.

  6. In the Storage section, complete the following steps:

    1. Select Automatically extend datafile when full (AUTOEXTEND).

    2. Set a suitable increment, such as 10 MB.

      This is the amount of disk space that is added to the datafile when it needs more storage space.

    3. For Maximum File Size, do one of the following, depending on available storage:

      • Select Unlimited to permit the file to increase without limits.

      • Select Value, and then enter a value in KB, MB, GB, or TB.

  7. Click Continue.

    The Edit Tablespace page returns.

  8. Repeat Step 5 through Step 7 for each additional datafile associated with the tablespace.

  9. Click Apply.

    A confirmation message appears.

Changing Space Usage Alert Thresholds for a Tablespace

You receive an alert in ­Database Control when a space usage threshold for a tablespace is reached. There are two types of space usage alerts that you can enable: warning, for when tablespace space is somewhat low, and critical, for when the tablespace is almost completely full and action must be taken immediately.

For both warning and critical alerts, there are two ways to specify alert thresholds:

  • By space used (%)

    When space used becomes greater than or equal to a percentage of total space, an alert is issued.

  • By free space (MB)

    When remaining space falls below an amount (in MB), an alert is issued.

    Free-space thresholds are more useful for large tablespaces. For example, for a 10 TB tablespace, setting the percentage full critical alert to as high as 99 percent means that the database would issue an alert when there is still 100 GB of free space remaining. In many cases, 100 GB remaining would not be a critical situation, and the alert would not be useful. For this tablespace, it might be better to use a free-space threshold, which you could set to issue a critical alert when 5 GB of free space remains.

For both warning and critical alerts for a tablespace, you can enable either the space used threshold or the free-space threshold, or you can enable both thresholds.

To change space usage alert thresholds for tablespaces:

  1. Go to the Database Home page.

    See "Accessing the Database Home Page".

  2. At the top of the page, click the Server link to view the Server subpage.

  3. In the Storage section, click Tablespaces.

    The Tablespaces page appears.

    See Figure 6-4.

    For more information about a page, at any time, click Help.

  4. Select the tablespace whose threshold you want to change, and then click Edit.

    The Edit Tablespace page appears, showing the General subpage.

  5. Click Thresholds to display the Thresholds subpage.

    Description of tablespace_thresholds.gif follows
    Description of the illustration tablespace_thresholds.gif

  6. In the Space Used (%) section, do one of the following:

    • Accept the default thresholds.

    • Select Specify Thresholds, and then enter a Warning (%) threshold and a Critical (%) threshold.

    • Select Disable Thresholds to disable the percentage full thresholds.

  7. In the Free Space (MB) section, do one of the following:

    • Accept the default thresholds.

    • Select Specify Thresholds, and then enter a Warning (MB) threshold and a Critical (MB) threshold.

    • Select Disable Thresholds to disable the threshold for free space remaining.

  8. Click Apply.

    A confirmation message appears.

Taking a Tablespace Offline

You may want to take a tablespace offline for any of the following reasons:

  • To make a portion of the database unavailable while still allowing access to the remainder of the database

  • To make an application and its group of tables temporarily unavailable while updating or maintaining the application

  • To perform an offline tablespace backup (even though a tablespace can be backed up while online and in use)

  • To recover a tablespace after a hardware or software failure

  • To rename or relocate tablespace datafiles

To take a tablespace offline:

  1. Go to the Database Home page.

    See "Accessing the Database Home Page".

  2. At the top of the page, click the Server link to view the Server subpage.

  3. In the Storage section, click Tablespaces.

    The Tablespaces page appears.

    See Figure 6-4.

    For more information about a page, at any time, click Help.

  4. Select the tablespace that you want to take offline, and then click Edit.

    The Edit Tablespace page appears.

  5. In the Status section, select Offline, make a selection from the Offline Mode list, and then click Apply.

    For more information about the selections on this page, click Help.

    A confirmation message appears.

Note:

To bring the tablespace back online, return to this page, and then, under the Status section, click Read Write.

See Also:

Dropping a Tablespace

After a tablespace has been dropped (deleted), the objects and data in it are no longer available. To recover them can be a time-consuming process. Oracle recommends performing a backup before and after dropping a tablespace.

To drop a tablespace:

  1. Go to the Database Home page.

    See "Accessing the Database Home Page".

  2. At the top of the page, click the Server link to view the Server subpage.

  3. In the Storage section, click Tablespaces.

    The Tablespaces page appears.

    For more information about a page, at any time, click Help.

  4. Select the tablespace that you want to drop, and then click Delete.

    Database Control asks for confirmation that you want to delete the tablespace and delete the associated datafiles from the disk.

  5. Click Yes to remove the tablespace.

See Also:

Reclaiming Unused Space

This section provides background information about reclaimable unused space in the database, and provides instructions about how to reclaim this space. It contains the following topics:

About Reclaimable Unused Space

Over time, performing insert, update, and delete operations (also referred to as DML operations) on objects within a tablespace can create pockets of empty space that individually are not big enough to be reused. Collectively, these pockets can waste large amounts of space. The sparsely populated objects that result can suffer performance degradation during queries and DML operations.

Oracle Database enables you reclaim this empty space with the following two online operations—that is, operations that do not block queries or DML against affected objects while the operations are proceeding:

  • Online segment shrink

    Online segment shrink operates on table segments and on the segments of the dependent objects of the table, such as indexes and partitions. For each segment, data is compacted to the front of the segment. Free space can either be returned to the tablespace or kept in the segment for future insert operations. Online segment shrink is permitted only on segments in a locally managed tablespace with automatic segment space management. Online segment shrink is an in-place operation; no additional free space in the tablespace is required.

  • Online table redefinition (also known as reorganization)

    Reorganization relocates the table and its dependent objects in a different part of the tablespace. This operation has the desirable side effect of compacting the data for those objects. For this operation to succeed, however, the tablespace must already have free space equal to the size of the table and its dependent objects. Reorganization is the only permitted operation for dictionary-managed tablespaces or for locally managed tablespaces with manual segment space management.

The Segment Advisor generates recommendations for shrinking or reorganizing segments that have a significant amount of reclaimable unused space.

See Also:

About the Segment Advisor

The Segment Advisor identifies database objects that have unused space that you can reclaim. It performs its analysis by examining usage and growth statistics and by sampling the data in the object. By default, it is configured to run automatically at regular intervals, during all maintenance windows (time periods). You can also run the Segment Advisor manually.

The regularly scheduled Segment Advisor task is known as the Automatic Segment Advisor. Results from the advisor are summarized on the Space Summary section of the Database Home page as Segment Advisor Recommendations. See Figure 6-5.

During each run of the Automatic Segment Advisor, only a subset of the segments in the database are analyzed. If you believe that particular segments may have reclaimable unused space, yet those segments do not appear among the Segment Advisor recommendations, the Automatic Segment Advisor may not have chosen them for analysis. You can run the Segment Advisor manually on those segments at any time. See Oracle Database Administrator's Guide for information about how the Automatic Segment Advisor selects tablespaces and segments for analysis.

Segment Advisor Recommendations

Segment Advisor recommendations are grouped by tablespace. Only tablespace names appear on the Segment Advisor Recommendations page in Database Control. If a tablespace contains any segments for which a shrink operation or reorganization is recommended, the tablespace appears on the Segment Advisor Recommendations page. This page estimates the amount of reclaimable space for each tablespace. If you request recommendation details for a tablespace, Database Control displays the segments in that tablespace for which recommendations were generated.

See Figure 6-6 and Figure 6-7.

A recommendation for a segment can be either a shrink operation or a reorganization operation. If you created the tablespace for a segment as locally managed with automatic segment space management, which is the default, the Segment Advisor recommends shrinking, if the segment is not one of the few segment types that are not eligible for shrinking. An example of such as segment is a table with function-based indexes. If the segment is not eligible for online segment shrink, or if its tablespace is dictionary-managed or was created with manual segment space management, the Segment Advisor recommends reorganization.

See Also:

Viewing Segment Advisor Recommendations and Reclaiming Space

Each Segment Advisor recommendation includes a button that you can click to start the space reclamation process. Although space reclamation is an online process, it can consume significant resources, so it is recommended that you reclaim space during off-peak hours.

To view Segment Advisor recommendations and reclaim space:

  1. Go to the Database Home page.

    See "Accessing the Database Home Page".

  2. In the Space Summary section, click the numeric link adjacent to Segment Advisor Recommendations.

    Figure 6-5 Home Page Space Summary Section

    Description of Figure 6-5 follows
    Description of "Figure 6-5 Home Page Space Summary Section"

    The Segment Advisor Recommendations page appears, showing recommendations from the most recent automatic and manual runs of the Segment Advisor.

    Figure 6-6 Segment Advisor Recommendations Page

    Description of Figure 6-6 follows
    Description of "Figure 6-6 Segment Advisor Recommendations Page"

    For more information about a page, at any time, click Help.

  3. (Optional) In the View list, select Recommendations for Last Automatic Run to view recommendations from only the most recent automatic run of the Segment Advisor.

  4. Select a tablespace, and then click Recommendation Details.

    The Recommendation Details for Tablespace page appears. This page lists the tablespace segments for which online segment shrink or reorganization is recommended.

    Figure 6-7 Segment Advisor Recommendation Details Page

    Description of Figure 6-7 follows
    Description of "Figure 6-7 Segment Advisor Recommendation Details Page"

  5. (Optional) Reduce the number of segments displayed in the segment list by entering search criteria in the fields Schema, Segment, Partition, or Minimum Reclaimable Space, and then clicking Search.

  6. Examine the recommendation for each segment, and then proceed as follows:

    • If the recommendation for any segments is to reorganize, start reorganization for those segments by running subprograms from the DBMS_REDEFINITION PL/SQL package, using SQL*Plus. See Oracle Database Administrator's Guide for instructions.

    • If the recommendation for any segments is to shrink, proceed with Step 7 through Step 12 for those segments.

  7. Do one of the following to select one or more segments to shrink:

    • To reclaim space in a single segment, click Shrink under the Recommendation column for that segment.

    • To shrink one or more segments, select the segments, and then click Implement.

  8. On the Shrink Segment: Options page, accept Compact Segments and Release Space.

    This option returns freed space to the tablespace. If you do not want to release the freed space to the tablespace, then choose Compact Segments. You can rerun the shrink process later to release the freed space.

    Note:

    Choose Compact Segments if you believe that you may have long-running queries currently in operation that involve the segments being shrunk. Long-running queries that were started before the shrink operation completes might attempt to read from blocks that have been reclaimed. This results in an error. Alternatively, you can schedule the shrink operation for an off-peak period in Step 10.

  9. Click Implement.

    The Shrink Segment: Schedule page appears.

  10. Note your job name, or replace it with a job name of your choosing. Under the heading Start, select Immediately.

    Because the shrink operation can be resource intensive, you can also select Later and schedule the operation for an off-peak period.

  11. Click Submit.

    The Scheduler Jobs page appears, and shows the shrink job in the Running subpage.

  12. Click Refresh to update the page until the job disappears from the Running subpage.

    You can then switch to the History or All subpage to view the completed status of the job.

Running the Segment Advisor Manually

You can run the Segment Advisor manually. You do so when you want to analyze objects not selected for analysis by the Automatic Segment Advisor, or when you want more up-to-date recommendations on a tablespace.

See Also:

Managing the Redo Log

This section describes some of the more common redo log management tasks. It contains the following topics:

See Also:

Multiplexing the Redo Log

Oracle recommends that you multiplex the redo log. Multiplexing provides better protection for data in the case of instance or media failure.

To multiplex your redo log, you must add members to each redo log group. It is not required that redo log groups be symmetrical, but Oracle recommends that your groups all have the same number of members. A database must have a minimum of two redo log groups.

Note:

When you multiplex the redo log, the database must increase the amount of I/O that it performs. Depending on your configuration, this may impact overall database performance.

To multiplex the redo log:

  1. Go to the Database Home page.

    See "Accessing the Database Home Page".

  2. At the top of the page, click the Server link to view the Server subpage.

  3. In the Storage section, click Redo Log Groups.

    The Redo Log Groups page appears.

    For more information about a page, at any time, click Help.

  4. Select a group and click Edit.

    The Edit Redo Log Group page appears.

  5. Click Add.

    The Add Redo Log Member page appears.

  6. In the File Name field, enter a file name for the new redo log member.

    For example, if your existing member file name is REDO01.log, then you might name this member REDO01a.log.

  7. In the File Directory field, enter the file directory or accept the default.

    You can create this file in the same directory, but it is recommended that you store members on separate disk drives. That way, if there is a drive failure, you still have access to one member.

  8. Click Continue, and then click Apply to accept your changes.

    A confirmation message appears.

  9. At the top of the page, click the Redo Log Groups link to return to the Redo Log Groups page.

  10. Repeat Step 4 through Step 9 for every existing log group.

Switching a Log File

When a log switch occurs, the log writer (LGWR) process stops writing to the current redo log group and starts writing to the next available redo log group. You can force a log switch to make the current redo group inactive and available for redo log maintenance operations. For example, you might want to drop the current redo group, but are not able to do so until the group is inactive. You may also want to force a log switch if the current redo group needs to be archived at a specific time before the members of the group are completely filled. This option is useful in configurations with large redo log files that take a long time to fill.

To switch a log file:

  1. Go to the Database Home page.

    See "Accessing the Database Home Page".

  2. At the top of the page, click the Server link to view the Server subpage.

  3. In the Storage section, click Redo Log Groups.

    The Redo Log Groups page appears.

    For more information about a page, at any time, click Help.

  4. In the Actions list, select Switch logfile, and then click Go.

    A confirmation message appears. The status of the group that had been Current changes to Active, and the status of the next group in the list changes from Inactive to Current.

Managing Undo Data

Beginning with Oracle Database Release 11g, for a default installation, Oracle Database automatically manages the undo data. There is typically no need for DBA intervention. However, if your installation uses Oracle Flashback operations, you may need to perform some undo management tasks to ensure the success of these operations.

This section provides background information and instructions for managing undo data. It contains the following topics:

About Undo Data

When a transaction modifies data, Oracle Database copies the original data before modifying it. The original copy of the modified data is called undo data. Saving this information is necessary for the following reasons:

  • To undo any uncommitted changes made to the database in the event that a rollback operation is necessary. A rollback operation can be the result of a user who wants to undo the changes of a misguided or unintentional transaction, or it can be part of a recovery operation.

  • To provide read consistency, which means that each user can get a consistent view of data, even while other changes may be occurring against the data. For example, if a user issues a query at 10:00 a.m. and the query lasts for 15 minutes, then the query results should reflect the entire state of the data at 10:00 a.m., regardless of update or insert operations by other users during the query.

  • To enable certain Oracle Flashback features, such as Oracle Flashback Query and Oracle Flashback Table, which enable you to view or recover data to a previous point in time.

Undo Tablespace

With automatic undo management, undo data is stored in an undo tablespace. Undo tablespaces have some additional properties beyond those of permanent tablespaces. There can be multiple undo tablespaces, but only one can be active for an Oracle instance.

When you create the database using DBCA, it creates an autoextending undo tablespace named UNDOTBS1, with a maximum extension size of 35 GB.

Undo Retention

Oracle Database automatically ensures that undo data that is in use by an active transaction is never overwritten until that transaction has been committed. After the transaction has been committed, the space occupied by that undo data can be reused, or overwritten. In this case, that undo data could be overwritten if space in the undo tablespace becomes scarce.

Even after a transaction has been committed, it is useful to retain (not overwrite) its undo data, to ensure the success of Oracle Flashback features and for read consistency for long-running queries. To this end, the database maintains and automatically tunes an undo retention period. Committed undo data whose age is less than the undo retention period is retained for use by queries or Oracle Flashback operations.

See Also:

About Managing Undo Data

Although by default Oracle Database manages undo data and the undo tablespace automatically, if your installation uses Oracle Flashback features, you may need to perform some undo management tasks to ensure the success of these operations.

Oracle Flashback operations resulting in snapshot too old errors indicate that you must intervene to ensure that sufficient undo data is retained to support these operations.

There are two ways to better support Oracle Flashback operations:

  • Set the minimum undo retention period for the autoextending tablespace to be as long as the longest expected Oracle Flashback operation.

    You do this by setting the UNDO_RETENTION initialization parameter. See Oracle Database Administrator's Guide for details.

  • Change the undo tablespace to a fixed size.

    For an autoextending undo tablespace, Oracle Database always automatically tunes the undo retention period to be slightly longer than the longest-running active query. However, this autotuned retention period may be insufficient to accommodate Oracle Flashback operations.

    For an undo tablespace of a fixed size, or a tablespace with autoextending disabled, rather than tuning the undo retention period to be slightly longer than the longest-running active query, the database dynamically tunes the undo retention period for the best possible retention, based on system activity and the undo tablespace size. This best possible retention period for an undo tablespace of fixed size can be much longer than the longest-running active query, and can thus better accommodate Oracle Flashback operations.

    Another reason to change the undo tablespace to a fixed size is to prevent the tablespace from growing too large.

    If you decide to change the undo tablespace to a fixed size, you must choose a tablespace size that is sufficiently large. If you choose an undo tablespace size that is too small, the following two errors could occur:

    • DML could fail because there is not enough space to accommodate undo data for new transactions.

    • Long-running queries could fail with a snapshot too old error, which means that there was insufficient undo data for read consistency.

    Oracle Enterprise Manager Database Control (Database Control) includes an Undo Advisor to help you determine the minimum size for the fixed size of the undo tablespace. See "Computing the Minimum Undo Tablespace Size Using the Undo Advisor".

    Note:

    If you want to configure the undo tablespace to have a fixed size, Oracle suggests that you first allow enough time after database creation to run a full workload, thus allowing the undo tablespace to grow to its minimum required size to handle the workload. Then, you can use the Undo Advisor to determine the best size to configure the undo tablespace to allow for future long-running queries and Oracle Flashback operations.

See Also:

Viewing Undo Information

You can use the Automatic Undo Management page to view the following information about your undo configuration:

  • Name and current size of the undo tablespace

  • Autoextend tablespace setting (Yes or No)

  • Current autotuned undo retention period

To view undo information:

  1. Go to the Database Home page.

    See "Accessing the Database Home Page".

  2. At the top of the page, click the Server link to view the Server subpage.

  3. In the Database Configuration section, click Automatic Undo Management.

    The Automatic Undo Management page appears.

    For more information about a page, at any time, click Help.

Description of undo_management.gif follows
Description of the illustration undo_management.gif

See Also:

Computing the Minimum Undo Tablespace Size Using the Undo Advisor

If you decide to change the undo tablespace to a fixed size, use the Undo Advisor to help determine the minimum required size. You can also use the Undo Advisor to set the minimum undo retention period.

To compute the minimum undo tablespace size using the Undo Advisor:

  1. Go to the Automatic Undo Management page.

    See "Viewing Undo Information".

  2. Decide whether you want to compute the minimum size of the undo tablespace based on statistics gathered over a designated time period (such as the last 7 days), or based on an undo retention period of a duration that you choose.

    The automatically gathered statistics include the duration of the longest-running query and the undo generation rate. Computing the minimum undo tablespace size based on these statistics is advisable if you do not use Oracle Flashback features or if you do not expect future long-running queries to exceed the duration of previous long-running queries.

    If you prefer to choose and enter the duration of a desired undo retention period, the duration must be based on your expectations of the duration of future long-running queries or Oracle Flashback operations.

  3. If you want to compute the minimum undo tablespace size based on statistics gathered over a period of time, complete the following steps:

    1. In the Analysis Period section, in the Analysis Time Period list, select the desired analysis time period.

      If you select Customize Time Period, a page appears that enables you to enter the starting and ending date and time for the period.

    2. Select Automatically chosen based on longest query in analysis period.

    3. Click Run Analysis.

      The minimum required undo tablespace size is displayed in the Analysis Results section.

    4. (Optional) Click Show Graph to view a graph of the analysis results.

  4. If you want to compute the minimum undo tablespace size based on a duration that you enter, complete the following steps:

    1. In the Analysis Period section, select Specified manually to allow for longer duration queries or flashback.

    2. In the Duration field, enter the desired duration of the undo retention period in seconds, minutes, hours or days.

      You may compute this duration as follows:

      • Determine the duration of the expected longest-running query for your workload.

        You can base your determination on the longest-running query recorded during a previous workload period. This information is available from the System Activity subpage of the Automatic Undo Management page. You choose the analysis period for this subpage by selecting from the Analysis Time Period list on the General subpage. You can choose a custom analysis period that corresponds to your typical workload period.

      • Determine the longest duration that is expected for an Oracle Flashback operation.

      • Take the maximum of these two durations.

      Description of undo_management_activity.gif follows
      Description of the illustration undo_management_activity.gif

    3. In the Analysis Period section of the General subpage, click Run Analysis.

      The minimum required undo tablespace size is displayed in the Analysis Results section.

    4. (Optional) Click Show Graph to view a graph of the analysis results.

      Description of undo_management_graph.gif follows
      Description of the illustration undo_management_graph.gif

  5. (Optional) Click the tick-mark, or point, on the curve that corresponds to the desired undo retention period.

    The Duration field changes to match the selected undo retention period, and the Minimum Required Undo Tablespace Size field above the graph changes to reflect the matching required size.

  6. (Optional) Click Apply.

    The minimum undo retention period is set to the value of the Duration field.

Note:

Running an analysis or setting the minimum undo retention with the Undo Advisor does not change the size of the undo tablespace. You must follow the instructions in "Changing the Undo Tablespace to a Fixed Size" to change the size of the undo tablespace.

See Also:

Changing the Undo Tablespace to a Fixed Size

You change the undo tablespace to a fixed size to prevent the tablespace from growing too large or to better support Oracle Flashback operations.

To change the undo tablespace to a fixed size:

  1. On the Automatic Undo Management page, after determining the minimum required undo tablespace size, click Edit Undo Tablespace.

    The Edit Tablespace page appears, displaying the properties of the undo tablespace.

  2. In the Datafiles section, click Edit.

    The Edit Datafile page appears.

  3. In the File Size field, enter the computed minimum size for the undo tablespace.

    See "Computing the Minimum Undo Tablespace Size Using the Undo Advisor".

  4. In the Storage section, deselect Automatically extend datafile when full (AUTOEXTEND).

  5. Click Continue.

    The Edit Tablespace page returns.

  6. Click Apply.

    A confirmation message appears.

See Also:

Storage: Oracle By Example Series

Oracle By Example (OBE) has a series on the Oracle Database 2 Day DBA guide. This OBE steps you through the tasks in this chapter and includes annotated screenshots.

To view the Storage OBE, in your browser, enter the following URL:

http://www.oracle.com/webfolder/technetwork/tutorials/obe/db/11g/r1/2day_dba/storage/storage.htm