Thanks to both of you for your replies. Pando, the goal is not so much to reduce the backup window; instead, we would like to have pieces of our database being backed up daily, such that everything is current to within one week. The various docs I have read seem to suggest that if I am using RMAN without setting up a flashback area (FRA), then I could just do traditional RMAN backups to a tape or disk location. However, the docs also seem to suggest that if you are using RMAN AND Flashback Features, all the files should be in one location (we cannot do that due to lack of space). I plucked the following quote from an Ebook by Mark Johnson:
"Typically, you should store in the FRA (Flash Recovery Area) one copy of your control file, one member of each on-line redo log group, and one copy of each archived redo log file. If you are using RMAN, then you should also set the backup destination to be the FRA: a full image copy of the database as well as any full and incremental backup sets should be stored here". I have found similar statements in Oracle notes. That is why I asked if it was possible to backup the database files to a place OTHER THAN the FRA.

Linux, you are correct that we have a bunch (over 20) large partitioned tables in our warehouse. Most are monthly with data going back as far as 1998, and a handful of others are daily partitions (60 to 90 day retentions) and a few are actually yearly partitions (just enough data to warrant partitions but not monthlies, also they are queried within a specific year). Our biggest table has 1.2 Billion rows, most of the others over 200 million, and the rest between 60 and 200 million. They NEVER archive off any of the monthly partitions, just the dailies.

This db is a hybrid Data Warehouse/DSS/low oltp database. Your point on making some of the partitioned tablespaces read-only has been vigorously discussed. We will likely do that with SOME of the tablespaces, maybe up to one third or one half. Our problem is that the business keeps re-inventing history.....that is, they come to us one day and tell us they want to update "n" number of rows in one of these tables because the original data received (from outside vendors) was incorrect. Sometimes, these update go back years. So we would have to go back and do all new backups just for those, and managing the entire mess could become daunting. Another thing that happens is that sometimes our largest tables are re-invented entirely. We have one table that is going to have the number of columns DOUBLED in the near future. It is our daily account history table and has 90 days of partitions online..last time I looked, it has 96 Million rows, over about 1.2M per partition. My boss wants me to consider redesigning it to be a mini "star schema" within the database, with one large fact table and a number of dimensions! So you can see, this database is in constant flux, and it would likely be difficult to keep all the backups straight to enable a quick recovery. I am the only DBA in this shop, with one other in training. So whatever solution I come up with needs to be as simple and efficient as possible, as I still have a lot of operational responsibilities and only so much bandwidth.

Thanks again for your responses.