Slow Restore of a Compressed Backup

Question

All,
I am seeing a strange behavior when restoring a compressed backup for standby duplication.
The target and auzillary database version is 11.1.0.6 Enterprise Edition
The size of the database uncompressed is 131.41G
The Size of the compressed Full Backup is 58.21G     
The Duplication script is as follows:
run {
SET NEWNAME FOR DATAFILE 1 TO '+DGROUPDATA1';
SET NEWNAME FOR DATAFILE 10 TO '+DGROUPDATA1';
SET NEWNAME FOR DATAFILE 100 TO '+DGROUPS1V1';
SET NEWNAME FOR DATAFILE 101 TO '+DGROUPS1V1';
SET NEWNAME FOR DATAFILE 102 TO '+DGROUPS1V1';
DUPLICATE TARGET DATABASE FOR STANDBY
NOFILENAMECHECK;
From the alert log on the standby during the recovery process I see that a 4GB file recovery takes a little more than an hour:
Full restore complete of datafile 66 to datafile copy +DGROUPRPRTRDATA1/mpstndby/datafile/reporter_data1.269.676544573.  Elapsed time: 1:03:45
Is there anyway to speed up the recovery process from a compressed backup?
Thanks,
Robert

Answer 1

It would seem that i have plenty of resources, but i think that i may have a bigger issue.
I am using defaults for filesperset and using just one channel.
The restore process is also failing to execute the final step of the duplication.
contents of Memory Script:
switch clone datafile all;
executing Memory Script
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN> **end-of-file**
RMAN>
so now not only do i have a slow restore but i have a restore that hasnt switched the files. So the database is in a very angry and confused state becasue it obviously doesnt know what the new names of the files are.
Thanks for your help to date