Server Processing Activity
The way the server processes replicated transactions is affected by configuration flags. You can use these configuration flags to do the following:
• Quiet and activate CDDSs, databases, and servers
• Detect lock contention
• Manage memory to fine tune processing performance
Server, Database, and CDDS Status
You can control traffic in a server by quieting or activating:
• The whole server
• Specific target databases
• Specific CDDSs
To affect a running server, you must send an event to it.
Visual DBA and Performance Monitor: For more information, see the Raising Events at the Server Level topic in online help for Visual DBA or Visual Performance Monitor. 
Replicator Manager: You can send an event from the Replication Monitor or from a terminal monitor. For more information, see Send Database Event Window. 
Servers, databases, or CDDSs can also be quieted by errors, depending on the error mode setting.
When you start a server, all databases and CDDSs are made active. You can, however, start a server in quiet mode by setting the Quiet Server (-QIT) flag as a startup parameter.
The flags that control server, database, and CDDS status are described below:
-NQT (Default)
An active server continually processes transactions for replication.
The Unquiet Server (-NQT) flag is primarily used on a server to resume propagation suspended with the -QIT flag.
-QIT
A quiet server ignores the activity in the replicated database and processes only the pending replication transactions when it receives a dd_go_servern database event. When used in conjunction with the -EVT flag, the server also processes transactions on a periodic basis. For more information, see -EVTn Flag--Use Event Timeout.
If the CDDS has QuietServer error mode and an error occurs, this flag is set against a server. Use the -NQT flag to activate the server.
-SGL
A single run server processes the pending replication transactions for its server number before it shuts down. This status is generally used to schedule the replication with the operating system’s job scheduling system.
-CLQ
If an error occurs that quiets a CDDS or database, the Clear Quiet Targets (-CLQ) flag resumes propagation. When
-CLQ is issued against a server, the server continues quiet; all quieted CDDSs and databases that the server is assigned to are activated for propagation.
-CLQ is issued against a server, the server continues quiet; all quieted CDDSs and databases that the server is assigned to are activated for propagation.
Note: The value of this flag is stored in the replicator system catalogs; using the dd_set_servern event merely causes the replication server to update the value.
-QDBn
The Quiet Database (-QDBn) flag suspends propagation activity to database number n. This flag can be set using the dd_set_servern event or in response to an error (if the error mode QuietDatabase was set).
Note: The value of this flag is stored in the replicator system catalogs; using the dd_set_servern event merely causes the replication server to update the value.
Use the -UDBn or -CLQ flag with the dd_set_servern event to resume propagation activity to a quiet database.
-UDBn(default)
The Unquiet Database (-UDB) flag resumes propagation activity to a database after it is suspended with the Quiet Database (-QDB) flag or by an error (if error mode QuietDatabase was set).
-QCDn
The Quiet CDDS (-QCDn) flag suspends propagation activity to CDDS number n. This flag can be set using the dd_set_servern event or in response to an error (if the error mode QuietCDDS was set).
Note: The value of this flag is stored in the replicator system catalogs; using the dd_set_servern event merely causes the replication server to update the value.
Use the -UCDn or -CLQ flag with the dd_set_servern event to resume propagation activity to a quiet database.
-UCDn(default)
The Unquiet CDDS (-UCDn) flag resumes propagation activity to a CDDS after it was suspended with the -QCDn flag or by an error (if error mode QuietCDDS was set).
Note: The QDB, UDB, QCD, and UCD flags do not take effect immediately; instead, they prevent or allow propagation the next time the servers read transactions from the distribution queue.
Lock Contention Detection
From the first time a record is manipulated in a distributed transaction until the last record of that transaction is processed, records applicable to the transaction are locked in the local and the target database and remain locked until the final COMMIT (or ROLLBACK) statement is issued.
Lock timeout is controlled by the Lock Timeout (-TOTn) flag, where n is the number of seconds. Ingres Replicator waits to obtain a lock before aborting the transaction and reprocessing the replication. The recommended value for n is 30 or greater. The default value is 60. The -TOTn flag can only be set in the configuration file; therefore, to change the value of -TOTn, you must stop and restart the server after editing the configuration file.
IMPORTANT! If deadlocking is a problem in your environment, replication can make the situation worse. If you are unable to resolve a deadlock, see Strategies for Avoiding Deadlock on page 187. If the problem persists, contact Actian Support for assistance.
Memory Management
Replicator Servers read the distribution queue into memory. If there is a high volume of replication activity, there is potential for the queue to become so large that the Replicator Server cannot efficiently handle it. To prevent this from occurring, Ingres Replicator provides the Transaction Break Limit (-QBT) and the Queue Read Limit (-QBM) flags, which define how many queue records can be read into memory.
The Replicator Server reads rows from the distribution queue up to the value of the -QBT flag (4000 rows by default) and begins looking for a logical break in the transaction to stop reading and start propagation. The maximum number of rows a Replicator Server can read into memory from the distribution queue is the value of the -QBM flag (5000 rows by default).
IMPORTANT! If the number of rows in a single transaction exceeds the value of the -QBM flag, the Replicator Server writes an appropriate error message to the replicat.log file and shut down. You need to increase the value of the -QBM flag and restart the Replicator Server.
The settings you choose for -QBM or -QBT depend on your operating system environment and the nature of your database transactions. If you find you are running out of virtual memory or you are paging excessively in the operating system, use values lower than the default. If you are reaching the default limits and are not having memory problems, increase the default.
Note: Once memory is acquired, a Replicator Server continually re-uses it. If a Replicator Server acquires too much memory, dynamically resetting the -QBT or ‑QBM values has no effect. To change memory usage, a Replicator Server must be shut down and restarted.
Last modified date: 04/03/2024