I like Toons' suggestion to do it by schema with a log on trigger. That should allow you to make use of it when indicated, especially with configurable off the shelf (COTS) application suites where you often cannot change the code or the ramifications of changing the code are unbounded. The capability is nice. The side effects of the change from not having a recycle bin to having a recycle bin are manifold and unpredictable in the general case. A lot more is involved in this consideration than just sticking a purge keyword on the end of a few drop statements. mwf From: oracle-l-bounce@xxxxxxxxxxxxx [mailto:oracle-l-bounce@xxxxxxxxxxxxx] On Behalf Of Michael McMullen Sent: Tuesday, April 19, 2011 10:17 AM To: Oracle-L@xxxxxxxxxxxxx Subject: RE: disable recyclebin? What's the push? People don't like to see all the BIN$ tables in a tool? I guess my argument would be to the user that they have the option of not using the recyclebin by using purge so why should I disable for the entire db. They have the option to turn it off/on as they seem fit which seems pretty good to me. _____ From: oracle-l-bounce@xxxxxxxxxxxxx [mailto:oracle-l-bounce@xxxxxxxxxxxxx] On Behalf Of TESTAJ3@xxxxxxxxxxxxxx Sent: Tuesday, April 19, 2011 9:55 AM To: Oracle-L@xxxxxxxxxxxxx Subject: disable recyclebin? I'm getting push to disable the recyclebin on a 10.2.0.4 database? I'm pushing back that its not a good idea to disable it for the entire database but to disable for the session or do a drop table <table_name> purge instead. Your thoughts? thanks, joe _______________________________________ Joe Testa, Oracle Certified Professional Senior Engineering & Administration Lead (Work) 614-677-1668 (Cell) 614-312-6715