Jonathan, I've been coming to the same conclusion as you have. In all of my databases that I have ever worked on, there are only a select set of Oracle params that are really required. And with space management the way it is, a lot of the 'create table' params are really not needed for the low-to-mid-end applications. While I personally always use pctfree and pctused, what you said makes sense. Consistency is more important to me (in creating the tables) than the details of each table. If all tables are created the same, then, at worse, you will use more space in storing data than you could if you tuned the parameters (like - pctfree/pctused 10/40 uses more space per table than 10/90). But does this really matter? In a high-end database, it might. But in a smaller application with only a couple of hundred users and, say, less than half-a-gig of total data, I'd say that tuning these params are only playing in the margins of throughput.
And I think a condensed documentation set is a great idea. I wonder if there is a market for it? Tom Mercadante Oracle Certified Professional -----Original Message----- Sent: Thursday, December 11, 2003 8:25 AM To: Multiple recipients of list ORACLE-L Thursday, December 11, 2003, 6:39:26 AM, Richard Foote ([EMAIL PROTECTED]) wrote: RF> a.. What's wrong with the following piece of expert analysis ? I don't know what's wrong with this "analysis". There's not much really there. The claim is that it's bad not to be able to specify PCTFREE, but there's no real backup to that claim, no testing to prove the point, etc. Not sure I want to admit this publicly, but I don't recall ever needing to use PCTFREE. I know what it does, and I've played around with it a bit, but in production I always got along just fine with the default setting. I told this to a data warehousing person recently, and he was aghast, as he (apparently) uses PCTFREE often. But I have not worked on such huge databases, and maybe that's why I've never needed it. Bringing this back to automatic space management, it's my opinion that such features are targeted towards the "low end" (for lack of a better term, sorry) in which defaults work just fine. I'd guess that there's a class of databases for which the default PCTFREE setting is good-enough, and for which the automatic space management feature is good-enough, and for which automatic extent management is good-enough, etc. One of the things I've wondered about lately, is how to characterize the sort of database for which all the automatic features and the defaults are fine. Related to all this, as complicated as Oracle *can* be, I'm close to convinced that it's possible to define a greatly simplified database management regime. Work within a certain box, and you can ignore much of the complexity. I can even envision a user-manual targeted specifically at that box. Such a manual, for example, would show a simplified version of CREATE TABLE that omitted such things as PCTFREE, PCTUSED, etc. I haven't quite figured out yet how to define that box and how to characterize the sort of environment to which it applies. I once worked for a client who had a 5-10 gigabyte database with in the neighborhood of a dozen users. What they needed to know about managing Oracle would have fit into a really small book. Oracle is on to something with all the automatic features, but they need to present that feature set differently. Right now you get a database, you get told it can do all these automatic things (space mgmt, extent mgmt, SGA mgmt), but then you get pointed to this HUGE manual set that you need to wade through before you can begin to understand the automatic features. Maybe I'm wrong here, but I don't believe Oracle has put together the simplified DBA manual yet, and perhaps maybe they should. What do you think? Should Oracle define the box and write a manual for customers who want to live within that box? Best regards, Jonathan Gennick --- Brighten the corner where you are http://Gennick.com * 906.387.1698 * mailto:[EMAIL PROTECTED] Join the Oracle-article list and receive one article on Oracle technologies per month by email. To join, visit http://four.pairlist.net/mailman/listinfo/oracle-article, or send email to [EMAIL PROTECTED] and include the word "subscribe" in either the subject or body. -- Please see the official ORACLE-L FAQ: http://www.orafaq.net -- Author: Jonathan Gennick INET: [EMAIL PROTECTED] Fat City Network Services -- 858-538-5051 http://www.fatcity.com San Diego, California -- Mailing list and web hosting services --------------------------------------------------------------------- To REMOVE yourself from this mailing list, send an E-Mail message to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L (or the name of mailing list you want to be removed from). You may also send the HELP command for other information (like subscribing). -- Please see the official ORACLE-L FAQ: http://www.orafaq.net -- Author: Mercadante, Thomas F INET: [EMAIL PROTECTED] Fat City Network Services -- 858-538-5051 http://www.fatcity.com San Diego, California -- Mailing list and web hosting services --------------------------------------------------------------------- To REMOVE yourself from this mailing list, send an E-Mail message to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L (or the name of mailing list you want to be removed from). You may also send the HELP command for other information (like subscribing).
