IBM Tivoli Monitoring > Version 6.3 Fix Pack 2 > Installation Guides > Installation Guide > Performance tuning > Optimizing queries
IBM Tivoli Monitoring, Version 6.3 Fix Pack 2
Processing queries
The query assigned to a chart or table view requests data from a particular attribute group. It executes when you open or refresh the workspace. Queries make up the processing load for on-demand data collection.
You can reduce the frequency and amount of data sampling by:
- Customize the query to filter out unwanted data. This reduces the number of selection criteria (rows), and attributes (columns) collected.
- Applying the same query to other views in the workspace. This reduces the number of data samples required: one query uses a single sample for multiple views.
- Disable automatic refresh of workspace views or adjust the refresh rate to longer intervals. This causes Tivoli Enterprise Monitoring Agent data to be collected less frequently.
- Consider how you want to display the data returned by a query. A graphical view workspace might require less data compared to a table view, because it uses only the truly numeric data and leaves out the character data.
Do not confuse custom queries with view filters from the Filters tab of the Query Properties editor. View filters fine-tune the data after it has been retrieved by the query and do not reduce network traffic, data collection processing, or memory demands.
The following general recommendations and observations might be considered as well:
- Some attributes are more expensive to retrieve than others. One expensive column in a table makes any workspace view or situation that references that table more expensive. An example of an expensive attribute is one that must run long storage chains to determine its value, such as using a process table to look for looping tasks. Where possible, ensure that you only retrieve attributes that are required for the monitoring process.
- Column function (such as MIN, MAX, AVG, and so on) requires post processing of the query results set after data is returned to Tivoli Enterprise Monitoring Server.
- Use more efficient data manipulating functions, such as substring instead of string scan. If you know the position of the string to search, do not scan the whole string to check for the value.
Post-filters versus pre-filters
Performance is improved for each view if you pre-filter the required view information and send to the portal client only what is needed in that view. This reduces the amount of data sent through the network and you do not have to post-process it either. However, there is one exception to the rule.
Think of a workspace that contains many views. Each of those views has a query associated with it, which is issued when the workspace is accessed. This might result in many queries that must be processed in parallel.
A better way of doing this might be to create one query that returns all data that is required in the workspace. In this case, the query will only be issued once and the data can then be post-filtered for each view to only display information as it applies to each view.
One important consideration however is that queries are saved globally and are not user ID dependent. This means that only administrators will be able to modify queries in most installations. For the end user to be able to modify filters, the preferred method might therefore be the filters applied in the view properties Filters tab.
Parent topic:
Optimizing queries