Hello and welcome to the SAP HANA Academy.
The topic of this video tutorial series is SAP HANA Administration and in this video
we will take a look at Disk Volume Monitoring.
This video has been recorded on release SAP HANA cockpit 2.0 SP08 from October 2018.
For earlier or later releases, please check the playlist on the SAP HANA Academy.
Hi, I am Denys van Kempen.
I am connected here to the SAP HANA cockpit, connected to a tenant database, HA0, and we
are looking at System Overview.
On the Disk Usage tile, we can see that we have a single disk, almost 200 GB, and on
this tile we can find a link to Monitor Disk Volume.
Select it and the Disk Volume Monitor app will open.
We have a couple of views.
The app opens with Standard, showing Volume Size by Volume ID.
In the header, we can then apply our filters.
We can filter on host, in case we are working with a multi-host distributed system.
We can filter on type: data or log volumes.
We can filter on service.
For this tenant database, we only have two services: the actual database engine, indexserver,
and the application server XS engine, XS classic that is, not XS advanced.
And finally we can also filter on the volume ID.
We can see them below in the graph, volume ID 2, not even 500 MB and volume 3 of about
6 GB.
Under the graph, we can choose whether we want to see graph + table, or table data only.
It is often easier to get a good picture of the state of affairs from a graph rather than
raw data.
However, you would need the raw data to drill down.
On the table header, we also have our column selector.
This is a single host system, so we do not need this column selected.
Now let’s zoom out a bit, so we get the column headers to appear correctly.
Very good.
We have 8 rows, sorted by size in MB. 4 rows for the indexserver service and 4 rows for
xsengine.
The xsengine service is on volume 2 and indexserver on volume 3.
The volume for this tenant database is much bigger in size than for the application server,
which is to be expected and this is a simple demo system with little data.
In production systems, the difference would be even greater.
Then for the indexserver, we have one data volume and three log volumes, one very small,
a single file of only 1 MB, the dictionary.
Percentage used for all log files is 100% with two log segment Free and one other in
Writing State.
The Path column shows where the file is to be found on the file system.
Let’s try another view: Log Segments Grouped by State.
The Type filter is now on LOG and the graph shows free and writing: two files are free
and 1 for writing.
View volume size by Host
Well, we only have a single host, and view Volume Size by Service: xsengine and indexserver
Volume Size by Volume ID is the same as Standard.
Let’s briefly also look at a multi-host system.
Disk Usage only shows the 3 Most Critical Disks, the most relevant ones that is.
Let’s open the Disk Volume Monitor.
We have a bit more data: 5 volumes in the graph, 20 rows.
The most relevant view here would be Volume Size by Host, and we can then filter on the
host.
Volume Size by Service sums it up for the indexserver, there is only a single service
on this multi-host system.
Below, we have the data in table format, basically for each indexserver on each host, the rest
is pretty much the same.
Log Segments Grouped by State gives the same view as for a single host system.
Select the entry for the Disk Volume Details view.
The header lists the main characteristics.
This data volume consists out of a single file: name, total size, used size and % used.
The same data as from the previous view.
We can see that there are 4 log files actually associated with this data file.
There is a relationship; 3 log files, one writing and two free, 1 GB each, and a dictionary
file.
Then we can also view the volume I/O total statistics.
I/O will be impacted by other databases or volumes on the same storage device, so we
also get the statistics here for volume 2 with the totals.
You can think of the device as the actual disk drive, the hardware, and the volume as
a logical partition, a part of that drive.
There a lots of ways of how this can be different, with RAID, SAN, and NAS, Storage Area Networks
and Network Attached Storage but this would get us into the nuts and bolts of storage,
which we might address some time.
Note that the path is identical except for data and log part.
Then we get Total Read Size, Write Size, Read and Write Time in microseconds, Read and Write
Speed in MB per second and total I/O time.
Typically, you would expect a lot more writes to the log volume and lot more reads on the
data.
For this reason, log and data volumes should not be stored on the same device if performance
is a consideration.
There is very little activity, hence very little writes, so that’s why we get a 0.0000
here, with eventually a 1.
We have a bit more reads.
Couple of options here from the table header.
We are looking at Volume Size & Time now.
Configuration will return the settings for the volume: async_write_submit_active=on,
etc.
The system administrator on the Linux side or the storage administrator will be familiar
with this.
The volumes have been configured identically for this device, as you can see.
We can also request Advanced Write Statistics.
Now we are definitely in the domain of system administration.
Trigger Write Ratio, Short Writes, Triggered Async Writes — this is getting a bit technical
— and the same for the Advanced Read Statistics.
There is an option to reset the Volume I/O Total Statistics.
You will get a warning first.
Why would you do this?
Well, typically, when either the hardware has changed or the configuration was altered.
This could be a good reason to reset statistics.
Then you can also indicate here whether you want to see the number Since service restart
or since last reset.
This is system is shut down every evening, so service restart is the most sensible choice.
If your system is up 24/7, Since last reset might be a better one.
OK —and we also have our column selector here, of course.
Last item on the page is data volume page statistics.
Storage devices are divided in pages, with each page consisting of blocks, with a superblock
at the start (like a dictionary), and here we see the statistics for 4k page, 16k page,
16k row store pages (all row store tables go into 16k pages) and then for the column
store 64k, 256, 1, 4 and 16 MB.
Like the I/O stats, this is all fairly low-level technical stuff.
Should this be your thing, then you might enjoy the trace files as well.
This will open the SAP HANA Database Explorer for SAP HANA Cockpit.
We are connected to our tenant database with the Database Diagnostic Files folder selected.
Open the host.
Pick your service.
We are mostly concerned here with the indexserver.
And then we get our list of trace files.
Select if for display.
Lots and lots of data.
You would have to know where you are looking for.
Typically, this will be for support purposes.
OK —back to Disk Volume Monitor.
In the header we also find two links to Backup and System Replication, and a button to Reclaim
Space.
You are advised to make a backup before you reclaim space, so this is why the Backup link
is included.
We can also find both as related apps in the header navigation menu.
Disk I/O is important when we are replicating data, so this is why System Replication is
listed here as well.
When selecting Reclaim Space, you will get warning again.
You can reclaim space from freed log segments or unused space in the data volumes, for all
volumes on the database you are connected to.
Significant impact on performance is to be expected.
Be careful here.
And, Murphy’s Law, always make a backup before this kind of operation.
Better be safe than sorry.
We can reclaim free log segments.
In our case, this would not make any difference, plus, as indicated here, new log segments
will need to be created later, affecting performance.
We can also reclaim data volume.
This is a more likely candidate.
Maybe a lot of data has recently been moved to warm storage, or has been deleted.
Data volumes are not automatically reduced in size, so reclaim space on the data volume
could be beneficial in those scenarios.
For my tenant here, we can reclaim 1 GB.
You certainly would not reclaim space for such a small gain but let’s do it any way.
Running reclaim data volume
Takes a bit of time, even on such a small volume and there we are: data volume was reclaimed
successfully.
OK —use with care, that’s the message.
For more information, for starters, you can select the online help menu: Monitoring Disk
Volume, which will open the Cockpit Administration Guide on this topic.
For further analysis, I can recommend the SAP HANA Troubleshooting and Performance Analysis
Guide, section I/O Related Root Causes and Solutions, and, in the same guide, the section
Disk Related Root Causes and Solutions.
From the Knowledge Base, we have article FAQ SAP HANA Persistence.
Persistence is storage, basically.
We have the FAQ on I/O Analysis for SAP HANA.
We have an article about the SAP HANA Storage Connector API, on itself another topic, but
this article has a whitepaper attached: SAP HANA Storage Requirement, which you might
find of interest, and finally an FAQ about system replication, in particular in relation
to the reclaim space operation.
OK —That’s it.
Disk Volume Monitoring.
Thanks for watching.
You can find more video tutorials on our YouTube channel.
If you would like to be informed about new video tutorials, please subscribe to our channel.
You can connect with us on LinkedIn or follow us on Twitter, as well for updates, and if
you are watching this video on YouTube, do not hesitate to leave your comments to the
video page and, if you like, give us your vote on this video.
Thank you for watching.