Re: Reply: temp table locking
Posted in 1993
Topics: Storage & Space Management, Server Administration
Bill Foote writes: >Huh? I can understand not setting it to /tmp on a system where the root >filesystem isn't very big. Is there a reason to specifically set it to >something different for each user? Personally, I can't see anything >wrong with everybody using /usr/tmp (or /usr2/tmp, or whatever). Neither can I, as long as you don't care that all the temp files from all the users get mixed in one big bag, or that someone (there's always the new system administrator) removes all the files in /usr/tmp to make room for something else. It could be that there is a disk allocation factor involved in having it this way and no other. I can only find one good reason for each user having DBTEMP set to their own $HOME/tmp, and it doesn't do anything for anyone except the database or system administrator who has to chase down problems when they occur. The rest should be obvious. If it isn't, then it doesn't apply; let your system administrator worry about those details. (I don't mean to be unfriendly with this comment, it's just another way to say, if you don't care, don't bother, be happy.) >"On any sane system" (well, on many sane systems) the user directories >for most people don't contain very much, and probably aren't on a very >big partition. I agree that most systems limit user disk space to small amounts. This has to be taken into account when setting DBTEMP, which is why I mention that you shouldn't be pointing to a small disk space. Personally, because I do development work, my home space has to be about 20 megabytes, and that's a bit too slim sometimes. That's why most of my work is done at home on 250 megabytes, and that isn't enough for really serious database testing. One set of transactions alone manages an 80 megabyte table. As an end note, database administration means more than plug 'n play. Newcomers to Informix or any computerized database (considering that there are still lots of paper factories out there), including long-lived Data Processing Managers, are quite frequently amazed at how many little things one has to be on top of to keep the system running. That you ask about the ins and outs of DBTEMP tells me you have never had to be concerned with it. Count yourself lucky. I've seen three related problems at one site in one year. The time it takes to track them down and correct them is worth knowing in advance how to prevent such problems. ------------------------------------------------------------------ John R. Carter, Sr. 71553.535@compuserve.com Programmer/Analyst for Informix products ------------------------------------------------------------------