Backup and Recovery

ODBA (06/08)

Flying Pigs Oracle

The Backup Process - Choosing a Method

Chose the most appropriate backup method for your organisation. The options are: simple complex cold or offline backup, WITHOUT archiving hot or online backup, WITH archiving

As an extra precaution, a utility such as Export may be used to backup the database objects, but it does NOT take a copy of the parameter file, control file or the redo log file.

Simple Backup Without Archiving

An operating system backup without archiving has the following implications: the redo log files are used in a cycle, they are not archived backups may only be taken when the database is shutdown for recovery, the entire set of database files must be restored A full database backup off-line involves the following steps: compile a list of all relevant files which need to be backed up shut down the Oracle instance back up the files using an operating system backup utility restart the Oracle instance The backup utility chosen must be such that the files can be restored in exactly the same format as when they were created.

ODBA (06/08)

Flying Pigs Oracle

What to Backup?
The physical files to be backed up include, the parameter file, the password file, the control files, the data files and the redo log files.

The Parameter File

The parameter file, or PFILE, in ORACLE\admin\orcl\pfile, is the file used to define the database instance. It should be backed up each time the file is edited and changed. If the parameter file is missing or corrupt the database instance will not start.

The SPFILE File

If in use, the SPFILE in ORACLE\DB_1\database or dbs is used to define the database instance. It should be backed up each time the file is changed. If the SPFILE file is missing or corrupt the database instance will not start.

The Password File

The password file, pwdorcl.ora in ORACLE\DB_1\database, is the file used to define the passwords for the internal user and any other users who may start and stop the server. If the password file is missing or corrupt the database instance will not start.

ODBA (06/08)

Flying Pigs Oracle

The Control Files

The control file, in ORACLE\oradata\orcl, is a binary file which contains the path names of all the data files and the log files in the database. Control files may be 'mirrored' by having more than one file name in the parameter file. This means that if one file is corrupt it may be recreated as a copy of one of the other files. The file showdb.sql may be run in order to find out what control files exist in the database. If one or more of the control files is missing or corrupt the database instance will not start. If ALL control files are corrupt, the database may need to be recreated.

The Data Files

The file showdb.sql may be run in order to find out what data files exist in the database. If one or more of the data files is missing or corrupt the database instance will not start.

The Redo Log File

The file showdb.sql may be run in order to find out what log files exist in the database. If one or more of the redo log files is missing or corrupt the database instance will not start.

ODBA (06/08)

Flying Pigs Oracle

The Cold or Offline Backup

Having identified the files, shut down the Oracle instance and back up the files using the chosen operating system backup utility. Once the backup is complete, the Oracle instance may be restarted. Consider using a reliable, automated backup procedure which runs un-attended overnight on a nightly basis.

Advantages of Off-line Backup

This type of database backup has several advantages: conceptually simple easy to perform requires very little operator intervention very reliable

Disadvantages of Off-line Backup

However, it does have two distinct disadvantages: requires that the database be unavailable for use during the backup may result in data loss since in the event of an error, full database recovery from the last backup is required This means that this method is of no use if 24 hour availability of the database is required or any data loss is unacceptable. If 24 hour availability is required and data must on no account be lost then an Operating System Backup With Archiving is required.

ODBA (06/08)

Flying Pigs Oracle

Exercise
1. If one does not exist, create an ordinary user such as trn1 with connect and resource privileges. 2. Log in as the user and run the file createord.sql in order to create several user tables that may be backed up. 3. Compile a list of all the relevant files that need to be backed up for the instance. 4. Shut down the instance and create a new backup directory called backup1. 5. Copy the parameter file, SPFILE ( if in use ) and the password file to the backup directory. 6. Back up the control files, data files and log files to the backup directory using an operating system backup utility. Under Windows, copy the files or use a utility such as Winzip. Under UNIX, use the tar or cpio utility to copy the files. 7. Restart the instance and start an SQL*Plus session to ensure that the database has started correctly.

ODBA (06/08)

