Translating with DrWatson… this can take a few seconds the first time.
This is a genuine, complex translation. DrWatson protects commands, error codes, and log output while naturally translating the surrounding text. It’s translated once and saved.
Danny set up a second IDS 9.40 instance on AIX 5.3 with its own sqlhosts/services entries, ONCONFIG, paths and env vars, but onstat -d on the second instance kept showing the first instance's data. Replies pointed out that two instances on one machine must have different SERVERNUM values, and that reusing copied chunks without running oninit -i leaves the old paths in place. Danny confirmed the cause: his first attempt had used a duplicate SERVERNUM; after correcting it he simply had to re-initialize (oninit -i) the second instance, which he had been avoiding for fear of wiping out the first.
Auto-generated by DrWatson from the posts below — may be imperfect; read the full thread.
After I set up one instance and everything seems to be working, I
attempted
to create a 2nd one.
I have entries in /etc/services for both instances.
I have entries in /informix/etc/sqlhosts for both.
I have unique values for ROOTPATH, MSGPATH, SERVERNUM, DBSERVERNAME and
DBSERVERALIASES in my config files (there is no mirroring).
And finally, I am changing the INFORMIXSERVER and ONCONFIG environment
variables when I attempt to switch instances.
I've created separate links to my logical volumes and I've double-checked
that they are not pointing to the same ones.
But, when I do an onstat -d in the 2nd instance, it shows me information
from the first instance.
I've just gotten off the phone with our software vendor (who we are supposed
to have Informix support through), but they were absolutely NO help - after
45 minutes, all I got was a useless document (their's, not Informix's)
telling me to do what I had already done.
Environment:
AIX 5.3
IDS 9.40
Thanks in advance,
Change the SERVERNUM ( two instances can not use the same SERVERNUM on
the same machine )
George
-----Original Message-----
From: forum.subscriber@iiug.org [mailto:forum.subscriber@iiug.org] On
Behalf Of Danny Wright
Sent: Thursday, June 16, 2005 12:59 PM
To: ids@iiug.org
Subject: 2nd instance problem - still looking at 1st instance [5171]
After I set up one instance and everything seems to be working, I
attempted to create a 2nd one.
I have entries in /etc/services for both instances.
I have entries in /informix/etc/sqlhosts for both.
I have unique values for ROOTPATH, MSGPATH, SERVERNUM, DBSERVERNAME and
DBSERVERALIASES in my config files (there is no mirroring).
And finally, I am changing the INFORMIXSERVER and ONCONFIG environment
variables when I attempt to switch instances.
I've created separate links to my logical volumes and I've
double-checked that they are not pointing to the same ones.
But, when I do an onstat -d in the 2nd instance, it shows me information
from the first instance.
I've just gotten off the phone with our software vendor (who we are
supposed to have Informix support through), but they were absolutely NO
help - after
45 minutes, all I got was a useless document (their's, not Informix's)
telling me to do what I had already done.
Environment:
AIX 5.3
IDS 9.40
Thanks in advance,
HI,
How did create the new chunks used by the second instance?
Did you just copy the chunks from the first to the second and apply a rename
to the new chunks? If you did so with oninit (not oninit -i), onstat -d
still shows the paths of the first instance even if you change the ROOTPATH
in the ONCONFIG file.
You will need to run oninit -i.
Can you please run: oncheck -pr on the second instance and send me the
output. You will probably notice that the ROOTPATH is OK, but the paths for
the other chunks still point to the chunks from the first instance.
Regards,
Khaled Bentebal
ConsultiX
Tél: 33 (0) 1 39 12 18 00
Fax: 33 (0) 1 39 12 18 18
Mobile: 33 (0) 6 07 78 41 97
Email: khaled.bentebal@consult-ix.fr
Site Web: http://www.consult-ix.fr
----- Original Message -----
From: "Danny Wright" <dwright@sherwoodfoods.com>
To: <ids@iiug.org>
Sent: Thursday, June 16, 2005 9:58 PM
Subject: 2nd instance problem - still looking at 1st instance [5171]
> After I set up one instance and everything seems to be working, I
attempted
> to create a 2nd one.
>
> I have entries in /etc/services for both instances.
>
> I have entries in /informix/etc/sqlhosts for both.
>
> I have unique values for ROOTPATH, MSGPATH, SERVERNUM, DBSERVERNAME and
> DBSERVERALIASES in my config files (there is no mirroring).
>
> And finally, I am changing the INFORMIXSERVER and ONCONFIG environment
> variables when I attempt to switch instances.
>
> I've created separate links to my logical volumes and I've double-checked
> that they are not pointing to the same ones.
>
> But, when I do an onstat -d in the 2nd instance, it shows me information
> from the first instance.
>
>
> I've just gotten off the phone with our software vendor (who we are
supposed
> to have Informix support through), but they were absolutely NO help -
after
> 45 minutes, all I got was a useless document (their's, not Informix's)
> telling me to do what I had already done.
>
> Environment:
>
> AIX 5.3
> IDS 9.40
>
> Thanks in advance,
>
>
>
So,
here's what went wrong.
The 1st time I tried to initialize the 2nd instance, I had SERVERNUM set the
same for both instances.
So, I fixed that, but expected that when I set the 2nd instance it would
show shared memory was not initialized instead of showing me the information
from the 2nd instance.
Not wanting to wipe out the 1st instance (which I had already done once), I
was reluctant to initialize the 2nd instance until I was certain I wouldn't
wipe out the first instance.
It seems stupid now, but I shouldn't have been so reluctant just to
reinitialize everything. It's not like it's that much work to set up the
database again - but I was under time constraints and I was sure I would
have just wiped it out again.
We use strictly necessary cookies to make this site work. With your
consent we’d also use optional cookies for analytics and marketing. You can accept all,
reject all, or choose. Read our Cookie Policy.