Handling unexpected shutdowns

Note: Make sure that there are no other Launcher systems running on the target DBMS before running the maintenance operations listed below.

If an Launcher system (containing database triggers) has encountered an unexpected shutdown and cannot be re-started and subsequently shut down in a normal sequence, you must re-run the triggering installation script (specific to your database) to clean up any triggering resources that have been left behind on the target DBMS. This is because when an Launcher is prematurely shut down, any defined database triggers will remain in operation on the backend DBMS (for example, Oracle) until the same system is re-started and then properly shut down.

The database triggers will continue to monitor for events while the Launcher is shut down, thus enabling the system to be fault-tolerant with respect to any database changes that occur during an unexpected downtime. This fault-tolerant behavior requires that a normal system shutdown eventually take place. Otherwise, the database triggers will continually remain in operation, taking up processing and space resources on the target DBMS.

If the triggering installation script cannot be run, a temporary solution would be to run the following SQL statements on the target DBMS:

  1. DELETE FROM Trigger_Events;
  2. DELETE FROM Trigger_Registry;
  3. COMMIT;