>> but that just reinforces my point about the parameter’s lack of purpose. I disagree, the parameter has purpose. If you have a server with many databaes on it, it serves to prevent one database from mindlessly filling up a shared file system thus preventing all the databases from archiving and as a result bringing the whole world to a screatching halt. I would agree that an option to IGNORE or some such thing would be nice. RF Robert G. Freeman Author: OCP: Oracle Database 11g Administrator Certified Professional Study Guide (Sybex) Oracle Database 11g New Features (Oracle Press) Portable DBA: Oracle (Oracle Press) Oracle Database 10g New Features (Oracle Press) Oracle9i RMAN Backup and Recovery (Oracle Press) Oracle9i New Features (Oracle Press) Other various titles out of print now... Blog: http://robertgfreeman.blogspot.com The LDS Church is looking for DBA's. You do have to be a Church member in good standing. A lot of kind people write me, concerned I may be breaking the law by saying you have to be a Church member. It's legal I promise! :-) ________________________________ From: Michael Fontana <mfontana@xxxxxxxxxxx> To: "Allen, Brandon" <Brandon.Allen@xxxxxxxxxxx> Cc: oracle-l@xxxxxxxxxxxxx Sent: Friday, December 19, 2008 2:19:27 PM Subject: RE: db_recovery_file_dest_size ________________________________ From:Allen, Brandon [mailto:Brandon.Allen@xxxxxxxxxxx] Sent: Friday, December 19, 2008 2:36 PM To: mfontana@xxxxxxxxxxx; oracle-l@xxxxxxxxxxxxx Subject: RE: db_recovery_file_dest_size I forgot to mention another option – just don’t use the flash recovery area at all. I agree, but then there’s this dogma, written in the manual: “Use of the flash recovery area is strongly recommended.” I have no problem using it, and I can certainly code the size value to an ungodly number and move on, but that just reinforces my point about the parameter’s lack of purpose. How about just making the size parameter optional, instead of oracle generating an error if it’s not set?