Backup and Recovery

ODBA (06/08)

1

© 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)

2

© 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)

3

© Flying Pigs Oracle

If one or more of the data files is missing or corrupt the database instance will not start.sql may be run in order to find out what data files exist in the database. This means that if one file is corrupt it may be recreated as a copy of one of the other files. the database may need to be recreated. If one or more of the control files is missing or corrupt the database instance will not start. The file showdb. 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.sql may be run in order to find out what log files exist in the database. in ORACLE\oradata\orcl. The Data Files The file showdb. The Redo Log File The file showdb.sql may be run in order to find out what control files exist in the database.The Control Files The control file. ODBA (06/08) 4 © Flying Pigs Oracle . If one or more of the redo log files is missing or corrupt the database instance will not start. If ALL control files are corrupt.

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. Consider using a reliable. ODBA (06/08) 5 © Flying Pigs Oracle . If 24 hour availability is required and data must on no account be lost then an Operating System Backup With Archiving is required. 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. the Oracle instance may be restarted. shut down the Oracle instance and back up the files using the chosen operating system backup utility.The Cold or Offline Backup Having identified the files. Once the backup is complete. 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. automated backup procedure which runs un-attended overnight on a nightly basis.

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

ODBA (06/08) 7 © Flying Pigs Oracle . Some require DBA intervention and some do not.The Recovery Process There are many types of failure which require recovery. note that If the ARCHIVER is NOT in use. 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. then ALL files must be recovered from the latest offline backup Types of Failure There are many types of failure which may occur. When attempting to recover a database.

It then rolls back the transaction process and releases any resources and locks that were held by the process. ODBA (06/08) 8 © Flying Pigs Oracle .User Process Failure No action is required to recover from this type of failure. The Oracle background process PMON detects any abnormally terminated user session. 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.

Exercise 1. 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. 5. Restart the Oracle service and the instance will restart and perform recovery. 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. 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.00. Common causes are: • a power cut occurred • a hardware problem. Examine the alert log file to see any messages related to the instance recovery. Connect as a normal user and update the Product table to set all selling prices to £100. such as CPU failure or memory corruption • a software problem. ODBA (06/08) 9 © Flying Pigs Oracle .log in the directory bdump. 2. Transactions that have not been committed are rolled back and any resources and locks that were held by the process are released.Instance Failure To recover from this type of failure restart the instance with the startup command. 4. Simulate an Instance Failure by terminating the Oracle background process or doing a shutdown abort. Investigate the cause of the failure by finding and examining the alert log file called orclalrt. 3.

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. 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) 10 © Flying Pigs Oracle . Simulate a User Error as a normal user by deleting all the rows in a table. Shut down the instance. Restart the instance and then start an SQL*Plus session to ensure that the deleted rows have been restored. and committing the changes. data and log files from the last offline backup. 4. Recover the table by restoring all control.User Error Action is usually required to recover from this type of failure. for example the Saleline table. 3. 2.

such an error can be easily simulated in an SQL*Plus session. Common causes are: • a logical error in an application • entering invalid data. The process is automatically rolled back and control is returned to the user. 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. 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.Statement Failure This type of failure may or may not require actions to perform recovery. ODBA (06/08) 11 © Flying Pigs Oracle .

In this case. ODBA (06/08) 12 © Flying Pigs Oracle . Simulate a Media Failure by deleting ONE of the Control files. Attempt to restart the instance. Recover JUST the missing control file using the operating system backup. This will succeed. Recovering a Control File In most cases a corrupt or lost control file can be recovered from the duplex copy of the file. Resolution of the error normally involves restoring the complete database from a backup.Media Failure Action is always required to recover from this type of failure. the database can be recovered by re-creating the missing control file from the DUPLEX copy. usually caused by a physical problem when reading from or writing to a file on disc. 7. Confirm the failure by trying to restart the instance. 5. 2. Attempt to restart the instance. 6. Shut down the database. Exercise 1. This will fail as the control file and data files are not now synchronised. 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. 3. 4.

The database will be left in MOUNT mode. This will fail as the renamed data file is missing.1. Simulate another Media Failure by renaming one of the data files in Windows Explorer.0\ORADATA\ORCL\USERS01. 3. Start up the database. In such a case. ALTER DATABASE RENAME FILE ‘C:\ORACLE\PRODUCT\10. enter the following in SQL*Plus: STARTUP MOUNT. Shut down the database. having copied the file from the latest backup. 2. 4. the data file may be restored to a new file name and then be renamed. For example. Exercise 1.DBF. ALTER DATABASE OPEN.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. ODBA (06/08) 13 © Flying Pigs Oracle . Use the ALTER statement to RENAME the old data file to the new name. 5.DBF’ TO ‘D:\ORACLE\PRODUCT\DATABASE\ORCL\USERS01. Confirm the recovery by making the instance available to users.

