Oracle Database test data, inside your network

What works today

Dedicated Oracle connector (python-oracledb thin mode, no Oracle Client needed): schema discovery, primary and foreign keys, optimizer row estimates, aggregate profiles and bounded streaming reads inside read-only transactions.

Password as a secret reference. TCPS (TLS) is the default, with certificate and host-name verification; plain TCP must be chosen explicitly and a session that should be TLS but is not is refused.

Authentication: password (secret reference).

Known limitations

• Requires agent 0.2.0 or later; agent 0.1.0 does not include its driver.
• Password authentication only. The conformance run used plain TCP (the test listener has no TLS endpoint); it proved that the TCPS default refuses such a listener, but a TCPS session and wallet-based mTLS are not yet part of the run.
• Tested against Oracle Database Free (23.26); Oracle 19c and Amazon RDS for Oracle are still to be tested.
• XMLTYPE and INTERVAL columns are carried as text, DATE as a timestamp, and NUMBER without declared precision as double precision; object, nested-table and VARRAY columns are not read.

Capability matrix

Each capability is tracked separately and shown at the level the recorded conformance evidence supports. A connector that only discovers metadata is never presented as equivalent to one that runs the whole workflow.

Read-only proof

Proven from the dictionary before reading: SESSION_PRIVS may hold only read privileges (CREATE SESSION, SELECT/READ ANY ...), USER_TAB_PRIVS and ROLE_TAB_PRIVS no INSERT, UPDATE, DELETE, ALTER or INDEX grant, and the user must own no tables.

Compatibility profiles

Managed variants of an engine are profiles of this connector, not separate connectors. A profile is marked tested only when its own conformance run passed.

• Amazon RDS for Oracle — not tested yet (roadmap only)

Conformance evidence

DataNivra runs every connector through a common conformance kit on synthetic data: no write statements, proven read-only access, secret redaction, schema and relationship discovery, bounded streaming, cancellation, clear reason codes, egress canaries and no raw values in logs, then the discover, mask, subset, certify and provision workflow. The published status is computed from those results.

Connector version 0.1.0, last verified 2026-09-30.

What crosses the boundary

Connectors run inside the agent in your network. Only metadata, aggregates and evidence reach DataNivra Cloud:

• Schema, table and column names and data types (for file sets, operator-declared or opaque table names — never data-derived file names).
• Aggregates such as row-count estimates, null and distinct ratios; counts from 1 to 10 are reported as 10 (small-cell protection).
• Classification findings (which column looks like which kind of sensitive data) and relationship metadata.
• Evidence metadata: checksums, gate outcomes, engine and policy versions, and templated error codes.

Never sent:

• Any cell value, row, sample, minimum/maximum or top-k value — masked or not.
• Credentials, connection strings or resolved secret values: DataNivra stores only the secret reference.
• Free text copied from your data, or exception messages that contain values.

See the customer-resident architecture and how to verify these claims yourself.

Setup outline

1. Use agent 0.2.0 or later (earlier agent images do not include the Oracle driver).
2. Create a user with CREATE SESSION and SELECT (or READ) on the tables to read, no INSERT, UPDATE, DELETE, ALTER or INDEX grants, and owning no tables.
3. Store the connection document with the password as a secret reference. TCPS (TLS) is the default, with certificate and host-name verification; plain TCP must be chosen explicitly.
4. In the console, register the source with the secret reference of that document (for example vault://tdm/source-connection) and the agent that can reach it, then run discovery.
5. Before reading, the agent proves the user is read-only from the data dictionary and refuses to continue if it is not.

Example connection document, stored in your secret store and resolved by the agent locally (DataNivra only ever sees its reference):

{
  "kind": "ORACLE",
  "host": "claims-ora.db.example.internal",
  "service_name": "CLAIMS",
  "user": "TDM_READER",
  "password_ref": "vault://tdm/claims-ora#password",
  "schemas": ["CLAIMS"]
}

Next: install the agent, then follow the getting started guide.