Clone an Oracle Database using Cold Physical BackupDatabase Name: troySource Database side:
(Troy database)
Cold Backup Steps:
1. Get the file path information using below query
Select name from v$datafile;
select member from v$logfile;
select name from v$controlfile;
2. Parameter file backup If troy database running on spfile
Create pfile=’/u01/backup/inittroy.ora’ from spfile;
If database running in pfile using os command to copy the pfile and placed in backup path.
3.Taken the control file backup
Alter database backup controlfile to trace as ‘/u01/backup/control01.ora’;
4.Shutdown immediate
5.Copy all the data files/log files using os command & placed in backup path.
6.Startup the database.
Clone Database side: (Clone database)
Database Name: Clone
Clone Database Steps:
1.Create the appropriate folder in corresponding path & placed the backup files in corresponding folder.(bdump,udump,create,pfile,cdump,oradata)
2.Change the init.ora parameter like control file path, dbname, instance name etc...
3.Create the password file using orapwd utility.(Database in windows we need to create the service id using oradim utility)
4.Startup the Database in NOMOUNT stage.
5.Create the control file for cloning database.
Using backup controlfile trace to generate the create controlfile scripts.Change the Database name & files path, also change 'REUSE' needs to be changed to 'SET'.
CREATE CONTROLFILE SET DATABASE "clone" RESETLOGS FORCE LOGGING NOARCHIVELOG
MAXLOGFILES 50
MAXLOGMEMBERS 5
MAXDATAFILES 100
MAXINSTANCES 1
MAXLOGHISTORY 453
LOGFILE
GROUP 1 '/U01/oradata/clone/redo01.log' SIZE 200M,
GROUP 2 '/U01/oradata/clone/redo02.log' SIZE 200M,
GROUP 3 '/U01/oradata/clone/redo03.log' SIZE 200M
DATAFILE'/U01/oradata/clone/system01.dbf',
'/U01/oradata/clone/undotbs01.dbf',
'/U01/oradata/clone/users01.dbf',
CHARACTER SET WE8ISO8859P1;
Note: placed the script in sql prompt. Now controlfile created.
6.Now open the database.
Alter database open resetlogs;
Note: Check the logfile, datafiles & instance status
**********************************************************************************
Clone an Oracle Database using Hot Physical BackupDatabase Name:
troyDatabase must be in Archive log mode.
Source Database side: (Troy database)
Hot Backup Steps:
1.Get the file path information using below query.
Select tablespace_name, file_name from dba_data_files order by 1;
2. Parameter file backup If troy database running on spfile
Create pfile=’/u01/backup/inittroy.ora’ from spfile;
If database running in pfile using os command to copy the pfile and placed in backup path.
3.Put the tablespace in begin backup mode Using os command to copy the datafiles belongs to begin backup mode tablespace & placed in backup path. (Refer below example)
4.Once copied the datafile, release the tablespace from begin backup mode to end backup
5.Repeat the steps 1-3 for all your tablespaces.
6.Taken the controlfile backup
Alter database backup controlfile to trace as ‘/u01/backup/control01.ora’;
7.Backup all your archive log files between the previous backup and the new backup as well.
Example:
steps:
2.Alter tablespace system begin backup;
To ensure the begin backup mode tablespace using below query
Select * from v$backup; (refer the Change#, Time column)
3. Host cp /u01/oracle/raja/system1.DBF /u01/backup/system01.dbf à using os command to copy the datafile.
4. Alter tablespace system end backup;
To ensure the begin backup mode tablespace using below query
Select * from v$backup;
Clone Database side: (Clone database)
Database Name: Clone
Clone Database Steps:
1.Create the appropriate folder in corresponding path & placed the backup files in corresponding folder.(bdump,udump,create,pfile,cdump,oradata)
2.Change the init.ora parameter like control file path, dbname, instance name etc...
3.Create the password file using orapwd utility.(Database in windows we need to create the service id using oradim utility)
4.Startup the Database in NOMOUNT stage.
5.Create the control file for cloning database.
Using backup controlfile trace to generate the create controlfile scripts.Change the Database name & files path, also change 'REUSE' needs to be changed to 'SET'.
CREATE CONTROLFILE SET DATABASE "clone" RESETLOGS FORCE LOGGING NOARCHIVELOG
MAXLOGFILES 50
MAXLOGMEMBERS 5
MAXDATAFILES 100
MAXINSTANCES 1
MAXLOGHISTORY 453
LOGFILE
GROUP 1 '/U01/oradata/clone/redo01.log' SIZE 200M,
GROUP 2 '/U01/oradata/clone/redo02.log' SIZE 200M,
GROUP 3 '/U01/oradata/clone/redo03.log' SIZE 200M
DATAFILE
'/U01/oradata/clone/system01.dbf',
'/U01/oradata/clone/undotbs01.dbf',
'/U01/oradata/clone/users01.dbf',
CHARACTER SET WE8ISO8859P1;
Note: placed the script in sql prompt. Now controlfile created.
6.Recover the database using controlfile.
Recover database using backup controlfile until cancel;
7.Now open the database.
Alter database open resetlogs;
Note: Check the logfile, datafiles status.
Friday, September 25, 2009
Thursday, September 24, 2009
Recovering a Lost Datafile Without a Backup: Example
RMAN can handle lost datafiles without user intervention during restore and recovery. When a datafile is lost, the possible cases can be classified as follows:
The control file knows about the datafile, that is, the user backed up the control file after datafile creation, but the datafile itself is not backed up. If the datafile record is in the control file, then RESTORE creates the datafile in the original location or in a user-specified location (for example, with SET NEWNAME). The RECOVER command can then apply the necessary logs to the datafile.
The control file does not have the datafile record, that is, the user did not back up the control file after datafile creation. During recovery, the database will detect the missing datafile and report it to RMAN, which will create a new datafile and continue recovery by applying the remaining logs. If the datafile was created in a parent incarnation, it will be created during restore or recover as appropriate.
In this example, the following sequence of events occurs:
You make a whole database backup of your ARCHIVELOG mode database.
You create a tablespace history containing a single datafile called /mydb/history01.dbf.
You populate the newly created datafile with data.
You archive all the active online redo logs.
A user accidentally deletes the datafile history01.dbf from the operating system before you have a chance to back it up.
In this case, the current control file knows about the datafile. To restore and recover the datafile, start RMAN, connect to the target database, and then enter the following commands at the RMAN prompt:# take the tablespace with the missing datafile offline
SQL "ALTER TABLESPACE history OFFLINE IMMEDIATE";
# restore the tablespace even though you have no backup
RESTORE TABLESPACE history;
# recover tablespace
RECOVER TABLESPACE hisotry;
# bring the recovered tablespace back online
SQL "ALTER TABLESPACE history ONLINE";
The control file knows about the datafile, that is, the user backed up the control file after datafile creation, but the datafile itself is not backed up. If the datafile record is in the control file, then RESTORE creates the datafile in the original location or in a user-specified location (for example, with SET NEWNAME). The RECOVER command can then apply the necessary logs to the datafile.
The control file does not have the datafile record, that is, the user did not back up the control file after datafile creation. During recovery, the database will detect the missing datafile and report it to RMAN, which will create a new datafile and continue recovery by applying the remaining logs. If the datafile was created in a parent incarnation, it will be created during restore or recover as appropriate.
In this example, the following sequence of events occurs:
You make a whole database backup of your ARCHIVELOG mode database.
You create a tablespace history containing a single datafile called /mydb/history01.dbf.
You populate the newly created datafile with data.
You archive all the active online redo logs.
A user accidentally deletes the datafile history01.dbf from the operating system before you have a chance to back it up.
In this case, the current control file knows about the datafile. To restore and recover the datafile, start RMAN, connect to the target database, and then enter the following commands at the RMAN prompt:# take the tablespace with the missing datafile offline
SQL "ALTER TABLESPACE history OFFLINE IMMEDIATE";
# restore the tablespace even though you have no backup
RESTORE TABLESPACE history;
# recover tablespace
RECOVER TABLESPACE hisotry;
# bring the recovered tablespace back online
SQL "ALTER TABLESPACE history ONLINE";
Recovering a Database in NOARCHIVELOG Mode: Example
You can recover a database running in NOARCHIVELOG mode with incremental backups. Note that the incremental backups must be consistent, like all backups of a database run in NOARCHIVELOG mode, so you cannot make backups of the database when it is open.
Assume the following scenario:
You run database trgt in NOARCHIVELOG mode.
You use a recovery catalog.
You shut down the database consistently and make a level 0 backup of database trgt to tape on Sunday afternoon.
You shut down the database consistently and make a level 1 differential incremental backup to tape at 3:00 a.m. on Wednesday and Friday.
The database has a media failure on Saturday, destroying half of the datafiles as well as the online redo logs.
In this case, you must perform an incomplete media recovery until Friday, since that is the date of the most recent incremental backup. RMAN uses the level 0 Sunday backup as well as the Wednesday and Friday level 1 backups.
Because the online redo logs are lost, you must specify the NOREDO option in the RECOVER command. You must also specify NOREDO if the online logs are available but the redo cannot be applied to the incrementals. If you do not specify NOREDO, then RMAN searches for redo logs after applying the Friday incremental backup, and issues an error message when it does not find them. If the correct online logs for the restored backup had been available, then you could have run RECOVER DATABASE without specifying NOREDO. The changes in the online logs would have been applied.
After connecting to trgt and the catalog database, recover the database with the following command:
STARTUP FORCE MOUNT;
RESTORE CONTROLFILE; # restore control file from consistent backup
ALTER DATABASE MOUNT;
RESTORE DATABASE; # restore datafiles from consistent backup
RECOVER DATABASE NOREDO; # specify NOREDO because online redo logs are lost
ALTER DATABASE OPEN RESETLOGS;
The recovered database reflects only changes up through the time of the Friday incremental backup. Because there are no archived redo logs, there is no way to recover changes made after the incremental backup.
Assume the following scenario:
You run database trgt in NOARCHIVELOG mode.
You use a recovery catalog.
You shut down the database consistently and make a level 0 backup of database trgt to tape on Sunday afternoon.
You shut down the database consistently and make a level 1 differential incremental backup to tape at 3:00 a.m. on Wednesday and Friday.
The database has a media failure on Saturday, destroying half of the datafiles as well as the online redo logs.
In this case, you must perform an incomplete media recovery until Friday, since that is the date of the most recent incremental backup. RMAN uses the level 0 Sunday backup as well as the Wednesday and Friday level 1 backups.
Because the online redo logs are lost, you must specify the NOREDO option in the RECOVER command. You must also specify NOREDO if the online logs are available but the redo cannot be applied to the incrementals. If you do not specify NOREDO, then RMAN searches for redo logs after applying the Friday incremental backup, and issues an error message when it does not find them. If the correct online logs for the restored backup had been available, then you could have run RECOVER DATABASE without specifying NOREDO. The changes in the online logs would have been applied.
After connecting to trgt and the catalog database, recover the database with the following command:
STARTUP FORCE MOUNT;
RESTORE CONTROLFILE; # restore control file from consistent backup
ALTER DATABASE MOUNT;
RESTORE DATABASE; # restore datafiles from consistent backup
RECOVER DATABASE NOREDO; # specify NOREDO because online redo logs are lost
ALTER DATABASE OPEN RESETLOGS;
The recovered database reflects only changes up through the time of the Friday incremental backup. Because there are no archived redo logs, there is no way to recover changes made after the incremental backup.
Restoring When Multiple Databases in the Catalog Share the Same Name: Example
As explained in the description for SET DBID in Oracle Database Recovery Manager Reference, you must run the SET DBID command to restore the control file when the target database is not mounted and multiple databases registered in the recovery catalog share the same name. In this case, do the following steps in order:
Start RMAN and connect to the target database.
Run the STARTUP FORCE NOMOUNT command.
Run the SET DBID command to distinguish this connected target database from other target databases that have the same name.
Run the RESTORE CONTROLFILE command. After restoring the control file, you can mount the database to restore the rest of the database.
This procedure avoids the RMAN-20005 message when you attempt to restore the control file. This message occurs because more than one target database has the same name, so RMAN requires the unique DBID to distinguishes the databases from one another.
Obtaining the DBID of a Database That You Need to Restore
If you have saved the RMAN output log files, then refer to these logs to determine the database identifier. RMAN automatically provides the DBID whenever you connect to the database:% rman TARGET /
Recovery Manager: Release 10.1.0.2.0 - Production
connected to target database: RMAN (DBID=1231209694)
The output from RMAN jobs is also stored persistently in V$RMAN_STATUS and RC_RMAN_STATUS.
The DBID is also stored in the RC_DATABASE and RC_DATABASE_INCARNATION recovery catalog views.
Because the names of the databases that are registered in the recovery catalog are presumed nonunique in this scenario, you must use some other unique piece of information to determine the correct DBID. If you know the filename of a datafile or online redo log associated with the database you wish to restore, and this filename is unique across all databases registered in the recovery catalog, then substitute this fully specified filename for filename_of_log_or_df in the following queries.
Determine the DBID by performing one of the following queries:
SELECT DISTINCT DB_ID
FROM DB, DBINC, DFATT
WHERE DB.DB_KEY = DBINC.DB_KEY
AND DBINC.DBINC_KEY = DFATT.DBINC_KEY
AND DFATT.FNAME = 'filename_of_log_or_df';
SELECT DISTINCT DB_ID
FROM DB, DBINC, ORL
WHERE DB.DB_KEY = DBINC.DB_KEY
AND DBINC.DBINC_KEY = ORL.DBINC_KEY
AND ORL.FNAME = 'filename_of_log_or_df';
Restoring a Backup Control File By Using the DBID
To set the DBID, connect RMAN to the target database and run the following SET command, where target_dbid is the value you obtained from the previous step:
SET DBID = target_dbid;
To restore the control file to its default location and then mount it, run:
RESTORE CONTROLFILE;
ALTER DATABASE MOUNT;
To restore and recover the database, run:
RESTORE DATABASE;
RECOVER DATABASE
# optionally, delete logs restored for recovery and limit disk space used
DELETE ARCHIVELOG MAXSIZE 2M;
Start RMAN and connect to the target database.
Run the STARTUP FORCE NOMOUNT command.
Run the SET DBID command to distinguish this connected target database from other target databases that have the same name.
Run the RESTORE CONTROLFILE command. After restoring the control file, you can mount the database to restore the rest of the database.
This procedure avoids the RMAN-20005 message when you attempt to restore the control file. This message occurs because more than one target database has the same name, so RMAN requires the unique DBID to distinguishes the databases from one another.
Obtaining the DBID of a Database That You Need to Restore
If you have saved the RMAN output log files, then refer to these logs to determine the database identifier. RMAN automatically provides the DBID whenever you connect to the database:% rman TARGET /
Recovery Manager: Release 10.1.0.2.0 - Production
connected to target database: RMAN (DBID=1231209694)
The output from RMAN jobs is also stored persistently in V$RMAN_STATUS and RC_RMAN_STATUS.
The DBID is also stored in the RC_DATABASE and RC_DATABASE_INCARNATION recovery catalog views.
Because the names of the databases that are registered in the recovery catalog are presumed nonunique in this scenario, you must use some other unique piece of information to determine the correct DBID. If you know the filename of a datafile or online redo log associated with the database you wish to restore, and this filename is unique across all databases registered in the recovery catalog, then substitute this fully specified filename for filename_of_log_or_df in the following queries.
Determine the DBID by performing one of the following queries:
SELECT DISTINCT DB_ID
FROM DB, DBINC, DFATT
WHERE DB.DB_KEY = DBINC.DB_KEY
AND DBINC.DBINC_KEY = DFATT.DBINC_KEY
AND DFATT.FNAME = 'filename_of_log_or_df';
SELECT DISTINCT DB_ID
FROM DB, DBINC, ORL
WHERE DB.DB_KEY = DBINC.DB_KEY
AND DBINC.DBINC_KEY = ORL.DBINC_KEY
AND ORL.FNAME = 'filename_of_log_or_df';
Restoring a Backup Control File By Using the DBID
To set the DBID, connect RMAN to the target database and run the following SET command, where target_dbid is the value you obtained from the previous step:
SET DBID = target_dbid;
To restore the control file to its default location and then mount it, run:
RESTORE CONTROLFILE;
ALTER DATABASE MOUNT;
To restore and recover the database, run:
RESTORE DATABASE;
RECOVER DATABASE
# optionally, delete logs restored for recovery and limit disk space used
DELETE ARCHIVELOG MAXSIZE 2M;
Restoring Datafile Copies to a New Host: Example
To move the database to a new host by means of datafile copies, you must transfer the copies manually to the new machine. This example assumes that you are using a recovery catalog.
After connecting to the target database and recovery catalog, run a LIST command to see a listing of datafile copies and their associated primary keys, as in the following example:
LIST COPY;
Copy the datafile copies to the new host with an operating system utility. For example, in UNIX: % cp -r /tmp/*dbf /net/new_host/oracle/oradata/trgt
Start RMAN and then uncatalog the datafile copies on the old host. For example, enter: CHANGE COPY OF DATAFILE 1,2,3,4,5,6,7,8 UNCATALOG;
Catalog the datafile copies, using their new filenames or CATALOG START WITH (if you know all the files are in directories with a common prefix easily addressed with a CATALOG START WITH). For example, run:
CATALOG START WITH '?/oradata/trgt/';
Or this example specifies files individually:
CATALOG DATAFILECOPY
'?/oradata/trgt/system01.dbf', '?/oradata/trgt/undotbs01.dbf',
'?/oradata/trgt/cwmlite01.dbf', '?/oradata/trgt/drsys01.dbf',
'?/oradata/trgt/example01.dbf', '?/oradata/trgt/indx01.dbf',
'?/oradata/trgt/tools01.dbf', '?/oradata/trgt/users01.dbf';
Perform the restore and recovery operation described in "Performing Disaster Recovery".
After connecting to the target database and recovery catalog, run a LIST command to see a listing of datafile copies and their associated primary keys, as in the following example:
LIST COPY;
Copy the datafile copies to the new host with an operating system utility. For example, in UNIX: % cp -r /tmp/*dbf /net/new_host/oracle/oradata/trgt
Start RMAN and then uncatalog the datafile copies on the old host. For example, enter: CHANGE COPY OF DATAFILE 1,2,3,4,5,6,7,8 UNCATALOG;
Catalog the datafile copies, using their new filenames or CATALOG START WITH (if you know all the files are in directories with a common prefix easily addressed with a CATALOG START WITH). For example, run:
CATALOG START WITH '?/oradata/trgt/';
Or this example specifies files individually:
CATALOG DATAFILECOPY
'?/oradata/trgt/system01.dbf', '?/oradata/trgt/undotbs01.dbf',
'?/oradata/trgt/cwmlite01.dbf', '?/oradata/trgt/drsys01.dbf',
'?/oradata/trgt/example01.dbf', '?/oradata/trgt/indx01.dbf',
'?/oradata/trgt/tools01.dbf', '?/oradata/trgt/users01.dbf';
Perform the restore and recovery operation described in "Performing Disaster Recovery".
Recovering Blocks Listed in V$DATABASE_BLOCK_CORRUPTION
The V$DATABASE_BLOCK_CORRUPTION view indicates which blocks in a datafile were marked corrupt since the most recent BACKUP or BACKUP VALIDATE command was run. After a corrupt block is repaired, the row identifying this block is deleted from the view.
You can check for logical corruption in the database by running the BACKUP (with or without VALIDATE option) with the CHECK LOGICAL command. If RMAN finds corrupt blocks, then it populates V$DATABASE_BLOCK_CORRUPTION. The backup will stop if the number of corrupt blocks exceeds MAXCORRUPT. A historical record of block corruptions in RMAN backups is kept in V$BACKUP_CORRUPTION and V$COPY_CORRUPTION.
In this scenario, you identify the blocks that require recovery by querying V$DATABASE_BLOCK_CORRUPTION, and then instruct RMAN to recover all blocks listed in this view by means of the CORRUPTION LIST keyword.
To recover datablocks while limiting the type of backup:
Query V$DATABASE_BLOCK_CORRUPTION to determine whether corrupt blocks exist in the most recent backups of the datafiles: SQL> SELECT * FROM V$DATABASE_BLOCK_CORRUPTION;
Assuming that you have preallocated automatic channels, recover all blocks marked corrupt in V$DATABASE_BLOCK_CORRUPTION by running the BLOCKRECOVER CORRUPTION LIST command. For example, this command restores blocks from backups created more than 10 days ago: BLOCKRECOVER CORRUPTION LIST
RESTORE UNTIL TIME 'SYSDATE-10';
You can check for logical corruption in the database by running the BACKUP (with or without VALIDATE option) with the CHECK LOGICAL command. If RMAN finds corrupt blocks, then it populates V$DATABASE_BLOCK_CORRUPTION. The backup will stop if the number of corrupt blocks exceeds MAXCORRUPT. A historical record of block corruptions in RMAN backups is kept in V$BACKUP_CORRUPTION and V$COPY_CORRUPTION.
In this scenario, you identify the blocks that require recovery by querying V$DATABASE_BLOCK_CORRUPTION, and then instruct RMAN to recover all blocks listed in this view by means of the CORRUPTION LIST keyword.
To recover datablocks while limiting the type of backup:
Query V$DATABASE_BLOCK_CORRUPTION to determine whether corrupt blocks exist in the most recent backups of the datafiles: SQL> SELECT * FROM V$DATABASE_BLOCK_CORRUPTION;
Assuming that you have preallocated automatic channels, recover all blocks marked corrupt in V$DATABASE_BLOCK_CORRUPTION by running the BLOCKRECOVER CORRUPTION LIST command. For example, this command restores blocks from backups created more than 10 days ago: BLOCKRECOVER CORRUPTION LIST
RESTORE UNTIL TIME 'SYSDATE-10';
Performing Disaster Recovery
If you are in a disaster recovery scenario, then presumably you have lost the target database, the recovery catalog database, all control files, all online redo logs, and all parameter files.
To perform a disaster recovery, the minimum required set of backups is backups of some datafiles, some archived redo logs generated after the time of the backup, and at least one autobackup of the control file.
See Also:
"Control File and Server Parameter File Autobackups"
The basic procedure for disaster recovery is found in "Performing Recovery with a Backup Control File", with an additional first step of restoring an autobackup of the server parameter file as described in Oracle Database Backup and Recovery Basics. After the instance is started, you can restore an autobackup of the control file, mount it, then restore and recover the datafiles. Because you are restoring to a new host, you should review the considerations described in "Restoring the Database to a New Host".
The following scenario restores and recovers the database to the most recently available archived log, which in this example is log 1124 in thread 1. It assumes that:
You are restoring the database to a new host with the same directory structure.
You have one tape drive containing backups of all the datafiles and archived redo logs through log 1124, as well as autobackups of the control file and server parameter file.
You do not use a recovery catalog.
In this scenario, perform the following steps:
If possible, restore all relevant network files such as tnsnames.ora and listener.ora by means of operating system utilities.
Start RMAN and connect to the target database. If you do not have the Oracle Net files, then connect through operating system authentication.
Specify the DBID for the target database with the SET DBID command, as described in "Performing Recovery with a Backup Control File and No Recovery Catalog".
Run the STARTUP NOMOUNT command. RMAN attempts to start the instance with a dummy server parameter file.
Allocate a channel to the media manager and then run the RESTORE SPFILE FROM AUTOBACKUP command.
Run STARTUP FORCE NOMOUNT mode so that the instance is restarted with the restored server parameter file.
Allocate a channel to the media manager and then restore a control file autobackup (refer to"Performing Recovery with a Backup Control File and No Recovery Catalog").
Mount the restored control file.
Catalog any backups not recorded in the repository with the CATALOG command (refer to"Removing Recovery Catalog Records with Status DELETED").
Restore the datafiles to their original locations. If volume names have changed, then run SET NEWNAME commands before the restore and perform a switch after the restore to update the control file with the new locations for the datafiles (refer to"Performing Disaster Recovery").
Recover the datafiles. RMAN stops recovery when it reaches the log sequence number specified.
Open the database in RESETLOGS mode. Only complete this last step if you are certain that no other archived logs can be applied. # Start RMAN and connect to the target database
% rman TARGET SYS/oracle@trgt
# Set the DBID for the target database
RMAN> SET DBID 676549873;
RMAN> STARTUP FORCE NOMOUNT; # rman starts instance with dummy parameter file
RUN
{
ALLOCATE CHANNEL t1 DEVICE TYPE sbt;
RESTORE SPFILE FROM AUTOBACKUP;
}
# Restart instance with restored server parameter file
RMAN> STARTUP FORCE NOMOUNT;
RMAN> RUN
{
# Manually allocate a channel to the media manager
ALLOCATE CHANNEL t1 DEVICE TYPE sbt;
# Restore autobackup of the control file. This example assumes that you have
# accepted the default format for the autobackup name.
RESTORE CONTROLFILE FROM AUTOBACKUP;
# The set until command is used in case the database
# structure has changed in the most recent backups, and you wish to
# recover to that point-in-time. In this way RMAN restores the database
# to the same structure that the database had at the specified time.
ALTER DATABASE MOUNT;
SET UNTIL SEQUENCE 1124 THREAD 1;
RESTORE DATABASE;
RECOVER DATABASE;
}
RMAN> ALTER DATABASE OPEN RESETLOGS; # Reset the online logs after recovery
completes
The following example of the RUN command shows the same scenario except with new filenames for the restored datafiles:RMAN> RUN
{
# If you need to restore the files to new locations, tell Recovery Manager
# to do this using SET NEWNAME commands:
SET NEWNAME FOR DATAFILE 1 TO '/dev/vgd_1_0/rlvt5_500M_1';
SET NEWNAME FOR DATAFILE 2 TO '/dev/vgd_1_0/rlvt5_500M_2';
SET NEWNAME FOR DATAFILE 3 TO '/dev/vgd_1_0/rlvt5_500M_3';
ALLOCATE CHANNEL t1 DEVICE TYPE sbt;
RESTORE CONTROLFILE FROM AUTOBACKUP;
ALTER DATABASE MOUNT;
SET UNTIL SEQUENCE 124 THREAD 1;
RESTORE DATABASE;
SWITCH DATAFILE ALL; # Update control file with new location of datafiles.
RECOVER DATABASE;
}
RMAN> ALTER DATABASE OPEN RESETLOGS;
To perform a disaster recovery, the minimum required set of backups is backups of some datafiles, some archived redo logs generated after the time of the backup, and at least one autobackup of the control file.
See Also:
"Control File and Server Parameter File Autobackups"
The basic procedure for disaster recovery is found in "Performing Recovery with a Backup Control File", with an additional first step of restoring an autobackup of the server parameter file as described in Oracle Database Backup and Recovery Basics. After the instance is started, you can restore an autobackup of the control file, mount it, then restore and recover the datafiles. Because you are restoring to a new host, you should review the considerations described in "Restoring the Database to a New Host".
The following scenario restores and recovers the database to the most recently available archived log, which in this example is log 1124 in thread 1. It assumes that:
You are restoring the database to a new host with the same directory structure.
You have one tape drive containing backups of all the datafiles and archived redo logs through log 1124, as well as autobackups of the control file and server parameter file.
You do not use a recovery catalog.
In this scenario, perform the following steps:
If possible, restore all relevant network files such as tnsnames.ora and listener.ora by means of operating system utilities.
Start RMAN and connect to the target database. If you do not have the Oracle Net files, then connect through operating system authentication.
Specify the DBID for the target database with the SET DBID command, as described in "Performing Recovery with a Backup Control File and No Recovery Catalog".
Run the STARTUP NOMOUNT command. RMAN attempts to start the instance with a dummy server parameter file.
Allocate a channel to the media manager and then run the RESTORE SPFILE FROM AUTOBACKUP command.
Run STARTUP FORCE NOMOUNT mode so that the instance is restarted with the restored server parameter file.
Allocate a channel to the media manager and then restore a control file autobackup (refer to"Performing Recovery with a Backup Control File and No Recovery Catalog").
Mount the restored control file.
Catalog any backups not recorded in the repository with the CATALOG command (refer to"Removing Recovery Catalog Records with Status DELETED").
Restore the datafiles to their original locations. If volume names have changed, then run SET NEWNAME commands before the restore and perform a switch after the restore to update the control file with the new locations for the datafiles (refer to"Performing Disaster Recovery").
Recover the datafiles. RMAN stops recovery when it reaches the log sequence number specified.
Open the database in RESETLOGS mode. Only complete this last step if you are certain that no other archived logs can be applied. # Start RMAN and connect to the target database
% rman TARGET SYS/oracle@trgt
# Set the DBID for the target database
RMAN> SET DBID 676549873;
RMAN> STARTUP FORCE NOMOUNT; # rman starts instance with dummy parameter file
RUN
{
ALLOCATE CHANNEL t1 DEVICE TYPE sbt;
RESTORE SPFILE FROM AUTOBACKUP;
}
# Restart instance with restored server parameter file
RMAN> STARTUP FORCE NOMOUNT;
RMAN> RUN
{
# Manually allocate a channel to the media manager
ALLOCATE CHANNEL t1 DEVICE TYPE sbt;
# Restore autobackup of the control file. This example assumes that you have
# accepted the default format for the autobackup name.
RESTORE CONTROLFILE FROM AUTOBACKUP;
# The set until command is used in case the database
# structure has changed in the most recent backups, and you wish to
# recover to that point-in-time. In this way RMAN restores the database
# to the same structure that the database had at the specified time.
ALTER DATABASE MOUNT;
SET UNTIL SEQUENCE 1124 THREAD 1;
RESTORE DATABASE;
RECOVER DATABASE;
}
RMAN> ALTER DATABASE OPEN RESETLOGS; # Reset the online logs after recovery
completes
The following example of the RUN command shows the same scenario except with new filenames for the restored datafiles:RMAN> RUN
{
# If you need to restore the files to new locations, tell Recovery Manager
# to do this using SET NEWNAME commands:
SET NEWNAME FOR DATAFILE 1 TO '/dev/vgd_1_0/rlvt5_500M_1';
SET NEWNAME FOR DATAFILE 2 TO '/dev/vgd_1_0/rlvt5_500M_2';
SET NEWNAME FOR DATAFILE 3 TO '/dev/vgd_1_0/rlvt5_500M_3';
ALLOCATE CHANNEL t1 DEVICE TYPE sbt;
RESTORE CONTROLFILE FROM AUTOBACKUP;
ALTER DATABASE MOUNT;
SET UNTIL SEQUENCE 124 THREAD 1;
RESTORE DATABASE;
SWITCH DATAFILE ALL; # Update control file with new location of datafiles.
RECOVER DATABASE;
}
RMAN> ALTER DATABASE OPEN RESETLOGS;
Testing the Restore of a Database to a New Host: Scenario
The DUPLICATE command is the preferred method of copying the target database. DUPLICATE creates a new DBID for the copied database, allowing it to be registered in the same recovery catalog as the original target database. However, you may wish to perform a test run of your disaster recovery scenarios that uses exactly the same steps that you would use in a genuine emergency. If so, then you should use the RESTORE and RECOVER commands rather than DUPLICATE.
This scenario assumes the following:
Two networked machines, hosta and hostb, are running Sun Solaris
A media management subsystem is accessible by both machines
The directory structure of hostb is different from hosta, so that trgta is located in /net/hosta/dev3/oracle/dbs, but you want to restore the database to /net/hostb/oracle/oradata/test
A target database named trgta is on hosta and uses a recovery catalog catdb
Database trgta uses a server parameter file (not a client-side initialization parameter file)
You want to test the restore and recovery of trgta on hostb, while keeping database trgta up and running on hosta
The ORACLE_SID for the trgta database is trgta and will not change for the restored database
You have recoverable backups on tape of all datafiles
You have backups of the archived logs required to recover the datafiles
You have control file and server parameter file autobackups on tape
You have a record of the DBID for trgta
To test the restore of the database to a new host:
Make backups of the target database available to hostb. To test disaster recovery, you need to have a recoverable backup of the target database. When preparing your disaster recovery strategy, ensure that the backups of the datafiles, control files, and server parameter file are restorable on hostb. Hence, you must configure the media management software so that hostb is a media manager client and can read the backup sets created on hosta. Consult the media management vendor for support on this issue.
Configure the ORACLE_SID on hostb. This case study assumes that you want to authenticate yourself through the operating system, which is much faster than configuring Oracle Net and creating a password file. However, you must be connected to hostb either locally or through telnet.
While connected to hostb with administrator privileges, edit the /etc/group file so that you are included:dba:*:614:
Run the setenv command on hostb to set the ORACLE_SID. In this example, you set the SID to the same value that you used on hosta:% setenv ORACLE_SID trgta
Start RMAN and connect to the target instance without connecting to the recovery catalog.% rman TARGET / NOCATALOG
Start the instance without mounting it. To start the instance, you first need to set the DBID. The DBID is recorded in several places, including:
V$DATABASE in the target and RC_DATABASE in the catalog
The RMAN output (command-line and V$RMAN_STATUS)
The filename of the control file autobackups
Run SET DBID to set the DBID, then run STARTUP NOMOUNT:SET DBID 1340752057;
STARTUP NOMOUNT
RMAN will fail to find the server parameter file, which has not yet been restored, but will start the instance with a "dummy" file. Sample output follows:startup failed: ORA-01078: failure in processing system parameters
LRM-00109: could not open parameter file
'/net/hostb/oracle/dbs/inittrgta.ora'
trying to start the Oracle instance without parameter files ...
Oracle instance started
Restore and edit the server parameter file. Because you enabled the control file autobackup feature when making your backups, the server parameter file is included in the backup sets. Hence, you can allocate a channel to the media manager and restore the server parameter file to a new location as a client-side initialization parameter file. Then you can edit the client-side file and restart the instance with the edited client-side file. For example: RUN
{
ALLOCATE CHANNEL c1 DEVICE TYPE sbt PARMS='...';
RESTORE SPFILE TO PFILE '?/oradata/test/inittrgta.ora' FROM AUTOBACKUP;
SHUTDOWN ABORT;
}
Change any location-specific parameters, for example, those ending in _DEST and _PATH, to reflect the new directory structure. For example, edit the following parameters: - IFILE
- *_DUMP_DEST
- LOG_ARCHIVE_DEST*
- CONTROL_FILES
Restart the instance, specifying the client-side initialization parameter file that you restored:STARTUP FORCE NOMOUNT PFILE='?/oradata/test/inittrgta.ora';
Restore the control file from an autobackup and then mount the database. Because you edited the init.ora in the preceding step, RMAN restores the control file to whatever location you specified in the CONTROL_FILES initialization parameter. For example: RUN
{
ALLOCATE CHANNEL c1 DEVICE TYPE sbt PARMS='...';
RESTORE CONTROLFILE FROM AUTOBACKUP;
ALTER DATABASE MOUNT;
}
Query the database filenames recorded in the control file on the new host (hostb). Because the control file is from the trgta database, the recorded filenames use the original hosta filenames. You can query V$ views to obtain this information. Start a new SQL*Plus session and connect to the newly created instance on hostb: % sqlplus '/ AS SYSDBA'
Run the following query in SQL*Plus:SQL> COLUMN NAME FORMAT a60
SQL> SPOOL LOG 'db_filenames.out'
SQL> SELECT FILE# AS "File/Grp#", NAME FROM V$DATAFILE
UNION
SELECT GROUP#,MEMBER FROM V$LOGFILE;
SQL> SPOOL OFF
SQL EXIT
Restore and recover the database. At this point you are ready to write the RMAN recovery script. The script should do the following:
Run SET NEWNAME for each datafile so it is renamed to its new hostb path name
Run SQL commands to rename the online redo logs to their new hostb path names
Perform a SET UNTIL to limit media recovery to the end of the archived redo logs, as described in "Determining the SCN for Incomplete Recovery After Restore"
Run SWITCH so that the control file recognizes the new path names as the official new names of the datafiles
Restore and recover the database
The following is an example of an RMAN script to perform these steps, which is contained in text file reco_test.rman:RUN
{
# allocate a channel to the tape device
ALLOCATE CHANNEL c1 DEVICE TYPE sbt PARMS='...';
# rename the datafiles and online redo logs
SET NEWNAME FOR DATAFILE 1 TO '?/oradata/test/system01.dbf';
SET NEWNAME FOR DATAFILE 2 TO '?/oradata/test/undotbs01.dbf';
SET NEWNAME FOR DATAFILE 3 TO '?/oradata/test/cwmlite01.dbf';
SET NEWNAME FOR DATAFILE 4 TO '?/oradata/test/drsys01.dbf';
SET NEWNAME FOR DATAFILE 5 TO '?/oradata/test/example01.dbf';
SET NEWNAME FOR DATAFILE 6 TO '?/oradata/test/indx01.dbf';
SET NEWNAME FOR DATAFILE 7 TO '?/oradata/test/tools01.dbf';
SET NEWNAME FOR DATAFILE 8 TO '?/oradata/test/users01.dbf';
SQL "ALTER DATABASE RENAME FILE ''/dev3/oracle/dbs/redo01.log''
TO ''?/oradata/test/redo01.log'' ";
SQL "ALTER DATABASE RENAME FILE ''/dev3/oracle/dbs/redo02.log''
TO ''?/oradata/test/redo02.log'' ";
# Do a SET UNTIL to prevent recovery of the online logs
SET UNTIL SCN 123456;
# restore the database and switch the datafile names
RESTORE DATABASE;
SWITCH DATAFILE ALL;
# recover the database
RECOVER DATABASE;
}
EXIT
Caution:
It is imperative that you not be connected with the recovery catalog when you run this script, so that you do not incorporate extraneous repository data about backups into the recovery catalog.
For example, connect and execute as follows:% rman TARGET / NOCATALOG
RMAN> @reco_test.rman
RMAN will apply as many of the archived redo logs as it can and leave the database in a state in which is can be opened.
Open the database. From the RMAN prompt, open the database with the RESETLOGS options: RMAN> ALTER DATABASE OPEN RESETLOGS;
Remove the test files from the operating system. If the test is successful, then shut down the instance and exit the RMAN session: RMAN> SHUTDOWN ABORT
RMAN> EXIT
Remove all test files. You can do this with an operating system utility or in RMAN. For example, in Unix you could perform the procedure this way:% rm $ORACLE_HOME/oradata/test/*
You can also use RMAN for a procedure that works ok all platforms. For example:RMAN> STARTUP FORCE NOMOUNT PFILE='?/oradata/test/inittrgta.ora';
RMAN> DROP DATABASE;
Because you did not perform the restore and recovery when connected to the recovery catalog, the recovery catalog contains no records for any of the restored files or the procedures performed during the test. Likewise, the control file of the trgta database is completely unaffected by the test.
This scenario assumes the following:
Two networked machines, hosta and hostb, are running Sun Solaris
A media management subsystem is accessible by both machines
The directory structure of hostb is different from hosta, so that trgta is located in /net/hosta/dev3/oracle/dbs, but you want to restore the database to /net/hostb/oracle/oradata/test
A target database named trgta is on hosta and uses a recovery catalog catdb
Database trgta uses a server parameter file (not a client-side initialization parameter file)
You want to test the restore and recovery of trgta on hostb, while keeping database trgta up and running on hosta
The ORACLE_SID for the trgta database is trgta and will not change for the restored database
You have recoverable backups on tape of all datafiles
You have backups of the archived logs required to recover the datafiles
You have control file and server parameter file autobackups on tape
You have a record of the DBID for trgta
To test the restore of the database to a new host:
Make backups of the target database available to hostb. To test disaster recovery, you need to have a recoverable backup of the target database. When preparing your disaster recovery strategy, ensure that the backups of the datafiles, control files, and server parameter file are restorable on hostb. Hence, you must configure the media management software so that hostb is a media manager client and can read the backup sets created on hosta. Consult the media management vendor for support on this issue.
Configure the ORACLE_SID on hostb. This case study assumes that you want to authenticate yourself through the operating system, which is much faster than configuring Oracle Net and creating a password file. However, you must be connected to hostb either locally or through telnet.
While connected to hostb with administrator privileges, edit the /etc/group file so that you are included:dba:*:614:
Run the setenv command on hostb to set the ORACLE_SID. In this example, you set the SID to the same value that you used on hosta:% setenv ORACLE_SID trgta
Start RMAN and connect to the target instance without connecting to the recovery catalog.% rman TARGET / NOCATALOG
Start the instance without mounting it. To start the instance, you first need to set the DBID. The DBID is recorded in several places, including:
V$DATABASE in the target and RC_DATABASE in the catalog
The RMAN output (command-line and V$RMAN_STATUS)
The filename of the control file autobackups
Run SET DBID to set the DBID, then run STARTUP NOMOUNT:SET DBID 1340752057;
STARTUP NOMOUNT
RMAN will fail to find the server parameter file, which has not yet been restored, but will start the instance with a "dummy" file. Sample output follows:startup failed: ORA-01078: failure in processing system parameters
LRM-00109: could not open parameter file
'/net/hostb/oracle/dbs/inittrgta.ora'
trying to start the Oracle instance without parameter files ...
Oracle instance started
Restore and edit the server parameter file. Because you enabled the control file autobackup feature when making your backups, the server parameter file is included in the backup sets. Hence, you can allocate a channel to the media manager and restore the server parameter file to a new location as a client-side initialization parameter file. Then you can edit the client-side file and restart the instance with the edited client-side file. For example: RUN
{
ALLOCATE CHANNEL c1 DEVICE TYPE sbt PARMS='...';
RESTORE SPFILE TO PFILE '?/oradata/test/inittrgta.ora' FROM AUTOBACKUP;
SHUTDOWN ABORT;
}
Change any location-specific parameters, for example, those ending in _DEST and _PATH, to reflect the new directory structure. For example, edit the following parameters: - IFILE
- *_DUMP_DEST
- LOG_ARCHIVE_DEST*
- CONTROL_FILES
Restart the instance, specifying the client-side initialization parameter file that you restored:STARTUP FORCE NOMOUNT PFILE='?/oradata/test/inittrgta.ora';
Restore the control file from an autobackup and then mount the database. Because you edited the init.ora in the preceding step, RMAN restores the control file to whatever location you specified in the CONTROL_FILES initialization parameter. For example: RUN
{
ALLOCATE CHANNEL c1 DEVICE TYPE sbt PARMS='...';
RESTORE CONTROLFILE FROM AUTOBACKUP;
ALTER DATABASE MOUNT;
}
Query the database filenames recorded in the control file on the new host (hostb). Because the control file is from the trgta database, the recorded filenames use the original hosta filenames. You can query V$ views to obtain this information. Start a new SQL*Plus session and connect to the newly created instance on hostb: % sqlplus '/ AS SYSDBA'
Run the following query in SQL*Plus:SQL> COLUMN NAME FORMAT a60
SQL> SPOOL LOG 'db_filenames.out'
SQL> SELECT FILE# AS "File/Grp#", NAME FROM V$DATAFILE
UNION
SELECT GROUP#,MEMBER FROM V$LOGFILE;
SQL> SPOOL OFF
SQL EXIT
Restore and recover the database. At this point you are ready to write the RMAN recovery script. The script should do the following:
Run SET NEWNAME for each datafile so it is renamed to its new hostb path name
Run SQL commands to rename the online redo logs to their new hostb path names
Perform a SET UNTIL to limit media recovery to the end of the archived redo logs, as described in "Determining the SCN for Incomplete Recovery After Restore"
Run SWITCH so that the control file recognizes the new path names as the official new names of the datafiles
Restore and recover the database
The following is an example of an RMAN script to perform these steps, which is contained in text file reco_test.rman:RUN
{
# allocate a channel to the tape device
ALLOCATE CHANNEL c1 DEVICE TYPE sbt PARMS='...';
# rename the datafiles and online redo logs
SET NEWNAME FOR DATAFILE 1 TO '?/oradata/test/system01.dbf';
SET NEWNAME FOR DATAFILE 2 TO '?/oradata/test/undotbs01.dbf';
SET NEWNAME FOR DATAFILE 3 TO '?/oradata/test/cwmlite01.dbf';
SET NEWNAME FOR DATAFILE 4 TO '?/oradata/test/drsys01.dbf';
SET NEWNAME FOR DATAFILE 5 TO '?/oradata/test/example01.dbf';
SET NEWNAME FOR DATAFILE 6 TO '?/oradata/test/indx01.dbf';
SET NEWNAME FOR DATAFILE 7 TO '?/oradata/test/tools01.dbf';
SET NEWNAME FOR DATAFILE 8 TO '?/oradata/test/users01.dbf';
SQL "ALTER DATABASE RENAME FILE ''/dev3/oracle/dbs/redo01.log''
TO ''?/oradata/test/redo01.log'' ";
SQL "ALTER DATABASE RENAME FILE ''/dev3/oracle/dbs/redo02.log''
TO ''?/oradata/test/redo02.log'' ";
# Do a SET UNTIL to prevent recovery of the online logs
SET UNTIL SCN 123456;
# restore the database and switch the datafile names
RESTORE DATABASE;
SWITCH DATAFILE ALL;
# recover the database
RECOVER DATABASE;
}
EXIT
Caution:
It is imperative that you not be connected with the recovery catalog when you run this script, so that you do not incorporate extraneous repository data about backups into the recovery catalog.
For example, connect and execute as follows:% rman TARGET / NOCATALOG
RMAN> @reco_test.rman
RMAN will apply as many of the archived redo logs as it can and leave the database in a state in which is can be opened.
Open the database. From the RMAN prompt, open the database with the RESETLOGS options: RMAN> ALTER DATABASE OPEN RESETLOGS;
Remove the test files from the operating system. If the test is successful, then shut down the instance and exit the RMAN session: RMAN> SHUTDOWN ABORT
RMAN> EXIT
Remove all test files. You can do this with an operating system utility or in RMAN. For example, in Unix you could perform the procedure this way:% rm $ORACLE_HOME/oradata/test/*
You can also use RMAN for a procedure that works ok all platforms. For example:RMAN> STARTUP FORCE NOMOUNT PFILE='?/oradata/test/inittrgta.ora';
RMAN> DROP DATABASE;
Because you did not perform the restore and recovery when connected to the recovery catalog, the recovery catalog contains no records for any of the restored files or the procedures performed during the test. Likewise, the control file of the trgta database is completely unaffected by the test.
Determining the SCN for Incomplete Recovery After Restore
Because the restored database will not have the online redo logs of the production database, perform incomplete recovery up to the lowest SCN of the most recently archived log in each thread and then open with the RESETLOGS option. Obtain the SCN for recovery termination by finding the lowest SCN among the most recent archived logs for each thread.
Start SQL*Plus and use the following query to determine the necessary SCN:SQL> SELECT MIN(maxnc) FROM
(SELECT MAX(a.NEXT_CHANGE#) maxnc
FROM V$ARCHIVED_LOG a, V$THREAD t
WHERE a.THREAD# = t.THREAD#
AND a.ARCHIVED='YES'
AND t.ENABLED='DISABLED'
GROUP BY a.THREAD#);
Start SQL*Plus and use the following query to determine the necessary SCN:SQL> SELECT MIN(maxnc) FROM
(SELECT MAX(a.NEXT_CHANGE#) maxnc
FROM V$ARCHIVED_LOG a, V$THREAD t
WHERE a.THREAD# = t.THREAD#
AND a.ARCHIVED='YES'
AND t.ENABLED='DISABLED'
GROUP BY a.THREAD#);
Point-in-Time Recovery to a Previous Incarnation
RMAN can seamlessly restore and recover backups from previous incarnations to the current incarnation. To perform point-in-time recovery to a target time prior to the most recent RESETLOGS, however, you must run the RESET DATABASE command to reset the database to the incarnation current at the desired target time.
Assume the following situation:
You run RMAN with a recovery catalog.
You made a backup of target database trgt on October 2, 2002.
You performed incomplete recovery on this database and opened it with the RESETLOGS option on October 10, 2002. A new database incarnation was created.
On October 25, you discover that you need crucial data that was dropped from the database at 8:00 a.m. on October 8, 2002. You decide to reset trgt to the prior incarnation, restore the October 2 backup, and recover to 7:55 a.m. on October 8.
Note:
It is not possible to restore one datafile of a previous incarnation while the current database is in a different incarnation--you must restore the whole database.
To recover the database by means of a backup from the old incarnation:
Obtain the primary key of the prior incarnation with a LIST command: # obtain primary key of old incarnation
LIST INCARNATION OF DATABASE trgt;
List of Database Incarnations
DB Key Inc Key DB Name DB ID STATUS Reset SCN Reset Time
------- ------- ------- ------ ------- ---------- ----------
1 2 TRGT 1224038686 PARENT 1 02-OCT-02
1 582 TRGT 1224038686 CURRENT 59727 10-OCT-02
Make sure the database is started but not mounted: SHUTDOWN FORCE NOMOUNT
Reset the incarnation to the primary key that you just obtained: # reset database to old incarnation
RESET DATABASE TO INCARNATION 2;
Recover the database, performing the following actions in the RUN command:
Set the end time for recovery to the time just before the loss of the data.
If automatic channels are not configured, then manually allocate one or more channels.
Restore the control file and mount it.
Restore and recover the database.
For example, run the following commands:RUN
{
# set time to just before data was lost.
SET UNTIL TIME 'Oct 8 2002 07:55:00';
RESTORE CONTROLFILE; # FROM AUTOBACKUP not needed in catalog mode
ALTER DATABASE MOUNT; # mount database after restoring control file
RESTORE DATABASE;
RECOVER DATABASE;
}
If recovery is successful, then reset the online redo logs: # this command automatically resets the database so that this incarnation is
# the new incarnation
ALTER DATABASE OPEN RESETLOGS;
Assume the following situation:
You run RMAN with a recovery catalog.
You made a backup of target database trgt on October 2, 2002.
You performed incomplete recovery on this database and opened it with the RESETLOGS option on October 10, 2002. A new database incarnation was created.
On October 25, you discover that you need crucial data that was dropped from the database at 8:00 a.m. on October 8, 2002. You decide to reset trgt to the prior incarnation, restore the October 2 backup, and recover to 7:55 a.m. on October 8.
Note:
It is not possible to restore one datafile of a previous incarnation while the current database is in a different incarnation--you must restore the whole database.
To recover the database by means of a backup from the old incarnation:
Obtain the primary key of the prior incarnation with a LIST command: # obtain primary key of old incarnation
LIST INCARNATION OF DATABASE trgt;
List of Database Incarnations
DB Key Inc Key DB Name DB ID STATUS Reset SCN Reset Time
------- ------- ------- ------ ------- ---------- ----------
1 2 TRGT 1224038686 PARENT 1 02-OCT-02
1 582 TRGT 1224038686 CURRENT 59727 10-OCT-02
Make sure the database is started but not mounted: SHUTDOWN FORCE NOMOUNT
Reset the incarnation to the primary key that you just obtained: # reset database to old incarnation
RESET DATABASE TO INCARNATION 2;
Recover the database, performing the following actions in the RUN command:
Set the end time for recovery to the time just before the loss of the data.
If automatic channels are not configured, then manually allocate one or more channels.
Restore the control file and mount it.
Restore and recover the database.
For example, run the following commands:RUN
{
# set time to just before data was lost.
SET UNTIL TIME 'Oct 8 2002 07:55:00';
RESTORE CONTROLFILE; # FROM AUTOBACKUP not needed in catalog mode
ALTER DATABASE MOUNT; # mount database after restoring control file
RESTORE DATABASE;
RECOVER DATABASE;
}
If recovery is successful, then reset the online redo logs: # this command automatically resets the database so that this incarnation is
# the new incarnation
ALTER DATABASE OPEN RESETLOGS;
Performing Point-in-Time Recovery with a Current Control File
The database must be closed to perform database point-in-time recovery. If you are recovering to a time, then you should set the time format environment variables before invoking RMAN. The following are sample Globalization Support settings:NLS_LANG = american_america.us7ascii
NLS_DATE_FORMAT="Mon DD YYYY HH24:MI:SS"
To recover the database until a specified time, SCN, or log sequence number:
After connecting to the target database and, optionally, the recovery catalog database, ensure that the database is mounted. If the database is open, shut it down and then mount it: SHUTDOWN IMMEDIATE;
STARTUP MOUNT;
Determine the time, SCN, or log sequence that should end recovery. For example, if you discover that a user accidentally dropped a tablespace at 9:02 a.m., then you can recover to 9 a.m.--just before the drop occurred. You will lose all changes to the database made after that time.
You can also examine the alert.log to find the SCN of an event and recover to a prior SCN. Alternatively, you can determine the log sequence number that contains the recovery termination SCN, and then recover through that log. For example, query V$LOG_HISTORY to view the logs that you have archived.RECID STAMP THREAD# SEQUENCE# FIRST_CHAN FIRST_TIM NEXT_CHANG
---------- ---------- ---------- ---------- ---------- --------- ----------
1 344890611 1 1 20037 24-SEP-02 20043
2 344890615 1 2 20043 24-SEP-02 20045
3 344890618 1 3 20045 24-SEP-02 20046
Perform the following operations within a RUN command:
Set the end recovery time, SCN, or log sequence. If specifying a time, then use the date format specified in the NLS_LANG and NLS_DATE_FORMAT environment variables.
If automatic channels are not configured, then manually allocate one or more channels.
Restore and recover the database.
The following example performs an incomplete recovery until November 15 at 9 a.m.RUN
{
SET UNTIL TIME 'Nov 15 2002 09:00:00';
# SET UNTIL SCN 1000; # alternatively, specify SCN
# SET UNTIL SEQUENCE 9923; # alternatively, specify log sequence number
RESTORE DATABASE;
RECOVER DATABASE;
}
If recovery was successful, then open the database and reset the online logs: ALTER DATABASE OPEN RESETLOGS;
NLS_DATE_FORMAT="Mon DD YYYY HH24:MI:SS"
To recover the database until a specified time, SCN, or log sequence number:
After connecting to the target database and, optionally, the recovery catalog database, ensure that the database is mounted. If the database is open, shut it down and then mount it: SHUTDOWN IMMEDIATE;
STARTUP MOUNT;
Determine the time, SCN, or log sequence that should end recovery. For example, if you discover that a user accidentally dropped a tablespace at 9:02 a.m., then you can recover to 9 a.m.--just before the drop occurred. You will lose all changes to the database made after that time.
You can also examine the alert.log to find the SCN of an event and recover to a prior SCN. Alternatively, you can determine the log sequence number that contains the recovery termination SCN, and then recover through that log. For example, query V$LOG_HISTORY to view the logs that you have archived.RECID STAMP THREAD# SEQUENCE# FIRST_CHAN FIRST_TIM NEXT_CHANG
---------- ---------- ---------- ---------- ---------- --------- ----------
1 344890611 1 1 20037 24-SEP-02 20043
2 344890615 1 2 20043 24-SEP-02 20045
3 344890618 1 3 20045 24-SEP-02 20046
Perform the following operations within a RUN command:
Set the end recovery time, SCN, or log sequence. If specifying a time, then use the date format specified in the NLS_LANG and NLS_DATE_FORMAT environment variables.
If automatic channels are not configured, then manually allocate one or more channels.
Restore and recover the database.
The following example performs an incomplete recovery until November 15 at 9 a.m.RUN
{
SET UNTIL TIME 'Nov 15 2002 09:00:00';
# SET UNTIL SCN 1000; # alternatively, specify SCN
# SET UNTIL SEQUENCE 9923; # alternatively, specify log sequence number
RESTORE DATABASE;
RECOVER DATABASE;
}
If recovery was successful, then open the database and reset the online logs: ALTER DATABASE OPEN RESETLOGS;
Performing Database Point-In-Time Recovery
RMAN can perform recovery of the whole database to a specified past time, SCN, or log sequence number. This type of recovery is sometimes called incomplete recovery because it does not completely use all of the available redo. Incomplete recovery of the whole database is also called database point-in-time recovery (DBPITR).
If you have enabled the collectionof flashback logs, you may be able to use Oracle Flashback Database instead of performing DBPITR. Flashback Database is generally faster and simpler to use, when it is available, because it does not require restoring a past backup. Depending upon your situation, you may also find one of the other Oracle flashback features can meet your data recovery need. See "Oracle Flashback Technology: Overview" for more details about these alternatives before deciding whether to use DBPITR.
DBPITR requires restoring your database from an older backup, then performing media recovery until your specified target time, SCN or log sequence number. Note that because you need your archived redo log files to perform this process, you cannot perform database point-in-time recovery if you have been running your database in NOARCHIVELOG mode.
After database point-in-time recovery, you must open the database with the RESETLOGS option. Using the RESETLOGS option archives the current online redo logs, resets the log sequence to 1, and then gives the online redo logs a new time stamp and SCN. In this way, the database eliminates the possibility of corrupting datafiles by the application of obsolete archived redo logs.
You have to recover all datafiles: you cannot recover some datafiles before the RESETLOGS and others after the RESETLOGS.
The OPEN RESETLOGS operation will fail if a datafile is off-line, unless the datafile went offline normally or is read-only. You can bring files in read-only or offline normal tablespaces online after the RESETLOGS because they do not need any redo.
When performing DBPITR, consider using the SET UNTIL command to set the target time at the beginning of the process, rather than specifying the UNTIL clause on the RESTORE and RECOVER commands individually. SET UNTIL sets the desired time for any subsequent RESTORE, SWITCH, and RECOVER commands in the same RUN job.
Note that if you specify a SET UNTIL command after a RESTORE and before a RECOVER, you may not be able to recover the database to the point in time required because the restored files may already have time stamps more recent than the set time. Hence, it is recommended that you specify the SET UNTIL command before the RESTORE command.
If you have enabled the collectionof flashback logs, you may be able to use Oracle Flashback Database instead of performing DBPITR. Flashback Database is generally faster and simpler to use, when it is available, because it does not require restoring a past backup. Depending upon your situation, you may also find one of the other Oracle flashback features can meet your data recovery need. See "Oracle Flashback Technology: Overview" for more details about these alternatives before deciding whether to use DBPITR.
DBPITR requires restoring your database from an older backup, then performing media recovery until your specified target time, SCN or log sequence number. Note that because you need your archived redo log files to perform this process, you cannot perform database point-in-time recovery if you have been running your database in NOARCHIVELOG mode.
After database point-in-time recovery, you must open the database with the RESETLOGS option. Using the RESETLOGS option archives the current online redo logs, resets the log sequence to 1, and then gives the online redo logs a new time stamp and SCN. In this way, the database eliminates the possibility of corrupting datafiles by the application of obsolete archived redo logs.
You have to recover all datafiles: you cannot recover some datafiles before the RESETLOGS and others after the RESETLOGS.
The OPEN RESETLOGS operation will fail if a datafile is off-line, unless the datafile went offline normally or is read-only. You can bring files in read-only or offline normal tablespaces online after the RESETLOGS because they do not need any redo.
When performing DBPITR, consider using the SET UNTIL command to set the target time at the beginning of the process, rather than specifying the UNTIL clause on the RESTORE and RECOVER commands individually. SET UNTIL sets the desired time for any subsequent RESTORE, SWITCH, and RECOVER commands in the same RUN job.
Note that if you specify a SET UNTIL command after a RESTORE and before a RECOVER, you may not be able to recover the database to the point in time required because the restored files may already have time stamps more recent than the set time. Hence, it is recommended that you specify the SET UNTIL command before the RESTORE command.
To recover the database with a backup control file and a recovery catalog:
After connecting to the target database and recovery catalog database, start the instance without mounting the database: STARTUP NOMOUNT
Restore the backup control file, then restore and recover the database. Do the following:
Run the RESTORE CONTROLFILE command to restore the control file to all default locations specified in the CONTROL_FILES initialization parameter. To restore a control file from an older backup, you can run SET UNTIL or specify the UNTIL clause on the RESTORE CONTROLFILE command.
Mount the database using the restored control file.
Optionally, run a SET UNTIL command for incomplete recovery. Note that you can also specify the UNTIL clause on the RESTORE and RECOVER commands.
Restore and recover the database as described in "Performing Basic RMAN Media Recovery".
This example restores the control file to its default location, then restores and completely recovers the database:RESTORE CONTROLFILE;
ALTER DATABASE MOUNT;
RESTORE DATABASE;
RECOVER DATABASE;
If recovery was successful, then open the database and reset the online logs: ALTER DATABASE OPEN RESETLOGS;
If the database uses locally-managed temporary tablespaces, then add new tempfiles to these tablespaces. For example: SQL "ALTER TABLESPACE temp ADD TEMPFILE ''?/oradata/trgt/temp01.dbf'' REUSE";
It is recommended that you immediately back up the database, preferably with the database mounted (to avoid possible data loss in an open database). Because the database is a new incarnation, the backups made prior to the RESETLOGS are not easily usable. For example, run the following to back up the database: SHUTDOWN IMMEDIATE
STARTUP MOUNT
BACKUP DATABASE;
ALTER DATABASE OPEN;
Restore the backup control file, then restore and recover the database. Do the following:
Run the RESTORE CONTROLFILE command to restore the control file to all default locations specified in the CONTROL_FILES initialization parameter. To restore a control file from an older backup, you can run SET UNTIL or specify the UNTIL clause on the RESTORE CONTROLFILE command.
Mount the database using the restored control file.
Optionally, run a SET UNTIL command for incomplete recovery. Note that you can also specify the UNTIL clause on the RESTORE and RECOVER commands.
Restore and recover the database as described in "Performing Basic RMAN Media Recovery".
This example restores the control file to its default location, then restores and completely recovers the database:RESTORE CONTROLFILE;
ALTER DATABASE MOUNT;
RESTORE DATABASE;
RECOVER DATABASE;
If recovery was successful, then open the database and reset the online logs: ALTER DATABASE OPEN RESETLOGS;
If the database uses locally-managed temporary tablespaces, then add new tempfiles to these tablespaces. For example: SQL "ALTER TABLESPACE temp ADD TEMPFILE ''?/oradata/trgt/temp01.dbf'' REUSE";
It is recommended that you immediately back up the database, preferably with the database mounted (to avoid possible data loss in an open database). Because the database is a new incarnation, the backups made prior to the RESETLOGS are not easily usable. For example, run the following to back up the database: SHUTDOWN IMMEDIATE
STARTUP MOUNT
BACKUP DATABASE;
ALTER DATABASE OPEN;
To recover the database with an autobackup of the control file without a recovery catalog:
Start RMAN and connect to the target database. For example, run: CONNECT TARGET /
Start the target instance without mounting the database. For example: STARTUP NOMOUNT;
Set the database identifier for the target database with SET DBID. RMAN displays the DBID whenever you connect to the target. You can also obtain it by running LIST, querying the catalog, or looking at the filenames of control file autobackup. (refer to "Restoring When Multiple Databases in the Catalog Share the Same Name: Example"). For example, run: SET DBID 676549873;
Restore the autobackup control file, then perform recovery. Do the following:
Optionally, specify the most recent backup time stamp that RMAN can use when searching for a control file autobackup to restore.
If a nondefault format was used to create the control file, then specify a nondefault format for the restore of the control file.
If the channel that created the control file autobackup was device type sbt, then you must allocate one or more sbt channels. Because no repository is available, you cannot use automatic channels. If the autobackup was created on a disk channel, however, then you do not need to manually allocate a channel.
Restore the autobackup of the control file, optionally setting the maximum number of days backward that RMAN can search (up to 366) and the initial sequence number that it should use in its search for the first day.
Mount the database. Note that because the repository is now available, any automatic channels that you configured are also available.
If the online logs are inaccessible, then restore and recover the database as described in "Performing Incomplete Restore and Recovery". You must terminate recovery by setting the UNTIL clause to a time, log sequence, or SCN before the online redo logs. If the online logs are usable, then restore and recover the database as described in "Performing Complete Restore and Recovery".
In this example, the online redo logs have been lost. This example limits the restore of the control file autobackup, then performs recovery of the database to log sequence 13243, which is the most recent archived log:RUN
{
# Optionally, set upper limit for eligible time stamps of control file backups
# SET UNTIL TIME '09/10/2000 13:45:00';
# Specify a nondefault autobackup format only if required
# SET CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO '?/oradata/%F.bck';
ALLOCATE CHANNEL c1 DEVICE TYPE sbt; # manually allocate one or more channels
RESTORE CONTROLFILE FROM AUTOBACKUP
MAXSEQ 100 # start at sequence 100 and count down
MAXDAYS 180; # start at UNTIL TIME and search back 6 months
ALTER DATABASE MOUNT DATABASE;
}
# uses automatic channels configured in restored control file
RESTORE DATABASE UNTIL SEQUENCE 13243;
RECOVER DATABASE UNTIL SEQUENCE 13243; # recovers to most recent archived log
If recovery was successful, then open the database and reset the online logs: ALTER DATABASE OPEN RESETLOGS;
It is recommended that you immediately back up the database, preferably with the database mounted (to avoid possible data loss in an open database). Because the database is a new incarnation, the backups made before the RESETLOGS are not easily usable. For example, enter: SHUTDOWN IMMEDIATE
STARTUP MOUNT
BACKUP DATABASE;
ALTER DATABASE OPEN;
Start the target instance without mounting the database. For example: STARTUP NOMOUNT;
Set the database identifier for the target database with SET DBID. RMAN displays the DBID whenever you connect to the target. You can also obtain it by running LIST, querying the catalog, or looking at the filenames of control file autobackup. (refer to "Restoring When Multiple Databases in the Catalog Share the Same Name: Example"). For example, run: SET DBID 676549873;
Restore the autobackup control file, then perform recovery. Do the following:
Optionally, specify the most recent backup time stamp that RMAN can use when searching for a control file autobackup to restore.
If a nondefault format was used to create the control file, then specify a nondefault format for the restore of the control file.
If the channel that created the control file autobackup was device type sbt, then you must allocate one or more sbt channels. Because no repository is available, you cannot use automatic channels. If the autobackup was created on a disk channel, however, then you do not need to manually allocate a channel.
Restore the autobackup of the control file, optionally setting the maximum number of days backward that RMAN can search (up to 366) and the initial sequence number that it should use in its search for the first day.
Mount the database. Note that because the repository is now available, any automatic channels that you configured are also available.
If the online logs are inaccessible, then restore and recover the database as described in "Performing Incomplete Restore and Recovery". You must terminate recovery by setting the UNTIL clause to a time, log sequence, or SCN before the online redo logs. If the online logs are usable, then restore and recover the database as described in "Performing Complete Restore and Recovery".
In this example, the online redo logs have been lost. This example limits the restore of the control file autobackup, then performs recovery of the database to log sequence 13243, which is the most recent archived log:RUN
{
# Optionally, set upper limit for eligible time stamps of control file backups
# SET UNTIL TIME '09/10/2000 13:45:00';
# Specify a nondefault autobackup format only if required
# SET CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO '?/oradata/%F.bck';
ALLOCATE CHANNEL c1 DEVICE TYPE sbt; # manually allocate one or more channels
RESTORE CONTROLFILE FROM AUTOBACKUP
MAXSEQ 100 # start at sequence 100 and count down
MAXDAYS 180; # start at UNTIL TIME and search back 6 months
ALTER DATABASE MOUNT DATABASE;
}
# uses automatic channels configured in restored control file
RESTORE DATABASE UNTIL SEQUENCE 13243;
RECOVER DATABASE UNTIL SEQUENCE 13243; # recovers to most recent archived log
If recovery was successful, then open the database and reset the online logs: ALTER DATABASE OPEN RESETLOGS;
It is recommended that you immediately back up the database, preferably with the database mounted (to avoid possible data loss in an open database). Because the database is a new incarnation, the backups made before the RESETLOGS are not easily usable. For example, enter: SHUTDOWN IMMEDIATE
STARTUP MOUNT
BACKUP DATABASE;
ALTER DATABASE OPEN;
Oracle Database Block corruption
Oracle Database Block corruption“Block corruption is rare but it does happen. As databases get larger and larger – the probability of it happening at some point nears 100%.”--Mr. Tom Kyte Oracle ExpertBlock corruption is while the data is being written to the data blocks, if the write to the block fails abruptly, I mean that there is a partial write in the block, may be because of power disruption or I/O problem, leaving no time for header to be updated, or row data to be populated, oracle leaves the block corrupt.In case of block corruption you can normally use the database unless you try to read that particular block, against which it shoots up the block corruption error.Generally block corruption occurs if write fails on the block, when the transaction is being committedORA-01578:ORACLE data block corrupted (file # string, block # string)Whenever we encounter above error message mean we have BLOCK CORRUPTION.NOTE: We can find detail information about block corruption in alert.log fileTwo types of block corruption can happens- Physical corruption (media corrupt)- Logical corruption (soft corrupt)Physical corruption can be caused by defected memory boards, controllers or broken sectors on a hard disk;Logical corruption can among other reasons be caused by an attempt to recover through a NOLOGGING action.Difference between logical and physical corruption Logical corruption is header - footer - that is one of the checks, yes (it is looking for fractured blocks and when it hits one, it'll re-read it, that is why there is no need for "alter tablespace begin backup" with rman) Physical corruption is "we cannot read the block from disk, something is physically preventing us from doing so”.How to detect block corruption?1. DBVERIFY utilityDBVERIFY is an external command-line utility that performs a physical data structure integrity check. It can be used on offline or online databases, as well on backup files. You use DBVERIFY primarily when you need to ensure that a backup database (or datafile) is valid before it is restored.http://dbataj.blogspot.com/2007/04/offline-database-verification-utility.html2. Block checking parametersThere are two initialization parameters for dealing with block corruption:- DB_BOCK_CHECKSUM (calculates a checksum for each block before it is written to disk, every time)causes 1-2% performance overhead- DB_BLOCK_CHECKING (serverprocess checks block for internal consistency after every DML)causes 1-10% performance overheadNote: In10g db_block_checksum value TYPICAL is implying TRUE and db_block_checking value FULL implying TRUE.DB_BLOCK_CHECKING Initialization Parameterhttp://download.oracle.com/docs/cd/B19306_01/server.102/b14231/repair.htm#sthref31763. ANALYZE TABLE tablename VALIDATE STRUCTURE CASCADE SQL statementValidate the structure of an index or index partition, table or table partition, index-organized table, cluster, or object reference (REF).ANALYZE: Reporting Corruptionhttp://download.oracle.com/docs/cd/B19306_01/server.102/b14231/repair.htm#sthref31734. RMAN BACKUP command with THE VALIDATE optionYou can use the VALIDATE option of the BACKUP command to verify that database files exist and are in the correct locations, and have no physical or logical corruptions that would prevent RMAN from creating backups of them. When performing a BACKUP... VALIDATE, RMAN reads the files to be backed up in their entirety, as it would during a real backup. It does not, however, actually produce any backup sets or image copies.Detection of Logical Block CorruptionBesides testing for media corruption, the database can also test data and index blocks for logical corruption, such as corruption of a row piece or index entry. If RMAN finds logical corruption, then it logs the block in the alert.log. If CHECK LOGICAL was used, the block is also logged in the server session trace file. By default, error checking for logical corruption is disabled.For BACKUP commands the MAXCORRUPT parameter sets the total number of physical and logical corruptions permitted in a file. If the sum of physical and logical corruptions for a file is less than its MAXCORRUPT setting, the RMAN command completes successfully. If MAXCORRUPT is exceeded, the command terminates and RMAN does not read the rest of the file. V$DATABASE_BLOCK_CORRUPTION is populated with corrupt block ranges if the command succeeds. Otherwise, you must set MAXCORRUPT higher and re-run the backup to find out the corrupt block ranges.RMAN found any block corruption in database then following Data Dictionary view populated.V$COPY_CORRUPTIONV$BACKUP_CORRUPTIONV$DATABASE_BLOCK_CORRUPTIONUsing RMAN to Validate Database Fileshttp://download.oracle.com/docs/cd/B19306_01/backup.102/b14192/bkup005.htm#i10066735. EXPORT/IMPORT command line utilityFull database EXPORT/IMPORT show=y is another method.. about to export SCOTT's tables via Conventional Path .... . exporting table BONUSEXP-00056: ORACLE error 1578 encounteredORA-01578: ORACLE data block corrupted (file # 4, block # 43)ORA-01110: data file 4: 'C:\ORA10GHOME\ORADATA\ORCL10G\USERS01.DBF'6. DBMS_REPAIR packagedbms_repair is a utility that can detect and repair block corruption within Oracle. It is provided by Oracle as part of the standard database installation.http://www.oracleutilities.com/Packages/dbms_repair.htmlHow to Repair & Fix block corruption?We can recover everything but we have valid database backup.Whenever we found block corruption then first need to find out which type of block corruption occurred because block corruption recovery depends on block corruption type.Like Corrupted block related to TABLE segment, INDEX segment, TABLE PARTITION segment, INDEX PARTITION segment, ROLLBACK segment, LOB segment.Through below query we can find out corrupted block typeselect segment_type,owner'.'segment_namefrom dba_extentswhere file_id = [&file_id] and [&block] between block_id and block_id+blocks -1; Below is example with RMAN BLOCK MEDIA RECOVERY. SQL> conn scott/tigerConnected.SQL> select * from test;select * from test *ERROR at line 1:ORA-01578: ORACLE data block corrupted (file # 5, block # 11)ORA-01110: data file 5: 'C:\INDEXDATA01.DBF'First check which type of block corruption happened through above mentioned query. RMAN> blockrecover datafile 5 block 11; Starting recover at 29-APR-08using channel ORA_DISK_1 starting media recoverymedia recovery complete, elapsed time: 00:00:00 Finished recover at 29-APR-08If you are not using rman then applying below procedure- if it is index then drop and recreate index- if it is table and you have backup of that table then restore backup on another database and exp/imp the table.
Same Reference:http://sysdba.wordpress.com/2006/04/05/how-to-check-for-and-repair-block-corruption-with-rman-in-oracle-9i-and-oracle-10g/NOTE: Find more information “Handling Oracle Block Corruptions in Oracle7/8/8i/9i/10g” Metalink Note: 28814.1How to corrupt database block for practice purpose?On Unix:Use dd command$man ddOn Windows:Use Editor and open datafile write some junk character at middle of file and save it.
Same Reference:http://sysdba.wordpress.com/2006/04/05/how-to-check-for-and-repair-block-corruption-with-rman-in-oracle-9i-and-oracle-10g/NOTE: Find more information “Handling Oracle Block Corruptions in Oracle7/8/8i/9i/10g” Metalink Note: 28814.1How to corrupt database block for practice purpose?On Unix:Use dd command$man ddOn Windows:Use Editor and open datafile write some junk character at middle of file and save it.
Subscribe to:
Posts (Atom)