data and log files from the last offline backup.0\ORADATA\ORCL\TEMP01. Confirm the failure by trying to restart the instance. Recover JUST the missing data file using the operating system backup. Shut down the database. Recover from the failure by restoring all control. Attempt to restart the instance. other copies are still intact and available to Oracle. 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. This will succeed.1. changes made to one member of the group are made to all members. 5. A duplex online redo log group consists of copies of online redo log files physically located on separate disks. 7. it may be recreated as follows: ALTER TABLESPACE TEMP ADD TEMPFILE 'C:\ORACLE\PRODUCT\10. If a disk that contains an online redo log file fails. 6. Simulate a Media Failure by deleting the data files for the users tablespace. Exercise 1. Attempt to restart the instance. This will fail as the control file and data files are not now synchronised.DBF' SIZE 20971520 REUSE AUTOEXTEND ON NEXT 655360 MAXSIZE 32767M. ODBA (06/08) 14 © 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. 4. 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. 3. 2. If the data file is lost. System operation is not interrupted and the lost online redo log file can be recovered by adding a new member to the group.

Resolution of the error involves correcting the parameter file or putting the offending rollback segments or table spaces online. 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. ODBA (06/08) 15 © 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.

It is vital that a copy of the control file is available in the event of a failure. ODBA (06/08) 16 © Flying Pigs Oracle . In SQL*Plus. may be generated as follows: ALTER DATABASE BACKUP CONTROLFILE TO TRACE.bak’. create a trace file which may be used to recreate the Control file. Exercise 1. View the trace file using an application such as Notepad. In the SQL*Plus session as user system. this can be displayed as: SHOW PARAMETER user_dump_dest Exercise 1. As a precaution. In the SQL*Plus session as user system. 2. The file is created in the directory udump which is pointed to by the parameter USER_DUMP_DEST. which may be used to recreate the control file if a backup is not available. A trace file.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. take on online backup of the Control file. multiple copies of the control file should be maintained by naming them in the parameter file.

in the directory bdump. 3. the text SQL script file created earlier may be used to recreate the control file if a backup is not available: Exercise 1. When the startup fails.Control File Restore In the event of a control file failure. 6. orclalrt. Shut down the database and then delete all of the control files. Shut the database down with the abort option. Now login to the database and check that it is open OK. 2. 5. In SQL*Plus as sys.sql. examine the alert log file. copy the trace file to a new file. run the control script file as follows: @createcontrol 8. 4.log. in your SQL directory. Edit this new file and remove all the lines not required. Now confirm the failure by trying to restart the database. 7. createcontrol. Now. ODBA (06/08) 17 © Flying Pigs Oracle .

the online redo log file and a set of archived redo log files. This will ensure that no data is lost and it also allows 24 hour running of the database. 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 .What is a Complex Backup? A COMPLEX BACKUP involves backing up all or part of the database while the database is up and running. What is Complex Recovery? COMPLEX RECOVERY is the process of recovering from a combination of a full or partial backup.

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. 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 . 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. partial database recovery is available Disadvantages of Online Backup However.

The following statement will also check the status in an using SQL: SELECT FROM log_mode v$database. Note that in ORACLE version 9i. Change Archive Status The following SQL statement is used to manually change the database log mode to Archive mode. which is the default with version 10g. The database must be mounted but NOT open when this statement is run: ALTER DATABASE ARCHIVELOG.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. Automatic archiving will then be enabled by default. 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. ODBA (06/08) 20 © Flying Pigs Oracle . Start an SQL*Plus session and connect as sys as sysdba. Check that the Archive status of the database is disabled. 2.

4. 2. Alter the database to OPEN mode: ALTER DATABASE OPEN. Alter the database to run in ARCHIVE log mode: ALTER DATABASE ARCHIVELOG. Start up the database in MOUNT mode: STARTUP MOUNT 3. Check the Archive status of the database: ARCHIVE LOG LIST ODBA (06/08) 21 © Flying Pigs Oracle .Exercise 1. Perform a normal shutdown of the database. 5.

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. Don't assume that if the users are not doing anything. intermedia. AQ and many other background processes. SMON is writing to the log file as are processes such as SNPn's. creating an archive log file. ODBA (06/08) 22 © Flying Pigs Oracle . the database is not doing anything. The redo logs will only switch as they fill but SMON will eventually fill one and perform a switch. An inactive database isn't inactive. information is still being written into the control files and the log files. This premise is wrong. 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.

