Re: Suggestions for improving the 7.x OnLine Engine installation and configuration
Posted in 1997
David Williams wrote: > > 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. > Not a good enough answer for lil o me. If Informix has the best engine then I expect them to have the best install to go with it. There should be at the bare minimum what I see coming with Solaris, to configure disks. I should be able to configure dbspaces dynamically on the initial install, and ongoing, not unlike the OWGS version. I might add this is not a bad interface, it needs to get over to UNIX. > >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. > Does not compute. I should be able to configure these three items independent of each other. They may work <WITH> each other but they should not prevent any one of the others from working. Each should stand on its' own merit. We insist on this for object orientated programming, why not for the program operation itself????? It should not matter whether you have less than 2 GB of data or more. The idea that core system processes are occupying the same data space as user data space is disturbing, and thus why you would want to move the logs to their own spaces. If this wasn't necessary then why did Informix write about how to do it in the manual? Why introduce a problem in the first place? Re-design the install to automatically create a logdbs and a physdb space along with the rootdbs space. Then have the logical logs write to their own dbspace, and the physical logs write to their own dbspace, and end of story. Then the DBA doesn't have to finish the install for Informix. > >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). > Huh? The engine software should be micro-kernel based, and operate on its' own merit, independent of ANY other software. The whole essence of API based software is modular in it's orientation, there is no reason why the engine software should EVER suffer at the hands of tools or network software installation. The current installation is purely amateur and unacceptable. But thanks for this tidbit. How come this information is not documented by Informix, and you somehow learned about it? Shouldn't the misconfiguration error-out without crashing the engine? > >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. > OK, so what's your point? I'm still asking why the Informix install is pisspoor, and needs a bit more sophistication. See, I suffer from this idea that if there's a better way, why aren't we doing it? We would probably find Informix admitting to the lack-luster install process if asked. All I'm trying to say, is, the install sucks. I could probably do a better install program if given the task. > > > >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. Huh? I'm not talking about UNIX. I'm talking about Informix. Haven't you seen pkgadd? > > 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...) > If you have your own tree of stuff, you can certainly put things anywhere you want. I'm going to QUESTION EVERYTHING. It's my nature. I think default values should be correct enough to eliminate more work later down the line. If you can create $INFORMIXDIR/etc, what's to stop you from creating $INFORMIXDIR/logs? Or any other directory??? > > 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. > When is the last time you did an Informix install? If you were to specify the top of the tree, then everything else follows it. This is not rocket science. > >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 co