The -pica source database startup parameter value reserves memory in KB units for the RPLS-Q and is allocated as such in database shared memory initialization at startup.
When the Replication Server (RPLS) process is running:
- The RPLS uses a buffer to store pointers to AI blocks as they are filled with AI transaction notes, that are yet to be transferred from the source database and committed to the target database(s).
- This buffer is referred to as the Database Service Manager queue (RPLS-Q), where the size is governed by the value of the -pica source database startup parameter and AI blocksize.
- It is essentially a FIFO (first in first out) queue, containing pointers to filled source AI blocks, that allows the source and targets to be asynchronous by buffering data transfer between the source and target database(s).
The RPLS begins to fill the RPLS-Q as soon as the replication enabled source database is started and the Replication Server (RPLS) process is initialized then ends if the source database
(control-agent) connect-timeout expires before communications with the Replication Agent (RPLA) have been established.
Unless at database startup, after the
connect-timeout has expired
defer-agent-startup mode is in effect. In which case the RPLS continues to attempt connection to the RPLA at 5 minute intervals filling the RPLS-Q until the defer-agent-startup time expires or
DSRUTIL -C canceldefer is called.
When the RPLS and RPLA have established contact and then loose contact at some future time, the source database's
Repl-Keep-Alive and
connect-timeout values affect how long the RPLS remains running filling the RPLS-Q until the RPLS eventually terminates.
While the RPLS-Q is being populated, RPLS-Q pointers are emptied out as each AI block is processed against the target database by the RPLA process. Once all the AI blocks associated with an AI file have been processed, that AI file status changes from LOCKED to FULL at which time it can be archived and emptied for re-use.
When the RPLS-Q is no longer being populated:AI transaction notes are stored in LOCKED AI files for processing at a later time when the Replication Server and Agent(s) have again established contact by being (re-)started and are connected, instead of filling the RPLS-Q.
In other words:
- While the RPLS is running, the maximum amount of AI transaction blocks that can be backlogged is based upon how many pointers to AI blocks can fit within the pica buffer (RPLS-Q) and the AI file capacity.
- While the RPLS-Q is being filled, all switched AI files will be marked LOCKED until such time as the last AI block in that AI extent has been processed against the target database.
- When the RPLS is not running, the amount of AI transaction blocks that can be backlogged is based only on the AI file capacity available. When switched AI files are marked as LOCKED pending connection to the RPLA and synchronization with the target, instead of filling the RPLS-Q.
Maximum value for -pica:
256 (9.1E, 10.0B, 10.1A)
1024 (9.1E04)
512 (10.0B05)
8192 (10.1A02, 10.1B01, 11.1)
1000000 (10.2B08, 11.2, and 11.3)
Considerations when setting the -pica value:
- The larger the Replication Server Queue (ie -pica), the less synchronised the target will be in the event of source database/machine failure, as there are more AI block(s) in transit between the source (RPLS) and the target (RPLA) at the time.
- In Application environments where multiple replication enabled source databases are connected to by the application, the -pica value should be the same for all source databases. If the RPLS-Q is not equal, if even one of the minimally used database's RPLS-Q buffer fills while the RPLS is running but not connected to its respective RPLA, then an application performance pause will be experienced until pointers are made available.
- There is a PICA queue on both the source and target databases
Choosing the best -pica value:The pica setting is not chosen based on database Buffer Hits but instead on:
- The rate at which of AI blocks are filled,
- The speed at which AI blocks can be transferred over the network and committed to the target database.
What is the difference between source and target PICA?There is a PICA queue on both the source and target databases.
- The size of the PICA queue on the target does not need to match that of the server
- The target does not need a large PICA and can be left at its default value, whereas the source PICA does need consideration as outlined above.
The PICA queue on the source is used:
- To communicate AI changes to the replication server
- By DSRUTIL to tell a replication server to terminate
- By DSRUTIL to tell a replication server start fail over transition
The PICA queue on the target is used:
- By DSRUTIL to tell a replication agent to terminate
- By online backup to tell a replication agent when the backup starts and when the BI portion of the backup has completed.
- By DSRUTIL to tell a replication agent to start transition.
Where to set PICA:
When the database is started with a script or from the command line, add the database startup parameter "-pica <value>"
When the replication enabled database is managed by the AdminServer, the pica value is set in the "dbservicecommareasize".
Prior to OpenEdge 11.6.3, 11.7.0 or later, the pica value needs to be set in "otherargs=-pica <value>". For further clarification refer to Article:
