Emptying the data store for a messaging engine

By emptying the data store of a messaging engine, we can discard persistent operating information without deleting the messaging engine.

Persistent operating information for a messaging engine is stored as persistent messages and associated information about message delivery and transmission. To discard this information without deleting the messaging engine and its destinations from the WebSphere Application Server configuration, you empty the messaging engine data store.

CAUTION:

• When we empty the data store, all of the persistent messages that were held are lost and any destinations that we created continue to exist.
• Be very careful to completely empty the data store. You get unpredictable behavior if the data store is only partially emptied.

Tasks

1. Ensure that the messaging engine and application server are stopped.
2. Empty the data store. There are several ways to achieve this:

   1. If we are using the embedded Derby database (as the default data store does) and the database contains just the tables for the messaging engine data store, delete the files that the database uses. This deletes the database. When the messaging engine is next started, it creates an empty database to replace it.

      If we are using the same database for application data, we must instead empty the data store tables as described for any other RDBMS in a subsequent step.

      1. Find the database data directory in the file system. The name of the directory containing the files used by the database is the same as the name of the database in the configuration of the JDBC data source used by the messaging engine data store. By default, this is

          ${USER_INSTALL_ROOT}/profiles/dmgr/databases/com.ibm.ws.sib/messagingEngineName
         

      2. Delete the directory. If we have configured a separate log directory for our Derby database, delete this too. If we find that we cannot delete the files, confirm that the application server is also stopped (if we stop the messaging engine but not the application server, we cannot delete the files).

   2. If we are using the Derby Network Server database, use a similar procedure but also stop Derby Network Server before you delete the files. We must restart Derby Network Server before starting the messaging engine.The USER_INSTALL_ROOT for WAS Network Deployment is usually changed when installing WAS (base). We might not find the data store in ${USER_INSTALL_ROOT}/profiles/dmgr but in ${USER_INSTALL_ROOT}/profiles/profileName, where profileName is the name you gave at installation.

   3. If we are using any other RDBMS, empty the data store tables using the administration tools of our RDBMS. We can either remove all data from the tables, or drop and recreate the tables.

      Most RDBMS support the TRUNCATE TABLE statement that removes all data from the tables. This is the preferred way of emptying the data store tables because it leaves the tables and their authorizations intact.

      If we RDBMS does not support the TRUNCATE TABLE statement (for example, DB2 does not), we can use the DELETE statement to delete all of the rows from all of the tables. However, if the tables contain a lot of data, this might not be practical because of resource limitations in the RDBMS. In this case, drop the tables and recreate them with the required indices and authorities.

      Tip: If we have enabled WAS to create the data store tables, we can drop the tables using the DROP TABLE statement. When the messaging engine is next started, it creates empty tables to replace them. If we have not enabled WAS (base) to create the data store tables, we must recreate the tables that you drop before starting the messaging engine.

      Tip: Use the -drop option of the sibDDLGenerator command to generate DDL to drop the tables.

      Optional: If we have deleted the messaging engine by removing it from the bus, we can now recreate it.

3. Start the messaging engine and the application server.

sibDDLGenerator command