Does Export count as a Backup?

Backup and Recovery Tips

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 adjunct to 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 departments which dont now actually exist). This needs to be handled carefully, of course.
Page 1 of 2

Copyright Howard Rogers 2001

28/10/2001

Does Export count as a Backup?

Backup and Recovery Tips

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 a transaction 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 wise to do both.

Copyright Howard Rogers 2001

28/10/2001

Page 2 of 2