Skip to Main Content

Breadcrumb

Question and Answer

Tom Kyte

Thanks for the question, Narendra.

Asked: September 26, 2000 - 9:34 am UTC

Last updated: November 29, 2012 - 6:46 am UTC

Version: 7.3.2.2.1

Viewed 10K+ times! This question is

You Asked

Hi Tom,
Please explain more about Incremental ,cumulative Export and then
Import the same with suitable example.
When use incremental Import ,how import will import data when existing table contain the previous data.Is the duplicat rows are inserted or only updated and new rows will insert.
How can I update my secondary database on second machine with this utility with mininmum time and effort.
Thanks
NP

and Tom said...

To use incremental or cumulative exports, you must start with a complete export. After that you can do incremental exports -- these will export any TABLE that has been modified since the last complete, incremental or cumulative export. It exports the entire table -- not just changed rows.

A cumulative export will export all tables that have been modified since the last complete or cumulative export -- you can now discard all intervening incremental backups you have done.

Lets say you do the following:

o a complete database export (should use consistent=y). That will generate an export with everything in it.

o you add a row to tables T1, T2 and T3.

o you do an incremental export. That will export T1, T2, and T3 only.

o you add a row to T3, T4 and T5

o you do an incremental export. That will export T3, T4, and T5.

Now, you can take that full complete export and apply it to an empty database -- then apply the first incremental. That will drop and recreate (and populate) T1..T3. Apply the next incremental and it'll do the same for T3..T5.

It is important to note that, since importing an incremental export file imports new versions of existing objects, existing objects are dropped before new ones are imported. This behavior differs from a normal import. During a normal import, objects are not dropped and an error is generated if the object already exists.

You may find that taking a HOT backup of the source database and restoring that and doing a point in time recovery may be faster if the volumne of changed data is high in the source database. Rather then dropping and recreating the table (and all indexes) -- just copy the datafiles after putting the database into hot backup mode and apply some logs to the copy to get it going.



Rating

  (10 ratings)

Is this answer out of date? If it is, please let us know via a Comment

Comments

cumulative importing

Lakshmi Sai Kumar, July 05, 2004 - 3:34 am UTC

To import cumulative backup from tape backup cumulative export to another machine which is located in other location, steps is needed.

Please tell me steps to take cumulative import.
what are steps to be followed in export and import



Tom Kyte
July 05, 2004 - 10:03 am UTC

