Updating SAP ABAP Systems on UNIX and Linux: SAP MaxDB

Error Handling for the Replication Process Monitor

The CRR Control Center (Replication Process Monitor) displays the current status of the Change Recording and Replay (CRR) procedure during the uptime.

The following issues regarding the Replication Process Monitor are known and may possibly occur:

Replication Not Running

The Software Update Manager stops with the following error message:

You cannot enter the downtime yet. You must wait until the replication progress has reached at least 75 percent.

If possible, restart the replication as follows:

  1. Open the extended UI as described in SUM Utilities (Extended UI) and navigate to the Process Control Center.

  2. Select the CRR Control Center and check in the current replication status if the replication is not running. If so, start the replication.

PXA Buffer Too Small (ABAP-Based Replication Only)

Note that this issue applies to the ABAP-based replication only. If the PXA buffer is too small, short dumps during the update can occur that contain PXA_NO_FREE_SPACE in the error message. This PXA buffer contains the ABAP loads that are needed for the ABAP runtime in the shadow instance.

To solve the issue, reduce the number of processes used for the replication or increase the system parameter abap/buffersize as follows:

  1. Stop the shadow instance (including transfer).

  2. Adapt the shadow instance profile in directory <SUM directory>/system/<SID>/SYS/profile by adding or adjusting the parameter abap/buffersize with an appropriate value.

  3. Start the shadow instance (including transfer).

  4. Restart the replication from the CRR Control Center (Replication Process Monitor).

Tablespace Too Small

If you encounter short dumps indicating that a tablespace overflow occurred, increase the tablespace and restart the transfer.

Error Message in Phase PROCESS_REPLICATE_RRC_STOP

In the log file REPLICATERRC.LOG, you detect the following error message:

Replay of changes could not be stopped

To solve the issue, proceed as follows:

  1. Log on to the shadow instance.

  2. Start transaction SM37 (Overview of job selection).

  3. Select the running transfer job and check its status by choosing Start of the navigation pathJob  Next navigation step  Check StatusEnd of the navigation path. When the list is refreshed, the job status changes from status Active to Canceled.

  4. Restart the transfer from the CRR Control Center (Replication Process Monitor).

  5. Repeat the phase PROCESS_REPLICATE_RRC_STOP.

The System Shows a Slow Replication Progress

You notice that the replication process is slow. In transaction SM50, you can see that the jobs for a lock on table CRRTI or a select on table CRRTASKINFO take a long waiting time. Furthermore, the select on table CRRTASKINFO takes longer than 1 second.

To solve the issue, update the statistics for the tables CRRTASKINFO~, UPGTRTOUCH, CRRRTI~, and CRRRTIT~.

Replication Fails on Tables with Secondary Unique Indices

You added a table manually to the uptime handling of the downtime-optimized DMO procedure. The table does not receive any structural changes or imports. However, the replication of the table repeatedly fails, and the replication log file contains the following error message:

MODIFY unexpectedly failed for table <...>.

The reason Is that the update patterns of the table on the source database are too complicated for the replication so that conflicts in secondary unique indices cannot be resolved. As a result, the writing to the target database is prevented.

To solve the issue, proceed as follows:

  1. Set a breakpoint at phase PROCESS_REPLICATE_RRC_START.

  2. Drop the secondary unique indices before the phase PROCESS_REPLICATE_RRC_START starts. Do it at the latest when the breakpoint is reached.

  3. Set a breakpoint at phase XPRAS_AIMMRG and continue with the SUM procedure.

  4. Recreate the indices manually. Carry this out asynchronously after the phase RUN_RRC_REPLICATE_FINAL is completed.

    Note that phase RUN_RRC_REPLICATE_FINAL begins shortly after phase DOWNCONF_DTTRANS.

  5. When the phase XPRAS_AIMMRG is reached, wait until all indices are successfully recreated.

  6. Afterwards, remove the breakpoints and proceed as normal.

If the table was NOT added manually, other reasons are possible: a structural change, a new secondary unique index, or imports. In this case, the issue must be solved by the component of the affected table.

Aborted CRR Agent Batch, Status Black in Phase DOWNCONF_DTTRANS or Error in Phase RUN_RRC_READYFINAL

The following errors may occur:

  • during the uptime replication:

    • you detect in the shadow system dumps with an aborted CRR agent batch process of class CL_CRR_AGENT_BATCH

    • the replication status is Black (= the downtime after phase DOWNCONF_DTTRANS cannot be entered) without single tables showing errors

  • during the downtime:

    • the SUM stops in phase RUN_RRC_READYFINAL with the error message ERROR: there are still <...> tasks not in state READY

To solve the problems, proceed as described in the following. The first steps apply equally to downtime and uptime. This is followed by additional steps for uptime or downtime.

  1. Uptime and Downtime:

    1. Log on with user DDIC to the shadow (!) system.

    2. Call transaction SM50 and note down the replication jobs.

    3. In a second window, call transaction SE37.

    4. Enter function module CRR_TRANSFER_CONTROL.

    5. Execute (F8) the function module for testing purposes with parameter IV_ACTION = STOP.

    6. Check the first window, in which transaction SM50 is running, wait until all replication jobs are stopped. It should only take some seconds.

    7. In the second window, in which transaction SM37 is running, check if the function module is still being executed. If so, cancel the process using the menu items Start of the navigation pathSymbol Next navigation step Stop TransactionEnd of the navigation path.

    8. Call transaction SE37 and enter function module CRR_TRANSFER_CONTROL again.

    9. For testing purposes, execute the function module with parameter IV_ACTION = START and IV_REQUESTED_BATCHES = <number of uptime replication processes>.

    10. Within a few seconds, the replication jobs should return and be visible in transaction SM50. There should also be a new process RSUPG_ASYN_RUN_REPLICATE, which is the previously aborted but now restarted job.

    11. Call transaction AL11 and navigate to the directory Start of the navigation pathDIR_PUT Next navigation step abap Next navigation step tmpEnd of the navigation path.

    12. Check if the file RRC_REPLICATE.<SID> has been updated at the restart of the replication.

  2. The following steps for uptime only:

    1. 1.Go to the CRR Control Center of the SUM Utilities and start the replication.

    2. Check using transaction AL11 that the file CRR_TRANSFER_CONTROL_STATUS.<SID> is updated again about every 15 seconds.

  3. The following steps for downtime only:

    1. Switch to the second window, in which transaction SM37 is running for function module CRR_TRANSFER_CONTROL.

    2. Execute (F8) the function module for testing purposes with parameter IV_ACTION = STOP and wait until the process is finished.

    3. Resume the procedure in the Software Update Manager. The issue is solved, If the phase RUN_RRC_READYFINAL is passed.