Re: Suggestions for improving the 7.x OnLine Engine installation and configuration

In article <3337679E.13FC@mindspring.com>, Tim Schaefer <tschaefe@mindspring.com> writes >Well, I think the biggest impression I have from the install is the >"right of passage" one goes through, in order to install the software. >Maybe it's intentionally a bad install to help keep the consulting >market going? I mean this whole idea of having to set up the physical >and logical logs is abit absurd. >> I << have to move the logical >logs out of the root dbspace? Why put them there in the first place? I case you only have one dbspace - small systems run from one dbspace on one disk. >And the physical logs. I mean why can't this be done at the outset? Same again. >HELLO! And what of this TEN business? ( tools - engine - network ) >This stuff was all cute early on in the romantic phase of Informix >software, but does it need to persist like some sort of twisted >tradition? > To handle users who have < 2Gb of data and few users running against the system. >I am developing my article on these premises: > >1. If the install is acceptable, then why do so many people have so > many problems with it? Why can't the distribution change to make > it easier to install. What difference should the order of the > install make? Tools Engine Network. How about we revise the > damn directory structure to make things so this doesn't matter? But libaries get shared between them (communication libaries). The engine always has the latest verison (the one with the most bugfixes/ performance enhancements). > Please don't give me romantic notions of how we did it in the old > days. The old days show me some really silly sh**. > >2. If you have good software, this should reduce the need for a help > desk. To rave about your customer service is one thing, but ask > yourself if the need for more help desk people isn't really an > indication that the software is not being properly distributed. > ( Yes, Oracle has the same problems, and so do other companies. ) > And what about the techlink site? When's the last time somebody > did some serious design on <that> mess? > >3. If the configuration is acceptable, then why do so many people > have problems with it? Is <this> an accurate question? Yes - the answer is that Online has to be complex to handle very different usage requiremnets. It has to handle everything from 1 user with 100Mb of data to 2000 users all doing short transactions with 100 Gb of data to 10 users all quering on 600Gb of data. To handle all these requirements Online needs to be highly configurable. Also it runs on UNIX where there is no standard GUI (don't mention X-windows, I have a client who ONLY has Wyse 60 terminals....). UNIX has security so you have to setup permissions on chunks... UNIX handles disk configuration poorly - no standard place to store partition info and no standard device names. You can even use the same area of disk twice with UNIX (overlapping partitions ARE allowed by the fdisk command on Solaris 2.5.1 - I did it briefly when repartitioning a disk (the quickest way was to change each partition [1-6] to be where I wanting it). UNIX does not removed shared memory segments/ semaphores when they are no longer used... It's mainly down to the OS rather than Informix. > >4. If the configuration and installation are <unacceptable> then why > does Informix continue to offer products that are not substantially > improved over the last release? Why hasn't the directory structure Because of UNIX limitations. > changed to show improvement? Did we put any thought into the idea > that log-files shouldn't go into the software distribution directory? Where else do you default them to when you can't be sure of what other directories exist (Solaris has /opt and /home be default, SCO UNIX does not...) > C'mon folks, this is not only sloppy, it's just L A Z Y. > There is no other way when each UNIX has it's pwn directory structure. >5. Where does the line begin between installation technician and > dba? Don't get so smug that you can configure the living daylights > out of the 7.x product, and are now an elitist because you chased > down more "secrets" of the product than the next guy. It doesn't > make you a better DBA to be a configuration expert--you're a better > configuration expert but totally distracted from the core responsibility > of dba. A data base administrator is concerned with the data not the > install. By this I mean log management should be a function of the > vendor placing logs in separate dbspaces AT INSTALLATION not running > somebody through the ridiculous exersize of moving logs out of one You may not want more then one dbspace during initial installation. 6 months later you buy another disk (as we did) and create another dbspace...wouldn't you want to be able to move logs onto the new disk??? Don't assume everyone has >1 disk and the same deirectorys after UNIX has been installed - UNIX has no standard disk/directory layout. And evern if it did you can change the default (add /remove/resize partitions). > space into another. If you went through this you know how silly > this whole exersize is. It's almost a sick joke Informix plays > on their customers. And the documentation isn't very clear what the > hell you're doing either. Please don't document any more Informix. > You've given way too much documentation to this. > You really need a training course, Informix is a complex database with many features - it has to be to get the level of performance that can be needed from the hardware. >6. The ONCONFIG, while a neat idea, is really a bit rigid in what it > <CANNOT> do. There's no other way to configure the engine, this is > it. But I would think you should be able to bring the engine up, What else do you need. > and then phase in the shared memory on a controlled basis. The Memory requirements do up as more users use the system - what else do you expect. > current method usurps the system without really allowing the DBA > or anybody control over the engine. All you can do is clamp down > on the memory and hope to God it doesn't bomb. There should be > a micro-kernel start-up, and then the ability to ramp up memory. > It does initially only the resident/message portions of shared memory and an initial virtual portion are used. If more if required more virtual portions are added. >But hey, I could be wrong! > >:-) > >( Where's Sam Kineson when I need him oh! oh! ) > > >> However why not include checking of /etc/hosts and suggestions for >> entries in that file (should probably not be entered automatically). > >This is a good idea. However, it wouldn't be too much to ask for a >simple little example of the various types of sqlhost entries. Yes, >I've read the f***ing manuals. :-) ( correction, I continue READING >the manuals ) > > >> The tool should also check DNS, NIS or whatever t