How are multiple instances monitored? For example, there are 30
instances running on a AIX BOX running DB2 V8, is ps -ef |grep
"inst[0-2][0-9]" the best way to see if the instance is running, where
instanes are named inst01 thru inst29.
Or is this set up in tools like Health Monitor?

You can attach to any instance as long as you have it cataloged, and use
monitor or the control centre...

hikums@gmail.com wrote:
> How are multiple instances monitored? For example, there are 30
> instances running on a AIX BOX running DB2 V8, is ps -ef |grep
> "inst[0-2][0-9]" the best way to see if the instance is running, where
> instanes are named inst01 thru inst29.
> Or is this set up in tools like Health Monitor?
>

Let me rephrase:
I want to be able to tell if an instance is down when there are
multiple instances running in the machine. Is there a tool in DB2 UDB
that sends alerts when an instance is down? Or is there a way to easily
tell that an instance is down by looking at something in this case?



hikums@gmail.com wrote:
> How are multiple instances monitored? For example, there are 30
> instances running on a AIX BOX running DB2 V8, is ps -ef |grep
> "inst[0-2][0-9]" the best way to see if the instance is running,
where
> instanes are named inst01 thru inst29.
> Or is this set up in tools like Health Monitor?

One way to know the instance is down would be to try to attach to it (or
to take dbm snapshots over an attachment)...

hikums@gmail.com wrote:
> Let me rephrase:
> I want to be able to tell if an instance is down when there are
> multiple instances running in the machine. Is there a tool in DB2 UDB
> that sends alerts when an instance is down? Or is there a way to easily
> tell that an instance is down by looking at something in this case?
>
>
>
> hikums@gmail.com wrote:
>
>>How are multiple instances monitored? For example, there are 30
>>instances running on a AIX BOX running DB2 V8, is ps -ef |grep
>>"inst[0-2][0-9]" the best way to see if the instance is running,
>
> where
>
>>instanes are named inst01 thru inst29.
>>Or is this set up in tools like Health Monitor?
>
>

this is how we used to do this:

1) create a single "manager" instance on one of the less productivity
oriented machine.
2) Catalog a database from each of the instances in question at the
"manager" instance.
3) Create a shell/SQL script, the objective of which was to go and
connect to each database individually using the relevant credentials.
4)Apart from connecting to the individual databases, it was also
required to run a very small predefined ad-hoc query on all the
databases.
5) All the above task was logged in a log file, and the logfile was
monitored on a regular basis. We used crontab to schedule this
shell/SQL script.
6) Apart from the above mentioned script, we also used customized shell
scripts to notify us immediately, if and when a database went down
(deactivated). The script would then execute some steps to re-activate
that database.

I believe, most of this functionality can be achieved through IBM's GUI
utilities or maybe through some other 3rd party tools like DBArtisan or
so. I don't know much about them. However, above scheme worked for us,
and I should say worked well. :-)

regards,
dotyet

Looks to me like the Health Monitor has an indicator for instance
operational state:

db2.db2_op_status - Instance Operational State health indicator

The state can be one of the following: Active, Quiesce pending,
Quiesced, or Down.

See the System Monitor Guide and Reference.

Also, you can use Tivoli to monitor instances.

Larry Edelstein

dotyet wrote:
> this is how we used to do this:
>
> 1) create a single "manager" instance on one of the less productivity
> oriented machine.
> 2) Catalog a database from each of the instances in question at the
> "manager" instance.
> 3) Create a shell/SQL script, the objective of which was to go and
> connect to each database individually using the relevant credentials.
> 4)Apart from connecting to the individual databases, it was also
> required to run a very small predefined ad-hoc query on all the
> databases.
> 5) All the above task was logged in a log file, and the logfile was
> monitored on a regular basis. We used crontab to schedule this
> shell/SQL script.
> 6) Apart from the above mentioned script, we also used customized shell
> scripts to notify us immediately, if and when a database went down
> (deactivated). The script would then execute some steps to re-activate
> that database.
>
> I believe, most of this functionality can be achieved through IBM's GUI
> utilities or maybe through some other 3rd party tools like DBArtisan or
> so. I don't know much about them. However, above scheme worked for us,
> and I should say worked well. :-)
>
> regards,
> dotyet
>