From time to time, users ask if it would be safe to delete log files for the OASIS database, especially when the server is running critically low on disc space. In response to this, Ingen Software strongly urges users to truncate the OASIS log file and store the truncated log file on a safe local hard drive. If automatic backups are set up, the OASIS log file will be truncated automatically daily. This document discusses the importance of the oasis.log file and solutions for managing log files when the server is running low on disc space. Caution: do not delete the oasis.log file. This will cause system failure.
Understanding Sybase Database Technology and Log Files
OASIS uses SAP Sybase SQL Anywhere. This is a relational database that uses internal recovery technology, allowing databases to automatically recover during system failures. This system uses the following files:
- oasis.db- this is the OASIS database.
- oasis.log- this is the active log (recovery) file. This file is used by Ingen Software to restore your system if problems occur with the database.
- ######XX.LOG- these are inactive recovery files. Note: these files will always be named with six numbers, two letters, and the "log" extension.
When users open and view an OASIS transaction, the data is pulled from the oasis.db file. When users save a transaction in OASIS, the data is written to both the oasis.db and the oasis.log file. This "dual-write" process is important if a system failure occurs and data in the oasis.db file is corrupted. In response, the oasis.log file is automatically consulted by the database to correct the order.
However, the size of the oasis.log file will continuously grow. If a verified backup system is in the place, the oasis.log file should be truncated periodically. For more information, click here.
Understanding the Truncation Process
If using the automated backup, OASIS will automatically truncate the log daily and the manual truncation process is unnecessary. When the truncation process is completed, the oasis.log file becomes inactive is renamed using the date and a unique number sequence (i.e. 151029AA.log), and a new empty oasis.log file is created.
The inactive recovery log file names are always a date stamp: year, month, day, and then followed by the log sequence. If the log is truncated first by the daily backup process, then manually, users would gain multiple log rotations listed as "AA log," "AB log," "AC log," etc.
The truncated transaction logs have internal offsets at the beginning and end of the files. For successful recovery purposes, all sequential log files must be present. With all the log files created for the OASIS database, it is possible to recover from a hardware failure and rebuild the database from day 1 of OASIS use to the point of failure with zero data loss.
What Can I Delete?
Before this question can be answered, users must know if they are using the automated daily backup that is included with OASIS software. For more information, click here.
If you are using daily backups
Users must consider two different folders: the live database location (C:\OASIS by default) and the backup location (C:\oasis_backup by default).
In the live database location, there will be an AA log file for every day, and there will be a duplicate of those AA log files in the backup location. Users only need one set of these log files. All AA log files from one of the two locations may be copied to an external hard drive and the originals in both locations can be deleted. However, Ingen Software recommends only deleting one copy and keeping one set of the logs on the server. In the event of a database failure, it will take time to copy the logs from an external hard drive to the server.
If you are not using daily backups
Ingen Software recommends considering setting up automatic daily backups. For more information, click here. Otherwise, it is not recommended that users delete any log files. Instead, truncate the log files and save them to an external hard drive. For more information, click here.
What is required for a successful recovery?
The reality in a recovery scenario is that we only need a known good, validated copy of the oasis.db file and every AA log file since that copy was made through the current date. The database will contain everything from the past AA log files, so as long as we have a known good database from a certain date, the AA logs from that date and before become redundant. A recommended policy would be to validate a copy of the backup monthly or quarterly, delete old AA logs from the validated database's last modified date and before.
- Have a daily backup set up and running
- Get a copy of the oasis.db file from the oasis_backup folder and save it to an external hard drive or other separate location.
- Copy this copy to another server or workstation with the server version of OASIS installed.
- Run a validation on the "validation copy" of the database. (Video Walkthrough)
- If this copy validates successfully, preserve the original copy on the external hard drive or the separate location and that becomes your known good copy to work from.
- The copy that was validated is no longer a viable backup itself because it has been started. (The offsets in the log files wouldn't match up.) The validation copy can be deleted.
- All AA logs from the day prior to the the database date and before could be deleted at that point. (ie, if the database shows a date of 12/1/16, you can delete log files from 11/28 and before.)
- In the event of a database failure, we would attempt to recover from the copy in the oasis_backup folder. If this fails, we would go to the known good copy and roll it forward using AA logs.
Comments
0 comments
Please sign in to leave a comment.