Troubleshooting
Problem
You enable Data Movement Services (DMS) for a monitor model version and, in the dashboard, you cannot see any information about views that are related to the model.
Symptom
In the dashboard, you cannot see any information about views that are related to the model. DMS errors may be reported in the administrative console DMS (6.1.x) or Monitor scheduled services (6.2.x) screens, or in the WebSphere Business Monitor logs.
Cause
The steps taken to enable DMS were incorrect or incomplete, or the database resources relative to the DMS configuration are insufficient.
Resolving The Problem
Enabling data movement services when a monitor model is deployed
When you enable DMS when a monitor model is deployed, DMS is enabled before any events are received. Set the DMS interval depending on dashboard latency, event volume, and performance requirements. A high DMS interval can improve performance. However, the timeliness of dashboard updates might be affected, and potential resource problems might occur. Excessive database resources may be required if DMS is configured to execute infrequently and the volume of events to process is large.
When setting the DMS interval, consider the volume of events.
- For a large volume of events, keep DMS interval set to 5 minutes (the default). A 5-minute interval ensures that adequate resources are available for successful processing. This interval prevents the accumulation of events in the DCL table, which could potentially result in inadequate resources to successfully complete processing.
- For a small volume of events, the DMS interval can be higher than 5 minutes.
Note: Upon enablement, DMS is suspended for the model version. Configure the DMS interval and start the DMS service.
- On the administrative console, navigate to Monitor Services > Monitor Scheduled Services > model > Scheduled Services > Data Movement Services > Versions.
- Select the model and click Resume.
- The next time the scheduler wakes up (within 1 minute), it implements the DMS service based on the interval settings that you configured.
Enabling data movement services after a monitor model is deployed
When you enable DMS after a monitor model is deployed, DMS is enabled after a (potentially large) number of instances is being monitored. Follow these steps to ensure that DMS enablement is successful.
- To enable DMS on existing models, put WebSphere Business Monitor into maintenance mode. Note: Processing one model at a time is recommended.
- Stop the monitor model.
- Back up the database.
- Enable DMS for the model version. Note: Upon enablement, DMS is suspended for the model version so that, using the Run Now function, you can move existing instances before new events are consumed.
- On the administrative console, navigate to Monitor Services > Monitor Scheduled Services > model > Scheduled Services > Data Movement Services > Versions. Select the model and click Run Now. See Running a scheduled service now in Related information.
- On the administrative console, navigate to Monitor Services > Monitor Scheduled Services > model > Scheduled Services > Data Movement Services > Versions. Look for the value of Success on the last run. See Running a related service now in Related information.
- Wait for the DMS run to complete successfully. Validate that dashboards can still see the monitor instances after they are moved to the reporting tables.
- After you verify DMS enablement, you configure the DMS interval and start the DMS service. For information about configuring DMS intervals, see Enabling DMS when a monitor model is deployed.
- On the administrative console, navigate to Monitor Services > Monitor Scheduled Services > model > Scheduled Services > Data Movement Services > Versions. Select the model and click Resume. The next time the scheduler wakes up (within 1 minute), it will implement the DMS service based on the interval settings that you configured.
DB2 parameters
If you have a high event volume but infrequent DMS, you need to increase the lock timeout. Otherwise, the Websphere Business Monitor server may encounter timeout situations and be unable to obtain a lock to write to the tables that the DMS is using.
Note: A high event volume but infrequent DMS interval is not recommended.
The following parameters apply for DB2 z/OS:
| Parameter | Description | Default value | For more information |
|---|---|---|---|
| Resource Timeout (IRLMRWT) | The number of seconds a transaction waits for a lock before a timeout is detected. | 60 seconds | See How DB2 calculates the wait time for timeouts in Related information. |
| Deadlock Time (DEADLOK) | The time, in seconds or milliseconds, of the local deadlock detection cycle. | 1 second | See How DB2 calculates the wait time for timeouts in Related information. |
The following parameters apply for DB2 LUW:
| Parameter | Description | Default value | For more information |
|---|---|---|---|
| LOCKTIMEOUT | Lock timeout configuration parameter. This parameter specifies the number of seconds that an application waits to obtain a lock. Lock timeout helps avoid global deadlocks for applications. | See Lockout timeout configuration parameters in Related information. |
If the volume of events to process is high, especially at enablement time, you need a large transaction log to handle the volume.
- For DB2 z/OS, see Active and archive logs management in Related information.
- For DB2 LUW, refer to configuration parameters LOGPRIMARY, LOGSSECOND, and LOGFILSIZ. See Tuning transaction log characteristics in Related information.
Troubleshooting tips
Use the following tips for DMS troubleshooting:
- View scheduled services for a deployed model, and navigate to details of the DMS implementation. Examples of details are last time DMS was run, duration of last run, time of last start, and time of last completion. Ensure that DMS service is still being invoked successfully at the model version level and at the model version monitor context level. See Viewing scheduled services for deployed models in Related information.
- Manage Monitor scheduled services including starting and stopping DMS. See Managing Monitor schedule services in Related information.
- Examine the error tables associated with the monitor context to identify any failing instances that were copied to the Error table instead of the Target table, as indicated in the Monitoring Context Details page. Examine the corresponding Error table for failed records.
| Sample Error table name | Format |
| ORDERITEM.ERR_ORDERITEMMC_20060803000000 | schema_name.ERR_model_name_model_version |
Correct any known problems if possible, and use the Retry scripts to again process the failing records. See Updating data in the operational tables in Related information.
Related Information
[{"Product":{"code":"SSSRR3","label":"WebSphere Business Monitor"},"Business Unit":{"code":"BU053","label":"Cloud & Data Platform"},"Component":"Monitor Configuration","Platform":[{"code":"PF002","label":"AIX"},{"code":"PF010","label":"HP-UX"},{"code":"PF016","label":"Linux"},{"code":"PF027","label":"Solaris"},{"code":"PF033","label":"Windows"}],"Version":"7.0;6.2.0.2;6.2.0.1;6.2","Edition":"","Line of Business":{"code":"LOB45","label":"Automation"}}]
Was this topic helpful?
Document Information
Modified date:
15 June 2018
UID
swg21394890