## 9.5 LogReplay: Managing the Size of the Log File
There is a risk in replication scenarios which use one of the logreplay operation modes of causing a disk full situation on the primary if the secondary system is not available for any reason; this can potentially lead to a complete freeze of the database.
The logreplay modes (logreplay introduced in HANA 1.0 SPS10 and logreplay\_readaccess introduced in HANA 2) require a log history on the primary so that a secondary system can be resynchronized without the need for a full data shipment. As long as a secondary system is registered the log file will continue to grow. When the secondary system synchronizes, then the log is automatically cleared down. However, if the replication environment changes, if for example, the secondary is separated because of network problems, manual intervention may be required to manage the log file or, in the worst case scenario, to recover from a disk full situation. This problem can also happen on a secondary system where a takeover has occurred.
The log replay modes are described in detail in the SAP HANA Administration Guide section System Replication With Operation Mode Logreplay . This section of the SAP HANA Troubleshooting and Performance Analysis Guide describes procedures to firstly prevent problems from occurring and secondly to resolve a disk full situation.
## Log File Retention (RetainedFree Status)
If the secondary cannot be synchronized for any reason, then log segments continue to be written but are marked as RetainedFree . Y ou can check for RetainedFree log segments either in SAP HANA cockpit or from the command line.
1) To check using SAP HANA cockpit, start from the Disk Usage app and open Monitor Disk Volume . The graph shows usage for log and data volumes; you can filter the display for a specific volume and server (for example indexserver). Check the State column of the log files for RetainedFree log segments as shown here:
<!-- image -->
2) To check using the command line, execute the following command as &lt;sid&gt;adm for a specific log volume (hdb00003 in this example - the log volume of one indexserver):
```
#>hdblogdiag seglist $DIR_INSTANCE/../SYS/global/hdb/log/mnt00001/hdb00003
```
The result shows details of each log segment including status information. Look for any segments with status RetainedFree as shown here:
```
LogSegment[0/2:0xec98740-0xecb6000(0x763000B)/ GUID=759DC14B-00D7-20161122-134436-39A00002ED/ PrevGUID=759DC14B-00D7-20161122-134436-39A00002EC,TS=2016-11-30 06:55:18.008741,Hole=0xec98740/RetainedFree/0x0]@0x00007f34cb32a010
```
## How to Avoid Log Full Situations
## Unregister an Unused Secondary
If the secondary is disconnected for a prolonged period and if it is not to be used as a replication server anymore, then unregister the secondary site and disable the primary functionality. This will stop the RetainedFree log entries from being written:
1. Unregister the secondary; this is normally done from the secondary site but can be done from the primary if the secondary is not available anymore:
2. Disable the primary (from the primary site): hdbnsutil -sr\_disable
3. Execute reconfigure on the primary site:
```
hdbnsutil -sr_unregister
```
```
hdbnsutil -reconfig
```
You can use this same procedure for a primary which, after a takeover, will no longer be used for failback.
## Set a Maximum Retention Size
Another option to manage the log size is to set a value for the logshipping\_max\_retention\_size parameter. If the log size reaches this limit, then RetainedFree log entries will be overwritten. Note the following points in this case:
- If any RetainedFree log entries are lost, then synchronization by logreplay will no longer be possible and a full data shipment will be necessary to resynchronize the secondary.
- It is not possible to switch back to delta mode to resynchronize - only a full data shipping is possible.
##  Tip
As a further general precaution, to prevent any disk full situation from arising you can reserve a portion of the disk with an emergency placeholder file (containing any dummy values), for example, occupying 5 10 % of the file system. This file can then be deleted if ever necessary to quickly solve disk full situations.
## How to Recover From Log Full Situations
## Secondary Has Been Taken out of Service
If the secondary has been permanently taken out of service, then these log entries will never be required. In this case the secondary can be unregistered and the log volume cleaned up:
1. Unregister the secondary (same steps as previous subsection: unregister, disable and reconfigure).
2. Delete the Free marked log segments from the command line for each of the persistent relevant services (nameserver, indexserver, xsengine, …). To do this run hdbcons with the log release parameter as &lt;sid&gt;adm. In a multi-database system the -p switch is required with the process ID of the service (such as indexserver):
hdbcons -p &lt;PID\_of\_service&gt; 'log release'
## Secondary Still Required
If the secondary is still required, then restart it and allow it to resynchronize. When this has completed, the RetainedFree log segments on the primary will be marked as Free, you can then clean up the log as described above by running hdbcons with the log release parameter.
## Log Full Has Caused Complete Database Freeze
If the log full has caused a complete database freeze, you can try to move the log to another linked file system and replay the log from there. Essentially, this is a three step procedure, refer to SAP Note 1679938 Log Volume is full for complete details:
- Stop the primary system.
- Mount the log volumes of the primary via symbolic link to another file system.
- Start the primary and the secondary and allow them to resynchronize.
When this has completed, you can then clean up the log by running hdbcons with the log release parameter as described above.
## Related Information
<!-- image -->