Nelson, I don't know if it's true that it's safe to let the system merely try - b/c I know that it's not supported. So, either it will try (possibly wasting time in the failed effort repeatedly) - or even worse it will think it can use it, and start trashing files.
If you need more I/O however, there are things you can do. Definitely you can support more than one DBWriter - no matter how small your system is. I generally allocate one or so per filesystem - but try not to exceed number of procs. But, the real answer is to start up the statspack, get some baseline, then start changing the number of db writers you have and see if the delays from writes start coming down. Your ability to support a 'bunch' of db writers really depends on how much bandwidth you've got to the storage system (in terms of concurrency). Can your storage system support lots of concurrent writes ? Then it's time to start increasing and measuring.
Another thing I like to do to increase my ability to write thing concurrently is to pre-allocate my tablespaces across many files, so that as data grows - it grows across the files in the tablespace - giving me some approximation of concurrency - at times. So, if you need a new file added to your tablespace (and say it's a hot one), don't just add a 2G file - why not add 4 512MB files or even 8 256M B files instead (Check that your nfile parameter can handle it)? Even better, if this tablespace is really hit hard - why not put those files across several mount points and interleave them? This will give you a lot of disk mechs doing your bidding for you. You can watch as the data grows over time in the files, it will be pretty evenly spread.
Keep in mind the load your storage system can handle - on direct attached I/O with ultra-SCSI I'll often use a db_writer_processes value of 4 or 6 (depending on how many disks/controllers/cache I'm using), but on a system with large enterprise storage - I'll use a value of 16 or 24.
As long as my total I/O doesn't go red-line on me, and my statspack shows better response times on delivering I/O and no ugly adverse effects in the rest of the system - I'll keep pushing db_writers until I'm happy with it.
Also, you can use one DB_Writer with a bunch of I/O slaves. I've not seen when using synchronous I/O myself on how that's better, or worse for that matter. In my researching papers, etc on the topic, I've seen how I/O slaves is MUCH better when doing asynchronous I/O in raw partitions. Keep in mind that when using multiple I/O slaves - you'll only have one DB writer ... hmmm ... is that what you have now??? If so, this is all a non-discussion...
You could do either - increase db-writers or increase with I/O slaves - either one will get you there. But, measure and test your way (or at least track) through it. Statspack reporting will help you figure it out.
We are the people our parents warned us about --Jimmy Buffett
