Stop and start websphere: dmgr, nodes, and application servers

Let's see a quick example of commands to stop and start all websphere java process of an environment with this logical topology:

The cluster in the example is logically built with 2 application server running on each node.

(*) Physically the deployment manager can reside on the first node for example and the application servers are running on the nodes.

START:

<node1>
was_dir/AppServer/profiles/Dmgr01/bin/startManager.sh                 (*)
was_dir/AppServer/profiles/AppSrv01/bin/startNode.sh
was_dir/AppServer/profiles/AppSrv01/bin/startServer.sh Server1
was_dir/AppServer/profiles/AppSrv01/bin/startServer.sh Server2
...
<nodeN>
was_dir/AppServer/profiles/AppSrv01/bin/startNode.sh
was_dir/AppServer/profiles/AppSrv01/bin/startServer.sh ServerN-1
was_dir/AppServer/profiles/AppSrv01/bin/startServer.sh ServerN

STOP:

<nodeN>

was_dir/AppServer/profiles/AppSrv01/bin/stopServer.sh ServerN-1 -user user -password xyz

was_dir/AppServer/profiles/AppSrv01/bin/stopServer.sh ServerN -user user -password xyz

was_dir/AppServer/profiles/AppSrv01/bin/stopNode.sh -user user -password xyz

...

<node1>

was_dir/AppServer/profiles/AppSrv01/bin/stopServer.sh Server1 -user user -password xyz

was_dir/AppServer/profiles/AppSrv01/bin/stopServer.sh Server2 -user user -password xyz

was_dir/AppServer/profiles/AppSrv01/bin/stopNode.sh -user user -password xyz

was_dir/AppServer/profiles/Dmgr01/bin/stopManager.sh -user user -password xyz

user is the websphere administrative user.

Compare performances of a query on differents db2 environments

If you have a product running on two different environments (i.e. sandbox and pre-production) using db2 as database, and you have different performance in terms of response times and you have the suspect that is related to some query, then my suggestion is first to identify what are the slowest queries analyzing the db2 snapshots (or using the monitor table functions) checking the worst cpu consumption and execution time, then run the db2 explain command on both enviroments and analyze the access plan of the queries.

For example write one of the slowest queries in a file and at the end of the file insert a terminator: @

Access to the db2 instance and run:


 db2expln -g -database DBNAME -stmtfile /tmp/query.sql -terminator @ -terminal -o /tmp/output_explain.txt


The output file contains Estimated Cost and Estimated Cardinality and the Optimizer Plan.
You can compare these values and the differences of the access plan. In case of access plan differences you can identify what are the most expensive operations. Then for example you can check if there are some indexes or views that are missing in one of the environments but already defined in the other one or simply check if you have forgotten to run the maintenance commands: reorg, runstats, rebind.