For the complete documentation index, see llms.txt. This page is also available as Markdown.

Oracle Database

Connect Oracle Database or Autonomous Database with Algenta's bundled Thin-mode driver, verify credentials once, browse schemas, and onboard a table or query.

Algenta connects to Oracle Database and Oracle Autonomous Database with the bundled python-oracledb Thin-mode driver. You do not install Oracle Instant Client, manage an additional runtime process, or add a Python package to the Algenta service. Algenta owns the driver, bounded connection pool, credential verification, schema browse, and Arrow-batch fetch path.

Use either:

  • TLS without a wallet with an Easy Connect DSN.

  • mTLS with an Autonomous Database wallet using a TNS alias, tnsnames.ora, and ewallet.pem.

No separate Oracle setup in Algenta

The API image pins oracledb==4.0.1, which supports Python 3.9 through 3.14 and defaults to Thin mode. Thin mode connects directly to Oracle Database and does not require Oracle Client libraries. Your only external prerequisite is a reachable Oracle database and valid database credentials.

For Autonomous Database wallet details, see Oracle's python-oracledb Thin-mode mTLS guide.

Config fields

Field
Required
Notes

user

yes

Oracle Database user, for example a dedicated read-only application user. username is accepted as an alias.

password

yes

Database-user password. This is not an OCI auth token or wallet password.

dsn

yes*

Easy Connect string, full connect descriptor, or TNS alias. connect_descriptor is accepted as an alias.

host

yes for a TNS alias

Required separately when dsn is an alias so the egress policy can validate the destination. It is inferred from Easy Connect strings and full descriptors.

port

no

Defaults to 1521, or 1522 when wallet_location is set.

service_name

yes*

Used with host to build a DSN when dsn is omitted. database is accepted as an alias.

config_dir

wallet connections

Directory containing tnsnames.ora. tns_admin is accepted as an alias.

wallet_location

mTLS only

Directory containing ewallet.pem for Thin mode.

wallet_password

with wallet_location

Password used to decrypt the wallet. This is distinct from the database password.

schema

no

Limits browse results to one Oracle owner/schema.

pool_min

no

Idle sessions kept per connector config; defaults to 0.

pool_max

no

Maximum pooled sessions; defaults to 4.

pool_wait_timeout_ms

no

Bounded acquire wait; defaults to 2000.

fetch_batch_size

no

Arrow fetch batch size; defaults to 10000.

limit

no

Positive maximum rows fetched from the selected query.

* Provide dsn, or provide both host and service_name so Algenta can build one.

Connect and onboard in one request

POST /v1/data/connect is the shortest production path. It stores the connector, performs one credential probe while its status is untested, persists the resulting live or error state, and onboards the selected table or query.

Expected result: status is ready, provider is oracle, and the response includes a connection_id, dataset_id, and schema summary. A failed first probe returns status: "failed", the saved connection_id, and a classified message without returning credentials.

Selection resume, dataset refresh, and query execution do not repeat the credential-only probe. A persisted live or error result is reused at 0 ms. Reads still perform the database operation they were asked to perform; external Oracle network latency is not reported as an Algenta warm-cache latency.

Autonomous Database with an mTLS wallet

Extract the wallet into a directory readable by the Algenta API process. Thin mode uses tnsnames.ora and ewallet.pem; Algenta does not require Instant Client or sqlnet.ora.

Use the wallet fields in connection_config:

The literal $... values above are placeholders. SDK and HTTP clients must resolve them from their secret store before sending JSON; Algenta never expands environment-variable names inside a JSON request.

Explicit connector lifecycle

Use the connector endpoints when you want to save, inspect, or browse the connection before onboarding data.

The explicit create endpoint returns untested; /test runs SELECT 1 FROM DUAL and persists live or error. Calling /test is always an explicit operator-requested probe. Browsing lists at most 200 tables and views and requires a live connector.

Query and pool behavior

Algenta accepts only SELECT and WITH query roots for Oracle datasets. When limit is set, it wraps the query with a bound ROWNUM limit. Results are fetched in Arrow-compatible batches and the bounded pool is reused across requests with the same connector config. If every configured pool slot is unavailable, the operation fails explicitly; it never opens a hidden unpooled fallback connection.

The pool removes cold-start setup from repeated reads, but it cannot remove the network round trip to Oracle. Governed queries run against Algenta's registered dataset path; use dataset refresh when you intentionally need a new Oracle snapshot.

Troubleshooting

Next

Connect a databaseConnectors referenceQuery governed data

Last updated

Was this helpful?