Flying Pigs Oracle

The Recovery Process

There are many types of failure which require recovery. When attempting to recover a database, note that If the ARCHIVER is NOT in use, then ALL files must be recovered from the latest offline backup

Types of Failure
There are many types of failure which may occur. Some require DBA intervention and some do not. The failure will be one of the following types: user process failure instance failure user error statement failure media failure other failure The procedure used to recover from the failure will depend on the type of failure.

ODBA (06/08)

Flying Pigs Oracle

User Process Failure

No action is required to recover from this type of failure. Common causes are that the user session was: abnormally disconnected by the user abnormally terminated terminated by the user program Such an error can be simulated by terminating a session in SQL*Plus which is connected to the database. The Oracle background process PMON detects any abnormally terminated user session. It then rolls back the transaction process and releases any resources and locks that were held by the process.

ODBA (06/08)

Flying Pigs Oracle

Instance Failure
To recover from this type of failure restart the instance with the startup command. Common causes are: a power cut occurred a hardware problem, such as CPU failure or memory corruption a software problem, such as an operating system crash a failure of one of the Oracle background processes Such an error can be simulated by terminating one of the Oracle background processes or by doing a shutdown abort. The Oracle background process SMON performs instance recovery and rolls forward any committed changes in the redo log that have not yet been written to the database. Transactions that have not been committed are rolled back and any resources and locks that were held by the process are released. Investigate the cause of the failure by finding and examining the alert log file called orclalrt.log in the directory bdump.

Exercise
1. Connect as a normal user and update the Product table to set all selling prices to 100.00. 2. Simulate an Instance Failure by terminating the Oracle background process or doing a shutdown abort. 3. Restart the Oracle service and the instance will restart and perform recovery. 4. Connect in SQL*Plus and select from the Product table to confirm that the update to selling prices has been lost because the change was not committed. 5. Examine the alert log file to see any messages related to the instance recovery.

ODBA (06/08)

Flying Pigs Oracle

User Error
Action is usually required to recover from this type of failure. Common causes are that the user: deleted all the rows in a table dropped or truncated a table committed data changes in error Such an error can be easily simulated in an SQL*Plus session. Resolution of the error involves one of the following: recover the corrupt table from an Export backup recover the whole database from a valid backup

Exercise
1. Simulate a User Error as a normal user by deleting all the rows in a table, for example the Saleline table, and committing the changes. 2. Shut down the instance. 3. Recover the table by restoring all control, data and log files from the last offline backup. 4. Restart the instance and then start an SQL*Plus session to ensure that the deleted rows have been restored.

ODBA (06/08)

10

Flying Pigs Oracle

Statement Failure
This type of failure may or may not require actions to perform recovery. Common causes are: a logical error in an application entering invalid data, for example a duplicate key in an index attempting an operation with insufficient privilege creating a table and exceeding allotted quota limits an insert or update found insufficient free space in a table space Again, such an error can be easily simulated in an SQL*Plus session. Resolution of the error involves one of the following: fix the application error modify and re-issue the SQL statement provide sufficient privileges change the quota limits for the user increase the size of the table space Oracle or the operating system will return an error code and a message. The process is automatically rolled back and control is returned to the user.

ODBA (06/08)

11

Flying Pigs Oracle

Media Failure
Action is always required to recover from this type of failure, usually caused by a physical problem when reading from or writing to a file on disc. Common causes are: a head crash on a disc drive a physical problem with the file a file was accidentally deleted Such an error can be simulated by deleting a file or files. Resolution of the error normally involves restoring the complete database from a backup.

Recovering a Control File

In most cases a corrupt or lost control file can be recovered from the duplex copy of the file.

Exercise
1. Shut down the database. 2. Simulate a Media Failure by deleting ONE of the Control files. 3. Confirm the failure by trying to restart the instance. 4. Recover JUST the missing control file using the operating system backup. 5. Attempt to restart the instance. This will fail as the control file and data files are not now synchronised. 6. In this case, the database can be recovered by re-creating the missing control file from the DUPLEX copy. 7. Attempt to restart the instance. This will succeed.

