WebSphere Reverse Investor: Are you sure you want to reorganize the Messaging Engine database?

In each column, "WebSphere contrarian investors" will answer questions, provide guidance and discuss the underlying topics associated with WebSphere products, often giving proven recommendations that contradict popular perceptions.

Swamp Monsters

I recently responded to an email query that resulted in a series of more emails in the course of a few days, prompting me to recall a proverb that my former manager liked very much:

When you fall into the crocodile's mouth, it's easy to forget why you wanted to drain the swamp water.

You ask, what does this remind you of? To get to the question, the enquiry is to consult "IBM's recommendations to the customers who are running DB2 reorganization and runstat of the Messaging Engine database", although I do not think I am speaking in Plenipotentiary IBM, my advice is not to worry about doing that. Because I don't like crocodiles, I usually try to avoid draining the swamp water, although it seems clear to me why the swamp may not need to be drained-or, for this example, why you don't need to run database utilities on the Messaging Engine database-but this is not a good idea for the customer. Although I'm not sure if the client was eventually persuaded, I think I should be here to share with you my rationale and approach so that you can decide what might be best for your environment.

Investigating the Swamp

It is always advisable to investigate the swamp water before draining it. In the case of the Messaging Engine database, you can start your survey in the WebSphere application Server Information Center, which provides information about the structure of the database:

Table 1. Message database table

Table	Use
Sibowner	Ensure that an active Messaging engine has exclusive access to the data store.
Sibclassmap	Catalogs different object types in the data store.
Siblisting	Catalog the sibnnn table.
Sibxacts	The status of the two-phase commit transaction for the maintenance activity.
Sibkeys	Assigns a unique identifier to an object in the Messaging engine.
SIBNNN, where nnn is the number	Contains persisted objects, such as messages and subscription information, that contain both persistent and non-persistent objects and use separate tables for different types of data.

One of the issues that bothers customers is the Sibowner table that contains exclusive locks, which are described in the WebSphere application Server Information Center, which is stated in the excerpt:

The Sibowner table in the data store contains locks as a pair of unique identifiers in a single row. The Messaging engine uses both identifiers to acquire and maintain its exclusive locks at startup:

Meuuid

The unique identifier of the message engine, which remains the same whenever the messaging engine starts and stops.

Incuuid

The specific identifier of the message engine, which is changed each time the message engine starts.

These identifiers determine which messaging engine is using a data store. These identifiers also determine whether the running instance of the Messaging Engine maintains its exclusive locks during the period during which it is run.

When the Messaging engine starts, it obtains an exclusive table lock on the Sibowner table.

The result of the message engine owning an exclusive lock is that the database Maintenance utility cannot be run in the preferred manner, which is intended to maintain all tables in the database.

Need to be reformed?

Now that you know the general situation of the swamp--the database--do you really need to row it? You can view the contents of the following table by stopping the messaging engine that is using the Messaging Engine database:

>db2　select　*　from　ibmme0.sibowner

ME_UUID　　　　　INC_UUID　　　　　VERSION　　　MIGRATION_VERSION
----------------　----------------　-----------　-----------------
E4C0B7CC5E3B76D3　4C224C2252CE2BDD　　　　　　1　　　　　　　　　0

1　record(s)　selected.