Oracle Database

Connect to your Oracle database.

Getting Started

Prerequisites to create an Oracle Database based workflow. You will need

  1. A source Oracle Database connection.

  2. (optional) A list of tables OR SQL queries.

  3. (optional) A destination Oracle Database connection OR object storage connection.

For the source database connection, we recommend using a backup or clone with read-only permissions, instead of connecting directly to your production database.

Do not use your input database connection as an output connector. This action can result in the unintended overwriting of existing data.

Create a Connection

A oracle connection is created using the following parameters:

Connection Creation Parameters

Creating Connections

First, create a file on your local computer containing the connection credentials. This file should also include type, name , config, and credentials. The config and credentials fields should contain fields that are specific to the connection being created.

Below is an example Oracle Database connection:

{
    "type": "oracle",
    "name": "my-oracle-connection",
    "config": {
        "username": "john",
        "host": "myserver.example.com",
        "port": 1521,
        "service_name": "mydatabase"
    },
    "credentials": {
        "password": "..."
    }
}

Now that you've created the credentials file, use the CLI to create the connection

gretel connections create --project [project id] --from-file [credential_file.json]

Oracle Database Source Action

The oracle_source action reads data from your Oracle database. It can be used to extract:

  • an entire database, OR

  • selected tables from a database, OR

  • the results of SQL query/queries against a database.

Each time the workflow is run the source action will extract the most recent data from the source database.

When combined in a workflow, the data extracted from the oracle_source action is used to train models and generate data with the gretel_tabular action, and can be written to an output database with the oracle_destination action. Your generated data can also be written to object storage connections, for more information see Writing to Object Storage.

For the source database connection, we recommend using a backup or clone with read-only permissions, instead of connecting directly to your production database.

Inputs

The oracle_source action takes slightly different inputs depending on the type of data you wish to extract. Flip through the tabs below to see the input config parameters and example action YAMLs for each type of extraction.

Entire Database

Example Source Action YAML

actions:
  - name: extract-database
    type: oracle_source
    connection: conn_1
    config:
      sync:
          mode: full

Outputs

Whether you are extracting an entire database, selected tables, or querying against a database, the oracle_source action always provides a single output, dataset.

The output of a oracle_source action can be used as the input to a gretel_tabular action in order to transform and/or synthesize a database.

Oracle Database Destination Action

The oracle_destination action can be used to write gretel_tabular action outputs to Oracle destination databases.

Inputs

Whether you are writing an entire database, selected tables, or table(s) created via SQL query, the oracle_destination action always takes the same input, dataset.

Sync Modes

There are multiple strategies for writing records into the destination database. These strategies are configured from the sync.mode field on a destination config.

sync.mode may be one of truncate, replace, or append.

Sync Mode: Truncate

When sync.mode is configured with truncate, records are first truncated from the destination table using the TRUNCATE TABLE DML command.

When sync mode is configured with truncate the destination table must already exist in the database.

Sync Mode: Replace

When sync.mode is configured with replace, the destination table is first dropped and then recreated using the schema from the source table.

If the source table is from Oracle, the DDL is extracted using the GET_DDL interface from the DBMS_METADATA package. If the source table is from a non Oracle source, the destination table schema is inferred based on the column types of the source schema (if present) or data.

When sync mode is configured with replace the destination table does not need to exist in the destination.

To respect foreign key constraints and referential integrity, tables without foreign keys are inserted first, and tables with foreign key references are inserted last.

When applying table DML for truncate or replace, operations are applied in reverse insertion order. This is to ensure records aren't deleted with incoming foreign key references.

It's also important to note: all table data is first dropped from the database before inserting new records back in. These operations are not atomic, so there may be periods of time when the destination database is in an incomplete state.

Sync Mode: Append

When sync.mode is configured with append, the destination action will simply insert records into the table, leaving any existing records in place.

When using the append sync mode, referential integrity is difficult to maintain. It's only recommended to use append mode when syncing adhoc queries to a destination table.

If append mode is configured with a source that syncs an entire database, it's likely the destination will be unable to insert records while maintaining foreign key constraints or referential integrity, causing the action to fail.

Example Destination Action YAML

actions:
...
  - name: oracle-write
    type: oracle_destination
    connection: conn_2
    input: synthesize
    config:
      sync:
        mode: replace
      dataset: {outputs.synthesize.dataset}

Writing to Object Storage

You can also write your output dataset to an object storage connection like Amazon S3 or Google Cloud Storage. Whether you are writing an entire database, selected tables, or table(s) created via SQL query, the {object_storage}_destination action always takes the same inputs - filename and input, and path. Additionally, S3 and GCS take bucket and Azure Blob takes container.

Example Destination Action YAML

actions:
...
  - name: s3-write
    type: s3_destination
    connection: conn_2
    input: <action-name>
    config:
     bucket: my-gretel-bucket
     filename: {outputs.<action-name>.dataset.files.filename}
     input: {outputs.<action-name>.dataset.files.data}
     path: gretel

Example Workflow Configs

Create a synthetic version of your Oracle database.

The following config will extract the entire Oracle database, train and run a synthetic model, then write the outputs of the model back to a destination Oracle database while maintaining referential integrity.

name: sample-oracle-workflow-full-db

actions:
  - name: oracle-read
    type: oracle_source
    connection: conn_1
    config:
      sync:
          mode: full

  - name: synthesize
    type: gretel_tabular
    input: oracle-read
    config:
      project_id: proj_1
      train:
        model: "synthetics/tabular-actgan"
        dataset: {outputs.oracle-read.dataset}
      run:
        num_records_multiplier: 1.0

  - name: oracle-write
    type: oracle_destination
    connection: conn_2
    input: synthesize
    config:
      sync:
        mode: replace
      dataset: {outputs.synthesize.dataset}

Last updated