IBM E027SLL-H Troubleshooting Guide - Page 246

Warehouse Proxy Agent or Summarization and Pruning Agent fails due

Page 246 highlights

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

  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11
  • 12
  • 13
  • 14
  • 15
  • 16
  • 17
  • 18
  • 19
  • 20
  • 21
  • 22
  • 23
  • 24
  • 25
  • 26
  • 27
  • 28
  • 29
  • 30
  • 31
  • 32
  • 33
  • 34
  • 35
  • 36
  • 37
  • 38
  • 39
  • 40
  • 41
  • 42
  • 43
  • 44
  • 45
  • 46
  • 47
  • 48
  • 49
  • 50
  • 51
  • 52
  • 53
  • 54
  • 55
  • 56
  • 57
  • 58
  • 59
  • 60
  • 61
  • 62
  • 63
  • 64
  • 65
  • 66
  • 67
  • 68
  • 69
  • 70
  • 71
  • 72
  • 73
  • 74
  • 75
  • 76
  • 77
  • 78
  • 79
  • 80
  • 81
  • 82
  • 83
  • 84
  • 85
  • 86
  • 87
  • 88
  • 89
  • 90
  • 91
  • 92
  • 93
  • 94
  • 95
  • 96
  • 97
  • 98
  • 99
  • 100
  • 101
  • 102
  • 103
  • 104
  • 105
  • 106
  • 107
  • 108
  • 109
  • 110
  • 111
  • 112
  • 113
  • 114
  • 115
  • 116
  • 117
  • 118
  • 119
  • 120
  • 121
  • 122
  • 123
  • 124
  • 125
  • 126
  • 127
  • 128
  • 129
  • 130
  • 131
  • 132
  • 133
  • 134
  • 135
  • 136
  • 137
  • 138
  • 139
  • 140
  • 141
  • 142
  • 143
  • 144
  • 145
  • 146
  • 147
  • 148
  • 149
  • 150
  • 151
  • 152
  • 153
  • 154
  • 155
  • 156
  • 157
  • 158
  • 159
  • 160
  • 161
  • 162
  • 163
  • 164
  • 165
  • 166
  • 167
  • 168
  • 169
  • 170
  • 171
  • 172
  • 173
  • 174
  • 175
  • 176
  • 177
  • 178
  • 179
  • 180
  • 181
  • 182
  • 183
  • 184
  • 185
  • 186
  • 187
  • 188
  • 189
  • 190
  • 191
  • 192
  • 193
  • 194
  • 195
  • 196
  • 197
  • 198
  • 199
  • 200
  • 201
  • 202
  • 203
  • 204
  • 205
  • 206
  • 207
  • 208
  • 209
  • 210
  • 211
  • 212
  • 213
  • 214
  • 215
  • 216
  • 217
  • 218
  • 219
  • 220
  • 221
  • 222
  • 223
  • 224
  • 225
  • 226
  • 227
  • 228
  • 229
  • 230
  • 231
  • 232
  • 233
  • 234
  • 235
  • 236
  • 237
  • 238
  • 239
  • 240
  • 241
  • 242
  • 243
  • 244
  • 245
  • 246
  • 247
  • 248
  • 249
  • 250
  • 251
  • 252
  • 253
  • 254
  • 255
  • 256
  • 257
  • 258
  • 259
  • 260
  • 261
  • 262
  • 263
  • 264
  • 265
  • 266
  • 267
  • 268
  • 269
  • 270
  • 271
  • 272
  • 273
  • 274
  • 275
  • 276
  • 277
  • 278
  • 279
  • 280
  • 281
  • 282
  • 283
  • 284
  • 285
  • 286
  • 287
  • 288
  • 289
  • 290
  • 291
  • 292
  • 293
  • 294
  • 295
  • 296
  • 297
  • 298
  • 299
  • 300
  • 301
  • 302
  • 303
  • 304
  • 305
  • 306
  • 307
  • 308
  • 309
  • 310

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