last updated: 2023-12-11
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 buffer
By default there are 8 log buffer with a size of 1024KB for each. All data changes are recorded in the redo log buffer. When a database transaction is committed, these log buffers are saved to disk. Also, if the redo log buffer fills at any time, the redo log buffer is written to the log segment (in log volume: /hana/log) on disk anyway, even if no commit has been sent.
3) 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. |
| RetainedFree | The log segment is waiting to be shipped to the HSR node. |
Status BackedUp is only be used in log mode normal. One segment will always stay active (status: Writing).
4) log mode overwrite
A segment will only be closed if it is full or the log backup timeout is reached (900s). Once a savepoint is successfully (and the log backup was already successful for the segment) , 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 occur.
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.
5) 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 HANA 2.0 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
- SAP Managed Tags:
2 Comments
