Yes, it seems you've got it, at least about the export of the indexes. BTW, if you think a bit about what is stored inside indexes, you'll easily understand that physicaly exporting the actual contents of the indexes would be totaly ludicrous. Indexes (at least B*tree, which are the most common ones) contain key values and the ROWIDs of the corresponding table rows. So what would be the point to import those ROWIDS into the new database when literaly each and every row in the imported table has new ROWID, totaly different from the one it had in the old table? If those indexes would indeed be physicaly exported, they would have been in UNUSABLE state after the import. So the only option with indexes after the import is to be created from scratch. And for this nothing else than index definition DDL command has to be exported.
Originally posted by DcsoBob
Have I got it now?
If you realy want to save time with export (although I would be much more concentrated on the time spend during the import, as some other have already suggested), then try to get the optimal setting of BUFFER parameter. Or even better, check if the DIRECT PATH export is possible in your situation - using this option together with proper RECORDLENGTH parameter will definitely spead up the export process more than anything else.
Last edited by jmodic; 02-04-2003 at 02:43 PM.
ASCII a stupid question, get a stupid ANSI
24 hours in a day .... 24 beer in a case .... coincidence?
LOL Marist, I didn't think anyone would remember that thread. The answer is --pretty much. I still do the exports, but not near as many. And with the migration, I will be using RMAN to setup my backup and recover scheme. I will also be implementing Data Guard once I have OEM/OMS and RMAN up and running.
Our vendor is responsible under the contract for doing the migration with me sitting in his backpocket. He and I have already done this migration once for our testing environment. The only reason the vendor is doing the migraiton is because of a redesign to the schema, addition of new tables, alteration of current tables, data conversion, etc. A straight up migration I would have handled myself.
But, I will use the cloning method to build my backup box. But I will use the new box to supply the clone. And probably use RMAN to clone it. Just lots of options to play with.
I have pondered the DIRECT=Y method and have tested export speeds. It cuts the export down to 15mins or less. However, my current workload and priorities have not allowed me testing and play time for the import. Cant scarp and rebuild my dev box when we are using it for dev and testing against the current app. Not enough boxes in our shop...sigh.
Jmodic, if I had stopped typing long enough to actually think about the indexes a little more, I would have realized what the index really was and why importing them is useless.
Thanks for all help and input. I love this forum.
I just love a happy ending.
I remember when this place was cool.
ROFL...Your killing me....
Click Here to Expand Forum to Full Width