ODBA (06/08)

12

Flying Pigs Oracle

Renaming a Recovered Data File

In some cases a data file cannot be recovered to the same file name on the same disc drive as before the failure. In such a case, the data file may be restored to a new file name and then be renamed. For example, having copied the file from the latest backup, enter the following in SQL*Plus: STARTUP MOUNT; ALTER DATABASE RENAME FILE C:\ORACLE\PRODUCT\10.1.0\ORADATA\ORCL\USERS01.DBF TO D:\ORACLE\PRODUCT\DATABASE\ORCL\USERS01.DBF; ALTER DATABASE OPEN;

Exercise
1. Shut down the database. 2. Simulate another Media Failure by renaming one of the data files in Windows Explorer. 3. Start up the database. This will fail as the renamed data file is missing. The database will be left in MOUNT mode. 4. Use the ALTER statement to RENAME the old data file to the new name. 5. Confirm the recovery by making the instance available to users.

ODBA (06/08)

13

Flying Pigs Oracle

Recovering a Data File

In all cases a corrupt or lost data file must be recovered from the most recent backup of the database.

Exercise
1. Shut down the database. 2. Simulate a Media Failure by deleting the data files for the users tablespace. 3. Confirm the failure by trying to restart the instance. 4. Recover JUST the missing data file using the operating system backup. 5. Attempt to restart the instance. This will fail as the control file and data files are not now synchronised. 6. Recover from the failure by restoring all control, data and log files from the last offline backup. 7. Attempt to restart the instance. This will succeed.

Recovering the Temp Tablespace

The temp database does not contain critical data and the database will still function if the data file is lost or corrupted. If the data file is lost, it may be recreated as follows:
ALTER TABLESPACE TEMP ADD TEMPFILE 'C:\ORACLE\PRODUCT\10.1.0\ORADATA\ORCL\TEMP01.DBF' SIZE 20971520 REUSE AUTOEXTEND ON NEXT 655360 MAXSIZE 32767M;

Recovering a Log File

An online redo log file must be recovered in the same way as a data file unless the log file is duplexed. A duplex online redo log group consists of copies of online redo log files physically located on separate disks; changes made to one member of the group are made to all members. If a disk that contains an online redo log file fails, other copies are still intact and available to Oracle. System operation is not interrupted and the lost online redo log file can be recovered by adding a new member to the group.

ODBA (06/08)

14

Flying Pigs Oracle

Other Failure
Action is always required to recover from this type of failure, usually caused by a problem with the Parameter file or with resources being offline. Common causes are: Parameter file errors rollback segments offline table space offline Such an error can be simulated by editing the parameter file or by putting one or more rollback segments or table spaces offline. Resolution of the error involves correcting the parameter file or putting the offending rollback segments or table spaces online.

ODBA (06/08)

15

Flying Pigs Oracle

Control File Backup

An online or hot backup of just the control file may be taken using the Alter command: ALTER DATABASE BACKUP CONTROLFILE TO C:\oracle\backup2\control.bak;

Exercise
1. In the SQL*Plus session as user system, take on online backup of the Control file. It is vital that a copy of the control file is available in the event of a failure. As a precaution, multiple copies of the control file should be maintained by naming them in the parameter file. A trace file, which may be used to recreate the control file if a backup is not available, may be generated as follows: ALTER DATABASE BACKUP CONTROLFILE TO TRACE; The file is created in the directory udump which is pointed to by the parameter USER_DUMP_DEST. In SQL*Plus, this can be displayed as: SHOW PARAMETER user_dump_dest

Exercise
1. In the SQL*Plus session as user system, create a trace file which may be used to recreate the Control file. 2. View the trace file using an application such as Notepad.

ODBA (06/08)

16

Flying Pigs Oracle

Control File Restore

In the event of a control file failure, the text SQL script file created earlier may be used to recreate the control file if a backup is not available:

