Your SlideShare is downloading. ×
Exportinc
Exportinc
Exportinc
Exportinc
Exportinc
Exportinc
Exportinc
Exportinc
Exportinc
Exportinc
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Exportinc

122

Published on

oracle foreign key primary key constraints performance tuning MTS IOT 9i block size backup rman corrupted column drop rename recovery controlfile backup clone architecture database archives export …

oracle foreign key primary key constraints performance tuning MTS IOT 9i block size backup rman corrupted column drop rename recovery controlfile backup clone architecture database archives export dump dmp duplicate rows extents segments fragmentation hot cold blobs migration tablespace locally managed redo undo new features rollback ora-1555 shrink free space user password link TNS tnsnames.ora listener java shutdown sequence

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
122
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
1
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. Can I do Incremental Exports? Backup and Recovery TipsCan I do Incremental Exports?You most certainly can, but you should be aware that Oracle has publicly declared thatthis 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 INCTYPEparameter, which accepts three different values: COMPLETE, CUMULATIVE orINCREMENTAL. Incidentally, this parameter can only be supplied when you are doing fulldatabase exports (i.e., where FULL=Y), though you can specify FULL=Y without specifyingany of these parameters.The rules as to what gets included in each of these types of export can be tricky to putinto words, though it can be summarised quite simply. I’ll give you the technical detailsfirst, and the easy summary at the end!The Rules of InclusionIf you’re doing incremental or cumulative exports, the export utility has to work out whattables should be included in the latest export, and which should be ignored (because theircontents haven’t changed). How it works out what has changed and what hasn’t isinstructive.Whenever you specify an INCTYPE parameter, export updates a special table in the SYSschema, called INCEXP. If you’ve never performed an INCTYPE export before, queryingthat table is something of a disapointment:SELECT * FROM SYS.INCEXP;NO ROWS SELECTEDBut if you query it immediately after performing an INCTYPE=COMPLETE export, you’ll seesomething 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 1Notice in particular the two time columns: CTIME means “included in a cumulative export”and ITIME means “included in an incremental export”. Obviously, a COMPLETE exportupdates both of these columns (since it includes all tables), and you can therefore regard aCOMPLETE as being a superset of both incremental and cumulative exports.Copyright © Howard Rogers 2001 15/11/2001 Page 1 of 10
  • 2. Can I do Incremental Exports? Backup and Recovery TipsLet us suppose that I now perform DML on the EMP table, and a day later seek to performan 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 3Again, both columns are updated.Now, another day passes, and I again perform some DML on the table, and perform anINCTYPE=INCREMENTAL export. The INCEXP table now shows this:OWNER# NAME TYPE# CTIME ITIME EXPID------ ------------------------- ---------- --------- --------- ----- 66 EMP 2 14/NOV/01 15/NOV/01 4Notice 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 thetable show then?OWNER# NAME TYPE# CTIME ITIME EXPID------ ------------------------- ---------- --------- --------- ----- 66 EMP 2 14/NOV/01 15/NOV/01 4So, 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 nextexport that is run with one of the INCTYPE parameters, these rules are significant.Obviously, a COMPLETE export includes everything. It’s therefore functionally equivalentto a FULL=Y, but does update the INCEXP table –so performing a new COMPLETE affectswhat future incrementals and cumulatives will contain, but performing a new FULL=Ydoesn’t.A CUMULATIVE export causes us to check each table’s SCN (timestamp) against the CTIMEcolumn 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 CUMULATIVEexports update the CTIME column, tables modified since the last complete or cumulativeexport are included in a new cumulative export. But since INCREMENTAL exports don’ttouch the CTIME column, the existence of intervening incremental exports is irrelevant asCopyright © Howard Rogers 2001 15/11/2001 Page 2 of 10
  • 3. Can I do Incremental Exports? Backup and Recovery Tipsfar as a subsequent cumulative export is concerned: the table gets exported anyway, evenif it’s been included in 20 intervening incremental exports.On the other hand, if you’re performing an INCREMENTAL export, we compare each table’sSCN with the ITIME column of the INCEXP table –and since COMPLETE, CUMULATIVE andINCREMENTAL exports all update that column, then the rule must be that a newincremental export will include any table that has been modified since the time of the lastexport of any of these kinds.Most importantly, since a FULL=Y export with no INCTYPE parameter specified doesn’ttouch any part of the INCEXP table, the existence of such exports is totally irrelevant towhat gets included in the next export that does specify an INCTYPE. For the purposes ofINCTYPE exports, and working out what tables they should include, it’s as though the FULLexports had never happened.Summary of the Rules of InclusionTrying 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 exportObject-level exportsTwo important points need to be made here: first, the cumulative and incremental exportsinclude objects that have changed. Not parts of objects. Not just the new rows addedsince 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 whethera 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=INCREMENTALEXPORT: 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.Copyright © Howard Rogers 2001 15/11/2001 Page 3 of 10
  • 4. Can I do Incremental Exports? Backup and Recovery TipsIf I then perform an update to just a few rows in the “S_INVENTORY” table, and follow thatup 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, notjust the 4 that I updated. That’s because export can only ever grab entire objects, sonaturally all the rows in a table go along for the ride.Uses of Incremental and Cumulative ExportsI suppose the inevitable question at this point is: why bother? Why is this functionalityuseful?Well, cumulative and incremental exports only include a subset of all the possible objectsin the database. Objects that haven’t been subject to DML or DDL are ignored on secondand subsequent exports. That means that the export dump files are considerably smallerthan they otherwise would be, of course. It also means that the exports themselves takemuch 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 numberof unique problems. For a start, it means that you can now no longer be certain of what isincluded within any given dump file. If a User suddenly announces that the EMP table hasgone 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.INCEXPtable and work it out, but that involves some work and some mental agility to convertITIME and CTIME columns into meaningful results. It’s not impossible to do, but it’sdefinitely 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 producedis not a complete export of the database, you have to keep all the partial files generatedavailable –you’d need the entire set to re-construct an entire database. To avoid excessivenumbers of such files being required, every so often you should perform a COMPLETEexport. That way, you only need to retain incremental and cumulative dump filesgenerated since the time of the last COMPLETE one.Copyright © Howard Rogers 2001 15/11/2001 Page 4 of 10
  • 5. Can I do Incremental Exports? Backup and Recovery TipsIndividual Table ImportsThe real killer with incremental exports, though, is what happens during subsequentimports. Let’s keep things simple at this stage (because it only gets worse!). Suppose youhave a Sunday complete export, followed by a Monday incremental, and then on Tuesdaythe EMP table gets accidentally dropped. The temptation is going to be to do what you’dprobably do with normal system tape backups: restore from the Sunday complete, andthen apply the Monday incremental to pick up new changes.But with export/import, that way disaster lies –because the Sunday and the Monday dumpfiles 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 fromMonday, 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=Yparameter… 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 willduplicate 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 astring of constraint violation messages, followed by the insertion of any rows that werefreshly created between the two exports. But what about any deletes that a Userperformed before the EMP table disappeared on Tuesday. Are those deletes re-performedfor us? No: those rows were inserted by performing the first import, and the secondimport does not contain instructions to delete records, only to insert new ones. So rowsthat were deleted are back again after performing the imports. What about rows thatwere updated on Monday? Well, the original values were restored by performing the firstimport, and the second import didn’t touch that row because of the primary key constraintissues –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 1307This table does have a primary key, on the ID column. That evening, I perform a completeexport:Copyright © Howard Rogers 2001 15/11/2001 Page 5 of 10
  • 6. Can I do Incremental Exports? Backup and Recovery TipsC:> EXP SYSTEM/MANAGER INCTYPE=COMPLETE FULL=Y FILE=EXPSUN.DAT…and the export display shows me:. . EXPORTING TABLE EMP 10 ROWS EXPORTEDOn 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 EXPORTEDOn 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=SCOTTIMPORT: 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 - PRODUCTIONWITH THE PARTITIONING OPTIONJSERVER RELEASE 9.0.1.1.1 - PRODUCTIONEXPORT FILE CREATED BY EXPORT:V09.00.01 VIA CONVENTIONAL PATHIMPORT DONE IN WE8MSWIN1252 CHARACTER SET AND AL16UTF16 NCHAR CHARACTER SETIMPORT SERVER USES CL8MSWIN1251 CHARACTER SET (POSSIBLE CHARSET CONVERSION). IMPORTING SCOTTS OBJECTS INTO SCOTT. . IMPORTING TABLE "EMP" 10 ROWS IMPORTEDIMPORT 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
  • 7. Can I do Incremental Exports? Backup and Recovery TipsC:>IMP SYSTEM/MANAGER TABLES=EMP IGNORE=Y FILE=EXPMON.DAT FROMUSER=SCOTTIMPORT: 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 - PRODUCTIONWITH THE PARTITIONING OPTIONJSERVER RELEASE 9.0.1.1.1 - PRODUCTIONEXPORT FILE CREATED BY EXPORT:V09.00.01 VIA CONVENTIONAL PATHIMPORT DONE IN WE8MSWIN1252 CHARACTER SET AND AL16UTF16 NCHAR CHARACTER SETIMPORT SERVER USES CL8MSWIN1251 CHARACTER SET (POSSIBLE CHARSET CONVERSION). IMPORTING SCOTTS OBJECTS INTO SCOTT. . IMPORTING TABLE "EMP"IMP-00019: ROW REJECTED DUE TO ORACLE ERROR 1IMP-00003: ORACLE ERROR 1 ENCOUNTEREDORA-00001: UNIQUE CONSTRAINT (SCOTT.EMP_PK) VIOLATEDCOLUMN 1 2COLUMN 2 WOLFGANG MOZARTCOLUMN 3 1COLUMN 4 41COLUMN 5 1450IMP-00019: ROW REJECTED DUE TO ORACLE ERROR 1IMP-00003: ORACLE ERROR 1 ENCOUNTEREDORA-00001: UNIQUE CONSTRAINT (SCOTT.EMP_PK) VIOLATED[SNIP MUCH MORE OF THE SAME…]COLUMN 5 1307IMP-00019: ROW REJECTED DUE TO ORACLE ERROR 1IMP-00003: ORACLE ERROR 1 ENCOUNTEREDORA-00001: UNIQUE CONSTRAINT (SCOTT.EMP_PK) VIOLATEDCOLUMN 1 1COLUMN 2 BENJAMIN BRITTENCOLUMN 3COLUMN 4 50COLUMN 5 3000 1 ROWS IMPORTEDIMPORT 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:Copyright © Howard Rogers 2001 15/11/2001 Page 7 of 10
  • 8. Can I do Incremental Exports? Backup and Recovery TipsSQL> 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 95011 ROWS SELECTED.…Britten is still there with his old salary –the update is ignored. Mr. Rachmaninov has beeninserted –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 thenature of the export, means that the approach of ‘import from full and applyincrementals’ is completely wrong. All you need do is import from the last export takenthat 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=SCOTTIMPORT: 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 - PRODUCTIONWITH THE PARTITIONING OPTIONJSERVER RELEASE 9.0.1.1.1 - PRODUCTIONEXPORT FILE CREATED BY EXPORT:V09.00.01 VIA CONVENTIONAL PATHIMPORT DONE IN WE8MSWIN1252 CHARACTER SET AND AL16UTF16 NCHAR CHARACTER SETIMPORT SERVER USES CL8MSWIN1251 CHARACTER SET (POSSIBLE CHARSET CONVERSION). IMPORTING SCOTTS OBJECTS INTO SCOTT. . IMPORTING TABLE "EMP" 10 ROWS IMPORTEDIMPORT TERMINATED SUCCESSFULLY WITHOUT WARNINGS.Copyright © Howard Rogers 2001 15/11/2001 Page 8 of 10
  • 9. Can I do Incremental Exports? Backup and Recovery Tips…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 95010 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 aretherefore being accounted for.In summary, when it comes time to using incremental exports to recover, you start withthe 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 thatexports always export complete objects, not individual rows.Apart from remembering to do imports in what is perhaps a non-intuitive way, it alsomeans that you need to be extremely aware of what tables managed to get included inwhat exports –otherwise, you’ll find yourself running multiple imports against dump filesthat don’t include the relevant table, and wasting time in the process.Complete Database ImportsThings get rather worse when you try and import a complete database using incrementalexports. The order of events becomes critical, because you have to get the datadictionary 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, specifyingINCTYPE=SYSTEM as one of the import parameters. This gets users, object types, and so oncorrect, but doesn’t import any actual tables.Copyright © Howard Rogers 2001 15/11/2001 Page 9 of 10
  • 10. Can I do Incremental Exports? Backup and Recovery TipsNext, 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, againspecifying INCTYPE=RESTORE.Then you import all incremental export files made after the last cumulative export, yetagain specifying INCTYPE=RESTOREAnd allegedly that does the deed, with one tiny proviso: the Oracle documentation statesunequivocally that you should only perform this sort of restore when the database beingimported into has NO user tables whatsoever within it. That’s because the INCTYPEparameter can only be specified when you are performing a full database import, notspecific tables or specific schemas. The presence of any tables in the database as youattempt 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 tobe the normal mode of operation in the first place. That frees you up from worrying aboutwhich dump file to use as the basis of a restore, since you simply start with the lastcomplete 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=SYSTEMjust to get the data dictionary in shape. Even with that in mind, though, it does mean youcan perform restores without being intimately familiar with the contents of your variousdump files.ConclusionHaving said all of that, what are the benefits and costs associated with incrementalexports?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 tokeep excellent records about which tables got included in which export –then you can gostraight to the latest export known to contain the table you want. The alternative ‘rollforward’ technique (start with a complete, and apply all subsequent cumulatives andincrementals) requires a database with no existing tables to work relaibly, which makes itof rather specialised use. It also requires multiple import runs, with great care beingrequired to specify the correct INCTYPE each time.Frankly, the costs are high: imports become extremely fiddly, however you elect to dothem. And, for me, that means they will generally outweigh the benefits. So the realanswer to the question posed right at the beginning of this paper, “Can I do IncrementalExports?” is “Yes, but you probably shouldn’t bother”.Copyright © Howard Rogers 2001 15/11/2001 Page 10 of 10

×