When Stitch replicates data from an Oracle-backed database, it will check for the required user permissions and database server settings. If permissions or server settings aren’t properly defined, you may receive an error during the Extraction phase of the replication process. These errors will surface in the integration’s Extraction Logs.

Oracle-backed databases

The errors and troubleshooting steps in this article are applicable to the following database integrations:

Extraction errors and troubleshooting

Below are the errors you might see if Stitch has trouble replicating data from an Oracle-backed database, as well as how to resolve them.

LogMiner is NOT supported for views. Please change the replication method for [table_name]

Meaning

The source object is a database view. Binary logging doesn’t track events that occur in database views, so Stitch is unable to use Log-based Replication for views.

Troubleshooting

To replicate the view, its Replication Method must be Full Table Replication.

Unable to replicate with logminer for stream([table_name]) because supplmental_log_data is not set to 'ALL' for either the table or the database. Please run: ALTER DATABASE ADD SUPPLEMENTAL LOG DATA (ALL) COLUMNS;

Meaning

Supplemental logging is incorrectly defined either for the database or the table. Supplemental logging is required by Oracle to use LogMiner, which Stitch uses to perform Log-based Incremental Replication.

Troubleshooting

Stitch supports supplemental logging at the database and table level:

  • If enabled at the database level, tables do not need to be individually configured:

     ALTER DATABASE ADD SUPPLEMENTAL LOG DATA (ALL) COLUMNS

  • If enabled at the table level, tables need to be individually configured. Run the following for every table you want to replicate through Stitch:

     ALTER TABLE <SCHEMA_NAME>.<TABLE_NAME> ADD SUPPLEMENTAL LOG DATA (ALL) COLUMNS

Refer to the Oracle documentation for more info.

ORA-01291: missing logfile

Meaning

The requested log file has been removed from the server. When a log file is removed before Stitch can read from it, replicaiton will be unable to proceed.

This error typically arises due to insufficient RMAN retention policy settings, which define how long log files remain on a server before they’re automatically purged.

It can also be caused by log files being purged before historical replication completes or critical errors that prevent Stitch from replicating data. When this occurs, it means Stitch was unable to proceed to the log file before the retention period passed and the log was purged.

Troubleshooting

To resolve the error, you’ll need to perform an integration-level reset. To do this, open the Integration Settings page and click the Reset Keys button. This will clear the integration’s Replication Keys and queue a full re-replication of the integration.

To prevent this error in the future, verify your RMAN retention policy settings and update them if needed. Stitch recommends a minimum of 3 days, but 7 days is preferred. This ensures that you have time to resolve any issues that arise before logs age out and are purged. Refer to the Oracle documentation for more info.

In addition, make sure you resolve any connection or replication issues quickly. This will reduce the likelihood that log files will age out and cause this error.

ORA-01292: no log file has been specified for the current LogMiner session

Meaning

LogMiner is unable to locate the System Change Number (SCN) value Stitch has saved. SCNs are used to identify data in log files for incremental replication.

This may occur for a few reasons:

  1. No new data is logged for the length of the RMAN retention window. For example: If the RMAN retention window is set to 2 days and no new data is created for two successive days, this error may occur.
  2. The integration is paused for longer than the RMAN retention window. For example: If the RMAN retention window is set to 2 days and the integration is paused in Stitch for longer than two days, this error may occur.
Troubleshooting
  1. Verify the current RMAN retention window length.
  2. Increase the RMAN retention window. For example: Increase the window from 2 days to 7.
  3. Perform an integration level reset. To do this, open the Integration Settings page and click the Reset Keys button. This will clear the integration’s Replication Keys and queue a full re-replication of the integration.
Questions? Feedback?

Did this article help? If you have questions or feedback, feel free to submit a pull request with your suggestions, open an issue on GitHub, or reach out to us.