Exercise
1. Shut down the database and then delete all of the control files. 2. Now confirm the failure by trying to restart the database. 3. When the startup fails, examine the alert log file, orclalrt.log, in the directory bdump. 4. Shut the database down with the abort option. 5. Now, copy the trace file to a new file, createcontrol.sql, in your SQL directory. 6. Edit this new file and remove all the lines not required. 7. In SQL*Plus as sys, run the control script file as follows: @createcontrol 8. Now login to the database and check that it is open OK.

ODBA (06/08)

17

Flying Pigs Oracle

What is a Complex Backup?

A COMPLEX BACKUP involves backing up all or part of the database while the database is up and running. This will ensure that no data is lost and it also allows 24 hour running of the database.

What is Complex Recovery?

COMPLEX RECOVERY is the process of recovering from a combination of a full or partial backup, the online redo log file and a set of archived redo log files.

Complex Backup With Archiving

An operating system backup with archiving has the following implications: the redo log files are used in a cycle and are archived backups may be taken when the database is running point in time recovery is possible A database backup online involves the following steps: compile a list of all relevant files which need to be backed up ensure that the database is running in ARCHIVE mode inform Oracle that the backup is about to commence back up the tablespace using an operating system backup utility inform Oracle that the backup is complete

ODBA (06/08)

18

Flying Pigs Oracle

Advantages of Online Backup

This type of database backup has two distinct advantages: the database may be available for use during the backup there is no loss of data since in the event of an error, partial database recovery is available

Disadvantages of Online Backup

However, it does have several disadvantages: conceptually complex difficult to perform requires a great deal of operator intervention If 24 hour availability is required and data must on no account be lost then an Operating System Backup With Archiving is the solution.

Running in Archive Mode

In order to run in this mode the following must be true: the database must be in ARCHIVELOG mode the ARCH background process must be running resources must be available to hold the generated archived redo log files

ODBA (06/08)

19

Flying Pigs Oracle

Displaying Archive Status

The following command may be used in to check the status of the Archiver and to display the log file sequence numbers: ARCHIVE LOG LIST

Exercise
1. Start an SQL*Plus session and connect as sys as sysdba. 2. Check that the Archive status of the database is disabled. The following statement will also check the status in an using SQL: SELECT FROM log_mode v$database;

Change Archive Status

The following SQL statement is used to manually change the database log mode to Archive mode. Automatic archiving will then be enabled by default. The database must be mounted but NOT open when this statement is run: ALTER DATABASE ARCHIVELOG; Note that in ORACLE version 9i, to enable Automatic Archival the following had to be included in the Parameter file: LOG_ARCHIVE_START = TRUE It is normal practice to start the Archiver automatically, which is the default with version 10g.

ODBA (06/08)

20

Flying Pigs Oracle

Exercise
1. Perform a normal shutdown of the database. 2. Start up the database in MOUNT mode: STARTUP MOUNT 3. Alter the database to run in ARCHIVE log mode: ALTER DATABASE ARCHIVELOG; 4. Alter the database to OPEN mode: ALTER DATABASE OPEN; 5. Check the Archive status of the database: ARCHIVE LOG LIST

ODBA (06/08)

21

Flying Pigs Oracle

Log File Destination

The archive log file destination defaults to the setting of the parameter: DB_RECOVERY_FILE_DEST This parameter is set to the FLASH recovery area and can be displayed with the command: SHOW PARAMETER DB_REC Multiple archive destinations may also be set by using the parameters available:

Generated Archive Log Files

Even if there is no database activity at all from users, information is still being written into the control files and the log files. An inactive database isn't inactive. Don't assume that if the users are not doing anything, the database is not doing anything. This premise is wrong. SMON is writing to the log file as are processes such as SNPn's, intermedia, AQ and many other background processes. The redo logs will only switch as they fill but SMON will eventually fill one and perform a switch, creating an archive log file. There may be 3 or 4 archive log files per day even for an inactive database! Also note that generated archive log files should be managed and old files deleted by the DBA.

