Occasionally, users ask if it would be safe to delete log files for the OASIS database, especially when the server runs critically low on disc space. This article discusses the importance of the oasis.log file and solutions for managing log files when disc space is limited. Caution: do not delete the oasis.log file. This will cause a system failure.
Understanding Sybase Database Technology and Log Files
OASIS uses SAP Sybase SQL Anywhere. This relational database uses internal recovery technology, allowing databases to recover during system failures automatically. This system uses the following files:
- oasis.db- this is the OASIS database.
- oasis.log- this is the active log (recovery) file. Ingen Software uses this file to restore your system if problems occur with the database.
- ######XX.LOG- these are inactive recovery files. 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 the oasis.db and the oasis.log file. This "dual-write" process is important if a system failure occurs and the oasis.db file data 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 place, the oasis.log file should be truncated periodically.
Understanding the Truncation Process
If using the automated backup, OASIS will automatically truncate the log daily, making the manual truncation process unnecessary. When the truncation process is completed, the oasis.log file becomes inactive and is renamed using the date and a unique number sequence (e.g., 151029AA.log), and a new empty oasis.log file is created. Note: The inactive recovery log file names are a date stamp: year, month, then day, followed by the log sequence. If the log is truncated first by the daily backup process and 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 included with the OASIS software.
If you are not using daily backups
First, Ingen Software recommends setting up automatic daily backups. Otherwise, users should not delete any log files but truncate them and save them to an external hard drive.
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, an AA log file will be created each 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, copying the logs from an external hard drive to the server will take time.
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 specific 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 and delete old AA logs from the validated database's last modified date and before.
- Have a daily backup set up and running.
- Copy 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.
- If this copy validates successfully, preserve the original copy on the external hard drive or in a separate location. That will become your known good copy to work from.
- The validated copy 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.
- Then, all AA logs from three days before the database date could be deleted. (E.g., if the database shows a date of 12/1, 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.