Cold or Offline Backup At this point. the physical files to be backed up include: • the parameter file. shut down the Oracle instance and back up the files using the chosen operating system backup utility. Shut down the instance and create a new backup directory under ORACLE called backup3. Copy the parameter file. a full offline backup should be taken. ODBA (06/08) 23 © Flying Pigs Oracle . data files and log files to the backup directory using an operating system backup utility. Exercise 1. 5. Create a trace file which may be used to recreate the Control file. include a trace file backup • the redo logs • the data files Having identified the files. Back up the control files. As before. 4. Once the backup is complete. SPFILE and the password file to the backup directory. This is because the current backup was taken BEFORE archiving was enabled. Compile a list of all the relevant files that need to be backed up for the instance. before attempting any partial recovery. 6. 2. SPFILE and password files • the control files. the Oracle instance may be restarted. Restart the instance. 3.

ALTER SYSTEM SWITCH LOGFILE. the log files will switch and be archived automatically and the sequence number will be incremented. Use a utility such as Windows Explorer to check for the new archive files in the archive directory. switch the log files twice and note the change in sequence number. To simulate this. In SQL*Plus as user system. ODBA (06/08) 24 © Flying Pigs Oracle . ARCHIVE LOG LIST 2. the following SQL statement may be used to switch the files manually. Exercise 1. ALTER SYSTEM SWITCH LOGFILE. To change the status of the Archiver to disabled: ALTER DATABASE NOARCHIVELOG. 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.Switching Log Files If the Archiver is enabled. either in SQL*Plus: ALTER SYSTEM SWITCH LOGFILE. enter the following command in SQL*Plus: ALTER SYSTEM ARCHIVE LOG STOP.

Backup the Data Files Second. In this example. ODBA (06/08) 25 © Flying Pigs Oracle . the files in the tablespace for users are backed up. the following SQL statement must be used to inform Oracle that the backup is about to commence: ALTER TABLESPACE users BEGIN BACKUP. ALL of the files belonging to the tablespace are backed up using the chosen operating system backup utility. End Online Backup Finally. First. Note that If this step is omitted. Oracle will make no changes to the tablespace but will log all committed changes made to the redo log file.Hot or Online Backup An online backup of the control file can be taken in one of two ways. During the backup. recovery in the event of a failure may NOT be possible. the following SQL statement informs Oracle that the backup is complete: ALTER TABLESPACE users END BACKUP. 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.

Now check the list of tablespaces in ACTIVE mode. file_name. the tablespace being backed up is said to be in ACTIVE mode. 4. 3. Exercise 1.Active Data Files During the online backup. A list of the status of all tablespaces can be found using the file showactive. Inform Oracle that the backup is complete: ALTER TABLESPACE users END BACKUP. identify the files used by the tablespace for users by running showdb.status v$backup b. Inform Oracle that the tablespace for users is about to be backed up online: ALTER TABLESPACE users BEGIN BACKUP. dba_data_files f file# = file_id. b. Full Online Backup In some circumstances. f. backupHot.sql. Backup ALL the files used by the tablespace into a new directory.status. and ALTER DATABASE END BACKUP. 2. it may be appropriate to take a full online backup of the database by using the commands: ALTER DATABASE BEGIN BACKUP. ODBA (06/08) 26 © Flying Pigs Oracle . In the SQL*Plus session as system/oracle.sql. 5. or as follows: SELECT FROM WHERE tablespace_name.

The Online Recovery Process There are several types of failure which require recovery. ODBA (06/08) 27 © Flying Pigs Oracle . usually caused by a physical problem when reading from or writing to a file on disc. 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. 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. Media Failure Action is always required to recover from this type of failure. Resolution of the error involves restoring ALL data files for the tablespaces to be recovered and running the Recover command.

sql. The status of the data files can be examined by running the file showfiles.This is known as tablespace or COMPLETE recovery. by default. 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. Note the following: • The database will. • 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.sql can be used to examine the log file sequence number and the archive status of the redo log files. be recovered to the PRESENT time as defined in the current Control file. ODBA (06/08) 28 © Flying Pigs Oracle . 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.

unless the following option is set: SET AUTORECOVERY ON When COMPLETE recovery has finished.The sequence of actions to complete the recovery is as follows. The user will be prompted for the archived log files. open the database for the users: ALTER DATABASE OPEN. but DO NOT restore the control file or any redo log files. ODBA (06/08) 29 © Flying Pigs Oracle . 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. Startup the database in mount mode as follows in SQL*Plus: STARTUP MOUNT Recover the data files with the command: RECOVER DATABASE. 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.

Exercise 1. Start a session as a normal user. 4. In SQL*Plus. Shutdown the database as normal and then simulate a Media Failure by deleting the data file used by the tablespace for users. Ensure that you do have a recent COMPLETE offline backup and an ONLINE backup of the tablespace users. ALTER SYSTEM SWITCH LOGFILE. Make changes to the tablespace for users by DELETing all rows in the Saleline table with an ordid greater that 104. 3. ODBA (06/08) 30 © Flying Pigs Oracle . Again SWITCH the log files TWICE and note the change in sequence number. 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. Confirm the changes with a SELECT statement and COMMIT the changes. 7. SWITCH the log files TWICE and note the change in sequence number. DELETE WHERE FROM saleline ordid > 104. There are now at least 2 archived log files and these will be used during recovery. 2. 6. At this point in a live situation it is advisable to take a complete backup of all the database files. Confirm the changes with a SELECT statement and then COMMIT the changes. UPDATE SET WHERE product sell = 100 prdid LIKE ‘M%’. 5. ALTER SYSTEM SWITCH LOGFILE.

10.Open the database to make it available to users: ALTER DATABASE OPEN. Examine the error message in the relevant trace file in ORACLE/admin/bdump. 12.Check that the changes made to the Saleline and Product tables are now back in place. If an attempt is now made to start the database as normal it will fail and the database will be left in MOUNT mode.Recover from the failure and If prompted for a log file name.8. These files do not contain the changes made to Saleline and Product. ODBA (06/08) 31 © Flying Pigs Oracle . 13. 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. 9. 11. press return: RECOVER DATABASE.Restore ALL of the data files for TABLESPACE for users from the latest online backup.

ODBA (06/08) 32 © Flying Pigs Oracle . 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.User Error Action is usually required to recover from this type of failure.

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. 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.Resolution of the error involves restoring ALL data files and running the Recover command until a certain condition is true. 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. since all the files will need recovery • ALWAYS use the current Control file and redo log files ODBA (06/08) 33 © Flying Pigs Oracle . This is known as partial or INCOMPLETE recovery.

to recover to a particular point in time. ODBA (06/08) 34 © Flying Pigs Oracle . For example. When INCOMPLETE recovery has finished. will be prompted for interactively.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. the ORACLE instance may be restarted. if needed. The database MUST be opened and the log file number reset to 1 with the following command: ALTER DATABASE OPEN RESETLOGS. The archived log files. 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 Oracle instance should now be shut down and all files backed up offline using the chosen operating system backup utility. use the command: RECOVER DATABASE UNTIL TIME ‘YYYY-MM-DD:HH:MI:SS’. Startup the database in mount mode as follows in SQL*Plus: STARTUP MOUNT Recover the data files until the condition is true. Once the backup is complete. the database may NOT be opened with: ALTER DATABASE OPEN.

UPDATE SET WHERE saleord dateord = SYSDATE ordid IN (101. 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.102).Exercise 1. 5.00. Make changes to the tablespace for users by UPDATing the cost price of all rows in the Product table to £150. If using SQL*Plus. Start a session as a normal user. Confirm the changes with a SELECT statement and then COMMIT the changes. SWITCH the log files TWICE and note the change in sequence number: ALTER SYSTEM SWITCH LOGFILE. Make a written note of the time using the prompt or the SQL statement: SELECT TO_CHAR(sysdate. Shutdown the database. 7. enter the command: SET TIME ON 2. 4. ODBA (06/08) 35 © Flying Pigs Oracle . At this point in a live situation it is advisable to take a complete backup of all database files. UPDATE SET product cost = 150. 'HH24:MI:SS') FROM dual. Make changes to the tablespace for users by UPDATing the column dateord in the Saleord table to today’s date for order numbers 101 and 102. 6. 3. Confirm the changes with a SELECT statement and COMMIT the changes.

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’. ODBA (06/08) 36 © Flying Pigs Oracle .8. 9. start the database in MOUNT mode: STARTUP MOUNT 10. These files do not contain the changes made to Saleord and Product. Confirm that the log file sequence number has been reset to 1: ALTER DATABASE OPEN RESETLOGS.Check that the changes made to the Saleord table but NOT the Product table are back in place.Open the database and RESET the log files. Restore ALL OF THE DATA files but NOT the control or log files from the offline or online backup. In an SQL*Plus session. 12. ARCHIVE LOG LIST At this point in a live situation it is advisable to take another complete offline backup of the database. 11.

Sign up to vote on this title
UsefulNot useful