Tài liệu ORACLE8i- P13 ppt

Control File Backups Control file backups come in two flavors: • Backup control files are generated through the use of the ALTER SYSTEM BACKUP CONTROL FILE TO ‘filename’ command, as in t

Now, let’s look at the table.

SQL> SELECT TO_CHAR(the_time, ‘mm/dd/yyyy hh24:mi:ss’) FROM time_table;

TO_CHAR(THE_TIME,’M -04/29/2001 00:24:5204/29/2001 00:24:5404/29/2001 00:27:2604/29/2001 00:27:26

Shut down the database

SQL> SHUTDOWN IMMEDIATEDatabase closed

Database dismounted

ORACLE instance shut down

Recover the last backup

SQL> HOST COPY d:\oracle_backup\hot\*.* d:\oracle\oradata\recoverd:\oracle_backup\hot\RECOVER_RBS_01.DBF

d:\oracle_backup\hot\RECOVER_USERS_01.DBFd:\oracle_backup\hot\RECOVER_DATA_01.DBFd:\oracle_backup\hot\RECOVER_INDEX_TBS_01.DBFd:\oracle_backup\hot\RECOVER_TEMP_01.DBFd:\oracle_backup\hot\RECOVER_TEST_TBS_01.DBFd:\oracle_backup\hot\SYSTEM01.DBF

Mount the database

SQL> STARTUP MOUNTORACLE instance started

Total System Global Area 92280076 bytesFixed Size 70924 bytesVariable Size 87937024 bytesDatabase Buffers 4194304 bytesRedo Buffers 77824 bytesDatabase mounted

We begin the change-based recovery

Notice we use automatic application of archived redo logs in response to the recovery prompt

Change 35936 is the first change in the online redo log after we forced the log switch, thus we will recover up to but not including that point

SQL> RECOVER DATABASE UNTIL CHANGE 35936;

We open the database Note the use of RESETLOGS

SQL> ALTER DATABASE OPEN RESETLOGS;

We query the table, and see only two records!

SQL> SELECT TO_CHAR(the_time, ‘mm/dd/yyyy hh24:mi:ss’) FROM time_table;

TO_CHAR(THE_TIME,’M -04/29/2001 00:24:5204/29/2001 00:24:54

Cancel-Based Recovery

Cancel-based recovery allows you to manually apply archived redo logs to the base during a recovery, but be able to stop the recovery after the application of eacharchived redo log and open the database This is handy in cases where you have lost acontrol file or the online redo log, and you need to recover the database as much aspossible

data-To use cancel-based recovery, use the command RECOVER DATABASE UNTIL CANCEL Then, as you are prompted for archived redo logs to apply, enter CANCEL

to stop the recovery process We will demonstrate the use of cancel-based recovery inthe next section

Recovery from Loss of Online Redo Logs

A special case is recovery from the loss of the online redo log This is a particular lem if the online redo log that is lost is the current online redo log and no othermembers exist In this case, if your database crashes along with the loss of the redolog, you will likely lose some data

prob-NOTE As noted earlier, the online redo log is the Achilles heel of Oracle This is why youmust protect it by creating at a minimum two different members of each redo log group(and I prefer three) Each of these should be on a separate disk and use a separate con-troller, if possible

RECOVERIES IN ARCHIVELOG MODE

Oracle Database Administration

P A R T

II

Should you lose the online log file and the database doesn’t crash, you may findthat it hangs In this case, you can try to issue the ALTER DATABASE CLEAR LOGFILEcommand, and this may solve the problem

Suppose that you accidentally deleted the online redo log during maintenance,after shutting down the database with the SHUTDOWN NORMAL or SHUTDOWNIMMEDIATE command In this case, you can perform an easy bit of magic to solve theproblem, as shown in Listing 10.9

Listing 10.9: Recovering from the Loss of the Online Redo Logs after a Normal Database Shutdown

In this first case, we shut down our database to do some maintenance. Unfortunately, we didn’t test our script and we accidentally deleted our online redo logs We shut down the database normally with a SHUTDOWN IMMEDIATE command, so recovery in this case is a snap

All we need to do is issue a recover database until cancel command, and then open the database with RESETLOGS (RESETLOGS will re-create the redo logs!)

SQL> STARTUPORACLE instance started

Total System Global Area 92280076 bytesFixed Size 70924 bytesVariable Size 87937024 bytesDatabase Buffers 4194304 bytesRedo Buffers 77824 bytesDatabase mounted

ORA-00313: open failed for members of log group 1 of thread 1ORA-00312: online log 1 thread 1: ‘D:\ORACLE\ORADATA\RECOVER\REDO01.LOG’SQL> RECOVER DATABASE UNTIL CANCEL;

Media recovery complete

SQL> ALTER DATABASE OPEN RESETLOGS;

Database altered

If you issued SHUTDOWN ABORT, or some other problem caused a database crash(such as a power failure), then you have a bigger problem Assuming that you have lostone or more of the online redo logs required to get the database up and going again,you will need to restore all database datafiles from the last good backup and recoverthe database In this kind of recovery situation, complete database recovery will not

be possible After you have completed the recovery, you will need to issue the ALTERDATABASE OPEN RESETLOGS command The use of the RESETLOGS command will

SQL> SELECT count(*) FROM time_table;

COUNT(*) -4096

SQL> ALTER SYSTEM SWITCH LOGFILE;

SQL> COMMIT;

Commit complete

SQL> connect / as sysdbaConnected

Oh no!! System crash big time!

SQL> SHUTDOWN ABORTORACLE instance shut down

Restart the database

SQL> STARTUPORACLE instance started

Total System Global Area 92280076 bytesFixed Size 70924 bytes

RECOVERIES IN ARCHIVELOG MODE

Oracle Database Administration

P A R T

II

Variable Size 87937024 bytesDatabase Buffers 4194304 bytesRedo Buffers 77824 bytesDatabase mounted.

ORA-00313: open failed for members of log group 3 of thread 1ORA-00312: online log 3 thread 1: ‘D:\ORACLE\ORADATA\RECOVER\REDO03.LOG’ORA-27041: unable to open file

OSD-04002: unable to open fileO/S-Error: (OS 2) The system cannot find the file specified

We lost our online redo log file It is nowhere to be found

So, we need to recover the database Can we do a regular recovery?SQL> RECOVER DATABASE;

ORA-00283: recovery session canceled due to errorsORA-00313: open failed for members of log group 3 of thread 1ORA-00312: online log 3 thread 1: ‘D:\ORACLE\ORADATA\RECOVER\REDO03.LOG’ORA-27041: unable to open file

OSD-04002: unable to open fileO/S-Error: (OS 2) The system cannot find the file specified

No way … that missing redo log is murder We need to do based recovery or change-based recovery Let’s do cancel-based. What log sequences do we have available?

cancel-SQL> ARCHIVE LOG LISTDatabase log mode Archive ModeAutomatic archival EnabledArchive destination D:\Oracle\oradata\Recover\archiveOldest online log sequence 2

Next log sequence to archive 4Current log sequence 4

So, the lost log sequence number is 4 (this shows as the current log file) We need to recover to log sequence number 3, which we should have available Let’s do that with cancel-based recovery

Apply log sequence 1

SQL> RECOVER DATABASE UNTIL CANCEL;

ORA-00279: change 56033 generated at 04/29/2001 00:52:37 needed

ORA-00289: suggestion :D:\ORACLE\ORADATA\RECOVER\ARCHIVE\RECOVERT001S00001.ARCORA-00280: change 56033 for thread 1 is in sequence #1

Specify log: {<RET>=suggested | filename | AUTO | CANCEL}

ORA-00279: change 56047 generated at 04/29/2001 00:53:53 neededORA-00289: suggestion :

D:\ORACLE\ORADATA\RECOVER\ARCHIVE\RECOVERT001S00002.ARCORA-00280: change 56047 for thread 1 is in sequence #2ORA-00278: log file

‘D:\ORACLE\ORADATA\RECOVER\ARCHIVE\RECOVERT001S00001.ARC’

no longer needed for this recovery

Specify log: {<RET>=suggested | filename | AUTO | CANCEL}

ORA-00279: change 56056 generated at 04/29/2001 00:55:02 needed ORA-00289: suggestion :

D:\ORACLE\ORADATA\RECOVER\ARCHIVE\RECOVERT001S00003.ARCORA-00280: change 56056 for thread 1 is in sequence #3ORA-00278: log file

‘D:\ORACLE\ORADATA\RECOVER\ARCHIVE\RECOVERT001S00002.ARC’

no longer needed for this recovery

Specify log: {<RET>=suggested | filename | AUTO | CANCEL}

ORA-00279: change 56065 generated at 04/29/2001 00:56:44 neededORA-00289: suggestion :

\D:\ORACLE\ORADATA\RECOVER\ARCHIVE\RECOVERT001S00004.ARCORA-00280: change 56065 for thread 1 is in sequence #4ORA-00278: log file

‘D:\ORACLE\ORADATA\RECOVER\ARCHIVE\RECOVERT001S00003.ARC’

no longer needed for this recoverySpecify log: {<RET>=suggested | filename | AUTO | CANCEL}

cancelMedia recovery canceled

SQL> ALTER DATABASE OPEN RESETLOGS;

Database altered

Note the data loss We have only half the number of rows in time_table that we should have!!

SQL> SELECT COUNT(*) FROM time_table;

RECOVERIES IN ARCHIVELOG MODE

Oracle Database Administration

P A R T

II

WARN I NG While using SHUTDOWN ABORT may work 99.99 percent of the time,you should realize that there is some risk to your database in doing this If you do a SHUT-DOWN ABORT, and you lose your online redo log file, you will likely suffer some data loss

To reduce this risk, issue an ALTER SYSTEM SWITCH LOGFILE command and then an ALTERSYSTEM CHECKPOINT command before forcing a SHUTDOWN ABORT It will make theshutdown take a bit longer, but it reduces your risk somewhat (but not completely)

Control File Backups

Control file backups come in two flavors:

• Backup control files are generated through the use of the ALTER SYSTEM BACKUP CONTROL FILE TO ‘filename’ command, as in this example:

ALTER DATABASE BACKUP CONTROL FILE TO

‘d:\oracle_backup\control\backup_control_01.ctl’;

• Trace files can be created that contain the DDL required to re-create the currentcontrol file This is facilitated through the use of the ALTER SYSTEM BACKUPCONTROL FILE TO TRACE command

Both methods are useful when you need to recover the database The trace file erated by the ALTER SYSTEM BACKUP CONTROL FILE TO TRACE command alsoserves as a good piece of documentation for your database, because it lists variousdatabase configuration information

gen-NOTE The backup control file itself is not readable It is in the same format as the Oraclecontrol file

Using the Backup Control File for Database Recovery

If you use the backup control file to recover a database, you must use the USINGBACKUP CONTROL FILE syntax of the RECOVER command Listing 10.11 provides

an example of using a backup control file to recover a database Note that whenrecovering with a backup control file, you will need to use RESETLOGS to open thedatabase

NOTE In many cases, when you use the CREATE CONTROL FILE command to recoverfrom a lost control file, you will not need to issue a RESETLOGS command You alwaysneed to use RESETLOGS when recovering with a backup control file

Listing 10.11: Using a Backup Control File when Recovering a Database

First, create a backup control file

SQL> ALTER DATABASE BACKUP CONTROLFILE TO

2 ‘d:\oracle_backup\control\backup_control_01.ctl’;

Database altered

Shut down the database

SQL> SHUTDOWN IMMEDIATEDatabase closed

Database dismounted

ORACLE instance shut down

Now, remove the existing control files

SQL> HOST DEL d:\oracle\oradata\recover\*.ctl

Try to start up the database

SQL> STARTUPORACLE instance started

Total System Global Area 92280076 bytesFixed Size 70924 bytesVariable Size 87937024 bytesDatabase Buffers 4194304 bytesRedo Buffers 77824 bytesORA-00205: error in identifying controlfile, check alert log for more info

A snippet from the alert log looks like this:

ORA-00202: controlfile: ‘D:\Oracle\oradata\Recover\control01.ctl’

CONTROL FILE BACKUPS

Oracle Database Administration

P A R T

II

ORA-27041: unable to open file OSD-04002: unable to open file O/S-Error: (OS 2) The system cannot find the file specified.

The database won’t start due to missing control files

Shut it down again

SQL> SHUTDOWNORA-01507: database not mountedORACLE instance shut down

Copy backup control file into place

SQL> HOST COPY d:\oracle_backup\control\backup_control_01.ctld:\oracle\oradata\recover\control01.ctl

SQL> HOST COPY d:\oracle_backup\control\backup_control_01.ctld:\oracle\oradata\recover\control02.ctl

SQL> HOST COPY d:\oracle_backup\control\backup_control_01.ctld:\oracle\oradata\recover\control03.ctl

Now, startup mount the database

SQL> STARTUP MOUNTORACLE instance started

Total System Global Area 92280076 bytesFixed Size 70924 bytesVariable Size 87937024 bytesDatabase Buffers 4194304 bytesRedo Buffers 77824 bytesDatabase mounted

Now, determine the current online log file sequence numbers. We may have to recover using an online sequence number

SELECT a.group#, a.member, b.sequence#

FROM v$logfile a, v$log bWHERE a.group#=b.group#;

GROUP# MEMBER SEQUENCE# - - -

1 D:\ORACLE\ORADATA\RECOVER\REDO01.LOG 10

2 E:\TESTRECOVER\REDO02.LOG 11

3 D:\ORACLE\ORADATA\RECOVER\REDO03.LOG 9

Now, recover the database

SQL> RECOVER DATABASE USING BACKUP CONTROLFILE;

ORA-00279: change 136287 generated at 04/29/2001 22:48:45needed for thread 1

ORA-00289: suggestion :D:\ORACLE\ORADATA\RECOVER\ARCHIVE\RECOVERT001S00011.ARCORA-00280: change 136287 for thread 1 is in sequence #11

Specify log: {<RET>=suggested | filename | AUTO | CANCEL}

e:\testrecover\redo02.logLog applied

Media recovery complete

Note that we had to apply the current online redo log (redo02.log) instead of taking the prompted archive log sequence number

This isn’t always going to be required, but it does happen

Now, we open the database with RESETLOGS

SQL> ALTER DATABASE OPEN RESETLOGS;

Database altered

Using a Trace File

If you are going to use a trace file resulting from the BACKUP CONTROL FILE TOTRACE command, you will need to edit it first, because Oracle adds a trace file header

on the trace file before generating the RECOVERY command The trace file will tain a CREATE CONTROL file command Review the command and make sure it issuitable Once you are satisfied that the command is correct, connect to the databaseand start the instance with STARTUP NOMOUNT command Following that, run thescript with the CREATE CONTROL FILE inside of it to re-create the control file

con-Depending on the condition of your online redo logs, RESETLOGS may or may not berequired If the online redo logs are intact, you should not need to issue a RESETLOGScommand In fact, if the database was shut down cleanly, you won’t even need torecover the database

Listing 10.12 provides an example of using the results of the ALTER DATABASEBACKUP CONTROL FILE TO TRACE command to recover a database

CONTROL FILE BACKUPS

Oracle Database Administration

P A R T

II

Listing 10.12: Using the Trace File Results to Recover a Database

First, create the trace file with the ALTER DATABASE COMMAND.SQL> ALTER DATABASE BACKUP CONTROLFILE TO TRACE;

Database altered

We will need to edit the trace file to remove the file header

Now, shut down the database

SQL> SHUTDOWN IMMEDIATEDatabase closed

Database dismounted

ORACLE instance shut down

Now, delete the control files

SQL> HOST DEL d:\oracle\oradata\recover\*.ctl Execute the edited trace file

This is the code in the trace file that is executed

SQL> STARTUP NOMOUNTORACLE instance started

Total System Global Area 92280076 bytesFixed Size 70924 bytesVariable Size 87937024 bytesDatabase Buffers 4194304 bytesRedo Buffers 77824 bytes

Create the control file

SQL> CREATE CONTROLFILE REUSE DATABASE “RECOVER” NORESETLOGS ARCHIVELOG

8 GROUP 1 ‘D:\ORACLE\ORADATA\RECOVER\REDO01.LOG’ SIZE 1M,

9 GROUP 2 ‘D:\ORACLE\ORADATA\RECOVER\REDO02.LOG’ SIZE 1M,

10 GROUP 3 ‘D:\ORACLE\ORADATA\RECOVER\REDO03.LOG’ SIZE 1M

11 DATAFILE

20 CHARACTER SET WE8ISO8859P1;

Control file created

Does the database need recovery?

SQL> RECOVER DATABASE;

ORA-00283: recovery session canceled due to errorsORA-00264: no recovery required

No recovery needed (this is because we had a clean shutdown)

Open the database

SQL> ALTER DATABASE OPEN;

Database altered

Other Oracle Backups

There are some other files that you might need to consider backing up from time totime These include the following:

• The parameter (init.ora) file should be backed up after any changes

• Any other database configuration files (ifiles, and the oratab file, for example)should be backed up after any changes

• Any listener or Net8 configuration files such as the listener.ora, tnsnames.ora,and sqlnet.ora files should be backed up after any changes

• All database creation scripts should be backed up after the creation of the base Any scripts that change the design of the database (DDL) should be backed

data-up as they are implemented

• Keep a current backup of your Oracle software for easy recovery Back up the ware directory any time a change (such as a patch application) is made

soft-CONTROL FILE BACKUPS

Oracle Database Administration

P A R T

II

RESETLOGS and Recovery

The use of the RESETLOGS command seems to be an area of confusion for beginningand even some intermediate-level DBAs In this section, we will try to remove some ofthe mystery

When you use RESETLOGS, you are creating another incarnation, or version, of

the database Recovery between incarnations is generally not supported by Oracle(though we will discuss a way to recover between incarnations shortly) Thus, it isvery important that you back up the database immediately after issuing the RESET-LOGS command Consider that the logical lifetime of a given database is between itscreation, or the execution of the last RESETLOGS command, and the execution of theRESETLOGS command Thus, you cannot recover different logical versions of thedatabase

TI P As you will see shortly, it is always a really good idea to back up your online redologs before issuing the RESETLOGS command

Before Oracle will open the database with the RESETLOGS command, several sistency checks are performed:

con-• Datafile compatibility set in the datafile headers must not be greater than thecompatible setting for the database The current compatible setting for the data-base is set by the COMPATIBLE parameter in the init.ora file

• Offline immediate files must be brought online or dropped

• Datafiles cannot have any of the fuzzy bits set, and all datafiles must be at thesame SCN level, except read-only tablespace datafiles

These checks can be a bit tough at times and can cause you to need to force openthe database (which we will discuss shortly)

Why and When to Use RESETLOGS

Once you have applied incomplete recovery, the remaining unapplied redo generated

by the database after the point you have recovered to becomes useless Therefore,there needs to be a way to clear the unusable redo and reset various other internal set-tings This is the purpose of the RESETLOGS command

You use RESETLOGS when doing a point-in-time recovery of the database Thiscommand is also used when you are recovering the database using a backup controlfile and recovering a database with a control file created using the CREATE CONTROLFILE command that includes the RESETLOGS option The RESETLOGS option in theCREATE CONTROL FILE command must be used if you are recovering a databasewhen both the control file and the current online redo logs are missing If you arerecovering a database with a backup control file, the RESETLOGS option will need to

be used if the online redo logs have been lost

When the RESETLOGS command is issued, the following actions take place:

• Oracle will reset the log sequence number for the next online redo log to 1 Thisalso has the effect of rendering unusable any archived redo log (and any onlineredo) generated in the online redo logs after the creation of the new incarnation

• A log file group is chosen to be the current online redo log group

• The control file and all the datafiles are resynchronized Datafile headers foronline datafiles are updated Offline datafiles are marked as needing recovery

• The control file and the FILE$ table are cross-checked Oracle will consider theFILE$ table to be correct Therefore, if a file is in the FILE$ table and it is not in

the control file, it will be marked in the control file with a MISSINGxxx

place-holder If the file is in the control file but not in FILE$, it will be dropped fromthe control file

• All redo in the online redo logs will be cleared

• Any missing online redo logs will be created

Recovering through RESETLOGS

You should always make a backup of your database after using the RESETLOGS mand This is one of those rare cases where I like to do a cold backup, because it makessure that the database remains consistent until after I have completed my backup

com-However, performing a cold backup may not possible It does, after all, increaseyour time to recover You may opt for a hot backup, or you might decide to wait forthe normal nightly backup so the backup process does not impact the user commu-nity While these decisions are somewhat related to business needs, you should makesure that management clearly understands the risks of such decisions

What happens if you perform an incomplete recovery, issue the RESETLOGS mand, and before you can back up the database, it comes crashing down again? Inthis case, you are not only faced with a recovery, but you also need to recover throughthe use of the RESETLOGS command Fortunately, there is a way to perform such a

com-RESETLOGS AND RECOVERY

Oracle Database Administration

P A R T

II

recovery (obviously, the database must be in ARCHIVELOG mode for this to work).The bad news is that the requirements to be able to perform this recovery are ratherexacting To do this kind of recovery you must have the following:

• The datafile backup from before the issuing of the RESETLOGS command

• A copy of the control file from the database backed up before the RESETLOGScommand

• All archived redo logs from before and after the issuing of the RESETLOGScommand

• A copy of the online redo logs as they looked just before you issued the LOGS command (in other words, right before you issue the RESETLOGS com-mand, back up the online redo logs)

RESET-WAR N I N G It is strongly suggested that you discuss your plans to roll forwardthrough RESETLOGS with Oracle support before you do it

Here are the steps you take to roll forward through the last RESETLOGS:

1 Create a backup control file for the current database (Use the ALTER SYSTEM

BACKUP CONTROLFILE TO TRACE command.)

2 Restore the datafiles using the last backup of the database made before you

issued the RESETLOGS command Make sure you have copies of the online redologs from before issuing the RESETLOGS command

3 Restore the backup control file from the last control file backup that you took

before the RESETLOGS command Restore it to a location other than the tion of the current control file Modify the init.ora file of the database to point

loca-to the new control file location

4 Mount the database by issuing a STARTUP MOUNT command.

5 From the alert log, find the change number for the open RESETLOGS command.

6 Recover the database using the backup control file until the change number

found in the previous step

7 When recovery completes, shut down the database with a normal shutdown.

8 Change init.ora to point back to the original location of the control files.

9 Mount the database by issuing a STARTUP MOUNT command.

10 Recover the database using the current control file Open the database without

RESETLOGS

When All Else Fails—Forcing Open the Database

We saved this section for last, and this is because forcing open the database is anabsolute last resort Table 10.5 provides a list of the parameters that can be used toforce open a database Often, if you are trying to force open a database, you will need

to use more than one parameter

WARNING Talk to Oracle before using these parameters They may change betweenversions, and their uses may even change

TABLE 10.5: PARAMETERS TO FORCE OPEN AN ORACLE DATABASE

_corrupted_rollback_

segments=rb01

If a rollback segment is unavailable orcorrupted, can be used to force the data-base open Any transaction that is in theaffected rollback segment will be consid-ered committed, thus leading to a veryserious possibility of database consistencyproblems, including the data dictionary

in place until all the database blockswith changes in the rollback segmentshave been recovered

_offline_rollback_segments

WHEN ALL ELSE FAILS—FORCING OPEN THE DATABASE

Oracle Database Administration

P A R T

II

TABLE 10.5: PARAMETERS TO FORCE OPEN AN ORACLE DATABASE (CONTINUED)

WARNING Using many of the parameters listed in Table 10.5 is not supported by Oracle.You should talk to Oracle support before using them Use of some of these parameters willalmost guarantee that your database will be in an inconsistent state They can cause yourdatabase to be destroyed (and you to ask yourself why you ever did what you did!)

You should use these parameters only if your database is hopelessly dead in thewater, Oracle support personnel have thrown up their hands in failure, and your sys-tem administrator has said you do not have a good backup available Oracle will prob-ably not suggest some of these to you—ever I am not suggesting that you use thesefor anything other than fun and frolic (I love to play with stuff I’m not supposed to!)

So, again, you are warned to use them at your own risk

_allow_read_only_corruption=TRUE

New in 8i, allows you to open the base in read-only mode, even if it is corrupted

data-_allow_read_only_corruption

_allow_resetlogs_corruption=TRUE

Causes all consistency checks during theexecution of RESETLOGS to be skipped

It allows database files to have differentSCNs or even have the fuzzy bits set

This can be used, for example, if youlose a datafile and it cannot be recov-ered completely because of missingarchived redo logs

_allow_resetlogs_corruption

CHAPTER 11

Oracle Logical Backup and Recovery

F E A T U R I N G : The Oracle Export utility 492 The Oracle Import utility 504

L restore some part of the physical database before you can use a logical

backup to recover it Logical backups do not provide point-in-time recovery,

as do physical backups

Logical backups do provide several useful features They facilitate Oracle8i featuressuch as transportable tablespaces, and they also provide the ability to recover specificobjects that were backed up at a specific point in time For example, you might want

to use logical backups with databases that are part of a development system, where alot of destructive testing occurs With logical backups, you can restore certain tables

to how they looked before a test Also, logical exports are one method that can beused to move an Oracle database between different operating systems

Logical backups are supported by Oracle through the use of two tools: the Importutility and the Export utility In this chapter, we will address the use of these twoutilities

The Oracle Export Utility

The Oracle Export utility (EXP) has been around since the early days of Oracle It vides a means of producing a logical extract of the data from an Oracle database into

pro-a operpro-ating system file, often cpro-alled the export dump file, or just the dump file This file

is created in a format that allows it to be used by the Oracle Import utility (IMP) to create the data (and database structures) in the same database or another database, at

re-a lre-ater dre-ate The following re-are some common uses of logicre-al exports:

• Extracting specific objects for recovery and re-creation purposes

• Defragmenting a database

• Rebuilding a database in order to defragment the SYSTEM tablespace

• Protecting the database from user errors, such as a user accidentally truncating atable

• Saving the structure of the database, including table definitions, indexes, straints, and stored program units (such as PL/SQL functions and procedures)

con-• Creating a historical archive of a given state of the databaseBasically, once the export file is created, it can be copied to any other system run-ning Oracle (for example, via NFS or FTP transfer) and used to re-create that database(or some part of it) on that other system Together, the Export and Import utilities

Oracle Database Administration

P A R T

II

allow you to move an Oracle database between operating systems, on the same ating system, or even the same database

oper-Logical backups provide the ability to extract the database in a consistent manner;

that is, the data in the export will be consistent to the time that the export was taken

Another interesting benefit you get with the Export utility is that as each block isread, the export process will detect logically corrupt blocks When corrupt blocks aredetected, the export will fail You can then correct the problem and restart the export

Most physical backup software will not detect corrupt blocks, making it possible toback up (and recover) corrupted data without ever knowing about it

NOTE RMAN provides block checking when performing physical backups See Chapter 13for details on using RMAN

What Can You Export?

The Export utility works with more than data When configured properly, it can beused to export the following database objects:

• Tablespaces

• Schema objects (tables and indexes)

• Constraints, grants, and synonyms

• Users

• Data

• Stored PL/SQL code (procedures, functions, triggers, and so on)The Export utility cannot be used to re-create the database itself The base databasemust be created (via the CREATE DATABASE command) before an export file can beused to load data into that database However, once the base database is created, theExport utility can create all of the tablespaces, including the datafiles and the otherassociated objects

The Export utility does not back up all of the objects in the database Specifically,objects owned by SYS (such as the data dictionary tables) will not be exported Otherschemas that will not be exported include ORDSYS , MDSYS, CTXSYS, and ORD-PLUGINS If you create objects using these schemas, those objects will not be exported

493

THE ORACLE EXPORT UTILITY