Fwd: RE: oninit: Not enough room in ROOT DBspace. [4035

How about simply an ONCONFIG paramter, ONINITLOCKED 1, means oninit -i is disabled! One would have to edit the ONCONFIG file to remove or disable the parameter (ie set to zero) in order to purposely init an existing instance. AND, oninit itself could add the parameter, initialized to one, after initializing the new instance to prevent the fumble fingered from doing rerunning the wrong history command to restart the instance after other ONCONFIG changes. That's simple, relatively foolproof, and does not change the existing paradigm. Art S. Kagel ----- Original Message ----- From: Malcolm Wea.... <malcolm.iiug@btopenworld.com> At: 1/18 15:00 Guys and gals, How would it be if we asked IBM for a new feature to take the -i otion away from oninit and provide a separate command to do that? This accidental oninit -i has been the cause of too many catastrophes. Maybe we could call the new command onconceive or something similar that really implies new life. We could surely spend a few months discussing the possible names. Or maybe we could have other commands like onstart and onstop and get away from option letters altogether in these very vital areas. It's not rocket science - or is it? Regards Malcolm -----Original Message----- From: forum.subscriber@iiug.org [mailto:forum.subscriber@iiug.org] On Behalf Of mrh@panix.com Sent: 18 January 2005 16:13 To: ids@iiug.org Subject: Re: oninit: Not enough room in ROOT DBspace. [4032] I believe Anna said that the documentation says that you cannot adjust "LOGFILES" without a re-init.... which is also incorrect, but very different than just adding more logical logs. Anna, the LOGFILES parameter can be adjusted without a re-init. It only needs an engine bounce to take effect. Same goes for the LOGSIZE parameter. However only new logs will be created with the new size... exisiting logs will not be adjusted. If you wish to add new logs of a *different* size than LOGSIZE, you must use "onparams". If you wish to change your existing logs to a new size, you can add new logs of the new size, bounce the engine (making the new logs available for use), "onmode -l" until one of the new logs is selected, "onmode -f" to force a checkpoint and move the current log to the one selected, and the "onparams" to drop the old logs. (Caveat: This was the process under IDS 7*. It may have been streamlined under IDS 9*) That said, and with Martin's notes below, a general practice is to set a low value for PHYSFILE and LOGSIZE, LOGFILES = 3, and a small ROOTSIZE (also, obviously, a small disk slice for RootDB... saving you a ton of space!). After the initialization (oninit -iv), you add your LOG and PHYS spaces, adjust the LOG and PHYS values, and you are on your way. Remember: Bounce the engine = "onmode -ky" and "oninit". Reinitialize and wipe out everyting = "oninit -iv". Hope this helps! Michael Hoffman > > Hi Anna, > > phew! Quite a couple of things going wrong here ... > > I'll try to clear up: > > - logical log files can be added while the server is running. > There's no need to even bring down the server, much less > to re-initialize it !! > Which documentation have you read that states such things ? > Sounds like something needs dire correction/clarification in the > documents ... > > - you use the onparams utility to add a logical log file, like > "onparams -a [ -d <dbspace> ] [ -s <size in kB> ]" > > - by reinitializing the server with "oninit -i[v]" you've lost all data > that was stored in the instance before. I hope you either have > a backup or you don't need whatever was in there ... > > The extra prompting about "... databases will NOT be accessible ..." > should have alerted you to the fact, that this can't be the only > and correct way to add logical logs. > > Anyway, as it has happened already, there's not much to do now other > than restoring a backup or "continuing from scratch". As I don't know > which option you'll have to choose, I'll just try to explain further > what has happened and why. > > - By reinitializing you have brought up the server in its very initial > state, where it doesn't know about any dbspaces except the > root dbspace, because that is defined in the onconfig. > So everything that the server needs must be created in this > root dbspace ("rootdbs" in your case) during the initialization. > Among other things these are the logical log files and the > physical log file. > > - As I can see from your onconfig you had the > physical log file in a different dbspace ("physdbs") before > you started with your re-configuration/reinitialization. > While this is still defined that way in the onconfig, it can't > work, because after reinitialization there is no longer a > dbspaces called "physdbs". (Actually it probably still exists, > but the server doesn't know about it anymore.) > > - Therefore the server has to create a physical log, but only > the "rootdbs" exists (is known to the server), so it will create > it there. (There might be a message to that effect in the > message log file "online.log".) > > - With that, you have to add up your configured PHYSFILE > and logical log file space (LOGFILES * LOGSIZE). With > your numbers that makes 8000000 + (50 * 4096) = 8204800 > which is more than 8000000 that you specified as ROOTSIZE. > > - And this is just these two types of log files needing space > in the root dbspace. There's other stuff too, so you get the > message about 8205838 kB required ... > > - While I'm at it, in case you're rebuilding the system from > scratch now, you'll eventually want to move the physical log > file from its initial location in the root dbspace to a different > dbspace (like "physdbs"). You do that with the same > onparams utility, with different options. As well as with logical > logs there's no need to reinitialize the server !! > > Hmm. If all this sounds too complicated and confusing, I suggest you > get some professional help (Tech Support or probably even better some > on-site consulting of a trusted > source) right away before doing further experiments. In such a > situation it is rather difficult to correctly restore the old system > via e-mail guidance/help alone ... > > Regards, > Martin > -- > Martin Fuerderer > IBM Informix Development Munich, Germany > Data Management Solutions > > forum.subscriber@iiug.org wrote on 17.01.2005 21:04:06: > > > I have [or, more appropriately, had] a version of IDS 9.4 UC2 > > running > under > > Solaris 9 on a Sun 280 server. Before bringing the system up in > production, > > I wanted to allow more logical logs (the system was initialized with > 11). > > The documentation said > > the only way to increase LOGFILES required a reinitialization. After > tuning > > the onconfig the way I wanted it, repeatedly bringing the server up > > and > down, > > and performing a level 0 a