NOTE: This method has been deprecated. This process has been found to be too fragile for supported use with OASIS.
In the event of a database failure, the daily backup or last known good database would be copied to the production server and all available "AA" log files would be applied to roll it forward. This typically results in zero data loss as long as all logs are present, including the current "oasis.log" file. But in the event that a server fails and the current "oasis.log" file is not available, you could lose the current day's worth of work (or more if daily backups are not enabled). For smaller volume groups, it isn't too big of a deal to re-enter a day's worth of work. For larger volume groups, this can cause major headaches. To help reduce the chance of losing the contents of the live oasis.log file in the event of a server failure, you can use the "live log" process to have a nearly full copy of the current transaction log being mirrored to another server.
On the production server, use the built in daily backup feature to get a full daily backup of the database saved to either a local but physically separate drive from the production database or a network location. This will also rotate the transaction log.
On the fail-over server, install an OASIS Server instance so you will have the backup utility. Have a scheduled task running that runs the dbbackup command with the -l option. This process should always be running. This is same dbbackup command that runs the daily backup feature on the production server, but with one extra option that provides only a nearly up to date copy of the 'oasis.log' file. (It contains only info that has been "checkpointed", or where all pending commits to the database are done. Checkpoints are usually hourly.)
Create a scheduled task on the backup server that uses the following information:
Path to executable: C:\Program Files\OASIS273\asa16\Bin64\dbbackup.exe
Options: -l C:\oasis_backup\oasis.log -c "uid=oasis;pwd=oasis;eng=OASIS"
- This assumes you are using the standard oasis/oasis credentials (typical for standard installations)
- This assumes you are outputting the live log copy of the oasis.log file to a local folder called 'C:\oasis_backup' but this can be adjusted as needed.
Alternately, you could create a batch file that is run via the scheduled task:
cd C:\Program Files\OASIS273\asa16\Bin64
dbbackup.exe -l C:\oasis_backup\oasis.log -c "uid=oasis;pwd=oasis;eng=OASIS" C:\oasis_backup
As long as the database server is running, and as long as the live log process is running, you will have a copy of the current 'oasis.log' file updating continuously on the backup server. As daily backups run daily, the 'oasis.log' file will be rotated and you will end up with a set of "AA" logs as well as a current 'oasis.log' file in the location specified in the scheduled task. In the event of a hardware failure on the production server, the latest daily backup would be copied to the backup server in the same directory as the log files. The database would be started with a specific option to apply the AA logs and oasis.log file. Once recovery operations are complete, the backup server would hold the production database for use.
Notes on the -c (connection parameters) option
The -c option specifies database connection parameters. It requires a database UserID (uid=), a password for that database user (pwd=), and a database to connect to. If the database is running as a broadcasting service (default), you would specify the database engine to connect to (eng=ServiceName). Alternately, if firewalls are an issue, you can use a direct TCP/IP communication link: CommLinks=tcpip(HOST=hostname;PORT=2638)
dbbackup -l D:\Data\oasis_backup\oasis.log -c "uid=oasis;pwd=oasis;CommLinks=tcpip(HOST=192.168.1.10;PORT=2638)" C:\oasis_backup
dbbackup -l C:\oasis_backup\oasis.log -c "uid=oasis;pwd=oasis;eng=OASIS" C:\oasis_backup
The time required for recovery will depend on the size of the database and speed of the hardware involved. SAS drives and 10 Gb/s networks will move data a lot faster than SATA drives and a 1 Gb/s ethernet network. If the database is under 100 GB, it won't take too long to copy. If the database is larger than 500 GB, recovery time could be hours due to the copy time involved.