Database export in oracle 11g

• Database export
You can use Oracle's export utility to supplement a full backup. If changes are made to a known set of data objects between full backups, you can export the objects.
However, the export utility should only be used on data objects that are not changing during the export and on all data objects that are closely related. For example, if you use export to back up a business table, you should also capture the related spatial index, feature, and delta tables in the same backup.
ESRI does not recommend that you use the export utility as your only backup method.
You can also back up the entire Oracle database with the Oracle export utility, then make cumulative and incremental backups.
For more information on the export utility, refer to the Oracle utilities manual for your Oracle release.

You should make regular full backups of the Oracle database. A full backup should include the Oracle database, control files, data files, redo log files, and, if you have started an ArcSDE service, the giomgr.defs, dbinit.sde, and services.sde files.

If your Oracle database is operating under ARCHIVELOG mode, you can add several variations to your backup strategy in addition to the periodic full backup. Databases operating under the NOARCHIVELOG mode are restricted to full backups with the possible addition of Oracle export files.

You should make at least three copies of the control files with each backup because of their importance in ensuring database consistency. Because control files are comparatively small, there is negligible cost in doing so.

The redo log files are essential for bringing the data files from an earlier state to a later state. Between any two points in time, the redo logs must be found in an unbroken sequence if database recovery is to succeed.

ESRI recommends that you maintain at least two copies of all archived redo logs for as far back in time as may be reasonably necessary for database recovery. The two copies should be stored on physically distinct media-separate disk drives, for example, or a disk drive and a tape drive.

If you intend to purge the archived redo log files from their location on disk, be sure that you have a second backup copy of each archived redo log file before purging.

This strategy of multiple backups of the archived redo log files helps guard against multiple media failure, which is not as rare as it might seem. Some tape drives, for example, fail to detect bit errors until you attempt to restore a file, when it may be too late.

You only need to make a single copy of each data file with each backup as long as you carefully maintain multiple copies of archived redo logs.

NOTE: The online redo log files are not necessary for backup. If the current online redo log file fails, committed information still exists in memory, which Oracle writes to the data files when a checkpoint is issued. Oracle issues a checkpoint automatically when you shut down a database instance with NORMAL, IMMEDIATE, or TRANSACTIONAL priority. Before shutting down a database with ABORT priority, you should force a checkpoint with the ALTER SYSTEM > CHECKPOINT command if at all possible.