8/6/2019 Oracle - Export as Backup

1/2

Does Export count as a Backup? Backup and Recovery Tips

Copyright Howard Rogers 2001 28/10/2001 Page 1 of 2

Does Export count as a Backup?

What do backups do for you? Well, if theyre any good, they should give you the ability to

recover your data in the event of catastrophe, and not lose any committed data in the

process.

By that definition, then exports do not really count as backups, since they have two

distinct failings: they can only recover data as it used to be, at the time the export was

taken, in fact. Whats worse, there is not the slightest possibility of recovering that data

further by applying redo to it. Hence, everything after the time of the export is lost,

whether committed or not.

As a substitute for a full physical backup (whether taken with RMAN or using O/S

techniques), exports are therefore hopeless.

But as an adj unctto physical backups, they are priceless because they give you extra

choices when it comes to choosing a particular recovery strategy.

The classic case is when a User commits some grievous error. Perhaps he drops a table, or

commits duff data in the table. The usual recommended approach at that point would be

to demand of the User when precisely the error occurred, and to perform an incomplete

recovery just prior to the time of that error (a recover until time recovery).

But incomplete recoveries are awful affairs. They require the entire database to be closed

for the duration; the entire database loses data that was committed after the time of the

user error; all prior database archives and backups are rendered useless and the database

is thus rendered extremely vulnerable the list goes on and on.

Consider the alternative: restore the single table from the last good export. Sure, all data

that was committed in that table after the time of the user error is lost, but thats a

trivial affair compared to losing data from the entire database. Import does not require

the database to be shutdown to perform its stuff in fact, the database must be open for it

to work therefore, theres minimal inconvenience to other Users. No archives or backups

are rendered useless by the running of import, so the database as a whole is not rendered

particularly vulnerable. And so on: for every minus associated with incomplete recoveries,

export/import provides an important escape route.

Of course, certain provisos now have to be introduced: what Im proposing here is that the

table subject to user error should be restored (effectively) to a different time from all

other tables in the rest of the database. There is clearly a potential for logical corruption

to be introduced into the database there (for example, restoring DEPT to a time of three

days ago might mean that there are a number of employees in EMP working in departmentswhich dont now actually exist). This needs to be handled carefully, of course.

8/6/2019 Oracle - Export as Backup

2/2

Does Export count as a Backup? Backup and Recovery Tips

Copyright Howard Rogers 2001 28/10/2001 Page 2 of 2

But, in general terms, any import followed by manual re-entry of lost records is going to be

a good deal easier (and cheaper) to perform than an equivalent incomplete recovery.

Whats more, in 9i, it is possible to combine export/import with Log Miner to guarantee

total data recovery for the affected table. Thats because in 9i you can include

supplemental log groups for a table which, despite the name, simply means that atransaction against a table causes the Primary Key (or any other nominated columns) to be

included in the redo stream for that transaction. Therefore, the possibility now arises of

recovering a table from import, and then mining the Logs for all transactions that affected

the table after the time of the relevant export. Using the Primary Key information stored

in the Logs, those transactions can then be re-applied to the freshly-imported table

without trouble.

Unfortunately, this approach cant work in anything earlier than 9i, because in those

earlier versions, the redo stream identifies all records affected by transactions only by

their rowids and when you run import, you can pretty well guarantee that every

recovered row has a brand new row id, thus rendering the redo stream inapplicable to that

tables recovered data. Nevertheless, using Log Miner, you can get a reasonable idea of

what transactions (and how many of them) hit the affected table, and thus be more

precise about what transactions need to be repeated, albeit manually.

Export has other uses, of course such as being able to logically clone a database without

too much drama, and without requiring the original database to be closed down in the

process (which a true clone really requires). It also allows a database to be transferred to

a completely different Operating System (Unix to NT, for example), provided the dump file

is ftpd to the new machine in binary mode. No physical backup can pull that one off.

Finally, being a logical backup of the database, it allows distribution of databases or parts

thereof to third parties, without them having to worry about exactly how, physically, the

database should be configured.

In summary, if youre relying on export as your only method of backup, you want your head

tested. Conversely, any DBA not performing regular exports because s/he thinks the

physical backup is sufficient is just asking for trouble (or miraculously has Users that never

make mistakes). Exports complement physical backups, and a decent DBA would be wiseto do both.