StarQuest Technical Documents

SQDR Plus Troubleshooting Tips

Last Update: 1 October 2021
Product: SQDR Plus
Version: 4.50 or later
Article ID: SQV00PU010


This document contains generic troubleshooting tips for SQDR Plus. Most of these tips apply to all source DBMS types; please refer to the appropriate technical document for DBMS-specific issues.

Additional troubleshooting hints can be found in these technical documents

The following topics are covered:

The following topics apply to specific versions of SQDR Plus and can be resolved by updating:

Unable to login to SQDR Control Center after an upgrade of SQDR Plus

Symptom: Credentials are rejected with the error "Login request failed. The response could not be deserialized."

Solution: Refresh the webpage in the browser.

Unexpected Control Center Behavior

Symptom: After upgrading SQDR Plus, SQDR Control Center is not behaving as expected - e.g. new functionality is not working, or you get the error "Request failed. 500 the call failed on the server; see server log for details" and the jetty wrapper log C:\ProgramData\StarQuest\sqdrplus\jetty\logs\wrapper.log contains GWT (Google Widget Toolkit) serialization errors.

Solution: Refresh the Javascript cache in the browser by using control-F5.

Shortcut to Control Center opens wrong port

Symptom: If you remove SQDR Plus and reinstall specifying a different port for the Control Center service, the shortcut attempts to use the original port.

Solution: Log off and log on.

Invalid Data Conversion Error after Schema Change on the Source

Symptom: The following error was encountered after a schema change (increasing the width of a character column) was made on the source, and the agent was continuously restarting to recover from the error:

SEVERE: [sqv][Thread-122][09.09.2013 15:43:50] CaptureAgentLog: [jcc][1091][10404][3.65.77] Invalid data conversion: Parameter instance ?1?0.?00 is invalid for the requested conversion. ERRORCODE=-4461, SQLSTATE=42815

Solution: Set validateMetadata=true in the agent configuration and restart the agent. All altered tables will be flagged for a new baseline.

Configuring extended_row_sz in the Db2 LUW staging database

Symptom: The following issue was encountered when performing incremental replication between two SQL Server databases. A snapshot replication of the same table encountered no problem.

Failed to add incremental subscription at Capture Agent for source table 'dbo.mytable'. Snapshot could not be started. Error: Stored procedure SQDR.ADDSUBSCRIPTION 04.22.20140314 returned error 11. RemoteException occurred in server thread; nested exception is:

java.rmi.RemoteException: Failed to add subscription: DB2 SQL Error: SQLCODE=-670, SQLSTATE=54010, SQLERRMC=32677;;71136, DRIVER=3.66.46 SQLSTATE=54010

The error message indicates that the source table exceeds the capacity of the intermediate staging database. This was confirmed by examining the CREATE TABLE statement in the details of the subscription).

Solution: Modify the staging database configuration used by the staging agent to use "extended_row_sz" ENABLE setting. This will permit the staging database to accomodate the larger row size required by this subscription.

  1. Identify the Db2 LUW staging database being used by the staging agent by examining the controlDbUrl parameter in the SQDR Plus configuration panel. controlDbUrl is of the form jdbc:db2://localhost:50000/SQDRPnn:driverType=4;deferPrepares=false; and we are interested in the value of SQDRPnn, where nn is a one or two digit number, 0 through 99.
  2. Stop the agent
  3. Using the Db2 Command Window (Administrator) issue the following commands:

db2 connect to SQDRPnn
db2 update db cfg using extended_row_sz ENABLE
db2 connect reset

  1. Start the agent.
  2. Run the subscription and confirm that it succeeds.

Note: This tip applies only to Staging agents created with versions of SQDR Plus earlier than 4.50. The staging databases associated with agents created with SQDR Plus v4.50 and later are already configured with the "extended_row_sz" ENABLE setting.

Agent fails to start with "Port already in use" error (SQDR Plus 5.00 & earlier)

Symptom: An agent fails to start, and an error like this appears in the Diagostics (the port number will vary based on your configuration):

java.rmi.server.ExportException: Port already in use: 50008; nested exception is: Address already in use: JVM_Bind

