oninit: Not enough room in ROOT DBspace.
Anna re-initialized an IDS 9.4 instance (oninit -iv) on Solaris 9 because she believed increasing LOGFILES required it, and initialization then failed with "Not enough room in ROOT DBspace" even after enlarging ROOTSIZE. Respondents explained the root cause: after re-init only rootdbs exists, so the physical log (PHYSDBS physdbs) plus all logical logs must fit in root — PHYSFILE 8000000 + 50 x 4096 exceeded ROOTSIZE 8000000. They stressed the re-init was unnecessary and destructive: logs can be added/resized online with onparams (-a/-d), and the physical log moved later. Art Kagel suggested recovering the old instance by restoring from archive, possibly rootdbs only, if no databases lived there.
Auto-generated by DrWatson from the posts below — may be imperfect; read the full thread.
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 archive, I did it.
Unfortunately, it looks like I have awakened a server with an insatiable
appetite for disk space.
Can anyone tell me what settings are causing the problem?
In this posting I am including:
- output from the oninit -iv command
- a diff of the working and nonworking onconfig files
- the complete nonworking onconfig file
Appreciate the assistance!
Anna
This is what happens when I try to initialize the instance...[note - I have
repeatedly increased the size of rootdbs and physdbs as the message suggests,
to a ridiculously large file size, but it always hangs in the same place.]
#################################################
bash-2.05$ oninit -iv
This action will initialize IBM Informix Dynamic Server;
any existing IBM Informix Dynamic Server databases will NOT be accessible -
Do you wish to continue (y/n)? y
Checking group membership to determine server run modesucceeded
Reading configuration file '/usr/informix/etc/onconfig.US280R'...succeeded
Creating /INFORMIXTMP/.infxdirs ... succeeded
Creating infos file "/usr/informix/etc/.infos.US280R_on" ...
"/usr/informix/etc/.conf.US280R_on" ... succeeded
Writing to infos file ... succeeded
Checking config parameters...succeeded
Allocating and attaching to shared memory...succeeded
Creating resident pool 6100 kbytes...succeeded
Creating buffer pool 60002 kbytes...succeeded
Initializing rhead structure...succeeded
Initializing ASF ...succeeded
Initializing Dictionary Cache and SPL Routine Cache...succeeded
Bringing up ADM VP...succeeded
Creating VP classes...succeeded
Onlining 0 additional cpu vps...succeeded
Onlining 2 IO vps...succeeded
Initialization of Encryption...succeeded
Forking main_loop thread...succeeded
Initializing DR structures...succeeded
Forking 1 'ipcstr' listener threads...succeeded
Forking 1 'tlitcp' listener threads...succeeded
Starting tracing...succeeded
Initializing 16 flushers...succeeded
oninit: Not enough room in ROOT DBspace.
Requested 8205838K, ONCONFIG value 'ROOTSIZE' 8000000K.
FAILED
bash-2.05$
############################################################
Comparing the working and nonworking onconfig files.....
bash-2.05$ diff ~anna/onconfig.US280R ~anna/onconfig.US280R.toobigroot
14c14,15
< ROOTSIZE 30000 # Size of root dbspace (Kbytes)
---
> #ROOTSIZE 30000 # Size of root dbspace (Kbytes)
> ROOTSIZE 8000000 # Size of root dbspace (Kbytes)
26,27c27,28
< #PHYSFILE 2000 # Physical log file size (Kbytes)< PHYSFILE 524288 # Physical log file size (Kbytes)
---
> #PHYSFILE 524288 # Physical log file size (Kbytes)
> PHYSFILE 8000000 # Physical log file size (Kbytes)
32,33c33,35< LOGFILES 11 # Number of logical log files
< LOGSIZE 10484 # Logical log size (Kbytes)
---
> LOGFILES 50 # Number of logical log files> #LOGSIZE 10484 # Logical log size (Kbytes)
> LOGSIZE 4096 # Logical log size (Kbytes)88c90
< SHMVIRTSIZE 8000 # initial virtual shared memory segment size
---
> SHMVIRTSIZE 8192 # initial virtual shared memory segment size279c281,282
< ROOTPATH /usr/informix//US280R/server/online_root
---
> #ROOTPATH /usr/informix/US280R/server/online_root
> ROOTPATH /usr/informix/server/rootdbs/online_root
bash-2.05$
#################################################################
bash-2.05$ cat onconfig.US280R
#**************************************************************************
#
# INFORMIX SOFTWARE, INC.
#
# Title: onconfig.std# Description: Informix Dynamic Server Configuration Parameters
#
#**************************************************************************
# Root Dbspace Configuration
ROOTNAME rootdbs # Root dbspace name
ROOTOFFSET 0 # Offset of root dbspace into device (Kbytes)#ROOTSIZE 30000 # Size of root dbspace (Kbytes)
ROOTSIZE 8000000 # Size of root dbspace (Kbytes)
# Disk Mirroring Configuration Parameters
MIRROR 0 # Mirroring flag (Yes = 1, No = 0)
MIRRORPATH # Path for device containing mirrored root
MIRROROFFSET 0 # Offset into mirrored device (Kbytes)
# Physical Log Configuration
PHYSDBS physdbs # Location (dbspace) of physical log
#PHYSDBS rootdbs # Location (dbspace) of physical log
#PHYSFILE 524288 # Physical log file size (Kbytes)
PHYSFILE 8000000 # Physical log file size (Kbytes)
# Logical Log Configuration
#LOGFILES 11 # Number of logical log files
LOGFILES 50 # Number of logical log files#LOGSIZE 10484 # Logical log size (Kbytes)
LOGSIZE 4096 # Logical log size (Kbytes)
# Diagnostics
CONSOLE /dev/console # System console message path
# To automatically backup logical logs, edit alarmprogram.sh and set
# BACKUPLOGS=Y
ALARMPROGRAM /usr/informix/etc/alarmprogram.sh # Alarm program path
TBLSPACE_STATS 1 # Maintain tblspace statistics
# System Archive Tape Device
TAPEBLK 1024 # Tape block size (Kbytes)
TAPESIZE 12288000 # Maximum amount of data to put on tape (Kbytes)
# Log Archive Tape Device
LTAPEBLK 32 # Log tape block size (Kbytes)
LTAPESIZE 10240 # Max amount of data to put on log tape (Kbytes)
# Optical
STAGEBLOB # Informix Dynamic Server staging area
# System Configuration
DBSERVERNAME US280R_on
SERVERNUM 0
DBSERVERALIASES US280R_onnet # List of alternate dbservernames
#NETTYPE tlitcp,1,50,NET # Configure poll thread(s) for nettype
NETTYPE ontlitcp,1,50,NET # Configure poll thread(s) for nettype
#NETTYPE ipcshm,1,50,CPU # Configure poll thread(s) for nettype
NETTYPE onipcstr,1,50,CPU # Configure poll thread(s) for nettype
DEADLOCK_TIMEOUT 60 # Max time to wait of lock in distributed env.
RESIDENT 0 # Forced residency flag (Yes = 1, No = 0)
MULTIPROCESSOR 0 # 0 for single-processor, 1 for multi-processor
NUMCPUVPS 1 # Number of user (cpu) vps
SINGLE_CPU_VP 0 # If non-zero, limit number of cpu vps to one
NOAGE 0 # Process aging
AFF_SPROC 0 # Affinity start processor
AFF_NPROCS 0 # Affinity number of processors
# Shared Memory Parameters
LOCKS 20000 # Maximum number of locks
BUFFERS 30000 # Maximum number of shared buffers
NUMAIOVPS # Number of IO vps
PHYSBUFF 32 # Physical log buffer size (Kbytes)
LOGBUFF 32 # Logical log buffer size (Kbytes)
CLEANERS 16 # Number of buffer cleaner processes
SHMBASE 0xa000000 # Shared memory base address
SHMVIRTSIZE 8192 # initial virtual shared memory segment size
SHMADD 8192 # Size of new shared memory segments (Kbytes)
SHMTOTAL 0 # Total shared memory (Kbytes). 0=>unlimited
CKPTINTVL 600 # Check point interval (in sec)
LRUS 31 # Number of LRU queues
LRU_MAX_DIRTY 60.000000 # LRU percent dirty begin cleaning limit
LRU_MIN_DIRTY 50.000000 # LRU percent dirty end cleaning limit
TXTIMEOUT 0x12c # Transaction time
t is not correct that it is not possible to increase
the numbers of
logiclogs without reinitiate the instance.
On AIX we the following:
Startup the instance with a small amount of logilogs and small in size.
The same with the physlog. Small in size.
# Logical Log Configuration
LOGFILES 6 # Number of logical log files
LOGSIZE 10000 # Logical log size (Kbytes)
# Physical Log Configuration
PHYSDBS dx_root_fs001
# Location (dbspace) of physical log
PHYSFILE 20000 # Physical log file size (Kbytes)
Then we create a physlog dbspace and 2 logiclogs dbspaces
Changes the physlog parameters in the onconfig fil and restart the
unstance.
In that way the physlog switch frokm rootdbs to physdbs.
Then we begins creating new and lager logiclogs:
# instance in single user mode
onmode -scy# creates the first 4 new and larger logiclogs
onparams -a -d dx_logiclog_fs001 -s 40916
onparams -a -d dx_logiclog_fs002 -s 40916
onparams -a -d dx_logiclog_fs001 -s 40916
onparams -a -d dx_logiclog_fs002 -s 40916# a fake backup to activate the new logiclogs
onbar -b -F# force change of logs from the ones created during init of the instance
onmode -lc
onmode -lc
onmode -lc# removes the first 3 of the original logs
onparams -d -l 1 -y
onparams -d -l 2 -y
onparams -d -l 3 -y# a fake backup to get the old logiclog actuali deleted
onbar -b -F# creates 4 more logiclogs
onparams -a -d dx_logiclog_fs001 -s 40916
onparams -a -d dx_logiclog_fs002 -s 40916
onparams -a -d dx_logiclog_fs001 -s 40916
onparams -a -d dx_logiclog_fs002 -s 40916# a fake backup to activate the new logiclogs
onbar -b -F
onparams -d -l 4 -y
onparams -d -l 5 -y
onparams -d -l 6 -y# a fake backup to get the old logiclog actuali deleted
onbar -b -F# creates the laste 2 logiclogs (we wants 10 logiclogs)
onparams -a -d dx_logiclog_fs001 -s 40916
onparams -a -d dx_logiclog_fs002 -s 40916# a fake backup to activate the new logiclogs
onbar -b -F# bring instance in multi user mode
onmode -m
In this way we don't need to create so large a rootdbs.
Try it it should work on Solaris as well.
Med venlig hilsen
Bjarne Wilken Jensen
DatabaseAdm. - IT-produktion.
Alm. Brand Forsikring A/S
Midtermolen 7
DK-2100 København Ø
Tlf: +45 3547 7771
E-Mail: abrbwj@AlmBrand.Dk
"ANNA JOHNSON" <anna.johnson@signal-ctc.com>
Sendt af: forum.subscriber@iiug.org
17-01-2005 21:04
Til
ids@iiug.org
cc
Emne
oninit: Not enough room in ROOT DBspace. [4024]
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 archive, I did it. Unfortunately, it looks like I have awakened a
server with an insatiable appetite for disk space.
Can anyone tell me what settings are causing the problem?
In this posting I am including:
- output from the oninit -iv command
- a diff of the working and nonworking onconfig files
- the complete nonworking onconfig file
Appreciate the assistance!
Anna
This is what happens when I try to initialize the instance...[note - I
have repeatedly increased the size of rootdbs and physdbs as the message
suggests, to a ridiculously large file size, but it always hangs in the
same place.]
#################################################
bash-2.05$ oninit -iv
This action will initialize IBM Informix Dynamic Server;
any existing IBM Informix Dynamic Server databases will NOT be accessible
-
Do you wish to continue (y/n)? y
Checking group membership to determine server run modesucceeded
Reading configuration file '/usr/informix/etc/onconfig.US280R'...succeeded
Creating /INFORMIXTMP/.infxdirs ... succeeded
Creating infos file "/usr/informix/etc/.infos.US280R_on" ...
"/usr/informix/etc/.conf.US280R_on" ... succeeded
Writing to infos file ... succeeded
Checking config parameters...succeeded
Allocating and attaching to shared memory...succeeded
Creating resident pool 6100 kbytes...succeeded
Creating buffer pool 60002 kbytes...succeeded
Initializing rhead structure...succeeded
Initializing ASF ...succeeded
Initializing Dictionary Cache and SPL Routine Cache...succeeded
Bringing up ADM VP...succeeded
Creating VP classes...succeeded
Onlining 0 additional cpu vps...succeeded
Onlining 2 IO vps...succeeded
Initialization of Encryption...succeeded
Forking main_loop thread...succeeded
Initializing DR structures...succeeded
Forking 1 'ipcstr' listener threads...succeeded
Forking 1 'tlitcp' listener threads...succeeded
Starting tracing...succeeded
Initializing 16 flushers...succeeded
oninit: Not enough room in ROOT DBspace.
Requested 8205838K, ONCONFIG value 'ROOTSIZE' 8000000K.
FAILED
bash-2.05$
############################################################
Comparing the working and nonworking onconfig files.....
bash-2.05$ diff ~anna/onconfig.US280R ~anna/onconfig.US280R.toobigroot
14c14,15
< ROOTSIZE 30000 # Size of root dbspace (Kbytes)
---
> #ROOTSIZE 30000 # Size of root dbspace (Kbytes)
> ROOTSIZE 8000000 # Size of root dbspace (Kbytes)
26,27c27,28
< #PHYSFILE 2000 # Physical log file size (Kbytes)< PHYSFILE 524288 # Physical log file size (Kbytes)
---
> #PHYSFILE 524288 # Physical log file size (Kbytes)
> PHYSFILE 8000000 # Physical log file size (Kbytes)
32,33c33,35< LOGFILES 11 # Number of logical log files
< LOGSIZE 10484 # Logical log size (Kbytes)
---
> LOGFILES 50 # Number of logical log files> #LOGSIZE 10484 # Logical log size (Kbytes)
> LOGSIZE 4096 # Logical log size (Kbytes)88c90
< SHMVIRTSIZE 8000 # initial virtual shared memory segment
size
---
> SHMVIRTSIZE 8192 # initial virtual shared memory segmentsize
279c281,282
< ROOTPATH /usr/informix//US280R/server/online_root
---
> #ROOTPATH /usr/informix/US280R/server/online_root
> ROOTPATH /usr/informix/server/rootdbs/online_root
bash-2.05$
#################################################################
bash-2.05$ cat onconfig.US280R
#**************************************************************************
#
# INFORMIX SOFTWARE, INC.
#
# Title: onconfig.std# Description: Informix Dynamic Server Configuration Parameters
#
#**************************************************************************
# Root Dbspace Configuration
ROOTNAME rootdbs # Root dbspace name
ROOTOFFSET 0 # Offset of root dbspace into device
(Kbytes)#ROOTSIZE 30000 # Size of root dbspace (Kbytes)
ROOTSIZE 8000000 # Size of root dbspace (Kbytes)
# Disk Mirroring Configuration Parameters
MIRROR 0 # Mirroring flag (Yes = 1, No = 0)
MIRRORPATH # Path for device containing mirrored root
MIRROROFFSET 0 # Offset into mirrored device (Kbytes)
# Physical Log Configuration
PHY
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 archive, I did it. Unfortunately, it looks like
I
> have awakened a server
> with an insatiable appetite for disk space.
>
> Can anyone tell me what settings are causing the problem?
>
> In this posting I am including:
> - output from the oninit -iv command
> - a diff of the working and nonworking onconfig files
> - the complete nonworking onconfig file
>
> Appreciate the assistance!
> Anna
>
>
> This is what happens when I try to initialize the instance...
> [note - I have repeatedly increased the size of rootdbs and
> physdbs as the message suggests, to a ridiculously large file
> size, but it always hangs in the same place.]
> #################################################
> bash-2.05$ oninit -iv>
> This action will initialize IBM Informix Dynamic Server;
> any existing IBM Informix Dynamic Server databases will NOT be
accessible -
> Do you wish to continue (y/n)? y
> Checking group membership to determine server run modesucceeded
> Reading configuration file
'/usr/informix/etc/onconfig.US280R'...succeeded
> Creating /INFORMIXTMP/.infxdirs ... succeeded
> Creating infos file "/usr/informix/etc/.infos.US280R_on" ...
"/usr/informix/etc/.conf.US280R_on" ... succeeded
> Writing to infos file ... succeeded
> Checking config parameters...succeeded
> Allocating and attaching to shared memory...succeeded
> Creating resident pool 6100 kbytes...succeeded
> Creating buffer pool 60002 kbytes...succeeded
> Initializing rhead structure...succeeded
> Initializing ASF ...succeeded
> Initializing Dictionary Cache and SPL Routine Cache...succeeded
> Bringing up ADM VP...succeeded
> Creating VP classes...succeeded
> Onlining 0 additional cpu vps...succeeded
> Onlining 2 IO vps...succeeded
> Initialization of Encryption...succeeded
> Forking main_loop thread...succeeded
> Initializing DR structures...succeeded
> Forking 1 'ipcstr' listener threads...succeeded
> Forking 1 'tlitcp' listener threads...succeeded
> Starting tracing...succeeded
> Initializing 16 flushers...succeeded
> oninit: Not enough room in ROOT DBspace.
> Requested 8205838K, ONCONFIG value 'ROOTSIZE' 8000000K.
> FAILED
> bash-2.05$
> ############################################################
>
>
> Comparing the working and nonworking onconfig files.....
> bash-2.05$ diff ~anna/onconfig.US280R ~anna/onconfig.US280R.toobigroot
> 14c14,15
> < ROOTSIZE 30000 # Size of root dbspace (Kbytes)
> ---
> > #ROOTSIZE 30000 # Size of root dbspace (Kbytes)
> > ROOTSIZE 8000000 # Size of root dbspace (Kbytes)
> 26,27c27,28
> < #PHYSFILE 2000 # Physical log file size (Kbytes)> < PHYSFILE 524288 # Physical log file size (Kbytes)
> ---
> > #PHYSFILE 524288 # Physical log file size (Kbytes)
> > PHYSFILE 8000000 # Physical log file size (Kbytes)
> 32,33c33,35> < LOGFILES 11 # Number of logical log files
> < LOGSIZE 10484 # Logical log size (Kbytes)
> ---
> > LOGFILES 50 # Number of logical log files> > #LOGSIZE 10484 # Logical log size (Kbytes)
> > LOGSIZE 4096 # Logical log size (Kbytes)> 88c90
> < SHMVIRTSIZE 8000 # initial virtual shared memory
segment size
> ---
> > SHMVIRTSIZE 8192 # initial virtual shared memorysegment si
Hi
Martin,
You are so excellent with your explanations, I love to read them !
While Anna did not have to re-init in this case, .... You know it's not
the first time someone has misunderstood that act....
Maybe you can start the bug in IBM's ear to move away from the word
initialize when perhaps a start/stop is meant. The other database
vendors don't use that word to mean start the engine. I think DBAs more
familiar with other vendors can too easily misunderstand what an
informix initialize means.
But this is IBM... ... What does DB2 call that action? (stop/start?
shutdown/startup? Db2up/db2down?)...
Thanks,
NJ
-----Original Message-----
From: forum.subscriber@iiug.org [mailto:forum.subscriber@iiug.org] On
Behalf Of Martin Fuer....
Sent: Tuesday, January 18, 2005 2:17 AM
To: ids@iiug.org
Subject: Re: oninit: Not enough room in ROOT DBspace. [4028]
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 archive, I did it. Unfortunately, it looks
> like
I
> have awakened a server
> with an insatiable appetite for disk space.
>
> Can anyone tell me what settings are causing the problem?
>
> In this posting I am including:
> - output from the oninit -iv command
> - a diff of the working and nonworking onconfig files
> - the complete nonworking onconfig file
>
> Appreciate the assistance!
> Anna
>
>
> This is what happens when I try to initialize the instance...
> [note - I have repeatedly increased the size of rootdbs and physdbs as
> the message suggests, to a ridiculously large file size, but it always
> hangs in the same place.]
> #################################################
> bash-2.05$ oninit -iv>
> This action will initialize IBM Informix Dynamic Server; any existing
> IBM Informix Dynamic Server databases will NOT be
accessible -
> Do you wish to continue (y/n)? y
> Checking group membership to determine server run modesucceeded
> Reading configuration file
'/usr/informix/etc/onconfig.US280R'...succeeded
> Creating /INFORMIXTMP/.infxdirs ... succeeded Creating infos file
> "/usr/informix/etc/.infos.US280R_on" ...
"/usr/informix/etc/.conf.US280R_on" ... succeeded
> Writing to infos file ... succeeded
> Checking config parameters...succeeded Allocating and attaching to
> shared memory...succeeded Creating resident pool 6100
> kbytes...succeeded Creating buffer pool 60002 kbytes...succeeded
> Initializing rhead structure...succeeded Initializing ASF ...succeeded
> Initializing Dictionary Cache and SPL Routine Cache...succeeded
> Bringing up ADM VP...succeeded Creating VP classes...succeeded
> Onlining 0 additional cpu vps...succeeded Onlining 2 IO
> vps...succeeded Initialization of Encryption...succeeded Forking
> main_loop thread...succeeded Initializing DR structures...succeeded
> Forking 1 'ipcstr' listener threads...succeeded Forking 1 'tlitcp'
> listener threads...succeeded Starting tracing...succeeded Initializing
> 16 flushers...succeeded
> oninit: Not enough room in ROOT DBspace.
> Requested 8205838K, ONCONFIG value 'ROOTSIZE' 8000000K.
> FAILED
> bash-2.05$
> ############################################################
>
>
> Comparing the working and nonworking onconfig files.....
> ba
As others have already pointed out the oninit -i destroyed the existing
instance
and created a new empty one. HOWEVER, it MAY be possible to recover the
original instance, IFF there were not databases living in rootdbs or you have
an
up-to-date archive and logical log backup from BEFORE the first time you ran
oninit -i. If you have a full archive from that point (or a combination of fulland partial archives to that point) and all logical log backups to the point of
shutting down that last time, then a full restore it the best way to go. If
you have recent backups but do not have completely up-to-date archives and log
backups, then you may be able to recover anyway, as I said if there were not
databases in ROOTDBS, by ONLY restoring the rootdbspace. That would restore the
reserved pages on which is recorded the locations of all the original chunks
and dbspaces. If you do that then everything will be as it was at the point of
the last shutdown except the rootdbs which will have been restored to the point
of the last archive. So any system changes (and mods to databases living in
rootdbs) made after that partially restored archive would be lost, but data in
the tables and databases living in other dbspaces would be restored as long as
they had no data in rootdbs or in new chunks added after the archive. Anyway
it's worth a try.
Art S. Kagel
----- Original Message -----
From: Anna Johnson <anna.johnson@signal-ctc.com>
At: 1/17 15:55
> 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 archive, I did it.
> Unfortunately, it looks like I have awakened a server with an insatiable
> appetite for disk space.
>
> Can anyone tell me what settings are causing the problem?
>
> In this posting I am including:
> - output from the oninit -iv command
> - a diff of the working and nonworking onconfig files
> - the complete nonworking onconfig file
>
> Appreciate the assistance!
> Anna
>
>
> This is what happens when I try to initialize the instance...[note - I have
> repeatedly increased the size of rootdbs and physdbs as the message suggests,
to
> a ridiculously large file size, but it always hangs in the same place.]
> #################################################
> bash-2.05$ oninit -iv>
> This action will initialize IBM Informix Dynamic Server;
> any existing IBM Informix Dynamic Server databases will NOT be accessible -
> Do you wish to continue (y/n)? y
> Checking group membership to determine server run modesucceeded
> Reading configuration file '/usr/informix/etc/onconfig.US280R'...succeeded
> Creating /INFORMIXTMP/.infxdirs ... succeeded
> Creating infos file "/usr/informix/etc/.infos.US280R_on" ...
> "/usr/informix/etc/.conf.US280R_on" ... succeeded
> Writing to infos file ... succeeded
> Checking config parameters...succeeded
> Allocating and attaching to shared memory...succeeded
> Creating resident pool 6100 kbytes...succeeded
> Creating buffer pool 60002 kbytes...succeeded
> Initializing rhead structure...succeeded
> Initializing ASF ...succeeded
> Initializing Dictionary Cache and SPL Routine Cache...succeeded
> Bringing up ADM VP...succeeded
> Creating VP classes...succeeded
> Onlining 0 additional cpu vps...succeeded
> Onlining 2 IO vps...succeeded
> Initialization of Encryption...succeeded
> Forking main_loop thread...succeeded
> Initializing DR structures...succeeded
> Forking 1 'ipcstr' listener threads...succeeded
> Forking 1 'tlitcp' listener threads...succeeded
> Starting tracing...succeeded
> Initializing 16 flushers...succeeded
> oninit: Not enough room in ROOT DBspace.
> Requested 8205838K, ONCONFIG value 'ROOTSIZE' 8000000K.
> FAILED
> bash-2.05$
> ############################################################
>
>
> Comparing the working and nonworking onconfig files.....
> bash-2.05$ diff ~anna/onconfig.US280R ~anna/onconfig.US280R.toobigroot
> 14c14,15
> < ROOTSIZE 30000 # Size of root dbspace (Kbytes)
> ---
> > #ROOTSIZE 30000 # Size of root dbspace (Kbytes)
> > ROOTSIZE 8000000 # Size of root dbspace (Kbytes)
> 26,27c27,28
> < #PHYSFILE 2000 # Physical log file size (Kbytes)> < PHYSFILE 524288 # Physical log file size (Kbytes)
> ---
> > #PHYSFILE 524288 # Physical log file size (Kbytes)
> > PHYSFILE 8000000 # Physical log file size (Kbytes)
> 32,33c33,35> < LOGFILES 11 # Number of logical log files
> < LOGSIZE 10484 # Logical log size (Kbytes)
> ---
> > LOGFILES 50 # Number of logical log files> > #LOGSIZE 10484 # Logical log size (Kbytes)
> > LOGSIZE 4096 # Logical log size (Kbytes)> 88c90
> < SHMVIRTSIZE 8000 # initial virtual shared memory segment size
> ---
> > SHMVIRTSIZE 8192 # initial virtual shared memory segment size> 279c281,282
> < ROOTPATH /usr/informix//US280R/server/online_root
> ---
> > #ROOTPATH /usr/informix/US280R/server/online_root
> > ROOTPATH /usr/informix/server/rootdbs/online_root
> bash-2.05$
>
> #################################################################
>
>
> bash-2.05$ cat onconfig.US280R
> #**************************************************************************
> #
> # INFORMIX SOFTWARE, INC.
> #
> # Title: onconfig.std> # Description: Informix Dynamic Server Configuration Parameters
> #
> #**************************************************************************
>
> # Root Dbspace Configuration
>
> ROOTNAME rootdbs # Root dbspace name
> ROOTOFFSET 0 # Offset of root dbspace into device (Kbytes)> #ROOTSIZE 30000 # Size of root dbspace (Kbytes)
> ROOTSIZE 8000000 # Size of root dbspace (Kbytes)>
> # Disk Mirroring Configuration Parameters
>
> MIRROR 0 # Mirroring flag (Yes = 1, No = 0)
> MIRRORPATH # Path for device containing mirrored root
> MIRROROFFSET 0 # Offset into mirrored device (Kbytes)>
> # Physical Log Configuration
>
> PHYSDBS physdbs # Location (dbspace) of physical log
> #PHYSDBS rootdbs # Location (dbspace) of physical log
> #PHYSFILE 524288 # Physical log file size (Kbytes)
> PHYSFILE 8000000 # Physical log file size (Kbytes)>
> # Logical Log Configuration
>
> #LOGFILES 11 # Number of logical log files
> LOGFILES 50 # Number of logical log files> #LOGSIZE 10484 # Logical log size (Kbytes)
> LOGSIZE 4096 # Logical log size (Kbytes)>
> # Diagnostics
>
> CONSOLE /dev/console # System console message path>
> # To automatically backup logical logs, edit alarmprogram.sh and set
> # BACKUPLOGS=Y
> ALARMPROGRAM /usr/informix/etc/alarmprogram.sh # Alarm program path
> TBLSPACE_STATS 1 # Maintain tblspace statistics>
> # System Archive Tape Device
>
> TAPEBLK 1024 # Tape block size (Kbytes)
> TAPESIZE 12288000 # Maximum amount of data to put on tape
(Kbytes)>
> # Log Archive Tape Device
>
> LTAPEBLK 32 # Log tap
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 archive, I did it. Unfortunately, it looks like
> I
> > have awakened a server
> > with an insatiable appetite for disk space.
> >
> > Can anyone tell me what settings are causing the problem?
> >
> > In this posting I am including:
> > - output from the oninit -iv command
> > - a diff of the working and nonworking onconfig files
> > - the complete nonworking onconfig file
> >
> > Appreciate the assistance!
> > Anna
> >
> >
> > This is what happens when I try to initialize the instance...
> > [note - I have repeatedly increased the size of rootdbs and
> > physdbs as the message suggests, to a ridiculously large file
> > size, but it always hangs in the same place.]
> > #################################################
> > bash-2.05$ oninit -iv> >
> > This action will initialize IBM Informix Dynamic Server;
> > any existing IBM Informix Dynamic Server databases will NOT be
> accessible -
> > Do you wish to continue (y/n)? y
> > Checking group membership to determine server run modesucceeded
> > Reading configuration file
> '/usr/informix/etc/onconfig.US280R'...succeeded
> > Creating /INFORMIXTMP/.infxdirs ... succeeded
> > Creating infos file "/usr/informix/etc/.infos.US280R_on" ...
> "/usr/informix/etc/.conf.US280R_on" ... succeeded
> > Writing to infos file ... succeeded
> > Checking config parameters...succeeded
> > Allocating and attaching to shared memory...succeeded
> > Creating resident pool 6100 kbytes...succeeded
> > Creating buffer pool 60002 kbytes...succeeded@@
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 archive, I did it. Unfortunately, it looks
> > like
> I
> > have awakened a server
> > with an insatiable appetite for disk space.
> >
> > Can anyone tell me what settings are causing the problem?
> >
> > In this posting I am including:
> > - output from the oninit -iv command
> > - a diff of the working and nonworking onconfig files
> > - the complete nonworking onconfig file
> >
> > Appreciate the assistance!
> > Anna
> >
> >
> > This is what happens when I try to initialize the instance... [note
> > - I have repeatedly increased the size of rootdbs and physdbs as the
> > message suggests, to a ridiculously large file size, bu
I suggested onit -i InItIaLiZe when I was working at Informix ... :)
They have had many requests to change the oninit setting to make it safer ...
have no idea why they have not acted on the change requests to do something
about this safety issue.
Take care.
Clifton
"ART KAGEL, ...." <KAGEL@bloomberg.net> wrote:
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....
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 ] [ -s ]"
>
> - 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
Not original by any means, but a simple wrapper script can save some
pain.
This one works on Linux and Sun, I know.
Mileage will vary.
#!/bin/ksh
# simple wrapper to prevent accidental running of oninit -iy
# mv /usr/informix/bin/oninit /usr/informix/bin/oninit.cmd
# cp this file to /usr/informix/bin/oninit
# set appropriate permissions for new file (informix:informix 750 seem
to work).
CMD=${0}.cmd
if [[ "$1" = -*i* ]] ; then
echo "** WARNING! oninit -i will completely erase this instance!
**"
echo "** If that's what you REALLY want to do, then re-run this
**"
echo "** command using a capital '-I' instead. (e.g. oninit -I ).
**"
exit
fi
if [[ "$1" = -*y* ]] ; then
echo "** Please do not use the y flag when initializing the engine.
**"
exit
fi
if [[ "$1" = -*I* ]] ; then
$CMD -i
exit
else
$CMD $*
Fi
Sam
-----Original Message-----
From: forum.subscriber@iiug.org [mailto:forum.subscriber@iiug.org] On
Behalf Of ART KAGEL, ....
Sent: Tuesday, January 18, 2005 3:12 PM
To: ids@iiug.org
Subject: Fwd: RE: oninit: Not enough room in ROOT DBspace. [4035 [4036]
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
> d
My follow on message appears to have been eaten, so
I'll send it again.
Sorry, I hit send before I finished.
This script is not mine, though I tweaked it some.
http://www.oreilly.com/catalog/unixbr/chapter/ch14.html
-----Original Message-----
From: forum.subscriber@iiug.org [mailto:forum.subscriber@iiug.org] On
Behalf Of Gentsch, Sam
Sent: Tuesday, January 18, 2005 4:41 PM
To: ids@iiug.org
Subject: RE: RE: oninit: Not enough room in ROOT DBspace. [4035 [4036]
[4039]
Not original by any means, but a simple wrapper script can save some
pain.
This one works on Linux and Sun, I know.
Mileage will vary.
#!/bin/ksh
# simple wrapper to prevent accidental running of oninit -iy # mv
/usr/informix/bin/oninit /usr/informix/bin/oninit.cmd # cp this file to
/usr/informix/bin/oninit # set appropriate permissions for new file
(informix:informix 750 seem to work).
CMD=${0}.cmd
if [[ "$1" = -*i* ]] ; then
echo "** WARNING! oninit -i will completely erase this instance!
**"
echo "** If that's what you REALLY want to do, then re-run this **"
echo "** command using a capital '-I' instead. (e.g. oninit -I ).
**"
exit
fi
if [[ "$1" = -*y* ]] ; then
echo "** Please do not use the y flag when initializing the engine.
**"
exit
fi
if [[ "$1" = -*I* ]] ; then
$CMD -i
exit
else
$CMD $*
Fi
Sam
-----Original Message-----
From: forum.subscriber@iiug.org [mailto:forum.subscriber@iiug.org] On
Behalf Of ART KAGEL, ....
Sent: Tuesday, January 18, 2005 3:12 PM
To: ids@iiug.org
Subject: Fwd: RE: oninit: Not enough room in ROOT DBspace. [4035 [4036]
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 * LOGSIZ
Feature
requests 113900 (and 115056, but reference B113900) cover this.
B113900: FEA: WANT A DIFFERENT COMMAND TO START THE SERVER THAN THE
COMMAND TO INITIALIZE IT (ONINIT -I)
Already known - since forever (request entered June 1999).
Principle reasons for not having changed it are (1) inertia and (2) it
would have a dramatic impact on the IDS QA suite (which is enormous -
thousands of tests), and for which most tests create a new instance of
IDS. To be remotely achievable, there'd have to be a backwards
compatibility mechanism -- probably an environment variable, along the
lines of INFORMIX_QA_ENABLE_ONINIT_INITIALIZATION=1 -- which would allow
'oninit -i' after all. And there would inevitably be people who would set
that (to avoid rewriting their initialization scripts), and then wonder
why the bug fix permitted them to break their system still!
--
Jonathan Leffler (jleffler@us.ibm.com)
STSM, Informix Database Engineering, IBM Information Management Division
4100 Bohannon Drive, Menlo Park, CA 94025
Tel: +1 650-926-6921 Tie-Line: 630-6921
"I don't suffer from insanity; I enjoy every minute of it!"
forum.subscriber@iiug.org wrote on 01/18/2005 11:55:43 AM:
> 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 diff