Log inRequest a demoStart free

Guides

Test data management for Oracle Database

Building safe Oracle test data - read-only extraction, entity subsets, consistent masking - and what DataNivra's Oracle connector covers today and what it does not.

Guide

Oracle Database sits underneath many of the oldest and most important systems in an enterprise: billing, core banking, policy administration, hospital information systems. These schemas are large, heavily customised and full of personal data, and their test environments are often years-old clones that nobody dares to refresh. This guide describes what good Oracle test data management looks like and where DataNivra stands today.

Current status: available

The Oracle connector is available in agent 0.2.0 and later. It uses python-oracledb in thin mode, so the agent needs no Oracle Client libraries. It passed DataNivra's connector conformance kit against Oracle Database Free (23.26), covering discovery, read-only proof, bounded reads, masking, subsetting, certification and provisioning of a synthetic estate. The Oracle integration page shows the tested versions and limitations from the same registry the product uses.

What it does not cover yet:

  • It needs agent 0.2.0 or later; agent 0.1.0 does not contain its driver.
  • Password authentication only. TCPS (TLS) is the default, and the conformance run proved that the default refuses a listener without TLS, but a full TCPS session and wallet-based mutual TLS are not yet part of the run.
  • Versions: Oracle 19c and Amazon RDS for Oracle are still to be tested.
  • XMLTYPE and INTERVAL columns are carried as text, DATE as a timestamp (an Oracle DATE has a time of day), and NUMBER without declared precision as double precision. Object, nested-table and VARRAY columns are not read.

What makes Oracle test data difficult

  • Full clones are the default. RMAN duplicates and Data Pump full exports are well understood by DBAs, so lower environments end up holding complete copies of production, including personal data that no test requires.
  • Relationships are not all declared. Many Oracle applications enforce integrity in PL/SQL packages or triggers rather than foreign-key constraints. A subset built only from declared constraints will leave dangling references.
  • Masking in place has side effects. Triggers, materialised views, auditing and flashback can all retain or propagate original values when you update rows after the copy.
  • Schemas drift. Large Oracle applications apply patches that add columns and tables; a masking script written last year silently misses the new sensitive column. Detecting that is covered in schema drift and failure recovery.

What a good Oracle extraction should look like

The connector's read-only proof is explicit: before reading, it queries SESSION_PRIVS, USER_TAB_PRIVS and ROLE_TAB_PRIVS and refuses to read if the account holds any system privilege beyond read access, any INSERT, UPDATE, DELETE, ALTER or INDEX object grant, or owns tables of its own (an Oracle user can always change its own tables, so the reader must be a separate user). Every transaction it starts is also SET TRANSACTION READ ONLY. Whatever tooling you use, apply the same discipline:

  1. Create a dedicated extraction account with CREATE SESSION and SELECT on the required objects only, ideally against a physical standby or read-only replica.
  2. Pick root business entities (customers, policies, accounts) and extract them with their dependent rows, not whole tables.
  3. Record the relationships the application enforces in code, so they can be declared to the subsetting step.

Outside the connector's limits: export to Parquet or CSV

For databases the connector does not cover yet (for example an Oracle release not yet tested, or object-type columns you need), an extract inside your network works today:

  1. Export the needed tables to Parquet or CSV with a tool you already operate (for example an existing ETL job or a Data Pump export converted by your pipeline). Keep the files inside your boundary; they are sensitive until masked.
  2. Register the landing directory as a read-only Local files source, or upload to your own Amazon S3 bucket or Azure Blob / Data Lake container.
  3. Declare table names and CSV header handling; the agent never reports data-derived file names.
  4. Declare foreign keys and application-level relationships through a policy or an industry pack, because Parquet files carry no constraints.
  5. Discover, classify, subset, mask, certify and provision as with any other source. The subsetting tutorial explains how roots and closure work.

How DataNivra approaches it

Row-level work always happens in the agent and engine inside your network. Masking is deterministic under a key you hold, so the same customer id becomes the same pseudonym across every table and every refresh; certification gates block any dataset whose masking or referential integrity cannot be proven. DataNivra Cloud sees names, counts and evidence references only.

Next steps

  • Follow the Oracle status and other connectors on the integrations page.
  • Use the free tools to estimate subset sizes and draft a masking policy from column names.
  • Read the documentation on file-set sources and agent installation.
  • Start free with the synthetic sandbox while you plan the export path.