rebuild sysadmin automatically ?

Folks, IDS12.10 FC4, Linux 6. I worked with a non-operational instance, after run, EXECUTE FUNCTION task("reset sysadmin","dbdw00");The log showed, 13:52:32 Maximum server connections 6 13:52:32 Checkpoint Statistics - Avg. Txn Block Time 0.000, # Txns blocked 0, Plog used 9, Llog used 2 14:01:48 SCHAPI: thread dbWorker1 task mon_memory_system(8-17288) shutting down 14:01:48 SCHAPI: thread dbWorker2 task mon_checkpoint(7-34555) shutting down 14:01:48 SCHAPI: thread dbScheduler(70) shutting down 14:01:57 SCHAPI: 'sysadmin' database will be moved to 'dbdw00'. See online message log. 14:01:57 Building 'sysadmin' database ... 14:02:32 Checkpoint Completed: duration was 0 seconds. 14:02:32 Wed Jul 1 - loguniq 321, logpos 0x1f3c4018, timestamp: 0x4fd56ab1 Interval: 197315 14:02:32 Maximum server connections 6 14:02:32 Checkpoint Statistics - Avg. Txn Block Time 0.000, # Txns blocked 0, Plog used 5, Llog used 4 14:06:57 SCHAPI: SQL Error -349, ISAM Error 0 in file /usr/informix/etc/sysadmin/db_install.sql at line 29 14:06:57 Error building 'sysadmin' database. 14:07:32 Checkpoint Completed: duration was 0 seconds. 14:07:32 Wed Jul 1 - loguniq 321, logpos 0x1f3c7018, timestamp: 0x4fd56d8a Interval: 197316 14:07:32 Maximum server connections 6 14:07:32 Checkpoint Statistics - Avg. Txn Block Time 0.000, # Txns blocked 0, Plog used 11, Llog used 3 Then, I checked, the sysadmin database was gone. I shut it down and restarted it, the log showed, :29:35 Logical Recovery Started. 21:29:35 10 recovery worker threads will be started. 21:29:36 Logical Recovery has reached the transaction cleanup phase. 21:29:36 Logical Recovery Complete. 1 Committed, 0 Rolled Back, 0 Open, 0 Bad Locks 21:29:37 Dataskip is now OFF for all dbspaces 21:29:37 Checkpoint Completed: duration was 0 seconds. 21:29:37 Wed Jul 1 - loguniq 322, logpos 0x30c0, timestamp: 0x4fd66011 Interval: 197350 21:29:37 Maximum server connections 0 21:29:37 Checkpoint Statistics - Avg. Txn Block Time 0.000, # Txns blocked 0, Plog used 14, Llog used 1 21:29:37 On-Line Mode 21:29:38 CDR GC: catalog recovery begin 21:29:39 Building 'sysadmin' database ... 21:29:40 Booting Language <spl> from module <> 21:29:40 Loading Module <SPLNULL> 21:29:40 CDR GC: catalog recovery complete 21:29:40 CDR queuer initialization complete 21:29:40 CDR NIF listening on asf://g_nsofdev1 21:29:41 DDR Log Snooping - Snooping started in log 322 21:29:41 CDR: Re-connected to server, id 12, name <g_nsofdev2> 21:29:41 'sysadmin' database built successfully. 21:29:41 SCHAPI: Started dbScheduler thread. 21:29:41 Auto Registration is synced 21:29:41 Updating Low Memory Manager to version 11 21:29:41 Installing patch to upgrade ph_task code. version(13.04) 21:29:41 SCHAPI: Started 2 dbWorker threads. 21:29:41 Checkpoint Completed: duration was 0 seconds. You can see the sysadmin database was rebuilt automatically. So, the question is, when the sysadmin database is dropped by running " reset sysadmin" , bouncing server will always get it rebuilt ? If yes, then why we need manual building script? if not, then in what case i it will not rebuild automatically ? Thanks Frank --001a11479476625c7e0519d751c2

