Historical Data Is Not Warehoused; Historical Data For Logs Is Incorrect; Warehouse Proxy Agent Or Summarization And Pruning Agent Fails Due To Db2 Transaction Log Full; Incorrect Data Is Collected In The Warehouse For Filtering If Using A Wildcard - IBM E027SLL-H - Tivoli Monitoring - PC Troubleshooting Manual

To avoid repeated disconnections, consider increasing the DB2 idle thread timeout
value to a value higher than the warehousing interval. Specifying a value of 0
disables time-out processing. If time-out processing is disabled, idle server threads
remain in the system and continue to hold their resources, if any.
For more information on the DB2 IDLE THREAD TIMEOUT field (IDTHTOIN
subsystem parameter), refer to the DB2 Version 9.1 for z/OS Installation Guide.

Historical data is not warehoused

Check the following Warehouse Proxy agent logs for errors that indicate why
historical data is not warehoused:
v Windows Event Log (all critical errors)
v WHProxy Agent RAS1 Log.
v Operations Log
The Warehouse Proxy agent contains an audit trail for each export written to the
warehouse database. You can also check the database table called
WAREHOUSELOG as it contains the same information as the logs.

Historical data for logs is incorrect

If there are duplicate or missing rows in a table, incorrect historical data is
collected for logs, such as managed system or situation status. Correct the incorrect
rows to ensure reliable logs.
Warehouse Proxy Agent or Summarization and Pruning Agent fails due
to DB2 transaction log full
If the DB2 transaction log is not large enough and fills, operations performed by
the Warehouse Proxy Agent or Summarization and Pruning Agent will fail. If this
happens you will see a message like the following in the Warehouse Proxy Agent
log file (hostname_hd_java_nnnnnnnnnn.log) or the Summarization and Pruning
Agent log file (hostname_sy_java_nnnnnnnnnn.log):
com.ibm.db2.jcc.a.SqlException: DB2 SQL error: SQLCODE: -964, SQLSTATE:
57011, SQLERRMC: null
Increase the DB2 transaction log size. See the DB2 manuals for altering the
LOGFILSIZ, LOGPRIMARY, and LOGSECOND parameters within DB2.
Incorrect data is collected in the warehouse for filtering if using a
wildcard
This behavior could be caused by either of these cases:
v There are multiple historical collections distributed to your agent for the
v You already had data in the short term history file for the tablespace attribute
228
IBM Tivoli Monitoring: Troubleshooting Guide
tablespace attribute group. All of the collections will write to the same short
term history files and to the same database tables.
group before you created and distributed the new historical collection that has
the filter. The older data would have been exported to the warehouse proxy and
shown up in the Tivoli Data Warehouse database.