To reduce the risk of a replication pool becoming full when a destination cannot handle the rate at which replication transactions are sent to it by the Event Replicator, you can now request that incoming compressed replication transactions be written to the SLOG system file, before they are queued to the assignment phase. This means that during the input phase, the compressed transactions are stored first in the Event Replicator Server replication pool, but then written to the SLOG system file, freeing up the space in the Adabas nucleus and Event Replicator Server replication pools. Such compressed input replication transactions written to the SLOG system file are called database-related input transactions.
To specify whether and when this happens, a LOGINPUTTRANSACTION (Log Input Transaction) parameter is provided. When logging of database-related input transactions is activated, every database-related input transaction from an Adabas nucleus will end up in the SLOG system file after the input phase. The LOGINPUTTRANSACTION parameter can be set as a threshold value so that this processing is only activated when a specified percentage of the Event Replicator Server replication pool space is used. When this threshold is exceeded, SLOG system file usage begins. If replication pool usage drops, the threshold is no longer exceeded, and all database-related input transactions have been processed, SLOG system file usage for database-related input transactions is turned off and normal processing resumes using only the replication pool. After being logged to the SLOG system file, the processing of database-related input transactions from the SLOG system file begins:
The transactions are returned to the replication pool, using a throttling mechanism so that only a limited amount of replication pool space is used at a time. Each transaction is queued to the assignment phase, at which point it is processed in the normal way.
Once each delogged transaction is fully processed by the assignment, subscription, and output phases, it is marked for deletion from the SLOG system file and the Event Replicator Server replication pool. It is deleted in chronological order (when all earlier database-related input transactions have been deleted, it is deleted).
Once processing of database-related input transactions from the SLOG system file has begun, all database-related input transactions are handled this way.
Note:
The SLOG system file can also be used by the Event Replicator for subscription
logging by destinations and for synchronized replay logging. The logging of
database-related input transactions from the Adabas nucleus takes priority over
these other uses of the SLOG system file.
This document covers the following topics:
In order to use the LOGINPUTTRANSACTION parameter, the SLOG system file must be defined for your Event Replicator Server. For complete information on the SLOG system file, all of its uses, and suggestions for determining its size, please read Setting Up Subscription Logging.
If an unexpected error is encountered writing or processing database-related input transactions on the SLOG system file, SLOG processing of database-related input transactions is suspended and all of the following actions are taken:
Replication is deactivated for the files with data on the SLOG system file.
Transactions held for writing to the SLOG system file are queued for the assignment phase for replication processing and processed in the normal manner.
The normal SLOG deletion routine will attempt to delete all of the database-related input transactions currently on the SLOG system file.
Processing of database-related input transactions on the SLOG system file is suspended until all database-related input transactions have been deleted.
No new database-related input transactions will be written to or held for writing to the SLOG system file nor will they be delogged from the SLOG system file.
When SLOG processing of database-related input files is suspended, an inactive file (with data in database-related input transactions on the SLOG system file) may not be activated until all database-related input transactions have been deleted from the SLOG system file.