How useful is space monitoring of HANA volumes? After all, isn't the data very compressed in memory and the space consumed on the volume should be negligible? It is true that HANA has great compression on most types of data, one of the reasons is that columnar tables get better compression because the data in columns tend to be more repetitive. One of the benefits of running on hardware with many fast cores is its ability to perform fast and efficient on-the-fly access to compressed data.
But I digressed, as DBAs we care about how much space is available in the database containers, and if those containers have enough room in the filesystem to grow on demand. Space should never become the reason of an outage in a well-maintained database environment.
In HANA, volumes are similar to tablespaces in Oracle or DB2. However, in HANA the volumes belong to the HANA services such as indexserver, statisticsserver, or xsengine. There are 2 types of volumes: Data and Log. Each of them comprises files at the OS level and generally, there are many more log segment files than data files.
To see them in HANA Studio open the Administration Console --> Volumes, expand the service under the host:port (e.g. imdbhdb:30003 for indexserver) --> Data or Log, then the Files should be displayed in the view below.
If you notice the Used % of the Volume, it represents how full is the file/volume (used vs allocated) based on data used compared to the total file size at the OS and not the used percentage of the filesystem. Similar to how full is the tablespace in Oracle. The Used % of the filesystem would be the percentage Used and Total Disk size of what HANA calls the Storage Device (aka filesystem). You can see this in the Service/Volume view. When we monitor, only the Data volume file % should be considered as the Log segment files are always 100%, as they rotate members to being actively written (denoted by HANA as 'Writing').
In the scale-out deployment of HANA, where several clustered nodes with global filesystems are on shared storage, the filesystems and volumes associated with each HANA service would be relocated during certain Failover scenarios. Therefore, traditional OS monitoring of the filesystem may not work well when these filesystems relocate. It is better to monitor the volume availability and the filesystem utilization wherever the service may reside.
The diagram below shows the relationship between the OS, HANA Studio, and 3rd-party monitoring by the OZSOFT HANA Management Pack for Microsoft System Center Operations Manager (SCOM).
With these next-generation databases and advanced auto space management, it is optional for each customer to alert on volume utilization, however, it is still important to collect metrics for growth and capacity usage. Often new environments are more closely monitored and alerted and as usage patterns are well-baselined, the alerting should be toned back or thresholds raised to catch exceptional situations.
Want to monitor your HANA volumes and space availability WITHOUT installation?