Important: Incremental, cumulative, and complete Exports are obsolete features that will be phased out in a subsequent release. You should begin now to migrate to Oracle’s Backup and Recovery Manager for database backups.
If you use cumulative and incremental Exports, you should periodically perform a complete Export to create a base backup. Following the complete Export, perform frequent incremental Exports and occasional cumulative Exports. After a given period of time, you should begin the cycle again with another complete Export.
An incremental Export backs up only tables that have changed since the last incremental, cumulative, or complete Export. An incremental Export exports the table definition and all its data, not just the changed rows. Typically, you perform incremental Exports more often than cumulative or complete Exports.
Assume that a complete Export was done at Time 1. Figure shows an incremental Export at Time 2, after three tables have been modified. Only the modified tables and associated indexes are exported.
Figure : Incremental Export at Time 2
Figure shows another incremental Export at Time 3, after two tables have been modified since Time 2. Because Table 3 was modified a second time, it is exported at Time 3 as well as at Time 2.
Figure : Incremental Export at Time 3
A cumulative Export backs up tables that have changed since the last cumulative or complete Export. A cumulative Export compresses a number of incremental Exports into a single cumulative export file. It is not necessary to save incremental export files taken before a cumulative export because the cumulative export file replaces them.
Figure shows a cumulative Export at Time 4. Tables 1 and 6 have been modified since Time 3. All tables modified since the complete Export at Time 1 are exported.
Figure : Cumulative Export at Time 4
This cumulative export file includes the changes from the incremental Exports from Time 2 and Time 3. Table 3, which was modified at both times, occurs only once in the export file. In this way, cumulative exports save space over multiple incremental Exports.
A complete Export establishes a base for incremental and cumulative Exports. It is equivalent to a full database Export, except that it also updates the tables that track incremental and cumulative Exports.
Figure shows a complete Export at Time 5. With the complete Export, all objects in the database are exported regardless of when (or if) they were modified.
Figure : Complete Export at Time 5
The scenario described in this section shows how you can use cumulative and incremental Exports.
Assume that as manager of a data center, you do the following tasks:
Your export schedule follows:
To restore through day 18, first you import the system information from the incremental Export taken on day 18. Then, you import the data from:
The incremental Exports on days 2 through 7 can be discarded on day 8, after the cumulative Export is done, because the cumulative Export incorporates all incremental Exports. Similarly, the incremental Exports on days 9 through 14 can be discarded after the cumulative Export on day 15.
Note: The section INCTYPE explains the syntax to specify incremental, cumulative, and complete Exports.
Which Data Is Exported?
The purpose of an incremental or cumulative Export is to identify and export only those database objects (such as clusters, tables, views, and synonyms) that have changed since the last Export. Each table is associated with other objects, such as the data, indexes, grants, audits, triggers, and comments.
The entire grant structure for tables or views is exported with the underlying base tables. Indexes are exported with their base table, regardless of who created the index. If the base view is included, "instead of" triggers on views are included. Any modification (UPDATE, INSERT, or DELETE) on a table automatically qualifies that table for incremental Export. When a table is exported, all of its inner nested
tables and LOB columns are exported also. Modifying an inner nested table column causes the outer table to be exported. Modifying a LOB column causes the entire table containing the LOB data to be exported.
Also, the underlying base tables and data are exported if database structures have changed in the following ways:
In addition to the base tables and data, the following data is exported:
Note: Export does not export grants on data dictionary views for security reasons that affect Import. If such grants were exported, access privileges would be changed and the user would not be aware of this. Also, not forcing grants on import allows the user more flexibility to set up appropriate grants on import.
Example Incremental Export Session
The following example shows an incremental Export session after the tables SCOTT.EMP and SCOTT.DEPT are modified:
> exp system/manager full=y inctype=incremental
Export: Release 188.8.131.52.0 - Production on Wed Oct 6 15:25:47 1999
(c) Copyright 1999 Oracle Corporation. All rights reserved.
Connected to: Oracle8i Enterprise Edition Release 184.108.40.206.0 - Production
With the Partitioning and Java options
PL/SQL Release 220.127.116.11.0 - Production
Export done in WE8DEC character set and WE8DEC NCHAR character set
About to export the entire database ...
. exporting tablespace definitions
. exporting profiles
. exporting user definitions
. exporting roles
. exporting resource costs
. exporting rollback segment definitions
. exporting database links
. exporting sequence numbers
. exporting directory aliases
. exporting context namespaces
. exporting foreign function library names
. exporting object type definitions
. exporting system procedural objects and actions
. exporting pre-schema procedural objects and actions
. exporting cluster definitions
. about to export SYSTEM's tables via Conventional Path ...
. about to export OUTLN's tables via Conventional Path ...
. about to export DBSNMP's tables via Conventional Path ...
. about to export SCOTT's tables via Conventional Path ...
. . exporting table DEPT 8 rows exported
. . exporting table EMP 23 rows exported
. about to export ADAMS's tables via Conventional Path ...
. about to export JONES's tables via Conventional Path ...
. about to export CLARK's tables via Conventional Path ...
. about to export BLAKE's tables via Conventional Path ...
. exporting referential integrity constraints
. exporting synonyms
. exporting views
. exporting stored procedures
. exporting operators
. exporting indextypes
. exporting bitmap, functional and extensible indexes
. exporting posttables actions
. exporting triggers
. exporting snapshots
. exporting snapshot logs
. exporting job queues
. exporting refresh groups and children
. exporting dimensions
. exporting post-schema procedural objects and actions
. exporting user history table
. exporting default and system auditing options
. exporting information about dropped objects
. exporting statistics
Export terminated successfully without warnings.
The user SYS owns three tables (INCEXP, INCFIL, and INCVID) that are maintained by Export. These tables are updated when you specify RECORD=Y (the default). You should not alter these tables in any way.
The table SYS.INCEXP tracks which objects were exported in specific exports.
This table contains the following columns:
OWNER# The userid of the schema containing the table.
NAME The object name. The primary key consists of OWNER#, NAME, and TYPE.
TYPE The type of the object (a code specifying INDEX, TABLE, CLUSTER, VIEW, SYNONYM, SEQUENCE, PROCEDURE, FUNCTION, PACKAGE, TRIGGER, DIMENSION, OPERATOR, INDEXTYPE, SNAPSHOT, SNAPSHOT LOG, or PACKAGE BODY).
CTIME The date and time of the last cumulative export that included this object.
ITIME The date and time of the last incremental export that included this object.
EXPID The ID of the incremental or cumulative export, also found in the table SYS.INCFIL.
You can use this information in several ways. For example, you could generate a report from SYS.INCEXP after each export to document the export file. You can use the views DBA_EXP_OBJECTS, DBA_EXP_VERSION, and DBA_EXP_FILES to display information about incremental exports.
The table SYS.INCFIL tracks the incremental and cumulative exports and assigns a unique identifier to each.
This table contains the following columns:
EXPID The ID of the incremental or cumulative export, also found in the table SYS.INCEXP.
EXPTYPE The type of export (incremental or cumulative).
EXPFILE The name of the export file.
EXPDATE The date of the export.
EXPUSER The USERNAME of the individual who initiated the export. When you export with the parameter INCTYPE = COMPLETE, all previous entries are removed from SYS.INCFIL and a new row is added specifying an "x" in the column EXPTYPE.
The table SYS.INCVID contains one column for the EXPID of the last valid export. This information determines the EXPID of the next export.
Oracle 8i Related Interview Questions
|Oracle 10g Interview Questions||Oracle 9i Interview Questions|
|Oracle 8i Interview Questions||Informatica Interview Questions|
|PL/SQL Interview Questions||Oracle 11g Interview Questions|
|SQL Interview Questions||Oracle apps Interview Questions|
|Sybase Interview Questions||Oracle Apps ERP Interview Questions|
|Oracle 7.3 Interview Questions||Oracle Access Manager Interview Questions|
|Oracle Application Framework Interview Questions||Oracle Apps DBA Interview Questions|
Oracle 8i Related Practice Tests
|Oracle 10g Practice Tests||Oracle 9i Practice Tests|
|Oracle 8i Practice Tests||Informatica Practice Tests|
|PL/SQL Practice Tests||Oracle 11g Practice Tests|
|SQL Practice Tests||Oracle apps Practice Tests|
|Sybase Practice Tests||Oracle Apps ERP Practice Tests|
|Oracle 7.3 Practice Tests|
Oracle 8i Tutorial
Sql*loader Case Studies
Sql*loader Control File Reference
Sql*loader Command-line Reference
Sql*loader: Log File Reference
Sql*loader: Conventional And Direct Path Loads
Dbverify: Offline Database Verification Utility
All rights reserved © 2018 Wisdom IT Services India Pvt. Ltd
Wisdomjobs.com is one of the best job search sites in India.