The kept status of the variables in the BY variables list and CLASS variables list must be Yes.

The BY variables list applies to the detail level of the table. The purpose of the BY variables list is to sort the observations in the detail level to match the sort order of the observations incoming during the processing step and to detect observations that have duplicate values in the BY variables.

Under normal circumstances, you do not need to modify the BY variables list, but if you need to modify the list you can. For example, if you add a variable in an exit, you may (or may not) want to add that variable to the BY variables list.

The variables on the list must have a Kept status of Yes. DATETIME must be on the BY variables list. To the right of DATETIME on the list, use only HOUR and/or SHIFT. To the left of DATETIME on the list, you can use any variables.

CLASS variables lists, displayed in the bottom of the Edit Table window, are used to group data so that the same values of all CLASS variables are together for the reduction step. The lists also assure that data are in the proper sort order for reporting on the reduction levels. By default, the CLASS variable lists contain the same variables in the same order as the BY variables list, but the CLASS variables list in your tables may be different. The CLASS variables list for a reduction level can be different from the BY variables list and can be different from all other CLASS variables lists, but it must contain the DATETIME variable.

If you want character string metrics like MACHINE and JOB to be carried into reduction levels for reporting, add them to the CLASS variables lists immediately to the left of the DATETIME variable. (This presumes that you changed the Kept status of the string variable to Yes earlier. However, even if their Kept status is Yes, string variables that are not on the CLASS variables list are dropped from the non-detail levels because there are no statistics for string variables.)

Each of the BY and CLASS variables must have a Kept status of Yes.

Note: These lists apply to a table definition and are used to process and reduce data.

This BY variables list is not related to the BY variables that you can select for a report definition.

More about frequently used variables:

• MACHINE is the host name of the node on which the metrics were created. In the process step, the value of MACHINE is obtained from the value of IPADRES.
  
  
• DATETIME is the timestamp on the observation.
  
  
• IPADRES is the TCP/IP address of the machine (node) that created the metric values in an observation. To group data, IT Service Vision uses MACHINE name (host name) rather than IPADRES because IP addresses generally change more frequently than system names. (IP addresses can change for network upgrades, office moves, and so on.) Generally, the mapping of IPADRES to a MACHINE name happens automatically (via snmpColDump) at the process step by using the management host's IP address table or name server. If data for an IP address is encountered in the input data for a machine that has not been defined yet to the SNMP management host, MACHINE will be assigned the same value as IPADRES's value.
  
  
• INSTANS is the interface identifier. For example, a router may have two ports, each with a unique instance identifier such as 0 or 1.
  
  
• If you want reports based on IPADRES instead of MACHINE, you can make them in a task later in this section. That task walks you through how to make custom report definitions by modifying supplied report definitions and saving them.

  Note: IPADRES, and INSTANS apply to HP OpenView and NetView for AIX only.

• HOUR is the hour of the observation.

  If the Kept status of HOUR is Yes, when an observation is processed into the PDB then IT Service Vision calculates the value of HOUR. The value of hour is based on the hour in the value of DATETIME.

  If HOUR is in the BY variables list, you must keep data for it. If HOUR is not in the BY variables list, you can set the Kept status of HOUR to No; however, that change is not recommended.

• SHIFT is the work shift code for the observation.

  If the Kept status of SHIFT is Yes, when an observation is processed into the PDB then IT Service Vision calculates the value of SHIFT (unless the observation has a non-blank value for SHIFT). First, IT Service Vision checks to see if the date in DATETIME is on the list of holidays at your site. If so, the value of SHIFT is set to the work shift code for holidays. If not, the value of SHIFT is based on the day-of-week and hour of the value that is in DATETIME and on the grid that contains work shift code by Day of Week and Hour of Day. For more details on the work shift grid, see Section 1, Task 1: Start IT Service Vision Server Software.

  If SHIFT is in the BY variables list, you must keep data for it. If SHIFT is not in the BY variables list, you can set the Kept status of SHIFT to No; however, that change is not recommended.

