Getting started

A first conversion, end to end.

This walkthrough drives a single Oracle schema from extraction to a validated PostgreSQL target. It uses the CLI for clarity. The desktop application drives the same engine through a graphical interface.

Before you start

  • Trekport is installed. See installation.
  • You have a connection string for the source Oracle and the target PostgreSQL.
  • The target PostgreSQL allows the extensions listed in the compatibility layer.

1. Extract the source catalog

The extractor connects to Oracle, walks the data-dictionary views, and serializes every object into a portable catalog mirror on local disk. The mirror is human-readable and version-controllable.

terminalbash
trekport extract \
  --source oracle://hr@oracle.internal:1521/HR \
  --output ./catalog

The catalog mirrors the data-dictionary layout one to one. Tables land under ./catalog/HR/tables/, packages under ./catalog/HR/packages/, and so on. Roles, privileges, and tablespaces land under ./catalog/_database/.

2. Run the conversion

The converter reads from the catalog mirror, parses every artifact into a syntax tree, applies translation rules, and emits PostgreSQL output. The converted tree mirrors the catalog tree one to one.

terminalbash
trekport convert \
  --input ./catalog \
  --output ./converted \
  --report ./reports/conversion.html

Inspect ./reports/conversion.html. Every translation decision is logged, including the rule reference, the parse-tree change, and any object that was deferred.

3. Deploy to the target

The deployer applies the converted tree to PostgreSQL in fourteen dependency-ordered phases. Failures retry across passes. Each phase emits a typed status into the deployment report. The exact phase order is documented in deployment phases.

terminalbash
trekport deploy \
  --converted ./converted \
  --target postgres://hr@pg.internal:5432/hr_target \
  --phases all \
  --extensions orafce,pg_cron,http

4. Transfer the data

Data transfer runs after the schema has landed. Temporal and binary columns route to the correct loader path automatically. Other tables use the high-throughput bulk-load path. The transfer is idempotent on the target.

terminalbash
trekport transfer-data \
  --source oracle://hr@oracle.internal:1521/HR \
  --target postgres://hr@pg.internal:5432/hr_target \
  --parallelism 8 \
  --validate

5. Validate

Validation checks row counts, sample-row equivalence, and smoke queries against the source. The output is a signed validation report — the artifact for change-management review.

terminalbash
trekport validate \
  --source oracle://hr@oracle.internal:1521/HR \
  --target postgres://hr@pg.internal:5432/hr_target \
  --output ./reports/validation.html

What you get

OutputLocationPurpose
Catalog mirror./catalog/Inspectable serialization of the Oracle source.
Converted output./converted/The deployable PostgreSQL tree.
Conversion report./reports/conversion.htmlEvery translation decision, by object.
Deployment report./reports/deploy.htmlPer-phase status and classifier buckets.
Validation report./reports/validation.htmlRow counts, checksums, and sample equivalence — the cutover artifact.

Re-running

Every stage is idempotent against a clean target. Re-running the same inputs against the same target produces a deploy report with zero changes. This is the contract that makes Trekport safe to rehearse against staging environments.

Related reading