Browse Prior Art Database

DB2 Thread Near Term History Exception Processing Disclosure Number: IPCOM000168060D
Original Publication Date: 2008-Feb-28
Included in the Prior Art Database: 2008-Feb-28
Document File: 2 page(s) / 24K

Publishing Venue



Near Term History Exception Processing

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 72% of the total text.

Page 1 of 2

DB2 Thread Near Term History Exception Processing

The current Near Term History processing reads performance data from DB2 and writes it into a file for online viewing. Each record, as it is read from DB2, is immediately written to the viewing file. The only filtering that is done is on some identifying fields that occur on all the records. This new invention is to cache all the records for a DB2 thread in storage until the accounting record is processed, which is the last record in the group. This would allow filtering on any field in any of the records. Exception conditions could be defined to only record the threads that did not perform within a specified range of criteria.

For example, if elapsed time is greater than a value or number of deadlocks is greater than zero.

This is a concept of how NTH could be changed to perform this function.

NTH Displays

All IFCIDs would be read and inserted into a NTH cache in a Data Space. This would accumulate all records for a thread before it is determined if they should be placed in the filtered NTH file.

The data in the cache would only have to be there for the duration of a thread. They data would all be the same format as the filtered NTH file.

Near Term History Exception Flow

IFI Read Process

Exception Processing

NTH Cache

Filtered NTH Data

NTH Display retrieval logic


Page 2 of 2

At the end of thread processing (or when an IFCID 3 record is written) the exception processing w...