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 WAS configuration, you empty the messaging engine data store.

CAUTION:

• When you empty the data store, all of the persistent messages that were held are lost and any destinations 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.

1. Ensure that the messaging engine and application server are stopped.

2. Empty the data store. There are several ways to achieve this:

   1. For 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.

      Important: For the same database for application data, you 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 the Derby database, delete this too. If we find that we cannot delete the files, confirm that the application server is also stopped (if you stop the messaging engine but not the application server, we cannot delete the files).

   2. For the Derby Network Server database, use a similar procedure but also stop Derby Network Server before we delete the files. We must restart Derby Network Server before starting the messaging engine.The USER_INSTALL_ROOT for WebSphere Application Server Network Deployment is usually changed when installing WebSphere Application Server (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. For any other RDBMS, empty the data store tables using the administration tools of the 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.

      If we have enabled WebSphere Application Server 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 WebSphere Application Server (base) to create the data store tables, you must recreate the tables that you drop before you start the messaging engine.

      We can 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.

Related

sibDDLGenerator command