Article: Mastering Data History using Oracle's Flashback Data Archive Feature

The Historical data is key for business decisions and having reliable data is very important for organizations. There are frequent implications for both financial and legal data for organizations and having a secure and accurate history of change of data is crucial for business.

Oracle Flashback technology offers significant benefits for database management and recovery. 

Please see the below article how it will help to meet the organizational needs.

Mastering Data History : A Guide using Oracle's Flashback Data Archive Feature
https://www.linkedin.com/pulse/mastering-data-history-guide-using-oracles-flashback-archive?trk=public_profile_article_view

Thanks,

https://oracleracexpert.com

Automatic Temporary Tablespace and undo tablespace Shrink in Oracle21c

Automatic Temporary Tablespace Shrink

Temporary tablespaces are used for storing temporary data and Users will notice high temporary tablespace usage when using sorts, hash joins and query transformations and DBA needs to manually size the temporary tablespace.

The automatic temporary tablespace helps to take care of below operations automatically

• Shrink temporary tablespace to reclaim unused space
• Grow temporary tablespace based upon high temp usage

You can run below query to identify the free space

SQL> SELECT * FROM dba_temp_free_space;

Or

SQL> SELECT TABLESPACE_NAME,TABLESPACE_SIZE/1024/1024 "TABLESPACE_SIZE", FREE_SPACE/1024/1024 "FREE_SPACE" from dba_temp_free_space;

Automatic Undo  Tablespace Shrink

Oracle Database creates and manages the information needed to roll back, or undo, changes before they are committed. These undo records are stored in the undo segments in an undo tabs pace.

An undo tablespace is used for undo management, it helps to undo data or rollback any transaction. In 11g Oracle introduced automatic undo management it helps to manage undo segments in a database. The UNDO_MANAGEMENT parameter is set to AUTO or null enables automatic undo management and UNDO_TABLESPACE specifies the name of the undo tablespace.

Use UNDO_RETENTION initialization parameter to specify minimum undo retention period in seconds and you will see better results with a fixed-size undo tablespace when using Automatic tuning of undo retention. The Undo Advisor can help you estimate the capacity and you can access through Oracle Enterprise Manager or using DBMS_ADVISOR or DBMS_UNDO_ADV package.

The undo tablespace can grow large and the easy way to reclaim the space from undo tablespace is to create a new undo tablespace and set the database with new undo tablespace and drop the old undo tablespace.

SQL> CREATE UNDO TABLESPACE UNDO2 DATAFILE '/u01/oradata/ORCL/undo02.dbf' SIZE 5G AUTOEXTEND ON ;
SQL> ALTER SYSTEM SET UNDO_TABLESPACE=UNDO2;
SQL> DROP TABLESPACE UNDO1 INCLUDING CONTENTS AND DATAFILES;

Oracle 21c introduces automated way to recover the space, this feature shrinks the undo tablespace by dropping the expired segments and extents, also it performs the data file shrink if possible. Note that data file shrink is based upon allocated extents.

This feature takes care of below operations automatically

• Recovery space from transactions that are not active
• Allow large transactions to run successfully by recovering space from expired undo

Please see the example for using DBMS_ADVISOR for UNDO.

DECLARE
tname VARCHAR2(30);
oid NUMBER;
BEGIN
DBMS_ADVISOR.CREATE_TASK('Undo Advisor', tid, tname, 'Undo Advisor Task');
DBMS_ADVISOR.CREATE_OBJECT(tname, 'UNDO_TBS', null, null, null, 'null', oid);
DBMS_ADVISOR.SET_TASK_PARAMETER(tname, 'TARGET_OBJECTS', oid);
DBMS_ADVISOR.SET_TASK_PARAMETER(tname, 'START_SNAPSHOT', 1);
DBMS_ADVISOR.SET_TASK_PARAMETER(tname, 'END_SNAPSHOT', 2);
DBMS_ADVISOR.SET_TASK_PARAMETER(tname, 'INSTANCE', 1);
DBMS_ADVISOR.EXECUTE_TASK(tname);
END;
/

Where

TARGET_OBJECTS is the undo tablespace of the system
START_SNAPSHOT Starting snapshot in the AWR to perform analysis
END_SNAPSHOT Ending snapshot in the AWR to perform analysis
BEGIN_TIME_SEC The beginning time of the period and now.
END_TIME_SEC The ending time of the period and now

