OpenLogReplicator: Table Filtering Issues & Solutions

Jan 17, 2026 by Editorial Team 54 views

Hey everyone! Today, we're diving into some common issues encountered while using OpenLogReplicator, specifically focusing on table filtering. A user, let's call him Bob, ran into a few snags with lowercase characters, wildcards, and fully qualified table names. Let's break down the problems and see if we can find some solutions.

The Setup

Bob's using OpenLogReplicator version 1.9.0 with an Oracle source database. He's got two tables, SITUATION and SITUATION_HISTORY, both in uppercase, and they're getting regular updates. He's trying to filter these tables using the OpenLogReplicator.json configuration file, but things aren't working as expected. Let's explore each case he brought up.

Case 1: Wildcard Woes

The Problem: Bob tried using wildcards (% and *) in his table filter, but no tables were detected. Here's the configuration he used:

"filter": {
 "table": [
 {"owner": "TIBREPO", "table": "SI%"},
 {"owner": "TIBREPO", "table": "SI*HISTORY"}
 ]
}

Explanation and Solution:

Wildcards in OpenLogReplicator, specifically % and *, aren't directly supported for table filtering in the way one might expect from SQL LIKE clauses. The table filter is designed for exact matches or specific table names. So, guys, if you're thinking of using wildcards to grab multiple tables with a similar naming pattern, it won't work out of the box. Instead of using wildcards directly in the table field, consider explicitly listing each table you want to include.

If you have a large number of tables that follow a consistent naming convention, you might need to explore scripting or other methods to dynamically generate the OpenLogReplicator.json configuration file with all the specific table names listed. Keep in mind that the replicator requires explicit definitions for each table to be monitored. This design ensures that the replicator only processes changes from the tables you have specifically configured, enhancing control and minimizing unwanted data replication. This is a deliberate design choice to prevent unintended replication and maintain a clear scope of operation. Always double-check your configurations to make sure only the desired tables are included, especially in environments with numerous tables.

Case 2: Missing Owner - Not Allowed!

The Problem: Bob added a filter line without specifying the owner, resulting in an error.

"filter": {
 "table": [
 {"owner": "TIBREPO", "table": "SI%"},
 {"owner": "TIBREPO", "table": "SI*HISTORY"},
 {"table": "TIBREPO.SITUATION"}
 ]
}

The Error:

2026-01-16 08:51:16 INFO 00000 config file changed, reloading
2026-01-16 08:51:16 ERROR 20003 file: scripts/OpenLogReplicator.json - parse error, field owner not found

Explanation and Solution:

The error message is pretty clear: the owner field is mandatory. When defining a table filter, you must specify the owner (schema) of the table. This is essential for OpenLogReplicator to correctly identify the table in the Oracle database. The tool expects to find the owner, and when it's missing, it throws an error and refuses to proceed. Remember, always include the owner field to keep things running smoothly.

Case 3: Lowercase Catastrophe

The Problem: Bob tried using lowercase characters for both the table name and the owner, leading to errors.

Lowercase Table:

"filter": {
 "table": [
 {"owner": "TIBREPO", "table": "SI%"},
 {"owner": "TIBREPO", "table": "SI*HISTORY"},
 {"owner": "TIBREPO", "table": "situation"}
 ]
}

The Error:

2026-01-16 08:52:34 ERROR 30004 table 'situation' contains lower case characters, value must be upper case
2026-01-16 08:53:16 INFO 00000 config file changed, reloading

Lowercase Owner:

"filter": {
 "table": [
 {"owner": "TIBREPO", "table": "SI%"},
 {"owner": "TIBREPO", "table": "SI*HISTORY"},
 {"owner": "tibrepo", "table": "SITUATION"}
 ]
}

The Error:

2026-01-16 08:53:16 ERROR 30003 owner 'tibrepo' contains lower case characters, value must be upper case
2026-01-16 08:53:43 INFO 00000 config file changed, reloading

Explanation and Solution:

OpenLogReplicator requires both the owner and table names to be in uppercase. This is because Oracle, by default, stores object names in the data dictionary in uppercase unless they are created with double quotes (e.g., create table "schema"."mytable").

Handling Lowercase Identifiers:

If your Oracle database contains tables or schemas created with double quotes to preserve lowercase names, you'll need to ensure that the OpenLogReplicator.json file reflects these case-sensitive names exactly. However, the tool might not directly support lowercase identifiers. In such cases, you might need to explore workarounds, such as creating views with uppercase names that point to the lowercase tables or using a transformation layer to handle the case conversion.

It's crucial to test thoroughly to ensure that the replicator correctly identifies and replicates data from these lowercase-named objects. Always refer to the official OpenLogReplicator documentation for the most accurate and up-to-date information on supported naming conventions and potential workarounds for case-sensitive identifiers. Additionally, engaging with the OpenLogReplicator community or support channels can provide valuable insights and solutions from other users who have encountered similar challenges. Keep an eye on future releases, as updates might include improved handling of lowercase identifiers.

Case 4: Fully Qualified Names - A Missed Connection

The Problem: Bob tried specifying the table name fully qualified with the schema (owner), but the table wasn't detected.

"filter": {
 "table": [
 {"owner": "TIBREPO", "table": "SI%"},
 {"owner": "TIBREPO", "table": "SI*HISTORY"},
 {"owner": "TIBREPO", "table": "TIBREPO.SITUATION"}
 ]
}

Explanation and Solution:

OpenLogReplicator expects the table field to contain only the table name, not the fully qualified name. The owner field is used to specify the schema. Combining them in the table field confuses the tool, and it fails to recognize the table. Always keep the owner and table name separate in the configuration.

Case 5: Success! (Finally)

The Problem: Bob added a line with the table name in uppercase, along with the owner, and it finally worked!

"filter": {
 "table": [
 {"owner": "TIBREPO", "table": "SI%"},
 {"owner": "TIBREPO", "table": "SI*HISTORY"},
 {"owner": "TIBREPO", "table": "SITUATION"}
 ]
}

Explanation and Solution:

This case highlights the correct way to specify a table filter in OpenLogReplicator. By providing the owner and the table name (in uppercase) separately, the tool can successfully identify and replicate the data. This confirms that OpenLogReplicator expects table names to be in uppercase and that the owner must be specified correctly. When in doubt, double-check the case and ensure that the owner and table names are specified as separate fields.

Key Takeaways and Best Practices

Alright, guys, let's wrap up what we've learned. When configuring table filters in OpenLogReplicator, keep these points in mind:

Case Matters: Always use uppercase for table and owner names, unless your Oracle objects are explicitly created with double quotes to preserve lowercase.
Owner is Mandatory: Don't forget to specify the owner (schema) for each table.
No Wildcard Magic: Wildcards aren't directly supported in the table field. List tables explicitly.
Keep it Separate: Use the owner and table fields for their intended purposes. Don't combine them.
Consult the Docs: Always refer to the official OpenLogReplicator documentation for the most accurate and up-to-date information.

By following these guidelines, you'll be well on your way to successfully filtering tables and replicating data with OpenLogReplicator. If you're still running into issues, don't hesitate to seek help from the community or support channels. Happy replicating!