This condition is intermittent, and the agent will often start if you reboot the system or restart the SQDR Plus Launch Agent service. It has been observed on systems with a large number of agents.

Solution: SQDR Plus is using TCP/IP ports starting at 50005 for RMI communications. This range is also part of the default dynamic port range on Windows, and another process may have already opened that port for outbound communcations before the agent in question started.

To discover which process is using the port:
C> netstat -a -b
and search the output for port in question.

Short term solution:

Identify and stop the application using the port and start the agent. The other application will then use a different port when it is restarted.

In one case, we discovered that the conflicting application was another SQDR Plus agent - netstat -a -b displayed java.exe as the application, and that the port was in use by a database connection to the second host system. After stopping the second agent, we were able to start the problem agent, and then restart the second agent.

Long term solution:

Install SQDR Plus 5.01 or later (which implements the following)


Use the following command to display the dynamic port range currently in use:

C> netsh int ipv4 show dynamicport tcp

Protocol tcp Dynamic Port Range
Start Port : 49152
Number of Ports : 16384

Then change the starting point of dynamic port range to higher port (above the range used by SQDR Plus and Db2):

C> netsh int ipv4 set dynamicport tcp start=51000 num=14536

This change is persistent.

Data out of range error (SQLCODE=-302, SQLSTATE=22001) for Db2 LUW Staging Table

Symptom: The following error appears, referencing the Db2 LUW staging database, and is related to particular data in a CHAR or VARCHAR column DB2 SQL Error: SQLCODE=-302, SQLSTATE=22001

Solution: The error indicates data out of range (too large to fit in the corresponding column of the table).

This error may occur if a CHAR or VARCHAR column contains data that (when converted to UTF-8) is too large to fit in the destination column in the Db2 LUW staging table. For example, a SQL Server source table may include columns containing the x8D character, which converts to a 3 byte sequence when converted to UTF-8.

This is a rare condition; the default inflation of 100% (i.e. CHAR and VARCHAR columns in the Db2 LUW staging table are double the size of the corresponding columns of the source table), is usually more than sufficient. If you are affected by this issue, we recommend working with StarQuest support, who will verify that this is the cause of the problem, and will either alter the Db2 LUW staging table, or temporarily change the SQDR Plus inflation property from 100 to 200, drop the subscription, wait for pruning to remove the Db2 LUW staging table (this may take up to 30 minutes), recreate the subscription, and change the inflation property back to 100.

AGENT_STACK_SZ error from Db2 LUW staging database

Symptom: When running an incremental group with a large number of tables, the following error was received:

Stored procedure SQDR.GETCHANGE3 04.91.20171002 returned error 11. DB2 SQL Error: SQLCODE=-973, SQLSTATE=57011, SQLERRMC=AGENT_STACK_SZ, DRIVER=4.19.66
Last GetChanges call: 2017-10-23 07:15:34.668000
Last Acknowledged: X'000000000000042E3FB3'
Pending Acknowledged: X'000000000000042E3FB3'

Solution: This is known issue which may occur when a large number of tables are involved in a single cycle of obtaining changes. This will be resolved in a future version of SQDR Plus.
Workaround: reduce the maximum number of transactions (an "advanced" group property) from 0 (no limit) to a number such as 100.

SQ_JRNMAP or SQ_LOGMAP Table Not Found error (SQLCODE=-204, SQLSTATE=42704)

Symptom: The following warning appears in the agent diagnostics:


This message indicates that the indicated table (SQ_JRNMAP or SQ_LOGMAP) does not exist in the local Db2 LUW staging database. This table is created when you create a subscription.

Solution: Create a subscription or disable the agent until you are ready to create a subscription.

This issue will be addressed in a future version of SQDR Plus.

Using JRE 9 and later

