In order to make your issue reports as actionable as possible, please provide the following information, depending on the issue type.

Bug report

For bug reports, provide this information, please:

What Debezium connector do you use and what version?

Strimzi Kafka Connect version: 3.4.0
kafka-connect.yaml

Strimzi Kafka Connect version: 3.4.0

kafka-connector-1.yaml

• debezium-connector-oracle-2.3.0.Alpha1-plugin
• ojdbc8-21.6.0.0.jar

What is the connector configuration?

    tasks.max: 1
    database.hostname: <db_host>
    database.port: <db_port>
    database.user: ${secrets:poc-secret:username}
    database.password: ${secrets:poc-secret:password}
    database.dbname: ORCLCDB.localdomain
    database.pdb.name: ORCLPDB1
    schema.include.list: CYTRICQA
    table.include.list: CYTRICQA.TLABEL_T
    topic.prefix: "oracle.cytric-poc."
    schema.history.internal.kafka.bootstrap.servers: kafka-bootstrap:9092
    schema.history.internal.kafka.topic: oracle.schema-history
    snapshot.mode: schema_only
    snapshot.include.collection.list: CYTRICQA.TLABEL_T
   schema.history.internal.store.only.captured.tables.ddl: true
   schema.history.internal.store.only.captured.databases.ddl: true

What is the captured database version and mode of deployment?

(E.g. on-premises, with a specific cloud provider, etc.)

It's deployed as Kafka Connector via the Strimzi operator on the OpenShift cluster at the in-house data center. The next one https://github.com/debezium/debezium-examples/tree/main/openshift was taken as a sample with modification according to Oracle's need due to the next documentation https://debezium.io/documentation/reference/2.3/connectors/oracle.html

What behavior do you expect?

I expect Debezium would capture schema changes during the snapshot phase and later on data changes only for one table named "TLABEL_T" from the single Oracle DB schema named "CYTRICQA" as specified in the next connector settings:

schema.include.list: CYTRICQA
table.include.list: CYTRICQA.TLABEL_T
snapshot.include.collection.list: CYTRICQA.TLABEL_T

What behavior do you see?

In the connect pod logs I see that configurations are parsed and matched provided in the deployment settings however Debezium throws "java.lang.NullPointerException: Cannot invoke "io.debezium.relational.Table.id()" because "table" is null" while trying to capture structure of the table. 

Do you see the same behavior using the latest released Debezium version?

(Ideally, also verify with the latest Alpha/Beta/CR version)

Yes with the latest debezium-connector-oracle-2.3.0.Alpha1-plugin

Do you have the connector logs, ideally from start till finish?

(You might be asked later to provide DEBUG/TRACE level log)

debezium-connect-orcale_after_ddl_is_set_to_true.log

How to reproduce the issue using our tutorial deployment?

It's partially based on the tutorial for Openshit but with Mysql DB as a source (https://github.com/debezium/debezium-examples/tree/main/openshift) and oracle specific part is taken from https://debezium.io/documentation/reference/2.3/connectors/oracle.html

Feature request or enhancement

For feature requests or enhancements, provide this information, please:
Ensure changes are captured from specified 'pdb' Oracle DB and specified schema and table list via LogMiner API

Which use case/requirement will be addressed by the proposed feature?

To perform CDC for selected DB schema or even tables from the Oracle server with multiple schemas

Implementation ideas (optional)

<Your answer>