microsoft word - can i do incremental exports

Can I do Incremental Exports? Backup and Recovery Tips

Copyright © Howard Rogers 2001 15/11/2001 of 10

Can I do Incremental Exports? 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!

The Rules of Inclusion If you’re doing incremental or cumulative exports, the export utility has to work out what tables should be included in the latest export, and which should be ignored (because their contents haven’t changed). How it works out what has changed and what hasn’t is instructive. 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: SELECT * FROM SYS.INCEXP; NO ROWS SELECTED

But if you query it immediately after performing an INCTYPE=COMPLETE export, you’ll see something that looks like this: SELECT * FROM SYS.INCEXP; OWNER# NAME TYPE# CTIME ITIME EXPID ------ ------------------------- ---------- --------- --------- ----- 5 AQ$_INTERNET_AGENTS 2 13/NOV/01 13/NOV/01 1 5 AQ$_INTERNET_AGENT_PRIVS 2 13/NOV/01 13/NOV/01 1 5 DEF$_AQCALL 2 13/NOV/01 13/NOV/01 1 66 EMP 2 13/NOV/01 13/NOV/0 1

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? OWNER# NAME TYPE# CTIME ITIME EXPID ------ ------------------------- ---------- --------- --------- ----- 66 EMP 2 14/NOV/01 14/NOV/01 3

Again, both columns are updated. 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: OWNER# NAME TYPE# CTIME ITIME EXPID ------ ------------------------- ---------- --------- --------- ----- 66 EMP 2 14/NOV/01 15/NOV/01 4

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? OWNER# NAME TYPE# CTIME ITIME EXPID ------ ------------------------- ---------- --------- --------- ----- 66 EMP 2 14/NOV/01 15/NOV/01 4

So, a FULL=Y doesn’t update this table at all. Bear these rules in mind, therefore:

• COMPLETE exports update both time columns. • CUMULATIVE exports update both time columns. • INCREMENTALs only update the ITIME column. • And a basic FULL=Y with no INCTYPE at all updates nothing.

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. Obviously, a COMPLETE export includes everything. It’s therefore functionally equivalent to a FULL=Y, but does update the INCEXP table –so performing a new COMPLETE affects what future incrementals and cumulatives will contain, but performing a new FULL=Y doesn’t. 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



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.

Summary of the Rules of Inclusion Trying to put that into very simple English, we deduce the following:

• 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. So you might issue this sort of command, for example: C:\>EXP SYSTEM/MANAGER FULL=Y INCTYPE=INCREMENTAL EXPORT: RELEASE 9.0.1.1.1 - PRODUCTION ON FRI NOV 16 12:42:49 2001 (…followed by a list of all the objects being exported) . . EXPORTING TABLE S_INVENTORY 114 ROWS EXPORTED . . EXPORTING TABLE S_ITEM 62 ROWS EXPORTED . . EXPORTING TABLE S_LONGTEXT 33 ROWS EXPORTED …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: SQL> UPDATE S_INVENTORY SET AMOUNT_IN_STOCK=0 WHERE PRODUCT_ID=41100; 4 ROWS UPDATED. C:\>EXP SYSTEM/MANAGER FULL=Y INCTYPE=INCREMENTAL [SNIP] . EXPORTING TABLESPACE DEFINITIONS . EXPORTING PROFILES [SNIP] . . EXPORTING TABLE S_INVENTORY 114 ROWS EXPORTED …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.

Uses of Incremental and Cumulative Exports I suppose the inevitable question at this point is: why bother? Why is this functionality useful? 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.



