Personally, if I am maxappls, the system has a problem, so I am happy to have it
reported as down.  Whilst it is slightly misleading, for any new connections,
the system is effectively down.

Similarly, my production systems should be activated - so I don't consider the
connection an overhead.

Having said that, if my systems go down, the users tell me soon enough!!

Jeremy


"Fortier, Christi (USPC.PCT.Hopewell)" wrote:

> If you are at maxappls, then you won't be able to connect & you will get a
> false read that the databse is down when it actually is up.  If your
> database is not activated, then each connection has some overhead, so this
> is also invasive.
>
> Checking if the db2 services are started & parsing the db2diag log for
> errors is the way I use (Windows or Unix).  You can use a VB script to netIQ
> or a knowledge module in Patrol to monitor, or write an iterative health
> check script on your own that takes a pulse every n seconds at next point in
> the log.  Tailing the log is not acceptable, as when DB2 hits an error it
> sometimes logs many more lines than expected and a critical message can be
> missed.  In windows an event is written, but since that might be set to
> overwrite itself, I prefer the diag log.
>
> Some things I look for:
> internal error
> DIA[0-9][0-9][0=9][0-9]E
> RC=[1-9]
> severed
> [Ss]ortheap
> [Dd]isk [Ff]ull
> TCP
> Retry limit*node
> unreliable
> [Cc]orrupt
> [Bb]ad FAT
>  -1040
>
> Good luck!
> -----Original Message-----
> From: Ian D. Bjorhovde [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, November 13, 2001 2:04 PM
> To: [EMAIL PROTECTED]
> Subject: Re: DB2EUG: Best way to determine if DB2 is "up"?
>
> Steve,
>
> I like to create a table in a tablespace that exists on all
> partitions and then query the number of rows in the table.
> If I get the expected value, then I can be pretty sure that
> the database is up and all partitions are available.
>
> Good luck,
>
> Ian
>
> ----- Original Message -----
> From: <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Tuesday, November 13, 2001 9:29 AM
> Subject: DB2EUG: Best way to determine if DB2 is "up"?
>
> > Our system administrator wants me to give him a UNIX shell script that
> will
> > report to him on whether DB2 is up or down.  It's easy to determine if
> it's
> > down:  If there are no processes running for the instance owner, my shell
> > script just prints "DB2 is down" on his screen.  But it seems more
> > problematic to determine if everything that should be running is in fact
> > running.  He doesn't want me to simply display all of the DB2 instance
> > processes, since he can't be expected to be expert in knowing all the
> > processes of every application on every system that he administers.  My
> > question, then, is:  What is the best/most desirable indicator that the
> DB2
> > instance is "up" in every respect?  Would a successful attempt to connect
> > to the database do it?  Is there another, better approach?
> >
> > By the way, we are running DB2 UDB EEE 7.2 on AIX 4.3.3.0.
> >
> > Thanks.
> >
> > Steve Westfall
> > Equifax, Inc.
> >
> >
> >
> >
> > This message contains information from Equifax, Inc. which may be
> > confidential and privileged.  If you are not an intended recipient, please
> > refrain from any disclosure, copying, distribution or use of this
> > information and note that such actions are prohibited.  If you have
> > received this transmission in error, please notify by e:mail
> > [EMAIL PROTECTED]
> >
> >
> > =====
> > To unsubscribe, send 'unsubscribe' to [EMAIL PROTECTED]
> > For other info (and scripts), see
> http://people.mn.mediaone.net/scottrmcleod
> >
>
> =====
> To unsubscribe, send 'unsubscribe' to [EMAIL PROTECTED]
> For other info (and scripts), see http://people.mn.mediaone.net/scottrmcleod
>
> =====
> To unsubscribe, send 'unsubscribe' to [EMAIL PROTECTED]
> For other info (and scripts), see http://people.mn.mediaone.net/scottrmcleod


=====
To unsubscribe, send 'unsubscribe' to [EMAIL PROTECTED]
For other info (and scripts), see http://people.mn.mediaone.net/scottrmcleod

Reply via email to