Critical Application Batch Performance

We have a critical application batch that runs daily and had a 7.5 hr window after which the application needs to come online. During the peak batch times the truncates are running very slow leading to slow down of the batch jobs quite considerably due to which the batch is going beyond the window.

Technical details:
Database version: 11.2.0.2
OS: HP-UX 11.31

The wait events that show up when the truncates are running are local write wait

enq: RO fast object reuse
enq: CR block range reuse ckpt
db file parallel write

The ASH reports show that the top sessions are those executing DMLs(insert, merge, update) and DDLs(Create/alter index & truncate). In addition to this it also shows that the blocking sessions are background wait events: CKPT and DBWR. Changes to DB configuration done with respect to addressing these issues are:

1) We have increased the DBWR processes to 2
2) Reduced the buffer cache size to 20G(from the original 30G)
3) Flushing the buffer cache before the batch begins in order to reduce the load on DBWR during the batch peak time
4) Set the parameter filessytem_io to SETALL(from none)
5) Tuned the EVA(SAN storage) to improve its performance - by distributing the loads evenly between the controllers, reducing the IO transfer block size, etc
6) Suggested using the reuse storage clause to improve truncate performance.

All of these have worked bring a semblance of control but the fact remains that the batch is generating more jobs(hence increasing data volume) over time due to it being the peak season. This causes an inevitable increase in the number of sessions all running DMLs and DDLs which are IO intensive operations.

Suggestions pending from our end:

1) Increase DBWR beyond 2. For this we need a H/W upgrade since we have maxed out the maximum number of DBWR that can be configured
2) Implementing asynchronous IO for DBWR which on HP-UX requires moving to raw disks. Hence have suggested using ASM.
3) Tuning the application to either reduce the IO generated or redistribute the jobs such that those with maximum loads don't run together

instead of truncating tables, can we rename the tables and delete them later . will this improve performance ?