Informix ontape problems - "could not fork server connection"

[Brian Butscher]

Robin,

In looking at your online.log I see the error 226- I did a finderr and got the following results:

finderr 226
-226 Cannot create index for system catalog table-name.

The database server is trying to create one of the tables for the
system catalog, probably as part of a CREATE DATABASE statement. It
created the table, but a problem with the host operating system
prevents it from making an index. Check the accompanying ISAM error
code for more information, and look for operating-system error
messages. Insufficient disk space probably caused this error.

It looks like you don't have all of the chunks defined for your database as indicated by the 'Insufficient disk space probably caused this error.'

Make sure you have all of the following chunks defined:
/dev/rootdbs
/dev/tempdbs
/dev/mvpdbs01
/dev/mvpdbs02
/dev/mvpdbs03
/dev/mvpdbs04
/dev/mvpdbs05
/dev/mvpdbs06
/dev/mvpdbs07
/dev/mvpdbs08
/dev/mvpdbs09
/dev/mvpdbs10
/dev/mvpdbs11
/dev/mvpdbs12
/dev/mvpdbs13
/dev/mvpdbs14

with the correct permissions and ownership.

Can you attach a detailed listing of the /dev directory? I would recommend creating a separate directory for your Informix chunks as they need to have specific permissions and ownership.

Regards,

Brian

[Robin King_1]

Daniel you are correct. We spoke to IBM and they confirmed that the OS version and the DB version have to be exactly the same at source and destination.

We are now looking into exporting the databases, and then importing on the new server.

At least I've learnt a little about Informix in the process. Thanks for your help.

[daniel m_1]

The support line might have steered you wrong a little.

I have done many Informix restores from HP-UX 10.20 to HP-UX 11.11 machines, the thing to remember is that the Informix engine must be the same.
You can still accomplish what you were trying to do - once you get the database on the new machine, you can upgrade to the new Informix version.

[Brian Butscher]

Robin,


The Informix version must be the same as well Informix support pointed out. You might want to remember also that if you are running a 64 bit version of Informix, you must be running the 64-bit OS as well.

We all learn from these experiences, that's what makes this forum so great!

Brian

[JJ_4]

I think that dbexport / dbimport is the way to go, as the backup was done on IDS 7.31.UD4 and you are restoring onto IDS 7.31.FD7!!

The reason that the engine is failing is different though :


11:55:40 listener-thread: err = -25572: oserr = 226: errstr = : Network driver
cannot bind a name to the port.
System error = 226.
11:55:40 Attempting to bring listener thread down.

# define EADDRINUSE 226 /* Address already in use */

So it is an O/S Error.

Check your sqlhosts file for this new instance, and see whether you have a conflict in the service name ...

dbservername onipcshm hostname dummy_servicename
dbserveralias onsoctcp hostname servicename

Service name may be a port number, you just need to check whether that name / port number is already in use.