Individual Table Imports The real killer with incremental exports, though, is what happens during subsequent imports. Let’s keep things simple at this stage (because it only gets worse!). Suppose you have a Sunday complete export, followed by a Monday incremental, and then on Tuesday the EMP table gets accidentally dropped. The temptation is going to be to do what you’d probably do with normal system tape backups: restore from the Sunday complete, and then apply the Monday incremental to pick up new changes. 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: ID ENAME MANAGER_ID DEPT_ID SALARY ---------- ------------------------- ---------- ---------- ---------- 1 BENJAMIN BRITTEN 50 2500 2 WOLFGANG MOZART 1 41 1450 3 FELIX MENDELSSOHN 1 31 1400 4 LUDWIG BEETHOVEN 1 10 1450 5 GUSTAV MAHLER 1 50 1550 6 DMITRI SHOSTAKOVICH 2 41 1200 7 EDWARD ELGAR 2 42 1250 8 HENRY PURCELL 2 43 1100 9 AARON COPLAND 2 44 1300 10 LEONARD BERNSTEIN 2 45 1307 This table does have a primary key, on the ID column. That evening, I perform a complete export:



C:\> EXP SYSTEM/MANAGER INCTYPE=COMPLETE FULL=Y FILE=EXPSUN.DAT …and the export display shows me: . . EXPORTING TABLE EMP 10 ROWS EXPORTED On Monday, I perform the following three bits of DML: DELETE FROM EMP WHERE ENAME=’EDWARD ELGAR’; INSERT INTO EMP VALUES (11, ‘SERGEI RACHMANINOV’, 3, 41,950); UPDATE EMP SET SALARY=3000 WHERE ID=1; COMMIT; That evening, I perform an incremental export: C:\> EXP SYSTEM/MANAGER INCTYPE=INCREMENTAL FULL=Y FILE=EXPMON.DAT …and again the export display shows me: . . EXPORTING TABLE EMP 10 ROWS EXPORTED On Tuesday morning, we have a slight accident: DROP TABLE EMP; …So I import from the Sunday export: C:\>IMP SYSTEM/MANAGER TABLES=EMP IGNORE=Y FILE=EXPSUN.DAT FROMUSER=SCOTT IMPORT: RELEASE 9.0.1.1.1 - PRODUCTION ON FRI OCT 26 13:27:33 2001 (C) COPYRIGHT 2001 ORACLE CORPORATION. ALL RIGHTS RESERVED. CONNECTED TO: ORACLE9I ENTERPRISE EDITION RELEASE 9.0.1.1.1 - PRODUCTION WITH THE PARTITIONING OPTION JSERVER RELEASE 9.0.1.1.1 - PRODUCTION EXPORT FILE CREATED BY EXPORT:V09.00.01 VIA CONVENTIONAL PATH IMPORT DONE IN WE8MSWIN1252 CHARACTER SET AND AL16UTF16 NCHAR CHARACTER SET IMPORT SERVER USES CL8MSWIN1251 CHARACTER SET (POSSIBLE CHARSET CONVERSION) . IMPORTING SCOTT'S OBJECTS INTO SCOTT . . IMPORTING TABLE "EMP" 10 ROWS IMPORTED IMPORT TERMINATED SUCCESSFULLY WITHOUT WARNINGS. Looking good! Now I try to capture the Monday changes by importing from the incremental export:



C:\>IMP SYSTEM/MANAGER TABLES=EMP IGNORE=Y FILE=EXPMON.DAT FROMUSER=SCOTT IMPORT: RELEASE 9.0.1.1.1 - PRODUCTION ON FRI OCT 26 13:28:55 2001 (C) COPYRIGHT 2001 ORACLE CORPORATION. ALL RIGHTS RESERVED. CONNECTED TO: ORACLE9I ENTERPRISE EDITION RELEASE 9.0.1.1.1 - PRODUCTION WITH THE PARTITIONING OPTION JSERVER RELEASE 9.0.1.1.1 - PRODUCTION EXPORT FILE CREATED BY EXPORT:V09.00.01 VIA CONVENTIONAL PATH IMPORT DONE IN WE8MSWIN1252 CHARACTER SET AND AL16UTF16 NCHAR CHARACTER SET IMPORT SERVER USES CL8MSWIN1251 CHARACTER SET (POSSIBLE CHARSET CONVERSION) . IMPORTING SCOTT'S OBJECTS INTO SCOTT . . IMPORTING TABLE "EMP" 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 2 COLUMN 2 WOLFGANG MOZART COLUMN 3 1 COLUMN 4 41 COLUMN 5 1450 IMP-00019: ROW REJECTED DUE TO ORACLE ERROR 1 IMP-00003: ORACLE ERROR 1 ENCOUNTERED ORA-00001: UNIQUE CONSTRAINT (SCOTT.EMP_PK) VIOLATED [SNIP MUCH MORE OF THE SAME…] 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. None of which looks quite so good! Now when we finally get to look at the contents of the EMP table, we see this:



