Dumps and loads are disk IO intensive operations, with said IO operations taking place outside of the dataserver. Net result is you're usually having to look at OS and/or filesystem configurations that affect disk IO performance.
NOTE: If using compressed dumps then you'll also want to keep in mind that (un)compressing dump files requires cpu cycles, so an excessive number of stripes performing (un)compression activities could push host cpu usage to 100%, ymmv.
For some background info take a look at this thread ...
Dump database - performance tuning | SCN
... while the thread discusses the performance of performing a dump, the same principles apply to loads.
Generally speaking ...
- have your OS/disk-subsystem folks monitor IO service times on your database *and* dump devices
- don't use NFS mounted filesystems (as then you'll have to put up with network latency)
- if database and/or dump devices are on filesystems, consider disabling filesystem journaling
FWIW, 6 hours to dump a 1.2TB db sounds pretty slow too, ie, that's only ~55MB/sec.