IDS Forum

Re: "IDS seems to have shutdown cleanly"

Posted By: Art Kagel
Date: Monday, 7 May 2012, at 9:32 a.m.

In Response To: Re: "IDS seems to have shutdown cleanly" (FRANK J. COMPUTER)

See below, inline:

Art

Art S. Kagel
Advanced DataTools (www.advancedatatools.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 my employer, Advanced DataTools, 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 Mon, May 7, 2012 at 7:26 AM, FRANK J. COMPUTER
<frank_in_pr@hotmail.com>wrote:

> Hmm, so wouldn't a better message be "onclean didn't find any problem that
> needed cleaning"?.. the "seems" made me feel like IDS could not totally
> guarantee that any problems were detected!..
>

That's a tomayto/tomahto issue really.

>
> Let me ask you this: I know for a fact that if an SE server crashes, it
> has no
> way of detecting that it crashed or that the client processes are notified
> that it crashed so that they can run an exception routine to perhaps
> gracefully exit.
>

That's because SE has no central server to crash. Each client is really
running its own private copy of the server.

>
> Now if IDS 11.70 crashes, is it aware it crashed, log an alarm in an OS
> logfile, signal client processes, or provide an automated mechanism for
> repair
> and restarting the server?
>

Yes, yes, and yes. The server not only knows that it is in the process of
crashing, but it knows at the time you restart it that it had crashed and
had not shut down normally. There are several mechanisms that make that
happen. First, there are three virtual processors (oninit processes), the
ADM VP, the MSC VP, and the first CPU VP that watch each other and the
other virtual processors. If any of these three crash the others instigate
an emergency shutdown to prevent disk corruption. If any of the other VPs
crash they clean up locks and latches held by the crashed VP and start a
new one to replace it. Second, when the engine is running its current run
state is recorded on the 0th page of the root chunk. During a normal
shutdown that state is updated to indicate a normal shutdown. If the
server starts up and the recorded state is not <down> then the server knows
that it may have to run through recovery. Third, during normal shutdown a
hard checkpoint is performed which flushes the logical log buffers to disk,
writes all dirty pages from the buffer cache to disk, and empties the
physical log since it is no longer needed. If the server starts up and the
current length of the physical log is not zero then again, it knows that it
must perform a recovery which entails restoring the physical log pages to
disk to get a clean slate as if the previous checkpoint to which it can
apply the logical log records, then it rolls forward the logical log
transaction records beginning at the last completed checkpoint up to the
end of the logical logs and rolls back any incomplete transactions. Only
then is the server state changed to <online> and the server made available
to users.

As far as alarming the crash event, there are two scripts, the ALARMPROGRAM
and the SYSALARMPROGRAM, which are executed when certain events happen.
When the server is crashing, depending on which VP detected the crash, one
of these scripts will be executed with arguments indicating the event that
caused the alarm to trigger. The contents of the scripts determines what
happens then. If the SYSALARMPROGRAM is the one that triggered, by default
it performs some memory and core dumps and some onstats that tech support
can use later to diagnose a recurring problem. Normally the ALARMPROGRAM
default code for most events is to do nothing unless you change the script
that is run or modify the delivered default script. Obviously if the whole
machine crashes, nothing is logged or noted.

>
> I recently changed RA_PAGES to 256, and RA_THRESHOLS to 128 in
> INFORMIXDIR\etc\onconfig.ol_informix1170 and when I tried to connect to it,
> with DBACCESS, it displayed "Running..." and froze up, forcing me to close
> the
> window. Now it wont connect anymore!
>

That is not because of the changes you made. Indeed RA_THRESHOLD is
deprecated in 11.70 and is ignored and RA_PAGES is also deprecated, but
still active. However it should no longer be used in favor of the new
AUTO_READAHEAD parameter (RA_PAGES will override the pages setting of
AUTO_READAHEAD if present and set). The readahead values you set are very
high, and I don't tune them that way myself because most of the servers I
deal with are reading from SANs which have lots of cache and do readahead
and which have intelligent drive controllers which themselves have cache
and perform readahead and which are managing SCSI or SATA/PATA drives which
are intelligent and have on-board cache and do their own readahead. I
simply don't see the purpose to wasting server cache on readahead when all
that readahead data is available from downstream rather cheaply. Anyway,
side issue, the main point is you didn't cause the problem with your tuning
changes.

What you have encountered is a know problem running on Windows, it never
happens on Linux/Unix. On my laptop (WinXP) I have two servers that used
to start up on boot up. At some point, for no reason I have ever
determined, they stopped accepting connections, though they would start up
and shutdown normally every time. I have reinstalled and even upgraded the
instance's versions to no avail. I no longer start them at all. I have my
Linux engine on my home desktop and I have Linux VMs running Innovator
Edition and Developer Edition on the laptop that I can start up when I need
access to an Informix instance, so I have not pursued the problem with
support. I don't like Windows and just don't personally care if the
problem gets solved frankly.

On the other hand, you apparently have a vested interest in running Windows
based servers, so I would suggest calling tech support and seeing what they
have to say about it.

>
>
>
> *******************************************************************************
> Forum Note: Use "Reply" to post a response in the discussion forum.
>
>

--047d7b15a9036f808b04bf724cdc

Messages In This Thread

• "IDS seems to have shutdown cleanly"
  FRANK J. COMPUTER -- Monday, 7 May 2012, at 1:36 a.m.
  • Re: "IDS seems to have shutdown cleanly"
    Art Kagel -- Monday, 7 May 2012, at 6:14 a.m.
    • Re: "IDS seems to have shutdown cleanly"
      FRANK J. COMPUTER -- Monday, 7 May 2012, at 7:26 a.m.
      • Re: "IDS seems to have shutdown cleanly"
        Art Kagel -- Monday, 7 May 2012, at 9:32 a.m.
        • Re: "IDS seems to have shutdown cleanly"
          FRANK J. COMPUTER -- Monday, 7 May 2012, at 5:23 p.m.
          • Re: "IDS seems to have shutdown cleanly"
            Art Kagel -- Monday, 7 May 2012, at 6:26 p.m.
          • Re: "IDS seems to have shutdown cleanly"
            Chuck Renaud -- Monday, 7 May 2012, at 8:39 p.m.
            • Re: "IDS seems to have shutdown cleanly"
              FRANK J. COMPUTER -- Tuesday, 8 May 2012, at 6:05 p.m.
              • Re: "IDS seems to have shutdown cleanly"
                Fernando Nunes -- Tuesday, 8 May 2012, at 6:21 p.m.
                • Re: "IDS seems to have shutdown cleanly"
                  FRANK J. COMPUTER -- Tuesday, 8 May 2012, at 6:36 p.m.

IDS Forum is maintained by Administrator with WebBBS 5.12.