DBAsupport.com Forums - Powered by vBulletin
Results 1 to 7 of 7

Thread: Rollback Segment Survey

  1. #1
    Join Date
    Jun 2001
    Posts
    29
    In preparation for a technical article/presentation on rollback segments, I would like to understand the general knowledge of rollback segments and how they are used. There are no right or wrong answers, so any input is appreciated. Answers to single questions are acceptable (heck...any participation is downright encouraged!)

    What is a rollback segment (rbs)?
    Describe the physical structure of an rbs.
    What method is used to allocate rbs?
    What information is contained in an rbs?
    What types of transactions write rbs entries?
    What types of transactions read rbs entries?
    How are rbs entries used for read consistent queries?
    What causes Snapshot Too Old errors?

    What other questions/issues/problems have you come across that are not addressed by these questions?

    A sincere thanks
    Daniel W. Fink
    oracledba@ix.netcom.com

  2. #2
    Join Date
    Jun 2000
    Location
    Madrid, Spain
    Posts
    7,447
    if you do a search on the forum you can virtually find all the informations you are looking for

  3. #3
    Join Date
    Jun 2001
    Posts
    29
    I realize there is a wealth of information available. What I am looking for is what DBAs, Developers, etc. think a rollback segment is. I want to see what areas of the topic are misunderstood or cause of concern. This helps me address the real issues.
    Daniel W. Fink
    oracledba@ix.netcom.com

  4. #4
    Join Date
    May 2000
    Location
    ATLANTA, GA, USA
    Posts
    3,135
    I feel Oracle's Rollback Tablespace ( segements) concept was not designed properly. Oracle should have been designed/developed to use /tmp (in Unix) or C:\TEMP (in NT) area for its internal activities such as maintaining read consistency, concurrency and sort activities.

  5. #5
    Join Date
    May 2001
    Location
    Dallas Texas
    Posts
    8
    You asked what caused ORA-1555, but not how to fix it (which is much more important in my mind).

    The other big problem I see is where people build rollback segments. There are performance and availability differences between using RAID-5, RAID-0+1 (mirroring/striping), or plain-jane concatenated filesystems and building the tablespace as one big datafile, or building it as one datafile per rollback segment built where each is on a different volume. Things like that. I have seen too many cases where people put rollbacks (and redos and temp space for that matter) on RAID-5 volumes using one big datafile for the tablespace and then being disappointed when performance isn't quite what they thought it should be.

    Also see if they understand the concept of slots and how many simultaneous transactions can run on a given system given the number of rollback segments and the number of extents each has allocated.

    I also find a lot of misconception on what actually happens to the data in the rollback and the cache and in the physical data block on disk when a commit takes place. The life-cycle of a rollback is important to understand, and it is also important to understand what actually happens to the rollback in relation to the cache and the physical datablock on disk in the event of a commit or a rollback.

  6. #6
    Join Date
    Mar 2001
    Posts
    287
    The following is quoted from Oracle Doc.

    Rollback Segments
    Each database contains one or more rollback segments. A rollback segment records the old values of data that were changed by each transaction (whether or not committed). Rollback segments are used to provide read consistency, to roll back transactions, and to recover the database.

    See Also:

    "Multiversion Concurrency Control" for information about read consistency

    "Rolling Back Transactions"

    "Rollback Segments and Rolling Back" for information about database recovery





    Contents of a Rollback Segment
    Information in a rollback segment consists of several rollback entries. Among other information, a rollback entry includes block information (the file number and block ID corresponding to the data that was changed) and the data as it existed before an operation in a transaction. Oracle links rollback entries for the same transaction, so the entries can be found easily if necessary for transaction rollback.

    Neither database users nor administrators can access or read rollback segments; only Oracle can write to or read them. (They are owned by the user SYS, no matter which user creates them.)

    Logging Rollback Entries
    Rollback entries change data blocks in the rollback segment, and Oracle records all changes to data blocks, including rollback entries, in the redo log. This second recording of the rollback information is very important for active transactions (not yet committed or rolled back) at the time of a system crash. If a system crash occurs, Oracle automatically restores the rollback segment information, including the rollback entries for active transactions, as part of instance or media recovery. Once the recovery is complete, Oracle performs the actual rollbacks of transactions that had been neither committed nor rolled back at the time of the system crash.

    When Rollback Information Is Required
    For each rollback segment, Oracle maintains a transaction table--a list of all transactions that use the associated rollback segment and the rollback entries for each change performed by these transactions. Oracle uses the rollback entries in a rollback segment to perform a transaction rollback and to create read-consistent results for queries.

    Rollback segments record the data prior to change on a per-transaction basis. For every transaction, Oracle links each new change to the previous change. If you must roll back the transaction, Oracle applies the changes in a chain to the data blocks in an order that restores the data to its previous state.

    Similarly, when Oracle needs to provide a read-consistent set of results for a query, it can use information in rollback segments to create a set of data consistent with respect to a single point in time.

    Transactions and Rollback Segments
    Each time a user's transaction begins, the transaction is assigned to a rollback segment in one of two ways:

    Oracle can assign a transaction automatically to the next available rollback segment. The transaction assignment occurs when you issue the first DML or DDL statement in the transaction. Oracle never assigns read-only transactions (transactions that contain only queries) to a rollback segment, regardless of whether the transaction begins with a SET TRANSACTION READ ONLY statement.

    An application can assign a transaction explicitly to a specific rollback segment. At the start of a transaction, an application developer or user can specify a particular rollback segment that Oracle should use when executing the transaction. This allows the application developer or user to select a large or small rollback segment, as appropriate for the transaction.

    For the duration of a transaction, the associated user process writes rollback information only to the assigned rollback segment.

    When you commit a transaction, Oracle releases the rollback information but does not immediately destroy it. The information remains in the rollback segment to create read-consistent views of pertinent data for queries that started before the transaction committed. To guarantee that rollback data is available for as long as possible for such views, Oracle writes the extents of rollback segments sequentially. When the last extent of the rollback segment becomes full, Oracle continues writing rollback data by wrapping around to the first extent in the segment. A long-running transaction (idle or active) may require a new extent to be allocated for the rollback segment.

    See Figure 4-6, Figure 4-7, and Figure 4-8 for more information about how transactions use the extents of a rollback segment.

    Each rollback segment can handle a fixed number of transactions from one instance. Unless you explicitly assign transactions to particular rollback segments, Oracle distributes active transactions across available rollback segments so that all rollback segments are assigned approximately the same number of active transactions. Distribution does not depend on the size of the available rollback segments. Therefore, in environments where all transactions generate the same amount of rollback information, all rollback segments can be the same size.

    Note:
    The number of transactions that a rollback segment can handle is a function of the data block size, which depends on the operating system.

    See your Oracle operating system-specific documentation for more information.




    When you create a rollback segment, you can specify storage parameters to control the allocation of extents for that segment. Each rollback segment must have at least two extents allocated.

    One transaction writes sequentially to a single rollback segment. Each transaction writes to only one extent of the rollback segment at any given time. Many active transactions can write concurrently to a single rollback segment--even the same extent of a rollback segment; however, each data block in a rollback segment's extent can contain information for only a single transaction.

    When a transaction runs out of space in the current extent and needs to continue writing, Oracle finds an available extent of the same rollback segment in one of two ways:

    It can reuse an extent already allocated to the rollback segment.

    It can acquire (and allocate) a new extent for the rollback segment.

    The first transaction that needs to acquire more rollback space checks the next extent of the rollback segment. If the next extent of the rollback segment does not contain information from an active transaction, Oracle makes it the current extent, and all transactions that need more space from then on can write rollback information to the new current extent.

    Figure 4-6 illustrates two transactions, T1 and T2, which begin writing in the third extent (E3) and continue writing to the fourth extent (E4) of a rollback segment.

    Figure 4-6 Use of Allocated Extents in a Rollback Segment


    As the transactions continue writing and fill the current extent, Oracle checks the next extent already allocated for the rollback segment to determine if it is available. In Figure 4-7, when E4 is completely full, T1 and T2 continue any further writing to the next extent allocated for the rollback segment that is available; in this figure, E1 is the next extent. This figure shows the cyclical nature of extent use in rollback segments.

    Figure 4-7 Cyclical Use of the Allocated Extents in a Rollback Segment


    To continue writing rollback information for a transaction, Oracle always tries to reuse the next extent in the ring first. However, if the next extent contains data from active transaction, then Oracle must allocate a new extent. Oracle can allocate new extents for a rollback segment until the number of extents reaches the value set for the rollback segment's storage parameter MAXEXTENTS.

    Figure 4-8 shows a new extent allocated for a rollback segment. The uncommitted transactions are long running (either idle, active, or persistent in-doubt distributed transactions). At this time, they are writing to the fourth extent, E4, in the rollback segment. However, when E4 is completely full, the transactions cannot continue further writing to the next extent in sequence, E1, because it contains active rollback entries. Therefore, Oracle allocates a new extent, E5, for this rollback segment, and the transactions continue writing to this new extent.

    Figure 4-8 Allocation of a New Extent for a Rollback Segment


    How Extents Are Deallocated from a Rollback Segment
    When you drop a rollback segment, Oracle returns all extents of the rollback segment to its tablespace. The returned extents are then available to other segments in the tablespace.

    When you create or alter a rollback segment, you can use the storage parameter OPTIMAL (which applies only to rollback segments) to specify the optimal size of the segment in bytes. If a transaction needs to continue writing rollback information from one extent to another extent in the rollback segment, Oracle compares the current size of the rollback segment to the segment's optimal size. If the rollback segment is larger than its optimal size, and if the extents immediately following the extent just filled are inactive, then Oracle deallocates consecutive nonactive extents from the rollback segment until the total size of the rollback segment is equal to or close to, but not less than, its optimal size. Oracle always frees the oldest inactive extents, as these are the least likely to be used by consistent reads.

    A rollback segment's OPTIMAL setting cannot be less than the combined space allocated for the minimum number of extents for the segment. For example:

    (INITIAL + NEXT + NEXT + ... up to MINEXTENTS) bytes

    The Rollback Segment SYSTEM
    Oracle creates an initial rollback segment called SYSTEM whenever a database is created. This segment is in the SYSTEM tablespace and uses that tablespace's default storage parameters. You cannot drop the SYSTEM rollback segment. An instance always acquires the SYSTEM rollback segment in addition to any other rollback segments it needs.

    If there are multiple rollback segments, Oracle tries to use the SYSTEM rollback segment only for special system transactions and distributes user transactions among other rollback segments; if there are too many transactions for the non-SYSTEM rollback segments, Oracle uses the SYSTEM segment as necessary. In general, after database creation, you should create at least one additional rollback segment in the SYSTEM tablespace.

    Oracle Instances and Types of Rollback Segments
    When an Oracle instance opens a database, it must acquire one or more rollback segments so that the instance can handle rollback information produced by subsequent transactions. An instance can acquire both private and public rollback segments. A private rollback segment is acquired explicitly by an instance when the instance opens a database. Public rollback segments form a pool of rollback segments that any instance requiring a rollback segment can use.

    Any number of private and public rollback segments can exist in a database. As an instance opens a database, the instance attempts to acquire one or more rollback segments according to the following rules:

    The instance must acquire at least one rollback segment. If the instance is the only instance accessing the database, it acquires the SYSTEM segment. If the instance is one of several instances accessing the database in an Oracle Parallel Server environment, it acquires the SYSTEM rollback segment and at least one other rollback segment. If it cannot, Oracle returns an error, and the instance cannot open the database.

    The instance always attempts to acquire at least the number of rollback segments equal to the quotient of the values for the following initialization parameters:

    CEIL(TRANSACTIONS/TRANSACTIONS_PER_ROLLBACK_SEGMENT)


    CEIL is a SQL function that returns the smallest integer greater than or equal to the numeric input. In the example above, if TRANSACTIONS equal 155 and TRANSACTIONS_PER_ROLLBACK_SEGMENT equal 10, then the instance will try to acquire at least 16 rollback segments. (However, an instance can open the database even if the instance cannot acquire the number of rollback segments given by the division above.)


    --------------------------------------------------------------------------------
    Note:
    The TRANSACTIONS_PER_ROLLBACK_SEGMENT parameter does not limit the number of transactions that can use a rollback segment. Rather, it determines the number of rollback segments an instance attempts to acquire when opening a database.

    --------------------------------------------------------------------------------




    After acquiring the SYSTEM rollback segment, the instance next tries to acquire all private rollback segments specified by the instance's ROLLBACK_SEGMENTS parameter. If one instance in an Oracle Parallel Server opens a database and attempts to acquire a private rollback segment already claimed by another instance, the second instance trying to acquire the rollback segment receives an error during startup. An error is also returned if an instance attempts to acquire a private rollback segment that does not exist.

    If the instance has acquired enough private rollback segments in number 3, no further action is required. However, if an instance requires more rollback segments, the instance attempts to acquire public rollback segments.

    Once an instance claims a public rollback segment, no other instance can use that segment until either the rollback segment is taken offline or the instance that claimed the rollback segment is shut down.

    A database used by the Oracle Parallel Server optionally can have only public and no private segments, as long as the number of segments in the database is high enough to ensure that each instance that opens the database can acquire at least two rollback segments, one of which is the SYSTEM rollback segment. However, when using the Oracle Parallel Server, you may want to use private rollback segments.

    See Also:

    Oracle8i Parallel Server Concepts

    Oracle8i Parallel Server Administration, Deployment, and Performance

    for more information about rollback segment use in an Oracle Parallel Server




    Rollback Segment States
    A rollback segment is always in one of several states, depending on whether it is offline, acquired by an instance, involved in an unresolved transaction, in need of recovery, or dropped. The state of the rollback segment determines whether it can be used in transactions, as well as which administrative procedures a DBA can perform on it.

    The rollback segment states are:

    OFFLINE
    Has not been acquired (brought online) by any instance.

    ONLINE
    Has been acquired (brought online) by an instance; may contain data from active transactions.

    NEEDS RECOVERY
    Contains data from uncommitted transactions that cannot be rolled back (because the data files involved are inaccessible), or is corrupted.

    PARTLY AVAILABLE
    Contains data from an in-doubt transaction (that is, an unresolved distributed transaction).

    INVALID
    Has been dropped (The space once allocated to this rollback segment will later be used when a new rollback segment is created.)




    The data dictionary table DBA_ROLLBACK_SEGS lists the state of each rollback segment, along with other rollback information.

    Figure 4-9 shows how a rollback segment moves from one state to another.

    Figure 4-9 Rollback Segment States and State Transitions


    PARTLY AVAILABLE and NEEDS RECOVERY Rollback Segments
    The PARTLY AVAILABLE and NEEDS RECOVERY states are very similar. A rollback segment in either state usually contains data from an unresolved transaction.

    A PARTLY AVAILABLE rollback segment is being used by an in-doubt distributed transaction that cannot be resolved because of a network failure. A NEEDS RECOVERY rollback segment is being used by a transaction (local or distributed) that cannot be resolved because of a local media failure, such as a missing or corrupted datafile, or is itself corrupted.

    Oracle or a DBA can bring a PARTLY AVAILABLE rollback segment online. In contrast, you must take a NEEDS RECOVERY rollback segment OFFLINE before it can be brought online. (If you recover the database and thereby resolve the transaction, Oracle automatically changes the state of the NEEDS RECOVERY rollback segment to OFFLINE.)

    A DBA can drop a NEEDS RECOVERY rollback segment. (This allows the DBA to drop corrupted segments.) A PARTLY AVAILABLE segment cannot be dropped; you must first resolve the in-doubt transaction, either automatically by the RECO process or manually.

    If you bring a PARTLY AVAILABLE rollback segment online (by a statement or during instance startup), Oracle can use it for new transactions. However, the in-doubt transaction still holds some of its transaction table entries, so the number of new transactions that can use the rollback segment is limited.

    Also, until you resolve the in-doubt transaction, the transaction continues to hold the extents it acquired in the rollback segment, preventing other transactions from using them. Thus, the rollback segment might need to acquire new extents for the active transactions, and therefore grow. To prevent the rollback segment from growing, a database administrator might prefer to create a new rollback segment for transactions to use until the in-doubt transaction is resolved, rather than bring the PARTLY AVAILABLE segment online.

    See Also:

    Oracle8i Distributed Database Systems for information about failures in distributed transactions

    "When Rollback Information Is Required" for information on the transaction table





    Deferred Rollback Segments
    When a tablespace goes offline so that transactions cannot be rolled back immediately, Oracle writes to a deferred rollback segment. The deferred rollback segment contains the rollback entries that could not be applied to the tablespace, so that they can be applied when the tablespace comes back online. These segments disappear as soon as the tablespace is brought back online and recovered. Oracle automatically creates deferred rollback segments in the SYSTEM tablespace.

  7. #7
    Join Date
    Dec 2000
    Location
    Ljubljana, Slovenia
    Posts
    4,439
    Originally posted by tamilselvan
    I feel Oracle's Rollback Tablespace ( segements) concept was not designed properly. Oracle should have been designed/developed to use /tmp (in Unix) or C:\TEMP (in NT) area for its internal activities such as maintaining read consistency, concurrency and sort activities.
    I'm not sure I understand exactly what do you mean by this, could you elaborate your idea? Should the /tmp "structures" that would implement undo entries still be formated as database blocks? If yes, what would be the difference then? If no, how would Oracle suppose to load "pre-changed" image of db blocks into buffer cache for read consistency? And how would you backup those structures to be able to perform recovery?
    Jurij Modic
    ASCII a stupid question, get a stupid ANSI
    24 hours in a day .... 24 beer in a case .... coincidence?

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  


Click Here to Expand Forum to Full Width