# Oracle Database

> Connect Oracle Database to LightHouse: your own read-only database user, the privileges it holds, where the credential is held, and what is indexed.

The engine reads the tables and views you name, in place, from your own database, through a read-only user, into a knowledge base.

Content is read in place, in your deployment, in your own account. LightHouse receives ids, hashes and counts only. The records are not transmitted, and LightHouse does not open the credential.

## The way to connect

| Way                                | What you do                                                                                                                                                                                 |
| ---------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Give a read-only database user** | Make a user with `CREATE SESSION` and `SELECT` on the named tables and views, and nothing else. Paste three lines: the connect string (`host:port/service_name`), the user and its password |

## Connect in LightHouse

You need the **Client administrator** (`client_admin`) role, signed in as a person, and a deployment whose engine reads this connector ([compatibility reference](/concepts/telemetry-contract/#compatibility-reference)) and keeps credentials in your own store.

1. Go to **Setup and admin → Connectors**, find **Oracle Database** (search for it, or filter by its family), and choose **Connect**.
2. Fill in `tables`.
3. The connection is **Read only**: this connector offers no other level.
4. Paste three lines: the connect string, the user, then its password. Your browser seals it to your deployment; LightHouse never sees it.
5. Your deployment keeps it and checks it at the provider. The card shows the result.

## Connect in code

```yaml
- id: oracle-db-knowledge
  purpose: Read Oracle Database into the knowledge base.
  executor: python
  target: aal_engine.ingest.connector:run_card
  overseer: ops-lead@example.com
  budget_usd: 0
  effect: internal
  source:
    kind: oracle-db
    tables:
      - table: SUPPORT.KNOWN_ISSUES
        key: ISSUE_ID
        updated: LAST_UPDATED          # optional: read whole on every pull without it
        title: SUMMARY                 # optional
        columns: [SUMMARY, FLEET, WORKAROUND, STATUS]   # optional: every column otherwise
    label: internal
    credential_secret: <connection id>
    requires:
      reads: [oracle-db:SUPPORT.KNOWN_ISSUES]
      reason: the engineering agents answer from the known-issues register
```

## Privileges

- **Read only, always**: `CREATE SESSION` and `SELECT` on the named objects. Read and write is not offered.
- **Only `SELECT` is ever run**, in a read-only transaction. Every name is checked and quoted, and every value is a bind variable.
- **The health check**: your deployment connects and asks the database for the session’s privileges. They are the card’s scopes, and any privilege beyond reading is flagged: a connection whose user could change the database is marked failing.
- **Where it connects**: from your deployment, in your network, with python-oracledb in thin mode (the engine’s `oracle` extra; no Oracle Instant Client).

## Where the credential is held

LightHouse never opens this credential. It is sealed in your browser, or by `lighthouse-ai connect oracle-db --credential-stdin`, to your deployment’s own key, and your deployment keeps it in your own secrets store under `lighthouse/connectors/oracle-db/<connection id>`. A request that sends it to LightHouse unsealed is refused with `422 sealing_required`. LightHouse keeps the connection’s fingerprint, the access level, the scopes the provider states and when it was checked: never the credential, and never what it reads.

See [Where every credential is held](/connect/#where-every-credential-is-held).

## What is indexed

- **Rows** of the tables and views named, one document per row, with the columns named.
- **How often, and what is read each time**: on the card’s schedule. With an `updated` column, each pull reads rows later than the cursor (less a five-minute margin for long transactions), in order. Without one, the table is read whole on every pull and only rows that changed are written.
- **Deletions**: every six hours the keys are listed and a row that has gone is removed. A table the user can no longer see keeps its rows until it can be listed again.
- **Large values**: a LOB is read as text up to a cap; binary values are never written.
- **Never read**: tables and views you do not name.

## Check it worked

- The source’s run note in your deployment: `written N, unchanged N, quarantined N, removed N`.
- **Agents → Knowledge**: documents from `oracle-db`.
- Content is read in place, in your deployment. LightHouse receives ids, hashes and counts only; the records are not transmitted.

## Removing it

On the card, choose **Disconnect**. Your deployment deletes the credential from your store. Lock or drop the user, as the database’s administrator (`ALTER USER <user> ACCOUNT LOCK`). Documents already written stay in the corpus until you delete them.

Source: https://docs.atlanticagenticlabs.com/connect/oracle-db/