I was visiting a customer recently and the topic of collecting historical data using OMEGAMON DB2 came up. I made the statement that you probably have as many as a dozen different ways to collect history data using OMEGAMON DB2. Couple that with the fact that DB2 has the potential to generate large volumes of trace and history data, and it points towards the need to consider your options when setting up history collection with OMEGAMON DB2.
To prove my point I went through this chart with my customer. You can have DB2 itself send data to SMF, and then run history reports from the SMF data. You can collect data to Near Term History (NTH). The primary use of NTH is for near term viewing within the Classic interface, but if you use the VSAM SEQ option you can also take the data from NTH and send it to other history processes. You can collect snapshot history, which can snap thread and subsystem data, and view that snapahot data within the PE GUI interface (shown at the bottom of the chart).
Which then brings us to Performance Database and Performance Warehouse. It may not be immediately obvious, but there is a difference. Both are DB2 trace data in DB2 tables, but with Performance DB you create and manage the objects yourself from hilev.RKO2SAMP members. Performance Warehouse is automatically managed by OMEGAMON DB2. Other than that, they are pretty similar. My preference is to manage my own objects, because of the size of the data involved.
But we are not done. There is also history in the Tivoli Data Warehouse. This is snap shot data, good for trending analysis, and viewable in the TEP, and using Tivoli Common Reporter. Plus we have many ways to collect data in the form of Collect Report Data (CRD). You can use CRD via the PWH, via ISPF interface, or via batch jobs provided in RKO2SAMP.
Quite a list, huh? I will probably be doing an article on this for Tivoli z Advisor.