Professional Documents
Culture Documents
Oracle - Export Inc
Oracle - Export Inc
FROM SYS.INCEXP;
NO ROWS SELECTED
But if you query it immediately after performing an INCTYPE=COMPLETE export, youll see something that looks like this:
SELECT
FROM SYS.INCEXP;
OWNER# -----5 5 5 66
NAME TYPE# CTIME ITIME EXPID ------------------------- ---------- --------- --------- ----AQ$_INTERNET_AGENTS 2 13/NOV/01 13/NOV/01 1 AQ$_INTERNET_AGENT_PRIVS 2 13/NOV/01 13/NOV/01 1 DEF$_AQCALL 2 13/NOV/01 13/NOV/01 1 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.
Copyright Howard Rogers 2001 15/11/2001 Page 1 of 10
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 doesnt 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. Its 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 doesnt. A CUMULATIVE export causes us to check each tables SCN (timestamp) against the CTIME column of the INCEXP system table. If the tables 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 dont touch the CTIME column, the existence of intervening incremental exports is irrelevant as
Copyright Howard Rogers 2001 15/11/2001 Page 2 of 10
far as a subsequent cumulative export is concerned: the table gets exported anyway, even if its been included in 20 intervening incremental exports. On the other hand, if youre performing an INCREMENTAL export, we compare each tables 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 doesnt 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, its as though the FULL exports had never happened.
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 ON
FRI
NOV
16 12:42:49 2001
. . . . . .
and so on.
Copyright Howard Rogers 2001 15/11/2001 Page 3 of 10
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, Ill see this: SQL> UPDATE S_INVENTORY 4 ROWS UPDATED.
SET AMOUNT_IN_STOCK=0 WHERE PRODUCT_ID=41100;
C:\>EXP SYSTEM/MANAGER FULL=Y INCTYPE=INCREMENTAL [SNIP] . EXPORTING TABLESPACE DEFINITIONS . EXPORTING PROFILES [SNIP] S_INVENTORY . . EXPORTING TABLE
114
ROWS EXPORTED
and youll notice that the same 114 rows as before get included in the new export, not just the 4 that I updated. Thats because export can only ever grab entire objects, so naturally all the rows in a table go along for the ride.
15/11/2001
Page 4 of 10
This table does have a primary key, on the ID column. That evening, I perform a complete export:
Copyright Howard Rogers 2001 15/11/2001 Page 5 of 10
C:\>
EMP
10
ROWS EXPORTED
3, 41,950);
EMP
10
ROWS EXPORTED
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:
Copyright Howard Rogers 2001 15/11/2001 Page 6 of 10
C:\>IMP
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) 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!
VIOLATED
Now when we finally get to look at the contents of the EMP table, we see this:
15/11/2001
Page 7 of 10
SQL>
SELECT
FROM EMP;
ID ---------2 3 4 5 6 7 8 9 10 1 11 11
ENAME MANAGER_ID DEPT_ID SALARY ---------------------- ---------- ---------- ---------WOLFGANG MOZART 1 41 1450 FELIX MENDELSSOHN 1 31 1400 LUDWIG BEETHOVEN 1 10 1450 GUSTAV MAHLER 1 50 1550 DMITRI SHOSTAKOVICH 2 41 1200 EDWARD ELGAR 2 42 1250 HENRY PURCELL 2 43 1100 AARON COPLAND 2 44 1300 LEONARD BERNSTEIN 2 45 1307 BENJAMIN BRITTEN 50 2500 SERGEI RACHMANINOV 3 1 950
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: Its 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 ON
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.
Copyright Howard Rogers 2001 15/11/2001 Page 8 of 10
FROM EMP;
ID ---------2 3 4 5 6 8 9 10 1 11 10
ENAME MANAGER_ID DEPT_ID SALARY ------------------------- ---------- ---------- ---------WOLFGANG MOZART 1 41 1450 FELIX MENDELSSOHN 1 31 1400 LUDWIG BEETHOVEN 1 10 1450 GUSTAV MAHLER 1 50 1550 DMITRI SHOSTAKOVICH 2 41 1200 HENRY PURCELL 2 43 1100 AARON COPLAND 2 44 1300 LEONARD BERNSTEIN 2 45 1307 BENJAMIN BRITTEN 50 3000 SERGEI RACHMANINOV 3 41 950
ROWS SELECTED.
Mr. Elgar has gone (and good riddance, too). Mr. Britten is being paid what hes 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 dont 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, youll find yourself running multiple imports against dump files that dont include the relevant table, and wasting time in the process.
15/11/2001
Page 9 of 10
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. Thats 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 shouldnt bother.
Copyright Howard Rogers 2001 15/11/2001 Page 10 of 10