SAP HANA Log Volume Full Time Calculator for Log Backup Outages
This calculator shows how many hours an SAP HANA database can keep writing before the /hana/log file system fills when log backups stop, and how full it gets after an outage you choose. It is built for on-call planning: set alert thresholds and decide how fast a broken backint or backup share must be fixed.
Your numbers
From M_DISKS for usage type LOG, or the sum of segment sizes in M_LOG_SEGMENTS.
Easiest source: hourly sums of log backup BACKUP_SIZE in M_BACKUP_CATALOG_FILES.
Parameter log_segment_size_mb in [persistence]; default 1024.
log_backup_timeout_s / 60; default 900 s = 15 min.
Your results
Linear estimate at a constant redo rate. Batch peaks, savepoint delays and system replication can hold segments longer. Use it to plan alerting, not as a guarantee.
Log volume used percent vs outage hours
Sweeps Log backup outage to simulate from 0 to 48, holding your other inputs fixed.
Get your HANA alerting thresholds checked
Send your log volume size, redo rates and current alert settings and we will suggest thresholds that leave time to react.
Optional. The tool and every export work without this. No spam.
How to use it
Enter the size of the log file system and how full it is now; M_DISKS (USAGE_TYPE LOG) or M_LOG_SEGMENTS give this. Take the peak hourly redo rate from your log backups, because log backup volume equals redo written. Check log_segment_size_mb and log_backup_timeout_s in the [persistence] section of global.ini (M_INIFILE_CONTENTS shows the effective values), then slide the outage length. The primary output is hours to full at peak rate. If that is shorter than the time your team needs to notice and fix a backup failure out of hours, you need a bigger log volume, earlier alerts, or a backup target that cannot silently fail.
- Use the peak hour, not the daily average
- Check each tenant: every service has its own log volume
- The risk flag is 1 when the simulated outage fills the log
Why log backups free log space
HANA writes redo into log segments of log_segment_size_mb in the log volume. With log_mode normal, a closed segment can only be reused after it has been backed up and is no longer needed for restart, which requires a savepoint after the changes it contains. M_LOG_SEGMENTS shows each segment's STATE, for example Writing, Closed, Truncated, BackedUp and Free. Many segments that are Closed but not BackedUp mean log backups are failing. If the log file system fills, the database can no longer write redo and stops accepting changes: commits hang and applications freeze until space is freed. SAP Note 1679938 covers the disk full event on the log volume. Never delete log segment files at OS level; that can make the database unrecoverable.
- Default log_backup_timeout_s is 900 seconds
- Default log_segment_size_mb is 1024
- log_mode overwrite frees segments without backup but removes point-in-time recovery
Worked example
A 512 GB log volume is 20 percent used, so 409.6 GB is free. At a peak of 15 GB of redo per hour, the log fills in about 27 hours if log backups stop. That sounds comfortable until a month-end job doubles redo to 30 GB per hour, which halves the window to under 14 hours: a Friday evening backint failure could stop the database by Saturday morning. At 15 GB/h about 15 segments of 1 GB close per hour, and the normal 15 minute backup interval holds about 3.75 GB. Run the sweep at your highest redo hour.
Emergency and prevention
In an outage, fix the cause first: a full or unmounted backup share, an expired backint credential, or a backup catalog error. As soon as log backups succeed, segments move to BackedUp and then Free after the next savepoint. Check the backup console or M_BACKUP_CATALOG for failed log backups and the backup.log trace. Prevention is cheap: alert on failed log backups within one interval, alert on log volume fill above a threshold well before full, and keep the log volume sized so hours to full exceeds your worst out-of-hours response time. With system replication, also watch replication status, because a disconnected secondary can retain log on the primary depending on the operation mode.
Frequently Asked Questions
What happens when the SAP HANA log volume is full?
HANA can no longer write redo, so transactions that change data wait and the system appears to hang. Reads may still work. The usual cause is failed log backups. Restore the backup destination, let log backups run, and segments are freed after backup and savepoint. Do not delete log files manually.
How do I check log segment states?
Query M_LOG_SEGMENTS for HOST, PORT, SEGMENT_ID, STATE and size columns, grouped by STATE. A growing count of Closed segments that never reach BackedUp or Free points at log backup failure. Compare with recent log backup entries in M_BACKUP_CATALOG.
Should I lower log_backup_timeout_s?
A shorter interval reduces potential data loss after a disaster and the log held between backups, but creates more, smaller log backups and catalog entries. The 900 second default suits most systems. It does not help if the backup destination itself is broken.
Can I just switch log_mode to overwrite to free space?
It frees segments without backup, but you lose point-in-time recovery until log_mode is set back to normal and a new full data backup is taken. In production treat it as a last resort decided with the business, not a routine fix.
If you want on-call staff to ask HANA why log backups failed and how much time is left, in plain English on your own servers, we can set that up.
Related Tools
SAP HANA Backup Storage and Retention Calculator
Estimate how much backup storage SAP HANA full, differential or incremental and log backups need for a given retention period, and how fast it grows.
SAPSAP HANA Disk Sizing Calculator (/hana/data, /hana/log, /hana/shared)
Work out the size of the HANA data, log and shared file systems from host RAM, net data size and growth, using the formulas in SAP's storage requirements white paper.
SAPSAP HANA Revision and SPS Upgrade Checklist (hdblcm)
A step-by-step checklist for updating SAP HANA 2.0 to a new revision or SPS with hdblcm, including system replication, client updates and rollback.
SAPSAP HANA Global Allocation Limit Calculator
Calculate the default HANA 2.0 memory allocation limit for your RAM, the MB value to set when reserving memory, tenant limits and statement memory exposure.
More SAP tools
See all- SAP HANA Monitoring Views Reference (M_ System Views)
- SAP HANA SQL Error Codes Reference
- SAP HANA Memory Usage SQL Generator (Used, Resident, Heap)
- SAP HANA Table Load, Unload and Preload SQL Generator
- SAP HANA Backup SQL Statement Generator (Data, Delta, Catalog)
- SAP HANA Table Partition Calculator (2 Billion Row Limit)
- SAP HANA Performance Health Checklist (Memory, CPU, Locks, Merges)
- SAP Movement Types Reference
- SAP Purchasing Document Types Reference
Keep exploring
Free tools
- SAP HANA Backup Storage and Retention CalculatorEstimate how much backup storage SAP HANA full, differential or incremental and log backups need for a given retention period, and how fast it grows.
- SAP HANA Backup SQL Statement Generator (Data, Delta, Catalog)Builds BACKUP DATA statements for a tenant (complete, differential, incremental, to file or Backint), queries to review the backup catalog and its size, and the catalog housekeeping statement.
- SAP HANA SQL Error Codes ReferenceSearchable table of common SAP HANA 2.0 SQL error codes with the error text, typical cause, the view or trace to check first and the fix.