Had an interesting situation ... IDS 12.10 engine had most of the sysmaster tables/views "disappear." This impacted a number of ops, including archives, etc. Some of the tables were there, so an engine bounce didn't attempt a recreate of the sysmaster database. Of course I recreated the missing tables with "buildsmi" fine. 

Anyone had this behavior though? Of course we have no scripts that ever try to manipulate sysmaster tables/views. 

Thanks! 

Mark Scranton

------------------------------
Mark Scranton
The Mark Scranton Group
mark@markscranton.com
------------------------------

#Informix

Hi,

Anything in online.log to help narrow it down?

Any onaudit enabled to see what happened?

Sounds like someone did some cleanup...


------------------------------
David Williams
------------------------------

David - 

Nothing in the msg log. And there really isn't any "clean-up"/maintenance to be done since most of the structures are actually views into shared memory. Of course we query sysmaster all the time but I've never written any scripts to manipulate any of the real tables in sysmaster.

Thanks -
Mark

------------------------------
Mark Scranton
------------------------------

Original Message:
Sent: Thu September 02, 2021 12:27 PM
From: David Williams
Subject: sysmaster tables gone


Hi,

Anything in online.log to help narrow it down?

Any onaudit enabled to see what happened?

Sounds like someone did some cleanup...


------------------------------
David Williams
------------------------------

Might be a known problem: "buildsmi script would corrupt sysmaster (remove all SMI pseudo tables) if ran while other session has sysmaster db open"

One way to incur this: you're creating a new instance, with another instance's onconfig + sqlhosts as templates
 -> oninit -ivy       will, among other things, invoke buildsmi to create sysmaster db
IF, at this point, you have not properly updated your new sqlhosts file, so your INFORMIXSERVER entry in that file would still point to that other instance, you'd attempt to recreate that instance's sysmaster ... and corrupt it.

Should no longer be possible starting with 12.10.xC13.

------------------------------
Andreas Legner
------------------------------

Thanks Andreas ... not our issue but good to know. Reminds me of teaching the IDS sys admin class and one student had the same col4 for their shared memory connection as another student. One of the students would add a dbspace and wouldn't see it, but it would end up in the other students' engine. Whichever engine "came up last" created the shmem connection helper and pointed to that engine. Back then we had limited hardware, etc. and they'd use the same box, same INFORMIXDIR, etc. and therefore, the other student was using this students shmem helper file. (Yeah - "shmem helper" is odd - can't remember if it was the .infos or what ...) 

For the sysmaster stuff disappearing, we'd never do an -ivy on this box as it's production plus we have FULL_DISK_INIT as we're on 12.10 so... The test/dev boxes can't even reach the prod box. 

Thanks1 
Mark

------------------------------
Mark Scranton
------------------------------

Original Message:
Sent: Wed September 08, 2021 12:18 PM
From: Andreas Legner
Subject: sysmaster tables gone

Might be a known problem: "buildsmi script would corrupt sysmaster (remove all SMI pseudo tables) if ran while other session has sysmaster db open"

One way to incur this: you're creating a new instance, with another instance's onconfig + sqlhosts as templates
 -> oninit -ivy       will, among other things, invoke buildsmi to create sysmaster db
IF, at this point, you have not properly updated your new sqlhosts file, so your INFORMIXSERVER entry in that file would still point to that other instance, you'd attempt to recreate that instance's sysmaster ... and corrupt it.

Should no longer be possible starting with 12.10.xC13.

------------------------------
Andreas Legner
------------------------------