Technical Articles
Details about HANA overwrite log mode
Hello admins,
this topic is not entirely new, but the background of how it works and the relation to e.g. a migration is even more interesting.
Usually you think that if you enable overwrite log mode, your log disk can’t get full, right? Data is overwritten when the segments become full.
What if I tell you, that this statement is wrong? Did you ever activate log mode overwrite for a migration to prevent log or backup volume to become full?
Ok, to understand it we must know about 3 things:
- savepoints
- log segments
- log mode overwrite
1) Savepoints
Most of you know what a savepoint in the context of HANA is and how it works.
Changes of pages from the last savepoint were written to the converter table (mapping of physical and logical pages).
If a savepoint is triggered this data will be read out of the table and the changes persisted to the data area.
In every of these procedures there is a critical phase. In this phase the locks of the affected objects taking place to identify the log position.
If the critical phase takes too long, the DB decides to trigger it at a later point in time when the workload is lower.
The time limit for the critical phase will be defined by the parameter savepoint_pre_critical_flush_retry_threshold. HANA will try to underbeat this value (default: 3 seconds). If this value is reached the DB is try it to a later point in time.
To avoid the risk of an endless loop there is a parameter savepoint_max_pre_critical_flush_duration => by default 900 seconds. The critical phase will be triggered hard after this time.
The topic of savepoint is more complex as just write changes to disk and some locks.
More details can be found in HA200 training or in books like “HANA Administration” (*).
For now we must not know more about it:
- Changes from the last savepoint will be persisted
- There is something called critical phase which should not take long time
- time limit for critical phase
- hard trigger after 900s without savepoint
* EN: ISBN 978-1-59229-953-9 DE: ISBN 978-3-8362-3641-6
2) log segments
Your log volume consists of multiple log segments. The size of each log segment will be defined by parameter log_segment_size_mb. If a segment becomes full, another one will be reused or created. The amount of segments depends on the changes, log mode and savepoint interval.
A segment can have the following status:
Status | Description |
Formatting | The log segment is being formatted and not yet used. |
Preallocated | The log segment has been preallocated, but never used. |
Writing | The log segment is currently being written. |
Closed | The log segment is closed, not backed up and is still required for restart. |
Truncated | The log segment is not required for restart, but has not been backed up. |
BackedUp | The log segment has been backed up, but is still required for restart. |
Free | The log segment has been backed up, it is not required for restart and can be reused. |
Status BackedUp is only be used in log mode normal. One segment will always stay active (status: Writing).
3) log mode overwrite
A segment will only be closed if it is full. Once a savepoint is successfully, the segment can be reused and get the status ‘Free’.
So if regulary savepoints are successfully, the log volume not becomes full and no archive stuck can occure.
With this mode no backups of the log segments are created.
Note: For this reason no point in time recovery (PTR) is possible. Even when no log backups are written, with each data backup, the backup catalog is still backed up to the log backup destination.
The first thing you should do after you have installed a HANA DB is a backup. Why? By default, the value of the log_mode parameter is normal, but if you did not create an initial backup, the DB works in overwrite mode.
4) Summary
After you know all this details => is it possible that the log volume becomes full in log mode overwrite? When we think about the critical phase and the 15min (900sec) of the forced savepoint => is it possible?
The log segments will only be freed if the savepoint is successfully. If it is not successfully new log segments will be created until the log volume is full or the savepoint is successfully and the log segments can be freed, but after 900 seconds the duration can be quite long.
Think about a migration with a lot of parallel R3load processes which change a mass of data by creating also excessive amount of log segments. If your log volume is not sized with an uplift you’ll run in an archiver stuck, even with log mode overwrite and for sure with log mode normal. May be some of you run into this issue even with log mode overwrite while migrating a system to HANA and wondered why the log volume becomes full.
Solutions? 2 of them:
– size your log volume with uplift as already explained
– disable logging with risk (not equal logmode overwrite)
Which risk? If your system crashes, your data will be lost from the last successful savepoint to the crash. So be careful when using this second option:
ALTER SYSTEM LOGGING <on_off>
Details:
ALTER SYSTEM LOGGING
Starting with SPS06 there is an own parameter for it which has to be activated as prerequisite to execute the command:
ALTER SYSTEM ALTER CONFIGURATION (‘indexserver.ini’, ‘SYSTEM’) SET (‘transaction‘, ‘allow_redo_logging_off_mode’) = ‘true’ WITH RECONFIGURE |
Afterwards execute again the alter system logging off command.
I hope you know a little bit more about the logging functions, its modes and dependencies of the HANA database.
Best Regards,
Jens
Hello Jens, Thank you for this wonderful blog!!
I have a situation where in the /hana/log got full during migration to Hana. Additional space was added later and we went on with migration and finally backup with backint. Later we can see that all the log segments are in status preallocated and we cannot even free up space with reclaim log.
Please can you advice what would be causing this.
Hi,
just follow the instructions on note 2083715 - Analyzing log volume full situations and 3047379 - Monitoring hana/log volume consumption
You can also use hdbcons "log info" as sidadm on OS for more details.
Regards,
Jens