Using sysadmin db in multi-instance env

We have a very important client that has many instances (65) 11.50.FC8 AIX setup on one frame using just one common $INFORMIXDIR. They want to implement OAT (and sysadmin db for remote admin) for the largest "main" instance but not for the remaining 64 instances as they do not want the sysadmin db to be created for these instances. To invalidate for the remaining instances requires placing a file called stop in $INFORMIXDIR/etc/sysadmin which will also invalidate spawning the dbworker threads on the main instance on startup . Any ways of working around this ? One idea that comes to mind is to start the main instance, sleep for a duration, create the stop file and then continue staring the other instances in the rc.informix file. However this can cause some grief if instances have to be started/stopped on their own etc. as you have to constantly check for the existance of the stop file. Be great if the "stop" file was created at the instance level($INFORMIXDIR/etc/sysadmin/<servernum>). Thanks, Mark

We could also benefit from this. I will be watching. Thanx Mark. Dan -----Original Message----- From: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org] On Behalf Of MARK JALKIEWICZ Sent: Thursday, August 11, 2011 9:39 AM To: ids@iiug.org Subject: Using sysadmin db in multi-instance env [24599] We have a very important client that has many instances (65) 11.50.FC8 AIX setup on one frame using just one common $INFORMIXDIR. They want to implement OAT (and sysadmin db for remote admin) for the largest "main" instance but not for the remaining 64 instances as they do not want the sysadmin db to be created for these instances. To invalidate for the remaining instances requires placing a file called stop in $INFORMIXDIR/etc/sysadmin which will also invalidate spawning the dbworker threads on the main instance on startup .. Any ways of working around this ? One idea that comes to mind is to start the main instance, sleep for a duration, create the stop file and then continue staring the other instances in the rc.informix file. However this can cause some grief if instances have to be started/stopped on their own etc. as you have to constantly check for the existance of the stop file. Be great if the "stop" file was created at the instance level($INFORMIXDIR/etc/sysadmin/<servernum>). Thanks, Mark ******************************************************************************* Forum Note: Use "Reply" to post a response in the discussion forum.

Why not have a seperate INFORMIXDIR for the one system that they want to use the sysadmin api on? From: "Dan Mueller" <Dan.Mueller@trnswrks.com> To: ids@iiug.org Date: 08/11/2011 07:50 AM Subject: RE: Using sysadmin db in multi-instance env [24600] Sent by: ids-bounces@iiug.org We could also benefit from this. I will be watching. Thanx Mark. Dan -----Original Message----- From: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org] On Behalf Of MARK JALKIEWICZ Sent: Thursday, August 11, 2011 9:39 AM To: ids@iiug.org Subject: Using sysadmin db in multi-instance env [24599] We have a very important client that has many instances (65) 11.50.FC8 AIX setup on one frame using just one common $INFORMIXDIR. They want to implement OAT (and sysadmin db for remote admin) for the largest "main" instance but not for the remaining 64 instances as they do not want the sysadmin db to be created for these instances. To invalidate for the remaining instances requires placing a file called stop in $INFORMIXDIR/etc/sysadmin which will also invalidate spawning the dbworker threads on the main instance on startup ... Any ways of working around this ? One idea that comes to mind is to start the main instance, sleep for a duration, create the stop file and then continue staring the other instances in the rc.informix file. However this can cause some grief if instances have to be started/stopped on their own etc. as you have to constantly check for the existance of the stop file. Be great if the "stop" file was created at the instance level($INFORMIXDIR/etc/sysadmin/<servernum>). Thanks, Mark ******************************************************************************* Forum Note: Use "Reply" to post a response in the discussion forum. ******************************************************************************* Forum Note: Use "Reply" to post a response in the discussion forum.

If you search for an old Jonathan Leffler presentation called something like "Paranoid DBA" you will see that he suggests to have a "virtual" INFORMIXDIR. This is a physical dir in which several links are created and some dirs exist. For example... In the "/usr/informix/ids11.50.fc8" directory you have the product installed. Than you create /usr/informix/ids11.50.fc8_INFORMIXSERVER for the "special" instance. This is a directory with several links to the main product dir and a few "full directories" like etc, aaodir, dbssodir.... O you'd have something like ln -s /usr/informix/ids11.50.fc8/bin /usr/informix/ids11.50.fc8_INFORMIXSERVER ln -s /usr/informix/ids11.50.fc8/msg /usr/informix/ids11.50.fc8_INFORMIXSERVER I have a script that does this automatically, if you're insterested. For the direcories that are not "linked" the original content is copied. This saves space and allows full separation of the important thngs. Nevertheless, yes, I agree that all the files should have specific names. And there are only a few exceptions that R&D should take care... Finally: 65 instances on the same host?! Are they trying to beat some record? :) Regards On Thu, Aug 11, 2011 at 2:38 PM, MARK JALKIEWICZ < mark.jalkiewicz@verizon.net> wrote: > We have a very important client that has many instances (65) 11.50.FC8 AIX > setup on one frame using just one common $INFORMIXDIR. They want to > implement > OAT (and sysadmin db for remote admin) for the largest "main" instance but > not > for the remaining 64 instances as they do not want the sysadmin db to be > created for these instances. To invalidate for the remaining instances > requires placing a file called stop in $INFORMIXDIR/etc/sysadmin which will > also invalidate spawning the dbworker threads on the main instance on > startup > .. Any ways of working around this ? > > One idea that comes to mind is to start the main instance, sleep for a > duration, create the stop file and then continue staring the other > instances > in the rc.informix file. However this can cause some grief if instances > have > to be started/stopped on their own etc. as you have to constantly check for > the existance of the stop file. > > Be great if the "stop" file was created at the instance > level($INFORMIXDIR/etc/sysadmin/<servernum>). > > Thanks, > > Mark > > > > ******************************************************************************* > Forum Note: Use "Reply" to post a response in the discussion forum. > > -- Fernando Nunes Portugal http://informix-technology.blogspot.com My email works... but I don't check it frequently... --000e0cd59e50a3edcf04aa3fdfa9