SQL> SELECT * FROM EMP; ID ENAME MANAGER_ID DEPT_ID SALARY ---------- ---------------------- ---------- ---------- ---------- 2 WOLFGANG MOZART 1 41 1450 3 FELIX MENDELSSOHN 1 31 1400 4 LUDWIG BEETHOVEN 1 10 1450 5 GUSTAV MAHLER 1 50 1550 6 DMITRI SHOSTAKOVICH 2 41 1200 7 EDWARD ELGAR 2 42 1250 8 HENRY PURCELL 2 43 1100 9 AARON COPLAND 2 44 1300 10 LEONARD BERNSTEIN 2 45 1307 1 BENJAMIN BRITTEN 50 2500 11 SERGEI RACHMANINOV 3 1 950 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. In short: It’s a mess. 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: C:\>IMP SYSTEM/MANAGER TABLES=EMP IGNORE=Y FILE=EXPMON.DAT FROMUSER=SCOTT IMPORT: RELEASE 9.0.1.1.1 - PRODUCTION ON FRI OCT 26 13:32:44 2001 (C) COPYRIGHT 2001 ORACLE CORPORATION. ALL RIGHTS RESERVED. CONNECTED TO: ORACLE9I ENTERPRISE EDITION RELEASE 9.0.1.1.1 - PRODUCTION WITH THE PARTITIONING OPTION JSERVER RELEASE 9.0.1.1.1 - PRODUCTION EXPORT FILE CREATED BY EXPORT:V09.00.01 VIA CONVENTIONAL PATH IMPORT DONE IN WE8MSWIN1252 CHARACTER SET AND AL16UTF16 NCHAR CHARACTER SET IMPORT SERVER USES CL8MSWIN1251 CHARACTER SET (POSSIBLE CHARSET CONVERSION) . IMPORTING SCOTT'S OBJECTS INTO SCOTT . . IMPORTING TABLE "EMP" 10 ROWS IMPORTED IMPORT TERMINATED SUCCESSFULLY WITHOUT WARNINGS.



…and a check of the EMP table reveals: SQL> SELECT * FROM EMP; ID ENAME MANAGER_ID DEPT_ID SALARY ---------- ------------------------- ---------- ---------- ---------- 2 WOLFGANG MOZART 1 41 1450 3 FELIX MENDELSSOHN 1 31 1400 4 LUDWIG BEETHOVEN 1 10 1450 5 GUSTAV MAHLER 1 50 1550 6 DMITRI SHOSTAKOVICH 2 41 1200 8 HENRY PURCELL 2 43 1100 9 AARON COPLAND 2 44 1300 10 LEONARD BERNSTEIN 2 45 1307 1 BENJAMIN BRITTEN 50 3000 11 SERGEI RACHMANINOV 3 41 950 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. Apart from remembering to do imports in what is perhaps a non-intuitive way, it also means that you need to be extremely aware of what tables managed to get included in what exports –otherwise, you’ll find yourself running multiple imports against dump files that don’t include the relevant table, and wasting time in the process.

Complete Database Imports Things get rather worse when you try and import a complete database using incremental exports. The order of events becomes critical, because you have to get the data dictionary in the right shape before attempting to recover the actual tables and their data. In fact, I’d go so far as to say that it’s practically impossible to pull off by mere mortals. What you are supposed to do (in this order) is: Import from the most recent incremental or cumulative export, specifying INCTYPE=SYSTEM as one of the import parameters. This gets users, object types, and so on correct, but doesn’t import any actual tables.



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”.

microsoft word - can i do incremental exports

Documents