ODBA (06/08)

22

Flying Pigs Oracle

Cold or Offline Backup

At this point, before attempting any partial recovery, a full offline backup should be taken. This is because the current backup was taken BEFORE archiving was enabled. As before, the physical files to be backed up include: the parameter file, SPFILE and password files the control files, include a trace file backup the redo logs the data files Having identified the files, shut down the Oracle instance and back up the files using the chosen operating system backup utility. Once the backup is complete, the Oracle instance may be restarted.

Exercise
1. Compile a list of all the relevant files that need to be backed up for the instance. 2. Create a trace file which may be used to recreate the Control file. 3. Shut down the instance and create a new backup directory under ORACLE called backup3. 4. Copy the parameter file, SPFILE and the password file to the backup directory. 5. Back up the control files, data files and log files to the backup directory using an operating system backup utility. 6. Restart the instance.

ODBA (06/08)

23

Flying Pigs Oracle

Switching Log Files

If the Archiver is enabled, the log files will switch and be archived automatically and the sequence number will be incremented. To simulate this, the following SQL statement may be used to switch the files manually, either in SQL*Plus: ALTER SYSTEM SWITCH LOGFILE;

Exercise
1. In SQL*Plus as user system, switch the log files twice and note the change in sequence number. ALTER SYSTEM SWITCH LOGFILE; ALTER SYSTEM SWITCH LOGFILE; ARCHIVE LOG LIST 2. Use a utility such as Windows Explorer to check for the new archive files in the archive directory.

Log File Name

The archive log file name includes the following by default: %t %s %r thread number log sequence number logical incarnation of the database

Stop Automatic Archiving

To stop the Archiver for the duration of the current instance, enter the following command in SQL*Plus: ALTER SYSTEM ARCHIVE LOG STOP; To change the status of the Archiver to disabled: ALTER DATABASE NOARCHIVELOG;

ODBA (06/08)

24

Flying Pigs Oracle

Hot or Online Backup

An online backup of the control file can be taken in one of two ways. The following steps are involved in taking an online tablespace backup: identify the tablespaces (excluding temp) to be backed up identify the corresponding files to be backed up perform the backup

Begin Online Backup

There are three steps involved in performing the backup. In this example, the files in the tablespace for users are backed up. First, the following SQL statement must be used to inform Oracle that the backup is about to commence: ALTER TABLESPACE users BEGIN BACKUP; During the backup, Oracle will make no changes to the tablespace but will log all committed changes made to the redo log file. Note that If this step is omitted, recovery in the event of a failure may NOT be possible.

Backup the Data Files

Second, ALL of the files belonging to the tablespace are backed up using the chosen operating system backup utility.

End Online Backup

Finally, the following SQL statement informs Oracle that the backup is complete: ALTER TABLESPACE users END BACKUP;

ODBA (06/08)

25

Flying Pigs Oracle

Active Data Files

During the online backup, the tablespace being backed up is said to be in ACTIVE mode. A list of the status of all tablespaces can be found using the file showactive.sql, or as follows: SELECT FROM WHERE tablespace_name, file_name, b.status, f.status v$backup b, dba_data_files f file# = file_id;

Exercise
1. In the SQL*Plus session as system/oracle, identify the files used by the tablespace for users by running showdb.sql. 2. Inform Oracle that the tablespace for users is about to be backed up online: ALTER TABLESPACE users BEGIN BACKUP; 3. Now check the list of tablespaces in ACTIVE mode. 4. Backup ALL the files used by the tablespace into a new directory, backupHot. 5. Inform Oracle that the backup is complete: ALTER TABLESPACE users END BACKUP;

Full Online Backup

In some circumstances, it may be appropriate to take a full online backup of the database by using the commands: ALTER DATABASE BEGIN BACKUP; and ALTER DATABASE END BACKUP;

ODBA (06/08)

26

Flying Pigs Oracle

The Online Recovery Process