Frank: Yes, every time the server is started and it see's that the sysadmin database does not exist it will create it. Who said those are manual build scripts? Those are the exact scripts which the server executes to build and populate the database. John F. Miller III STSM, Lead Architect miller3@us.ibm.com 503-747-1366 IBM Informix Dynamic Server (IDS) ids-bounces@iiug.org wrote on 07/01/2015 02:51:00 PM: > From: "FRANK" <yunyaoqu@gmail.com> > To: ids@iiug.org > Date: 07/01/2015 02:51 PM > Subject: rebuild sysadmin automatically ? [35378] > Sent by: ids-bounces@iiug.org > > Folks, > > IDS12.10 FC4, Linux 6. > > I worked with a non-operational instance, after run, > > EXECUTE FUNCTION task("reset sysadmin","dbdw00");> The log showed, > > 13:52:32 Maximum server connections 6 > 13:52:32 Checkpoint Statistics - Avg. Txn Block Time 0.000, # Txns blocked > 0, Plog used 9, Llog used 2 > 14:01:48 SCHAPI: thread dbWorker1 task mon=5Fmemory=5Fsystem(8-17288) shutting > down > 14:01:48 SCHAPI: thread dbWorker2 task mon=5Fcheckpoint(7-34555) shutting > down > 14:01:48 SCHAPI: thread dbScheduler(70) shutting down > 14:01:57 SCHAPI: 'sysadmin' database will be moved to 'dbdw00'. See online > message log. > 14:01:57 Building 'sysadmin' database ... > 14:02:32 Checkpoint Completed: duration was 0 seconds. > 14:02:32 Wed Jul 1 - loguniq 321, logpos 0x1f3c4018, timestamp: > 0x4fd56ab1 Interval: 197315 > 14:02:32 Maximum server connections 6 > 14:02:32 Checkpoint Statistics - Avg. Txn Block Time 0.000, # Txns blocked > 0, Plog used 5, Llog used 4 > 14:06:57 SCHAPI: SQL Error -349, ISAM Error 0 in file > /usr/informix/etc/sysadmin/db=5Finstall.sql at line 29 > 14:06:57 Error building 'sysadmin' database. > 14:07:32 Checkpoint Completed: duration was 0 seconds. > 14:07:32 Wed Jul 1 - loguniq 321, logpos 0x1f3c7018, timestamp: > 0x4fd56d8a Interval: 197316 > 14:07:32 Maximum server connections 6 > 14:07:32 Checkpoint Statistics - Avg. Txn Block Time 0.000, # Txns blocked > 0, Plog used 11, Llog used 3 > > Then, I checked, the sysadmin database was gone. > > I shut it down and restarted it, the log showed, > > :29:35 Logical Recovery Started. > 21:29:35 10 recovery worker threads will be started. > 21:29:36 Logical Recovery has reached the transaction cleanup phase. > 21:29:36 Logical Recovery Complete. > > 1 Committed, 0 Rolled Back, 0 Open, 0 Bad Locks > 21:29:37 Dataskip is now OFF for all dbspaces > 21:29:37 Checkpoint Completed: duration was 0 seconds. > 21:29:37 Wed Jul 1 - loguniq 322, logpos 0x30c0, timestamp: 0x4fd66011 > Interval: 197350 > 21:29:37 Maximum server connections 0 > 21:29:37 Checkpoint Statistics - Avg. Txn Block Time 0.000, # Txns blocked > 0, Plog used 14, Llog used 1 > 21:29:37 On-Line Mode > 21:29:38 CDR GC: catalog recovery begin > 21:29:39 Building 'sysadmin' database ... > 21:29:40 Booting Language <spl> from module <> > 21:29:40 Loading Module <SPLNULL> > 21:29:40 CDR GC: catalog recovery complete > 21:29:40 CDR queuer initialization complete > 21:29:40 CDR NIF listening on asf://g=5Fnsofdev1 > 21:29:41 DDR Log Snooping - Snooping started in log 322 > 21:29:41 CDR: Re-connected to server, id 12, name <g=5Fnsofdev2> > 21:29:41 'sysadmin' database built successfully. > 21:29:41 SCHAPI: Started dbScheduler thread. > 21:29:41 Auto Registration is synced > 21:29:41 Updating Low Memory Manager to version 11 > 21:29:41 Installing patch to upgrade ph=5Ftask code. version(13.04) > 21:29:41 SCHAPI: Started 2 dbWorker threads. > 21:29:41 Checkpoint Completed: duration was 0 seconds. > > You can see the sysadmin database was rebuilt automatically. > > So, the question is, > when the sysadmin database is dropped by running " reset sysadmin" , > bouncing server will always get it rebuilt ? If yes, then why we need > manual building script? if not, then in what case i it will not > rebuild automatically ? > > Thanks > Frank > > --001a11479476625c7e0519d751c2 > > > ***************************************************************************= **** > Forum Note: Use "Reply" to post a response in the discussion forum. >

Just touch file 'stop' in $INFORMIXDIR/etc/sysadmin , then sysadmin won't rebuild or start..