An easy way to confirm whether this instance is okay, is to do a full initialisation before the restore (which probably won't work anyway because of the different versions).

So, I think you will have to do a full disk initialisation of the 7.31.FD7, add all of your dbspaces / chunks, move your logs out etc. etc. Then do a full dbexport / dbimport.

An alternative could be to install 7.31.UD4 onto your new machine, and do a restore from your old 7.31.UD4, then look at the migration guide, and do an in-place upgrade to 7.31.FD7.

Food for thought hopefully.

[Matt Siconolfi]

Just wondering what the solution to Robin's problem was?

[ca25089]

Hi Matt, it is future Matt.  Your particular issue was related to hung shared memory segments that didn't clean up after a crash due to extent overlapping:

carsddb (aine): ipcs | grep inf
m 393231 0x00000000 D-rw-rw---- root informix
m 360464 0x00000000 D-rw-rw---- root informix

See these guys above?  You won't be able to remove them with ipcrm, you had to get kmeminfo from HP (through our CSS account rep, which was the easiest way).  Once you did that, you were able to find the processes attached to these by running the following:

carsddb (aine): kmeminfo -shmem 393231
tool: kmeminfo 10.37 - libp4 9.633 - libhpux 1.422 - HP CONFIDENTIAL
unix: HP-UX B.11.31 64bit Montvale 9140N on host "carsddb"
core: /dev/kmem live kernel!
link: Sun Jan 08 09:29:33 EST 2012
boot: Thu Feb 14 08:35:55 2013
time: Wed Feb 20 10:34:10 2013
nbpg: 4096 bytes

Shmid 393231:
Descriptor : struct shmid_ds 0xe0000001d0030618
Pseudo vas : vas_t 0xe0000003a893ba00
Pseudo preg: preg_t 0xe000000328bf4180
Shared reg : reg_t 0xe000000396ff1600
Segment range 0x7ff80031.0xc0000001e0000000-0xc000000204e5ffff
Segment allocated out of "Global 64-bit quadrant 6"
Processes using this segment:
proc=0xe004010010473100 (pid 16955 "oninit"): vas=0xe0000003378ba080, shmem preg=0xe000000328bd2480
proc=0xe000000335e3c400 (pid 16946 "oninit"): vas=0xe00000038bc02a00, shmem preg=0xe0000003383e6e00
proc=0xe000000344e0c400 (pid 16941 "oninit"): vas=0xe0000003c252e980, shmem preg=0xe000000347c81a00
proc=0xe004010010479300 (pid 16940 "oninit"): vas=0xe0000003710d0680, shmem preg=0xe0000003ca497c00
proc=0xe00000033bb70000 (pid 16939 "oninit"): vas=0xe0000003710d0980, shmem preg=0xe0000003682d6e00
proc=0xe0000003367cc400 (pid 16938 "oninit"): vas=0xe0000001dfec0980, shmem preg=0xe0000003a4910080
proc=0xe00000035c0eab80 (pid 16937 "oninit"): vas=0xe0000003cc26e380, shmem preg=0xe0000001aa888280
proc=0xe000000352a49300 (pid 16936 "oninit"): vas=0xe000000337874700, shmem preg=0xe00000039deef480
proc=0xe000000362c1ab80 (pid 16935 "oninit"): vas=0xe0000003600b4400, shmem preg=0xe0000003ce865680
proc=0xe0000003d24ec400 (pid 16930 "oninit"): vas=0xe0000003ac9e1400, shmem preg=0xe00000033b727780
proc=0xe000000344e00000 (pid 16929 "oninit"): vas=0xe0000003d1485980, shmem preg=0xe0000003398f5300
proc=0xe000000333140000 (pid 16915 "oninit"): vas=0xe00000033d40da00, shmem preg=0xe00000033768cb80
proc=0xe00000033f79c400 (pid 16914 "oninit"): vas=0xe0000001dfae8380, shmem preg=0xe0000003398ab300
proc=0xe00000033cc06200 (pid 16913 "oninit"): vas=0xe000000336a47100, shmem preg=0xe000000353e0e400
proc=0xe000000337bbdc80 (pid 16912 "oninit"): vas=0xe0000001dfec0080, shmem preg=0xe0000003974c5580
proc=0xe000000333dedc80 (pid 16911 "oninit"): vas=0xe000000352bcfa00, shmem preg=0xe0000003ba283a00
proc=0xe000000335e33100 (pid 16910 "oninit"): vas=0xe0000003311e6a00, shmem preg=0xe00000033eebe600
proc=0xe000000344ea3100 (pid 16909 "oninit"): vas=0xe000000376108a00, shmem preg=0xe0000003e1b69100
proc=0xe000000344fd7a80 (pid 16908 "oninit"): vas=0xe0000001dfddc680, shmem preg=0xe0000003affed180
proc=0xe000000362c11880 (pid 16907 "oninit"): vas=0xe0000001e0212c80, shmem preg=0xe0000003dbfb6100
proc=0xe000000334bc4980 (pid 16906 "oninit"): vas=0xe000000396f54a00, shmem preg=0xe0000003db953600
proc=0xe000000335e36200 (pid 16905 "oninit"): vas=0xe00000036010ed00, shmem preg=0xe0000003a2b20100
proc=0xe0000003367cab80 (pid 16904 "oninit"): vas=0xe0000001e0212380, shmem preg=0xe00000033d9c6900
proc=0xe000000336d10000 (pid 16903 "oninit"): vas=0xe00000033a2c6400, shmem preg=0xe00000036ac86d00

So basically you threw all the pids in a foreach loop, killed them off and then you were able to do your 'ontape -r'