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
tablespace attribute group. All of the collections will write to the same short
term history files and to the same database tables.
v
You already had data in the short term history file for the tablespace attribute
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.
228
IBM Tivoli Monitoring: Troubleshooting Guide
Содержание E027SLL-H - Tivoli Monitoring - PC
Страница 1: ...IBM Tivoli Monitoring Version 6 2 3 FP1 Troubleshooting Guide GC32 9458 05...
Страница 2: ......
Страница 3: ...IBM Tivoli Monitoring Version 6 2 3 FP1 Troubleshooting Guide GC32 9458 05...
Страница 14: ...xii IBM Tivoli Monitoring Troubleshooting Guide...
Страница 16: ...xiv IBM Tivoli Monitoring Troubleshooting Guide...
Страница 18: ...xvi IBM Tivoli Monitoring Troubleshooting Guide...
Страница 22: ...4 IBM Tivoli Monitoring Troubleshooting Guide...
Страница 82: ...64 IBM Tivoli Monitoring Troubleshooting Guide...
Страница 144: ...126 IBM Tivoli Monitoring Troubleshooting Guide...
Страница 164: ...146 IBM Tivoli Monitoring Troubleshooting Guide...
Страница 188: ...170 IBM Tivoli Monitoring Troubleshooting Guide...
Страница 240: ...222 IBM Tivoli Monitoring Troubleshooting Guide...
Страница 262: ...244 IBM Tivoli Monitoring Troubleshooting Guide...
Страница 274: ...256 IBM Tivoli Monitoring Troubleshooting Guide...
Страница 276: ...258 IBM Tivoli Monitoring Troubleshooting Guide...
Страница 284: ...266 IBM Tivoli Monitoring Troubleshooting Guide...
Страница 288: ...270 IBM Tivoli Monitoring Troubleshooting Guide...
Страница 302: ...284 IBM Tivoli Monitoring Troubleshooting Guide...
Страница 308: ...290 IBM Tivoli Monitoring Troubleshooting Guide...
Страница 309: ......
Страница 310: ...Printed in USA GC32 9458 05...