We recommend using the certified version of the Java Runtime Environment (a recent version of JRE 8) that is installed with SQDR Plus. The following considerations apply when using JRE 9 or later; however, this is supplied for informational purposes and is not a supported or recommended environment, as there are known issues related to sending email when using JRE 9 or later.

  • Use v4.96 or later of SQDR Plus.
  • Create a text file C:\ProgramData\StarQuest\sqdrplus\conf\wrapper-local.conf (/var/sqdrplus/conf/wrapper-local.conf on Linux)
  • For JRE 9 and 10, wrapper-local.conf should contain the following directive:


  • For JRE 11 and later, download the JAXB-RI standalone distribution from, extract the following .jar files, and place the following directives in the wrapper-local.conf:\jaxb\jaxb-api.jar\jaxb\jaxb-runtime.jar\jaxb\istack-commons-runtime.jar\jaxb\javax.activation-api.jar

Note that the numbering may change in future versions of SQDR Plus if additional jar files are added to the CLASSPATH in the base wrapper.conf (C:\Program Files\StarQuest\sqdrplus\CapAgent\wrapper\conf\wrapper.conf).

Failure to do this will result in the following error in the CapAgent wrapper log:

Exception in thread "main" java.lang.NoClassDefFoundError: javax/xml/bind/JAXBException


Reclaiming Disk Space

Over time, dIsk space utilitization can grow, especially if there has been an incident that resulted in the logging a large number of errors or a backlog of change data. Here are some suggested methods of lowering disk utilization.

  • Db2 Table Space Storage (used by the local Db2 staging databases) - see Db2 LUW Staging Database - Storage Maintenance.
  • Logs in C:\ProgramData\StarQuest\sqdrplus
    • conf/wrapper.log
    • derby/logs/wrapper.log
    • jetty/logs/wrapper.log
    • derby/derby.log
  • Db2 files in C:\ProgramData\IBM\DB2\DB2COPY1\DB2 or C:\ProgramData\IBM\DB2\DB2COPY1\DB2\DIAG0000
    • Old db2diag.log files. Use db2diag -A to rotate the logs.
    • *,trap.bin, *.db2pd.bin, javacore*, Snap.*
    • FODC.* subdirectories
  • Run Windows Disk Cleanup, including system files. This is recommended after a Windows Update.
  • Installer images (downloaded zip files and expanded directories) that are no longer needed, especially large installers such as Db2 & IBM Data Studio.

StarAdmin shortcut fails to locate javaw.exe


After an update of SQDR Plus to 5.22 or later, StarAdmin fails with a "Searching for javaw.exe" message.


SQDR Plus 5.22 & later uses the environment variable JRESQ to locate javaw.exe. Installing the JRESQ package first, then rebooting before updating SQDR Plus should result in the correct shortcut for StarAdmin for the initial update (this is not necessary for future updates). Failing to reboot before updating SQDR Plus will result in a poorly-formed shortcut for StarAdmin. In addition, on rare occasions we have seen a problem even on a fresh install.

To fix the shortcut:

Right-click on the StarAdmin Program Group item and select Open File Location

This should open the folder:
C:\ProgramData\Microsoft\Windows\Start Menu\Programs\SQDR Plus (64-bit)\Tools\StarAdmin

Right click on StarAdmin and select Properties.

Modify the Target field to begin with:

Unable to open wrapper.conf (Linux/AIX)

Symptom: After installing or updating SQDR Plus on Linux or AIX, messages similar to the following appear in the terminal console when trying to start the SQDR Plus services:

FATAL | wrapper | Unable to open configuration file. /opt/StarQuest/sqdrplus/capagent/wrapper/conf/wrapper.conf

Solution: This error can result if the user performing the installation or update (e.g. root) is using a umask with restrictive file permissions - e.g. a umask of 027 will prevent the sqdr user (running the service) from accessing the files it needs to read. We recommend setting umask 022 to ensure that the SQDR Plus program files are readable by the sqdr user.


The information in technical documents comes without any warranty or applicability for a specific purpose. The author(s) or distributor(s) will not accept responsibility for any damage incurred directly or indirectly through use of the information contained in these documents. The instructions may need to be modified to be appropriate for the hardware and software that has been installed and configured within a particular organization.  The information in technical documents should be considered only as an example and may include information from various sources, including IBM, Microsoft, and other organizations.