I am glad you understood and taking the right course. For a faster export/import, we had the same dilemma. here are some recommendations.
- Of-course try it in non-prod first but I will recommend using a server which has same performance as production DB server.
- more CPU cores in the DB server, faster the export import will be.
- Also it is a very I/O intensive activity, I will suggest using FC drives, also create multiple drives and get your storage team to dedicate as much storage performance as possible, especially in production. By adjusting the CPU and Storage I/O, you will get your optimal speed. Understand that one export parallel process per CPU core so you can actually export a lot of tables in parallel if you have lot of CPU cores in the DB server but then the I/O starts becoming the bottleneck if your storage is not very good.
- If you can spare two servers, you can do a parallel export import, it will reduce your downtime to half.
- If you have really large tables, it will increase your total export/import time. So you will have to split the tables. Use migration monitor for that.
When we did our ECC system export import, it was over 3TB in size, after it was reduced to 700. Our performance improved to 3-4ms/op from something which was over 50 on the larger datafiles. Total time for export/import of a 3.1TB system was less than 11 hours. + another 2-3 for other system copy steps. Though it took atleast 4-5 full cycle tries to reach the magic number.
I will recommend at-least 16+ datafiles. If you DB server has more dedicated CPU cores to your instance, then add more. Plan the number of datafiles in multiple of the luns. so if you are distributing the datafiles to 5 drives, have in the multiples of 5 and so on. This to make sure number of datafiles in each drive/lun is the same.
~Yogesh