Documente Academic
Documente Profesional
Documente Cultură
You most certainly can, but you should be aware that Oracle has publicly declared that
this facility will disappear from future versions of Oracle (though it’s still there in 9i).
It’s not something that will reliably work into the future, therefore.
But first, the basics. The way to perform an incremental export is to use the INCTYPE
parameter, which accepts three different values: COMPLETE, CUMULATIVE or
INCREMENTAL. Incidentally, this parameter can only be supplied when you are doing full
database exports (i.e., where FULL=Y), though you can specify FULL=Y without specifying
any of these parameters.
The rules as to what gets included in each of these types of export can be tricky to put
into words, though it can be summarised quite simply. I’ll give you the technical details
first, and the easy summary at the end!
Whenever you specify an INCTYPE parameter, export updates a special table in the SYS
schema, called INCEXP. If you’ve never performed an INCTYPE export before, querying
that table is something of a disapointment:
But if you query it immediately after performing an INCTYPE=COMPLETE export, you’ll see
something that looks like this:
Notice in particular the two time columns: CTIME means “included in a cumulative export”
and ITIME means “included in an incremental export”. Obviously, a COMPLETE export
updates both of these columns (since it includes all tables), and you can therefore regard a
COMPLETE as being a superset of both incremental and cumulative exports.
Let us suppose that I now perform DML on the EMP table, and a day later seek to perform
an INCTYPE=CUMULATIVE export. What does the INCEXP table now show?
Now, another day passes, and I again perform some DML on the table, and perform an
INCTYPE=INCREMENTAL export. The INCEXP table now shows this:
Notice this time that only the ITIME column is updated, not the CTIME one.
Finally, suppose I now perform a final FULL=Y export, without specifying any INCTYPE
(again, a day later, and again after performing DML on the EMP table). What does the
table show then?
Since the contents of this INCEXP table determine which tables get included in the next
export that is run with one of the INCTYPE parameters, these rules are significant.
A CUMULATIVE export causes us to check each table’s SCN (timestamp) against the CTIME
column of the INCEXP system table. If the table’s SCN is greater than the CTIME date,
then the table is included in the new export. Since both COMPLETE and CUMULATIVE
exports update the CTIME column, tables modified since the last complete or cumulative
export are included in a new cumulative export. But since INCREMENTAL exports don’t
touch the CTIME column, the existence of intervening incremental exports is irrelevant as
Copyright © Howard Rogers 2001 15/11/2001 Page 2 of 10
Can I do Incremental Exports? Backup and Recovery Tips
far as a subsequent cumulative export is concerned: the table gets exported anyway, even
if it’s been included in 20 intervening incremental exports.
On the other hand, if you’re performing an INCREMENTAL export, we compare each table’s
SCN with the ITIME column of the INCEXP table –and since COMPLETE, CUMULATIVE and
INCREMENTAL exports all update that column, then the rule must be that a new
incremental export will include any table that has been modified since the time of the last
export of any of these kinds.
Most importantly, since a FULL=Y export with no INCTYPE parameter specified doesn’t
touch any part of the INCEXP table, the existence of such exports is totally irrelevant to
what gets included in the next export that does specify an INCTYPE. For the purposes of
INCTYPE exports, and working out what tables they should include, it’s as though the FULL
exports had never happened.
• FULL=Y includes all objects and does not affect the contents of future exports at all
• COMPLETE includes all objects and does affect future cumulatives and incrementals
• CUMULATIVE includes objects modified since the last cumulative or complete
• INCREMENTAL includes objects modified since the last incremental, cumulative or
complete export
Object-level exports
Two important points need to be made here: first, the cumulative and incremental exports
include objects that have changed. Not parts of objects. Not just the new rows added
since the last export. But the entire table, cluster, index or whatever the object might be.
Second, both DML and DDL constitute a “change” for the purposes of determining whether
a particular object should be included in a new export.
…and so on.
If I then perform an update to just a few rows in the “S_INVENTORY” table, and follow that
up immediately with a new incremental backup, I’ll see this:
…and you’ll notice that the same 114 rows as before get included in the new export, not
just the 4 that I updated. That’s because export can only ever grab entire objects, so
naturally all the rows in a table go along for the ride.
Well, cumulative and incremental exports only include a subset of all the possible objects
in the database. Objects that haven’t been subject to DML or DDL are ignored on second
and subsequent exports. That means that the export dump files are considerably smaller
than they otherwise would be, of course. It also means that the exports themselves take
much less time to complete than a full database export would require.
However, for precisely that same reason, the use of these types of export poses a number
of unique problems. For a start, it means that you can now no longer be certain of what is
included within any given dump file. If a User suddenly announces that the EMP table has
gone missing, you can’t know for sure whether it can be recovered from Monday’s,
Tuesday’s or whatever’s export. You could, of course, dash off to query the SYS.INCEXP
table and work it out, but that involves some work and some mental agility to convert
ITIME and CTIME columns into meaningful results. It’s not impossible to do, but it’s
definitely trickier than simply having a single dump file that’s guaranteed to be complete.
The other problem with this sort of export is that, because each dump file that is produced
is not a complete export of the database, you have to keep all the partial files generated
available –you’d need the entire set to re-construct an entire database. To avoid excessive
numbers of such files being required, every so often you should perform a COMPLETE
export. That way, you only need to retain incremental and cumulative dump files
generated since the time of the last COMPLETE one.
But with export/import, that way disaster lies –because the Sunday and the Monday dump
files both include a complete copy of the EMP table. If you therefore import from Sunday,
a fully-populated version of EMP is created. When you come to apply the incremental from
Monday, the import will fail, because the object it wants to create (EMP) will already exist.
So you might at that point remember to run the second import with the IGNORE=Y
parameter… at which point, what happens to your data is in the lap of the gods:
Suppose you don’t have a primary key on the EMP table. Then the second import will
duplicate every single row that was already created by the import from Sunday’s dump file!
Now suppose you do have a primary key defined. Then the second import will generate a
string of constraint violation messages, followed by the insertion of any rows that were
freshly created between the two exports. But what about any deletes that a User
performed before the EMP table disappeared on Tuesday. Are those deletes re-performed
for us? No: those rows were inserted by performing the first import, and the second
import does not contain instructions to delete records, only to insert new ones. So rows
that were deleted are back again after performing the imports. What about rows that
were updated on Monday? Well, the original values were restored by performing the first
import, and the second import didn’t touch that row because of the primary key constraint
issues –so all updates are lost too!
I can demonstrate that as follows. On Sunday, the EMP table looked like this:
This table does have a primary key, on the ID column. That evening, I perform a complete
export:
Looking good!
Now I try to capture the Monday changes by importing from the incremental export:
Copyright © Howard Rogers 2001 15/11/2001 Page 6 of 10
Can I do Incremental Exports? Backup and Recovery Tips
COLUMN 5 1307
IMP-00019: ROW REJECTED DUE TO ORACLE ERROR 1
IMP-00003: ORACLE ERROR 1 ENCOUNTERED
ORA-00001: UNIQUE CONSTRAINT (SCOTT.EMP_PK) VIOLATED
COLUMN 1 1
COLUMN 2 BENJAMIN BRITTEN
COLUMN 3
COLUMN 4 50
COLUMN 5 3000 1 ROWS IMPORTED
IMPORT TERMINATED SUCCESSFULLY WITH WARNINGS.
Now when we finally get to look at the contents of the EMP table, we see this:
11 ROWS SELECTED.
…Britten is still there with his old salary –the update is ignored. Mr. Rachmaninov has been
inserted –the insert is respected. Mr. Elgar is still sitting there, composing dreadful music –
deletes are ignored.
The reason of course is that the inclusion of complete objects in a dump file, whatever the
nature of the export, means that the approach of ‘import from full and apply
incrementals’ is completely wrong. All you need do is import from the last export taken
that happens to include the object you want.
In this particular example, all we need do is import from the Monday Incremental backup,
since that contains all the latest updates, deletes and inserts:
10 ROWS SELECTED.
Mr. Elgar has gone (and good riddance, too). Mr. Britten is being paid what he’s worth.
And Mr. Rachmaninov makes his expected appearance. All inserts, updates and deletes are
therefore being accounted for.
In summary, when it comes time to using incremental exports to recover, you start with
the latest export and work backwards. As soon as the table is recovered, you can stop –
you don’t need to go any further back. And all this behaviour is as a result of the fact that
exports always export complete objects, not individual rows.
In fact, I’d go so far as to say that it’s practically impossible to pull off by mere mortals.
Next, you import from the most recent complete export file, specifying INCTYPE=RESTORE.
Then you import all cumulative export files made after the last complete export, again
specifying INCTYPE=RESTORE.
Then you import all incremental export files made after the last cumulative export, yet
again specifying INCTYPE=RESTORE
And allegedly that does the deed, with one tiny proviso: the Oracle documentation states
unequivocally that you should only perform this sort of restore when the database being
imported into has NO user tables whatsoever within it. That’s because the INCTYPE
parameter can only be specified when you are performing a full database import, not
specific tables or specific schemas. The presence of any tables in the database as you
attempt such an import is therefore liable to cause the import process to fail.
Note, however, that the recovery process using this technique does actually follow the
‘restore from complete then apply incrementals’ sequence that you might have assumed to
be the normal mode of operation in the first place. That frees you up from worrying about
which dump file to use as the basis of a restore, since you simply start with the last
complete export, and progress forwards in sequence with all subsequent incrementals.
The only slight twist to that is to apply the last incremental first with an INCTYPE=SYSTEM
just to get the data dictionary in shape. Even with that in mind, though, it does mean you
can perform restores without being intimately familiar with the contents of your various
dump files.
Conclusion
Having said all of that, what are the benefits and costs associated with incremental
exports?
The benefits are easy to state: Your exports take less time, and the dump files are smaller.
The costs are significant, too: Importing either requires you to work your way backwards,
starting with the latest export, until you happen to restore the right table. Or you have to
keep excellent records about which tables got included in which export –then you can go
straight to the latest export known to contain the table you want. The alternative ‘roll
forward’ technique (start with a complete, and apply all subsequent cumulatives and
incrementals) requires a database with no existing tables to work relaibly, which makes it
of rather specialised use. It also requires multiple import runs, with great care being
required to specify the correct INCTYPE each time.
Frankly, the costs are high: imports become extremely fiddly, however you elect to do
them. And, for me, that means they will generally outweigh the benefits. So the real
answer to the question posed right at the beginning of this paper, “Can I do Incremental
Exports?” is “Yes, but you probably shouldn’t bother”.