Always-On Availability in Adabas

Hey all,

I currently run ADABAS with four DBs (3 ADA and 1 ADA2). We write records using Natural 8.3.

For disaster recovery, we do nightly backups of the full database. This is simply accomplished by shutting-down the DB and using a file-based backup of the Adabas Containers to create a replica.

To date this has not caused an issue, and I have restored the DBs from this backup to our development server for testing reasons. However, as business expands I would like to be able to ensure ‘always-on’ availability of the DBs.

To the best of my knowledge, this would be accomplished through the use of the ADABCK routine. I performed an ADABCK on a DB, while it was live on my test server, and it produced a file. This file appears to be simply a copy of the DB itself.

I then attempted to perform a restore, and got the following error:

%ADABCK-E-BKNRDB, restore database not permitted while nucleus running.

This seems pretty obvious, as I attempted to do a full DB restore while the DB was still active.

I then attempted to do a file restore for a specific file on the DB while it is live and got:

%ADABCK-E-ALLOAD, File 20 already loaded

I then selected the option to do a ‘Replace existing files’ and closed my active session of Natural.

Overlay files from database 240 dumped on 18-APR-2019 10:00:26

-> Success! The specific file was replaced and I verified that an added record no longer existed.
This made me overly hopeful that I would be able to restore a file, while live, to the DB as long as records are not being held.

I then tried to repeat the exact same feat while maintaining a session of Natural and doing a simple query on the file.

%ADABCK-I-DBON, database 240 accessed online
%ADABCK-E-ADA048, File / Userid not available
%ADABCK-I-IOCNT, 1 IOs on dataset ASSO
%ADABCK-I-IOCNT, 2 IOs on dataset BCK001

So it appears that I am unable to restore a file live when I have an active user with the file open for access (ACC) or update (UPD) :(.

To check if it is related to having any user in the DB, or if it is specific to the file, I set-up a second user session (new etid) in Natural, and verified with ADAOPR that it was connected to the specific DB. I closed my session of Natural and attempted the restore again.

%ADABCK-I-DBON, database 240 accessed online
Overlay files from database 240 dumped on 18-APR-2019 10:00:26
Database 240, EEPROD
File    20, CODES-TABLE     , loaded on  7-APR-2017 10:05:15

So, when I have an active UID in the DB, it didn’t have a problem restoring the file! I checked with APAOPR display=uq_files and saw that it must have been because the specific file had not opened by any session’s id. Accessing the file with the second session, and then attempting to restore again gave the same error as before (File not available).

I then tried to run the following command:

ADAOPR db=240 lock=20

This allowed me to restore the file, however it resulted in running a STOP command for all the users accessing that file, but only in the DB specified. I would have to come up with a way to identify a) all the users whose IDs were stopped b) all their IDs in any other database so that they are all stopped. Otherwise they will get NAT 3145 (DB not available) while doing any action related to this DB.

So, based on my testing I have come to the conclusion:

  1. I can do live backups of my Adabas DBs using ADABCK
  2. I can do live restore of a file as long as there are no users accessing that file.
  3. I can kick out all users accessing a file, in order to restore it, by using LOCK=, HOWEVER this will kick them out of entire DB!
  4. I can only restore the entire DB if the nucleus is not active.

I have only looked into this for a few hours, so I would appreciate any discussion for how this is done in large production environments.

Please note, I am not asking about fail-over or DR features, as those are hard-ware related. I am merely seeking out what methods are used to maximize uptime in the event that the restoration of ‘some’ data is required.

Some utility and parameter names are different, but you are doing in the LUW world what has always been done with Adabas on the mainframe.

There have always been pesky users to stop, always the decision for on-line vs off-line backups, etc. etc.

  • File-by-file backups are more common than full database backups, in my experience.
  • Take time to compare DUMP and EXU_DUMP.
  • Take time to compare RESTORE and OVERLAY.
  • You can get pretty close to 24x7x365 availability.