How to find the table affected by the error “Unable to get table definition for table '0'”

[raffaelec]

Hello,

I have configured a Log Stream task that reads from an Oracle database.

The task failed following a database maintenance activity that temporarily disabled the ARCHIVELOG log mode.

After ARCHIVELOG was re-enabled, I resumed the Log Stream task. However, the task is unable to complete the resume successfully and remains in the recovering state.

When reviewing the task log file, I can see the following error messages:

• Unable to get table definition for table '0'
• add table desc to the metadata manager has failed

I found the following link in the Qlik Community, which explains that the error retrieving the table definition should be caused by a DDL operation that modified the structure of a table: https://community.qlik.com/t5/Official-Support-Articles/SOURCE-CAPTURE-E-Unable-to-get-table-definit....

I tried increasing the task verbosity to understand which tables might have been affected by this change. Specifically, I increased the verbosity of the SOURCE_CAPTURE, SORTER, METADATA_MANAGER and TARGET_LOAD parameters. However, I cannot find any indication in the log file of which tables were affected by the modification.

Is there any way to identify in Qlik Replicate which tables were affected by the DDL operations that are causing a mismatch with the table metadata registered by Qlik Replicate?

Thank you in advance for your support.

Best regards

[iva89ward]

In this situation, table '0' usually doesn’t identify the actual Oracle table, so increasing task verbosity may not reveal it directly. I’d check the Oracle archived redo logs around the maintenance window for DDL operations and correlate the SCN/timestamp with the Replicate task log; you can then compare those objects against the tables included in the task. If no specific table can be identified, Qlik Support may need the task logs and recovery/metadata information to determine the affected object.
Mayo Clinic Patient Portal login

[john_wang · Accepted solution]

Hello @raffaelec ,

I was unable to reproduce the behavior in my lab using Replicate 2025.11 with an Oracle 19c PDB. My test procedure was as follows:

1. Start a Full Load + CDC task and verify that it works normally.

2. Stop the task.

3. Disable Oracle ARCHIVELOG mode and insert several rows into the test table.

4. Restart the Oracle database.

5. Re-enable ARCHIVELOG mode.

6. Resume the Replicate task. The task started normally, and the rows inserted while ARCHIVELOG was disabled were successfully captured and applied to the target.

Based on this test, it appears that there may have been other database activities or operations in your Oracle environment that affected the recovery.

If the task cannot resume successfully, I would suggest trying one of the following approaches:

• Start from a specific timestamp after ARCHIVELOG mode was re-enabled, if the changes before that point are not required.

• Perform a Full Load of the affected tables or tasks.

If possible, please also share the Oracle activities performed during the maintenance window. That may help us identify what is different between your environment and my lab test.

Hope this helps.

John.