CDM Disk Metrics not showing correct value in USM

The disk usage details on the device details tab in USM keeps resetting to 0% for some drives, while other are unaffected, before then showing the correct value again on the next USM refresh, this can be seen in the screenshots attached. 

The disk usage details on the device details tab keeps resetting to 0% for some drives, while other are unaffected, before then showing the correct value again on the next USM refresh, this can be seen in the screenshots attached to the case. 

The disk usage metric comes from the S_QOS_SNAPSHOT table. No duplicate rows in s_qos_data table as stated before this happens on brand new installs which have only the core hub, database and ump.

The actual issue is: 

- disk usage metric (perc) are not shown at the bottom of the details page for the listed disks in USM 

- When you double-click on one disk, a qoschart opens in the standalone portlet and it shows data 

- The default metrics are shown on the details tab, right-hand side 

- There are no metrics displayed on the metrics tab (no data) 

- QOS metrics are available in prd, dashboards etc 

we did: 

- reset the device discovery via the discovery server call back 

- nulled the ci_metric_id and restarted data_engine 

- no change in behaviour 

-Data is coming from the probe as shown in Dr.Nimbus

The customer has witnessed this problem in 8.40 SP2 and they have now upgraded to 8.47 and then deployed ump_usm_8.4.7_HF2; however, the same problem remains.

The following query returns the data for QOS_DISK_USAGES for cs.cs_id 7, 57 and 61 but no data are shown in USM.

SELECT sqd.table_id, 

       sqd.source, 

       sqd.qos, 

       sqd.probe, 

       sqd.target, 

       sqd.origin, 

       sqd.ci_metric_id, 

       cim.ci_metric_type, 

       ci.dev_id, 

       CASE WHEN(qs.sampletime < '2016-12-06 09:20:57.49') THEN(NULL) 

                                    ELSE(qs.samplevalue) 

       END AS samplevalue 

  FROM cm_computer_system cs 

         INNER JOIN 

       cm_device d ON d.cs_id = cs.cs_id 

         INNER JOIN 

       cm_configuration_item ci ON ci.dev_id = d.dev_id 

         INNER JOIN 

       cm_configuration_item_metric cim ON cim.ci_id = ci.ci_id 

         INNER JOIN 

       s_qos_data sqd ON sqd.ci_metric_id = cim.ci_metric_id 

         LEFT JOIN 

       s_qos_snapshot qs ON qs.table_id = sqd.table_id 

  WHERE (   (     sqd.qos LIKE 'QOS_DISK_USAGE%' 

               OR sqd.qos LIKE '%DISK_FREE' ) 

         OR (     probe = 'netapp' 

              AND qos = 'QOS_STORAGE_PERCENT_CAPACITY_USED_AGGR' ) 

         OR (     probe = 'vmax' 

              AND qos = 'QOS_STORAGE_DISK_PERCENT_USED' ) 

         OR (     probe = 'clariion' 

              AND qos = 'QOS_STORAGE_TP_PERCENT_FULL' ) 

         OR (     probe = 'celerra' 

              AND qos = 'QOS_STORAGE_RAW_FREE_CAPACITY_PERCENT' ) 

         OR (     probe = 'ibm-ds4k' 

              AND qos = 'QOS_STORAGE_POOL_CAPACITY_USED_PERCENT' ) 

         OR (     probe = 'vmware' 

              AND cim.ci_metric_type = '1.1:14' ) 

        ) 

    AND cs.cs_id = '61' 

  ORDER BY sqd.target ASC

The problem is related to S_QOS_SNAPSHOT not being updated. 
We found that if we disabled bulk insert mode the table populated correctly. 

You can either disable bulk insert mode (set single_insert=yes in the data_engine.cfg file) or you can set the "hub_bulk_size" parameter in their data_engine.cfg file to a number lower than 20. 

I would try "5". This number needs to be lower than the actual number of total QOS's that you are collecting. 

You can find out how many QOS's you are collecting by running the following command against the database: 

>> select distinct table_id from S_QOS_SNAPSHOT 

Adjusted the hub_bulk_size to lower than the actual number of total QOS's that you are collecting, after a short while the UMP USM is now showing the data.