short of reading the documentation (to discover cumulative exp/imp isn't really used.....)

You do realize a cumulative export exports any table (the entire table) that had a single row modified. It is not very *useful*.


but, the docs do have the steps -- the server utilities guide is the one you want to read.

(or read the original answer which lists them as well i suppose.

Example for increamental, Cumulative Exports

Sri, September 16, 2004 - 3:16 am UTC

1.how to define multiple incremental or cumulative backups

For the full back we define full=y
how do we specify the value for the inctype = ? if it is incremental backup or cumulative backup.

Actually what could be the value for the inctype = ?

How do we determine the multiple increamental or cumulative backups.


Tom Kyte
September 16, 2004 - 8:06 am UTC

do not even remotely consider use EXP as a "backup" tool.


incremental exports is a deprecated feature. besides, it exports any table that has had one bit modified in it.

It might have made sense in 1984. In 2004, it really doesn't.


Use RMAN and make proper, real, useful backups of your database.

Logical schema backup

Steve, October 21, 2004 - 9:22 am UTC

We are currently running 8.1.7. Ever since we created our first database under V6, we've always run an automated full export during off-hours. We're not a 24x7 shop and we have the storage capacity to keep two weeks worth of exports on line. We use these as a logical backup of schema objects and data. We also do cold physical backups of the entire database and archived log files each night.
Our exports are ultimately used most often for recovery of stored pl/sql objects--someone dropped or replaced one by accident and, regardless of how good our configuration management software is, we still want to see exactly what was stored "in the database" before the mishap.

We're investigating an upgrade to 9i or 10g and are currently trying to figure out what will replace our exports for this type of backup. I've begun reading the RMAN documentation and have not yet found a way to "mine" and recover individual schema objects using RMAN capabilities. Can you point me in the right direction?

Tom Kyte
October 21, 2004 - 2:26 pm UTC

exp/imp still exist?

Left off an important piece of information...

Steve, October 21, 2004 - 4:46 pm UTC

Our exports must be incremental because of their size. I understand that incremental exports will no longer exist...

Tom Kyte
October 22, 2004 - 3:15 pm UTC

you do understand that INCREMENTAL means "pull any table that had one single bit changed in them" -- eg, in most normal databases, it would be the entire thing.

For you -- why not just go "rows=n"? get the structures.

(you could use a DDL trigger to version your stored procedures and all as well, so you always have the last "N" versions -- i've examples of doing that on this site as well)

Reg Incremental Backup

A Reader, July 12, 2005 - 9:29 am UTC

Hi Tom,

Please explain the difference between incremental export and incremental backup using rman.

Thanks.

Tom Kyte
July 12, 2005 - 5:15 pm UTC

incremental exports don't really exist anymore (deprecated) and export is not a backup tool whereas rman is

so, stick with rman.

incremental export - best solution

whizkid420, October 24, 2005 - 7:47 am UTC

Tom,

we have this requirement. would really appreciate if you could help out on this one. we have a couple of activities scheduled on the database side.

1. DB upgrade from 8.1.7 to 9.2.0.5
2. Application upgrade & configuration (DB side)

Application upgrade would require couple of weeks. We cant afford to take such a big downtime. Our action plan is as below

-> Create a new 9.2.0.5 oracle home
-> take an export of the existing db and import in the 9205 (DB would be upgraded)
-> open the old 817 database to the users for normal activity
-> start the application upgrade on the 9205 database.
-> import the changed rows of 817 database into 9205 database.

Incremental type export is removed in 9205. Could you list out the ways though which we can accomplish the above?

thanks a lot,



Tom Kyte
October 24, 2005 - 11:37 am UTC

incremental export NEVER DID JUST ROWS - it would export the entire table if one bit in one column from one row was changed.


what does the application upgrade "entail" here - what would you be doing in that database (and why would it take "WEEKS??????" )

incremental

whizkid, October 24, 2005 - 12:18 pm UTC

I know incremental export would export the entire table, but it's ok in our case as the data is not huge.

we are upgrading to the next version of the application for the client. it requires changes front end changes and the changes to the objects... it's an upgrade of the existing application and we are also deploying a new module.. the developers and the deployment team have said that it would take that much time for upgradation, deployment and configuration.. changes in the database would mean running some scripts which would add new objects, modify existing ones, add some data in the tables etc..



Tom Kyte
October 24, 2005 - 1:07 pm UTC

if the "objects" (assuming tables and such) are changing, then you would need a data migration program wouldn't you?

It would see an upgrade script shouldn't take more than a little bit to actually run (I mean, you have upgraded a database in the past - we create new objects, add columns etc etc etc).

They should be able to create an upgrade script that works with "version 1 database" and turns it into version 2 - and it shouldn't take weeks to run.

web application testing

ian gallacher, October 24, 2005 - 3:42 pm UTC

Just to say on previous topic "web application testing"

Jump to toms latest goes nowhere and when scroll down get to
June 21 , 2004 and then nothing !

Ian

whizkid, October 25, 2005 - 12:06 am UTC

Thanks Tom.. but the upgrade is not just running scripts.. there is a seperate configurator application to attach the new modules to the exisiting application.. and for each product we have configure it.. it does take time.. and during this time we cannot keep the production down.. so we decided to take a copy of production as of a time and create another database.. carry on the migration on this database whereas the original production is accessible to users.. merge both the db's once the activity is complete..

is there way we can achieve this?? using rman or some other method?

Tom Kyte
October 25, 2005 - 1:37 am UTC

I don't see how this would work. You have different structures by definition. Your tables do not match one to one, you need a mapping function in between don't you (a transformation)

Still seems like an upgrade that takes "weeks" is called "software development" and you would get it right in the weeks and create a reproducible upgrade process from that (eg: the upgrade doesn't take weeks, the development does - but then you would have developed a process that can be run "in much less than weeks")


trying to syncronize these systems is going to require "some large amount of development" itself - it is non-trivial.

Incremental ,cumulative Export

Nikhil Mehta, November 22, 2012 - 8:11 am UTC

Can we use Incremental ,cumulative Export for 11gR2 database. As we need to perform cross platform data migration from 10gRAC (AIX) environment to 11gRAC (LINUX) with no downtime. Please advise.

Regards,
Nikhil Mehta.
Tom Kyte
November 29, 2012 - 6:46 am UTC

incremental exports are useless. they'll export any table (the entire table, all rows) that was modified.

update a row - export the entire table.



streams
golden gate

they are your tools for "near zero downtime" migration.