Subscribe

Database Schema possible values

Ok, so we are querying the Datafabric Manager nonhistoric data for our SQL reporting purposes. I have no issues

with executing the views and we are interested in pulling information out of the storageSystemView, specifically

the ssTemperature, ssFailedFanCount, ssFailedPowerUnitCount and the ssNvramBatteryStatus.  In both our

production and test environments, all of our filers are displaying a normal value. However, what are all possible

values that these elements can hold so that our reports can reflect when an issue or problem has arisen. For

example ssTemperature is only 6 characters in length. However, when a warning or critical temperature is detected

by the Filer and DFM, what value would be stored in this field, since both warning and critical are more than 6

characters in length. Ditto for the other fields mentioned above. Unfortuately, the database schema is not descriptive

enough to tell me the possible values other than "normal".

Re: Database Schema possible values

Here are the possible values:

ssTemperature --> 'normal' or 'hot'

ssFailedFanCount: --> 'normal' or 'one failed' or 'many failed'

ssFailedPowerUnitCount --> 'normal' or 'one failed' or many failed'

ssNvramBatteryStatus --> 'normal' or 'low' or 'discharged' or 'missing' or 'old' or 'replace' or 'unknown' or 'overCharged' or 'fullyCharged'

>> However, when a warning or critical temperature is detected by the  Filer and DFM, what value would be stored in this field, since both  warning and critical are more than 6 characters in length.

     Note that ssTemperature just represents whether the env over temperature has reached or not. In DFM terms its 'hot' or 'normal' respectively.

     For other fields, i have mentioned the possible values which you can expect.

Hope this is helpfull..

Regards,

Sanjyoth

Re: Database Schema possible values

Hi,

     Basically for the storage system environment related info(especially) can be made got from the NetApp Storage System mib which gives all possible values.( this is jsut a stop gap workaround that will help you get over this hurdle.) But I do agree that possible values needs to be documented.

Regards

adai