There are several types of failure which require recovery. The main ones are: control file failure media failure user error The procedure used to recover from the failure will depend on the type of failure.

Media Failure
Action is always required to recover from this type of failure, usually caused by a physical problem when reading from or writing to a file on disc. Common causes are: a head crash on a disc drive a physical problem with the file a file was accidentally deleted Such an error can be simulated by corrupting or deleting a file or files. Resolution of the error involves restoring ALL data files for the tablespaces to be recovered and running the Recover command.

ODBA (06/08)

27

Flying Pigs Oracle

This is known as tablespace or COMPLETE recovery. Note the following: The database will, by default, be recovered to the PRESENT time as defined in the current Control file. The Control file holds the sequence number of the CURRENT redo log file Each database file header holds the sequence number of the EARLIEST redo log file to be applied to the restored data file When a data file is restored from a backup, the sequence number will not coincide with the current sequence number and Oracle will DETECT that recovery is required Log files from the earliest to the current will be APPLIED as required to each data file ALWAYS restore JUST the data files for the tablespaces to be recovered, whether from the latest online or offline backup, since the other data files are OK ALWAYS use the current Control file and redo log files The file showlogs.sql can be used to examine the log file sequence number and the archive status of the redo log files. The status of the data files can be examined by running the file showfiles.sql.

ODBA (06/08)

28

Flying Pigs Oracle

The sequence of actions to complete the recovery is as follows. Shutdown the corrupt database as follows in SQL*Plus: SHUTDOWN ABORT Restore ALL data files for the tablespaces from the most recent online or offline backup, but DO NOT restore the control file or any redo log files. Startup the database in mount mode as follows in SQL*Plus: STARTUP MOUNT Recover the data files with the command: RECOVER DATABASE; When the data files are recovered the database will use the current and the archived log files to apply changes to the restored data files. The user will be prompted for the archived log files, unless the following option is set: SET AUTORECOVERY ON When COMPLETE recovery has finished, open the database for the users: ALTER DATABASE OPEN;

ODBA (06/08)

29

Flying Pigs Oracle

Exercise
1. Ensure that you do have a recent COMPLETE offline backup and an ONLINE backup of the tablespace users. 2. Start a session as a normal user. 3. Make changes to the tablespace for users by DELETing all rows in the Saleline table with an ordid greater that 104. DELETE WHERE FROM saleline ordid > 104;

Confirm the changes with a SELECT statement and COMMIT the changes. 4. In SQL*Plus, SWITCH the log files TWICE and note the change in sequence number. ALTER SYSTEM SWITCH LOGFILE; 5. Change the tablespace for users by UPDATing the selling price of all rows with a prdid starting with M in the Product table by 100.00. UPDATE SET WHERE product sell = 100 prdid LIKE M%;

Confirm the changes with a SELECT statement and then COMMIT the changes. 6. Again SWITCH the log files TWICE and note the change in sequence number. ALTER SYSTEM SWITCH LOGFILE; There are now at least 2 archived log files and these will be used during recovery. 7. Shutdown the database as normal and then simulate a Media Failure by deleting the data file used by the tablespace for users. At this point in a live situation it is advisable to take a complete backup of all the database files.

ODBA (06/08)

30

Flying Pigs Oracle

8. If an attempt is now made to start the database as normal it will fail and the database will be left in MOUNT mode. 9. Examine the error message in the relevant trace file in ORACLE/admin/bdump. 10.Restore ALL of the data files for TABLESPACE for users from the latest online backup. These files do not contain the changes made to Saleline and Product. 11.Recover from the failure and If prompted for a log file name, press return: RECOVER DATABASE; 12.Open the database to make it available to users: ALTER DATABASE OPEN; Note that at this point in a live situation it is advisable to take another complete backup of all database files before making the database available to users. 13.Check that the changes made to the Saleline and Product tables are now back in place.

ODBA (06/08)

31

Flying Pigs Oracle

