Abstract
InformixHQ (HQ) is the administration Web GUI now provided by IBM with Informix Dynamic Server (IDS). The previous article InformixHQ Setup contains recommendations on getting started, including how to specify for each HQ agent (one per IDS instance) which Informix database should store sensor data.
This article follows on to describe in detail how this data is stored, looking at the InformixHQ Repository, so you can get what you need from these tables, either directly using BSON functions, or using views with BSON elements transformed to standard columns.
Content
The Informix database you choose to contain HQ sensor data does not have to be dedicated to this purpose, although we recommend that it should, and preferably in a separate dbspace. It can be in the same instance that the agent is monitoring, or another entirely: for example, you could have three instances each with an HQ agent on different machines, but store tables for all of them in one database. This is possible because the table names include the Server ID (not $ONCONFIG SERVERNUM) automatically allocated sequentially by HQ for each IDS instance added.
For the first one you configure, the Server ID is 1. The following tables are created expressed as simplified and reformatted “dbschema” output:
The following generates SQL to sample the contents of the “data” column for all these tables:
That produces lines like this (indented for readability):
Note above that BSON columns are unreadable unless converted to JSON.
Example output produced by the whole of the generated SQL (with the final extraneous UNION ALL removed) is as follows (with spaces inserted after commas for word wrapping):
The following generates SQL to sample the contents of the “pkey” column for all tables that have it:
That produces lines like this (indented for readability):
Note above that “pkey” is converted to VARCHAR to cope with mixed actual data types.
Example output produced by the whole of the generated SQL (with the final extraneous UNION ALL removed) is as follows:
We need to decode BIGINT milli-second timestamp columns into readable DATETIME values, which is done by this function:
The following shows this in use compared with standard DBINFO conversion:
- BSON_VALUE_TYPE (bson-column, “field-name“) gets an element from a BSON column.
- DBINFO (‘UTC_TO_DATETIME’, integer) converts a whole-second timestamp to DATETIME.
Example results are:
The following SQL puts it all together and creates functions (including the one above) and views so that HQ tables can be read in traditional fashion:
Use this shell script to generate SQL for views with different names or server IDs other than 1:
For example, to create views for server ID 2 known as “two” with repository database name “hq”, use this shell command:
Views are created with the first letter of the name changed to “v” and the first row selected as a test. A typical example view is:
The original timestamp is passed through unchanged as well as the decoded DATETIME value. (Remaining fields depend on what was found in BSON content.) This makes it possible to perform indexes searches using another function which does the opposite of the one already described. Two solutions follow to select data for last month with a summary of the resulting query plan:
Solution 1 |
---|
|
Query plan summary |
|
Solution 2 |
---|
|
Query plan summary |
|
Rows from solution 2 will also be in date order, whereas solution 1 might need “ORDER BY”.
A sample of the output in both cases follows (memory figures in bytes):
Note additional logic in this view to decode the integer segment class:
date_time | seg_class | seg_code | seg_name | seg_size | seg_used | seg_free |
---|---|---|---|---|---|---|
2020-04-18 16:59:24.364 | 1 | R | Resident | 5107712 | 5107712 | 0 |
2020-04-18 16:59:24.364 | 2 | V | Virtual | 134217728 | 91701248 | 42516480 |
2020-04-18 16:59:24.364 | 4 | B | Buffer | 113287168 | 113287168 | 0 |
Caveats
The schema of InformixHQ repository tables allows for future expansion in scope by not having hard-coded column names, but instead holds data in BSON form which does not require tables to be altered should elements be added in future. We expect that the provided views will need extending over time to include new elements, but should continue to work as currently defined.
Conclusion
Armed with the information and code in this article, you should be able to select data directly from an InformixHQ sensor repository in a usable form with simple SQL statements. Techniques are provided to sample the BSON structures after future releases to include new elements.
Disclaimer
Suggestions above are provided “as is” without warranty of any kind, either express or implied, including without limitation any implied warranties of condition, uninterrupted use, merchantability, fitness for a particular purpose, or non-infringement.
Contact us
If you have any questions about InformixHQ Repository or would like to find out more, simply contact us.