Load strategy 6 TB data , oracle to oracle

Question

Hi,
What’s the quickest way to load multiple terabytes worth of data from 10+ smaller oracle db’s (v11.2) into one bigger oracle db (v11.2, 3node rac) on Linux?
Thank you

Answer 1

Hi,
thanks for the info, I can deal with the tablespace name, basically i dont mind using unique naming for tbl spaces ..., I'm also happy to use unique >table names but the required end result is to join all those data together and append to one bigger table for example >customer1,customer2customer2... all to be appended to customer table and order1,order2,order3 all to be appended to the main order table in >the target db .. hope this makes sense ..The requirement would be that the tables be the same geometry. If so then your imports would look like this:
Let's say you ave 3 customer dump files.
cust1.dmp
cust2.dmp
cust3.dmp
and all of them have tables user1.orders
Then the first impdp would be normal:
impdp user1/password dumpfile=cust1.dmp ...
The rest of the impdp commands would have this added
table_exists_action=append
This will cause data to be appended to existing tables if they exist. If the tables do not exist, then the table will be created and the data will be inserted into that table.
If the table names changed or if the schemas changed, then you will need to add some remap transforms to the impdp command:
Let's say cust1.dmp has user1.orders and cust2.dmp has user2.orders
You would want to add:
remap_schema=user2:user1
to the second impdp (along with the table_exists_action=append) to make the data from user2.orders be imported into user1.orders.
I also have club field but that doesnt seem to be a problemNot sure what this club field means.
(■Limitation: The tablespaces to be transported contain no columns with the CLOB data type, or the source and the target database character sets are both single-byte or both multibyte.).
should I stil consider the TTS? or its not suitable for my case anymore?Appending data to an existing table is only available for non-tts jobs. For tts jobs, the tables would have to be uinque. If they are not unique you would have to use the remap_table or remap_schema to make them unique.
i say this because my ideal strategy has to be the fastest one ? and unsure
about how long it might take to re-organize data in the main db for example appending all to one table ...I'm not sure if the transportable move along with the appending of data would be faster than just running each impdp without transportable while having datapump append the data for you. If you can use the parallel parameter of datapump, that will help move the data faster.
however my main db is going to be partitioned so when it comes to doing select/insert it will only insert into one partition of customer or order >table. in another word every tablespace ( or group of tablespaces from smaller db) will have data related to one partition ..If each customer is going to be it's own partition in a table, I would think that you could import all of the tables as individual tables and then use exchange partition to have the customer flat table exchanged into your partitioned table. If this is the case, then transportable would probably be your fastest approach:
Above you said that each database has the same tables, are they just named the same, or do they have the same geometry? There may be different ways of doing this depending on what version your databases are. Can you please list the versions of the databases that you are coming from and going to?
Thanks
Dean