## 3.3 Disk Related Root Causes and Solutions
This section discusses issues related to hard disks and lack of free space.
## Low Disk Space
This problem is usually reported by alert 2 which is triggered whenever one of the disk volumes used for data, log, backup or trace files reaches a critical size.
Use the following tools in the SAP HANA cockpit to examine the situation and try to free some disk space:
- Via Alerts tile
- Via Disk Usage tile
- On the Disk Volume Monitor
For high log volume utilizations, refer to SAP KBA 2083715 - Analyzing log volume full situations . For data volume exhaustions which cannot be explained by the size of the catalog objects (tables etc.) there are a few more mechanisms which utilize the persistency layer (data volume) such as:
- Disk LOBs
- Table Sizes on Disk
- MVCC Mechanism
- Database Snapshots
The following sections will assist you in analyzing these possible problem areas step by step.
## Disk LOBs
Large binary objects are usually not optimally compressible in SAP HANA, thus tables with large LOB files may also indicate large memory footprints in SAP HANA. Since SAP HANA also offers the concept of hybrid LOBs (as of SAP HANA SPS07), the majority of the LOB data - larger than a specific threshold - is automatically outsourced to the physical persistence on disk instead. This can lead to the situation that you have a table which is small in memory but large on disk level. The SQL statement HANA_Tables_DiskSize_1.00.120+, which you can find in the SAP Note 1969700 - SQL Statement Collection for SAP HANA , may provide further insights on the disk and memory footprint of the largest tables with LOB columns. In the following example, you see tables which utilize large amounts of disk space but effectively no memory due to the nature of the data itself (LOBs):
| TABLE_NAME     | VIRTUAL_FILE_N   |   COUNT |   SIZE_GB |   SIZE_NOLOB_GB |
|----------------|------------------|---------|-----------|-----------------|
| SACONTOIDI     | any              |      13 |     42.55 |           42.55 |
| SACONTO1       | any              |      10 |     29.63 |           29.63 |
|                | any              |      36 |     18.7  |            0.35 |
| OBJECT_HISTORY | any              |      26 |    287    |            0.01 |
For further information on handling LOBs, refer to:
- SAP Note 2220627 - FAQ: SAP HANA LOBs
- SAP Note 1994962 - How-To: Activation of Hybrid LOBs in SAP HANA
If you cannot narrow down the issue to LOBs, check the virtual file containers on persistency level in more detail.
## Table Sizes on Disk
A first insight on whether the virtual file containers of the column store tables are responsible for the data volume utilization can be gained by running the following statement:
SELECT host, port, sum(physical_size) FROM m_TABLE_VIRTUAL_FILES GROUP BY port, host
This will return the sum of the physical size of all virtual file containers on disk level, representing the total size of the catalog objects on disk level. If this deviates drastically from the data volume utilization you observe, there are objects utilizing the data volume other than database tables and indices.
If the sum of the virtual file containers does not match the disk utilization observed on OS level for the data volume, further checks are necessary.
## MVCC Mechanism
A blocked garbage collection may also over-utilize the SAP HANA data volume of the indexserver. Proceed as outlined in:
- Multiversion Concurrency Control (MVCC) Issues
- SAP KBA 2169283 - FAQ: SAP HANA Garbage Collection
Run the following query to make sure there are no excessive amounts of undo cleanup files:
```
SELECT SUM(page_count) FROM M_UNDO_CLEANUP_FILES
```
Undo files contain information needed for transaction rollback and these files are removed when the transaction completes.
Cleanup files contain deleted information which is kept because of MVCC isolation requirements. When the transaction completes garbage collection uses the cleanup files to finally remove data.
For more information, refer to m_UNDO_CLEANUP_FILES System View in the SAP HANA SQL and System Views Reference guide.
## Database Snapshots
In specific cases, for example, if data backups have failed in the past, database snapshots for these backups are not cleaned up. This can be evaluated by the following SQL statements:
```
SELECT page_sizeclass AS "Page Size-class", page_size*used_block_count/ (1024*1024*1024) AS "Disk Utilization in GB" FROM M_DATA_VOLUME_PAGE_STATISTICS WHERE volume_id = <volume_id>
```
This statement may show a result like:
This leads to the conclusion that the main contributor to the disk utilization are 16MB pages which are mainly used for the main fragment of the column store. To confirm this, check whether snapshots exist which have been created for backups:
In this case, "dangling" database snapshots which are no longer required should be dropped. This happens automatically after a database restart.
## Related Information
I/O Related Root Causes and Solutions [page 114]
```
SAP Note 1900643 SAP Note 2083715 SAP Note 1969700 SAP Note 2220627 SAP Note 1994962 Multiversion Concurrency Control (MVCC) Issues [page 175] SAP Note 2169283 M_UNDO_CLEANUP_FILES System View
```