The Restore/Undo Transaction Log feature is available in the PowerOLAP® MDB Server. Users can enable/disable transaction logging from the Service Control Program.
.png)
Checking the "Maintain transaction log" checkbox and selecting the "Apply" button in the Server Control Program will turn logging on for the specified database.
When logging is turned on for a database, several new files are generated. These files will reside in the same directory as the database file. The first two files maintain a list of users and Cubes that have been modified for this database. These files will appear as xxx_Users.plf and xxx_Cubes.plf where xxx is the name of the database file without the .olp extension.
In addition, log files will be created that will maintain the data to undo changes and to restore the database. The log files will appear as xxxyyy.log files where xxx is the name of the database file without the .olp extension, and yyy is an encoded date field representing when the file was created. A single .olp file can have multiple log files. A new log file is created each time the server is restarted. A log file also has a maximum size of 10MB. Once this file size is exceeded, a new file is automatically created.
A user does not generally need to be worried about the generated transaction log files. The only time a user needs to be concerned is when the number of log files is large and the amount of disk space is running low. If you view these files by name, because of the date encoding scheme, you are guaranteed to get the older files first. Since these files are being stored as binary files, they will require significantly less disk space than the other databases.
The Server does not need to be shut down in order to undo changes or restore the database. A restore/undo operation can be done while users are online – particularly useful for undo. It is recommended though for users to log out if meta data are being restored. If the server happens to crash, the transaction log will maintain all points written to the MDB Server up to the point where the server crashed. As an additional precaution, we strongly suggest using the Autosave feature in the service control program be enabled as well as transaction logging. This will significantly reduce the time required to restore a database, as you will only need to restore since the last Autosave occurred.
Please see the following topics: