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
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.
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?
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...
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.
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,
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..
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?
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.
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.