Did this article resolve your question/issue?



Considerations using -bithold with Replication


TitleConsiderations using -bithold with Replication
URL Name000044059
Article Number000164655
EnvironmentProduct: OpenEdge
Version: 9.x, 10.x, 11.x
OS: All Supported Operating Systems
Other: Replication
Question/Problem Description
Considerations using the -bithold -bistall database startup parameters on Replication enabled databases.

When bistall on the source database has subsequently been addressed, how to release the replication target database status of:
(6560)  Forward processing stalled until database administrator intervention. 

Can replication resume after -bithold has been realised on either the source or target databases?

Replication DB stuck at "performing startup sync" status.
Steps to Reproduce
Clarifying Information
Error MessageForward processing stalled until database administrator intervention. (6560)
Defect/Enhancement Number
The easiest recommendation is to not set -bithold on the target database startup parameters, unless it is used purely as a 'stop' condition under abnormal/unexpected bi growth situations in order to rebaseline the target after the source environment has been resolved.
Always ensure when creating a target datbase baseline, there are more bi file space configured in the target structure than that on the source database.

In addition to the discussion below, there is also diskspace and available ai files to consider.
A. Once the -bithold value is reached against a source or target database, as long as synchronisation has previously completed, it can be raised with:
$  proquiet [source | target] -C bithreshold <value in MB>
B. Raising bithreshold on source directly affects target. Consider intially setting -bithold on target larger than that on source to provide sufficient time between raising thresholds against each database, or to not use the -bithold startup parameter on the target.
C. When the -bithold value is reached against the source database, if the -bithreshold is to be raised:
1. Raise the threshold then immediately stop replication from the source side which will set the target to PRE-TRANSITION mode if agent-shutdown-action=recovery is set otherwise the target agent will shutdown.
$  proquiet [source | target] -C bithreshold <value in MB>
$  DSRUTIL source -C terminate server
2. Once the final -bithreshold value on source is realised and the bi is no longer growing as the transactions involved have been resolved,
or the source is is finally shutdown, take special note of the final bithreshold value.
3a. If source was shutdown, truncate the bi against source and restart source.
3b. If source was not shutdown, restart the replication server.
4a. If the target was shutdown, restart the target without the -bithold startup parameter or at least 2x the last value on source noted in Step 2 above.
4b. If the target was not shutdown, increase the bithreshold value to at least 2x the last value on source noted in Step 2 above.
D:  After a condition where bithold has been increased online against the target database with "proquiet target -C bithreshold <value in MB>, 
following abnormal bi growth on source. The bithold startup parameter on the target has to remain at this raised size (viz GT last-bithold-value GT current bi HWM) until such time as the target database can be rebaselined.
Starting the target database with a lower value will fail to start:
BI file size is greater than the BI file threshold size. (6566)
You must truncate the BI file or increase the BI threshold size. (6567)
Whereas on the source database, after the bi file has been truncated, it can be restarted with intial bithold value as designed for application environment.
This is a design limit, the target bi cannot be truncated as it would break the replication model.
The only method of re-setting the bi sizes on a target database is to rebaseline the target database.
E: If during target startup, the -bithold value is close to the current bi HWM during synchronisation, the following messages will appear:
Current BI File size is greater than 90% of the BIFile threshold value. (9485)
The database will not be stalled until a new BI cluster is needed and created, which could then exceed the BI File threshold value. (9486)
If then during synchronisation, the -bithold value on target is realised:
(10392) Database \repl\target is being replicated from database \repl\source on host <IPAddress>.
(10489) Fathom Replication Agent agent1 is beginning Startup Synchronization at block 9780.
(9240)  BI File size has grown to within 90 percent of the threshold value of 83.0  MBytes.
(9239)  BI File Threshold size of 83.0  MBytes has been reached.
(6560)  Forward processing stalled until database administrator intervention.
The bithreshold value CANNOT be increased against the target database until synchornisation is complete:
$  proquiet target -C bithreshold 90
You are not licensed to access the database. (10830)
This is a design limit, limited database connections are allowed prior to synchronisation completing.
In order to recover, the target needs to be shutdown and started again with an appropriately raised bithold or ideally without a -bithold startup parameter at all. The exact -bithold (or bithreshold value for that matter) is not easy to determine as the size that the bi file will end up at is comparible to the size of the source bi file x 2 at the time that the source was last connected to the target when the bi chains were locked.
Last Modified Date4/6/2020 3:50 AM
Disclaimer The origins of the information on this site may be internal or external to Progress Software Corporation (“Progress”). Progress Software Corporation makes all reasonable efforts to verify this information. However, the information provided is for your information only. Progress Software Corporation makes no explicit or implied claims to the validity of this information.

Any sample code provided on this site is not supported under any Progress support program or service. The sample code is provided on an "AS IS" basis. Progress makes no warranties, express or implied, and disclaims all implied warranties including, without limitation, the implied warranties of merchantability or of fitness for a particular purpose. The entire risk arising out of the use or performance of the sample code is borne by the user. In no event shall Progress, its employees, or anyone else involved in the creation, production, or delivery of the code be liable for any damages whatsoever (including, without limitation, damages for loss of business profits, business interruption, loss of business information, or other pecuniary loss) arising out of the use of or inability to use the sample code, even if Progress has been advised of the possibility of such damages.