Not a good idea in v12.10! IBM says that there are several internal operations that depend on sysadmin and the task manager! Art Art S. Kagel, President and Principal Consultant ASK Database Management www.askdbmgt.com Blog: http://informix-myview.blogspot.com/ Disclaimer: Please keep in mind that my own opinions are my own opinions and do not reflect on the IIUG, nor any other organization with which I am associated either explicitly, implicitly, or by inference. Neither do those opinions reflect those of other individuals affiliated with any entity with which I am affiliated nor those of the entities themselves. On Sat, Jul 4, 2015 at 10:48 AM, NETSKY LIAO <liaosnet@126.com> wrote: > Just touch file 'stop' in $INFORMIXDIR/etc/sysadmin , then sysadmin won't > rebuild or start.. > > > > ******************************************************************************* > Forum Note: Use "Reply" to post a response in the discussion forum. > > --001a113ec89289965a051a16eb99

Can someone from IBM please confirm what depends on sysadmin and the scheduler? Regards, David. > On 05 July 2015 at 02:43 Art Kagel <art.kagel@gmail.com> wrote: > > > Not a good idea in v12.10! IBM says that there are several internal > operations that depend on sysadmin and the task manager! > > Art > > Art S. Kagel, President and Principal Consultant > ASK Database Management > www.askdbmgt.com > > Blog: http://informix-myview.blogspot.com/ > > Disclaimer: Please keep in mind that my own opinions are my own opinions > and do not reflect on the IIUG, nor any other organization with which I am > associated either explicitly, implicitly, or by inference. Neither do > those opinions reflect those of other individuals affiliated with any > entity with which I am affiliated nor those of the entities themselves. > > On Sat, Jul 4, 2015 at 10:48 AM, NETSKY LIAO <liaosnet@126.com> wrote: > > > Just touch file 'stop' in $INFORMIXDIR/etc/sysadmin , then sysadmin won't > > rebuild or start.. > > > > > > > > > ******************************************************************************* > > Forum Note: Use "Reply" to post a response in the discussion forum. > > > > > > --001a113ec89289965a051a16eb99 > > > ******************************************************************************* > Forum Note: Use "Reply" to post a response in the discussion forum. >

I don´t believe someone will give you a direct answer on what components use the sysadmin database, given the fact that it's where the SQL administration API resides it's suffice to say don't drop it or alter. Besides the SQL administration API and the Scheduler, since version 11.70 sysadmin comes with the storagepool table that has information about all the Storage Pool entities. From the 12.10 it was added the tenant table that keeps all the Tenant databases that exists in the IDS. The strange thing is that $INFORMIXDIR/etc/sysadmin/stop flag will prevent the rebuild of the sysadmin database when bouncing the engine, when I believe it should just disable the scheduler. But then we have the question, is it safe to disable the scheduler or are any internal components using it? Safest way to go around, move the sysadmin to a dbspace of its own and disable the tasks and schedulers you don't want to use, not the scheduler. On Sun, 5 Jul 2015 at 10:25 david@smooth1.co.uk <david@smooth1.co.uk> wrote: > Can someone from IBM please confirm what depends on sysadmin and the > scheduler? > > Regards, > David. > > > On 05 July 2015 at 02:43 Art Kagel <art.kagel@gmail.com> wrote: > > > > > > Not a good idea in v12.10! IBM says that there are several internal > > operations that depend on sysadmin and the task manager! > > > > Art > > > > Art S. Kagel, President and Principal Consultant > > ASK Database Management > > www.askdbmgt.com > > > > Blog: http://informix-myview.blogspot.com/ > > > > Disclaimer: Please keep in mind that my own opinions are my own opinions > > and do not reflect on the IIUG, nor any other organization with which I > am > > associated either explicitly, implicitly, or by inference. Neither do > > those opinions reflect those of other individuals affiliated with any > > entity with which I am affiliated nor those of the entities themselves. > > > > On Sat, Jul 4, 2015 at 10:48 AM, NETSKY LIAO <liaosnet@126.com> wrote: > > > > > Just touch file 'stop' in $INFORMIXDIR/etc/sysadmin , then sysadmin > won't > > > rebuild or start.. > > > > > > > > > > > > > > > > ******************************************************************************* > > > Forum Note: Use "Reply" to post a response in the discussion forum. > > > > > > > > > > --001a113ec89289965a051a16eb99 > > > > > > > > ******************************************************************************* > > Forum Note: Use "Reply" to post a response in the discussion forum. > > > > > > ******************************************************************************* > Forum Note: Use "Reply" to post a response in the discussion forum. > > --f46d044304c4d467b0051a32aa99