This section examines aspects of the backup concept that apply specifically to distributed processing with SESAM/SQL-DCN. Cross-configuration transaction logging ensures that no data losses or inconsistencies will be incurred by the failure of a component in the computer network.
Distributed transactions
A transaction is regarded as distributed if more than one DBH is involved in processing it. A distributed transaction is processed in three steps (see figure 29).
Figure 29: Execution of a distributed transaction
”Configuration A”,
“Configuration B” and
“DBH 2” and
“DBH 4” in figure 29
refer to the situation illustrated in figure 28.
Processing phase
The first SQL statement that introduces the transaction, or the BTA statement in CALL DML, and the transaction's other SQL or CALL DML statements are executed.
PTC phase (Prepare To Commit)
The processing phase within the transaction has finished. The changes made are logged to guard against system failure, but they can still be reversed. The final end of the transaction cannot be finally completed until “prepared to commit” has been confirmed by all the DBHs involved.
“Final termination of the transaction” phase
The transaction is irrevocably terminated: All changes are committed or reset.
The master DCN and the backup file
Master DCN
If a computer crashes, SESDCN has to be restarted in order to maintain transaction consistency (see “SESDCN restart”). The coordination and execution of the restart is SESDCN's responsibility. SESDCN also monitors the creation of backup files. If SESDCN was loaded more than once in the configuration, the SESDCN loaded first carries out this task. The SESDCN that controls the restart is referred to as the master DCN.
The backup file
A backup file containing the restart data has to be available for a restart after a system failure to succeed.
The master DCN checks whether the backup file already exists.
If no corresponding file exists yet, the backup file is created under the file name specified via the link name SESDLG the first time the master DCN is started or, if no assignment exists under this link name, under the default file name in the user ID in which the master DCN is loaded.
The file can be supplied with a password using the SET-DCN-OPTIONS statement SESDLG-PASSWORD. Password protection applies both to read and to write accesses.If a backup file already exists and is not yet password-protected, password protection can only be achieved using the BS2000 command MODIFY-FILE-ATTRIBUTES. Password protection should cover both read and write access here, too. If it opens an existing backup file, the master DCN determines whether a restart is necessary.
The naming conventions, the access method and the default assignment for SESDCN's backup file are as follows:
Standard name | SES.DLGc |
Link name | SESDLG |
Access method | PAM-shared (or SHAREUPD) |
Primary/secondary assignment | 9 / 24 |
The name of SESAM/SQL-DCN's backup file includes the configuration name “c”, which assigns it to the configuration to which the master DCN belongs.
System administrators can also create the backup file under a name of their choice using the SDF command CREATE-FILE, and can assign it with the link name SESDLG.
SESDCN restart
The backup file contains information indicating whether the last SESDCN session terminated correctly. The next time SESDCN starts, the master DCN opens the backup file and checks whether a restart is necessary. A prerequisite for restarting SESDCN is that the DBHs involved in distributed processing are capable of restarting.
An SESDCN restart constitutes the logical continuation of the previous SESDCN run; as a result, all the load options used in the previous run apply again.
The handling of distributed transactions
The way in which SESDCN handles distributed transactions during a restart depends on the phase of processing in which the previous SESDCN run was aborted, and on the result of the DBH restart performed prior to the SESDCN restart.
The way in which the DBH handles the transactions varies, depending on the time at which the system failed:
The DBH rolls back a transaction during a restart if the transaction was in the processing phase and PTC phase had not yet been completed from the DBH's point of view.
Transactions that had completed the PTC phase when the system failed remain in this state when the DBH restarts. The decision on whether to roll back or terminate such transactions is not made until SESDCN restarts and the information in the backup file is evaluated.
Restarting SESDCN on a remote computer
SESDCN can be restarted on the computer on which it was originally started (the cold-start computer) or on a different computer. A prerequisite for performing the restart on a different computer is that configuration names that are unique network-wide were assigned when the system was generated.
In order to perform the restart on another computer, the whole configuration has to be moved to that computer. This means that all the application programs, SESDCNs, DBHs, the backup file, and all the DBH-specific files that belong to the configuration have to be moved to that computer. All the required tasks must be restartable on the new computer. In addition, the system environment for the DBH must be the same on the new computer, i.e. the DBH user IDs must be the same on the new and old computers. In the same way, the DB user IDs must be the same on the new and old computers.
Updating the distribution rules
If the SESDCN restart takes place on a different computer, the location of the restart configuration within the computer network changes from the point of view of the other configurations. For this reason, the restart configuration's master DCN automatically replaces the old processor name in the distribution rules for the remote computers it knows and can access with the name of the computer on which the restart takes place. This ensures that communication is still possible with the configurations on these machines.
If not all the remote computers in the network are accessible to the master DCN at the time of the SESDCN restart, the master DCN cannot change all the distribution rules automatically. If this is the case, system administrators have to update some of the distribution rules by issuing the appropriate administration statements (see the “Database Operation” manual).
If a number of different configurations perform their SESDCN restarts on different computers after a crash, a full update of the distribution rules by the relevant master DCNs is likewise impossible. In this case, system administrators have to update a number of distribution rules with SESDCN administration statements.