When installing and configuring an ADABAS serverdb, the user must determine whether this serverdb is to be used autonomously (stand-alone) or as part of a distributed configuration.
After installing a stand-alone serverdb, other serverdbs can be added to form a distributed configuration. During their installation, it must be ensured that the value of the configuration parameter MAXSERVERDB on all participating serverdbs is equal to or greater than the number of serverdbs belonging to the distributed system. These serverdbs can be installed either on the same computer or on other computers. When installing new serverdbs in a distributed configuration, these are provided with both the current global catalog and the current state of all replicated tables of the distributed configuration. When doing so, a serverdb (sponsor serverdb) within the distributed configuration must be specified. The names of the serverdbs must be unique within a distributed configuration.
To process SQL statements in a distributed configuration, internal orders are sent to several serverdbs and executed there, and the result data or the return code is returned. Servertasks on each serverdb are used for such distributed command processing. The number of these servertasks is determined by the configuration parameter MAXSERVERTASKS. If too few servertasks have been configured, wait states occur during the processing of SQL orders sent to other serverdbs. It must be taken into account that servertasks are also needed for other purposes, e.g., for Save/Restore operations.
Serverdbs in a distributed configuration are completely autonomous with regard to restart/shutdown, save/restore, etc. The effects of CREATE/ALTER/DROP statements are known on all nodes because of the concept of a global catalog. Each user is assigned to the serverdb at which the CREATE USER statement was performed for him. All catalog entries for his database objects (e.g., tables) are stored on his serverdb. All serverdbs of a distributed configuration know all users and their serverdbs. Therefore, the pertinent catalog entries must be retrieved from the corresponding serverdb when executing a statement that concerns database objects of a non-local user. These catalog entries are stored in the catalog cache of the corresponding database session to save network communication for the repeated execution of the same commands.
For tables defined WITH REPLICATION, both the user data and the catalog information concerning the replicated tables are stored redundantly on all serverdbs belonging to the distributed configuration. Thus, it is possible to perform SQL statements concerning the replicated tables without having to access (network communication) catalogs located on other serverdbs.
Replicated tables can be modified even if single serverdbs have failed or are shut down. A majority principle prevents table replications in separate subnetworks from being modified in different ways. Replicated tables can only be modified as long as the majority of the serverdbs belonging to a distributed configuration is operational and accessible. This means that a smaller subnetwork has no right to make modifications. For an equal number of serverdbs, the internal numbering of serverdbs is decisive.
When restarting, replicated tables are automatically updated to the most recent state within the network either by redoing the modifications made during the time of failure or by completely transferring the latest table contents.
In addition to replicated tables as synchronous copies, ADABAS supports asynchronous copies in the form of snapshots. Snapshot tables typically require a distributed configuration in which data from one serverdb is provided on other serverdbs in the form of extracts, the snapshot tables. Snapshot contents are explicitly updated with the refresh statement. For snapshots based on source tables, a snapshot log can be used to incrementally transfer the modifications. For snapshots with a more complicated structure (joins), the complete snapshot contents are always transferred with refresh.
Besides this single-database distribution, ADABAS also supports multi-database distribution. The participating serverdbs are then configured as autonomous serverdbs with their own local SQL catalogs. To access remote tables, DATABASE LINKs and, sometimes, synonyms must be defined.