User Error
Action is usually required to recover from this type of failure. Common causes are that the user: deleted all the rows in a table dropped or truncated a table committed data changes in error Such an error can be easily simulated in an SQL*Plus session.

ODBA (06/08)

32

Flying Pigs Oracle

Resolution of the error involves restoring ALL data files and running the Recover command until a certain condition is true. This is known as partial or INCOMPLETE recovery. The steps are similar to those for recovery from a Media Failure but resolution of the error involves restoring ALL data files and running the Recover command. Note the following: The database will be recovered until one of the following is true: the user cancels the recovery a particular system change number is reached a particular point in time is reached The Control file holds the sequence number of the CURRENT redo log file Each database file header holds the sequence number of the EARLIEST redo log file to be applied to the restored data file When a data file is restored from a backup, the sequence number will not coincide with the current sequence number and Oracle will DETECT that recovery is required Log files from the earliest to the current will be APPLIED as required to each data file ALWAYS restore ALL data files from the latest backup, since all the files will need recovery ALWAYS use the current Control file and redo log files

ODBA (06/08)

33

Flying Pigs Oracle

The sequence of actions to complete the recovery is as follows. Shutdown the database as follows in SQL*Plus: SHUTDOWN Restore ALL data files from the most recent backup. Startup the database in mount mode as follows in SQL*Plus: STARTUP MOUNT Recover the data files until the condition is true. For example, to recover to a particular point in time, use the command: RECOVER DATABASE UNTIL TIME YYYY-MM-DD:HH:MI:SS; When the data files are recovered the database will use the restored and the archived log files to apply changes to the restored data files. The archived log files, if needed, will be prompted for interactively. When INCOMPLETE recovery has finished, the database may NOT be opened with: ALTER DATABASE OPEN; The database MUST be opened and the log file number reset to 1 with the following command: ALTER DATABASE OPEN RESETLOGS; The Oracle instance should now be shut down and all files backed up offline using the chosen operating system backup utility. Once the backup is complete, the ORACLE instance may be restarted.

ODBA (06/08)

34

Flying Pigs Oracle

Exercise
1. Start a session as a normal user. If using SQL*Plus, enter the command: SET TIME ON 2. Make changes to the tablespace for users by UPDATing the column dateord in the Saleord table to todays date for order numbers 101 and 102. UPDATE SET WHERE saleord dateord = SYSDATE ordid IN (101,102);

Confirm the changes with a SELECT statement and COMMIT the changes. 3. SWITCH the log files TWICE and note the change in sequence number: ALTER SYSTEM SWITCH LOGFILE; 4. Make a written note of the time using the prompt or the SQL statement: SELECT TO_CHAR(sysdate, 'HH24:MI:SS') FROM dual; 5. Make changes to the tablespace for users by UPDATing the cost price of all rows in the Product table to 150.00. UPDATE SET product cost = 150;

Confirm the changes with a SELECT statement and then COMMIT the changes. 6. The User Error is simulated by a wish to KEEP the changes to the Saleord table above but UNDO the changes just made to the Product table. 7. Shutdown the database. At this point in a live situation it is advisable to take a complete backup of all database files.

ODBA (06/08)

35

Flying Pigs Oracle

8. Restore ALL OF THE DATA files but NOT the control or log files from the offline or online backup. These files do not contain the changes made to Saleord and Product. 9. In an SQL*Plus session, start the database in MOUNT mode: STARTUP MOUNT 10.Recover from the failure by using the UNTIL parameter of the system time noted AFTER the change to the Saleord table but BEFORE the changes to the Product table: RECOVER DATABASE UNTIL TIME YYYY-MM-DD:HH:MI:SS; 11.Open the database and RESET the log files. Confirm that the log file sequence number has been reset to 1: ALTER DATABASE OPEN RESETLOGS; ARCHIVE LOG LIST At this point in a live situation it is advisable to take another complete offline backup of the database. 12.Check that the changes made to the Saleord table but NOT the Product table are back in place.

ODBA (06/08)

36

Flying Pigs Oracle