ID variables are non-changing or slowly changing variables whose values you want to have available for reporting at one or more reduction levels.

Index variables are variables whose values you want to index at one or more level. The purpose of an index is to speed up the generation of reports when you run a report definition with one or more of the indexed variables.

Within your table(s), the variables that are generally most useful for performance analysis are the ones whose default values for the Kept status are Yes. These are the variables that you logged in the first section of this document.

Note: If you decide on a Kept status of Yes, you can decide later to change it to No, in which case the values are not processed into the detail level from that time forward. Similarly, if you decide on a Kept status of No, you can decide later to change it to Yes, in which case values are processed into the detail level from that time forward.

1. Check the Age Limit at detail level.

   By default, IT Service Vision keeps ten days of data at the detail level, but the age limit in your tables may be different. If you want your reports on detail level to be able to cover a different number of days (for example, 14 days), overwrite the current value with the new value (in this case, 14).

   Note: If you do not want to generate reports on detail-level data in this table but you do want to generate reports on other levels, you can set the value to 0.

   Note: The process step deletes existing data in the detail level that are beyond the age limit for the detail level, but the process step keeps incoming data (and adds it to existing data in the detail level) regardless of the dates in the incoming data. When the age limit at detail level is 0, the process step behaves just as it always does: it deletes existing detail level data whose age is greater than the age limit (thus, in this case, it deletes all of the existing detail level data), and it keeps the incoming data in the detail level (thus, in this case, what were the incoming data are now all the existing data).

   The reduce step ages out data in non-detail levels that are beyond the age limits for those levels and uses the existing data in detail level to update the non-detail levels. If and only if the age limit at detail level is 0, the reduce step also deletes the existing data (which, if age limit is 0, are the data that were incoming data to the process step) in the detail level.

   If the age limit is 0, the existing data in detail level would be cleared anyway (at the time of the next processing step) because the data by now are existing data and over the age limit for detail level. The purpose of this exception is to remove the existing data in detail level many hours sooner. This is quite useful when there is a tremendous volume of detail-level data and the data can be 'thrown away' after the day, week, month, and/or year levels have been updated. Performing this frees extra disk space between production jobs when the data will not be used again.

   There is one caution: if you have a failure (for instance, a power outage) during the reduce step and any age limits at detail level are zero and any age limits at non-detail levels are non-zero, make sure that you re-submit the reduce step before you go on; otherwise, the next day's production job will remove the detail data before the data have an opportunity to be summarized in the non-detail levels.

2. Check the Age Limits at reduction levels.

   By default, the PDB keeps reduction-level data as follows

   Day	45	days
   Week	15	weeks
   Month	18	months
   Year	5	years

   but the age limits in your tables may be different.

   If you want your reports on these levels to be able to cover a different number of days, weeks, months, or years, or if you want to keep fewer data in order to save disk space and shorten processing time, overwrite the current value with a new value.

The following variables/metrics fall in this category: IFSPEC (ifSpecific), SYSCONT (sysContact), SYSLOC (sysLocation), SYSNAME (sysName), and SYSOBID (sysObjectID).

The process step takes longer when string variables are kept in the detail level of the PDB. HPOV/NVAIX does not automatically collect the values of the string variables so their Kept status is set to No by default. If you change the Kept status to Yes, an additional snmp get request per variable is required to gather this data during the process step.

Gathering this data can slow down the process step, especially if there are network problems that delay the snmp get requests. However, the information in these fields is often useful in reports; for example, an interfaces report on a router is more meaningful if the interface is identified as "Ethernet/0" rather than just "4".

If you are thinking of keeping values for string variables, in the task after this one you can time processing with the Kept status set to various combinations of Yes and No to check how much extra time is required to gather the data. Based on that, you can decide whether the time to gather the data is acceptable to you.