Thanks & Regards,

http://oracleracexpert.com, Oracle ACE

ORA-01555: snapshot too old: rollback segment number x with name "_xxxxx" too small

When we come across “snapshot too old” error we need to look into all possibilities

1. Determine if UNDO_MANAGEMENT is MANUAL or AUTO – Make sure you are using Auto, this will take care of auto management and will help to tune

2. In the ora-01555, if you see segment number with name that means it is caused by UNDO segment, if not LOG segment due to read consistency

3. Find out which client sessions or programs causing the issue and QUERY DURATION.

The possible solution will be set UNDO_MANAGEMENT to AUTO then make sure we have set correct value for UNDO_RETENTION.

Run below SQL query to identify weather undo tablespace was too small to maintain UNDO_RETENTION

select inst_id, to_char(begin_time,'MM/DD/YYYY HH24:MI') begin_time,
UNXPSTEALCNT "# Unexpired|Stolen", EXPSTEALCNT "# Expired|Reused",
SSOLDERRCNT "ORA-1555|Error", NOSPACEERRCNT "Out-Of-space|Error",
MAXQUERYLEN "Max Query|Length" from gv$undostat
where begin_time between
to_date(‘Start time of the query','MM/DD/YYYY HH24:MI:SS')
and
to_date('End time of the query','MM/DD/YYYY HH24:MI:SS')
order by inst_id, begin_time;

Find out the current retention period by querying the tuned_undoretention column of v$undostat. The database tunes the undo retention period to be longer than the long running query. The v$undostat view contains one row for each 10-minute stats collection interval over the last 4 days. The Data beyond 4 days can query the dba_hist_undostat view.

The below query will display the tuned_undoretention value in seconds:

select to_char(begin_time, 'DD-MON-RR HH24:MI') begin_time,
to_char(end_time, 'DD-MON-RR HH24:MI') end_time,
tuned_undoretention from v$undostat
order by end_time;

Refer Oracle notes
Note 563470.1 Lob retention not changing when undo_retention is changed
Note 800386.1 ORA-1555 - UNDO_RETENTION is silently ignored if the LOB
Note 422826.1 How To Identify LOB Segment Use PCTVERSION Or RETENTION
Bug:3200789 Abstract: VISIBILITY OF LOB SEGMENT USAGE FOR UNDO

Thanks & Regards,

http://oracleracexpert.com, Oracle ACE

ORA-01555: snapshot too old: rollback segment number

There are many reasons for this error. In this post I am providing all the possible scenarios and related Oracle Notes/Links.

Concepts/Definitions

The ORA-1555 errors can happen when a query is unable to access enough undo to build
a copy of the data at the time the query started. Committed "versions" of blocks are
maintained along with newer uncommitted "versions" of those blocks so that queries can
access data as it existed in the database at the time of the query. These are referred to as
"consistent read" blocks and are maintained using Oracle undo management.

See Document 40689.1 - ORA-1555 "Snapshot too old" - Detailed Explanation for more about
these errors.

Diagnosing
Due to space limitations, it is not always feasible to keep undo blocks on hand for the life of the instance. Oracle Automatic Undo Management (AUM) helps to manage the time frame that undo blocks are stored. The time frame is the "retention" time for those blocks.

There are several ways to investigate the ORA-1555 error. In most cases, the error is a legitimate problem with getting to an undo block that has been overwritten due to the undo "retention" period having passed.

AUM will automatically tune up and down the "retention period, but often space limitations or configuration of the undo tablespace will throttle back continuous increases to the "retention" period.

The error message is reported in the user session and often is not captured in the alert log. The user could see a message like

Using rollback segment functionality:

ORA-1555: snapshot too old (rollback segment too small)

or

Using AUM:

ORA-01555: snapshot too old: rollback segment number 9 with name "_SYSSMU9$" too small

If the error is captured in the alert.log, you would see something like

Tue May 26 16:16:57 2009

ORA-01555 caused by SQL statement below (SQL ID: 54yn3n36w24ft, Query Duration=922 sec, SCN: 0x0007.8a55f4e3)

Initial Investigation

Rollback Segments:

With Oracle 10g and later versions of Oracle, you can still use a Rollback Segments configuration. ORA-1555 errors in that environment still follow older guidelines as described in


Document 10579.1 - How many Rollback Segments to Have
Document 107085.1 - Tuning Rollback Segments
Document 69464.1 - Rollback Segment Configuration & Tips
Automatic Undo Management:

The database will be self tuning for undo when using Automatic Undo Management. This does not eliminate ORA-1555 completely, but does minimize ORA-1555 as long as there is adequate space in the undo tablespace and workloads tend to follow repeatable patterns. In some cases with periodic changes to workload (large data updates particularly with LOB data) the self tuning of undo can become aggressive and lead to undo issues.

Document 461480.1 - FAQ Automatic Undo Management (AUM) / System Managed Undo (SMU)
Document 135053.1 - How to Create a Database with Automatic Undo Management
Document 268870.1 - How to Shrink the datafile of Undo Tablespace
Document 231776.1 - How to switch a Database from Automatic Undo Management (AUM) back to using Rollback Segments
Document 396863.1 - How to Keep All UNDO Segments from Being Offlined in Oracle 10g - Fast Ramp-Up

LOB Issues:

Out-of-row LOB undo is maintained in the LOB segment. So the UNDO tablespace and undo retention is not associated with most LOB ORA-1555 issues. Instead the LOB column is created using either PCT_VERSION or RETENTION to manage how much space within blocks or time transpires before the LOB undo is overwritten. In environments with high updates, deletes on rows including LOBs, the chances of ORA-1555 on LOB undo is very high.

PCT_VERSION and RETENTION are not auto-tuned. To "tune" those configuration settings, you must change the values for PCT_VERSION or RETENTION. Changes to UNDO_RETENTION does not change LOB retention time frames.


Document 162345.1 - LOBS - Storage, Read-consistency and Rollback
Document 386341.1 - How to determine the actual size of the LOB segments and how to free the deleted/unused space above/below the HWM
Document 563470.1 'Lob retention not changing when undo_retention is changed
Document 422826.1 How to identify LOB Segment Use PCTVERSION or RETENTION from Data Dictionary

Error Tracing

Undo error tracing can be done for normal undo operations using the following events:

NOTE: Normal undo operations will be indicated in the error message in that the error message includes a segment name like

'¦. name "_SYSSMU1$" too small

If the error doesn't show a segment name

'¦ name "" too small

the problem is often related to LOB undo

If using pfile:
event="10442 trace name context forever, level 10"

If using spfile:
Alter system set events '10442 trace name context forever, level 10';

Reproduce the ORA-1555 error and upload the trace file to Oracle Support.

LOB undo error tracing is more difficult. Set additional tracing events as follows:

Start Session 1
Alter session set events '10046 trace name context forever, level 12';
Reproduce the error
Exit Session 1

Start Session 2
Alter session set events '10051 trace name context forever, level 1';
Reproduce the error
Exit Session 2

Start Session
Alter session set events '1555 trace name errorstack forever, level 3';
Reproduce the error
Exit Session 3

Additional resources to review:

Document 846079.1 - LOBs and ORA-1555 troubleshooting
Document 253131.1 - Concurrent Writes May Corrupt LOB Segment When Using Auto Segment Space Management
Document 467872.1 - TROUBLESHOOTING GUIDE (TSG) - ORA-1555
V$UNDOSTAT Analysis

The V$UNDOSTAT view holds undo statistics for 10 minute intervals. This view
represents statistics across instances, thus each begin time, end time, and
statistics value will be a unique interval per instance.

This does not track undo related to LOB
Document 262066.1 - How To Size UNDO Tablespace For Automatic Undo Management

Document 1112363.1 - When Does Undo Used Space Become Available?
Document 240746.1 - 10g NEW FEATURE on AUTOMATIC UNDO RETENTION

Diagnostics Scripts
Refer to Document 746173.1 : Common Diagnostic Scripts for AUM problems
and Document 877613.1 : AUM Common Analysis/Diagnostic Scripts
Common Causes/Solutions
Document 1555.1 - Known defects for ora-1555 error
Using Rollback Segments functionality:

* Problem happening on SYSTEM tablespace that still uses old Rollback Segment functionality even when configured for Automatic Undo Management (AUM).

* There are not enough rollback segments to manage the undo needed for long running queries.

* Rollback Segments are too small and undo is overwritten before long running queries complete.
Reference:

Document 69464.1 - Rollback Segment Configuration & Tips
Document 10630.1 - ORA-1555: 'Snapshot too old' - Overview
Document 862469.1 - ORA-604 & ORA-1555 Rollback Segment 0 with Name "System" Too Small

Using Automatic Undo Management (AUM):

* TUNED_UNDORETENTION in V$UNDOSTAT around the time of the error is lower than the QUERY DURATION indicated in the error message. This is a legitimate ORA-1555 and if queries are going to run for very long time frames, UNDO_RETENTION may need to be larger. Auto-tuned retention may not be able to keep up with the undo workload and staying within space limitations on the UNDO tablespace.

* LOB updates and/or deletes are frequent and a higher PCT_VERSION is required to provide enough space in the LOB Segment to accommodate the LOB undo. RETENTION on LOBs that are updated or deleted frequently can run into problems holding UNDO long enough for queries.

* QUERY DURATION shown in the error message is 30+ years and therefore, no amount of undo will satisfy the consistent read blocks.

Document 750195.1 - ORA-1555 Shows Unrealistic Query Duration (billions of seconds)

* QUERY DURATION shown in the error message is 0. NOTE: This has been filed as a bug on many release levels and has been very difficult to narrow down to a specific problem.

Document 761128.1 - ORA-1555 Error when Query Duration as 0 Seconds

* QUERY DURATION is lower than TUNED_UNDRETENTION. Undo header information can sometimes get overwritten or you could be seeing a bug.

* TUNED_UNDORETENTION stays very high and UNDO tablepsace continues to grow continuously or getting space errors.

Document 1112431.1 - Undo Remains Unexpired When Using Non-autoextensible Datafiles for Undo Tablespace.

* How to find the complete SQL statement caused ORA-1555 :
If the Database was not restarted after the error ORA-1555 , so the Statement can be obtained from :

select SQL_TEXT from SQL_TEXT where SQL_ID='<sql id from the error message>';

If the Database was restarted after the error ORA-1555 and an AWR snapshot was gathered before the restart , so the Statement can be obtained from :

select SQL_TEXT from DBA_HIST_SQLTEXT where SQL_ID='<sql id from the error message>';

Thanks
Satishbabu Gunukula, Oracle ACE
http://oracleracexpert.com

ORA-00600: internal error code, arguments: [krcrfr_nohist]

Users may see below error in alert_<SID>.log file.

Errors in file /oracle/ORAC/saptrace/diag/rdbms/ORAC/ORAC/trace/ORAC_ora_6240.trc (incident=211514):
ORA-00600: internal error code, arguments: [krcrfr_nohist], [2596956098], [49126131], [],  
ORA-00600: internal error code, arguments: [krcrfr_nohist], [2596956098], [49126131], [],
Use ADRCI or Support Workbench to package the incident.
See Note 411.1 at My Oracle Support for error and packaging details.
Fri Sep 27 21:44:47 2013
Errors in file /oracle/ORAC/saptrace/diag/rdbms/ORAC/ORAC/trace/ORAC_ora_7583.trc (incident=211585):
ORA-00600: internal error code, arguments: [krcrfi_nohist], [2596956688], [2594394265], [], [], [], [], [], [], [], [], []

Cause:
Users may see this error on databases where Block change tracking enabled. The corrupted blocks in the Block Change Tracking are causing the ORA-600 [krcrfr_nohist], which is a mismatch in the Block Change Tracking information.

This applies to Oracle 11.2.0.2 and later versions. You might be hitting a BUG:13701312 and check with Oracle Support to see any patch available.

Workaround: Disable and enable change tracking.

SQL> alter database disable block change tracking;
SQL> alter database enable block change tracking [using file '<file-name>'];

You may see below errors after ORA-00600

minact-scn: got error during useg scan e:12751 usn:1
minact-scn: useg scan erroring out with error e:12751
Suspending MMON action 'Block Cleanout Optim, Undo Segment Scan' for 82800 seconds

The above warning is raised while scanning UNDO segment. It indicates that undo segment scan has failed with ORA-12751 error.

The ora-12751 indicates that some part of MMON Operation is either taking too long to complete and taking too much CPU. Due to “Suspending MMON” you may not able to see AWR reports during the issue period.

Reference:
ORA-12751 "cpu time or run time policy violation" in the MMON Slave Process File during Feature Usage Statistics [FUS] (Doc ID 1291296.1)
Alert log shows: "Minact-scn: Useg Scan Erroring Out With Error E:12751" Warning (Doc ID 1478691.1)

Regards,
Satishbabu Gunukula, Oracle ACE
http://www.oracleracexpert.com

Oracle Recovery Manager(RMAN) New features in 11g

Oracle Recovery Manager (RMAN) is the preferred method to backup database and it is included with Oracle software. Using RMAN you can backup the database to local/shared disk without any other agents. If you need to backup to tape then you need Media management library.

Please refer below link for configuring RMAN to backup database to a media manager.
http://docs.oracle.com/cd/B28359_01/backup.111/b28270/rcmconfb.htm#i1006526

The restore and recovery of the database is very easy using RMAN, it will figure it out where the backups are stored and which data files need to be restored and recovered.

Oracle 11g introduced many exciting new features in Recovery Manager (RMAN). Lets start using these new features and benefit from it.

• RMAN Proactive health checks :- Now you can proactively check database block corruptions using VALIDATE DATABASE
RMAN > VALIDATE DATABASE;

You can also run the proactive check on a datafile, tablespace or block.
RMAN > VALIDATE DATAFILE 1 BLOCK 10;
RMAN > VALIDATE TABLESAPCE users;

• Database Recovery Advisor : – The data recovery advisor automatically diagnoses the corruptions and loss of data on disk and determines the corrective repair options.

The LIST FAILURE command displays any failures with priority of CRITICAL or HIGH in order of importance
RMAN> LIST FAILURE

The ADVISE FAILURE command provides repair advice for failures listed by LIST FAILURE
RMAN > ADVICE FAILURE

The REPAIR FAILURE command applies the repair scripts advised by the ADVISE FAILURE command.
RMAN>REPAIR FAILURE

You can also use PREVIEW command to see the contents of the repair before proceeding to actual repair
RMAN>REPAIR FAILURE PREVIEW

• Faster Backup Compression: The ZLIB compression is faster than original B2ZIP compression with less CPU resources

Use below command for ZLIB compression
RMAN> configure compression algorithm 'ZLIB' ;

Use below command to change compression to BZIP2
RMAN> configure compression algorithm 'bzip2';

• More backup Comcodession Choices (11gR2 only): Now we have different types of comcodession levels, i.e. LOW, MEDIUM and HIGHT and with CPU resource usage from least to highest.

Here is the example
RMAN> configure comcodession algorithm ‘medium’;

• RMAN Backups to Cloud: Now you can set your RMAN backup destination to Cloud. Amazon provides cloud computing service, but you need to use specially developed media management library.

• RMAN UNDO bypass: The RMAN backup command no longer backs up the UNDO data that is not needed for recovery. Prior to Oracle 11g, all UNDO transactions that were already committed also backed up. This backup undo optimization minimizes the backup time and storage.

• Duplicate Database from Backup (11gR2 only): Prior 11g, In order to duplicate a database using DUPLICATE TARGET DATABASE command you need connect to target database. In case if target database is down you cannot able to duplicate. From 11g, you can able to duplicate the database without connecting to target database, make sure that you have backups available on duplicate site.

Here is the example for duplicate database
connect auxiliary sys/xxxx@dup
connect catalog rman/xxx@rmancat
duplicate database 'PRD' to DUP' until time "to_date('01/01/11 10:00:00','mm/dd/yy hh24:mi:ss')"
db_file_name_convert =( “/dbs1/oradata/PRD","/dbs2/oradata/DUP")
backup location '/rman_backup' ;

Duplicate Database options
-NOREDO – Using this option no archivelogs will be applied
-UNDO_TABLESPACE – You must specify the UNDO tablesapce when you are not connected to target database.

• Set NEWNAME Flexibility while restoring Database (11gR2 only): When you are restoring database on different server with different file system structure you need to change data file path using “SET NEWNAME” command. If you have hundreds of datafiles then you need to change the path for all data files.

run
{
set newname for datafile 1 to ‘/dbs1/oradata/system01.dbf’;
set newname for datafile 2 to ‘/dbs2/oradata/users01.dbf’;
---- (Some detail removed for brevity) ----
restore database;
}

From 11g, you have flexibility using a single “SET NEWNAME” clause for all datafiles in a tablespace.

run
{
set newname for tablespace DATA to '/dbs1/oradata/data%b.dbf';
set newname for tablespace INDEX to '/dbs2/oradata/index%b.dbf';
---- (Some detail removed for brevity) ----
Restore database;
}

You can also set the path for entire database using a single command.
run
{
set newname for database to '/dbs1/oradata/%b';
restore database;
}

• TO DESTINATION Clause in BACKUP command (11gR2 only): You can specify a destination location for RMAN backups using “TO DESTINATION” clause .

RMAN> backup tablespace users to destination '/backup/rman;
You can also use this clause in ALLOCATE CHANNEL command
RMAN> run {
2> allocate channel c1 type disk to destination '/backup/rman';
backup database;
3> }

• Parallel backup of Same datafile: Now you can break the large datafiles into small sections and it reduces the backup time of large datafiles

Here is the example
run {
allocate channel c1 type disk format '/rman_backup1/%U';
allocate channel c2 type disk format '/rman_backup2/%U';
backup section size 100m
datafile 10;
}

• Automatic Block Repair (11g R2 Only): This feature automatically repairs the blocks on primary from blocks on Physical Standby. RECOVER BLOCK enhanced to repair the blocks on Primary as soon as it detects the corruption from standby when available.

• Transported Tablespace Enhancement: Prior 11g, the transported tablespace must be in read-only mode. But from 11g onwards you can transport the tablespace both in read-only and read-write mode.

• Virtual Private Catalog: The virtual catalogs are created within in same RMAN Catalog. Prior to 11g, we have only one catalog and catalog owner can able to see repository information for all databases. From 11g, you can separate the catalog database access across the departments/groups (for ex, Manufacturing, IT…etc.) using virtual catalogs feature to maximize the security.

Create a separate user for IT department to grant catalog access
SQL> create user it_user identified by xxxxx quota unlimited on users;
SQL> grant recovery_catalog_owner to it_user;

Grant catalog access on “itdb1” to virtual catalog owner “it_user”
$ rman target=/ rcvcat rman/rman@rmancat
RMAN> grant catalog for database itdb1 to it_user;

Now connect using the virtual catalog owner “it_user” and create virtual catalog
$ rman target=/ rcvcat ituser/xxxx@rmancat
RMAN> create virtual catalog;

• Merging RMAN Catalogs: If you have operations across different regions and maintaining different catalogs for each state and want to merge then you can use merge catalog feature without re-registering the databases in new catalog.
In below example we are importing rmancat2 into rmancat1
$ rman target=/ rcvcat rman/rman@rmancat1
RMAN> import catalog rman/rman@rmancat2;

• GUI interface for RMAN: Now you can use RMAN functionality through a GUI iFrom Enterprise manager

•Archive log Deletion Policy Enhancements: The archive log deletion policy has been extended in 11g for greater flexibility and protection for Dataguard environments.

Oracle 10g Syntax.
CONFIGURE ARCHIVELOG DELETION POLICY {CLEAR | TO {APPLIED ON STANDBY | NONE}}

Oracle 11g Syntax.
ARCHIVELOG DELETION POLICY {CLEAR | TO {APPLIED ON [ALL] STANDBY |BACKED UP integer TIMES TO DEVICE TYPE deviceSpecifier |NONE | SHIPPED TO [ALL] STANDBY}[ {APPLIED ON [ALL] STANDBY | BACKED UP integer TIMES TO DEVICE TYPE deviceSpecifier |NONE | SHIPPED TO [ALL] STANDBY}]...}

Regards
Satishbabu Gunukula
http://www.oracleracexpert.com

How to recover Undo or Rollback Tablespace

While handing with undo tablespace you need to be extra cautious due to active transactions in the undo segments. You need to follow different approach depend upon scenario.

Scenario 1: Undo/rollback datafile damaged or dropped accidently when database is up
In this scenario the lost or damaged datafile may contain the active transactions and you cannot able to offline or drop the undo/rollback datafile.

• Startup mount
SQL> STARTUP MOUNT

• Check the status of the datfile
SQL> SELECT FILE#, NAME, STATUS FROM V$DATAFILE;
If the datafile is offline you must bring the datafile online before you recover

• Restore and Recover the datafile
$ rman TARGET / CATALOG rman/*****@rman
RMAN> Restore datafile 'fullpath_and_filename'
RMAN> Recover datafile 'fullpath_and_filename'

• Open the database.
SQL> ALTER DATABASE OPEN;

Scenario 2: Undo/rollback datafile damaged or dropped accidently when database is down

• If using automatic UNDO_MANAGMENT then comment out the parameter in init.ora file. If using rollback segments then comment out ROLLBACK_SEMGNETS parameter

• Mount the database in restricted mode
SQL> STARTUP RESTRICT MOUNT

• Offline the undo or rollback datafile and drop the file
SQL> ALTER DATABASE DATAFILE 'fullpath_and_filename' OFFLINE DROP;

• Open the database and drop the UNDO tablespace or the tablespace which contains the rollback segments
SQL> ALTER DATABASE OPEN
SQL> DROP TABLESPACE tablespace_name INCLUDING CONTENTS;

• Recreate the undo tablespace. If you are using rollback segments, recreate the rollback segment tablespace and rollback segments. Make sure to bring the rollback segments online.

If using Undo tablespace
SQL> CREATE UNDO TABLESPACE undotbs2 DATAFILE '/oradata/undotbs2_01.dbf' SIZE 100M REUSE AUTOEXTEND ON;

If using rollback segment tablespace
SQL> CREATE TABLESPACE rollback_tbs DATAFILE '/oradata/rollback_tbs01.dbf' SIZE 100M EXTENT MANAGEMENT LOCAL;
SQL> CREATE ROLLBACK SEGMENT rollback1 TABLESPACE rollback_tbs;
SQL> ALTER ROLLBACK SEGMENT rollback1 ONLINE;

• Modify the parameter file settings
If using UNDO tablespace
UNDO_MANAGEMENT=AUTO
UNDO_TABLESPACE=new_undo_tablespace_name

If you are using the rollback segment tablespace, include the rollback segments that you created in previous step in ROLLBACK_SEMGNETS parameter in init.ora file

• Take the database out of restricted mode.
SQL> ALTER SYSTEM DISABLE RESTRICTED SESSION;

Oracle 11g introduced a new feature called RMAN UNDO Bypass. The RMAN backup command no longer backs up the UNDO data that is not needed for recovery. Prior to Oracle 11g, all UNDO transactions that were already committed also backed up. This backup undo optimization minimizes the backup time and storage.

Regards,
Satishbabu Gunukula
http://www.oracleracexpert.com

Flashback Table Feature in Oracle 10g

In Oracle 9i Database, we have concept of Flashback Query option to retrieve data from a point in time in the past. The Oracle 10g provides the ability to recover a table or set of tables to a specified point in time in the past, this concept is called “Flashback table”.

Oracle Flashback Table operation is very quick and you do not have to restore any data from backups, and the rest of your database remains available while the Flashback Table operation is being performed.

The Flashback table depends on Undo information retained in the undo tablespace. If you set UNDO_RETENTION=1 hr, Oracle will not overwritten the data in undo tablespace until 1 hr. User can recover from their mistakes until specified time only.

Flashback table feature has some prerequisites:
•Row movement must be enabled on the table.
SQL> ALTER TABLE table_name ENABLE ROW MOVEMENT;
•You must have SELECT, INSERT, DELETE, and ALTER privileges on the table.
•You must have FLASHBACK ANY TABLE privilege or the FLASHBACK object privilege on the table.

Use below commands to restore the table to its state when the database was at the time specified by SCN or point in time.
SQL> FLASHBACK TABLE employee_tbl TO SCN 786;
or
SQL> FLASHBACK TABLE employee_tbl TO TIMESTAMP TO_TIMESTAMP ('2010-03-01 09:00:00', 'YYYY-MM-DD HH:MI:SS')

Regards
Satishbabu Gunukula
http://www.oracleracexpert.com