Re: Using export as a backup strategy

Just a few personal opinion/comments...

What is the "acceptable downtime for recovery"?

No matter how well you plan it, a recover from a full export WILL take longer than you think. Also, a test today might not really indicate what a "real recover" will be like in a year or 2. Applications add Plsql, views, Java, or something that was not there in your test and could cause "pain" when you do the "real recover".

The process of "create empty database and do a full import" is re-building EVERY database object(table,index,users,tablespaces,grants,sequences,etc.). This is especially painful if you have a lot of PlSql or database links (other databases had better be up when doing the import). Also, some features like "fine-grain access" (or "virtual private database") require you do the export as SYS. I like to avoid using SYS whenever possible :)

I could not imagine have only 1 backup/recover option. I like alternatives :)

Having said all that, our supplemental export backups have been useful MANY times to recover 1 table's data or 1 schema's data (where there is no referential integrity across schemas). Also, when the backup file is compressed, the export backup is "tiny" compared to the database. This makes it useful for other things. For example, we ftp a copy of full exports nightly from 1 site to another site as a "cheap" method of potentially handling "disaster recovers" where a building is destroyed. We of course have a backup to this backup of using physical backups on tape and the tapes are sent offsite, but they are a little (a much as 1 month) older. And, yes, this was acceptable to all involved.

Anyway, for anyone doing export backups as a supplement or as a primary (not that I am recommending it as primary), I would highly recommend using consistent=y for the export to get a consistent view (in case someone changes something while the export is running). Note that this could require a very large rollback segment, so it is best if you can get applications to "avoid" the export backup time.

Also, I would use compress=n to avoid things like creating a table at its existing "high water mark" and creating unnecessarily large disorganized indexes "that need reducing/rebuilding" anyway.

-- 
"Thomas Richards" <tom.richards_at_rocketmail.com> wrote in message
news:f118866.0401080927.145449c1_at_posting.google.com...


> Oracle 8i 8.1.5 on NT.

>

> I have a database for which a day's data loss is an acceptable risk.

> From reading the Oracle Backup and Recovery guide, I get the

> impression that export is recommended as a supplement to a backup

> strategy rather than a backup strategy in itself.

>

> Please can someone explain why export only can't be used in a scenario

> where a day's data loss is acceptable and there is a period of no user

> activity when a consistent export can be achieved?

>

> If I lose a disk, can I not create an empty database and load the

> previous night's backup?

>

> Is there any advantage to doing physical backups that I have

> overlooked? For example, if I do export only should I be doing control

> file backups as well?

>

> Any thoughts on this much appreciated

>

> Thanks

> Tom