Ad
More Related Content
What's hot (20)
Viewers also liked (19)
Ad
Similar to Less10 Undo (20)
Ad
More from vivaankumar (20)
Less10 Undo
- 2. Objectives After completing this lesson, you should be able to: Explain DML and undo data generation Monitor and administer undo data Describe the difference between undo data and redo data Configure undo retention Guarantee undo retention Use the Undo Advisor
- 3. Data Manipulation Data manipulation language (DML) consists of the following SQL statements: INSERT UPDATE DELETE MERGE DML always executes as part of a transaction, which can be: Rolled back using the ROLLBACK command Committed using the COMMIT command
- 4. Undo Data Undo data is: A copy of original, premodified data Captured for every transaction that changes data Retained at least until the transaction is ended Used to support: Rollback operations Read-consistent queries Flashback Query, Flashback Transaction, and Flashback Table Recovery from failed transactions User
- 5. Undo Data Full Notes Page
- 6. Transactions and Undo Data Each transaction is assigned to only one undo segment. An undo segment can service more than one transaction at a time. Data in Undo “ old ” data in undo tablespace UPDATE DML operations buffer cache Redo log buffer Redo log files New change details in Redo log files Undo segment
- 7. Storing Undo Information Undo information is stored in undo segments, which are stored in an undo tablespace. Undo tablespaces: Are used only for undo segments Have special recovery considerations May be associated with only a single instance Require that only one of them be the current writable undo tablespace for a given instance at any given time
- 8. Undo Data Versus Redo Data Redo log files Undo segment Inconsistent reads in multiuser systems Undo segments Rollback, read consistency, flashback How to undo a change Undo Protects against Stored in Used for Record of Rolling forward database changes Redo log files Data loss How to reproduce a change Redo
- 9. Managing Undo Automatic undo management: Fully automated management of undo data and space in a dedicated undo tablespace For all sessions Self-tuning in AUTOEXTEND tablespaces to satisfy long-running queries Self-tuning in fixed-size tablespaces for best retention DBA tasks in support of Flashback operations: Configuring undo retention Changing undo tablespace to a fixed size Avoiding space and “snapshot too old” errors
- 10. Configuring Undo Retention UNDO_RETENTION specifies (in seconds) how long already committed undo information is to be retained. The only time you must set this parameter is when: The undo tablespace has the AUTOEXTEND option enabled You want to set undo retention for LOBs You want to guarantee retention DBA
- 11. Configuring Undo Retention Full Notes Page
- 12. Guaranteeing Undo Retention A transaction will fail if it generates more undo than there is space. SELECT statements running 15 minutes or less are always satisfied. Undo data in undo tablespace Retention guarantee: 15 minutes
- 13. Changing an Undo Tablespace to a Fixed Size Reasons: Supporting Flashback operations Limiting tablespace growth Workflow: Run regular workload. Self-tuning mechanism establishes minimum required size. (Optional) Use Undo Advisor, which calculates required size for future growth. (Optional) Change undo tablespace to a fixed size.
- 14. General Undo Information Current table- space size
- 15. Using the Undo Advisor
- 16. Viewing System Activity 3 1 2
- 17. Summary In this lesson, you should have learned how to: Explain DML and undo data generation Monitor and administer undo segments Describe the difference between undo data and redo data Configure undo retention Guarantee undo retention Use the Undo Advisor
- 18. Practice 10 Overview: Managing Undo Segments This practice covers the following topics: Viewing system activity Calculating undo tablespace sizing to support a 48-hour retention interval Modifying an undo tablespace to support a 48-hour retention interval
Editor's Notes
- #3: Oracle Database 11 g : Administration Workshop I 10 -
- #4: Oracle Database 11 g : Administration Workshop I 10 - Data Manipulation Data is manipulated, or modified, by the DML class of SQL statements: INSERT , UPDATE , DELETE , and MERGE . These statements execute as part of a transaction, which starts with the first successful DML statement and ends with either a COMMIT or ROLLBACK command. A transaction is either entirely committed or entirely rolled back. In addition to the explicit COMMIT or ROLLBACK commands, they can also occur implicitly. For example, rollback may occur if there is a process or system failure. Commit may occur after a DDL command, such as the CREATE TABLE command. Note: The MERGE command performs a combination of DML commands to merge data from one table into another. It is covered in the lesson titled “Managing Data and Concurrency.”
- #5: Oracle Database 11 g : Administration Workshop I 10 - Undo Data The Oracle database saves the old value (undo data) when a process changes data in a database. It stores the data as it exists before modifications. Capturing undo data enables you to roll back your uncommitted data. Undo supports read-consistent and flashback queries. Undo can also be used to “rewind” (flash back) transactions and tables. Read-consistent queries provide results that are consistent with the data as of the time a query started. For a read-consistent query to succeed, the original information must still exist as undo information. If the original data is no longer available, you receive a “Snapshot too old” error. As long as the undo information is retained, the Oracle database can reconstruct data to satisfy read-consistent queries. Flashback queries purposely ask for a version of the data as it existed at some time in the past. As long as undo information for that past time still exists, flashback queries can complete successfully. Flashback Transaction uses undo to create compensating transactions, to back out a transaction and its dependent transactions. With Flashback Table, you can recover a table to a specific point in time. Undo data is also used to recover from failed transactions. A failed transaction occurs when a user session ends abnormally (possibly because of network errors or a failure on the client computer) before the user decides to commit or roll back the transaction. Failed transactions may also occur when the instance crashes or you issue the SHUTDOWN ABORT command.
- #6: Oracle Database 11 g : Administration Workshop I 10 - Undo Data (continued) In case of a failed transaction, the safest behavior is chosen, and the Oracle database reverses all changes made by a user, thereby restoring the original data. Undo information is retained for all transactions, at least until the transaction is ended by one of the following: User undoes a transaction (transaction rolls back). User ends a transaction ( transaction commits). User executes a DDL statement, such as a CREATE , DROP , RENAME or ALTER statement. If the current transaction contains any DML statements, the database first commits the transaction and then executes and commits the DDL as a new transaction. User session terminates abnormally ( transaction rolls back). User session terminates normally with an exit ( transaction commits). The amount of undo data that is retained and the time for which it is retained depend on the amount of database activity and the database configuration.
- #7: Oracle Database 11 g : Administration Workshop I 10 - Transactions and Undo Data When a transaction starts, it is assigned to an undo segment. Throughout the life of the transaction, when data is changed, the original (before the change) values are copied into the undo segment. You can see which transactions are assigned to which undo segments by checking the V$TRANSACTION dynamic performance view. Undo segments are specialized segments that are automatically created by the instance as needed to support transactions. Like all segments, undo segments are made up of extents, which, in turn, consist of data blocks. Undo segments automatically grow and shrink as needed, acting as a circular storage buffer for their assigned transactions. Transactions fill extents in their undo segments until a transaction is completed or all space is consumed. If an extent fills up and more space is needed, the transaction acquires that space from the next extent in the segment. After all extents have been consumed, the transaction either wraps around back into the first extent or requests a new extent to be allocated to the undo segment. Note: Parallel DML and DDL operations can actually cause a transaction to use more than one undo segment. To learn more about parallel DML execution, see the Oracle Database Administrator’s Guide .
- #8: Oracle Database 11 g : Administration Workshop I 10 - Storing Undo Information Undo segments can exist only in a specialized form of tablespace called an undo tablespace . (You cannot create other segment types, such as tables, in the undo tablespace.) The installation process automatically creates a “smallfile” undo tablespace. You can also create a “bigfile” undo tablespace. However, in a high-volume online transaction processing (OLTP) environment with many short concurrent transactions, contention could occur on the file header. An undo tablespace, stored in multiple data files, can resolve this potential issue. Although a database may have many undo tablespaces, only one of them at a time can be designated as the current undo tablespace for any instance in the database. Undo segments are automatically created and always owned by SYS . Because the undo segments act as a circular buffer, each segment has a minimum of two extents. The default maximum number of extents depends on the database block size but is very high (32,765 for an 8 KB block size). Undo tablespaces are permanent, locally managed tablespaces with automatic extent allocation. They are automatically managed by the database. Because undo data is required to recover from failed transactions (such as those that may occur when an instance crashes), undo tablespaces can be recovered only while the instance is in the MOUNT state. Recovery considerations for undo tablespaces are covered in the lesson titled “Performing Database Recovery.”
- #9: Oracle Database 11 g : Administration Workshop I 10 - Undo Data Versus Redo Data Undo data and redo data seem similar at first, but they serve different purposes. Undo data is needed if there is the need to undo a change, and this occurs for read consistency and rollback. Redo data is needed if there is the need to perform the changes again, in cases where they are lost for some reason. Undo block changes are also written to the redo log. The process of committing entails a verification that the changes in the transaction have been written to the redo log file, which is persistent storage on the disk, as opposed to memory. In addition, the redo log file is typically multiplexed. As a result, there are multiple copies of the redo data on the disk. Although the changes may not yet have been written to the data files where the table’s blocks are actually stored, writing to the persistent redo log is enough to guarantee consistency of the database. Suppose that a power outage occurs just before committed changes have been reflected in the data files. This situation does not cause a problem because the transaction has been committed. When the system starts up again, it is thus able to roll forward any redo records that are not yet reflected in data files at the time of the outage.
- #10: Managing Undo The Oracle database provides automatic undo management , which is a fully automated mechanism for managing undo information and space in a dedicated undo tablespace for all sessions. The system automatically tunes itself to provide the best possible retention of undo information . More precisely, the undo retention period for autoextending tablespaces is tuned to be slightly longer than the longest-running active query. For fixed-size undo tablespaces, the database dynamically tunes for best possible retention. Automatic undo management is the default for Oracle Database 11 g (and later releases). Manual undo management is supported for backward compatibility with Oracle8 i and earlier releases but requires more DBA interaction. In manual undo management mode, undo space is managed through rollback segments (not through undo tablespace). Note: Oracle strongly recommends that you use automatic undo management. Although by default the Oracle database manages undo data and space automatically, you may need to perform some tasks if your database is using Flashback operations. The administration of undo should prevent space errors, the use of too much space, and “Snapshot too old” errors.
- #11: Configuring Undo Retention The UNDO_RETENTION initialization parameter specifies (in seconds) the low threshold value of undo retention. Set the minimum undo retention period for the autoextending undo tablespace to be as long as the longest expected Flashback operation. For autoextending undo tablespaces, the system retains undo for at least the time specified in this parameter, and automatically tunes the undo retention period to meet the undo requirements of the queries. But this autotuned retention period may be insufficient for your Flashback operations. For fixed-size undo tablespaces, the system automatically tunes for the best possible undo retention period on the basis of undo tablespace size and usage history; it ignores UNDO_RETENTION unless retention guarantee is enabled. So for automatic undo management, the UNDO_RETENTION setting is used for the three cases listed in the slide. In cases other than these three, this parameter is ignored.
- #12: Oracle Database 11 g : Administration Workshop I 10 - Configuring Undo Retention (continued) Undo information is divided into three categories: Uncommitted undo information: Supports a currently running transaction; is required if a user wants to roll back or if the transaction has failed. Uncommitted undo information is never overwritten. Committed undo information: Is no longer needed to support a running transaction but is still needed to meet the undo retention interval. It is also known as “unexpired” undo information. Committed undo information is retained when possible without causing an active transaction to fail because of lack of space. Expired undo information: Is no longer needed to support a running transaction. Expired undo information is overwritten when space is required by an active transaction.
- #13: Guaranteeing Undo Retention The default undo behavior is to overwrite committed transactions that have not yet expired rather than to allow an active transaction to fail because of lack of undo space. This behavior can be changed by guaranteeing retention. With guaranteed retention, undo retention settings are enforced even if they cause transactions to fail. RETENTION GUARANTEE is a tablespace attribute rather than an initialization parameter. This attribute can be changed only with SQL command-line statements. The syntax to change an undo tablespace to guarantee retention is: SQL> ALTER TABLESPACE undotbs1 RETENTION GUARANTEE; To return a guaranteed undo tablespace to its normal setting, use the following command: SQL> ALTER TABLESPACE undotbs1 RETENTION NOGUARANTEE; The retention guarantee applies only to undo tablespaces. Attempts to set it on a non-undo tablespace result in the following error: SQL> ALTER TABLESPACE example RETENTION GUARANTEE; ERROR at line 1: ORA-30044: 'Retention' can only specified for undo tablespace
- #14: Changing an Undo Tablespace to a Fixed Size You might have two reasons for changing the undo tablespace to a fixed size: to support Flashback operations (where you expect future use of the undo) or to prevent the tablespace from growing too large. If you decide to change the undo tablespace to a fixed size, you must choose a large enough size to avoid the following two errors: DML failures (because there is not enough space to the undo for new transactions) “ Snapshot too old” errors (because there was insufficient undo data for read consistency) Oracle recommends that you run a regular, full workload, allowing the undo tablespace to grow to its minimum required size. 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 for a system without Flashback operations, and for a system for which you do not expect longer-running queries in the future. You can use the Undo Advisor to enter your desired duration for the undo period for longer-running queries and flashback.
- #15: General Undo Information In Enterprise Manager, select Server > Automatic Undo Management. There are two pages: General and System Activity. In the top part of the General page, you see the Undo Retention Settings and information about the undo tablespace for this instance.
- #16: Using the Undo Advisor The middle part of the General Undo page is your access to the Undo Advisor. It provides an estimate of the undo tablespace size required to satisfy a given undo retention. The analysis region of the advisor displays the tablespace size required to support the retention period. You can click a point on the graph to see the tablespace size required to support the selected period. Click the Edit Undo Tablespace button, and then click Edit in the Datafile section to change the undo tablespace to a fixed size.
- #17: Viewing System Activity The top part of the page displays system activity during the selected period. Beneath this, there are three graphs: 1. Undo Tablespace Usage: Shows the tablespace size (in MB) by days of the month 2. Undo Retention Auto-Tuning: Visualizes the tuned undo retention (in minutes) by days of the month 3. Undo Generation Rate: Displays the undo generation (in KB per seconds) by days of the month
- #18: Oracle Database 11 g : Administration Workshop I 10 -
- #19: Oracle Database 11 g : Administration Workshop I 10 -